AX LABS
← 블로그 에이전트 제품 설계

MRTR은 상태기계로 다뤄야 한다

pause·resume·cancel은 UX가 아니라 실행 계약이다

AX LABS 5분 읽기

현장에서 MCP 기반 에이전트를 붙이면 처음에는 tool call만 보인다. 그런데 실제 업무로 들어가면 바로 막힌다. 결재선이 비어 있다. 삭제 범위 확인이 필요하다. 사용자가 OAuth 화면을 지나와야 한다. 이때 서버가 조용히 실패하거나 모델에게 다시 물어보라고 떠넘기면 운영은 무너진다.

MCP의 MRTR, Multi Round-Trip Request는 이 지점을 다룬다. 서버가 client-initiated request 안에서 추가 입력을 요구하고, 클라이언트가 그 응답을 붙여 원 요청을 다시 보낸다. SEP-2322는 이를 InputRequiredResult, inputRequests, inputResponses, requestState로 설명한다. 핵심은 대화가 아니라 실행 재개다.

MRTR의 본질은 pause 가능한 tool call이다

일반 tool call은 한 번 호출하고 한 번 결과를 받는다. 업무 tool은 그렇게 끝나지 않는다. 삭제, 승인, 외부 로그인, 범위 선택, 민감 데이터 확인은 중간 입력을 요구한다.

MRTR을 대화 플로우로 보면 구현이 UI에 갇힌다. 상태기계로 보면 운영 계약이 보인다.

서버는 “지금 멈춘 이유”와 “다시 시작할 최소 상태”를 명시해야 한다.

권장 상태는 단순하다.

상태 의미 MCP 구현 포인트
running 서버가 원 요청 처리 중 tools/call 등 client request 처리
input_required 서버가 멈추고 입력을 요구 InputRequiredResult, inputRequests
resuming 클라이언트가 응답을 붙여 재호출 inputResponses, requestState
completed 최종 결과 반환 기존 result
cancelled 사용자 또는 클라이언트가 종료 Task 기반이면 tasks/cancel
failed 재개 불가 오류 명시적 error와 재시도 정책

이 표가 없으면 팀은 “사용자에게 한 번 더 물어보는 기능”을 만든다. 표가 있으면 재시도, 감사, 타임아웃, 취소, 권한 경계가 설계된다.

ephemeral과 persistent를 섞으면 장애가 난다

MRTR에는 두 가지 운영 감각이 있다. 짧은 중단은 ephemeral로 충분하다. 서버는 requestState를 불투명 문자열로 넘기고, 클라이언트는 해석하지 않고 돌려준다. 로드밸런서가 다른 인스턴스로 보내도 서버가 그 상태를 읽고 이어간다. SEP-2322가 이 문제를 명확히 겨냥한다.

반대로 긴 작업, 외부 job, 배치, 사용자 대기 시간이 긴 승인은 persistent로 빼야 한다. Tasks extension은 task 상태와 input_required, tasks/update, tasks/cancel 흐름을 제공한다. 2026-06-30 계열 설명에서는 과거 실험적 Tasks와 호환되지 않는 변경도 명시되어 있다. 그래서 지금 설계는 “tool call 안에서 버틸 것인가, Task로 승격할 것인가”를 먼저 정해야 한다.

판단 기준은 세 가지다.

  • 사용자가 브라우저를 닫아도 이어가야 하면 Task다.
  • 서버 재배포 중에도 이어가야 하면 requestState 또는 Task가 필요하다.
  • 취소가 실제 외부 작업 중단을 의미하면 Task다.
  • 단순 확인·추가 필드 입력이면 ephemeral MRTR로 충분하다.

cancel은 나중에 붙이는 버튼이 아니다

pause와 resume만 설계한 에이전트는 현장에서 위험하다. 사용자가 “취소”를 누른 뒤 서버가 이미 실행을 계속하면 사고다. 반대로 서버가 아무 일도 하지 않았는데 UI만 취소되면 감사 로그가 빈다.

cancel은 상태 전이다. input_required에서 사용자가 거절하면 cancelled로 끝난다. running에서 긴 작업을 취소해야 하면 Task로 모델링하고 tasks/cancel을 구현한다. ephemeral MRTR에서 취소는 보통 “원 요청을 재시도하지 않음”이다. 이 차이를 문서화해야 한다.

AX Ops 관점에서는 여기서 세 가지 산출물이 필요하다. 상태 전이표, idempotency 규칙, 감사 이벤트 스키마다. 모델 프롬프트보다 이 세 가지가 먼저다. 모델은 결정을 보조하지만, 실행 경계는 상태기계가 지킨다.

참고와 실행 지점은 명확하다

MRTR은 최신 기능을 써보는 문제가 아니다. 서버 주도 elicitation을 운영 가능한 루프로 바꾸는 문제다. 설계 회의의 질문도 바뀌어야 한다. “어떤 화면을 띄울까”가 아니라 “어떤 상태에서 멈추고, 무엇을 받아야 재개하며, 어디서 취소할 것인가”를 물어야 한다.

참고한 1차 출처는 다음이다.

PoC 단계에서는 elicitation이 편의 기능처럼 보인다. 운영 단계에서는 실행 계약이다. MCP MRTR 설계는 상태기계, 취소 정책, 관측 이벤트를 한 묶음으로 잡아야 한다. 이 구조까지 설계하는 팀이 에이전트를 현장 업무에 올린다. 더 깊은 설계 원칙은 AX Ops 방법론 →에서 이어진다.