LLM (Large Language Model)을 사용하여 구축하는 모든 팀은 결국 동일한 벽에 부딪힙니다. 개념 증명 (Proof of Concept, POC)은 아주 아름답게 작동합니다. 단일 도구에 연결된 단일 에이전트가 단일 유형의 질문에 답하고, 리더십 앞에서 시연되어 박수갈채를 받습니다. 그러고 나면 누군가 당연한 다음 질문을 던집니다: "좋습니다, 그럼 이 에이전트 20개를 운영 환경(Production)에서 돌리려면 언제쯤 가능할까요?"

보통 바로 그 지점에서 모든 것이 무너집니다.

모델이 충분히 좋지 않아서가 아닙니다. 선택한 프레임워크(Framework)가 틀렸기 때문도 아닙니다. 에이전트 함대 (Agent Fleet)가 운영 트래픽, 컴플라이언스 (Compliance) 팀, 그리고 실제 비즈니스 데이터와 접촉하며 생존하는 데 실제로 필요한 인프라를 아무도 구축하지 않았기 때문에 무너지는 것입니다.

"에이전트 하나"와 "에이전트 함대" 사이의 간극

만약 당신이 에이전트 하나를 출시해 본 적이 있다면, 그 패턴을 알고 있을 것입니다: 프롬프트 템플릿 (Prompt Template), 몇 가지 도구 호출 (Tool Calls), 아마도 검색을 위한 벡터 스토어 (Vector Store), 그리고 FastAPI 엔드포인트 (Endpoint)로 감싸진 형태 말입니다. 이는 한 팀이 소유한 단일 에이전트에게는 괜찮습니다.

하지만 서로 다른 5개의 팀에서 온 5개의 에이전트가, 5개의 서로 다른 모델을 호출하며, 중복되는 엔터프라이즈 시스템에 접근하는 순간, 프롬프트 엔지니어링 (Prompt Engineering)과는 전혀 상관없는 다른 문제들이 나타나기 시작합니다:

이 에이전트의 운영 환경 배포를 누가 승인했는가? 기록이 남아 있습니까, 아니면 그냥 Slack 스레드에만 있습니까?

에이전트가 고객 데이터에 대해 잘못된 행동을 하면 어떻게 되는가? 사후에 에이전트가 무엇을 왜 했는지 확인할 수 있습니까?

이번 달에 어떤 에이전트가 OpenAI 예산을 다 쓰고 있는가? 단순히 API 키 단위가 아니라 에이전트별로 지출을 할당할 수 있습니까?

이 에이전트가 응답 중에 개인정보(PII)를 유출했는가? 배포 전에 확인되었습니까, 아니면 누군가 불평한 후에야 확인되었습니까?

14번 에이전트가 조용히 성능이 저하되어 3주 동안 아무도 눈치채지 못하는 것을 무엇이 막아줄 수 있는가?

이 중 그 어떤 것도 더 나은 프롬프트로 해결되지 않습니다. 이는 에이전트를 다른 모든 운영 소프트웨어처럼 다룸으로써 해결됩니다: 즉, 라이프사이클 (Lifecycle), 감사 추적 (Audit Trail), 그리고 킬 스위치 (Kill Switch)를 갖추어 다루는 것입니다.

거버넌스 (Governance)는 방해물이 아니라, 확장을 가능하게 하는 요소입니다

엔지니어링 팀 사이에는 "거버넌스 (Governance)"를 제품 출시를 늦추는 관료적 절차(red tape)로 보는 흔한(그리고 이해할 수 있는) 본능이 있습니다. 하지만 실제로 에이전트 시스템(agentic systems)의 경우, 그 반대가 사실인 경향이 있습니다. 거버넌스의 부재가 바로 여러분이 확장할 수 있는 범위를 제한하는 요소입니다.

