어떤 순서로 얼마나 쪼갤 것인가: 워크플로우 제어의 세 축

200개의 빨간불

Anthropic 엔지니어가 웹 앱 하나를 만들기 위해 처음 한 일은 코드를 쓰는 게 아니었다. 200개 이상의 피처를 정의하고, 각각에 실패하는 테스트를 붙였다. 화면은 빨간불 200개로 가득 찼다. 그리고 하나를 골라 초록불로 바꾸고, 다음 하나를 골라 초록불로 바꾸고, 반복했다. Initializer Agent 패턴이다.

"에이전트한테 앱 만들어줘"라는 한 줄짜리 지시와 뭐가 다른가. 결국 같은 앱이 나오는 것 같지만, 작업의 형태가 전혀 다르다. 한 줄짜리 지시는 큰 덩어리를 한 번에 삼키라는 요구다. 200개 빨간불은 작은 조각을 하나씩 소화하라는 설계다. 이 차이가 워크플로우 제어의 본질이다.

작업을 어떻게 쪼개고, 누구에게 맡기고, 컨텍스트가 넘칠 때 어떻게 관리하는가. 이 세 문제가 워크플로우 제어의 핵심이다.

1. 수직 분해

"빠져 있는 것"을 묻는다

작업을 쪼개는 보통의 접근은 "무엇을 만들 것인가"로 시작한다. 로그인 기능, 대시보드, 알림 시스템. OpenAI의 하니스 엔지니어링 가이드는 질문을 뒤집었다. "무엇이 빠져 있는가?"

"빌드하려는 것"을 묻는 접근은 에이전트에게 넓은 해석 여지를 준다. "로그인 기능을 만들어"라고 하면 에이전트는 자기 나름대로 만든다. 기대와 맞을 수도 있고 아닐 수도 있다. 반면 "빠져 있는 것"을 나열하면 이야기가 달라진다. 이메일 입력 필드가 없다. 비밀번호 검증 로직이 없다. 세션 토큰 발급이 없다. 빠진 조각 하나가 곧 검증 가능한 작업 단위가 된다.

OpenAI는 이걸 "Contract-First 분해"라고 부른다. 각 작업 단위에 "완료했다"는 증거 조건이 미리 붙어 있다. 유닛 테스트가 대표적이다. 테스트가 통과하면 계약 이행, 실패하면 미이행. 모호함이 낄 틈이 없다.

Google DeepMind도 비슷한 맥락에서 "transitive accountability(이행적 책임)"라는 개념을 제안했다. 에이전트 A가 B에게 작업을 위임하면 A가 B의 결과를 검증한다. B가 C에게 다시 위임하면 B가 C를 검증한다. 위임 체인 전체에서 검증 구조가 이행적으로 유지된다. 이 구조가 작동하려면 각 단위의 출력이 검증 가능해야 하니, 결국 Contract-First와 같은 원리다.

구체적일수록 정확하다

Contract-First의 실천은 TODO 리스트의 품질에서 드러난다.

나쁜 예: "대시보드 전체 구축."

좋은 예: "내비게이션 바에 Home, About, Contact 링크 추가. 현재 페이지는 파란색 하이라이트. 수용 기준: 각 링크 클릭 시 해당 페이지로 이동, 현재 페이지 링크에 active 클래스 적용."

나쁜 예는 에이전트에게 해석을 떠넘긴다. 좋은 예는 해석의 여지를 제거한다. 무엇을 만들고 어떤 조건이면 완료인지가 명시되어 있으니 에이전트가 판단할 영역이 줄고, 실수 가능 범위도 줄어든다. Anthropic의 Initializer Agent가 200개 피처에 각각 failing test를 붙인 것도 같은 원리다. 테스트가 수용 기준이다.

이 규모가 가능한 이유

원리를 넘어 실전 규모를 보자. Stripe의 Minions는 주당 1,000건 이상의 PR을 머지한다. 개발자가 Slack에 태스크를 올리면 에이전트가 코드를 작성하고 CI를 통과시키고 리뷰 준비된 PR을 연다. Peter Steinberger는 OpenClaw 프로젝트에서 한 달간 6,600건 이상의 커밋을 기록했다. 5개에서 10개 에이전트를 동시에 운영하면서 본인은 아키텍처 게이트키퍼 역할에 집중했다.

이 숫자가 가능한 건 단순하다. PR 하나가 "대시보드 전체 구축"이면 1,000건을 리뷰할 수 없다. PR 하나가 "내비게이션 바에 링크 3개 추가"이면 리뷰가 분 단위로 끝난다. CI 통과 여부와 수용 기준 충족만 확인하면 된다.

