하네스를 오래 돌리게 되자, 병목은 ‘하나뿐’이 되었다

지난 시간까지는 한 하네스가 긴 일을 끝까지 하게 만들었습니다. 이제는 여러 하네스를 누가 나눠 주고 점검하나가 문제입니다.

같은 회사 모델도 입력 단가가 최대 100배 차이 난다

platform.claude.com/docs/en/about-claude/pricing

공식 문서 화면 캡처 · 2026-10-28 확인

Anthropic 공식 가격표. 모델마다 값이 달라서, 가장 비싼 모델과 가장 싼 모델이 100배 차이 난다.

• 같은 회사 안에서도 입력 단가가 최대 100배: Fable 5.1 $10 vs Haiku 5.5 $0.10 (모델에 보내는 글 100만 토큰당)
• 어려운 설계는 비싼 모델, 문서·테스트 정리는 싼 모델
• 회사가 다르면 강점도 다르다. 한 도구에 묶이지 않는다

한 사람이 큰 프로젝트를 맡으려면 하네스가 여러 개여야 한다

개발자는 코드를 쓰는 사람에서 일을 나누고 결과를 판정하는 사람이 됩니다. 하네스가 여러 개여야 한 사람이 큰 프로젝트를 감당합니다.

여섯 달 만에 모든 도구가 같은 방향으로 갔다

GitHub는 여러 회사의 에이전트를 한곳에서 관리하겠다고 밝혔다

github.blog/news-insights/company-news/welcome-home-agents

공식 발표 화면 캡처 · 2025-10-28

GitHub가 낸 Agent HQ 발표 글. Anthropic · OpenAI 등의 코딩 에이전트를 GitHub 안에서 쓰게 하겠다는 내용.

• Anthropic · OpenAI · Google · Cognition · xAI의 에이전트를 GitHub 안에서
• 미션 컨트롤: 작업을 배정하고 진행을 보는 관제 화면

여러 회사의 에이전트를 GitHub 한곳에서 배정하고 추적한다. 이슈·PR(Pull Request, 변경 병합 요청)이 이미 거기 있다.

발표 시점엔 앞으로 몇 달에 걸쳐 제공한다는 계획. 관제 화면이지 일을 나누는 방법은 아니다.

코드가 모이는 플랫폼이 ‘모든 에이전트의 집’이 되려는 움직임. 이슈·PR은 뒤의 코디네이터 패턴의 바탕.

Codex 앱은 에이전트마다 저장소 사본을 따로 준다

learn.chatgpt.com/docs/app

OpenAI 공식 문서 화면 캡처 · 2026-10-28 · 현재는 ChatGPT 데스크톱 앱 문서

OpenAI Codex 앱 공식 문서 첫 화면. 여러 에이전트를 프로젝트별 스레드로 나란히 돌리는 앱.

• 프로젝트별 스레드로 여러 에이전트를 나란히, 하나를 보다 다른 하나로 전환
• 에이전트마다 저장소의 격리된 워크트리(작업용 사본)
• 스킬과 예약 작업(자동화)을 앱 안에 내장

에이전트마다 워크트리를 따로 줘 서로 덮어쓰지 않는다. 스킬·예약 작업도 앱에 내장.

첫 출시는 macOS 먼저. 발표문 접근이 막혀 날짜·기능은 2차 보도로 확인했다.

7교시에서 손으로 하던 워크트리가 상용 앱의 기본 기능이 되었다.

agent teams: 팀 리드가 독립된 세션의 팀원들을 이끈다

code.claude.com/docs/en/agent-teams

공식 문서 화면 캡처 · 2026-10-28 확인

Claude Code 공식 문서의 agent teams 설명. 한 세션이 팀 리드, 나머지가 팀원이 되어 작업 목록을 공유.

• 한 세션이 팀 리드, 나머지는 각자 컨텍스트 창(기억 범위)을 가진 팀원
• 공유 작업 목록과 메시지함으로 서로 조율
• 서브에이전트보다 토큰을 많이 쓴다. 실험 기능(환경 변수로 켠다)

팀원끼리 직접 메시지를 주고받고 작업 목록을 공유해, 결과만 돌려주는 서브에이전트보다 조율이 촘촘하다.

토큰을 많이 쓰는 실험 기능. 두 팀원이 같은 파일을 고치면 덮어쓴다(문서 경고).

뒤에서 볼 코디네이터 패턴의 가까운 형제. 담당 파일을 나누는 습관이 필수.

Cursor 3는 에이전트 여러 개를 병렬로 돌리는 새 창을 내놓았다

cursor.com/changelog/3-0

공식 변경 기록 화면 캡처 · 2026-04-02

Cursor 3 변경 기록. Agents Window에서 여러 에이전트를 로컬·클라우드 등 어디서든 병렬로 돌린다는 내용.

• 여러 에이전트를 병렬로: 로컬 · 워크트리 · 클라우드 · 원격 SSH(Secure Shell, 원격 접속)
• /best-of-n: 같은 작업을 여러 모델에 동시에 시켜 가장 나은 결과 고르기
• /worktree: 변경을 격리된 워크트리에서

로컬·워크트리·클라우드·SSH 어디서든 병렬 실행. /best-of-n으로 여러 모델의 결과를 비교.

같은 일을 여러 모델에 시키면 실행량도 그만큼 는다. 최선을 비교해 고르는 일이 남는다.

모델별 차이를 도구가 직접 활용한다. IDE(Integrated Development Environment, 통합 개발 환경)와 창을 함께 연다.

병렬 에이전트 관리의 대표 도구, Orca

onorca.dev/docs

공식 문서 화면 캡처 · 2026-10-28 확인

