에이전트 3개에서 40개로: 아무도 뭘 하는지 모르는 상황
We went from 3 agents to 40 in four months. Nobody knows what half of them do anymore
핵심 요약
에이전트가 무분별하게 늘어나며 마이크로서비스처럼 관리 불능 상태에 빠진 현상을 경고하고 거버넌스 필요성을 강조함.
- 에이전트 무분별한 확장 — 4개월 만에 3개에서 40개로 늘어나며 관리 체계가 붕괴함.
- 마이크로서비스의 악몽 — 가시성 없는 인프라와 파편화된 도구로 인해 장애 대응이 어려워짐.
- MCP 보안 리스크 — 검증되지 않은 도구 연결로 인한 권한 남용과 데이터 유출 위험이 커짐.
- 거버넌스 도입 필수 — 에이전트 등록제, 중앙 집중식 관리, 작업 로그 기록을 통해 통제력을 회복해야 함.
4개월 전에는 에이전트가 3개였습니다. 코딩 보조, 사고 대응 봇, 배포 도우미였죠. 깔끔하고 관리하기 쉬웠으며 모두가 각자 무슨 일을 하는지 알고 있었습니다.
오늘날 우리는 40개 정도의 에이전트를 가지고 있습니다. "40개 정도"라고 말하는 이유는 솔직히 아무도 정확한 숫자를 모르기 때문입니다. 팀마다 PR 리뷰, 로그 분석, 온콜 요약, 데이터 파이프라인 모니터링, 고객 티켓 라우팅, 문서 업데이트 등을 위해 각자의 에이전트를 만들었습니다.
익숙한 상황인가요? 2018년 마이크로서비스 때 정확히 일어났던 일이니까요. 모두가 "작은 서비스로 쪼개라"는 말을 들었고, 갑자기 200개의 서비스가 생겼지만 서비스 메시도, 소유권 지도도 없었죠. 결국 나쁜 배포 하나가 아무도 존재를 몰랐던 15개의 하위 의존성으로 연쇄 작용을 일으켰습니다.
우리는 지금 에이전트로 똑같은 짓을 하고 있습니다. 다만 몇 가지 면에서 더 나쁩니다.
에이전트는 보이지 않는 인프라입니다
A 마이크로서비스는 적어도 Dockerfile과 CI 파이프라인이 있는 저장소에 존재했습니다. 찾을 수는 있었죠. 우리 에이전트 중 다수는 누군가의 Cursor 설정, Claude Code 세션, 혹은 금요일 오후에 누군가 만든 n8n 워크플로우 안에 살고 있습니다. 레지스트리도, 카탈로그도 없습니다. 그 사람이 휴가를 가면 에이전트는 방치된 채 계속 돌아가거나, 조용히 멈춰서 무언가 고장 날 때까지 아무도 눈치채지 못합니다.
MCP는 "통합"을 "각자 알아서 연결하기"로 만들었습니다
오해하지 마세요. MCP는 이론적으로 훌륭한 아이디어입니다. 도구 접근을 위한 표준 프로토콜이죠. 하지만 실제로는 모든 개발자가 MCP 서버를 통해 원하는 도구에 에이전트를 연결하기 시작했습니다. 한 팀의 에이전트는 프로덕션 데이터베이스에 읽기-쓰기 권한을 가지고 있습니다. 다른 팀의 에이전트는 리뷰 없이 메인 브랜치에 푸시할 수 있습니다. 세 번째 팀의 에이전트는 보안 검토도 안 된 MCP 서버를 통해 고객 데이터를 가져오고 있습니다.
지난주 Nightfall의 2026 AI 에이전트 위험 보고서를 읽었는데, 제가 이미 보고 있던 것을 확인해주더군요. MCP는 자격 증명 확산의 악몽이 되고 있습니다. 도구 오염(Tool poisoning)은 이제 실질적인 공격 벡터입니다. 도구 메타데이터에 악의적인 지침을 심어두면 에이전트는 MCP 서버를 신뢰하기 때문에 그대로 따릅니다. 대부분의 팀은 아직 이 문제조차 생각하지 않고 있습니다.
아마존의 경고
최근 아마존은 일주일 만에 소매 웹사이트에서 6시간 동안의 결제 중단을 포함해 4건의 심각한 사고를 겪었습니다. 근본 원인은 무엇이었을까요? 자체 AI 에이전트들이 오래된 위키 페이지를 기반으로 행동했기 때문입니다. 에이전트가 낡은 문서를 읽고 자신 있게 잘못된 결정을 내렸고, 그 연쇄 작용으로 수백만 명의 결제가 중단되었습니다.
그들은 말 그대로 인간을 다시 루프에 넣고 사이트가 왜 계속 고장 나는지 파악하기 위해 긴급 회의를 열어야 했습니다. 아마존조차 이런 일을 겪는데, 여러분이라고 다를까요?
첫날부터 했어야 했다고 생각하는 것들:
모든 답을 가지고 있지는 않지만, 지금 우리가 도입하고 있는 것들은 다음과 같습니다:
- 실제 에이전트 레지스트리. 모든 에이전트는 소유자, 하는 일, 접근하는 도구, 수명 주기 상태를 가집니다. 이 정보가 없으면 종료됩니다.
- 중앙 집중식 MCP 거버넌스. 개별 개발자가 프로덕션 시스템에 MCP 연결을 마음대로 하는 것은 금지입니다. 모든 MCP 서버는 검토되고 범위가 지정된 통합 계층을 거쳐야 합니다.
- 결정 추적. 모든 에이전트 작업은 당시의 컨텍스트와 함께 기록됩니다. 무언가 고장 나면 추측하는 대신 체인을 따라 추적할 수 있습니다.
- 킬 스위치. 토큰 예산을 초과하거나 루프 안에서 N번 이상의 도구 호출을 하는 에이전트는 자동으로 일시 중지됩니다. 토요일 밤에 재시도 루프가 400달러어치 토큰을 태워버린 뒤에 배운 교훈입니다.
아이러니하게도 우리는 복잡성을 줄이려고 에이전트를 도입했습니다. 하지만 결국 복잡성을 더 보기 힘든 곳으로 옮겼을 뿐입니다.