OpenAI 내부에서도 3명의 엔지니어가 5개월간 100만 줄 규모의 제품을 구축했는데, 사람이 직접 쓴 코드는 0줄이었다. 엔지니어당 하루 평균 3.5건의 PR을 처리했다. 이들이 한 일은 코드를 작성하는 게 아니라 코드가 올바른지 검증하는 것이었다.

2. 수평 배치

계획하는 뇌와 실행하는 손

수직 분해가 "얼마나 깊이 쪼갤 것인가"의 문제라면, 수평 배치는 "쪼갠 조각을 누가 실행하는가"의 문제다.

가장 널리 쓰이는 패턴이 Planner/Worker/Judge 삼자 구조다.

Planner(계획자): 고수준 목표를 순차적 서브태스크로 분해한다. "결제 시스템을 만들어라"를 받으면 "1. 결제 API 스키마 설계 → 2. 카드 검증 로직 → 3. 트랜잭션 로깅 → 4. 통합 테스트 작성"처럼 JSON 형태의 계획을 출력한다. 전략을 세울 뿐 코드는 쓰지 않는다.

Worker(실행자): 계획에 따라 각 태스크를 처리한다. 웹 내비게이션 전문, 데이터 분석 전문, 파일 작업 전문처럼 도메인별로 전문화할 수 있고, 각자의 컨텍스트 윈도우에서 독립 실행된다.

Judge(검증자): 워커의 출력을 검증한다. 점수가 기준(예: 0.8) 이상이면 통과, 미만이면 플래너에게 재분해를 요청한다. 보안 취약점 검토나 사실 확인 같은 특화 검증도 여기서 일어난다.

이 구조의 핵심은 역할 분리가 곧 컨텍스트 분리라는 점이다. 플래너는 전체 구조만, 워커는 맡은 태스크의 세부만, 저지는 검증 기준만 들고 있다. 하나의 에이전트가 전부 하면 컨텍스트 윈도우가 금방 넘친다. 역할을 나누면 각자가 필요한 정보만으로 움직인다.

2026년에 발표된 AgentOrchestra가 이 구조의 진화된 형태를 보여준다. 중앙 플래너가 전문 서브에이전트를 조율하는데, 실행 중에 도구를 동적으로 생성하고 개선하는 "continual adaptation"이 추가되었다. GAIA 벤치마크에서 89.04%(SOTA)를 기록했고, 멀티에이전트 아키텍처가 단일 Claude Opus 대비 90.2% 성능 향상을 보였다.

병렬화의 두 모드, 그리고 세 가지 실패

쪼갠 조각을 한 줄로 세워 순서대로 처리하는 것만이 방법은 아니다. 동시에 여러 조각을 돌리면 속도가 올라간다.

Attended(관리형): 사람이 3~4개 에이전트 세션을 열어두고 필요에 따라 방향을 조정한다. Peter Steinberger의 OpenClaw 작업 방식이 이에 해당한다.

Unattended(무인형): 태스크를 올리고 자리를 비운다. 에이전트가 CI 파이프라인을 통해 빌드, 테스트, PR 생성까지 자율 처리한다. Stripe Minions가 대표적이다. 정교한 환경 인프라(샌드박스, CI/CD, 권한 관리)가 전제 조건이다.

병렬로 돌리면 속도는 빨라지지만 단일 에이전트에서는 나타나지 않는 실패가 생긴다.

Miscoordination(조율 실패): 에이전트 A가 파일 X를 이 구조로, B가 같은 파일을 다른 구조로 만든다. 중복과 모순이 시스템 일관성을 깨뜨린다.

Conflict(충돌): A와 B가 같은 자원을 동시에 변경하려 한다. 한쪽의 작업이 다른 쪽을 덮어쓴다.

Collusion(공모): 여러 에이전트가 피드백 루프를 통해 서로의 오류를 강화한다. A의 잘못된 출력을 B가 "맞다"고 검증하고, B의 판단을 A가 참조하면서 집단 맹점이 형성된다.

세 번째가 특히 까다롭다. 조율 실패와 충돌은 버전 관리와 락(lock) 같은 전통적 기법으로 완화할 수 있지만, 공모는 에이전트 간 피드백 루프 자체에 내재된 문제라 구조적 해법이 필요하다.

결정 엔진과 실행 레이어의 분리

Planner/Worker/Judge가 에이전트 사이의 역할 분리라면, 한 단계 넓게 보면 "에이전트 전체"와 "실행 환경" 사이의 분리가 있다. SpiralScout의 프로덕션 아키텍처 가이드가 이걸 한 문장으로 정리한다. "에이전트는 결정 엔진이다. 실행자가 아니다."

