에이전트 호출의 생명주기 — 왜 그냥 API 호출로는 안 되나

번역 에이전트에게 일을 맡겼다고 하자. 짧은 문장이면 즉시 답이 온다. 그런데 300쪽짜리 문서라면 어떨까? 처리에 몇 분이 걸린다. 이때 평범한 API 호출처럼 "요청 보내고 응답 올 때까지 기다리기"로 짜면 문제가 생긴다. 연결이 몇 분간 묶여 있어야 하고, 그사이 진행 상황은 깜깜하며, 중간에 연결이 끊기면 처음부터 다시다.

그래서 A2A(Agent2Agent)·ACP(Agent Communication Protocol) 같은 에이전트 협업 프로토콜은 호출을 단순한 요청/응답이 아니라 생명주기를 가진 실행(Run)으로 다룬다. "이게 왜 그냥 REST 호출이 아니라 별도 프로토콜이어야 하는가"라는 질문의 답이 바로 여기에 있다. 이 글은 그 실행의 세 가지 방식 — 동기·비동기·스트리밍 — 하나만 다룬다.

방식 1. 동기 — 기다렸다가 한 번에 받기

동기(synchronous) 호출은 가장 단순하다. 요청을 보내고, 답이 다 만들어질 때까지 그 자리에서 기다렸다가, 완성된 결과를 한 번에 받는다.

다이어그램 설명. 요청 하나에 응답 하나가 오는 가장 익숙한 형태다. "나의 에이전트"가 요청을 보내고 "처리 중" 구간 내내 기다렸다가 완성된 결과를 받는다. 짧은 작업에는 이보다 나은 게 없다 — 코드가 단순하고 이해하기 쉽다. 함정은 작업이 길어질 때다. "처리 중" 구간이 몇 분으로 늘어나면 그동안 연결을 붙잡고 있어야 하고, 진행 상황을 전혀 알 수 없으며, 도중에 끊기면 결과를 통째로 잃는다. 그래서 동기 방식은 빠르게 끝나는 작업 전용이다.

방식 2. 비동기 — 접수증 받고 나중에 확인

오래 걸리는 작업이라면 비동기(asynchronous)가 맞다. 요청을 보내면 상대는 즉시 "접수했습니다"라는 작업 번호(task id)만 돌려주고 연결을 끊는다. 실제 작업은 뒤에서 진행되고, 나는 그 번호로 가끔 "다 됐나요?"를 물어(polling, 폴링) 확인한다.

다이어그램 설명. 핵심은 요청과 결과 수령이 분리됐다는 점이다. "나의 에이전트"는 요청 직후 "접수증(작업 번호)"만 받고 곧장 풀려나, 그동안 다른 일을 할 수 있다. 그러다 원할 때 그 번호로 "다 됐나요?"를 물어 상태(진행 중 40% → 완료)를 확인한다. 동기 방식의 "연결을 몇 분간 묶어 둔다"는 부담이 사라지는 게 가장 큰 이득이다. 대신 트레이드오프가 있다 — 언제 끝날지 모르니 주기적으로 물어봐야 하고, 너무 자주 물으면 낭비, 너무 뜸하면 결과를 늦게 받는다. 이 "얼마나 자주 물을지"의 애매함이 다음 방식을 부른다.

방식 3. 스트리밍 — 진행되는 대로 계속 흘려받기

스트리밍(streaming)은 폴링의 애매함을 뒤집는다. 내가 물어보는 게 아니라, 상대가 진행 상황을 생기는 대로 계속 밀어 준다. 이걸 가능하게 하는 웹 기술이 SSE(Server-Sent Events) — 하나의 연결을 열어 둔 채 서버가 클라이언트로 여러 개의 업데이트를 순차적으로 흘려보내는 방식이다.

다이어그램 설명. 요청은 한 번인데 응답이 여러 조각으로 이어져 온다. "나의 에이전트"가 물어보지 않아도 "번역 에이전트"가 1장, 2장, 3장을 끝나는 족족 밀어 주고 마지막에 완료 신호를 보낸다. 이 방식의 가치는 두 가지다. 첫째, 사용자에게 진행 상황을 실시간으로 보여줄 수 있다 — 챗봇에서 답변이 한 글자씩 타이핑되듯 나타나는 게 바로 이것이다. 둘째, 오래 걸리는 작업이라도 앞부분부터 곧바로 쓸 수 있어 체감 속도가 빠르다. 폴링처럼 "얼마나 자주 물을지"를 고민할 필요도 없다. 그래서 요즘 에이전트 협업의 기본값은 점점 이 스트리밍 쪽으로 기운다.

정리 — 작업의 길이가 방식을 정한다

세 방식은 우열이 아니라 용도가 다르다. 순식간에 끝나는 일은 동기가 가장 간단하고, 오래 걸리지만 지켜볼 필요 없는 일은 비동기가, 진행 과정을 보여주거나 앞부분부터 써야 하는 일은 스트리밍이 맞다. 에이전트 프로토콜이 이 세 가지를 모두 품는 이유는 결국 하나다 — 에이전트의 일은 "0.1초 만에 끝나는 함수 호출"부터 "몇 분짜리 사고 과정"까지 길이가 천차만별이라, 단순 요청/응답 하나로는 그 폭을 감당할 수 없기 때문이다. 내 에이전트를 남에게 열어 줄 때, 그 작업이 어느 길이에 속하는지부터 정하면 어떤 방식을 지원할지가 저절로 따라온다.

---

참고한 공개 자료:

• Agent Communication Protocol — IBM Research (https://research.ibm.com/projects/agent-communication-protocol)
• What is Agent Communication Protocol (ACP)? — IBM (https://www.ibm.com/think/topics/agent-communication-protocol)
• Server-Sent Events — MDN Web Docs (https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events)

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.