Orca 공식 문서 첫 화면. Orca는 Codex · Claude Code 같은 CLI 에이전트를 한 화면에 나란히 돌리는 개발 도구.

“Run Codex, ClaudeCode, OpenCode or Pi side-by-side”Codex, ClaudeCode, OpenCode, Pi를 나란히 실행하세요Orca README · stablyai/orca

• 모델이 아니다. 내가 구독한 CLI 에이전트(터미널용)를 그대로 쓴다

쓰던 CLI 에이전트를 그대로 한 화면에서. 작업마다 워크트리·터미널·브라우저 한 벌. MIT 라이선스.

첫 커밋이 2026-03-16인 일곱 달 된 프로젝트. 기본값이 권한 우회(16장).

앞의 도구들이 간 방향을 워크트리 단위로 가장 투명하게 보여 줘서 자세히 뜯어 본다.

Orca: 작업 하나 = 워크트리 하나 = 에이전트 하나

onorca.dev/docs/model/worktrees

공식 문서 화면 캡처 · 2026-10-28 확인

Orca 문서의 워크트리 모델 설명. 기준 지점에서 작업마다 워크트리를 하나씩 만들고 그 안에서 에이전트가 일한다.

1. 저장소마다 base ref(기준, 보통 origin/main), 워크트리마다 start-from ref(갈라질 시작점)
2. 워크트리마다 자기 브랜치 · 자기 파일 · 자기 에이전트 터미널
3. 생성 → 작업 → 검토 → 출하(커밋·푸시·PR) → 삭제까지 한 흐름

진짜 git 워크트리라서 터미널에서 일반 git을 그대로 쓸 수 있습니다.

Orca는 터미널에서 도는 에이전트면 모두 돌릴 수 있다

onorca.dev/docs/agents/supported

공식 문서 화면 캡처 · 2026-10-28 확인

Orca 문서의 지원 에이전트 표. Claude Code · Codex 등 수십 종이 미리 설정되어 있고, 일부만 깊게 연동된다.

• 기본 목록: Claude Code · Codex · Cursor CLI · Gemini · GitHub Copilot · OpenCode 등 수십 종
• 깊은 연동(사용량 · 계정 전환 · 훅): Claude Code, Codex 등 일부
• 나머지는 “터미널에서 돌면 Orca에서 돈다”

Orca 한 화면에서 열 개 안팎의 작업을 감시한다

github.com/stablyai/orca

저장소 소개 화면 캡처 · 왼쪽 워크트리 목록, 가운데 Claude Code · Codex 터미널, 오른쪽 모바일 앱

Orca 소개 화면. 왼쪽 워크트리 목록, 가운데 에이전트 터미널, 오른쪽 휴대폰 앱으로 작업 상태를 한눈에 본다.

• 왼쪽: 워크트리 목록. 작업 중 · 입력 대기 · 완료 · 실패를 점으로 표시
• 가운데: 워크트리마다 에이전트 터미널(분할 가능)
• 오른쪽: 파일 · diff · 내장 브라우저. 휴대폰 앱으로 알림과 후속 지시

Orca: 같은 프롬프트로 세 에이전트를 경주시키고 하나만 고른다

onorca.dev/docs/first-session

공식 문서 화면 캡처 · 2026-10-28 확인

Orca 문서의 ‘첫 3-에이전트 세션’ 안내. 같은 프롬프트를 세 에이전트에 주고 가장 나은 결과 하나만 고른다.

# 첫 3-에이전트 세션 흐름 1 Add Repo(저장소 추가) → 로컬 저장소 선택 2 + → 작업 이름 → 워크트리 생성 3 에이전트 고르기 (Claude Code · Codex · Cursor CLI) 4 같은 프롬프트를 세 워크트리에 붙여 넣기 5 사이드바 상태로 감시 → diff 비교 ✓ 가장 나은 하나만 커밋·푸시, 나머지는 삭제

Orca: 에이전트가 orca 명령으로 작업과 워커를 직접 만든다

onorca.dev/docs/cli/orchestration

공식 문서 화면 캡처 · 2026-10-28 확인

Orca 문서의 오케스트레이션 CLI 안내. 코디네이터가 작업을 만들고 워커를 띄운 뒤 완료 신호를 기다린다(실험 기능).

$ orca orchestration run-create --objective "결제 화면 QA" $ orca orchestration task-create --spec "모바일 레이아웃 점검" $ orca orchestration worker-start --task <taskId> \ --worktree new-child --agent codex $ orca orchestration check --wait \ --types worker_done,escalation,question Run(실행) · Task(작업) · Dispatch(배정) · Message · Decision gate(결정 관문) ! 워커(작업 맡은 에이전트)는 끝나면 worker_done을 한 번 보낸다

Orca는 빨리 바뀌고, 기본값이 권한 우회라 주의해야 한다

github.com/stablyai/orca/releases

GitHub 릴리스 화면 캡처 · 2026-10-28

Orca 릴리스 목록(v1.4.243). 거의 매일 새 버전이 나올 만큼 변화가 빠르다.

• 기본값이 권한 우회 플래그(승인 없이 실행, 수동 선택 가능). 워크트리는 파일만 나눌 뿐 보안 샌드박스가 아니다
• 오케스트레이션은 실험 기능. 명령이 바뀐다(구 명령은 폐기)
• 거의 매일 배포. 버전이 빨리 바뀐다
• 합치기·CI(Continuous Integration, 지속적 통합 자동 검사) 폭증은 해결해 주지 않는다 → 15교시

→ 편리하지만 실험적이니 권한 설정부터 확인