에이전트가 "이 파일을 삭제하겠다"고 결정하면 그대로 실행되지 않는다. 오케스트레이션 레이어가 가로채서 권한, allowlist, 영향 범위를 검증한다. 통과해야 비로소 실행된다. allowlist에 없는 도구를 호출하면 [BLOCKED by harness]라는 메시지가 대화 이력에 삽입되고, 에이전트는 차단 이유를 읽고 다른 접근을 시도한다. 단순한 에러("뭔가 잘못됐다") 대신 구조화된 차단 메시지("이 도구는 쓸 수 없다, 이유는 X다")를 주면 에이전트가 시행착오 대신 정보에 기반해 적응한다.

Phil Schmid의 표현이 이 설계를 압축한다. "LLM은 교체 가능한 부품이다. 비즈니스 로직은 당신이 소유한다." 확률적 모델 위에 결정론적 시스템을 보장하는 것이 오케스트레이션의 본질이다.

승인 피로를 넘어서: 액션 티어링

수십 개 서브에이전트가 병렬로 돌아가면 시간당 수천 건의 마이크로 결정이 쏟아진다. 전부 사람 승인을 거치면 "prompt fatigue(승인 피로)"가 발생한다. 승인이 고무 도장이 되고, 위험한 결정이 무의식적으로 통과된다.

해법은 액션 티어링(Action Tiering)이다. 모든 행동을 동등하게 취급하지 않고 세 단계로 나눈다.

거버넌스 에너지를 Step-up 티어에 집중시키면 승인 피로 없이 위험 관리가 된다. 여기에 Confidence-Adaptive Escalation이 결합된다. 행동 유형이 아니라 리스크 요소(모델 신뢰도 하락, 오케스트레이터와 서브에이전트 출력 불일치, 영향 범위 초과)에 기반해 사람 개입 여부를 결정하는 기법이다.

Anthropic의 실측 데이터가 이 전략의 실전 양상을 보여준다. Claude Code를 750회 이상 사용한 사용자의 40% 이상이 auto-approve 모드를 쓴다. 동시에 개입률도 5%에서 9%로 올랐다. "모든 행동을 사전 승인"에서 "자율을 부여하되 필요할 때 더 적극적으로 개입"으로의 전환이다. 사람이 루프 위에 있되, 루프 안에서 모든 행동을 일일이 승인하지는 않는 Human-on-the-Loop 모델이다.

3. 시간 관리

컨텍스트가 넘칠 때

작업을 잘 쪼갰고, 역할을 잘 분배했다. 그런데 에이전트가 50번째 도구 호출을 하면서 3번째 호출의 결과를 잊어버렸다면? 컨텍스트 윈도우라는 작업 기억에는 한계가 있다. 시간 관리는 이 한계를 어떻게 다루느냐의 문제다.

교대 근무의 인수인계 문서

Anthropic이 장기 실행 에이전트를 운영하면서 발견한 패턴은 기술적 혁신이 아니라 인간의 오래된 관행이었다. 병원 교대 근무에서 환자 차트를 넘기듯, 에이전트도 세션 사이에 문서를 남긴다.

첫 세션에서 Initializer Agent가 개발 환경을 구동하고, 완료된 작업을 claude-progress.txt에 기록하고, 초기 Git 커밋으로 베이스라인을 수립한다. 후속 세션에서 Coding Agent가 의도적인 오리엔테이션을 거친다. 작업 디렉토리를 확인하고, Git 로그와 진행 파일을 읽고, 피처 리스트에서 최우선순위 미완료 항목을 선택한다.

핵심은 "기억 영속성"이라는 문제를 기술적으로 풀지 않았다는 점이다. 컨텍스트 윈도우를 무한히 늘리거나 메모리 모듈을 따로 구축하는 대신, 파일시스템에 텍스트를 쓰고 읽는 방법을 택했다.

이 접근이 단순해 보여도 효과는 측정 가능하다. Anthropic 데이터에 따르면 Claude Code의 99.9번째 백분위수 세션 지속시간이 2025년 10월 25분 미만에서 2026년 1월 45분 이상으로 두 배 가까이 늘었다. 에이전트가 컨텍스트를 더 오래 유지하면서 복잡한 작업을 이어갈 수 있게 된 것이다.

Manus가 KV 캐시에 집착하는 이유

Manus(AI 에이전트 스타트업)가 공개한 컨텍스트 관리 원칙(Reduce, Offload, Isolate) 밑에 깔린 구현 세부가 흥미롭다.

KV 캐시 최적화: Claude Sonnet 기준으로 캐시된 토큰은 백만 개당 $0.30, 캐시되지 않은 토큰은 $3다. 10배 차이다. 이 차이를 활용하려면 프롬프트의 앞부분이 요청마다 동일해야 한다. Manus는 세 가지를 금지했다. 시스템 프롬프트에 타임스탬프 같은 변동 요소를 넣는 것, 이전 대화의 행동이나 관찰을 수정하는 것, JSON 키 순서가 요청마다 달라지는 것. 안정적 접두사, append-only 컨텍스트, 결정론적 직렬화라는 세 규칙이다.

