도구를 연결하는 것과 도구가 대화하게 만드는 것

에이전트 워크플로우가 프로덕션에서 부딪히는 벽들, 그리고 운영 가능한 에이전트의 조건

로컬에서 잘 돌던 에이전트 워크플로우도 프로덕션에서는 다른 조건을 만난다. 에이전트가 다른 에이전트를 부르는 구조, 도구끼리 주고받는 데이터의 형식, 같은 입력에도 달라지는 실행 결과, 사람 확인 없이 맡겨도 되는 범위는 PoC 단계에서 거의 드러나지 않는다.

이 글은 에이전트 워크플로우를 운영에 올리기 전에 점검해야 할 질문 다섯 가지와 확인 방법을 정리한다. RAG와 에이전트에서 로그 없이 생기는 장애 유형은 4편에서 다뤘다. 이번 글은 그보다 한 단계 위, 에이전트와 도구가 서로 연결되는 지점을 다룬다.

서브에이전트 호출은 환경별로 어떻게 확인하나

서브에이전트 호출은 환경별 호출 성공 여부, 실패 전달, 소요 시간을 점검한다.

• 로컬, 스테이징, 프로덕션에서 호출이 성공하는지 확인한다.
• 각 환경에서 전체 소요 시간을 측정한다.
• 하위 호출의 실패가 상위에 전달되는지 시험한다.

에이전트가 에이전트를 부르면 상태는 누가 갖고 있나

체인 안에서 상태를 누가 보관하는지는 설계 단계에서 먼저 정해야 한다. 단일 에이전트의 도구 호출은 비교적 단순하지만, 에이전트가 에이전트를 부르는 체인에서는 상태 공유 방식이 전체 동작을 좌우한다.

정해 두어야 할 질문은 세 가지다. 멀티턴 대화에서 메인 에이전트가 서브에이전트를 호출할 때, 서브에이전트는 메인의 대화 이력을 얼마나 알아야 하는가. 서브에이전트가 실행 중에 실패하면 메인은 어느 지점부터 다시 시작하는가. 서브에이전트 A의 결과가 서브에이전트 B의 입력이 되면, 그 중간 상태는 누가 갖고 있는가.

이 질문에 답이 없으면 타임아웃 값 하나, 통신 경로 설정 하나, 상태 전달 방식 하나가 체인 전체를 조용히 멈출 수 있다. 상태 관리 방식은 에이전트 프레임워크마다 지원 수준이 다르므로, 깊은 체인을 쓰려면 프레임워크가 어디까지 맡아 주고 어디부터 직접 설계해야 하는지 확인해야 한다.

이렇게 확인한다.

• 서브에이전트에 넘기는 대화 이력의 범위를 정하고, 넘기지 않은 정보 때문에 답이 달라지지 않는지 시험한다.
• 중간 결과를 외부 저장소에 남기는지, 에이전트 내부 메모리에만 두는지 확인한다.
• 서브에이전트 하나를 강제로 실패시켰을 때 메인이 어디서부터 이어 가는지 관찰한다.
• 한 단계의 출력이 다음 단계의 입력으로 넘어갈 때 형식과 필수 값이 정의되어 있는지 본다.

에이전트가 가끔 끝까지 실행하지 않으면 재실행이 답인가

재시도는 실패 원인 확인과 완료 검증을 포함해 설계한다. LLM 기반 에이전트는 같은 프롬프트와 같은 도구 구성에서도 실행이 끝까지 완결된다는 보장이 없다. 온도(temperature)를 0으로 두어도 마찬가지다. NAACL 2025 연구는 어떤 LLM도 완벽한 결정론이나 높은 답변 일관성에 근접하지 못했다고 보고했고, 소형 LLM을 128회 반복한 실험에서는 특정 질문의 오류율이 89%에 달한 경우도 있었다[1].

운영 설계에는 재시도, 자동 검증, 부분 결과 활용을 포함한다. 다음 항목을 확인한다.