코디네이터-배치 패턴: 코딩하지 않는 세션이 일을 나눈다

코디네이터는 목표와 완료 조건을 쥐고, 워커에게 배치로 일을 나눠 준 뒤, 이슈·PR·CI를 읽어 다음 배치를 정합니다.

코디네이터는 읽고 보내고, 워커는 코딩한다

코디네이터의 컨텍스트 창을 코드로 채우지 않는 것이 핵심입니다. 그래서 며칠을 버팁니다.

/batch: 큰 변경을 독립 단위로 쪼개 워크트리에 뿌린다

code.claude.com/docs/en/commands

공식 문서 화면 캡처 · 2026-10-28 확인

Claude Code 명령 문서의 /batch 항목. 큰 변경을 5~30개 독립 단위로 나눠 단위마다 서브에이전트가 맡는다.

• 코드베이스를 조사해 5~30개 독립 단위(서로 안 겹치는 작업 조각)로 분해, 계획을 보여 준다
• 승인하면 단위마다 백그라운드 서브에이전트(보조 에이전트)가 격리된 워크트리에서
• 각자 구현 · 테스트 · 변경 게시

큰 변경을 5~30개 독립 단위로 쪼개 병렬 처리. 승인 전에 계획을 보여 준다.

단위가 서로 안 겹쳐야 한다. 겹치면 합치는 비용이 병렬의 이득을 지운다.

배치 한 번의 모양. 코디네이터 패턴은 이를 반복해 며칠을 간다.

/loop: 간격을 생략하면 Claude가 스스로 깨울 시각을 정한다

code.claude.com/docs/en/scheduled-tasks

공식 문서 화면 캡처 · 2026-10-28 확인

Claude Code 예약 작업 문서. /loop는 같은 일을 되풀이하는 명령이고, 간격을 빼면 Claude가 다음 시각을 고른다.

• /loop 5m …: 고정 간격. 2.1.71(2026-03-06)에서 추가
• 간격 없이 /loop …: 매 회차 끝에 다음 깨우기까지 1분~1시간 중 길이를 Claude가 고른다

간격을 생략하면 Claude가 1분~1시간 중 알맞게 다음 깨우기를 고른다.

세션이 열려 있어야 깨어나고, 반복 작업은 7일 뒤 만료된다.

코디네이터가 스스로 깨어 점검하게 하는 장치. 만료는 25장에서 다시 본다.

한 사이클: 깨어나서 읽고, 판단하고, 보내고, 다시 잔다

판단은 세 갈래입니다. 보낸다(빈 자리가 있다), 고친다(실패·충돌), 끝낸다(완료 조건 충족). 끝내는 것도 코디네이터의 일입니다.

며칠에 걸친 완주: 배치 → 점검 → 재배정 → 마무리

예시 도식 · 강사 실제 화면으로 교체 예정. 일수와 배치 크기는 설명용 가상의 값입니다.

코디네이터는 깨어나 PR·이슈를 읽고 실패한 일을 재배정한다

모형 · 강사 실제 화면으로 교체 예정. 줄 내용은 패턴을 보여 주려고 꾸민 예시입니다.

이렇게 망가지고, 이렇게 막는다

안전장치는 도구가 이미 갖고 있다

code.claude.com/docs/en/scheduled-tasks

공식 문서 화면 캡처 · 2026-10-28 확인

Claude Code 예약 작업 문서의 제약 부분. 반복 작업은 만든 지 7일 뒤 자동으로 사라진다고 안내.

• 반복 작업은 7일 뒤 자동 만료. 더 길면 취소 후 다시 만들거나 클라우드·데스크톱 예약 작업
• /usage에 Loops 표: 루프별 실행 횟수 · 총 토큰 · 회당 토큰
• 세션이 열려 있어야 깨어난다. 백그라운드 세션으로 유지

→ 며칠 가는 일은 만료·세션 제약부터 확인

묶으면: 병렬은 쉽고, 나눠 주고 점검하는 일이 어렵다

1. 모델 가격·성능 차이와 큰 프로젝트가 여러 하네스를 부른다
2. Agent HQ · Codex 앱 · agent teams · Orca · Cursor 3가 같은 방향
3. 코디네이터는 코딩하지 않고 이슈·PR·CI를 읽어 배치를 보낸다
4. 완료 조건 · 만료 · 사용량 점검 없이는 돌리지 않는다

→ 14교시: 코디네이터가 읽을 ‘이슈 원장’과 ADR(Architecture Decision Record, 아키텍처 결정 기록)

cognitect.com/blog/2011/11/15/documenting-architecture-decisions

다음 교시 · ADR 원문 화면 캡처 · 2011-11-15

다음 교시에서 볼 Nygard의 ADR 원문(2011). 큰 문서는 낡는다는 문제의 출발점.

SDD: 스펙이 사람과 AI의 기준이 된다

github.blog/…/spec-driven-development-with-ai

GitHub Blog 화면 캡처 · 2025-09-02

GitHub Spec Kit 발표 글. 스펙을 먼저 쓰는 SDD(Spec-Driven Development, 스펙 주도 개발)를 소개.

martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

원문 화면 캡처 · 2025-10-15

Böckeler의 글. SDD의 정의가 아직 흔들린다고 밝히고 공통점을 정리.

문제 1: 스펙은 길어지고, 길어지면 낡는다

cognitect.com/blog/2011/11/15/documenting-architecture-decisions

원문 화면 캡처 · 2011-11-15

Nygard가 2011년에 쓴 글의 ‘Context’ 부분. 큰 문서는 최신으로 유지되지 않는다고 짚는다.

“Large documents are never kept up to date.”큰 문서는 결코 최신 상태로 유지되지 않는다.Nygard · 2011-11-15

