1장. 코딩의 병목이 이동했다

다음은 여러 현장에서 반복된 패턴을 합친 합성 사례로, 등장하는 숫자는 설명을 위한 예시 수치다.

월요일 오전, 제품 책임자가 결제 화면에 쿠폰 기능을 추가해 달라고 요청했다. 에이전트는 점심 전에 API와 화면, 테스트까지 담긴 변경을 세 개 만들었다. 팀은 빨라졌다고 생각했다. 오후가 되자 첫 번째 변경은 할인 중복 규칙을 잘못 이해했다는 사실이 드러났다. 두 번째는 오래된 API를 사용했고, 세 번째는 다른 기능 브랜치와 같은 파일을 수정했다. 생성에는 두 시간이 걸렸지만 검토·충돌 해결·재시험에는 이틀이 들었다.

이 장면은 에이전트가 무능해서 생긴 일이 아니다. 코드 생산 능력만 늘고 그 전후 공정은 그대로였기 때문에 생긴 일이다.

이번 장의 약속

이 장을 마치면 다음을 할 수 있다.

• 코드 생성 속도와 제품 전달 속도를 구분한다.
• 에이전트 도입 뒤 새로 생기는 병목을 찾는다.
• 소프트웨어 공장을 일곱 개 층으로 나누어 진단한다.
• 도입 전 기준선을 기록해 ‘빨라진 느낌’을 측정 가능한 가설로 바꾼다.

산출물이 많아져도 전달은 느릴 수 있다

개발 흐름을 아주 단순하게 줄이면 다음과 같다.

문제 이해 → 명세 → 구현 → 검증 → 리뷰 → 통합 → 운영 관찰

코딩 에이전트는 주로 구현의 처리 능력을 크게 늘린다. 때로는 명세 초안과 테스트 작성도 돕는다. 하지만 전체 흐름의 처리량은 가장 느린 공정과 공정 사이의 대기 시간에 제약된다. 구현만 빨라지면 검증 대기열과 리뷰 대기열이 길어진다. 동시에 진행 중인 변경이 늘면 충돌과 문맥 전환도 증가한다.

여기서 첫 번째 원칙을 얻는다.

에이전트가 만든 코드의 양이 아니라, 검증되어 운영에 도달한 가치의 흐름을 최적화한다.

다음 두 팀을 비교해 보자.

왼쪽 팀의 에이전트가 더 많은 코드를 만들었지만 오른쪽 팀이 더 많은 가치를 전달한다. 숫자는 설명을 위한 예시지만 판단 기준은 실제 현장에도 그대로 적용된다. 생성량은 선행 지표일 뿐이고, 검증된 변경과 실패 비용이 함께 보이지 않으면 성과라고 부를 수 없다.

프롬프트가 아니라 생산 시스템

팀이 처음 에이전트를 도입할 때 흔히 프롬프트부터 다듬는다. 역할을 길게 쓰고, 금지 사항을 더하고, 성공한 대화를 템플릿으로 저장한다. 좋은 지시는 중요하다. 그러나 프롬프트 한 장이 다음 질문에 모두 답하지는 못한다.

• 현재 요구의 공식 버전은 어디에 있는가?
• 에이전트가 읽어야 할 파일과 건드리면 안 되는 경계는 무엇인가?
• 두 작업이 같은 파일을 바꾸면 누가 먼저 통합하는가?
• 테스트가 통과해도 아키텍처 규칙을 어기면 누가 막는가?
• 중단된 작업을 다른 에이전트가 어디서 이어받는가?
• 실행 비용과 사람의 개입 시간은 어디에 기록되는가?

이 질문의 답을 실행 가능한 구조로 묶은 것이 에이전트 하니스다. 이 책에서 하니스는 모델 주변의 프롬프트만 뜻하지 않는다. 입력을 정규화하고, 도구와 권한을 제한하고, 상태를 보존하고, 검사를 실행하고, 결과를 다음 단계로 전달하는 전체 작업 환경을 뜻한다.

에이전트 소프트웨어 공장은 이 하니스를 반복 가능한 개발 흐름으로 운영하는 체계다. ‘공장’이라는 말은 창의성을 없애거나 사람을 부품처럼 취급한다는 뜻이 아니다. 품질을 개인의 기억과 영웅적 야근에 맡기지 않고, 반복 가능한 공정과 피드백으로 만든다는 뜻이다.

공장을 이루는 일곱 층

