당신은 노트북에서 멀티 에이전트 시스템 (multi-agent system)을 구축합니다. 몇 개의 에이전트를 프로세스 내 (in-process)에서 연결하고, 이들은 Python 객체나 Rust 채널 (channels)을 통해 상태 (state)를 공유하며, 모든 것이 잘 작동합니다. 테스트도 통과합니다. 지연 시간 (Latency)은 무시할 수 있는 수준입니다. 메시지는 절대 유실되지 않습니다. 데모는 모두를 감동시킵니다.

그런นั้น 이를 여러 머신에 걸쳐 배포합니다. 그리고 localhost에서 완벽하게 작동하던 것들이 미치도록 간헐적이고, 재현하기 어려운 방식으로 실패하기 시작합니다.

문제는 당신의 아키텍처 (architecture)가 아닙니다. 문제는 당신이 인지하지 못했던 채로 내리고 있던 조용한 가정들 (assumptions)입니다. 여기 가장 큰 타격을 주는 가정들이 있습니다.

공유 메모리에 대한 가정 (The Assumption of Shared Memory)

단일 머신에서는 에이전트들이 딕셔너리 (dictionary), 데이터베이스 연결 풀 (database connection pool), 인메모리 큐 (in-memory queue) 등을 통해 아주 쉽게 상태를 공유할 수 있습니다. 두 에이전트는 아무런 고민 없이 동일한 데이터 구조를 읽고 씁니다.

에이전트들이 서로 다른 머신에 거주하는 순간, 그 공유 메모리는 네트워크 호출 (network call)이 됩니다. 모든 읽기, 모든 쓰기, 모든 잠금 (lock)이 그렇게 됩니다. O(1)이었고 로컬이었던 것이 이제는 O(network)가 되며 오류가 발생할 수 있게 됩니다. 당신의 에이전트들은 과거에 나노초 (nanoseconds) 단위로 가져오던 상태를 기다리느라 멈춰 서게 됩니다.

만약 에이전트들이 가변 상태 (mutable state)를 직접 공유한다면, 이 가정이 가장 먼저 무너지게 됩니다.

제로 지연 시간에 대한 가정 (The Assumption of Zero Latency)

에이전트들이 프로세스 내에서 통신할 때, 메시지 왕복 시간 (round trip)은 마이크로초 (microseconds) 단위로 측정됩니다. 당신은 아마 그것에 대해 생각해 본 적조차 없을 것입니다. 타임아웃 (Timeouts)? 굳이 신경 쓸 필요 없습니다. 재시도 (Retries)? 불필요합니다.

머신 간 통신에서는 동일한 왕복 시간이 밀리초 (milliseconds) 단위가 됩니다. 종종 10~100배 더 느려지며, 때로는 그 이상이 되기도 합니다. 더 나쁜 것은 지연 시간이 가변적이라는 점입니다. 캐시 미스 (cache miss), GC 일시 중지 (GC pause), 혼잡한 링크 (congested link) 등 무엇이든 하룻밤 사이에 당신의 p99를 두 배로 만들 수 있습니다.

타이트한 타이밍 (tight timing)에 의존했던 패턴들 — 폴링 루프 (polling loops), 조정된 상태 업데이트 (coordinated state updates), 동기식 핸드오프 (synchronous handoffs) — 이 예측 불가능하게 실패하기 시작합니다. 코드는 변하지 않았습니다. 지연 시간이 변했을 뿐입니다.

신뢰할 수 있는 전달에 대한 가정 (The Assumption of Reliable Delivery)

프로세스 내 메시지 전달 (In-process message passing)은 본질적으로 손실이 없습니다 (lossless). 동일한 프로세스 내의 다른 에이전트에게 메시지를 보내면, 그것은 도착하며, 정확히 한 번 (exactly once) 도착합니다.

여러 머신(Cross-machine)에서는 네트워크가 패킷을 손실시키고, 연결이 초기화되며, 메시지가 중복되어 도착합니다. 또는 시간 초과(timeout)가 이미 발생한 후에 늦게 도착할 수도 있습니다. 이는 재시도 로직(retry logic)이 예상치 못한 중복을 보게 만든다는 것을 의미합니다.

만약 에이전트 오케스트레이션이 전송(send) 행위가 전달(delivery)의 보장이라고 가정한다면, 여러분은 유령 상태(ghost state), 중복 작업(duplicate work), 그리고 새벽 3시에야 프로덕션 환경에서 재현되는 종류의 버그들을 목격하게 될 것입니다.

단일 신뢰 영역(Single Trust Domain)의 가정

모든 에이전트가 같은 머신에서 실행될 때는, 신뢰가 암묵적입니다. 코드가 변수를 읽을 수 있다면, 그것은 권한이 있다는 뜻이며, 이는 운영체제(operating system)의 역할입니다.