• 스펙이 코드보다 커진 프로젝트가 흔하다고 쓴 글
• 너무 커서 열고, 읽고, 고치지 못한다
• 작은 조각이어야 갱신될 가능성이 있다

문제 2: 에이전트는 낡은 스펙도 믿는다

사람은 “이건 옛날 문서야”라고 의심하지만, 에이전트는 읽은 문서를 기준으로 삼습니다.

문제 3: 병렬로 일하면 한 스펙에서 부딪힌다

워크트리로 코드는 갈라도, 스펙 파일 하나는 모두가 고치려 듭니다. ← 13교시

그래서 스펙 하나를 성격별로 나눴습니다

결정과 이유는 ADR, 이번 작업의 요구는 이슈 단위 스펙, 실제 동작의 기준은 코드와 테스트.

결정과 근거를 남긴다는 생각은 1992년부터, ‘ADR’이라는 이름은 2011년부터

ADR(Architecture Decision Record, 아키텍처 결정 기록) = 결정 하나와 그 근거. 무거운 아키텍처 문서에서 떼어 낸 작은 기록이다.

근거를 남긴다는 목적은 같다. 바뀐 것은 크기, 놓이는 곳, 읽는 쪽이다

Nygard: “Large documents are never kept up to date.” 큰 문서는 결코 최신으로 유지되지 않는다.

ADR: 결정 하나와 그 이유를 적은 기록

adr.github.io

ADR 커뮤니티 사이트 화면 캡처

adr.github.io 첫 화면. ADR을 결정 하나와 그 근거를 적은 문서로 정의한다.

• Architecture Decision Record(아키텍처 결정 기록): 결정 하나와 그 근거
• 선택의 트레이드오프와 결과까지 적는다
• 모아 두면 프로젝트의 결정 로그

Nygard의 ADR 원형은 다섯 칸, 한두 쪽이면 끝난다

cognitect.com/blog/2011/11/15/documenting-architecture-decisions

원문 화면 캡처 · 2011-11-15

Nygard 글에서 Status(상태)와 Consequences(결과) 칸을 설명하는 부분.

1. Title(제목): 짧은 명사구
2. Status(상태): 제안됨 · 승인됨 · 폐기 · 대체됨
3. Context(맥락): 힘겨루기 중인 사실들
4. Decision(결정): “We will …”(우리는 ~한다)
5. Consequences(결과): 좋은 것도 나쁜 것도

다섯 칸, 한두 쪽이면 끝난다. 상태를 바꿔 결정의 역사가 남는다.

대안을 적는 전용 칸이 없다(11장 표). 낡음을 알리는 조건 칸도 없다.

모든 서식의 뼈대. AI 이전인 2011년부터 ‘작은 문서’를 주장했다.

상태가 바뀌어도 기록은 지우지 않는다

낡은 ADR을 고쳐 쓰지 않고 상태만 바꾸고 새 ADR을 추가합니다. 그때 무엇이 결정이었는지가 남습니다.

MADR: 마크다운으로 가볍게 쓰는 ADR

adr.github.io/madr

MADR 공식 사이트 화면 캡처 · 2026-10-28 확인

MADR 공식 사이트 첫 화면. ADR을 마크다운 서식으로 간소화한 템플릿(4.0)을 소개.

• 최소형: 맥락 · 선택지 · 결정 결과(· 결과)
• 전체형: 결정 요인 · 선택지별 장단점 · 확인 방법 추가
• 머리말 status · date · decision-makers

마크다운이라 저장소에 두기 쉽다. 최소형·전체형 중 고르고 선택지를 적는다.

전체형은 칸이 늘어난다. ‘확인’ 칸은 결정이 지켜졌는지 보는 용도라 낡음 신호는 아니다.

Nygard에 선택지 칸이 더해진 형태. 이미 검토한 안을 에이전트가 되풀이하지 않게 한다.

세 서식, 같은 뼈대와 다른 칸

제 서식: 여덟 칸, 둘이 새로 붙었다

예시 ADR (1/2): 배경과 대안

예시 ADR (2/2): 선택, 영향, 다시 판단할 조건

‘다시 판단할 조건’이 낡음을 알려 준다

스펙은 낡았는지 스스로 말하지 못하지만, ADR은 낡을 조건을 미리 적어 둡니다.

왜 에이전트에게 ADR이 좋은가

모든 결정에 쓰지는 않습니다

ADR 초안은 AI가 쓰게 해도 됩니다. 상태와 사용자 판단은 사람이 확정합니다.

이슈 원장: 설계도가 곧 작업 목록

이슈 하나가 작업 하나, 닫을 때마다 한 칸씩 채우는 도장 깨기입니다. 강사 실제 보드 화면으로 교체 예정

프로젝트: 이슈와 PR이 표·보드·로드맵이 된다

docs.github.com/en/issues/planning-and-tracking-with-projects/…/about-projects

GitHub 공식 문서 화면 캡처

GitHub Docs ‘About Projects’ 화면. 프로젝트를 이슈·PR과 연결된 표·보드·로드맵이라고 설명한다.

“…an adaptable table, board, and roadmap…”유연하게 바꿔 쓰는 표, 보드, 로드맵GitHub Docs · About Projects

• 이슈·PR(변경 요청)과 양방향으로 동기화
• 담당자·상태 같은 사용자 지정 필드
• 필터·정렬·그룹으로 여러 보기

이슈 하나 = 작업 하나, 큰 일은 하위 이슈로

docs.github.com/en/issues/…/using-issues/adding-sub-issues

GitHub 공식 문서 화면 캡처

