아프니까 개발자다 아프니까 개발자다

MCP(Model Context Protocol, AI 모델을 외부 도구·데이터와 잇는 표준 규약)의 원격 트랜스포트는 처음에 HTTP + SSE 조합이었다. 동작은 잘 했다. 그런데 2025년 3월, MCP 명세는 트랜스포트를 Streamable HTTP라는 새 방식으로 갈아탔다. 잘 굴러가던 걸 왜 바꿨을까? 이 글은 그 이유를 따라간다 — 옛 방식이 남긴 어떤 숙제 때문에, Streamable HTTP가 무엇을 어떻게 바꿨고, 그래서 MCP에 무엇이 좋아졌는지를 순서대로 본다.(이 글은 SSE가 무엇이고 MCP가 왜 그걸 골랐는지를 다룬 앞 글의 후속이다. SSE의 기본 — 서버가 HTTP 위에서 클라이언트에게 데이터를 밀어 넣는 단방향 스트림 — 은 안다고 보고 출발한다.)출발점: 잘 돌아가던 두..

음성 챗봇의 첫 인상은 "질문을 끝낸 뒤 첫 음성이 들리기까지 몇 초 걸리느냐"로 결정됩니다. 5초가 넘으면 아이가 화면을 보며 "이거 고장 났어?"라고 물어봅니다. 3초 이하면 자연스러운 대화처럼 느낍니다.그래서 LLM 응답이 끝나기를 기다리지 않고, 토큰이 흐르는 동안 문장 단위로 TTS를 시작하는 패턴을 적용했습니다. 한국어 답변이 5문장이라면 첫 문장이 완성되는 1~2초쯤에 TTS 합성을 시작하고, 사용자는 LLM이 나머지 4문장을 만드는 동안 첫 문장을 듣고 있습니다. 첫 음성까지의 지연이 절반 이하로 줄어듭니다.기본 흐름과 단순한 접근의 한계LLM은 SSE(Server-Sent Events) 같은 스트리밍 채널로 토큰을 한 글자씩 흘려보냅니다. 그걸 받은 클라이언트가 화면에 그대로 찍으면 Ch..

봇 정의를 한 곳(LLM 게이트웨이)에 두고 클라이언트가 헤더 한 줄(X-Bot-ID)로 어떤 봇인지 가리키는 패턴 — 이건 별도 글에서 다뤘습니다. 이번 글은 그 패턴을 받는 쪽 클라이언트의 30줄 구현 이야기입니다.받는 쪽이 해야 할 일이 단순할 것 같지만, 음성 챗봇처럼 SSE 스트리밍을 쓰고 대화 세션이 이어져야 하는 환경에서는 의외로 두 가지 헤더를 동시에 다뤄야 합니다. X-Bot-ID(어떤 봇인가)는 매 요청마다 클라이언트가 주입하고, X-Session-ID(어떤 대화인가)는 처음 한 번 게이트웨이가 발급한 뒤 양방향으로 흐릅니다. 이 두 흐름이 맞물려 있는 30줄짜리 라우터 코드가 어떻게 짜였는지 풀어봅니다.왜 두 헤더인가봇 위임 패턴을 처음 적용하면 머릿속에 그려지는 그림은 단순합니다. ..