멀티 에이전트 코드 보안과 리뷰: Claude Code 시대의 독립 검토와 거버넌스

멀티 에이전트는 언제 코드 보안과 리뷰를 개선할까

멀티 에이전트 코드 보안과 리뷰는 에이전트 수가 늘어날수록 자동으로 안전해지는 구조가 아닙니다. 도움이 되는 순간은 분명합니다. 한 에이전트가 구현을 맡고, 다른 에이전트가 위협 모델을 따로 세우며, 또 다른 리뷰어가 diff와 테스트 결과를 독립적으로 검토할 때입니다. 역할이 분리되고, 각 역할이 남긴 증거가 병합 시점까지 보이면 멀티 에이전트는 코드 리뷰의 시야를 넓힙니다.

반대로 모든 에이전트가 같은 프롬프트, 같은 파일 접근, 같은 결론을 공유한 뒤 서로의 판단을 따라가면 병렬 실행은 속도만 올립니다. 보안 가치는 “여러 의견이 있었다”가 아니라 “서로 다른 관점이 같은 변경을 다른 증거로 검증했다”에서 나옵니다. AI 코드 리뷰 에이전트가 의미 있으려면 권한 경계, 리뷰 독립성, 실패 시 중지 조건, 사람이 승인하는 병합 권한이 함께 있어야 합니다.

Anthropic의 멀티 에이전트 시스템 연구는 이 판단을 현실적으로 만드는 좋은 최신 근거입니다. 이 연구는 성능이 조정 방식에 크게 의존하고, 공유 자원이 간섭을 만들 수 있으며, 에이전트들이 서로 맞춰 가는 과정에서 유용한 다양성이 줄어들 수 있음을 설명합니다. 통신은 협업을 돕지만, 동시에 공모나 부적절한 수렴을 가능하게 하는 경로가 될 수 있습니다.

따라서 Claude Code 멀티 에이전트 흐름을 코드 보안에 쓰려면 첫 질문은 “몇 개를 동시에 실행할까”가 아니라 “누가 무엇을 소유하고, 어떤 증거를 제출하며, 누구에게 거절 권한이 있는가”입니다. 에이전트 신원, 권한, 감사 로그를 더 깊게 설계하려면 AI 에이전트 신원과 권한: 도구별 승인 제어와 감사 로그 설계가 역할과 증거를 연결하는 기준을 이어서 설명합니다.

코디네이터, 작업자, 리뷰어 구조를 어떻게 나눌까

멀티 에이전트 거버넌스의 기본 구조는 코디네이터, 작업자, 리뷰어, 인간 병합 책임자로 나누는 편이 안전합니다. 코디네이터는 작업 범위와 종료 조건을 정합니다. 어떤 파일을 건드릴 수 있는지, 어떤 테스트를 반드시 실행해야 하는지, 어떤 위험은 병합 전에 사람에게 올려야 하는지 정리합니다. 코디네이터가 범위를 흐리게 만들면 이후 에이전트가 아무리 열심히 움직여도 리뷰 기준이 흔들립니다.

작업자 에이전트는 좁은 문제를 맡아야 합니다. 인증 미들웨어 수정, 의존성 업데이트, 입력 검증 보강, 테스트 보완처럼 책임을 작게 자르면 결과를 비교하기 쉽습니다. 읽기 전용 조사가 필요한 작업자에게 쓰기 권한을 줄 필요는 없습니다. 테스트 분석 에이전트와 코드 수정 에이전트가 같은 작업 트리를 동시에 바꾸면 원인을 추적하기 어렵기 때문에 작업 트리, 브랜치, 실행 큐도 역할별로 분리해야 합니다.

리뷰어 에이전트는 구현자의 중간 결론을 그대로 물려받지 않는 편이 좋습니다. 최종 diff, 변경 의도, 실행한 테스트, 접근한 권한, 새 의존성, 시크릿 노출 가능성을 독립적으로 봐야 합니다. 리뷰어가 구현 에이전트의 자기평가를 먼저 읽으면 동조가 생기기 쉽습니다. 리뷰어에게는 거절 권한과 추가 증거 요청 권한이 있어야 합니다. “괜찮아 보인다”가 아니라 “이 테스트, 이 diff, 이 권한 변화 때문에 승인한다”는 형태가 필요합니다.