이 책은 공장을 일곱 층으로 나눈다.

1. 의도 층: 문제, 범위, 수용 기준, 비기능 요구를 명세한다.
2. 지식 층: 저장소 구조, 용어, 결정, 작업 규칙을 에이전트가 읽을 수 있게 둔다.
3. 계획 층: 일을 작고 검증 가능한 작업으로 나누고 의존성을 표현한다.
4. 실행 층: 도구, 권한, 시간, 예산을 가진 에이전트가 격리 공간에서 변경한다.
5. 검증 층: 기능 테스트, 구조 규칙, 보안 검사, 독립 리뷰로 결과를 판정한다.
6. 통합 층: 충돌과 순서를 관리하고 승인된 변경만 기준선에 합친다.
7. 관측·학습 층: 이벤트, 비용, 실패 이유, 사람의 개입을 기록하고 다음 공정을 개선한다.

그림 1-1. 구현 속도만 높이면 후단 대기열이 커진다. 일곱 층의 닫힌 흐름이 전달 속도와 품질을 함께 만든다.

좋은 모델은 실행 층의 성능을 높인다. 그러나 의도가 모호하거나 검증 층이 약하면 더 좋은 모델도 잘못된 방향으로 더 멀리 간다. 반대로 일곱 층이 명확하면 모델을 교체해도 팀의 운영 지식은 남는다.

에이전트 도입 뒤 나타나는 네 가지 병목

1. 명세 부채

사람끼리는 회의의 표정과 조직의 암묵지로 모호함을 보완한다. 에이전트는 저장된 문맥을 기준으로 행동한다. “기존처럼 처리해”라는 문장은 기존이 어느 버전인지, 예외가 무엇인지 판정할 수 없다. 생성 능력이 늘수록 모호한 요구에서 파생되는 잘못된 구현도 빨리 늘어난다.

명세 부채의 신호는 다음과 같다.

• 구현은 완료됐지만 ‘원한 것이 아니다’라는 반응이 반복된다.
• 테스트가 코드의 현재 행동만 확인하고 제품 규칙을 설명하지 못한다.
• 같은 용어를 기획, 프런트엔드, 백엔드가 다르게 쓴다.
• 에이전트가 질문하지 않고 임의의 기본값을 자주 선택한다.

2. 검증 부채

생성 코드가 늘면 사람이 읽어야 할 diff도 늘어난다. 리뷰어는 피로해지고 큰 변경에서 중요한 한 줄을 놓친다. 테스트가 느리거나 불안정하면 에이전트가 피드백을 받기 전에 다음 잘못을 쌓는다.

검증 부채는 ‘테스트 개수’만으로 판단하지 않는다. 실패가 원인과 가까운 곳에서, 이해할 수 있는 메시지로, 충분히 빨리 드러나는지가 중요하다.

3. 통합 부채

병렬 에이전트는 작업 시작 수를 늘린다. 하지만 같은 모듈과 설정 파일을 건드리면 병렬성의 이득이 충돌 해결 비용으로 사라진다. 작업의 의존성과 소유권이 보이지 않을수록 완료된 변경이 통합 대기열에 쌓인다.

4. 관측 부채

결과 파일만 남고 어떤 명세, 도구, 판단, 재시도에서 나왔는지 기록되지 않으면 실패를 재현할 수 없다. 사람은 긴 대화 기록을 뒤지거나 처음부터 다시 실행한다. 관측 부채가 쌓인 팀은 모델 문제, 도구 문제, 명세 문제를 구분하지 못해 프롬프트만 계속 바꾼다.

자동화와 자율성은 같은 말이 아니다

자동화는 정해진 조건에서 단계를 수행하는 능력이다. 자율성은 불확실한 상황에서 다음 행동을 선택할 수 있는 범위다. 자율성을 넓힐수록 다음 세 가지도 함께 강화해야 한다.

• 판정 가능성: 성공과 실패를 기계 또는 사람이 분명히 가를 수 있는가?
• 실패 격리: 잘못된 행동이 영향을 미치는 범위가 제한되는가?
• 복구 가능성: 중단, 되돌리기, 인계가 가능한가?

이 관계를 간단히 적으면 다음과 같다.

허용할 자율성 ∝ 판정 가능성 × 실패 격리 × 복구 가능성

