에이전트 한 개는 기능 문제입니다. 에이전트 열 개는 거버넌스 문제입니다.

이 전환점을 가장 먼저 포착한 것은 벤처 자본입니다. 에이전트 신원(identity) 관리 스타트업 NewCore가 지난주 $66M 시드 투자를 받았습니다. 에이전트가 first-class citizen이 되어야 한다는 명제에 자본이 붙었다는 뜻입니다.

같은 주에 Boris Cherny가 한 마디를 남겼습니다.

“AI world is getting loopy.”

에이전트가 루프를 돌고, 루프 안에서 또 다른 에이전트를 부르고, 그 에이전트가 다시 루프를 도는 구조가 됐을 때 — 무슨 일이 벌어지고 있는지 파악하기 어려워진다는 경고입니다. 서로 다른 두 신호가 같은 방향을 가리킵니다. 에이전트 스케일의 다음 병목은 실행 능력이 아니라 통제 구조라는 것입니다.

신원이 없으면 권한을 통제할 수 없다

지금까지 에이전트 설계는 “무엇을 실행하는가”에 집중했습니다. 프롬프트, 도구 목록, 메모리 구조. 그런데 에이전트가 10개, 20개로 늘어나면서 빠진 레이어가 드러나기 시작했습니다.

신원(Identity): 이 에이전트는 누구인가. 어떤 시스템에 접근할 수 있는가.

권한(Permission): 무엇을 할 수 있는가. 무엇은 하면 안 되는가.

폐기(Revocation): 권한을 언제, 어떻게 철회할 수 있는가.

사람에게는 이 세 가지가 기본으로 갖춰져 있습니다. 신입 직원이 재무 시스템에 접근하려면 승인이 필요하고, 그 접근은 기록되며, 퇴사하면 권한이 즉시 회수됩니다.

에이전트는 달랐습니다. 대부분의 구현에서 에이전트는 API 키 하나로 어디든 접근했습니다. 무엇을 했는지 추적되지 않았고, 권한 범위가 명시되지 않았습니다. 에이전트 하나일 때는 문제가 없었습니다. 열 개가 넘는 순간, 한 에이전트의 권한 오남용이 전체 파이프라인을 오염시킵니다.

NewCore가 해결하려는 것은 에이전트를 사람처럼 대우하는 겁니다. 에이전트에게도 신원이 있고, 그 신원에 권한이 연결되며, 그 권한은 언제든 철회될 수 있어야 한다는 원칙입니다.

루프를 제어하려면 목표 검증을 분리해야 한다

Slack 엔지니어링 팀이 에이전틱 테스팅을 설계하면서 찾아낸 원칙이 있습니다. 목표 검증(goal verification)과 결정론적 실행(deterministic execution)을 분리해야 한다는 것입니다.

“이 목표가 달성됐는가”를 판단하는 레이어와 “실행하는 레이어”가 섞이면, 에이전트는 자신의 기준으로 완료를 판단합니다. 그 기준이 우리가 원하는 것과 다를 때 루프는 끝나지 않습니다.

이 분리를 CLAUDE.md에 실제로 적용하면 이렇게 됩니다.

## 이 에이전트가 할 수 있는 것
- src/ 하위 파일 읽기·수정
- 테스트 실행 (npm test, npm run lint)
- GitHub PR 생성 및 설명 작성

## 이 에이전트가 해서는 안 되는 것
- 외부 API 직접 호출 (반드시 에스컬레이션)
- 프로덕션 배포 명령 실행
- .env 또는 secrets 파일 접근

## 성공 조건 (자율 종료 기준)
- PR이 CI를 통과하고 리뷰 준비 완료 상태
- 변경 파일 10개 이하

## 에스컬레이션 조건 (사람에게 넘기는 기준)
- 연속 3회 테스트 실패
- 예상치 못한 에러 타입 발생
- 예상 비용 $5 초과

이 파일 하나가 에이전트의 신원증명서입니다. 권한 범위, 행동 제약, 종료 조건이 명문화됩니다. 에이전트가 30개가 돼도 각자의 신원증명서가 있으면 어떤 에이전트가 어떤 권한으로 무엇을 했는지 추적 가능합니다.

자본이 먼저 보는 다음 병목

NewCore의 $66M은 에이전트 신원 인프라에 대한 투자입니다. 아직 표준이 없는 레이어에 자본이 먼저 들어갔습니다.

구글 딥마인드는 같은 방향을 다른 각도에서 가리키고 있습니다. AI 제어 로드맵에서 에이전트를 ‘내부 위협자(insider threat)‘로 분류하기 시작했습니다. 나쁜 의도가 있어서가 아닙니다. 권한 범위가 명확하지 않은 에이전트는 — 의도와 무관하게 — 내부 시스템에 예상치 못한 방식으로 접근할 수 있다는 현실적 판단입니다.

PM이 20년간 사람 조직을 설계하며 알게 된 것이 에이전트 설계에 그대로 적용됩니다. 좋은 팀원 한 명은 신뢰로 운영할 수 있습니다. 팀원이 30명이 되면 역할 정의와 권한 매트릭스가 없으면 조직이 돌아가지 않습니다.

에이전트도 같습니다. 한 개는 프롬프트 잘 쓰는 것으로 충분합니다. 열 개부터는 신원, 권한, 종료 조건을 설계하지 않으면 에이전트가 많아질수록 혼란이 비선형으로 증가합니다.

에이전트를 열 개 운영하는 것은 열 배 어려운 게 아닙니다. 설계 레이어 하나가 통째로 빠져 있을 때는 방향이 다른 문제가 됩니다.

운영 중인 에이전트에 신원증명서가 있나요? 권한 범위와 에스컬레이션 조건이 코드가 아니라 선언으로 명시돼 있나요?