요약 (TL;DR)

• 에이전트 레지스트리 (Agent Registry)는 조직 내 모든 에이전트에 대한 중앙 집중식 카탈로그입니다. 각 에이전트가 무엇을 하는지, 어떤 도구(Tools)에 접근할 수 있는지, 어떤 버전이 실행 중인지, 소유자가 누구인지, 그리고 어떻게 호출하는지를 관리합니다.
• 이는 Docker 이미지에 대한 컨테이너 레지스트리 (Container Registry)나 마이크로서비스 (Microservices)에 대한 서비스 메시 (Service Mesh)와 같은 역할을 합니다. 즉, 분산된 구성 요소들을 통제 가능하게 만드는 계층입니다.
• 우리는 3개 팀에 걸쳐 14개의 에이전트가 생겼을 때 "우리가 어떤 에이전트를 가지고 있지?"라는 벽에 부딪혔습니다. 그때부터 레지스트리는 있으면 좋은 것이 아니라 반드시 필요한 것이 되었습니다.

에이전트 기반 AI (Agentic AI) 구축을 시작한 지 약 4개월이 지났을 때, 보안 책임자가 제가 대답할 수 없는 질문을 던졌습니다: "현재 운영 환경(Production)에서 실행 중인 모든 AI 에이전트 목록과, 그들이 어떤 시스템에 접근 권한을 가지고 있는지, 그리고 각각 현재 배포된 버전이 무엇인지 알려줄 수 있나요?"

저에게는 대략적인 정신적 모델 (Mental model)이 있었습니다. 우리 팀이 구축한 에이전트들에 대해서는 알고 있었습니다. 데이터 엔지니어링 팀이 무엇을 출시했는지에 대해서도 막연하게나마 알고 있었습니다. 제품 팀은 최근 제가 건너 건너 들었던 두 개의 에이전트를 추가한 상태였습니다.

저는 하루의 대부분을 스프레드시트를 정리하는 데 보냈습니다. 제가 작업을 마쳤을 때, 목록에 적어둔 에이전트 중 하나는 이미 더 새로운 버전으로 교체된 상태였습니다. 그중 두 개는 제가 알지 못했던 내부 API에 대한 접근 권한을 이미 부여받은 상태였습니다.

스프레드시트는 제가 전송하기도 전에 이미 구식이 되어버렸습니다.

그 사건은 우리가 제대로 된 에이전트 레지스트리 (Agent registry)를 구축하게 만든 강제적인 계기 (Forcing function)가 되었습니다. 이 포스트는 제가 그 대화가 일어나기 전에 읽었더라면 좋았을 내용입니다.

에이전트 레지스트리란 무엇인가

에이전트 레지스트리 (Agent registry)는 AI 에이전트의 중앙 집중식 카탈로그입니다. 조직 내에 배포된 모든 에이전트의 기능, 통합 (Integrations), 소유권 및 현재 상태를 추적하는 단일 진실 공급원 (Single source of truth)입니다.

저에게 와닿았던 비유는 이것입니다: 컨테이너 레지스트리(Container Registry, Docker Hub, ECR, GCR)가 컨테이너 이미지에 대해 하는 역할이 에이전트에게는 바로 이것과 같습니다. 컨테이너가 3개 실행되고 있을 때는 레지스트리가 필요하지 않습니다. 무엇을 가지고 있는지 알고 있으니까요. 하지만 6개 팀에 걸쳐 40개의 컨테이너가 있다면, 무엇이 실행 중인지, 누가 소유하고 있는지, 어떤 버전이 배포되었는지, 그리고 무엇이 무엇에 의존하고 있는지를 알기 위해 레지스트리가 필요합니다.

에이전트도 마찬가지입니다. 에이전트가 2~3개일 때는 공유된 Notion 문서로 충분합니다. 하지만 3개 팀에 걸쳐 14개의 에이전트가 있다면, 누군가 지난달에 마지막으로 편집한 문서가 아니라 상태(State)를 추적하는 인프라가 필요합니다.

레지스트리는 각 에이전트에 대한 메타데이터(Metadata)를 저장합니다:

• 정체성 및 소유권 (Identity and ownership) — 어떤 팀이 구축했는지, 현재 소유자는 누구인지, 정식 명칭(Canonical name)은 무엇인지
• 역량 (Capabilities) — 에이전트가 무엇을 할 수 있는지, 표준 인터페이스로 표현됨 (점점 더 Model Context Protocol (MCP)을 통해 표현되어, 다른 에이전트들이 커스텀 통합 없이도 이를 발견하고 호출할 수 있게 함)
• 도구 및 모델 액세스 (Tool and model access) — 어떤 MCP 서버를 사용할 권한이 있는지, 어떤 모델을 호출할 수 있는지, 어떤 권한을 보유하고 있는지
• 버전 및 배포 상태 (Version and deployment state) — 현재 프로덕션(Production)에 어떤 버전이 있는지, 무엇이 변경되었는지, 마지막으로 언제 업데이트되었는지
• 관측 가능성 메타데이터 (Observability metadata) — 성공률, 지연 시간(Latency), 마지막 에러, 평가(Evals)를 실행 중이라면 평가 점수
• 액세스 정책 (Access policy) — 어떤 다른 에이전트나 서비스가 이 에이전트를 호출할 권한이 있는지

마지막 항목이 바로 레지스트리를 스프레드시트와 구분 짓는 요소입니다. 레지스트리는 단순한 카탈로그가 아니라, 에이전트 간 통신(Agent-to-agent communication)을 위한 집행 지점(Enforcement point)입니다.

레지스트리 없이 운영할 때 발생하는 문제

우리는 레지스트리 없이 생각보다 오래 운영했습니다. 실제로 무엇이 망가졌는지 알려드리겠습니다.

섀도우 에이전트 (Shadow agents). 세 개의 서로 다른 팀이 내부 데이터 API를 호출하는 에이전트들을 독립적으로 구축했습니다. 그들 중 누구도 서로의 존재를 알지 못했습니다. 우리가 해당 API에 속도 제한 (Rate limits)을 도입했을 때, 두 개의 에이전트가 간헐적으로 실패하기 시작했습니다. 우리는 이것이 데이터 API 문제라고 생각하여 일주일 동안 디버깅을 진행했지만, 실제 문제는 우리가 단 하나의 에이전트만을 위해 할당했던 할당량 (Quota)을 세 개의 에이전트가 서로 경쟁하며 사용하고 있었다는 사실을 깨닫기 전까지였습니다.

새벽 2시의 버전 혼란 (Version confusion at 2am). 버그가 있는 에이전트가 운영 환경 (Production)에 배포되었습니다. 우리는 롤백 (Rollback)을 수행했습니다. 하지만 롤백은 한쪽 환경에는 적용되었으나 다른 쪽에는 적용되지 않았습니다. 어떤 버전이 어디에 있는지에 대한 단일 진실 공급원 (Single source of truth)이 없었기 때문에, 6시간 동안 스테이징 (Staging) 환경에는 수정된 버전이, 운영 환경에는 버그가 있는 버전이 남아 있었습니다. 팀원들이 서로 다른 버전 참조를 보고 있었기 때문에, 이 사고를 해결하는 데 예상보다 훨씬 더 많은 시간이 소요되었습니다.

오프보딩 공백 (The offboarding gap). 엔지니어가 팀을 떠날 때, 우리는 우리가 알고 있는 시스템들에 대한 그들의 자격 증명 (Credentials)을 회수했습니다. 3주 후, 한 계약업체가 그들이 구축한 에이전트로부터 내부 Jira 웹훅 (Webhook)이 여전히 발송되고 있다고 보고했습니다. 해당 에이전트는 어디에도 등록되어 있지 않았습니다. 그 에이전트는 그들이 직접 구축한 인프라 위에서, 아무도 에이전트의 존재를 몰랐기에 오프보딩 체크리스트에 포함되지 않았던 자격 증명을 사용하여 실행되고 있었습니다.

M×N 통합 지옥 (M×N integration hell). 도구 (Tools)를 호출해야 하는 각 새로운 에이전트는 각 도구에 대한 자체적인 통합 (Integration)을 구축해야 했습니다. 8개의 에이전트와 6개의 도구가 있다면, 각각 고유한 자격 증명 관리, 에러 처리 (Error handling), 재시도 로직 (Retry logic)을 가진 48개의 잠재적 통합 지점이 발생합니다. 도구 API가 변경될 때마다, 우리는 해당 도구를 사용하는 모든 에이전트를 수동으로 찾아 업데이트해야 했습니다.

레지스트리는 이 네 가지 문제를 모두 해결합니다. 등록이 배포의 전제 조건이 된다면 섀도우 에이전트는 존재할 수 없습니다. 버전 상태는 중앙에서 추적됩니다. 오프보딩은 "레지스트리에서 이 에이전트의 액세스 권한을 취소한다"로 단순화됩니다. M×N 통합은 각 도구가 한 번만 등록되고 각 에이전트가 레지스트리를 가리키는 방식으로 축소됩니다.

레지스트리가 아닌 것

초기에 제가 몇 가지 개념을 혼동했었기에, 이를 명확히 짚고 넘어갈 가치가 있습니다.

