대부분의 팀은 스스로 AI 에이전트 팀이 되기로 결정하지 않았습니다. 한 개발자는 코딩 에이전트를 도입했고, 다른 개발자는 이를 CI에 연결했으며, 어느새 분기 요청(PR)의 절반이 기계가 작성한 것이 되었습니다.

그러면 고통이 시작되는데, 이는 특정한 종류의 고통입니다:

• 읽을 수 있는 속도보다 빠르게 PR이 쌓인다.
• 두 에이전트가 겹치는 문제들을 서로 호환되지 않는 방식으로 해결한다.
• 한 개발자의 채팅 세션에 존재했던 프롬프트가 아무도 승인하지 않은 제품 결정으로 이어진다.

실패는 에이전트 자체가 아닙니다. 팀의 의도가 어느 에이전트나 검토자가 확인할 수 없는 곳에 존재한다는 것입니다. 채팅 기록은 검토할 수 없고, 재사용할 수 없으며, 최종 diff와 비교될 수도 없습니다.

에이전트가 등장하기 전에는 배포 과정에서 가장 느린 단계는 구현이었기 때문에 모든 프로세스가 개발자 처리량(throughput)을 최적화했습니다. 에이전트를 사용하면 구현은 거의 무료가 되며, 나머지 두 가지 단계가 제약 조건이 됩니다: 무엇을 정확히 만들지 결정하는 것, 그리고 결과가 그 결정과 일치하는지 확인하는 것.

다음은 인간의 노력을 이 두 지점으로 이동시키는 5단계 워크플로우입니다. 이는 도구에 구애받지 않습니다 — Claude Code, Cursor, Copilot 에이전트 또는 혼합 조합 모두 가능합니다 — 왜냐하면 계약(contract)이 어떤 도구의 메모리에 있는 것이 아니라 파일 안에 존재하기 때문입니다.

한눈에 보는 워크플로우

단계 1: 티켓을 스펙 패킷으로 전환하기

모든 후속 과정은 이 단계의 품질을 물려받게 되며, 이는 팀들이 가장 건너뛰고 싶어 하는 단계입니다.

입력:

가장 중요한 규율은 '달성하지 않을 목표(non-goals)'를 설정하는 것입니다. _"스키마 변경 없음, 이메일 템플릿 수정 없음, 새 의존성 추가 없음"_과 같은 문구는 에이전트가 도움이 되게 범위를 확장시키는 가장 흔한 세 가지 방법을 차단합니다.

어떤 에이전트가 구현할지 선택하기 전에 패킷을 작성하세요. 이 단계에서 제품의 모호성이 에이전트의 가정으로 새어나가는 대신 사람에 의해 해결됩니다.

2단계: 스펙을 경계가 있는 작업(bounded tasks)으로 분할하기

스펙 패킷은 여전히 하나의 프롬프트로 단일 에이전트에게 전달하기에는 너무 큽니다. 신뢰할 수 있는 에이전트의 작업 단위는 단일 에이전트가 한 번에 완료하고, 단일 사람이 검토할 수 있는 작업입니다.

각 작업은 설명 외에 세 가지 필드가 필요합니다:

Task 2 of 3: add retry endpoint
Write scope:
- src/exports/retry.ts
...

대부분의 다중 에이전트 혼란을 피하는 하나의 규칙이 있습니다: 파일을 공유하는 작업들은 병렬로 실행되어서는 안 됩니다. 만약 두 개의 작업이 모두 billing/index.ts를 건드린다면, 이들을 병합하거나 명시적으로 직렬화해야 합니다. 에이전트 간의 충돌(merge conflicts)은 도구링(tooling) 문제가 아니라 작업 분할 문제입니다.

3단계: 쓰기 범위 내에서 에이전트를 병렬로 실행하기

경계가 있는 작업을 사용하면, 병렬 처리는 안전하고 지루해집니다. 이것이 목표입니다. 각 에이전트에게 하나의 작업과 그 패킷, 그리고 격리된 브랜치 또는 git worktree를 제공하세요.

쓰기 범위(write scope)는 강제하는 선입니다: 쓰기 범위 밖에 있는 파일을 수정하려는 에이전트는 검토 전에 diff가 거부됩니다. 논의할 필요조차 없습니다. 대부분의 최신 에이전트는 다음과 같은 지침을 준수합니다:

쓰기 범위에 나열된 파일만 수정하세요. 작업 수행에 다른 것을 건드려야 한다면, 편집하는 대신 멈추고 보고하세요.

이 '멈추고 보고하라(stop-and-report)' 조항은 보이는 것보다 훨씬 중요합니다. 가장 비용이 많이 드는 에이전트의 실패는 잘못된 구현 자체가 아닙니다. 그것은 그저 _조용한 결정_입니다—겉보기에는 그럴듯한 diff 속에 묻혀 있는 추가 열, 이름이 변경된 함수, 새로운 의존성 같은 것입니다. 범위 강제(Scope enforcement)는 조용한 결정을 인간이 몇 초 만에 답하는 큰 질문으로 바꿉니다.

4단계: 검토를 요청하기 전에 증거 수집하기

에이전트가 작업 완료를 주장하는 것은 아무 가치가 없습니다. 태스크의 PR(Pull Request)이 열리기 전에, 같은 에이전트는 evidence.md 파일에 다음 내용을 채웁니다: 어떤 이름의 테스트가 추가되었는지, 그 패스 출력 결과는 무엇인지, 그리고 각 테스트가 어떤 수용 기준(acceptance criterion)을 커버하는지입니다.

증거(Evidence)는 환각적인 완전성(hallucinated completeness)이 죽는 곳입니다.

안정 상태(steady state)는 화려하지 않습니다. 사양(specs)은 짧고, 작업(tasks)은 지루하며, 에이전트는 상호 교체 가능하고, 검토(review)는 빠릅니다. 이것은 인간이 의도(intent)와 증거(evidence)에 시간을 쓰고, 기계가 그 사이의 모든 것에 시간을 쓰는 모습입니다.

실패 모드 테이블과 사양 패킷(spec packets), 작업 계획(task plans), 증거 로그(evidence logs)를 복사하여 바로 사용할 수 있는 템플릿 링크가 포함된 이 글의 전체 버전은 spec-coding.dev에서 확인할 수 있습니다. 사양 패킷 생성기(spec packet generator)는 무료이며 브라우저 내에서 완전히 실행됩니다.