'루프를 짜는 게 내 일이 됐다'는 Claude Code 창시자 Boris Cherny의 발언이 화제가 됐을 때, 많은 팀이 착각했다. 루프 자체가 어려운 게 아닌데, 루프 구현에 집중한 것이다. 실제로 어려운 건 루프를 돌릴 에이전트를 팀원처럼 세팅하는 일이다. 역할을 정의하고, 판단 순서를 설계하고, 에이전트가 '낡은 세계'를 기준으로 행동하지 않도록 경계를 만드는 것—이 세 가지가 함께 설계되어야 한다.
역할 없이 루프만 돌리면 보일러플레이트만 남는다
Squad 프레임워크가 흥미로운 이유는 바로 이 지점을 건드리기 때문이다. GitHub Copilot 위에서 동작하는 이 도구는 frontend, backend, tester, lead 같은 역할을 파일 형태로 레포에 정착시킨다. 에이전트마다 자신의 컨텍스트와 지식 범위가 분리되고, loop.md를 통해 사이클마다 자신이 해야 할 일을 확인한다. GitHub 이슈 큐를 읽어 스스로 작업을 꺼내오고, 자기 범위를 벗어난 작업은 직접 이슈를 생성해 다른 에이전트에게 넘긴다.
중요한 건 이게 단순한 멀티챗봇이 아니라는 점이다. 각 에이전트는 자기 역할에 맞는 스킬만 갖고, 자기 컨텍스트 안에서만 동작한다. 30분 작업, 10분 휴식 사이클을 운영한 실사용자의 경험에 따르면 10분 미만으로 줄이면 서브에이전트 작업이 충돌한다. 이건 AI의 문제가 아니라 워크플로우 설계의 문제다. 팀원을 뽑을 때 역할 정의 없이 뽑지 않듯, 에이전트도 차터(charter)와 스킬 정의가 먼저다.
현실적인 한계도 명확하다. Copilot 전용이라 Claude Code나 Codex로 이식이 쉽지 않고, 병렬 서브팀(subsquad)은 오히려 처리량을 떨어뜨렸다는 보고도 있다. 도입 전에 자기 팀의 툴체인과 맞는지 먼저 따져봐야 한다.
리뷰어 에이전트는 '더 긴 프롬프트'가 아니라 '단계 분리'로 개선된다
AI 리뷰어를 에디토리얼 파이프라인에 구축한 한 개발자의 경험은 에이전트 스킬 설계에 대한 중요한 통찰을 준다. 초기에는 루브릭을 확장하고 프롬프트를 길게 만드는 방식으로 개선을 시도했다. 결과는 기대에 못 미쳤다.
진짜 개선은 추론 단계를 분리하는 것에서 왔다. 점수를 먼저 매기면 편집 피드백이 아니라 QA 피드백이 나온다. 해결책은 분석을 먼저, 채점을 나중에 하는 순서 재조정이었다. 그다음 문제는 리뷰어가 자기 결론에 이의를 제기하지 않는다는 것이었다. 여기서 도입한 게 적대적 리뷰 패스(adversarial review)다. 1차 비평을 동결(freeze)한 뒤, 그 비평이 틀렸다는 가정으로 반론을 생성하고, 반론이 유효할 때만 최종 권고를 바꾼다.
세 번의 실패를 거치며 드러난 패턴은 명확하다. 루브릭을 늘리는 게 아니라, 인지 작업(cognitive job)을 분리된 패스로 쪼개는 것이 핵심이다. 자기 반박, 감산 편집, 독자 집중 추적은 하나의 패스에 몰아넣으면 서로 간섭한다. 각각 독립된 관찰 패스로 분리하고 고정된 핸드오프를 설계해야 한다.
이 원리는 코드 리뷰 에이전트에도 그대로 적용된다. 보안 취약점 탐지, 아키텍처 일관성 검토, 가독성 피드백을 하나의 프롬프트에 욱여넣으면 성능이 떨어진다. 역할을 명확히 나누고 단계를 분리하는 것, 이게 에이전트 리뷰어의 품질을 결정한다.
에이전트는 '낡은 세계'를 기준으로 행동할 수 있다
GitHub 어댑터 개발 경험에서 나온 세 번째 통찰은 에이전트 팀 설계에서 가장 간과되기 쉬운 부분이다. stale state 문제다.
에이전트는 레포를 읽고, 계획을 세우고, 도구를 호출하고, 수정을 제안한다. 그 사이에 브랜치가 advance되고, 다른 워크플로우가 같은 파일을 수정하고, 누군가 핫픽스를 푸시할 수 있다. 에이전트의 추론은 옳았지만, 그 추론의 기반이 된 세계가 이미 바뀐 것이다.
이를 해결하는 개념이 state-bound intent다. 에이전트가 제안하는 변경에 '이 변경이 합리적이었던 상태의 참조값(브랜치 헤드, 파일 해시 등)'을 함께 묶는 것이다. 경계(boundary)는 에이전트가 본 상태와 현재 상태를 비교해, 상태가 바뀌었으면 변경을 차단하고 재읽기를 요청한다. 이건 에이전트가 틀렸다는 게 아니다. 에이전트의 제안이 속한 세계가 더 이상 존재하지 않는다는 것이다.
Git의 base commit, DB의 version check, HTTP의 ETag—이 개념들은 새로운 게 아니다. 다만 에이전트는 read-to-write 갭을 훨씬 넓고 예측 불가능하게 만든다. 읽고, 계획하고, 도구를 호출하고, 재시도하는 동안 타깃 시스템은 계속 움직인다. 에이전트 팀을 설계할 때 이 갭을 구조적으로 처리하지 않으면, 정교하게 설계된 루프도 엉뚱한 결과를 낸다.
세 가지를 함께 설계하라
세 소스가 가리키는 방향을 종합하면 에이전트 팀 세팅의 실행 순서가 나온다.
첫째, 역할과 스킬을 파일로 정의하라. 에이전트가 무엇을 알고, 무엇을 하고, 어디까지 개입하는지를 코드가 아니라 문서로 먼저 선언해야 한다. Squad의 charter 방식이 하나의 레퍼런스다.
둘째, 인지 작업을 단계로 분리하라. 하나의 에이전트 패스에 여러 추론 작업을 몰아넣지 마라. 분석, 채점, 자기 반박, 감산 편집—각각을 분리된 패스로 쪼개고 단계 간 핸드오프를 고정하라. 루브릭 확장보다 시퀀스 설계가 먼저다.
셋째, 상태 참조를 제안에 묶어라. 에이전트가 변경을 제안할 때, 그 제안이 합리적이었던 상태의 참조값을 함께 첨부해야 한다. 경계에서 상태 일치를 검증하고, 불일치 시 변경을 차단하며 재읽기를 유도하는 구조를 설계하라.
이 세 가지가 갖춰지지 않은 에이전트 루프는 '잘 돌아가는 루프'가 아니라 '빠르게 실수하는 루프'다. 에이전트를 팀원처럼 믿고 맡기려면, 팀원을 온보딩할 때처럼 역할·판단 기준·안전 경계를 함께 설계해야 한다. 루프는 그 다음이다.