GitHub Docs ‘하위 이슈 추가’ 화면. 이슈 아래 하위 이슈를 100개, 8단계까지 둘 수 있다고 설명한다.

• 하위 이슈: 상위 이슈 하나에 최대 100개, 중첩은 8단계까지
• 마일스톤 → 스테이지 → 스프린트 → Task를 추적 이슈로
• 완료 조건과 검증 방법이 이슈에 있다

PR 폭증은 이슈를 합쳐 줄인다

기준은 개수가 아니라 하나의 검토·출시·롤백 단위인가입니다. 번호는 가상입니다. → 15교시

이슈를 닫는 규칙: 키워드는 이슈마다 하나씩

docs.github.com/en/issues/…/linking-a-pull-request-to-an-issue

GitHub 공식 문서 화면 캡처

GitHub Docs ‘PR을 이슈에 연결’ 화면. PR이 기본 브랜치에 머지되면 연결된 이슈가 자동으로 닫힌다.

# PR 본문 Closes #201 Closes #203 Related: #204

• 기본 브랜치로 머지될 때만 자동 종료
• Related는 닫지 않는다

운영 기준 18단계: ADR은 7단계

방향 문서(개요·가이드라인·ADR·Spec 개요)를 먼저 세우고 → 쪼개서 이슈로 등록하고 → 이슈별로 만듭니다. → 16교시

이슈 하나가 지나가는 열두 칸

스펙·계획·구현은 각각 리뷰하고, 블로커가 있으면 그 단계로 되돌아갑니다. CI(Continuous Integration, 지속적 통합) 실패는 구현으로 돌아갑니다.

묶으면: 짧은 결정 기록과 한 장씩 닫는 이슈

docs.github.com/…/managing-a-merge-queue

다음 교시 · 15교시에서 볼 화면

GitHub 머지 큐 문서. 15교시에서 PR이 폭증할 때 합치는 문제를 다루며 다시 봅니다.

• 큰 스펙은 길어지고, 낡고, 병렬에서 부딪힌다
• ADR: 결정 하나, 이유, 다시 판단할 조건
• 이슈 하나 = 작업 하나, 도장 깨기, 묶기는 신중히

→ 15교시: PR이 늘면 CI가 폭증합니다. 머지 큐와 스모크 테스트

PR이 늘면, 병목은 CI와 검증으로 옮겨 간다

14교시에서 일을 이슈 단위로 쪼갰습니다. 이제 그 결과물(PR(Pull Request, 변경 병합 요청))이 쏟아져 CI(Continuous Integration, 지속적 통합 자동 검사)에 쌓이는 곳을 봅니다. → 14교시

단가는 내렸다: 호스티드 러너 최대 39% 인하

github.blog/changelog/2025-12-16-coming-soon-simpler-pricing-and-a-better-experience-for-github-actions

GitHub 변경 로그 화면 캡처 · 2025-12-16 발표

GitHub 공식 변경 로그. 2026-01-01부터 호스티드 러너(GitHub이 빌려주는 실행 서버) 가격을 최대 39% 내린다는 발표.

−39%

GitHub 호스티드 러너 가격
기존 대비 최대 인하폭, 2026-01-01 적용

셀프호스티드 러너 과금 변경은
발표 후 보류됨

터진 것은 실행량이다: 한 달 32.6억 회, 1년 전의 4배

github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development

GitHub Blog 화면 캡처 · 2026-10-06 (10-26 갱신)

GitHub Blog 본문. Actions(자동 실행 기능)가 2026년 9월 한 달에 32.6억 번 돌았고 1년 전의 4배를 넘는다는 문장.

4배+

Actions 실행 횟수, 2025-09 대비
(2026-09 한 달, 32.6억 회)

5배+

커밋 수, 2025-09 대비
(2026-09 한 달 73.8억 건, 사람+에이전트)

하루 머지 30,401건: Anthropic은 소스 관리를 새로 만들었다

anthropic.com/engineering/redesigning-source-control

Anthropic Engineering 차트 · 2026-01~09

Anthropic 모노레포(코드를 한 저장소에 모은 것)의 하루 머지(변경 합치기) 수 차트. 여름 이후 급증해 9월 9일 30,401건.

하루 머지 약 2,500건 → 30,401건(5월→9월 9일)에 맞춰 git 대신 자체 소스 관리 Scion을 새로 만들었다.

인프라를 직접 새로 만든 사례다. 대부분의 프로젝트는 이 규모가 아니어서 그대로 따라 할 수는 없다.

에이전트가 늘면 PR·머지·CI가 사람 속도가 아닌 기계 속도로 는다. 방향은 우리 프로젝트도 같다.

단가는 못 건드리니, 횟수와 시간을 줄인다

오른쪽으로 갈수록 효과가 크지만 설정과 위험도 큽니다. 왼쪽부터 하나씩 켭니다.

1. 낡은 실행은 취소한다: concurrency

docs.github.com/…/control-workflow-concurrency

GitHub Docs 화면 캡처

GitHub Docs 동시 실행 제어 문서. 같은 그룹의 실행이 겹칠 때 이전 실행을 취소하는 concurrency 설정을 다룬다.

# .github/workflows/ci.yml concurrency: group: ci-${{ github.workflow }}- ${{ github.event.pull_request.number || github.sha }} cancel-in-progress: ${{ github.event_name == 'pull_request' }} ✓ 같은 PR에 새 푸시 → 이전 실행 취소 ! 큐 후보(merge_group)는 취소 안 함 후보마다 sha가 달라 서로 끊지 않는다

2. 관계없는 변경은 거른다: 경로 필터

docs.github.com/…/workflow-syntax

