에이전트 팀 — 사람의 말은 원문으로

역할 분리 파이프라인(TM01)을 한 세션 안의 에이전트 팀으로 옮겨 본 기록입니다. 저녁 메뉴를 대신 정해주는 앱 '끼니'를 사람의 한 줄 요청에서 시작해, 역할 에이전트 7개가 요구사항 초안부터 Expo 프로토타입까지 나눠 썼습니다. 팀 구조는 문제없이 돌았고, 실패는 전부 사람의 판단이 에이전트에게 넘어가는 경계에서 났습니다.

사례

1. 05-1

   판단이 무거운 자리는 큰 모델, 기계적인 자리는 작은 모델

   문제

   한 세션이 기획·조사·설계·구현을 다 하면 같은 모델이 기준 문서와 코드와 리뷰를 모두 쓰고, 모든 맥락이 한 컨텍스트에 쌓입니다. 작업마다 필요한 판단의 무게도 다릅니다.

   설계

   역할 에이전트 7개를 정의 파일로 고정했습니다 — 기획·설계·구현은 opus, 리서치·UX·문서 검증은 sonnet, 미정 질문 병합·집계·색인만 하는 서기는 haiku. 각 역할은 자기 파일만 쓰고, 다른 역할에 넘길 것은 문서 끝 '미정 제안' 절에 남겨 서기가 옮깁니다. 순서는 기획∥리서치 → UX∥설계 → 서기 → 문서 검증 → 사람 승인. 문서 검증은 자기와 같은 모델이 쓴 문서를 리뷰할 때 그 사실을 보고서 머리에 적습니다 — 오류의 비상관성이 약해지는 구간을 숨기지 않기 위해서입니다.

   결과

   하루 안에 요구사항·미정 질문·시장 조사 2건·UX·설계 문서와 프로토타입이 나왔습니다. 서기가 병합한 미정 제안은 1차 16건, 2차 15건. 미정은 BLOCKER 25·LATER 24건으로 집계돼 게이트 A에 걸린 채 사람 승인을 기다립니다.

2. 05-2

   프로토타입이 질문보다 먼저 나갔다

   문제

   사람이 준 것은 '저녁 메뉴 고민될 때 추천해주는 앱' 한 줄이었습니다. 에이전트 팀은 미정 항목마다 추천 답을 전제로 기획 초안과 프로토타입 두 판(HTML·Expo)을 만들었고, 사람은 화면을 보자마자 '이게 아니라'고 했습니다 — 해 먹기 위주, 예산·인분 입력, 재료비 기준, 레시피와 조리법.

   설계

   에이전트의 추천 답에 [제안] 표기를 지켜 둔 덕분에 무엇이 무너졌는지는 바로 추적됐습니다 — '입력 0회', '200종 고정 목록', '하루 1건 고정' 전제가 폐기로 표시됐습니다. 구조를 가르는 질문 5개를 한 번에 묻고, 답을 받은 뒤에 문서와 화면을 다시 만들었습니다. 이 결함은 기능이 아니라 절차의 문제로 따로 기록했습니다.

   결과

   v0 프로토타입 두 판 모두 재작업 — 둘 다 스모크 테스트(37건·31건)를 통과한 상태였습니다. 테스트가 통과해도 방향은 틀릴 수 있습니다. 답 5개로 BLOCKER 3건이 닫히고 1건이 부분적으로 닫혔으며, v1 프로토타입은 질문 이후에 만들었습니다.

3. 05-3

   에이전트는 사람의 말을 조용히 약화시킨다

   문제

   2차 문서 검증에서 H급 9건 중 6건이 '문서가 사람의 말과 어긋남'이었습니다. 5건은 사람의 답을 채팅에서 받고 사람 진술 기록 문서에 옮기지 않은 절차 누락에서 나왔고, 그 탓에 BLOCKER 4건이 근거 없이 '해결'로 닫힌 것처럼 보였습니다. 1건은 기획 에이전트가 '시켜 먹는 건 집주소 입력 필요'를 '건너뛸 수 있다'로 바꿔 쓴 것이었습니다.

   설계

   문서 검증의 0번 축을 '문서가 사람의 말을 정확히 옮겼는가'로 두고, 이 유형은 무조건 H로 분류합니다. 사람의 답은 질문과 함께 원문 표로 기록 문서에 먼저 적고, 에이전트가 원문을 완화한 줄은 원문으로 되돌린 뒤 '푸는 것은 사람이 정한다'고 표기합니다. 내용 판단이 필요한 나머지 지적은 고치지 않고 사람에게 넘깁니다.

   결과

   답 5개를 원문으로 기록해 근거를 복원하고, 주소 필수 요구사항을 원문대로 되돌려 구현 에이전트에 다시 전달했습니다. 프로토타입 스모크에 '주소 없이 돌리기 불가 → 입력 후 가능' 단계가 추가됐습니다.

4. 05-4

   에이전트의 보고는 다시 센다

   문제

   작은 모델에 맡긴 기계적 집계도, 문서 검증 보고서의 머리 숫자도 틀렸습니다. 1차 검증 보고서는 머리에 '총 12건'이라 적고 표에는 11행이 있었고, 2차 서기 집계는 LATER 21건이었지만 실제 행은 24건이었습니다.

   설계

   에이전트가 낸 숫자는 grep으로 다시 세어 표와 맞춥니다. 구현 에이전트는 '통과할 것으로 보인다'가 아니라 검사 원문을 보고하고, 확인하지 못한 범위를 결과보다 먼저 말합니다. 실행 환경에서 Expo 서버가 막혀 폰 실행 대신 웹 번들로 같은 로직을 검증했고, 그 한계를 함께 적었습니다.

   결과

   집계 불일치 2건 정정. v1 프로토타입은 카탈로그 무결성 검사(레시피 20·재료 54·배달 메뉴 26), 타입 검사, 웹 번들 빌드, Playwright 스모크 53건 통과·콘솔 에러 0, expo-doctor 19/21(실패 2건은 막힌 호스트 조회)로 확인했고, 실제 폰 실행은 미확인으로 먼저 보고했습니다.

남은 규칙

1. 01역할마다 모델을 고정한다. 판단이 무거운 문서는 큰 모델, 기계적 정리는 작은 모델에 준다.
2. 02각 역할은 자기 파일만 쓴다. 다른 역할에 넘길 것은 제안 절로 남기고 한 역할이 병합한다.
3. 03프로토타입 전에 질문 1라운드를 먼저 한다. 테스트가 통과해도 방향은 틀릴 수 있다.
4. 04사람의 답은 질문과 함께 원문으로 먼저 적는다. 채팅에만 있는 결정은 없는 것이다.
5. 05문서 검증의 0번 축은 '사람의 말을 정확히 옮겼는가'다. 원문을 약화한 줄은 원문으로 되돌린다.
6. 06에이전트가 낸 숫자는 다시 센다. 확인하지 못한 범위는 결과보다 먼저 말한다.