여러 머신에 걸쳐서는 암묵적인 신뢰가 존재하지 않습니다. 모든 메시지는 인증(authentication)이 필요합니다: 이 에이전트가 주장하는 그 주체가 맞는지? 모든 메시지는 암호화(encryption)가 필요합니다: 전송 경로상의 누군가가 내용을 읽을 수 있는지? 모든 행위는 권한 부여(authorization)가 필요합니다: 이 에이전트가 해당 엔드포인트(endpoint)를 호출할 권한이 있는지?

이러한 과정을 건너뛰고 자체적으로 '네트워크를 신뢰하라' 접근 방식(private VPC, Tailscale, VPN)을 구현하는 팀들은 결국 두 대의 머신에서는 작동하지만 열 대는커녕 백 대에는 확장되지 않는 설정을 갖게 됩니다. 그 이유는 메시지 형식에 암묵적인 신뢰를 내장했기 때문이지, 전송 계층(transport layer)에 그렇게 하지 않았기 때문입니다.

하드코딩된 주소로의 발견(Discovery) 가정

여러분의 노트북에서는 'localhost:8001'과 'localhost:8002'가 항상 작동합니다. 주소를 하드코딩하는 것은 단일 머신에게는 괜찮습니다.

하지만 여러 머신에 걸쳐서는 IP 주소가 바뀝니다. 컨테이너(Container)는 재시작 시 새로운 IP를 받습니다. 클라우드 인스턴스(Cloud instance)는 교체됩니다. DNS 항목에는 잊어버리기 쉬운 TTL(Time To Live)이 있습니다. 10.0.1.55:9000에 연결하는 여러분의 에이전트는 해당 인스턴스가 재활용되면 조용히 실패합니다.

여러분은 서비스 디스커버리(service discovery)가 필요합니다 — 아니면 서비스 디스커버리보다 더 나은 것이 필요합니다. 내일 바뀔 IP 주소에 의존하지 않고 에이전트들이 서로를 찾을 수 있는 방법이 필요합니다.

처음부터 분산 환경을 고려하여 설계하기

솔직히 말해서, 여러 머신에 걸쳐 작동하는 다중 에이전트 시스템(multi-agent system)을 구축하는 것은 단일 머신에서 작동하는 시스템보다 엄격하게 더 어렵습니다 — 그리고 이 가정들 중 어느 것도 단일 머신 케이스에서는 틀린 것이 아닙니다. 다만 포터블하지 않을 뿐입니다.

실질적인 경로: 설령 한 대의 머신에서 프로토타입을 제작하더라도, 에이전트 통신 계층 (communication layer)은 이미 분산된 환경인 것처럼 구축하십시오. 공유 메모리 (shared memory)가 아닌, 명시적인 직렬화 (serialization)를 포함한 메시지 전달 (message passing) 방식을 사용하십시오. 부분적 장애 (partial failure)를 고려하여 설계하십시오. 타임아웃 (timeouts)과 재시도 (retries) 로직을 실제로 필요로 하기 전에 미리 추가하십시오. 정체성 (identity)과 신뢰 (trust)를 나중에 프로토콜을 재작성해야 하는 사후 고려 사항이 아니라, 처음부터 메시지 엔벨로프 (message envelope)의 일부로 만드십시오.

교차 머신 에이전트 네트워킹 (cross-machine agent networking)을 일급 시민 (first-class concern)으로 다루는 도구들이 존재합니다. 예를 들어, Pilot Protocol은 AI 에이전트를 위해 특별히 설계된 오픈 소스 오버레이 네트워크 (overlay network)입니다. 이 프로토콜은 각 에이전트에게 물리적 IP와 독립적인 영구적인 가상 주소를 부여하고, 홈 라우터나 클라우드 NAT 게이트웨이 뒤에 있는 에이전트도 도달 가능하도록 NAT 트래버설 (NAT traversal)을 처리하며, 피어별 핸드셰이크 신뢰 모델 (per-peer handshake trust model)을 갖춘 암호화된 터널을 제공합니다. 핵심 아이디어는 에이전트가 상대방이 동일한 머신에 있는지, 동일한 클라우드에 있는지, 아니면 다른 대륙에 있는지 신경 쓸 필요가 없어야 한다는 것입니다. 그것은 오케스트레이션 계층 (orchestration layer)의 역할이 아니라 전송 계층 (transport layer)의 역할입니다.

해당 도구를 사용하든 직접 구축하든, 핵심은 자신이 어떤 가정을 하고 있는지, 그리고 그 가정들이 단일 머신에서 여러 머신으로 넘어갈 때 유지될 수 있는지를 조기에 인식하는 것입니다.