GitHub Docs 화면 캡처 · paths / paths-ignore

GitHub Docs 워크플로 구문 문서. 목차에 paths(특정 경로가 바뀔 때만 실행) 항목이 보인다.

# 문서만 바뀐 PR은 테스트를 건너뛴다 on: pull_request: paths-ignore: - 'docs/**' - '**.md' ! 필수 검사 워크플로 전체를 paths로 생략하면 상태가 안 올라와 PR·머지 큐가 기다릴 수 있다 → 워크플로는 항상 실행하고, 안에서 작업만 고른다

3. 받은 것은 다시 받지 않는다: 캐시

docs.github.com/…/dependency-caching

GitHub Docs 화면 캡처

GitHub Docs 캐시 문서. 호스티드 러너는 매번 깨끗한 이미지에서 시작해 의존성을 다시 받으므로, 캐시로 재사용한다.

# PHP · Laravel 예: composer 캐시 - uses: actions/cache@v4 with: path: ~/.composer/cache key: composer-${{ hashFiles('composer.lock') }} - run: composer install ✓ lock 파일이 같으면 다운로드 생략 ! 캐시는 재사용일 뿐, 검사 생략이 아님 ! 비밀정보는 캐시하지 않는다

폴더 필터를 넘어: 영향받는 검사만 고른다

기본 규칙은 변경 영역 + 전이적 소비자(그 영역을 가져다 쓰는 곳) + 경계 계약 검사. 확실하지 않으면 전체 검사로 돌아갑니다.

4. 묶어서 검증한다: 머지 큐

docs.github.com/…/managing-a-merge-queue

GitHub Docs 화면 캡처

GitHub Docs 머지 큐 문서. 머지 큐는 PR 머지를 줄 세우고, 합친 상태로 먼저 검사하는 기능.

합친 상태로 먼저 검사해 main이 깨지는 일을 머지 전에 막고, 브랜치를 매번 최신으로 맞추지 않아도 된다.

실패가 잦거나 러너가 부족하면 대기가 오히려 늘고, 충돌 해결·검토는 대신하지 않는다. 제공 범위도 제한된다.

PR이 몰려도 기본 브랜치를 항상 초록으로 지키는 4단계 최종 수단. 앞 단계를 켠 뒤에 쓴다.

큐는 ‘누적 후보’를 만들어 검사한다

PR 하나의 성공은 후보의 성공이 아닙니다. 실패한 PR이 빠지면 뒤 후보는 다시 검사합니다.

큐를 쓰려면 merge_group도 받아야 한다

GitLab에서는 머지 큐를 ‘머지 트레인’이라 부른다

docs.gitlab.com/ci/pipelines/merge_trains

GitLab Docs 화면 캡처

GitLab Docs 문서. MR(Merge Request, 머지 요청)을 줄 세워 앞선 MR과 합친 상태로 검사한다는 설명.

앞선 MR을 모두 합친 상태로 검사해, 같은 시간에 머지되는 MR끼리의 충돌을 대상 브랜치 전에 잡는다.

Premium·Ultimate 등급 기능이다. 머지 결과 파이프라인은 다른 MR을 고려하지 못한다.

이름만 다르고 핵심은 같은 누적 후보. GitHub이든 GitLab이든 같은 설계로 생각하면 된다.

병렬화는 기다림을, 범위 축소는 러너·분을 줄인다

가정: 후보 A·B·C 모두 성공, 대기 없음. 러너·분 = 검사 서버를 쓴 시간의 합(청구 단위). B가 실패하면 C를 다시 검사하는 시간이 더해집니다.

테스트가 틀리면, 통과는 아무것도 증명하지 못한다

에이전트가 테스트와 구현을 둘 다 쓰면, 서로 맞춘 채 틀릴 수 있습니다. 결국 직접 눌러 봐야 확정되는데, 이것이 스모크 테스트(앱이 켜지고 핵심 기능이 도는지 훑는 검사)입니다. → 6교시 · TDD(Test-Driven Development, 테스트 주도 개발)

AI가 사람처럼 화면을 보고 눌러 볼 수 있게 됐다: computer use

anthropic.com/news/3-5-models-and-computer-use

Anthropic 발표문 화면 캡처 · 2024-10-22

Anthropic의 2024-10-22 발표문. Claude가 화면을 보고 커서로 클릭·입력하는 computer use를 공개 베타로 낸다는 내용.

“…by looking at a screen, moving a cursor, clicking buttons, and typing text.”화면을 보고, 커서를 움직이고, 버튼을 누르고, 글자를 입력해서.Anthropic · 2024-10-22

웹뿐 아니라 어떤 화면이든(데스크톱 앱 포함) 사람처럼 보고 누를 수 있다.

공개 때 “실험적이고 오류가 잦다”고 밝혔다. 화면 이미지로 판단해 웹 앱에는 덜 정확하고 무겁다.

브라우저 밖 앱을 확인할 때의 선택지. 웹 앱은 뒤의 브라우저 전용 도구가 낫다.

브라우저 자동화(접근성 스냅샷)의 대표 도구, Playwright MCP

playwright.dev/mcp/introduction

Playwright 공식 문서 화면 캡처

Playwright MCP 소개 문서. 브라우저를 접근성 스냅샷(화면 요소 목록)으로 조작해 비전 모델이 필요 없다는 설명.

화면 이미지 대신 요소 목록을 읽어 결과가 안정적이고 토큰이 적다. 비전 모델이 필요 없다.

브라우저 안의 웹 앱만 대상이다. 콘솔 오류·네트워크 증거는 DevTools MCP를 더한다.