• 체크포인트 저장: 단계가 끝날 때마다 중간 결과를 외부 저장소에 남긴다. 앞 단계까지 완료된 결과가 있으면 다음 단계부터 재시작할 수 있다.
• 단계별 완료 검증: 각 단계 출력이 정말 완료된 것인지 별도로 확인한다. 에이전트의 자기 보고를 그대로 믿지 않는다. 벤치마크 대비 프로덕션 신뢰성이 20~40% 과대 추정된다는 연구가 있고, pass@1 기준 60%를 달성한 에이전트도 같은 과제를 여러 번 시도하면 일관성이 25% 수준이라는 측정이 있다[2].
• 복구 절차 명문화: 실패 시 전체를 처음부터 돌리지 않고 마지막 체크포인트 이후부터 재실행하는 것을 표준 절차로 정한다.

재시도를 설계할 때는 재시도 폭주(retry storm)도 막아야 한다. 여러 에이전트가 동시에 실패한 작업을 재시도하면 연쇄 장애로 번진다. 서킷 브레이커, 전체 제한 시간 예산, 요청 단위 상관 ID 로깅이 실용적인 최소 요건이다[3].

이렇게 확인한다.

• 같은 시나리오를 여러 번 반복 실행해 완료율을 잰다. 한 번의 성공으로 판단하지 않는다.
• 단계마다 완료를 확인하는 검증이 있는지, 검증이 에이전트 자기 보고에만 의존하지 않는지 본다.
• 재실행 단위가 전체인지 체크포인트 이후인지 확인한다.
• 재시도 횟수 상한과 대기 시간, 동시 재시도를 막는 장치가 있는지 점검한다.

MCP 서버를 연결하면 도구가 동작한다고 볼 수 있나

MCP 서버가 연결됐다는 사실만으로는 도구가 동작한다고 말할 수 없다. 연결 확인과 응답 형식 호환은 별개의 검증이다.

MCP(Model Context Protocol)는 LLM 에이전트가 외부 도구와 통신하는 표준 방식으로, 2024년 11월 Anthropic이 제안했고 2025년 4월 OpenAI가 채택했다. 2025년 12월에는 Linux Foundation 산하 AAIF(Agentic AI Foundation)로 거버넌스가 이전됐다. Zuplo 보고서는 SDK 월간 다운로드가 9,700만 건 이상이고 PulseMCP 레지스트리에 5,500개 이상의 서버가 등록되어 있다고 전한다[4].

다만 서버 수는 프로덕션 채택의 지표로 보기 어렵다. CData 분석은 원격(Remote) MCP 서버의 증가율을 실제 채택의 더 강한 지표로 읽고, 2025년 5월 이후 약 4배 늘었다고 짚는다[4]. 같은 자료들은 MCP 스펙의 output schema 정의가 느슨해서 구현체, 서버, 버전마다 실제 응답 형식이 조금씩 다를 수 있다는 점을 과제로 지적한다[4]. 에이전트가 기대하는 응답 형식과 서버가 실제로 돌려주는 형식이 어긋나면 연결은 되어 있어도 에이전트는 결과를 도구 응답으로 해석하지 못한다.

도구의 입출력 형식과 인코딩은 연결 테스트로 확인한다.

맞춰야 할 인터페이스	어긋날 때 생기는 일
응답 구조(output shape)	응답을 도구 결과로 해석하지 못함
인코딩	본문을 올바르게 해석하지 못함
에러 응답 구조	실패가 성공처럼 처리되거나 원인이 사라짐
버전별 스펙 차이	업그레이드 뒤 갑자기 형식이 어긋남

이렇게 확인한다.

• 서버를 연결하기 전에 두 쪽의 응답 형식을 나란히 놓고 차이를 비교한다. 연결 뒤 오류로 발견하는 것보다 연결 전에 스키마를 비교하는 편이 빠르다.
• 도구 단독 테스트와 별도로, 도구 A의 출력을 도구 B에 넘기는 연결 테스트를 만든다.
• 연결 테스트에서 입출력 인코딩을 확인한다.
• 서버나 도구의 버전을 올린 뒤에는 응답 형식 비교를 다시 돌린다.

에이전트가 알아서 해도 되는 일은 어디까지인가

외부에 영향을 주는 작업은 승인 대상과 책임자를 업무별로 정한다.