배포 플랫폼(Deployment platform)이 아닙니다. 레지스트리는 무엇이 실행되고 있는지를 추적하지만, 에이전트를 직접 실행하지는 않습니다. 배포는 별개의 관심사입니다. 컨테이너 오케스트레이터인 Kubernetes든, 귀하의 팀이 사용하는 무엇이든 말이죠. 레지스트리는 카탈로그(Catalog)이며, 배포는 실행 계층(Execution layer)입니다.

오케스트레이션 프레임워크(Orchestration framework)가 아닙니다. LangGraph, CrewAI, AutoGen 등은 에이전트들이 서로 어떻게 협업하는지를 다룹니다. 레지스트리는 어떤 에이전트가 존재하는지, 그리고 그들이 서로 통신할 권한이 있는지 여부를 다룹니다. 이들은 경쟁 관계가 아니라 상호 보완적인 관계입니다.

MCP 서버 목록이 아닙니다. MCP 서버 레지스트리는 사용 가능한 도구(Tools)를 카탈로그화합니다. 에이전트 레지스트리는 사용 가능한 에이전트(Agents)를 카탈로그화합니다. 둘 다 유용하며, 둘 다 필요합니다. TrueFoundry는 이 둘의 결합을 통합 MCP 및 에이전트 레지스트리(Unified MCP and Agents Registry)라고 부릅니다. 즉, 에이전트가 사용할 수 있는 도구와 에이전트 자체를 모두 확인할 수 있는 단일 장소입니다. 이러한 통합이 중요한 이유는 거버넌스(Governance) 문제가 결국 "어떤 에이전트가 어떤 도구를 호출할 수 있는가"에 관한 것이기 때문입니다. 이 질문에 답하기 위해서는 두 카탈로그가 모두 필요합니다.

단순한 스프레드시트가 아닙니다. 스프레드시트 형태의 에이전트 카탈로그는 스냅샷(Snapshot)에 불과합니다. 제대로 된 레지스트리는 상태 유지(Stateful)가 가능합니다. 즉, 관측성 계층(Observability layer)에 연결되어 지난주의 업데이트된 성능이 아닌 실시간 성능을 보여줍니다. TrueFoundy의 레지스트리가 에이전트의 성공률을 보여줄 때, 이는 수동으로 업데이트된 필드가 아니라 실시간 텔레메트리(Telemetry)에서 데이터를 가져오는 것입니다.

이를 가능하게 하는 아키텍처 패턴

모든 것을 더 깔끔하게 만든 패턴은 다음과 같습니다: 모든 에이전트가 Model Context Protocol (MCP)을 사용하여 게이트웨이(Gateway)에 등록합니다. 일단 등록되면, 해당 에이전트는 시스템 내의 다른 모든 에이전트에게 표준 MCP 엔드포인트(Endpoint)처럼 보이게 됩니다. LangGraph 에이전트, CrewAI 에이전트, 그리고 커스텀 HTTP 서비스 모두 오케스트레이터에게는 동일한 종류의 객체로 나타납니다. 이들은 모두 정의된 스키마(Schema)를 가진 호출 가능한 엔드포인트일 뿐입니다.

이것이 바로 아키텍처 측면에서 M×N 문제를 해결하는 방식입니다. 각 도구(Tool)는 한 번만 등록됩니다. 각 에이전트(Agent)도 한 번만 등록됩니다. 레지스트리(Registry)는 어떤 에이전트가 어떤 도구를 호출할 수 있는지 매핑합니다. 에이전트는 Jira나 Slack, 또는 내부 데이터 API와 직접 통합하는 방법을 알 필요가 없습니다. 에이전트는 레지스트리 엔드포인트를 호출하기만 하면 되며, 레지스트리가 라우팅(Routing), 자격 증명(Credentials), 그리고 액세스 제어(Access Control)를 처리합니다.

중요했던 또 다른 패턴은 액세스 제어 집행 지점(Enforcement Point)으로서의 레지스트리입니다. 이 방식 이전에는 에이전트 간 호출에 대한 액세스 제어가 애플리케이션 코드 내에 존재했습니다. 즉, 각 에이전트가 호출을 수락할지 여부를 스스로 결정했습니다. 들리는 것만큼이나 신뢰도가 낮다는 뜻입니다. 액세스 제어를 레지스트리 계층으로 옮긴다는 것은, 그것이 중앙에서 일관되게 집행되며 각 개별 에이전트의 구현이 올바른지에 의존하지 않음을 의미합니다.

우리가 최종적으로 선택한 것

보안 감사(Security Audit) 사고 이후, 우리는 몇 가지 옵션을 검토했고 TrueFoundry의 Agent Registry를 선택했습니다. 무엇이 중요했는지 구체적으로 설명하겠습니다.