웹 앱 스모크의 기본 도구: 로그인·입력·이동 같은 흐름 확인에 쓴다.

콘솔과 네트워크를 직접 읽게 하는 도구, Chrome DevTools MCP

developer.chrome.com/blog/chrome-devtools-mcp

Chrome for Developers 화면 캡처 · 2025-09-23

Chrome 팀의 DevTools MCP 발표 글. 에이전트가 콘솔 오류·네트워크·성능을 직접 보게 하는 도구의 공개 프리뷰 소개.

“…effectively programming with a blindfold on.”사실상 눈을 가리고 프로그래밍하는 셈이다.Chrome for Developers · 2025-09-23

콘솔 오류·네트워크 요청·성능을 직접 읽어, 화면이 멀쩡해도 숨은 실패를 잡는다.

화면 흐름을 조작하는 도구라기보다 디버깅 도구다. 2025-09 공개 프리뷰로 시작했다.

스모크에서의 가치는 증거. Playwright로 흐름을 돌리고 DevTools로 증거를 모은다.

내 로그인 상태 그대로 눌러 보는 확장, Claude in Chrome

code.claude.com/docs/en/chrome

Claude Code 공식 문서 화면 캡처 · 2026-10-28 확인

Claude Code 문서의 Chrome 연동 페이지. 확장으로 웹 앱을 테스트하고 콘솔 로그로 디버깅하며 로그인 상태를 공유한다.

내 로그인 상태 그대로 눌러 봐서, 관리자 화면처럼 로그인이 필요한 곳도 확인한다.

로그인 공유는 편리한 만큼 위험하다. 로그인·CAPTCHA(Completely Automated Public Turing test to tell Computers and Humans Apart, 사람 확인 퀴즈)를 만나면 멈추고 사람에게 넘긴다.

스모크에는 테스트 계정과 개발 환경만 쓴다. 내 실제 계정으로는 돌리지 않는다.

무엇을 확인하느냐로 도구를 고른다

정답은 하나가 아닙니다. 웹 앱이면 Playwright MCP로 흐름, DevTools MCP로 증거가 무난한 조합입니다.

시나리오 한 개는 다섯 칸이면 된다

핵심 흐름 3~5개만. 로그인, 핵심 기능 한 번, 저장 후 다시 열기 정도가 적당합니다.

시나리오는 저장소 안의 마크다운 파일이다

playwright.dev/mcp/introduction

Playwright 공식 문서 화면 캡처 · 실행 방법

Playwright MCP 문서의 시작 방법 화면. 오른쪽 시나리오 파일을 이 도구로 실행한다.

# smoke/login.md 목적: 로그인하면 대시보드에 닿는다 전제: http://localhost:8000 계정 [email protected] (시드) 단계 1. /login 을 연다 2. 이메일·비밀번호 입력, [로그인] 3. 대시보드 제목을 확인 판정 - 주소가 /dashboard - "내 현황" 제목이 보인다 - 콘솔 error 0건 - 실패한 요청(4xx·5xx) 0건 증거: 단계마다 스크린샷

“통과했습니다”가 아니라 증거 파일을 남긴다

규칙: 증거 없는 PASS는 FAIL. 에이전트에게 파일 이름 규칙까지 시키고, PR에 보고서를 붙입니다.

CI는 줄이고, 초록불은 직접 확인한다

스모크가 통과해도 남는 질문: 쓸 만한가

developer.chrome.com/blog/chrome-devtools-mcp

Chrome for Developers 화면 캡처 · 15교시에서 본 화면

15교시에서 본 Chrome DevTools MCP 발표 글. 에이전트가 브라우저에서 콘솔 오류·요청 실패를 직접 읽는 스모크용 도구.

• 스모크는 동작하는지를 본다: 열리고, 눌리고, 오류가 없는가
• 버튼이 있어도 그 사람이 찾을 수 있는지는 모른다
• 다음 장치: 특정 고객이 되어 눌러보게 한다

→ 15교시 이어서

페르소나 평가: 고객이 되어 눌러보고, 고친다

사람 대신 에이전트가 고객 한 명(페르소나: 고객을 글로 적은 프로필)을 연기하며 앱을 씁니다. 막힌 곳은 이슈가 되고, 고친 뒤 같은 사람으로 다시 평가합니다.

LLM 가상 사용자 시뮬레이션의 연구 사례, UXAgent: 사용성 시험을 미리 돌려 본다

arxiv.org/abs/2502.12561

arXiv 화면 캡처 · 논문 초록

UXAgent 논문 초록. LLM 에이전트가 수천 명의 가상 사용자처럼 웹사이트를 쓰게 해 사용성 시험을 돕는다는 내용.

참가자를 모으기 전에 수천 명의 가상 사용자로 시험해 연구 설계를 점검한다. 생각·행동·영상이 남는다.

가상 사용자일 뿐이라 실제 사람 실험을 대신하지 못한다. 논문도 사람 연구 이전 단계로 제안한다.

우리 과정에서는 페르소나 평가의 근거 ①: 사람에게 가기 전 막힌 곳을 싸게 찾는다.

LLM 페르소나 시뮬레이션 라이브러리, TinyTroupe: 성격과 목표를 준 가상 인물

arxiv.org/abs/2507.09788

arXiv 화면 캡처 · 2025-07-13 제출 · 2026-06-09 v3

TinyTroupe 논문의 arXiv 화면. Microsoft의 가상 인물 시뮬레이션 Python 라이브러리를 다룬 논문.

성격·관심사·목표를 가진 가상 인물을 만들어 대화·행동시킨다. 광고 평가·포커스 그룹 등에 쓴다.