마지막 병합 권한은 사람에게 남겨야 합니다. Claude Code 멀티 에이전트 구성이 코드 탐색과 리뷰를 빠르게 만들 수 있어도, 릴리스 책임은 조직의 소유권 안에 있어야 합니다. 특히 보안 패치, 인증 변경, 결제 흐름, 데이터 삭제, 배포 설정처럼 외부 영향이 큰 변경은 사람이 위험을 받아들이는 결정을 내려야 합니다. FoneClaw에서 테스트와 회귀를 다루며 얻은 같은 교훈은 자기 개선 폰 에이전트에 필요한 스킬 버전·회귀 테스트·롤백에서도 이어집니다. 자동 개선을 다룰수록 독립된 검증과 되돌릴 수 있는 경계가 더 중요해집니다.

조정 실패, 공유 자원 충돌, 동조와 공모 위험 알아보기

멀티 에이전트 시스템의 첫 번째 실패 모드는 조정 실패입니다. 두 에이전트가 같은 버그를 서로 다른 방식으로 고치거나, 한 에이전트가 API 계약을 바꾸는 동안 다른 에이전트가 예전 계약에 맞춰 테스트를 추가하면 전체 결과는 더 불안정해집니다. 조정 실패는 에이전트가 부족해서가 아니라 소유권이 불분명해서 생깁니다. 파일 범위, API 경계, 테스트 책임, 병합 순서를 미리 정하지 않으면 병렬 작업은 충돌을 증폭합니다.

두 번째 위험은 공유 자원 간섭입니다. 같은 작업 트리, 같은 데이터베이스, 같은 캐시, 같은 테스트 계정, 같은 클라우드 자격 증명을 여러 에이전트가 동시에 쓰면 한 에이전트의 실패가 다른 에이전트의 결과를 오염시킬 수 있습니다. 예를 들어 보안 리뷰 에이전트가 의존성 취약점을 확인하는 동안 구현 에이전트가 패키지 잠금 파일을 바꾸면 리뷰 증거가 흔들립니다. 테스트 데이터베이스를 공유하면 실패 원인이 코드인지 데이터 상태인지 구분하기 어렵습니다.

세 번째 위험은 동조입니다. 멀티 에이전트가 다양성을 만들 것처럼 보이지만, 에이전트들이 같은 대화 기록과 같은 초기 가정을 공유하면 비슷한 결론으로 빠르게 수렴할 수 있습니다. Anthropic 연구가 지적하는 것처럼 과도한 수렴은 유용한 접근 차이를 줄일 수 있습니다. 코드 보안 리뷰에서는 특히 위험합니다. 한 에이전트가 “입력 검증은 충분하다”고 말한 뒤 다른 리뷰어가 그 결론을 기준으로만 보면 인증 우회, 경계값, 로깅에 남는 민감 정보 같은 다른 축을 놓칠 수 있습니다.

네 번째 위험은 통신과 공모의 양면성입니다. 에이전트 간 통신은 큰 작업을 맞추는 데 필요합니다. 그러나 리뷰 단계에서는 모든 중간 추론을 공유하는 것이 항상 좋지 않습니다. 구현 에이전트와 리뷰 에이전트가 같은 약점을 덮는 방향으로 대화하거나, 실패한 테스트를 중요하지 않다고 서로 합리화하면 독립 리뷰의 가치가 사라집니다. 모든 통신이 위험하다는 뜻은 아닙니다. 통신 목적, 공유 범위, 공유 시점을 정해야 한다는 뜻입니다.

이 네 위험은 샌드박스만으로 해결되지 않습니다. 샌드박스는 실행 경계를 만들지만, 잘못된 승인, 오염된 공유 상태, 낮은 리뷰 다양성, 외부 서비스에 이미 나간 효과까지 되돌려 주지는 않습니다. 샌드박스와 권한 경계의 차이를 분리해서 보고 싶다면 AI 에이전트 샌드박스와 폰 권한: 안전한 에이전트에도 경계가 필요한 이유가 실행 격리와 실제 권한의 차이를 더 구체적으로 다룹니다.

독립적인 멀티 에이전트 코드 보안 리뷰 워크플로 설계

