AI 클라우드 환경에서 에이전틱 AI가 인프라를 스스로 구성하고, 스케일링을 결정하고, 데이터를 삭제하고, 신원을 선택하는 시대가 됐다. 그런데 이 모든 자율 결정의 밑바닥에는 아직 제대로 논의되지 않은 질문이 하나 더 있다. "그 AI는 어떤 방식으로, 어떤 채널을 통해, 어떤 형식으로 다른 시스템과 대화하는가?" 즉, AI 오케스트레이션 에이전트가 런타임에서 스스로 선택하는 통신 프로토콜과 인터페이스 전략의 문제다.

이것이 왜 지금 중요한가? 2026년 현재, 대부분의 기업 AI 클라우드 스택에는 LLM 기반 오케스트레이터가 마이크로서비스, 외부 API, 데이터 파이프라인, 그리고 다른 AI 에이전트들과 실시간으로 통신하고 있다. 그런데 그 통신 방식을 누가 설계했는지, 혹은 AI가 스스로 선택했는지를 명확히 설명할 수 있는 기업은 놀랍도록 드물다.

---

AI 오케스트레이터는 이미 "통신 아키텍처"를 스스로 쓰고 있다

전통적인 클라우드 아키텍처에서 서비스 간 통신 방식은 설계 단계에서 명시적으로 결정됐다. REST냐 gRPC냐, 동기냐 비동기냐, 어떤 메시지 큐를 쓸 것이냐 — 이런 선택들은 아키텍처 문서에 기록되고, 코드 리뷰를 거치고, 변경 관리 프로세스의 승인을 받았다.

에이전틱 AI 시대에는 이 구조가 흔들린다. LangChain, AutoGen, CrewAI 같은 멀티에이전트 프레임워크를 기반으로 구축된 AI 워크플로우는 런타임에서 다음과 같은 결정을 스스로 내린다.

• 어떤 도구(Tool)를 호출할 것인가 — 사전에 정의된 도구 목록 중 어느 것을 선택할지를 LLM이 추론으로 결정
• 어떤 형식으로 페이로드를 구성할 것인가 — 자연어 기반 프롬프트가 구조화된 API 호출로 변환되는 과정에서 스키마 해석이 동적으로 이루어짐
• 재시도 시 동일 채널을 쓸 것인가, 대안 경로를 탐색할 것인가 — 폴백 로직이 에이전트 레이어에 내장되어 있어 라우팅 결정이 투명하지 않음
• 외부 시스템에 어떤 컨텍스트를 전달할 것인가 — 어떤 정보를 포함하고 어떤 정보를 생략할지를 모델이 암묵적으로 판단

이 각각의 결정은 단독으로 보면 작아 보인다. 하지만 이것들이 누적되면 사실상 통신 아키텍처가 런타임에 동적으로 생성되는 것과 같다. 그리고 그 아키텍처를 승인한 사람은 없다.

---

"도구 호출"이라는 이름으로 숨겨진 거버넌스 공백

많은 기업들이 에이전틱 AI의 외부 시스템 호출을 "도구 호출(Tool Calling)"이라는 개념으로 관리한다고 생각한다. OpenAI의 Function Calling이든, Anthropic의 Tool Use든, 이 메커니즘은 LLM이 미리 정의된 함수 목록 중 하나를 선택해 실행하는 방식이다. 얼핏 보면 통제된 환경처럼 보인다.

문제는 "미리 정의된 함수 목록"이 누가, 언제, 어떤 기준으로 만들었는가다.

실제 기업 현장에서는 이 도구 목록이 개발팀이 빠르게 추가한 유틸리티 함수들의 집합인 경우가 많다. 보안 검토를 받지 않은 외부 API 래퍼, 권한 범위가 명시되지 않은 데이터베이스 쿼리 함수, 로깅이 없는 파일 시스템 접근 도구들이 섞여 있다. AI 에이전트는 이 목록을 신뢰하고 자율적으로 선택한다. 하지만 그 선택의 보안 함의를 검토한 인간은 없다.

더 심각한 것은 멀티에이전트 환경에서의 에이전트 간 통신이다. 오케스트레이터 에이전트가 서브에이전트를 호출할 때, 그 호출 방식과 전달되는 컨텍스트의 범위는 프레임워크의 기본값을 따른다. NIST의 AI 리스크 관리 프레임워크(AI RMF)는 AI 시스템의 신뢰성과 책임성을 확보하기 위해 설계 단계부터 거버넌스 구조를 내재화할 것을 권고하지만, 런타임 에이전트 통신에 대한 구체적 기준은 아직 산업 전반에 걸쳐 정립되어 있지 않은 것으로 보인다.

---