유용한 사고 모델(mental model)을 하나 제시하자면, 공유된 레지스트리(registry), 공유된 가드레일(guardrails), 그리고 공유된 관측성(observability) 없이 배포되는 모든 에이전트는 복리로 쌓이는 소량의 기술 부채(technical debt)와 같습니다. 통제되지 않은 10개의 에이전트는 1개의 에이전트보다 위험이 10배 높은 것이 아니라, 100개의 에이전트가 가진 위험에 더 가깝습니다. 왜냐하면 실제로 무엇이 실행되고 있는지, 무엇을 건드리고 있는지, 그리고 무엇을 할 수 있도록 허용되었는지에 대해 아무도 완전한 그림을 가지고 있지 않기 때문입니다.

이것이 실제로 어떻게 구현되는지 볼 수 있는 한 가지 방법은 최근 등장하고 있는 기업용 에이전트 관리 플랫폼(enterprise agent management platforms) 카테고리입니다. 이들은 정확히 이 아이디어, 즉 거버넌스를 프로세스의 마지막에 체크하는 항목이 아니라 파이프라인(pipeline)의 일부로 보는 개념을 중심으로 구축되었습니다. 구체적으로 이는 에이전트가 승인 게이트(approval gates)가 있는 정의된 개발(Dev), QA, 운영(Production) 단계를 거치며 이동하고, 에이전트가 내리는 모든 결정이 변경 불가능한 감사 로그(immutable audit log)에 기록되며, 관제탑 스타일의 대시보드가 무엇이 배포되었는지, 비용이 얼마나 발생하는지를 보여주고, 무언가 오작동하기 시작할 때 운영자에게 킬스위치(killswitch)를 제공한다는 것을 의미합니다. 이는 여러분이 플랫폼을 채택하든 혹은 그에 상응하는 것을 사내에서 직접 구축하든 관계없이, "생명주기에 내장된 거버넌스"가 시스템으로서 실제로 어떤 모습인지를 보여주는 유용한 참조점이 됩니다.

이러한 생명주기가 실제로 어떤 모습인지 대략적으로 그려보면 다음과 같습니다:

중요한 점은 특정 도구의 이름이 아니라 파이프라인의 형태입니다. 구축(Build), 거버넌스(Govern), 배포(Deploy), 모니터링(Monitor), 반복(Repeat). 만약 현재 여러분의 에이전트 스택에서 이 단계 중 하나라도 빠져 있다면, 대개 그 단계가 여러분을 가장 먼저 곤경에 빠뜨릴 것입니다.

아무도 충분히 이야기하지 않는 컨텍스트(Context) 문제

거버넌스(Governance)보다는 아키텍처(Architecture)에 더 가까운 두 번째 실패 모드가 있습니다. 바로 에이전트가 기업 데이터를 실제로 관통하며 추론(Reasoning)할 수 없는 경우입니다. 그 이유는 데이터가 서로 단절된 12개의 시스템에 흩어져 있고, 그중 절반은 비정형(Unstructured) 데이터이기 때문입니다.

도구(Tool)를 호출할 수 있는 에이전트가 곧 여러분의 비즈니스를 이해하는 에이전트와 같은 것은 아닙니다. 이해를 위해서는 정형 데이터(ERP, CRM, 데이터 웨어하우스), 비정형 데이터(문서, 이메일, 티켓), 그리고 이들 사이의 관계를 조화시켜, LLM이 단순히 파편을 검색(Retrieve)하는 수준을 넘어 실제로 추론할 수 있는 무언가로 만들어주는 시맨틱 레이어(Semantic Layer)가 필요합니다.

이것이 더 성숙한 에이전트 아키텍처에서 전용 시맨틱/컨텍스트 레이어(Semantic/Context Layer)가 수행하는 역할입니다. 이 레이어는 도메인별 온톨로지(Ontology)를 유지하고, 실시간으로 데이터 소스 전반의 컨텍스트를 조립하며, 에이전트가 어떤 시스템을 어떻게 쿼리해야 하는지 정확히 알 필요 없이 의도(Intent)를 표현할 수 있게 해줍니다. 에이전트는 "이 고객의 리스크 프로필이 무엇인가요?"라고 묻기만 하면 됩니다. 해당 정보가 어디에 있는지, 어떻게 결합해야 하는지에 대한 해결 과정은 모든 에이전트의 프롬프트(Prompt)에 하드코딩되는 대신, 하부 레이어에서 자동으로 이루어집니다.