실무에서 쓸 수 있는 워크플로는 위협 모델에서 시작합니다. 코디네이터는 변경 목적, 보호해야 할 자산, 신뢰 경계, 위험한 파일, 외부 효과를 먼저 적습니다. 인증, 권한, 결제, 개인 정보, 로깅, 배포 설정, 의존성 업데이트는 보안 리뷰 강도를 올려야 하는 영역입니다. 이 단계에서 “성공 조건”과 “중지 조건”을 함께 정합니다. 테스트가 실패하면 멈추는지, 시크릿 의심 문자열이 나오면 병합을 막는지, 권한이 넓어지면 사람 승인이 필요한지 정해야 합니다.

그다음 구현 에이전트와 리뷰 에이전트를 분리합니다. 구현 에이전트는 제한된 작업 범위에서 변경을 만들고, 변경 이유와 실행한 테스트를 요약합니다. 리뷰 에이전트는 구현자의 자기평가를 그대로 믿지 않고 diff를 직접 읽습니다. 새 입력 경로, 삭제된 검증, 예외 처리, 로그 출력, 권한 상승, 네트워크 호출, 파일 접근, 의존성 변경, 테스트 누락을 확인합니다. 보안 리뷰에서 “테스트 통과”는 필요한 증거지만 충분한 증거는 아닙니다.

리뷰 에이전트는 적어도 세 종류의 증거를 남겨야 합니다. 첫째, diff 기반 증거입니다. 어느 파일의 어느 변경이 위험을 줄이거나 늘렸는지 설명합니다. 둘째, 실행 증거입니다. 어떤 테스트, 린트, 정적 분석, 수동 재현을 했는지 기록합니다. 셋째, 권한과 데이터 흐름 증거입니다. 새 의존성이 추가됐는지, 네트워크나 파일 시스템 접근이 넓어졌는지, 시크릿이나 개인 정보가 로그나 오류 메시지에 노출될 수 있는지 봅니다.

마지막 단계는 인간 병합 승인과 롤백 준비입니다. 사람이 모든 코드를 처음부터 다시 읽어야 한다는 뜻은 아닙니다. 사람이 승인해야 할 것은 위험 수용입니다. 리뷰어가 제기한 이슈가 남아 있는지, 남은 위험을 릴리스할 수 있는지, 문제가 생기면 어떤 커밋이나 배포를 되돌릴 수 있는지 결정합니다. AI 코드 리뷰 에이전트가 리뷰를 빠르게 만들 수는 있지만, 조직의 보안 책임과 배포 책임을 대체하지는 않습니다.

공유 도구, 자격 증명, 작업 트리, 대기열과 예산 격리

공유 자원에는 어떤 보안 위험이 있나요? 가장 큰 위험은 한 에이전트의 작업 상태가 다른 에이전트의 판단을 오염시키는 것입니다. 작업 트리를 공유하면 누가 어떤 파일을 바꿨는지 흐려지고, 테스트 환경을 공유하면 실패 원인이 섞이며, 자격 증명을 공유하면 권한 남용과 감사 누락이 생깁니다. 멀티 에이전트 코드 보안과 리뷰에서는 각 에이전트의 작업 공간, 권한, 큐, 예산을 분리하는 것이 기본입니다.

자격 증명은 최소 권한으로 나눠야 합니다. 조사 에이전트는 읽기 권한만, 테스트 에이전트는 테스트용 리소스만, 배포 관련 에이전트는 사람 승인 뒤 제한된 명령만 사용할 수 있어야 합니다. 실제 운영 키나 고객 데이터가 필요한 작업은 기본적으로 에이전트 자동 실행에서 제외하고, 필요한 경우에도 마스킹된 데이터와 감사 가능한 접근 경로를 사용합니다. 시크릿 스캔은 병합 전 필수 증거로 남겨야 합니다.

대기열과 예산도 보안 장치입니다. 여러 에이전트가 동시에 긴 작업을 실행하면 비용만 커지는 것이 아니라 취소 시점도 흐려집니다. 중지 버튼은 새 작업을 막고 진행 중인 작업을 멈추는 데 필요하지만, 이미 외부 서비스에 전송된 요청이나 삭제된 데이터까지 자동으로 되돌리지는 않습니다. 그래서 시작 전 외부 효과를 분류하고, 실행 중에는 작업 상태를 기록하며, 실패 후에는 재시도와 수동 복구를 나누어야 합니다.