AI 클라우드에서 "프로토콜 드리프트"가 발생하는 방식

여기서 내가 "프로토콜 드리프트(Protocol Drift)"라고 부르는 현상을 설명할 필요가 있다.

초기에 설계된 AI 클라우드 워크플로우는 특정 통신 패턴을 전제로 한다. 예를 들어, 모든 외부 API 호출은 API 게이트웨이를 통과하고, 모든 에이전트 간 메시지는 특정 메시지 브로커를 통한다는 식의 원칙이다. 그런데 에이전틱 AI 시스템이 운영되면서 다음과 같은 일들이 조용히 일어난다.

1. 모델 업데이트로 인한 도구 선택 패턴 변화 — 동일한 프롬프트에 대해 새 버전의 모델이 다른 도구를 선택하기 시작한다. 이전에는 API A를 호출하던 워크플로우가 이제 API B를 호출한다. 변경 관리 티켓은 없다.

2. 프롬프트 엔지니어링 최적화의 부작용 — 성능 개선을 위해 시스템 프롬프트를 수정했더니, 에이전트가 이전에 사용하지 않던 채널을 통해 데이터를 전송하기 시작한다.

3. 폴백 로직의 암묵적 경로 확장 — 주 채널이 응답하지 않을 때 에이전트가 대안 경로를 탐색하는 과정에서 원래 설계에 없던 외부 엔드포인트에 접근하는 일로 보인다.

4. 컨텍스트 윈도우 관리로 인한 정보 손실 또는 누출 — 긴 대화 컨텍스트를 요약하거나 잘라내는 과정에서 어떤 정보가 다음 에이전트에게 전달되고 어떤 정보가 누락되는지를 아무도 추적하지 않는다.

이 네 가지 현상이 복합적으로 작용하면, 6개월 후의 AI 클라우드 통신 아키텍처는 처음 설계한 것과 상당히 달라져 있을 가능성이 있다. 그리고 그 차이를 인식하는 사람이 조직 내에 없을 수 있다.

---

실무에서 이것이 어떤 문제로 드러나는가

추상적인 이야기처럼 들릴 수 있으니 실제 시나리오로 구체화해보자.

시나리오 1: 규제 감사 대응 실패 금융 서비스 기업이 AI 클라우드 기반 고객 서비스 자동화를 운영 중이다. 감독 기관이 특정 고객 데이터가 어떤 시스템을 거쳐 처리됐는지를 추적하라고 요구한다. 담당 팀은 로그를 뒤지기 시작하지만, AI 에이전트 간 내부 통신 과정에서 어떤 데이터가 어떤 형식으로 전달됐는지에 대한 기록이 없다. 에이전트가 도구를 호출한 기록은 있지만, 그 호출에 담긴 페이로드의 내용과 수신 시스템의 처리 결과를 연결하는 추적 체계가 없다.

시나리오 2: 예상치 못한 외부 데이터 전송 헬스케어 기업의 AI 오케스트레이터가 진단 보조 워크플로우를 실행하는 중, 성능 최적화를 위해 추가된 캐싱 도구가 환자 데이터 일부를 외부 CDN 레이어에 임시 저장하는 결정을 내린다. 이 결정은 에이전트의 폴백 로직에 의해 자동으로 이루어졌고, 개인정보보호 책임자는 이 사실을 감사 과정에서야 알게 된다. GDPR 또는 국내 개인정보보호법 위반 가능성이 생긴다.

시나리오 3: 공급망 AI 통신 오염 제조업체의 AI 클라우드 플랫폼이 협력사의 AI 에이전트와 실시간으로 데이터를 교환한다. 협력사 측 에이전트가 업데이트되면서 통신 스키마가 미묘하게 변경됐고, 우리 측 에이전트는 이를 감지하지 못한 채 잘못 해석된 데이터를 기반으로 의사결정을 내리기 시작한다. 두 시스템 모두 정상 동작 중이라고 보고하지만, 실제 비즈니스 결과는 조용히 왜곡되고 있다.

세 시나리오 모두 공통점이 있다. AI가 통신 방식을 스스로 결정했고, 그 결정을 사전에 승인하거나 사후에 추적할 수 있는 체계가 없었다.

---

AI 클라우드 통신 거버넌스를 위한 실질적 접근

그렇다면 무엇을 해야 하는가? 이 문제는 기술적 솔루션만으로는 해결되지 않는다. 거버넌스 구조와 기술적 통제가 함께 작동해야 한다.

1. 에이전트 통신 경계를 명시적으로 정의하라