Microsoft의 실험적 라이브러리다. README는 결과를 “통찰용”으로만 쓰고 직접 의사결정에는 쓰지 말라고 한다.

그대로 쓰지 않아도, 페르소나를 상세히 정의해 주입한다는 발상을 가져온다. ②번 근거.

가상 사용자는 사전 점검이다, 최종 판정이 아니다

TinyTroupe README: 결과는 “insight generation”(통찰을 얻기)용이고 직접 의사결정용이 아닙니다. UXAgent도 실제 참가자 연구 이전 단계로 제안합니다.

페르소나는 지어내지 않고, 실제 고객에서 뽑는다

문의·불만·인터뷰에서 반복되는 사람 유형을 한 명씩 적습니다. 이름·연락처 같은 식별 정보는 지웁니다.

페르소나 파일: 목표와 포기 조건까지 적는다

실행: 과업은 한 줄, 증거는 파일로

관찰 항목: 판정보다 증거 한 줄

항목마다 수월·헤맴·막힘 중 하나. 각 칸에는 스크린샷 번호나 기록 줄을 붙입니다. 증거 없는 판정은 이슈로 만들지 않습니다.

피드백은 이슈로: 재현 경로와 증거를 붙인다

자기 개선 루프: 평가가 다음 배치를 만든다

제 서비스에서 돌리는 모습

역공학(리버스 엔지니어링) MCP의 예, REA: 소스 없이 앱의 동작을 조사한다

github.com/morluto/rea

GitHub 저장소 화면 캡처 · 2026-10-29

REA GitHub 저장소 첫 화면. 제목은 “에이전트로 무엇이든 역공학”(Reverse engineer anything with agents).

“One MCP for reverse engineering across binaries, applications, and runtime behavior.”바이너리·애플리케이션·실행 중 동작을 아우르는, 역공학(완성품을 뜯어 원리 파악)용 MCP 하나.REA README

소스 없이 앱·바이너리·웹사이트가 어떻게 동작하는지 조사하고, 근거와 한계를 함께 돌려준다. 분석은 로컬에서 한다.

대상에 따라 Hopper·Ghidra·IDA 등 별도 분석 도구가 필요하다. 허가받은 소프트웨어에만 쓴다.

에이전트 도구가 내 앱 테스트를 넘어 남의 앱 조사로 넓어지는 최근 동향의 예.

REA 쓰는 법: 에이전트에게 묻고, 근거를 받는다

github.com/morluto/rea · How REA works 그림

README 그림 화면 · 질문 → 조사·추적 → 근거 → 활용, 추가 질문으로 반복

REA README의 ‘How REA works’ 그림. 질문 → 조사·추적 → 근거 읽기 → 에이전트 활용, 추가 질문으로 반복.

# 설치는 각자. 붙인 뒤에는 평소처럼 묻는다 에이전트에게 Understand how search works in the Notes app, show me the evidence, and build a similar feature for my project. 번역 Notes 앱의 검색이 어떻게 동작하는지 설명하고, 근거를 보여 주고, 내 프로젝트에 비슷한 기능을 만들어 줘. ! 대상에 따라 Hopper · Ghidra · IDA, Node.js, Chrome 계열 브라우저 등 필요

REA는 앱 안을 넓게 들여다보되, 허가받은 소프트웨어에만 쓴다

github.com/morluto/rea · 네이티브 분석 예시

README 이미지 · Hopper 안에서 네이티브 바이너리 분석

Hopper(바이너리 분석 앱) 안에서 분석을 돌리는 화면. 분석 대상은 /usr/bin/true.

rea.tools/guides/rl-environments

가이드 화면 캡처 · 녹화한 웹앱 세션을 에이전트용 환경으로

REA 가이드 ‘RL 환경 만들기’. 녹화한 웹앱 세션을 AI 에이전트 훈련·시험용 환경으로 바꾼다(RL: 강화학습).

이슈 하나를 PR에서 스모크까지 보내고, 결과는 코드 대신 스모크로 확인한다

저는 코드를 읽지 않습니다. 하네스에게 시키고, 돌려서 확인합니다. 사람이 보는 것은 내 답, 정리된 결정, 스모크 결과 세 가지입니다. 이것은 제 방식이고, 내 하네스에 맞게 바꿔도 됩니다.

하네스는 PR 전에 여섯 가지를 하나씩 묻는다

첫 프롬프트로 질문부터 시키고, 다섯 가지를 보고 승인한다

PR과 CI는 만들게 시키고, 결과 요약을 보여 달라고 한다

머지하고 나면, 합쳐진 앱을 눌러 보고 표로 남긴다

이슈 하나를 실제로 보내 보고, 규칙을 일부러 어겨 본다

머지한 앱에 페르소나 평가를 돌리고, 피드백을 이슈로 남긴다

피드백은 다음 계획이 되고, 새 이슈로 처음부터 이어진다

내 하네스를 한 번 더 키운다: 무엇을 하는 하네스인지는 내가 정한다

고를 수 있는 장치 여섯 가지: 필요한 것만 골라 하네스에게 시킨다

다음 회차까지 해 볼 것과, 그때 나누면 좋은 것

코드는 읽지 않아도 됩니다. 다 못 해도, 못 쟀어도 괜찮습니다. 있는 만큼 가져와 이야기로 나눕니다.

자유롭게 나누고 이야기합니다: 돌릴 때마다 한 줄 남겨 두면 이야깃거리가 됩니다

토큰은 도구의 사용량 화면이나 API(Application Programming Interface, 프로그램 연동 규약) 응답의 usage에서 읽습니다. 실패한 회차도 지우지 않습니다.

막힐 때: 하네스에게 이렇게 다시 말한다