통합된 에이전트 및 MCP 카탈로그. 모든 에이전트와 모든 도구가 한 곳에서 보입니다. 보안 팀이 "어떤 에이전트가 내부 데이터 API에 접근 권한이 있는가?"라고 물었을 때, 답변은 이틀간의 조사 결과가 아니라 쿼리(Query) 한 번으로 나옵니다.

프레임워크에 구애받지 않는 등록(Framework-agnostic registration). 우리는 LangGraph 기반의 에이전트, CrewAI 기반의 에이전트 하나, 그리고 두 개의 커스텀 HTTP 서비스를 보유하고 있습니다. 레지스트리는 표준 등록 인터페이스를 통해 이들 모두를 처리합니다. 일단 등록되면, 에이전트를 구축한 프레임워크가 무엇인지와 관계없이 거버넌스(Governance) 정책이 적용됩니다. 즉, 동일한 RBAC(역할 기반 액세스 제어) 규칙, 동일한 감사 추적(Audit Trail), 동일한 액세스 정책이 적용됩니다.

실시간 성능 추적. 레지스트리는 관측성(Observability) 계층에서 가져온 각 에이전트의 성공률, 평균 지연 시간(Latency), 그리고 마지막 에러를 보여줍니다. 우리는 라우팅 규칙을 설정했습니다. 프로덕션 코드 변경 시, 최신 평가(Eval) 실행에서 성공률이 90%를 초과하는 에이전트로만 라우팅하도록 합니다. 레지스트리는 배포 전 사람이 직접 확인할 필요 없이 이를 자동으로 집행합니다.

MCP를 통한 A2A 통신. 에이전트가 다른 에이전트를 호출해야 할 때, 레지스트리를 거치게 됩니다. 레지스트리는 호출하는 에이전트가 대상 에이전트를 호출할 권한이 있는지 확인하고, 호출을 처리하며, 양쪽 에이전트의 식별 정보(identities)와 함께 상호작용을 기록(log)합니다. 생성된 에이전트가 부여받은 것보다 더 많은 권한을 상속받는 문제인 '과도한 권한을 가진 서브 에이전트(over-privileged sub-agent)' 문제는 레지스트리 계층에서 차단됩니다.

트레이드오프(Tradeoff): TrueFoundry는 Kubernetes-native이므로, 이미 Kubernetes (K8s)를 사용하고 있지 않다면 실제 인프라 투자가 필요합니다. 에이전트 3개를 사용하는 5인 규모의 팀이라면 YAML 파일 하나로도 충분할 것입니다. 저희에게 변곡점은 여러 팀에 걸쳐 컴플라이언스(compliance) 요구 사항이 있는 약 10개의 에이전트가 생겼을 때였습니다.

실제로 레지스트리가 필요한 시점

솔직한 답변은 이렇습니다: 여러분은 레지스트리가 필요하다고 생각하기 전에 이미 필요하며, 레지스트리가 없을 때 비로소 더 일찍 필요했음을 깨닫게 될 것입니다.

몇 가지 구체적인 신호는 다음과 같습니다:

• 여러 사람에게 물어보지 않고서는 "현재 운영 환경(production)에 어떤 에이전트들이 있는가"라는 질문에 답할 수 없다.
• 한 팀이 에이전트를 배포했는데, 체크인(check-in)을 통해서가 아니라 통제 불능의 비용 경고를 통해 그 사실을 알게 된다.
• 엔지니어가 퇴사했는데, 그가 운영하던 에이전트들이 어떤 자격 증명(credentials)을 사용하고 있었는지 모른다는 사실을 깨닫는다.
• 두 팀이 서로의 존재를 몰라서 유사한 기능을 수행하는 에이전트를 각각 구축한다.
• 내부 시스템에 속도 제한(rate limits)이나 액세스 제어(access controls)를 도입하고 싶은데, 얼마나 많은 에이전트가 해당 시스템을 호출하고 있는지 모른다.

만약 이 중 하나라도 귀하의 상황을 설명한다면, 레지스트리에 대한 논의는 이미 늦었습니다. 아직 해당 사항이 없다면, 아마도 오버헤드(overhead)를 감수할 만큼 규모가 크지 않은 상태일 것입니다.

무엇이 여러분을 레지스트리 구축이나 도입으로 이끌었나요? 그리고 현재 여러분의 에이전트 카탈로그(agent catalog)는 어떤 모습인가요? 대부분의 팀이 여전히 스프레드시트 버전을 사용 중인지, 아니면 레지스트리 인프라가 실제로 에이전트 배포 속도를 따라잡았는지 궁금합니다. 댓글로 알려주세요.