에이전틱 AI 워크플로우를 설계할 때 "이 에이전트가 통신할 수 있는 대상과 방식의 허용 범위"를 명시적으로 문서화해야 한다. 단순히 도구 목록을 정의하는 것을 넘어, 각 도구 호출의 허용 페이로드 범위, 전달 가능한 데이터 분류 수준, 그리고 통신 로깅 요구사항을 함께 정의해야 한다. 이것은 전통적인 API 계약(Contract)의 AI 에이전트 버전이다.

2. 에이전트 간 통신을 관찰 가능한(Observable) 레이어로 분리하라

에이전트 내부 로직과 에이전트 간 통신을 분리하여 후자를 독립적으로 모니터링할 수 있는 구조를 만들어야 한다. OpenTelemetry 기반의 분산 추적을 AI 에이전트 통신에 적용하거나, 에이전트 통신 전용 미들웨어 레이어를 두는 방식이 현실적인 접근으로 보인다. 핵심은 에이전트가 무엇을 호출했는지뿐 아니라 어떤 데이터를 담아 호출했는지가 추적 가능해야 한다는 것이다.

3. 프로토콜 드리프트 감지를 자동화하라

모델 버전 업데이트, 프롬프트 변경, 도구 목록 수정이 발생할 때마다 에이전트 통신 패턴이 이전과 달라지는지를 자동으로 감지하는 체계가 필요하다. 이것은 A/B 테스트 방식으로 접근할 수 있다. 변경 전후의 도구 호출 빈도, 페이로드 스키마 분포, 외부 엔드포인트 접근 패턴을 비교하여 유의미한 드리프트가 감지되면 변경 관리 프로세스를 트리거해야 한다.

4. 멀티에이전트 통신에 "최소 컨텍스트 원칙"을 적용하라

보안에서 최소 권한 원칙(Principle of Least Privilege)이 있듯이, 에이전트 간 통신에는 "최소 컨텍스트 원칙(Principle of Least Context)"을 적용해야 한다. 서브에이전트는 자신의 작업을 수행하는 데 필요한 최소한의 컨텍스트만 전달받아야 한다. 이를 위해 에이전트 간 통신 시 컨텍스트 필터링 레이어를 두고, 어떤 정보가 전달됐는지를 감사 가능한 형태로 기록해야 한다.

5. 공급망 AI 통신에 버전 계약을 도입하라

외부 시스템이나 파트너사의 AI 에이전트와 통신하는 경우, 전통적인 API 버전 관리를 넘어 에이전트 통신 프로토콜 버전 계약이 필요하다. 상대방의 에이전트가 업데이트될 때 우리 측에 사전 통보하고, 통신 스키마 변경에 대한 하위 호환성을 보장하는 계약 조항을 포함해야 한다. 이것은 기술적 문제이기 이전에 비즈니스 계약의 문제다.

---

거버넌스의 공백은 결국 책임의 공백이다

이 시리즈에서 계속 다뤄온 주제가 있다. AI 클라우드 환경에서 에이전틱 AI가 내리는 자율적 결정들 — 스케일링, 프로비저닝, 삭제, 신원 선택, 실행 위치 — 각각은 개별적으로 관리 가능해 보이지만, 그것들이 서로 통신하고 조율되는 방식까지 자율화될 때 거버넌스의 공백은 시스템 전체로 확산된다.

통신 프로토콜은 시스템의 신경계다. 어떤 신호가 어디로, 어떤 형식으로 흐르는지를 결정하는 이 레이어가 AI에 의해 동적으로 재구성될 때, 우리는 더 이상 "우리가 설계한 시스템"을 운영하는 것이 아닐 수 있다.

재미있는 비유를 하나 들자면, 이것은 마치 건물의 전기 배선을 스스로 재배치하는 AI 시스템에 "이상 없음" 표시등만 달아놓은 것과 같다. 불이 켜져 있다는 사실이 배선이 안전하다는 증거가 되지는 않는다.

기업의 AI 클라우드 거버넌스 담당자들에게 한 가지 질문을 던지고 싶다. 지금 이 순간, 당신의 AI 에이전트들이 서로 주고받는 메시지의 내용과 경로를 당신은 설명할 수 있는가? 그 답이 "아마도"나 "확인해봐야 할 것 같다"라면, 그것이 바로 시작해야 할 지점이다.

기술이 스스로 통신 방식을 결정하는 시대에, 그 결정에 대한 책임은 여전히 인간에게 있다. AI 클라우드를 도입한 조직이 그 책임을 이행하기 위해서는, 지금 당장 에이전트 통신 거버넌스를 아키텍처 설계의 일급 시민(First-class Citizen)으로 격상시켜야 한다.

---

