같은 Claude 모델에게 코드를 짜게 하면 "완성됐다"고 한다. 그런데 리뷰어 역할을 주고 같은 코드를 보여주면 메모리 누수와 엣지 케이스 세 개를 바로 잡아낸다. 모델이 달라진 게 아니다. 역할이 달라진 것뿐이다. dev.to에 공개된 5-에이전트 팀 구축 사례는 이 단순한 원리가 실제 개발 워크플로우를 어떻게 바꾸는지 보여준다.
역할 분리가 품질을 바꾼다
핵심 통찰은 명확하다. LLM은 자신이 방금 쓴 코드를 방어하는 경향이 있다. 같은 세션에서 "잘 됐나요?"라고 물으면 보호 본능이 작동한다. 인간 개발자가 자기 코드를 리뷰할 때 생기는 블라인드 스팟과 구조적으로 같은 문제다. 해결책은 역할을 강제로 분리하는 것이다—Planner, Coder, Reviewer, Tester, Debugger. 각 에이전트는 다른 시스템 프롬프트, 다른 툴 권한, 다른 출력 포맷을 가진다. Reviewer에게는 "룩스 파인은 세 번 리뷰 이후에만 허용"이라는 규칙이 박혀 있다.
설계에서 눈에 띄는 건 '금지 규칙'이 명시적이라는 점이다. Reviewer는 파일을 수정하지 않는다. Coder는 커밋하지 않는다. Debugger는 코드를 바꾸지 않는다. 역할의 경계는 할 수 있는 것보다 할 수 없는 것으로 더 선명하게 그어진다. 이 구조가 없으면 에이전트는 자기 역할 밖을 침범하고, 그 순간 품질 보장은 무너진다.
상태 공유 없이는 멀티 에이전트도 없다
역할 분리를 실제로 구현하면 바로 벽에 부딪힌다. Claude Code 서브에이전트는 세션 간 메모리를 공유하지 않는다. Planner가 만든 spec.json을 Coder가 모른다. 이 문제를 해결하지 않으면 멀티 에이전트는 이름뿐이다. 해당 사례에서는 Supabase의 agent_state 테이블로 태스크 상태를 영속화하고, MCP 서버로 역할별 권한을 강제했다. Planner는 읽기만, Coder는 쓰기 가능하되 마이그레이션 불가, Tester는 테스트 테이블에만 쓰기—권한 정책이 시스템 프롬프트가 아닌 서버 레이어에서 집행된다. 프롬프트에 금지 규칙을 넣는 것보다 훨씬 견고하다.
인간 게이팅이 자동화의 마지막 안전망이다
흥미로운 지점은 완전 자동화를 시도했다가 실패했다는 고백이다. 에이전트가 자동으로 다음 에이전트를 호출하게 했더니 방향을 잃었다. 현재 운영 방식은 에이전트 간 전환을 사람이 수동으로 승인한다. 커밋 권한도 어떤 에이전트에도 없다. 이건 타협이 아니라 설계 원칙이다—자동화가 넓어질수록 인간 게이트의 위치가 더 중요해진다.
비슷한 맥락에서 DeepSeek을 테크 리드로 삼아 Claude Code를 관리하게 한 실험도 주목할 만하다. DeepSeek이 아키텍처를 기획하고 Claude Code에 태스크를 위임하며 결과를 리뷰하는 구조다. "마크다운 노트앱을 만들어 Cloudflare Pages에 배포해"라는 한 줄 프롬프트로 스캐폴딩부터 배포까지 진행됐다. 두 사례 모두 공통점이 있다—단일 에이전트에 모든 걸 맡기지 않고, 역할을 설계한 뒤 협업 구조를 만들었다는 것이다.
역할 설계 없는 자동화는 보안 구멍을 양산한다
그런데 AI가 코드를 빠르게 생성할수록 놓치는 게 있다. Cursor가 반복적으로 작성하는 prototype pollution 취약 패턴이 그 증거다. JavaScript의 딥 머지 함수를 요청하면 다섯 번 중 세 번은 __proto__ 키 검증이 없는 코드가 나온다. 문제의 원인은 명확하다—학습 데이터의 대부분이 prototype pollution이 알려지기 이전에 작성된 StackOverflow 답변들이다. {"__proto__": {"isAdmin": true}} 같은 페이로드 하나로 프로세스 내 모든 객체가 isAdmin을 상속받고, 인증 체크가 뚫린다. CVE-2019-10744(lodash merge)부터 CVE-2021-25928까지, 이미 현실에서 터진 취약점들이다.
역할 설계가 된 Reviewer 에이전트라면 이런 패턴을 잡을 수 있다. Reviewer의 체크리스트에 SQL 인젝션, XSS, 권한 누락이 명시돼 있는 것처럼, prototype pollution 탐지 규칙도 시스템 프롬프트 수준에서 정의할 수 있다. 반대로 역할 없이 단순히 "코드 짜줘"만 반복하면 AI는 빠르게 취약점을 양산한다. 자동화의 속도와 보안의 깊이는 역할 설계라는 같은 레버로 동시에 조정된다.
지금 팀에 적용한다면
세 가지 소스가 가리키는 방향은 같다. 첫째, 에이전트에게 역할을 주기 전에 '이 역할이 무엇을 해서는 안 되는가'를 먼저 정의하라. 할 수 있는 것의 목록보다 금지 목록이 품질을 만든다. 둘째, 세션 간 상태를 어떻게 공유할지 설계하지 않으면 멀티 에이전트는 단순히 여러 개의 단독 프롬프트일 뿐이다. Supabase든 Redis든 공유 아티팩트 레이어가 필요하다. 셋째, AI가 생성한 코드의 보안 검증을 자동화 파이프라인 바깥에 두면 안 된다. Reviewer 에이전트의 체크리스트에 prototype pollution, SQL 인젝션, 권한 누락을 명시적으로 박아라.
팀 리빌딩을 AI-First로 한다는 건 도구를 더 많이 쓰는 게 아니다. 역할을 설계하고, 경계를 정의하고, 검증 레이어를 자동화에 내장하는 것이다. AI가 팀원이 되려면 팀원답게 역할을 받아야 한다—그 역할 설계는 여전히 테크 리드의 몫이다.