LangGraph 공식 문서의 HITL(Human-in-the-Loop) 설계 원칙은 사람의 개입을 정보가 빠졌거나 모호할 때에 한정하라고 안내한다. 인터럽트 기능으로 실행을 멈췄다가 승인 뒤에 재개하는 동기, 비동기 패턴을 지원한다[5]. 에이전트가 스스로 판단하기 어려운 지점을 식별하도록 설계한다.

사람의 승인이 들어가도 에이전트의 역할은 크게 줄지 않는다. 정보 수집, 데이터 통합, 패턴 감지, 실행 후보 생성은 계속 에이전트가 맡고, 사람은 최종 판단과 맥락 확인에 집중한다. 에이전트의 정확도가 모든 경우에 100%가 아닌 이상, 어디까지 맡길지는 모델 성능이 정하지 않는다. 업무 프로세스와 조직이 감당할 수 있는 리스크 수준이 정한다.

이렇게 확인한다.

• 에이전트가 수행하는 액션을 모두 적고, 되돌릴 수 있는 것과 없는 것으로 나눈다.
• 되돌릴 수 없거나 외부에 영향을 주는 액션에 승인 단계가 있는지 본다.
• 승인 대기 중 제한 시간이 지났을 때의 동작이 정해져 있는지 확인한다.
• 거절 사유가 기록되고 다시 볼 수 있는지 확인한다.

우리 팀의 에이전트 운영은 몇 단계에 와 있나

에이전트 운영 성숙도는 연결, 정합, 신뢰, 자율의 네 단계로 나눠 볼 수 있고, 프로덕션 투입은 세 번째 단계에 도달한 뒤가 안전하다. 많은 팀이 첫 단계에서 에이전트가 작동한다고 판단해 프로덕션에 올리는데, 이때 부딪히는 문제의 대부분은 아래 단계 구분으로 설명된다.

단계	확인하는 것	점검 질문
1. 연결	도구가 호출된다	MCP 등록, API 응답, 기본 도구 호출이 되는가
2. 정합	도구끼리 대화한다	도구 사이 데이터 형식이 맞는가, 체인 전체가 프로덕션 환경에서 제한 시간 안에 끝나는가, 중간에 멈추면 어디서 멈췄는지 알 수 있는가
3. 신뢰	실패해도 복구된다	재시도, 중간 결과 저장, 부분 완료 처리 방식이 있는가
4. 자율	사람이 범위를 정한다	불가역 액션의 승인 구조와 예외 처리 규칙이 있는가

첫 단계는 PoC에서 할 수 있는 수준이다. 두 번째 단계부터가 실제 운영의 시작이고, 로컬에서는 보이지 않는 문제가 여기서 나온다. 세 번째 단계는 에이전트가 완벽하게 작동한다는 전제를 버리고, 실패할 수 있다는 것을 알고 복구하는 설계로 넘어가는 단계다. 네 번째 단계는 기술보다 조직의 준비가 필요하다. 에이전트가 어디까지 자율적으로 움직여도 되는지는 조직의 리스크 허용도와 프로세스 설계가 답한다.

Gartner는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 취소될 것으로 전망했다[6]. 국내에서도 도입 기업의 38.1%가 기대에 못 미친다고 답한 조사가 있다[7]. 단계 구분은 이 전망 속에서 지금 팀의 위치를 가늠하는 용도로 쓴다.

이렇게 확인한다.

• 지금 운영 중이거나 준비 중인 에이전트가 위 표의 어느 단계 질문까지 답할 수 있는지 표시한다.
• 답하지 못한 가장 낮은 단계부터 채운다.
• 세 번째 단계 질문에 답하지 못하면 프로덕션 투입을 미룬다.

업무 시스템까지 이어지는 에이전트는 어떤 범위로 공개됐나

공개된 구축 사례를 보면 에이전트의 범위는 업무별 앱을 여러 개 배포하는 단계에서 여러 시스템을 거쳐 결재까지 이어지는 단계로 넓어지고 있다. 앞의 성숙도 표로 보면 앱 배포는 연결과 정합 단계, 결재 시스템 등록까지 이어지는 흐름은 승인 구조가 필요한 자율 단계에 가깝다.