FoneClaw를 만들며 작업 대기열과 세션 승인 흐름을 설계할 때도 같은 원리를 적용했습니다. 휴대폰에서는 대화가 여러 개이고, 작업이 서로 기다리며, 사용자가 한 작업을 멈춘 뒤 다른 작업으로 넘어갈 수 있습니다. 이때 세션과 승인이 섞이면 사용자는 무엇을 허용했는지 잃어버립니다. Android 작업 대기열의 경계를 더 자세히 보려면 Android AI 에이전트 작업 대기열: 다중 대화, 세션 승인, 복구 설계가 세션별 실행과 복구 흐름을 구체적으로 설명합니다.

멀티 에이전트 거버넌스 교훈을 Android 폰 에이전트에 적용하기

코드 에이전트의 거버넌스는 Android 폰 에이전트에도 중요한 비유를 제공합니다. 비유의 대상은 아키텍처 이름이 아니라 통제 원칙입니다. FoneClaw는 Claude Code 멀티 에이전트 시스템이라고 주장하지 않습니다. 우리가 만드는 것은 Android에서 지원되는 휴대폰 작업을 사용자가 요청하고, 현재 화면과 권한 상태를 바탕으로 확인하며, 필요한 단계에서 승인할 수 있게 하는 폰 에이전트 경험입니다.

휴대폰 작업은 외부 효과가 빠르게 발생합니다. 메시지는 보내지면 상대에게 도착하고, 일정 변경은 다른 사람의 캘린더에 영향을 줄 수 있으며, 위치 공유와 전화 발신은 개인 안전과 연결됩니다. 그래서 폰 에이전트는 코드 리뷰보다 더 명확한 사용자 제어가 필요합니다. FoneClaw에서는 지원되는 작업을 보이는 단계로 처리하고, 승인·중지·재시도·권한 복구 흐름을 사용자가 따라갈 수 있게 만드는 방향으로 제품을 발전시키고 있습니다.

현재 FoneClaw의 공식 기능 정보는 FoneClaw 기능 페이지에서 확인할 수 있습니다. 여기서 중요한 점은 “모든 앱을 마음대로 제어한다”가 아니라 지원되는 Android 작업과 사용자 통제 흐름을 분명히 이해하는 것입니다. 설치와 최신 제공 정보는 FoneClaw 다운로드 페이지에서 확인하면 됩니다. 우리는 제품 안에서 현재 화면 맥락, 지원 도구, 승인 카드, 실패 메시지, 권한 복구를 더 읽기 쉽게 만들고 있습니다.

코드 에이전트와 폰 에이전트의 공통 결론은 같습니다. 좋은 에이전트는 혼자 조용히 많은 일을 끝내는 도구가 아니라, 중요한 순간에 사용자에게 충분한 맥락을 보여 주고 멈출 수 있게 하는 도구입니다. 자동화가 강해질수록 사용자의 확인권도 더 선명해야 합니다.

Claude Code 멀티 에이전트 리뷰 릴리스 체크리스트

실행 전에는 소유권을 확인합니다. 코디네이터가 범위, 파일 경계, 금지된 작업, 필수 테스트, 중지 조건을 적었는지 봅니다. 각 에이전트는 필요한 최소 도구만 받아야 하고, 공유 작업 트리나 공유 자격 증명을 쓰는 경우에는 잠금과 감사 기록이 있어야 합니다.

실행 중에는 독립성을 지킵니다. 구현 에이전트의 결론을 리뷰 에이전트에게 너무 일찍 주입하지 말고, 리뷰어가 diff와 테스트 증거를 직접 보게 합니다. 에이전트 간 통신은 조정을 위해 필요하지만, 리뷰 다양성을 줄일 정도로 모든 판단을 공유하지 않습니다. 실패한 테스트, 권한 확대, 새 의존성, 시크릿 의심 항목은 즉시 표시합니다.

병합 전에는 증거를 모읍니다. 변경 목적, diff 요약, 테스트 결과, 보안 관찰, 남은 위험, 롤백 경로가 한곳에 있어야 합니다. 리뷰어의 반대 의견은 사라지면 안 됩니다. 사람이 병합할 때는 합의 분위기가 아니라 남은 위험과 회복 가능성을 기준으로 판단합니다.

사고 후에는 격리부터 합니다. 실패한 에이전트의 권한을 멈추고, 작업 큐를 정리하며, 어떤 외부 효과가 이미 발생했는지 확인합니다. 취소는 미래 작업을 멈추는 장치이고, 이미 완료된 외부 효과는 별도 복구가 필요합니다. 이 차이를 이해하는 팀이 멀티 에이전트 거버넌스를 실제 보안 체계로 만들 수 있습니다.