수학적 법칙이 아니라 설계 경험칙이다. 세 요소 중 하나가 거의 0이면 자율성의 범위를 좁혀야 한다. 예를 들어 자동 생성된 문서 초안은 실패 비용이 낮고 되돌리기 쉬워 넓게 위임할 수 있다. 운영 데이터 삭제는 결과 판정 이전에 피해가 발생할 수 있으므로 강한 승인과 최소 권한이 필요하다.

실습: 현재 흐름의 기준선 만들기

도구를 설치하기 전에 최근 완료한 변경 하나를 고른다. 기억에 의존하지 말고 이슈, 커밋, CI 기록을 보고 아래 표를 채운다.

그다음 흐름을 한 줄로 그린다.

[요청 09:00] --대기 4h--> [구현 13:00~15:00]
              --대기 18h--> [리뷰 09:00~10:30]
              --대기 2h--> [통합 12:30]

구현은 두 시간이지만 전체 리드 타임은 27시간 30분이다. 이 팀에서 구현 시간을 절반으로 줄여도 전달 시간은 약 한 시간만 줄어든다. 먼저 다룰 후보는 리뷰 대기와 불명확한 수용 기준이다.

진단 카드

아래 항목을 0(없음)부터 3(심각함)까지 표시한다.

[ ] 요구가 여러 채널에 흩어져 있다.
[ ] 저장소 사용법이 사람의 기억에만 있다.
[ ] 테스트 실패 원인을 찾는 데 10분 넘게 걸린다.
[ ] 병렬 작업의 파일 충돌이 잦다.
[ ] 에이전트 실행을 재현할 기록이 없다.
[ ] 리뷰어가 생성된 큰 변경을 그대로 승인한다.
[ ] 배포 뒤 결함이 에이전트 작업과 연결되지 않는다.

가장 높은 두 항목이 공장 설계의 첫 투자 대상이다. 모든 층을 한꺼번에 자동화하지 않는다.

왜 실패하는가

생성량을 성과로 보고한다

커밋 수, 생성 줄 수, 에이전트 실행 횟수는 쉽게 늘릴 수 있다. 그러나 이 숫자는 사용자 가치나 품질을 보장하지 않는다. 최소한 검증 완료율, 재작업률, 사람 개입 시간과 짝지어 본다.

가장 어려운 업무부터 위임한다

영향 범위가 넓고 성공 기준이 모호한 레거시 재설계를 첫 시범 과제로 고르면 모델과 하니스를 동시에 디버깅하게 된다. 반복적이고 경계가 분명하며 자동 판정 가능한 작업부터 시작한다.

사람의 검토를 무조건 안전장치로 둔다

‘마지막에는 사람이 보니 괜찮다’는 말은 리뷰 양이 사람의 주의 한계를 넘을 때 무너진다. 사람에게 보내기 전에 기계가 잡을 수 있는 형식, 테스트, 구조, 보안 위반을 제거해야 한다.

운영 판단: 첫 자동화 후보 고르기

후보 업무마다 다음 네 항목을 1~5점으로 평가한다.

네 점수의 합이 높고 실제로 자주 발생하는 업무를 첫 후보로 삼는다. 단, 보안·개인정보·금전 이동 같은 고위험 작업은 총점이 높아도 별도 승인 경계를 둔다.

연습문제

1. 구현 시간이 4시간에서 1시간으로 줄었지만 리뷰 대기가 2일에서 4일로 늘었다. 팀이 ‘개발 속도 4배’라고 보고하면 무엇이 빠졌는가?
2. 현재 팀의 명세 부채 신호를 세 가지 적고, 각 신호를 관측할 자료를 연결하라.
3. 자동화 후보 세 개를 반복성·판정 가능성·실패 영향·문맥 준비도로 채점하라.
4. “모든 PR은 사람이 리뷰한다”를 더 강한 안전 문장으로 바꾸어 보라. 기계 검사와 사람 판단의 역할을 나눠야 한다.

체크포인트

다음이 준비되면 1장을 마쳤다.

• 최근 변경 하나의 요청부터 통합까지 타임라인
• 구현 시간, 대기 시간, 재작업, 사람 개입의 기준값
• 일곱 층 가운데 현재 가장 약한 두 층
• 자동화할 첫 업무와 선택 근거

다음 장에서는 실행 층 안으로 들어간다. 모델이 어떻게 도구를 사용하며, 하니스가 어디에서 행동을 제한하고 상태를 이어 주는지 하나의 루프로 해부한다.