사례	공개된 범위	관련 단계
오다큐 빌 서비스(일본, 시설관리)	현업 부서와 함께 생성형 AI 앱 160개 이상 배포. 회의록 작성 1시간 이상 → 약 5분[8]	연결·정합
주오 로킨(일본, 금융)	전 직원 약 3,000명이 쓰는 생성형 AI 기반. 생성형 AI 앱·AI 에이전트 100개 이상 기본 탑재[9]	연결·정합
우리투자증권(국내, 증권)	온프레미스 AI 플랫폼 구축 착수 발표. 비개발자용 에이전트 빌더, 명령어 입력 뒤 여러 시스템 데이터 조회 → 보고서 초안 작성 → 결재 시스템 등록까지 진행하는 구조[10]	신뢰·자율

결재 시스템까지 이어지는 구조라면 앞 절의 승인 단계와 체크포인트 설계가 먼저 정해져 있어야 한다. 앱 수를 늘리는 단계와 업무 흐름 전체를 맡기는 단계는 점검할 질문이 다르다.

에이전트 구조는 팀의 단계에 맞춰 어떻게 고르나

구조는 지금 팀이 어느 단계에 있는지를 기준으로 고른다. 복잡한 구조일수록 각 단계에 도달하는 데 시간이 더 걸리고, 두 번째 단계에서 네 번째 단계의 구조를 고르면 복잡도만 높아지고 운영 성숙도는 올라가지 않는다.

구조	복잡도	타임아웃 리스크	상태 관리	적합한 상황
단일 에이전트 + 도구 N개 (1-depth)	낮음	낮음	불필요	단순 질의응답, 단일 출력
메인 + 서브 (2-depth)	보통	보통	부분 필요	병렬 처리, 역할 분리
체인 (3-depth 이상)	높음	매우 높음	필수(복잡)	복잡한 파이프라인, 다단계 의존성
오케스트레이터	매우 높음	극고	필수(난제)	자율 태스크, 동적 서브에이전트 구성

3-depth 이상의 체인은 상태 관리가 필수다. 오케스트레이터와 전문 에이전트 풀을 쓰는 구조는 복잡도 자체는 높지만, 제한 시간을 오케스트레이터 수준에서 관리할 수 있고 외부 상태 저장소로 상태 공유를 명시적으로 설계할 수 있다는 장점이 있다.

이렇게 확인한다.

• 업무에 필요한 최소 깊이를 먼저 정하고, 그보다 깊은 구조는 단계가 올라간 뒤에 검토한다.
• 구조를 한 단계 올리기 전에 앞 장의 단계 질문에 답할 수 있는지 본다.
• 깊이를 늘릴 때마다 체인 전체 소요 시간과 타임아웃을 다시 측정한다.

에이전트 플랫폼에 물어봐야 할 5가지

플랫폼을 평가할 때는 기능 목록보다 아래 다섯 질문의 답을 먼저 확인한다. RAG 플랫폼을 고르는 일반 기준은 엔터프라이즈 RAG 비교 기준에 정리해 두었다.

1. 서브에이전트 체인의 최대 깊이는 몇 단계이고, 단계별 타임아웃은 어떻게 설정하는가? 2-depth와 3-depth는 지원 방식이 다르다. 기본 타임아웃 값과 단계별 독립 설정 여부를 확인한다. 기본값이 짧은 플랫폼에서 3-depth 체인을 돌리면 운영에 들어간 뒤에야 문제를 알게 된다.
2. 도구 사이 입출력 형식이 어긋날 때 플랫폼이 변환 계층을 제공하는가? 응답 구조 불일치는 도구, 서버, 버전마다 생긴다. 매번 파싱 코드를 직접 쓰는 구조라면 도구가 늘어날수록 유지보수가 어려워진다.
3. 에이전트가 중간에 실패했을 때 부분 결과를 보존하고 거기서부터 재시도하는가? 재시도가 처음부터 전체를 다시 도는 방식인지, 체크포인트에서 재시작하는 방식인지에 따라 긴 체인이 마지막 단계에서 실패했을 때의 비용이 크게 달라진다.
4. 사람의 승인 단계를 에이전트 파이프라인에 넣을 수 있는가? 실행을 멈추고 사람이 확인한 뒤 재개하는 흐름, 비동기 승인, 대기 시간 초과 시 기본 동작, 거절 시 분기 처리가 플랫폼 기능인지 직접 구현해야 하는지 확인한다.
5. 프로덕션에서 도구 호출 성공률과 단계별 응답 시간을 볼 수 있는가? 에이전트 모니터링은 체인 전체의 성공과 실패를 추적해야 한다. 어느 단계에서 시간이 초과됐는지, 어느 도구의 응답 형식이 어긋났는지, 재시도가 몇 번 일어났는지 알 수 있어야 한다. 호출은 성공했지만 목표를 달성하지 못한 경우는 일반 에러 지표에 잡히지 않는다[2]. 로그에 드러나지 않는 장애를 점검하는 방법은 4편에 있다.

