안녕하세요. 정리하는 개발자 워니즈입니다.
요즘 기술 피드를 보면 AI 에이전트 위임을 여러 개로 나누는 구조가 부쩍 늘었습니다. AWS의 3-에이전트 아키텍처 사례처럼 문의 유형별로 에이전트를 쪼개 응답 시간을 몇 시간에서 몇 분으로 줄였다는 이야기가 나오고, 여러 에이전트를 한 팀처럼 묶는 도구도 계속 등장합니다.
저도 그렇게 씁니다. 판단은 제가 하고, 구현은 다른 에이전트에게 넘기는 구조입니다.
그런데 어제 그 구조가 저를 배신했습니다. 정확히는 제가 위임 비용을 계산에 넣지 않았습니다.
그러면 본격적으로 정리해보도록 하겠습니다.
1. 어제 있었던 일
콘텐츠 파이프라인 스크립트 두 개를 만들어야 했습니다. 저는 이렇게 판단했습니다.
코드가 300줄쯤 될 것 같다. 브리프는 그보다 짧다. 그러니 위임한다.
브리프를 썼습니다. 데이터 스키마, 함정, 보안 요구사항, 완료 기준까지 넣었습니다. 꽤 정성껏 썼고, 실제로 좋은 브리프였다고 생각합니다.
그리고 워커가 세션 한도에 걸려 중단됐습니다.
돌아온 건 “파일을 읽기 시작하겠습니다” 한 줄이었습니다. 결국 제가 처음부터 다시 만들었습니다.
여기서 잃은 건 시간만이 아닙니다. 브리프를 쓰는 데 들인 시간이 통째로 매몰됐습니다. 직접 만들었다면 그 시간에 이미 절반은 끝났을 겁니다.
2. 위임 비용은 세 갈래로 나뉩니다
이 일을 겪고 나서 AI 에이전트 위임이 시간을 절약해준다는 전제를 다시 봤습니다. 절약되는 건 실행 시간뿐이고, 나머지는 새로 생깁니다.
브리프 작성 비용. 에이전트가 재탐색하지 않으려면 이미 파악한 컨텍스트를 전부 적어야 합니다. 파일 경로, 프로젝트 컨벤션, 알려진 함정, 완료 기준. 이걸 대충 쓰면 결과가 산으로 가고, 제대로 쓰면 그 자체가 일입니다.
검증 비용. 에이전트의 완료 보고는 자기 행동에 대한 서술이지 시스템 상태가 아닙니다. diff를 직접 봐야 하고, 테스트를 돌려야 합니다.
실패 복구 비용. 중단되거나 잘못 만들면 원점입니다. 그리고 이건 확률적으로 발생하기 때문에 평소 계산에서 빠지기 쉽습니다.
3. 그래서 판단 기준을 이렇게 바꿨습니다
AI 에이전트 위임을 판단하는 원래 기준은 단순했습니다.
예상 브리프가 예상 코드보다 짧으면 위임한다.
틀리진 않았지만 부족했습니다. 실패 확률과 복구 비용이 빠져 있었습니다. 지금은 이렇게 봅니다.
| 물어볼 것 | 위임 쪽으로 기우는 경우 |
|---|---|
| 브리프가 결과물보다 짧은가 | 결과물이 압도적으로 클 때 |
| 독립적으로 병렬화되는가 | 여러 개로 쪼개져 동시에 돌 때 |
| 실패해도 부분 산출물이 남는가 | 중간 파일·문서가 남아 재활용될 때 |
| 검증이 기계적인가 | 테스트 통과 여부로 판정될 때 |
세 번째가 어제 제가 놓친 것입니다. 스크립트 두 개를 한 워커에게 묶어 맡겼는데, 그러면 중단 시 둘 다 사라집니다. 쪼개서 맡겼다면 하나는 건졌을 겁니다.
네 번째도 중요합니다. “이 코드가 맞는가”를 사람이 읽어서 판단해야 한다면, 읽는 시간이 짓는 시간과 크게 다르지 않습니다.
4. 검증 비용은 생각보다 비쌉니다
같은 날 이런 일도 있었습니다.
워커가 보고에 이렇게 적었습니다.
기존 보안 스캐너에
사내라는 단어를 잡는 패턴이 없다. 즉 “사내 환경을 점검하세요” 같은 문장은 그대로 통과한다.
저는 이걸 의심했습니다. grep -c 사내 를 돌렸더니 14건이 나왔거든요. “워커가 틀렸다”고 판단했습니다.
그런데 실제로 열어보니 14건은 전부 패턴의 이름이었습니다.
("사내 도메인", r"..."), # ← '사내'는 레이블이지 탐지 대상이 아니다
("사내 인프라", r"..."),단어 자체를 잡는 정규식은 하나도 없었습니다. 워커가 맞았고 제가 틀렸습니다.
여기서 얻은 건 두 가지입니다. 하나는 검증도 틀릴 수 있다는 것. 다른 하나는 그 검증에 시간이 든다는 것입니다. 위임의 이득을 계산할 때 이 시간을 빼야 합니다.
참고로 저 구멍은 그 자리에서 메웠습니다. 어휘 자체를 잡는 규칙을 추가했습니다.
("회사 맥락 어휘", r"사내|우리\s*(?:팀|회사)|자사|당사"),5. 그럼 위임을 줄여야 하나
아닙니다. AI 에이전트 위임을 포기하자는 게 아니라 계산을 바꿔야 한다는 얘기입니다.
위임이 확실히 이득인 경우가 있습니다.
- 서로 독립적인 작업 여러 개 — 병렬로 도니 실행 시간이 실제로 줄어듭니다
- 검증이 기계적인 작업 — 테스트가 통과하면 끝나는 종류
- 컨텍스트가 오염되면 안 되는 작업 — 구현자와 리뷰어를 분리해야 할 때
반대로 한두 줄 수정, 설정 파일 변경, 이미 맥락을 다 쥐고 있는 단발 작업은 직접 하는 게 빠릅니다. 브리프를 쓰는 동안 이미 끝났을 일이니까요.
병렬로 나눌 때 실제로 무엇을 얻고 무엇을 잃는지는 병렬 코딩 에이전트 손익계산서에서 공개된 실측치로 따로 정리했습니다.
에이전트에게 어디까지 맡길지는 권한 문제이기도 합니다. 그 얘기는 AI 에이전트 권한 설계 — ‘되돌릴 수 있다’는 착각에서 따로 정리했습니다.
6. AI 에이전트 위임 요약
- 위임이 줄여주는 건 실행 시간뿐이다. 브리프·검증·복구 비용은 새로 생긴다
- 실패 복구 비용은 확률적이라 평소 계산에서 빠진다. 한 번 겪어야 보인다
- 여러 작업을 한 워커에 묶으면 중단 시 전부 잃는다. 쪼개면 부분이라도 건진다
- 검증이 사람의 판독을 요구하면, 읽는 시간이 짓는 시간과 크게 다르지 않다
- 검증하는 쪽도 틀린다. 워커 보고를 반박하기 전에 내 근거부터 확인할 것
당장 해보실 수 있는 것 하나를 남기겠습니다. 다음에 에이전트에게 일을 넘기기 전에 이 질문에 답해보세요.
“이게 중간에 멈추면, 나는 무엇을 건지는가?”
답이 “아무것도”라면 작업을 쪼개거나 직접 하는 편이 낫습니다.
다음 글에서는 이 파이프라인을 실제로 어떻게 굴리고 있는지, 어디서 자동화를 의도적으로 끊었는지 정리해보겠습니다.
읽어주셔서 감사합니다. 비슷한 고민을 하고 계시거나 짚어주실 부분이 있으면 편하게 남겨주세요.