Agent Teams 로 코드 감사 돌려봤습니다 — 5명의 Opus 가 동시에 논쟁하는 풍경

시작 — 프로젝트가 커지면서 느낀 한계

이 블로그는 처음부터 끝까지 혼자 개발합니다. 초기엔 페이지 몇 개·게임 두세 개 수준이라 전체 코드를 머리에 담을 수 있었지만, 시간이 지나면서 상황이 달라졌습니다. 컨테이너·훅·공통 유틸이 쌓이고, 같은 패턴의 미묘한 사이드이펙트가 여러 파일에 분산되기 시작했습니다. "이쯤 되면 전체 상태를 한 번 점검해야겠다" 는 지점에 온 것이죠.

그래서 2026년 4월 10일부터 Claude 유료 구독 을 시작했습니다. 이유는 간단합니다.

• 이 웹페이지의 규모가 눈에 띄게 커졌고 (파일 수·기능·외부 API 연동 등)
• 혼자서 코드 전체의 일관성·보안·성능을 점검하기엔 한계에 도달
• 대규모 refactor 와 최적화를 신뢰할 만한 "리뷰어 AI" 가 필요

구독을 시작하고 며칠 동안은 Claude Code 의 기본 기능 — 파일 편집·테스트·리팩토링 — 을 일상적으로 쓰며 적응했습니다. 그러던 중 Agent Teams 라는 기능이 눈에 들어왔습니다. 여러 AI 에이전트가 독립 세션으로 병렬 실행되며 서로 메시지를 주고받는 구조. "다섯 명의 Opus 에이전트를 동시에 돌려서 코드 감사를 시키면 어떨까?" 라는 생각이 자연스럽게 떠올랐고, 실제로 실행해봤습니다.

이 글은 그 실사용 후기입니다.

Agent Teams 가 뭔가

Claude Code 의 실험적 기능으로, 여러 에이전트가 독립 세션으로 동시 실행되며 서로 메시지를 주고받을 수 있는 구조입니다. 단순 병렬 호출이 아니라:

• 각 에이전트가 자신만의 context 보유
• 공유 task list 로 작업 분배
• SendMessage 로 에이전트 간 논쟁·협업 가능
• 팀장 (메인 세션) 이 최종 결정·수정 실행

"한 명의 AI 에게 여러 역할을 시키는" 것과 "여러 AI 에게 각자 역할을 맡기고 논쟁시키는" 것은 결과물이 완전히 다릅니다. 후자가 놀랍도록 촘촘한 감사를 만들어냅니다.

팀 구성 — 역할별 5명

제가 구성한 감사팀은 이랬습니다.

역할	Agent Type	담당 영역
프런트엔드 감사관	yujh-auditor-frontend	components / views / routing / styles / a11y
코어 로직 감사관	yujh-auditor-core	비즈니스 로직 / 상태 머신 / 순수 함수
데이터 감사관	yujh-auditor-data	API / 모델 / 스토리지 / 캐시 / 보안
인프라 감사관	yujh-auditor-infra	빌드 도구 / deps / CI / manifest
검증관 (Verifier)	yujh-auditor-verifier	다른 감사관 발견을 반증 시도

핵심은 검증관 입니다. 감사관 4명이 🔴 이슈를 올리면 검증관은 "이거 진짜 문제인가?" 를 독립 검증합니다. 기본 가정은 "모든 🔴 는 오탐일 수 있다". 감사관의 발견을 그대로 믿지 않는 devil's advocate 역할.

실제 감사 플로우

1. 팀장 preflight

메인 세션(팀장)이 프로젝트를 훑어서 프로젝트 프로필 을 만듭니다 — 프레임워크, 빌드 도구, 프로젝트 규칙 파일 위치 등. 이걸 spawn 시 각 팀원에게 전달해 "너희는 이 프로젝트를 감사하는 거야" 를 인식시킵니다.

2. 병렬 감사 시작

각 감사관은 독립 세션에서 자기 영역을 훑어 🔴 이슈를 생성. task 제목은 예를 들면:

B2-01 [data]     NASA API key 클라이언트 번들 노출
B2-02 [data]     visit_log 스팸 방지 부재
D-03  [infra]    GitLab Variables Protected 플래그 미확인
A-08  [frontend] Cosmic Barrage resize debounce 400ms 주석 부재
B1-07 [core]     useCosmicBarrageAudio visibilitychange 핸들러 누락
...

3. 검증관의 반증 시도

감사관이 올린 🔴 task 를 검증관이 claim. 실제 코드를 다시 읽고 판정:

• ✅ Valid — 유효한 지적, 수정 필요
• ❌ False positive — 오탐. SendMessage 로 감사관에게 반박
• ⚠️ Partial — 일부만 맞음. 🟡 로 downgrade 제안