만약 이러한 컨텍스트 레이어 없이 에이전트를 구축하고 있다면, 곧 증상을 목격하게 될 것입니다. 데모 데이터셋에서는 훌륭하게 작동하던 에이전트가 실제의 무질서하고 사일로(Siloed)화된 기업 데이터에 부딪히는 순간 무너져 내리는 모습 말입니다.

첫 번째 에이전트를 넘어 확장하기 전 실무 체크리스트

거버넌스 레이어를 직접 구축하든 플랫폼을 채택하든, 멀티 에이전트 운영 시스템(Multi-agent Production System)으로 나아가고 있다면, 규모를 확장하기 전에 반드시 답해야 할 질문들은 다음과 같습니다.

레지스트리(Registry): 모든 에이전트의 목록, 허용된 작업 범위, 그리고 소유자가 명시된 단일 지점이 있는가?

승인 게이트(Promotion gates): 에이전트가 정의된 승인 단계를 거치지 않고 운영 환경(Production)에 배포될 수 있는가?

감사 추적(Audit trail): 어떤 에이전트의 결정에 대해서든, 6개월이 지난 시점에도 왜 그런 결정이 내려졌는지 재구성할 수 있는가?

기본 설정된 가드레일 (Guardrails by default): 개인정보(PII) 탐지, 콘텐츠 안전성(Content safety), 그리고 컴플라이언스 정책(Compliance policy)이 자동으로 적용되고 있는가, 아니면 각 팀이 이를 일일이 추가해야 하는가?

비용 귀속 (Cost attribution): 단순히 하나의 API 청구서가 아니라, 에이전트와 모델별로 세분화된 지출 내역을 확인할 수 있는가?

킬 스위치 (Kill switch): 만약 에이전트가 새벽 2시에 비정상적인 동작을 시작한다면, 얼마나 빨리 누군가가 이를 중단시킬 수 있는가? 그리고 그 과정에서 별도의 배포(Deploy)가 필요한가?

공유 컨텍스트 (Shared context): 에이전트들이 데이터에 대해 동일한 이해를 바탕으로 추론하고 있는가, 아니면 각 팀이 자신들만의 취약한 통합(Integration) 방식을 유지하고 있는가?

대부분의 팀은 초기 단계에서 이 중 한두 가지 질문에는 "예"라고 답할 수 있습니다. 하지만 일곱 가지 모두에 대해 "예"라고 답할 수 있게 되는 것이야말로 에이전트형 AI (Agentic AI)를 데모 수준에서 지속 가능한 기업용 인프라로 격상시키는 실제 작업입니다. 그리고 이것이 바로 CAMS와 같은 플랫폼들이 모든 팀이 독립적으로 재발명해야 하는 것이 아니라, 즉시 사용할 수 있도록(Out of the box) 제공하기 위해 설계된 바로 그 계층입니다.

맺음말

AI 에이전트를 확장하는 것은 프롬프팅 (Prompting) 문제나 모델의 문제가 아닙니다. 그것은 플랫폼의 문제이며, 소프트웨어 팀들이 이전에 해결해 온 다른 모든 플랫폼 문제와 매우 유사합니다. 즉, 공유 인프라, 공유 관측성 (Observability), 공유 가드레일을 구축하여 개별 팀이 전체 시스템이 통제 불능 상태가 되지 않으면서도 빠르게 움직일 수 있도록 하는 것입니다.

만약 당신의 에이전트 로드맵이 "하나의 에이전트, 하나의 팀"을 넘어선다면, 첫 번째 사고가 발생하여 논의가 강제되기 전, 즉 필요하기 전에 거버넌스 계층 (Governance layer)을 설계할 가치가 있습니다.