당신의 에이전트 데모는 작동하지만, 실제 에이전트는 작동하지 않습니다

대부분의 에이전트 아키텍처(Agent architectures)는 조용히 망가져 있습니다. 단일 턴(single turn), 깔끔한 작업, 즉각적인 응답과 같이 데모에서는 훌륭해 보이지만, 실제적인 무언가를 요청하는 순간 무너져 버립니다. 예를 들어 일주일 치의 보험 청구를 처리하거나, 며칠간의 영업 시퀀스(sales sequence)를 실행하거나, 시간이 일치하지 않는 시스템 간의 데이터를 조정하는 작업 같은 것들 말입니다.

이유는 간단하며, 아무도 이에 대해 이야기하지 않습니다: 대부분의 에이전트는 내부적으로 상태가 없는(stateless) 구조입니다. 이들은 매 상호작용마다 처음부터 컨텍스트(context)를 재구성합니다. 마지막 결정을 합리적으로 만들었던 추론 체인(reasoning chain)은 사라집니다. 미세한 신호(soft signals), 신뢰도 기울기(confidence gradients), 부분적인 진행 상황도 모두 사라집니다. 당신은 그저 무슨 일이 일어나고 있는지 아는 척하는 예의 바른 LLM(Large Language Model)을 얻게 될 뿐입니다.

Google Cloud의 Addy Osmani와 Shubham Saboo가 이를 해결하기 위한 다섯 가지 패턴을 방금 발표했습니다. 저는 그 내용을 전부 읽었습니다. 실제로 중요한 내용은 다음과 같습니다.

다섯 가지 패턴 (나의 언어로 정리)

1. 체크포인트 및 재개 (Checkpoint-and-Resume). 에이전트를 요청 처리기(request handler)가 아닌, 장기 실행 서버(long-running server)처럼 취급하세요. 매 작업 단위마다 체크포인트를 생성하십시오. 모든 단위마다 하는 것은 낭비이며, 마지막에만 하는 것은 위험합니다. 만약 에이전트가 1,000개 중 201번째 문서에서 멈춘다면, 0이 아닌 201부터 재개해야 합니다. 기사 속 코드 샘플은 매 50개 문서마다 체크포인트를 생성하는데, 이는 합리적인 기본값입니다. 각 작업 단위의 비용에 따라 이를 조정하십시오.

2. 위임된 승인 (Delegated Approval - 형편없지 않은 HITL). 대부분의 인간 참여형(human-in-the-loop, HITL) 설정은 엉망입니다. 상태를 JSON으로 직렬화(serialize)하고, 웹훅(webhook)을 발송한 뒤, 누군가 편지함을 확인하기만을 기도합니다. 몇 시간 뒤에 응답이 오면, 에이전트는 처음부터 다시 역직렬화(deserialize)하고 컨텍스트를 재설정해야 하며, 이는 전체적인 목적을 무색하게 만듭니다. 해결책은 다음과 같습니다: 에이전트를 그 자리에서 일시 정지시키십시오. 전체 실행 상태를 온전하게 유지하십시오. 대기하는 동안 컴퓨팅 자원 소모는 제로(zero)여야 하며, 재개할 때는 1초 미만의 콜드 스타트(cold start)가 이루어져야 합니다. 또한, Slack이나 이메일이 아닌, "입력 필요", "오류", "완료"와 같이 구조화된 편지함 형태의 통합 승인 큐(approval queue)를 구축하십시오.

3. 계층화된 메모리 컨텍스트 (Memory-Layered Context). 장기 메모리 (Long-term memory)와 작업 메모리 (Working memory)를 결합하되, 이를 명확히 구분하여 유지해야 합니다. 장기 메모리는 세션 전반에 걸쳐 축적되는 지식 베이스 (Knowledge base)입니다. 작업 메모리는 저지연 (Low-latency), 고정확도 (High-accuracy)의 '지금 당장'을 위한 메모리입니다. 이는 대부분의 팀이 메모리 드리프트 (Memory drift) 때문에 과소평가하는 패턴입니다. 몇 가지 이례적인 상호작용으로부터

이 기사는 상호 운용성 프로토콜인 A2A와 MCP도 다룹니다. A2A는 에이전트가 다른 에이전트와 대화하는 방식입니다 (에이전트 간 통신을 위한 OpenAPI 사양을 생각하면 됩니다). MCP는 에이전트가 도구 및 데이터와 대화하는 방식입니다. 이들이 결합되면, 별도의 커스텀 통합 협상 없이도 당신의 Python 코디네이터가 Go 전문가에게 작업을 위임할 수 있음을 의미합니다. 각 조직은 자체적인 거버넌스 경계를 유지합니다. 프로토콜은 인터페이스가 되고, 백엔드는 교체 가능해집니다.

나의 견해

제가 강조하고 싶은 부분은 다음과 같습니다: 메모리 드리프트 (Memory drift)는 아무도 충분히 이야기하지 않는 가장 무서운 문제입니다.

모두가 프롬프트 엔지니어링 (Prompt engineering)과 도구 호출 (Tool calling)에 집착하고 있습니다. 하지만 아무도 다음과 같은 질문을 던지지 않습니다: 내 에이전트가 무엇을 '기억'하고 있으며, 그것이 시간이 지남에 따라 어떻게 행동을 변화시키는가? 에이전트가 며칠 또는 몇 주에 걸쳐 경험을 축적하면, 에이전트는 당신이 작성한 코드처럼 행동하기보다 상호작용의 총합처럼 행동하기 시작합니다. 만약 그 상호작용 중 몇 가지가 이상하거나, 예외적이거나, 적대적이었다면 — 당신의 에이전트는 당신이 의도하지 않은 무언가를 조용히 학습하게 된 것입니다.

이것이 바로 거버넌스 (Governance) 요소가 선택 사항이 아닌 이유입니다. 이는 핵심적인 지지 구조입니다. 에이전트의 정체성(Identity), 레지스트리(Registry), 그리고 경계에서의 정책 집행(Policy enforcement)이 필요합니다. 에이전트를 마이크로서비스 (Microservices)처럼 취급하십시오. 결국 그것들이 바로 마이크로서비스이기 때문입니다.

말할 가치가 있는 또 다른 점은, 이 기사에서 제시한 진단 질문이 올바른 방향이라는 것입니다. 당신의 에이전트가 수행해야 하는 중단 없는 가장 긴 작업 단위는 무엇입니까? 만약 그것이 몇 분 단위라면, 장기 실행 에이전트 (Long-running agents)는 필요하지 않습니다. 만약 몇 시간 또는 며칠 단위라면, 이 모든 것이 필요하며 패턴들이 결합됩니다. 컴플라이언스 (Compliance) 시스템은 처리를 위한 체크포인팅 (Checkpointing), 검토 게이트를 위한 위임된 승인 (Delegated approval), 세션 간 지식을 위한 계층형 메모리 (Layered memory), 그리고 전문가들을 조율하기 위한 플릿 오케스트레이션 (Fleet orchestration)을 사용할 수 있습니다.

오늘날 고립된 상태 비저장(Stateless) 에이전트를 구축하는 기업들은 12개월 안에 리팩토링을 해야 할 것입니다. 영속성 (Persistence), 거버넌스, 그리고 상호 운용성을 염두에 두고 구축하는 기업들은 매일 그들의 우위를 복리로 쌓아갈 것입니다.

그것이 베팅의 핵심이며, 옳은 방향입니다.