4. 순환 논쟁 → 팀장 에스컬레이션

감사관과 검증관이 3 라운드 돌렸는데 합의 안 되면 팀장에게 에스컬레이션. 팀장이 직접 파일 읽고 최종 판정.

기억에 남는 발견 몇 가지

실제 감사에서 나온 진짜 재밌던 것들입니다.

🔴 → ✅ 유효 확정

• NASA API 키 클라이언트 번들 노출 (B2-01) — 배포 번들에서 40자 키가 그대로 읽힘. CloudFront Function 으로 edge 주입 구조로 전환
• 방명록 rate limit 부재 — session 당 30초 쿨다운만 있어, 다른 session 갈아타면 우회 가능. 일일 한도 + 포스트별 한도 트리거 추가

🔴 → ❌ 오탐 철회

• Exoplanet API 프로덕션에서 rewrite 동작 안 함 — data agent 가 next.config rewrites() 는 dev 전용임을 근거로 제기. 팀장이 실제 확인: 프로덕션 CloudFront 에 해당 경로 proxy behavior 가 있음. repo 외부 인프라라 파일만으로는 검증 불가했던 오탐
• useMemo(() => getUserId(), []) 는 매 렌더마다 재실행돼서 성능 이슈 — verifier 의 초기 판정. 실제론 SSR에서 null 캐시되어 영구 null 이 되는 진짜 문제. 감사관 재반박으로 🔴 유지

🔴 → 🟡 Downgrade

• "성능 최적화 기회" 류 이슈 다수는 검증 중 "현재 상태로도 충분" 판정되어 🟡 (개선 대기) 로 강등

실제 수치

두 차례 실행 결과:

지표	값
총 🔴 raise	30+
실제 수정	8
오탐 철회	4
🟡 downgrade	6
POST-AUDIT 대기	2

"오탐 4건" 은 중요합니다. 만약 검증관 없이 감사관 혼자 돌렸다면 이 4건은 그대로 수정 대상으로 들어가, 실제로는 문제없는 코드를 건드려 새 버그를 만들었을 가능성이 높습니다. devil's advocate 역할의 가치가 구체적으로 드러난 순간.

제약사항 — 알고 써야 하는 것들

Agent Teams 는 강력하지만 제약도 명확 합니다.

Session Resume 미지원

한번 팀을 만들고 일시 중단하면 나중에 이어받을 수 없습니다. In-process 팀원은 /resume 이나 /rewind 로 복원되지 않음. 작업을 한 번에 끝내는 구조로 접근.

세션당 팀 1개

동시에 여러 팀을 만들 수 없습니다. 재호출하려면 이전 팀을 명시적으로 정리(TeamDelete).

Shutdown 지연

팀원에게 shutdown_request 를 보내도 현재 턴 종료 후에만 실제 종료. 수 분 걸릴 수 있음.

비용

Opus 5명 병렬이라 비용이 만만치 않습니다. 주간 정기 감사 같은 용도는 과함 — 대신 릴리스 전 심층 감사, 큰 refactor 직후 같이 "이벤트성" 사용이 합리적.

활용 팁

감사관에게 프로젝트 프로필 꼭 전달

팀장이 preflight 에서 파악한 정보 (프레임워크·빌드·규칙 파일) 를 spawn 프롬프트에 포함. 그래야 감사관이 "이 프로젝트 컨벤션에 맞는지" 를 기준으로 판단합니다.

검증관 프롬프트는 공격적으로

"검증관은 모든 🔴 를 오탐으로 의심하라" 를 강하게 명시. 안 그러면 감사관의 주장을 그대로 인정해버리는 경향.

Repo 외부 인프라 고려

이번 오탐 4건 중 3건이 "repo 외부 CloudFront 설정" 때문이었습니다. 감사관은 파일만 보고 판단하니, CloudFront·nginx·외부 API 설정에 대한 가정 은 반드시 팀장이 별도 확인해야 합니다.

회고

Agent Teams 로 감사를 돌린 경험은 "AI 여러 명이 협업한다" 는 개념을 실감한 계기였습니다. 특히 오탐 철회 워크플로우 가 인상적이었습니다 — 감사관 한 명만 돌렸다면 그대로 수정 대상이 됐을 것을, 검증관이 반박하고 실제 인프라를 확인해서 철회한 흐름.

혼자 만드는 프로젝트에도 "동료 리뷰" 에 준하는 압력을 걸 수 있는 도구라는 점이 가장 큰 가치였습니다. 전역 인프라·보안 이슈를 주로 찾는 용도에서 특히 위력적입니다.

릴리스 전 큰 감사가 필요하거나, 대규모 refactor 뒤 누수 체크가 필요하시다면 한 번 시도해볼 만합니다. 비용은 있지만, 놓친 이슈 하나를 배포 후 발견하는 비용보다는 작습니다.