Todo List Recitation: 에이전트가 todo.md를 단계별로 업데이트하게 한다. 단순한 진행 추적이 아니다. LLM에는 "lost-in-the-middle" 문제가 있다. 컨텍스트의 맨 앞과 맨 뒤 정보는 잘 기억하지만 중간은 무시하는 경향이다. 50회 이상 도구 호출이 이어지면 초기 목표가 중간에 묻힌다. todo.md를 주기적으로 갱신하면 목표가 컨텍스트의 최근 위치로 다시 올라온다. 목표를 모델의 최근 주의 범위에 반복적으로 밀어넣는 메커니즘인 셈이다.

에러 보존: 실패한 행동과 스택 트레이스를 컨텍스트에서 지우지 않고 유지한다. 직관적으로는 실패 기록을 지워서 컨텍스트를 아끼는 게 효율적으로 보인다. Manus는 반대로 했다. 모델이 이전 실패를 보면 내부 신념을 암묵적으로 업데이트하여 유사한 실수를 회피한다는 관찰에 기반한 결정이다.

Action Space 관리: 상황에 따라 도구 목록을 바꾸고 싶지만, 도구 정의를 바꾸면 KV 캐시가 깨진다(도구 정의는 시스템 프롬프트의 일부이므로). Manus의 해법은 도구 정의를 항상 동일하게 유지하되, "state-aware logit masking"으로 디코딩 단계에서 특정 도구의 선택 확률을 0으로 만드는 것이다. 캐시를 보존하면서도 행동 범위를 조절하는 절충안이다.

Deep Agents의 3단계 압축

LangChain이 장기 실행 에이전트 "Deep Agents"를 개발하면서 다른 각도의 접근을 공개했다. Manus가 "캐시를 깨지 마라"에 집중했다면, Deep Agents는 "컨텍스트가 가득 차면 어떻게 비우느냐"에 집중했다.

1단계: 대형 도구 결과 오프로딩. 도구 응답이 20,000 토큰을 초과하면 전체를 파일시스템에 기록하고, 에이전트는 파일 경로 참조와 10줄짜리 미리보기만 받는다.

2단계: 오래된 도구 호출 제거. 컨텍스트가 전체 용량의 85%에 도달하면 오래된 도구 호출을 잘라내고 디스크 포인터로 대체한다. "30분 전 검색 결과의 전체 텍스트"가 "30분 전 검색 결과: /tmp/search-result-031.txt 참조"로 바뀐다.

3단계: 인컨텍스트 요약. 1, 2단계로도 부족할 때 비로소 요약이 적용된다. 세션 의도, 생성된 아티팩트, 다음 단계를 캡처하는 구조화된 요약을 만들고 원본은 디스크에 보존한다.

Manus와 Deep Agents의 접근이 다르지만 공유하는 원칙이 있다. 둘 다 요약을 최후의 수단으로 취급한다. Manus는 "한계 수익이 감소한 뒤에만"이라고 말하고, Deep Agents는 85%라는 구체적 트리거를 설정했다. 표현은 다르지만 의미는 같다. 원본 정보를 최대한 오래 유지하되 물리적 한계에 도달하면 계층적으로 압축하라.

세 축이 만드는 워크플로우

수직 분해가 작업의 깊이를 정한다. 어디까지 쪼갤 것인가, 완료 조건은 무엇인가. 수평 배치가 작업의 폭을 정한다. 어떤 역할이 어떤 순서로 실행하는가, 거버넌스는 어떻게 적용할 것인가. 시간 관리가 작업의 지속성을 정한다. 컨텍스트가 넘치면 무엇을 남기고 무엇을 버릴 것인가, 세션 사이의 연속성을 어떻게 보장할 것인가.

한 번 짠 워크플로우가 영구히 유효하지는 않다. 모델이 바뀌면 분해 단위가 달라지고, 컨텍스트 윈도우가 커지면 압축 전략의 필요성이 줄어들고, 새로운 도구가 나오면 역할 배분이 재편된다. Manus가 6개월간 하니스를 5번 리팩토링하고, Vercel이 도구의 80%를 제거한 사례가 이를 보여준다.

워크플로우를 설계하는 것만큼, 그 설계를 주기적으로 해체하고 재구축하는 일이 필요하다. 다음 편에서 이 "개선 사이클"을 다룬다. 하니스 자체를 어떻게 관찰하고, 어떤 데이터로 판단하고, 언제 갈아엎을 것인가.