AI 클라우드 거버넌스와 관련된 더 넓은 기술 생태계의 변화가 궁금하다면, Genesis GMR-001이 이몰라에서 완주하며 자동차 산업의 판을 어떻게 바꾸는지 분석한 글도 참고해볼 만하다. 하드웨어와 소프트웨어, 자율화 기술이 산업 경계를 어떻게 재정의하는지에 대한 맥락이 AI 클라우드 거버넌스 논의와 맞닿아 있기 때문이다.

이 글은 에이전틱 AI가 클라우드 환경에서 에이전트 간 통신 프로토콜을 자율적으로 결정하는 문제, 그리고 그로 인해 발생하는 거버넌스 공백을 다루는 시리즈의 일부입니다.

---

그리고 그 격상은 단순한 기술 정책 업데이트가 아니다. 그것은 조직이 "우리는 AI가 내리는 결정에 대해 설명 책임을 진다"는 선언이며, 그 선언을 뒷받침할 수 있는 구조를 실제로 만들겠다는 의지의 표명이다.

에이전트 통신 거버넌스를 아키텍처의 일급 시민으로 만든다는 것은 구체적으로 무엇을 의미하는가? 세 가지로 정리할 수 있다.

첫째, 설계 단계에서부터 가시성을 확보하라. 에이전트 통신 경로는 사후에 추적하는 것이 아니라, 시스템 설계 단계에서 명시적으로 정의되어야 한다. "이 에이전트는 저 에이전트와 이런 형식으로, 이런 조건에서, 이런 내용을 주고받는다"는 것이 아키텍처 문서에 기록되어야 한다. 나중에 "로그 뒤져봐야 알 것 같다"는 말이 나오는 순간, 이미 거버넌스는 실패한 것이다.

둘째, 통신 이상을 감지하는 독립적 감시 레이어를 두어라. 에이전트 통신 자체를 모니터링하는 시스템이 그 에이전트들과 독립적으로 운영되어야 한다. 감시자가 피감시자와 같은 오케스트레이션 레이어 위에 있다면, 그 감시는 의미가 없다. 마치 피고인이 판사를 겸임하는 법정과 같다.

셋째, 거버넌스 책임자를 기술팀 밖에 두어라. 에이전트 통신 거버넌스의 최종 책임은 엔지니어링 팀만의 문제가 아니다. 법무, 컴플라이언스, 리스크 관리 부서가 에이전트 통신 정책의 수립과 검토에 참여해야 한다. 기술적 결정이 법적·윤리적 결과를 낳는 시대에, 그 결정 과정에 비기술 이해관계자가 없다는 것은 구조적 취약점이다.

---

결론: 신경계를 AI에게 맡기기 전에 물어야 할 것들

이 글에서 다룬 에이전트 간 통신 거버넌스 문제는, 어떤 의미에서 이 시리즈 전체를 관통하는 핵심 질문으로 귀결된다.

"AI가 결정을 내릴 때, 그 결정이 어떤 정보를 바탕으로, 어떤 경로를 통해, 누구의 승인 아래 이루어졌는가?"

스케일링을 결정하든, 프로비저닝을 결정하든, 삭제를 결정하든, 신원을 선택하든 — 모든 에이전틱 AI의 자율 결정은 결국 에이전트 간 통신이라는 신경계를 통해 전달되고 실행된다. 그 신경계가 투명하지 않다면, 그 위에서 내려지는 모든 결정의 거버넌스는 사상누각이다.

2026년 현재, 많은 기업들이 에이전틱 AI를 클라우드 인프라에 적극적으로 통합하고 있다. 그 속도는 놀랍고, 그 효율성은 실질적이다. 하지만 속도와 효율성이 가시성과 책임을 대체할 수는 없다.

AI가 통신 방식을 스스로 결정하는 시대가 이미 왔다. 이제 우리가 결정해야 할 것은, 그 통신의 규칙을 누가 쓰느냐다. 그 답이 "AI가 알아서"가 되어서는 안 된다. 적어도 아직은.

기술은 단순히 기계가 아니라, 인간의 삶을 풍요롭게 하는 도구다. 그리고 도구는 언제나 사용하는 사람의 의도와 책임 위에서 작동해야 한다. 에이전트 통신 거버넌스는 그 책임을 기술적으로 구현하는 첫 번째 관문이다.

---

이 글은 AI 클라우드 거버넌스 시리즈의 일부입니다. 에이전틱 AI가 클라우드 환경에서 내리는 자율적 결정들 — 스케일링, 프로비저닝, 삭제, 신원 선택, 실행 위치, 그리고 이번 글에서 다룬 에이전트 간 통신 — 각각의 거버넌스 공백이 어떻게 연결되는지를 다루고 있습니다. 이전 글들도 함께 읽어보시길 권합니다.