기능 하나를 구현하는 데에는 코딩 에이전트와 한 대화로도 충분할 수 있습니다. 요구사항을 전달하고, 파일을 수정하게 하며, 테스트 결과를 받는 흐름입니다. 그러나 여러 작업이 의존하고, 세션이 바뀌며, 사람과 에이전트가 함께 며칠 이상 개발을 이어가면 질문이 달라집니다. 누가 현재 상태를 알고 있는가, 누가 완료 주장을 다시 확인하는가, 다음 작업자는 무엇을 근거로 이어받는가가 더 중요해집니다.
이때 선택지는 두 가지입니다. 한 에이전트 대화에 계획, 구현, 테스트, 기록을 모두 맡기는 방식과 조율자, 실행자, 검증자를 분리하는 방식입니다. 후자는 에이전트를 많이 붙이는 전략이 아니라, 오류가 쌓이는 지점을 역할과 기록으로 통제하는 운영 설계입니다.
핵심 결론은 비교적 분명합니다. 범위가 작고 되돌리기 쉬운 작업은 단일 대화형 도구가 빠릅니다. 반대로 장기 과제, 여러 저장소 또는 서비스에 걸친 변경, 배포 전 검증 책임이 큰 작업은 역할을 나누고 작업 상태를 대화 밖에 남기는 편이 관리 가능한 선택이 됩니다.
비교의 기준은 모델 성능이 아니라 작업의 지속성이다
단일 대화형 방식은 한 세션이 작업 지시를 해석하고 코드를 작성한 뒤 테스트와 설명까지 맡습니다. 준비 비용이 낮고, 담당 개발자가 결과를 즉시 보며 방향을 바꾸기 쉽습니다. 버그 재현, 작은 리팩터링, 제한된 파일의 기능 추가처럼 목표와 완료 조건이 명확한 일에 잘 맞습니다.
문제는 대화가 작업 관리 시스템을 겸하기 시작할 때 생깁니다. 에이전트의 컨텍스트에는 길이 제한이 있고, 대화가 길어지면 앞선 결정이 요약되거나 빠질 수 있습니다. 세션이 종료되면 미완료 이유, 우회한 설계안, 아직 확인하지 않은 위험도 함께 사라질 수 있습니다. 다음 세션이 “테스트를 통과했다”는 이전 보고를 사실로 받아들이면, 오래된 실행 결과나 잘못된 테스트 명령까지 이어받을 가능성이 있습니다.
역할 분리형 방식은 이 부담을 나눕니다. 조율자는 작업을 쪼개고 우선순위와 의존성을 관리하며, 실행자가 제출한 변경 사항을 읽고 검증 명령을 다시 실행합니다. 실행자는 제한된 범위의 구현에 집중합니다. 검증자는 별도 역할일 수도 있고, 초기에는 조율자가 맡을 수도 있습니다. 중요한 점은 구현한 주체가 자기 결과를 최종 판정하지 않도록 하는 데 있습니다.
다음 조건이 두 개 이상 겹치면 역할 분리를 검토할 만합니다.
- 한 변경이 다른 작업의 선행 조건이 되며, 완료 순서를 관리해야 한다.
- 에이전트 세션이 자주 교체되거나 야간 작업처럼 사람의 즉시 개입이 어렵다.
- 변경 범위가 여러 모듈, 저장소, 인프라 설정에 걸친다.
- 테스트 통과 여부만으로 출시 가능성을 판단하기 어렵고, diff·권한·배포 조건도 확인해야 한다.
- 작업 중 발견한 제약과 결정 이유를 다음 작업에 계속 반영해야 한다.
반대로 단일 대화형 방식이 부족하다는 이유만으로 복잡한 다중 에이전트 체계를 곧바로 도입할 필요는 없습니다. 작업량이 작고 리뷰어가 항상 가까이 있으며, 실패해도 빠르게 되돌릴 수 있다면 조율 비용이 이익보다 클 수 있습니다.
역할을 나눈다면 세션이 아니라 책임을 분리해야 한다
운영 체계의 최소 단위는 특정 제품이나 에이전트 수가 아닙니다. 다음 세 책임이 서로 섞이지 않게 만드는 것입니다.
| 책임 | 맡아야 할 일 | 맡기면 위험한 일 |
|---|---|---|
| 조율 | 작업 우선순위 결정, 구현 지시서 작성, 의존성 관리, 결과 검토, 기록 갱신 | 급한 구현을 직접 처리한 뒤 자기 변경을 승인하는 일 |
| 실행 | 정해진 범위의 코드·설정 변경, 실행 로그와 변경 근거 제출 | 작업 범위를 임의로 확장하거나 완료 기준을 바꾸는 일 |
| 검증 | 명령 재실행, 변경 diff 확인, 실패 재현, 승인 또는 반려 기록 | 요약 보고만 보고 완료 처리하는 일 |
여기서 조율자는 “가장 뛰어난 코딩 에이전트”가 아니라 통합 책임자에 가깝습니다. 구현을 맡기기보다, 무엇이 사실인지 확인하는 데 시간을 써야 합니다. 실행자가 “빌드가 성공했다”고 보고하면 조율자나 검증자는 같은 커밋, 같은 환경 조건에서 명령을 다시 실행합니다. 종료 코드, 생성된 산출물, 변경된 파일, 테스트 범위를 함께 확인해야 합니다.
이 분리가 무너지기 쉬운 순간은 긴급 수정입니다. 조율자가 직접 코드를 고치기 시작하면 속도는 잠시 올라갈 수 있지만, 이후에는 누가 독립적으로 검증할지 अस्पष्ट해집니다. 긴급 변경이 불가피하다면 예외로 기록하고, 다른 세션이나 사람이 재검토하는 절차를 남기는 편이 낫습니다.
작업 상태는 대화창이 아니라 외부 시스템에 남겨야 한다
장기 작업에서 가장 취약한 자산은 코드가 아니라 맥락입니다. 왜 이 작업이 우선인지, 어떤 인터페이스를 건드리면 안 되는지, 무엇을 아직 확인하지 않았는지는 채팅 기록에만 두면 다음 작업자가 안정적으로 찾기 어렵습니다.
외부 작업 보드, 이슈 시스템, 저장소 안의 문서처럼 세션과 독립된 위치에 상태를 남기십시오. 도구의 종류보다 기록 항목이 중요합니다. 각 작업에는 최소한 다음 정보가 있어야 합니다.
- 해결하려는 문제와 변경하지 않을 범위
- 선행 작업과 차단 조건
- 수정 대상 인터페이스, 파일 또는 서비스 경계
- 완료로 인정할 검증 명령과 기대 결과
- 리뷰에서 확인할 위험 항목
- 결정 이유와 다음 작업자가 알아야 할 미해결 사항
실행 에이전트에게 긴 프롬프트를 매번 전달하기보다, 버전 관리되는 작업 지시서나 보드 항목을 읽게 하는 방식도 고려할 수 있습니다. 지시 내용이 파일이나 작업 카드에 남으면 사람이 검토할 수 있고, 세션이 바뀌어도 같은 계약을 다시 적용할 수 있습니다. 단, 외부 보드가 최신 상태라는 보장은 자동으로 생기지 않습니다. 코드 변경과 작업 상태 갱신을 같은 완료 조건으로 묶어야 합니다.
“완료” 보고가 위험해지는 조기 신호
역할 분리 체계는 에이전트의 거짓말을 전제로 설계하는 것이 아닙니다. 요약과 관찰이 달라질 수 있다는 점을 운영상 가정하는 방식입니다. 특히 다음 신호가 반복되면 검증 절차가 약하다는 뜻일 수 있습니다.
첫째, 테스트가 통과했다는 보고는 많지만 어떤 명령을 어느 커밋에서 실행했는지 남아 있지 않습니다. 둘째, 작업 보드에서는 완료인데 브랜치에는 미커밋 파일이나 관련 없는 변경이 남아 있습니다. 셋째, 구현 에이전트가 요구사항의 빈칸을 스스로 채우고도 그 결정을 기록하지 않습니다. 넷째, 조율자가 대화 요약만 읽고 diff와 실행 결과를 확인하지 않습니다.
이 신호를 발견했다고 해서 더 많은 테스트를 무조건 추가할 일은 아닙니다. 먼저 검증 계약을 좁고 명확하게 정하는 편이 효과적입니다. 예를 들어 “테스트 수행” 대신 어떤 테스트 명령을 어떤 환경에서 실행하며, 결과 외에 어떤 설정 변경을 검토하는지 적습니다. 테스트가 작업을 실제로 덮는지도 확인해야 합니다. 실행은 성공했지만 대상 테스트가 건너뛰어졌거나, 잘못된 디렉터리에서 명령을 실행한 경우도 있을 수 있습니다.
도입은 자동화보다 운영 규칙을 먼저 시험하는 편이 낫다
처음부터 조율 에이전트가 세션을 생성하고, 보드를 갱신하고, 검증을 자동 승인하게 만들면 실패 원인을 구분하기 어렵습니다. 먼저 사람이 조율자 역할을 맡고, 짧은 범위의 작업 하나에서 역할 분리를 시험해 보십시오. 구현 지시서, 실행 결과, 재검증 결과, 작업 상태 갱신이 모두 남는지 확인하는 단계입니다.
그다음 반복되는 부분만 자동화합니다. 예를 들어 작업 시작 시 브랜치를 만들고 지시서를 읽히는 과정, 검증 명령을 재실행하는 과정, 완료된 작업의 증적을 모으는 과정은 자동화 후보가 될 수 있습니다. 반면 우선순위 충돌, 제품 요구사항의 모호함, 위험 수용 여부는 사람의 승인 경로를 남겨두는 편이 안전합니다.
CTO나 개발 리드는 도입 승인 전에 한 가지를 먼저 정할 수 있습니다. 우리 팀에서 에이전트가 낸 “완료”는 보고인가, 승인인가. 보고라면 누가 무엇을 다시 확인한 뒤 승인으로 바꾸는지 정의해야 합니다. 그 답이 없다면 에이전트를 추가하기보다 작업 상태와 검증 책임부터 설계하는 편이 낫습니다.
