왜 지금 로드맵이 폴링을 문제 삼는가
2026년 8월 22일 공개된 새 MCP 로드맵은 다섯 개 우선순위 영역 가운데 첫 번째로 "에이전틱 메시징 프리미티브"를 올렸습니다. 지금까지 MCP 클라이언트는 장기 실행 작업의 진행 상황을 알기 위해 Tasks 확장(SEP-2663)이 제공하는 핸들을 주기적으로 조회하는 폴링 구조에 의존해 왔습니다. 로드맵은 이 구조 대신 서버가 상태 변화를 먼저 알리는 웹훅·채널 방식을 다음 스펙 우선순위로 명시하며, 목표를 "모든 전송 방식에서 유지되는 순서 보장을 갖춘 표준 콜백 메커니즘"으로 못박았습니다.
지난 3월 로드맵 이후 무상태 프로토콜 코어(SEP-2575·SEP-2567), Multi Round-Trip Requests(SEP-2322), 엔터프라이즈 관리형 인가는 이미 안정화 단계에 들어갔습니다. 8월 로드맵이 그 다음 단계로 서버발신 이벤트를 명시했으니, 지금 폴링 기반으로 Tasks를 운영하는 팀이라면 전환 시점보다 먼저 대비 항목을 정리해 두는 편이 유리합니다.
아직 실험 단계라는 표시를 흘려보내면 안 된다
서버발신 이벤트의 실제 작업은 "MCP Triggers & Events Working Group"의 인큐베이션 저장소에서 진행 중입니다. 이 저장소는 스스로를 "탐색적이며 공식 스펙이나 권고를 대표하지 않는다"고 명시하고, 웹훅을 유력한 후보로 제시하면서도 구체 기술 사양은 아직 문서화하지 않았습니다. 리더는 AWS의 Clare Liguori와 Anthropic의 Peter Alexander이며, 범위는 SEP 문서·참조 구현·전송 방식 간 조율로 한정되고 와이어 포맷 변경이나 범용 pub/sub 인프라 구축은 명시적으로 범위 밖에 둡니다.
이 구분이 중요한 이유는 팀의 투자 순서 때문입니다. 아직 확정되지 않은 와이어 포맷을 먼저 구현하려 들면 스펙이 바뀔 때마다 코드를 다시 쓰게 되지만, 수신 측 운영 원칙 — 멱등성, 순서 보정, 장애 시 폴백 — 은 스펙이 바뀌어도 그대로 재사용됩니다. 지금 시점에 팀이 준비할 것은 특정 웹훅 구현체가 아니라 이 세 가지 원칙입니다.
웹훅으로 넘어가기 전에: 순서·중복·장애를 먼저 설계한다
전환 계획은 수치로 시작해야 합니다. 웹훅 파일럿을 붙인 뒤 목표로 삼을 기준은 폴링 대비 API 호출 수 90% 이상 감소, 이벤트 수신부터 처리 완료까지 p95 지연 3초 이내, 중복 이벤트로 인한 재처리율 1% 이하입니다. 이 세 숫자를 먼저 코드로 선언해 두면 파일럿이 끝난 뒤 "느낌상 나아졌다" 대신 통과·중단을 판정할 근거가 생깁니다.
가장 먼저 걸리는 함정은 순서 보장을 미리 가정하는 것입니다. Triggers & Events 워킹그룹 헌장 자체가 "모든 전송 방식에서 유지되는 순서 보장"을 아직 풀지 못한 목표로 적어 두었으므로, stdio와 HTTP 전송이 섞인 배포에서는 이벤트가 발생 순서와 다르게 도착할 수 있습니다. 이벤트마다 시퀀스 번호를 붙이고 클라이언트 쪽에 짧은 재정렬 버퍼를 둬야 나중 이벤트가 먼저 도착해도 상태 머신이 잘못된 전이를 일으키지 않습니다.
두 번째 함정은 정확히 한 번 전달을 가정하는 것입니다. 웹훅은 재시도 특성상 같은 이벤트가 중복 발송될 수 있는데, 이를 그대로 처리하면 알림이 두 번 나가거나 상태가 이중으로 갱신됩니다. 이벤트 ID를 멱등키로 저장해 짧은 시간 창(예: 10분) 안의 중복 수신을 서버 측에서 걸러내는 장치가 웹훅 수신부의 기본값이어야 합니다.
세 번째는 수신 엔드포인트 장애를 전제하지 않는 설계입니다. 웹훅 URL이 잠깐 죽어 있으면 그 사이의 이벤트는 발신 측 재시도가 끝나는 순간 유실됩니다. 전환 초기에는 웹훅과 폴링을 동시에 켜 둔 이중 경로 기간을 두고, 웹훅 실패율이 임계값을 넘으면 자동으로 폴링 주기를 좁혀 격차를 메우는 회로를 넣습니다.
배포 전 시나리오 테스트에는 최소 세 가지를 넣습니다. 수신 엔드포인트를 강제로 30초간 다운시켜 재시도가 실제로 도착하는지, 같은 이벤트를 세 번 연속 보내 중복 처리가 걸러지는지, 시퀀스가 뒤바뀐 두 이벤트를 순서를 바꿔 보내 재정렬 버퍼가 동작하는지입니다. 로그에는 이벤트 ID·시퀀스 번호·수신 시각·전송 방식(webhook/SSE/stdio)·재시도 횟수를 표준 필드로 남기고, 페이로드는 서명 검증(HMAC)과 타임스탬프 윈도우 체크를 기본값으로 걸어 위조 이벤트 주입을 막습니다.
스펙이 아직 인큐베이션 단계이므로 매주 할 일은 거창하지 않습니다. Working Group의 SEP 진행 상황을 주 단위로 확인하고, 파일럿에서 걸린 실패 유형(순서 역전·중복·유실)의 비중을 표로 남겨 스펙 확정 시점에 어느 원칙을 먼저 코드로 승격할지 우선순위를 다시 매깁니다.
바로 쓰는 체크리스트
MCP 로드맵이 예고한 서버발신 이벤트는 아직 와이어 포맷조차 확정되지 않은 인큐베이션 단계입니다. 그렇다고 대비를 미룰 이유는 아닙니다. 폴링 대비 호출 90% 감소·지연 p95 3초·재처리율 1% 이하라는 숫자를 목표로 걸고, 순서 역전·중복 전달·엔드포인트 장애라는 세 가지 실패 패턴에 시퀀스 재정렬·멱등키·이중 경로 폴백을 먼저 구현해 두면, 스펙이 확정된 뒤에는 전송 계층만 웹훅으로 바꿔 끼우면 됩니다.