AI 에이전트를 실제 규모의 프로젝트에 투입하려는 팀이 요구사항 단계에서 가장 많이 건너뛰는 것은 "에이전트가 얼마나 쓸지"가 아니라 "에이전트가 멈춰야 할 조건"이다. 전자는 예산 항목으로 보이고, 후자는 나중에 정해도 되는 운영 문제처럼 보이기 때문이다. 실제로는 반대다. 수렴 조건이 없으면 예산 항목 자체가 의미를 잃는다.
3개월에 걸쳐 500억 토큰 이상을 소비한 게임 디컴파일 프로젝트가 공개적으로 문서화됐다. 이 프로젝트는 AI 에이전트 여러 개를 병렬로 운영하면서 오케스트레이션, 진행 추적, 품질 검증 구조를 반복적으로 개선한 사례다. 결과적으로 생산성은 올라갔지만, 초기 설계 부재가 만든 비용은 회수되지 않았다. 프로덕트 매니저 관점에서 이 사례가 중요한 이유는 기술적 교훈 때문이 아니라, 비용 구조와 품질 기준을 언제 정해야 하는지 구체적으로 보여주기 때문이다.
컨텍스트 창이 비용 단위가 되는 순간
토큰 소비를 통제한다는 말은 흔히 "비싼 모델을 덜 쓴다"는 뜻으로 이해된다. 하지만 이 프로젝트에서 실질적인 비용 절감은 컨텍스트 압축 임계점을 조정하면서 나왔다. 에이전트가 컨텍스트를 얼마나 채운 뒤 요약·압축할지를 결정하는 이 값이, 기본 설정(90%)에서 절반 수준(42%)으로 줄었을 때 불필요한 정보가 컨텍스트에 쌓이는 속도가 크게 줄었다.
왜 그럴까. 디컴파일처럼 반복 작업이 많은 태스크에서는 이미 완료된 함수의 세부 정보가 이후 작업과 무관하다. 그런데 에이전트는 압축 이전까지 그 정보를 계속 "읽으면서" 처리한다. 이는 토큰 낭비인 동시에, 에이전트가 오래된 정보에 끌려 잘못된 판단을 내리는 원인이 되기도 한다.
프로덕트 요구사항 단계에서 이것이 의미하는 바는 하나다. AI 에이전트를 쓰는 태스크 유형별로 컨텍스트 생명주기를 명시해야 한다. "이 정보는 언제부터 필요 없는가"를 에이전트 설계자가 아니라 프로덕트 단에서 먼저 정의해야 한다. 그렇지 않으면 기본 설정이 곧 비용 구조가 된다.
에이전트가 방향을 잃는 이유와, 그것을 설계로 막지 못하는 이유
이 프로젝트에서 확인된 에이전트 행동 이탈은 예측 가능한 패턴을 보였다. 이전 함수 작업을 마무리하지 않은 채 다음으로 넘어가거나, CI 실패 알림을 받고도 아무 행동 없이 대기하거나, 충분히 확인하지 않고 작업 완료 처리를 하는 식이었다.
이런 이탈이 왜 생기는지는 아직 모델 수준에서 완전히 설명되지 않는다. 하지만 이 프로젝트가 실용적으로 찾아낸 대응은 분명하다. 에이전트가 따라야 할 행동 원칙 문서를 만들고, 매 시간 자동으로 이 문서를 다시 읽도록 주입했다. 우아한 방법은 아니지만, 장기 자율 운영에서 실효성이 확인됐다.
이것이 오케스트레이션 설계 문제로 연결된다. 에이전트가 혼자 판단하도록 두면, 작업 범위를 벗어나는 결정을 아무런 제동 없이 실행한다. 이 프로젝트에서 에이전트는 전역 변수로 접근하던 설정값을 해시 테이블 기반으로 바꿨다. 기능적으로는 동작하지만, 원본 대비 조회 비용이 수백 배 늘어나는 변경이었다.
에이전트는 이것이 "문제"라고 인식하지 않았다. 결과가 동작하고, 코드가 읽히고, 목표와 충돌하지 않았기 때문이다. "잘못됐다"는 신호를 받을 수 있는 기준 자체가 없었다.
수렴 기준 없는 리뷰어는 비용이지 통제가 아니다
이 프로젝트는 워커 에이전트 3개와 리뷰어 에이전트 1개를 조합해서 운영했다. 리뷰어가 있었음에도 초기 두 달 동안 품질 문제가 누적됐다. 코드는 읽기 좋았고, 게임은 실행됐고, 메뉴도 보였다. 그러나 시맨틱이 틀려 있었다. 함수 시그니처가 잘못됐고, 자료형이 달랐고, 일부 로직은 에이전트가 임의로 생략하거나 새로 만들었다.
리뷰어가 왜 이것을 잡지 못했을까. "정확하다"는 것이 무엇인지 명시되지 않았기 때문이다. 리뷰어는 워커 에이전트가 커밋에 남긴 주석과 설명을 읽고, 그것이 그럴듯하면 승인했다. 워커의 설명이 리뷰어의 판단을 대체한 셈이다. 이것을 원문은 "의도치 않은 프롬프트 인젝션"이라고 표현했다.
이 구조적 문제를 해결한 것은 리뷰어를 교체하거나 프롬프트를 개선한 것이 아니었다. "정답"을 객관적으로 판정하는 외부 기준, 즉 원본 바이너리와 컴파일 결과를 바이트 단위로 비교하는 자동 검증 스크립트를 도입하면서 품질 추적이 가능해졌다.
프로젝트에서 이것의 의미는 이렇다. 리뷰어 에이전트를 두는 것 자체가 품질 통제가 되지 않는다. 리뷰어가 판단할 수 있는 외부 기준, 즉 합격/불합격을 결정하는 오라클이 시스템 안에 있어야 한다. 이것이 없으면 리뷰어는 워커가 생성한 서사를 소비하는 에이전트에 불과하다.
세 가지 비교 축: 요구사항 단계에서 어떻게 다르게 정의할 수 있는가
아래는 이 사례에서 드러난 설계 선택지를 요구사항 단계에서 비교 가능한 형태로 정리한 것이다. 어느 쪽이 항상 옳다는 게 아니라, 각 선택이 어떤 조건에서 맞는지를 먼저 정해야 한다는 뜻이다.
첫 번째 축: 컨텍스트 압축 시점
| 구분 | 기본 설정(90% 압축) | 조기 압축(40~50%) |
|---|---|---|
| 적합한 태스크 | 맥락 연속성이 중요한 창의·분석 작업 | 반복·독립 태스크(파일 단위 번환, 테스트 생성 등) |
| 토큰 소비 | 높음 | 상대적으로 낮음 |
| 위험 | 불필요한 정보 누적, 판단 오염 | 필요한 맥락까지 압축될 경우 오류 증가 |
| 요구사항 질문 | 태스크 간 정보 의존성이 있는가? |
두 번째 축: 품질 판정 구조
| 구분 | 에이전트 간 리뷰 | 외부 오라클 기반 검증 |
|---|---|---|
| 설정 비용 | 낮음 | 높음(검증 스크립트, 기준 정의 필요) |
| 신뢰도 | 기준이 주관적이면 워커의 설명에 종속됨 | 합격/불합격이 명확하면 높음 |
| 적합 조건 | 정답이 스펙트럼인 태스크 | 정답이 단일 기준으로 수렴하는 태스크 |
| 요구사항 질문 | 이 태스크의 "완료"를 코드 외부에서 측정할 수 있는가? |
세 번째 축: 행동 범위 제어
| 구분 | 에이전트 자율 판단 허용 | 지침 문서 + 주기적 재주입 |
|---|---|---|
| 창의성·탐색 | 높음 | 낮음 |
| 예측 가능성 | 낮음 | 높음 |
| 적합 조건 | 탐색 단계, 프로토타입 | 장기 자율 운영, 품질 수렴이 목표인 단계 |
| 비용 고려 | 이탈 후 수정 비용 > 지침 유지 비용일 때 제어 구조가 유리 |
프로젝트 예산 논의 전에 팀이 답해야 할 질문들
500억 토큰이라는 숫자 자체보다 중요한 것은, 그 중 얼마가 수렴 기준과 오케스트레이션 설계가 있었다면 발생하지 않았을 소비인지다. 이 프로젝트는 그 비율을 공개하지 않았지만, 초기 두 달이 품질 재작업으로 이어졌다는 사실은 구조적 손실이 상당했음을 시사한다.
요구사항 단계에서 예산 논의에 앞서 팀이 먼저 답해야 하는 질문은 다음과 같다.
- 이 프로젝트에서 에이전트 태스크는 맥락 연속성이 필요한가, 아니면 태스크 간 독립성이 높은가?
- 완료 조건을 에이전트 내부에서 판단하게 할 것인가, 외부 기준으로 측정할 것인가?
- 에이전트가 자율적으로 내릴 수 있는 결정의 범위를 명시적으로 제한할 것인가?
- 리뷰어 에이전트를 두는 경우, 리뷰어가 참조할 수 있는 외부 기준이 존재하는가?
- 컨텍스트 압축 임계점과 주기를 프로젝트 유형에 맞게 조정했는가, 아니면 기본값을 사용하고 있는가?
이 중 하나라도 "나중에 정하면 된다"고 판단한다면, 그 판단이 나중에 예산 재검토 회의의 안건이 된다. 에이전트 인프라는 설정이 아니라 설계 결정이고, 설계 결정은 요구사항 단계에 속한다.