답이 불명확한 항목은 계약과 PoC에서 확인한다.

5편을 마치며

에이전트를 운영하는 일은 도구와 도구 사이의 보이지 않는 이음새를 하나씩 점검하는 일이다. 체인의 타임아웃, 실행 결과의 비결정성, 응답 형식의 불일치, 자동화할 범위는 모두 PoC에서는 드러나지 않고 프로덕션에서 확인된다.

에이전트 운영 성숙도 네 단계(연결, 정합, 신뢰, 자율) 가운데 지금 팀이 어디에 있는지 답하는 것이 에이전트를 프로덕션에 올릴 시점을 가늠하는 출발점이다.

다음 편 예고: 다음 글에서는 PoC가 끝나고 운영을 넘겨받은 뒤에 점검해야 할 것들을 6편에서 다룬다.

올거나이즈는 온프레미스 AI의 도입 검토부터 운영 전환까지를 하나의 흐름으로 설계한다. 이 글에서 다룬 점검을 지금 팀이 서 있는 단계부터 함께 진행한다. → 도입·운영 상담 요청하기

출처

1. "Evaluation of LLMs Should Not Ignore Non-Determinism," NAACL 2025, ACL Anthology. greedy sampling 설정에서도 LLM 비결정성 확인; "The Non-Determinism of Small LLMs," arXiv, 2025년 9월. 소형 LLM 128회 반복 실험, 특정 케이스 오류율 89%
2. "How Do LLMs Fail In Agentic Scenarios?," arXiv, 2025년 12월. pass@1 60% 에이전트의 실제 일관성 25%; "ReliabilityBench," arXiv, 2026년 1월. 벤치마크 대비 프로덕션 신뢰성 20-40% 과다 추정
3. "9 Strategies to Ensure Stability in Dynamic Multi-Agent Systems," Galileo AI, 2025. 재시도 스톰: 서킷 브레이커, 하드 타임아웃 예산, 상관 ID 로깅
4. "The State of MCP," Zuplo, 2025-2026. MCP SDK 월간 다운로드 9,700만 건+, PulseMCP 5,500개+ 서버, 도구 과노출·컨텍스트 창 한계 지적; "2026: The Year for Enterprise-Ready MCP Adoption," CData, 2026. Linux Foundation AAIF 이관, 원격 MCP 서버 증가, output schema 느슨한 정의와 구현체별 편차
5. LangGraph 공식 문서, "Human-in-the-Loop (HITL) Architecture," LangChain, 2025. interrupt() 프리미티브, Static/Dynamic Async Interrupt 패턴
6. Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027," 공식 보도자료, 2025-06-25
7. "생성형 AI가 IT 전략을 바꾼다, 2026 IT 전망 조사 결과," CIO Korea (IDG), 2025-2026. 도입 기업 38.1% 기대에 못 미침
8. 올거나이즈 재팬, 오다큐 빌 서비스 도입 사례. 사례 페이지
9. 올거나이즈 재팬, 주오 로킨(중앙노동금고) 도입 사례(2026년 7월 9일 뉴스 릴리스 기반). 사례 페이지
10. 디일렉, "올거나이즈코리아, 우리투자증권 AX 플랫폼 구축", 2026년 1월 12일. 기사