Model Context Protocol

8월 초에 직접 운영하던 Rails MCP 서버를 손으로 짠 구현에서 공식 Ruby SDK(mcp gem)로 옮겼다. 이전 작업 자체는 며칠이면 끝날 줄 알았다. 실제로는 옮기는 도중에 SDK가 우리 서버 모양을 다 받아주지 못하는 지점이 하나씩 나왔고, 그걸 우회 코드로 덮을지 업스트림에 올릴지 매번 고민해야 했다. 결과만 보면 두 달 동안 이렇게 됐다. 저장소 번호 종류 결과 modelcontextprotocol/ruby-sdk #493 PR 머지 (8/9) modelcontextprotocol/ruby-sdk #507 이슈 메인테이너가 #509로 구현, v1.3.0 modelcontextprotocol/ruby-sdk #508 이슈 다른 결함으로 재정의돼 #510으로 수정, v1.3.0 modelcontextprotocol/ruby-sdk #489, #491 리뷰 코멘트 머지 순서·에러 모양 결정에 반영 webmachinelearning/awesome-webmcp #19, #20 PR 머지 (webmcp-django, webmcp-go 등재) webmachinelearning/webmcp #234, #331 스펙 논의 진행 중 숫자보다 남기고 싶은 건 과정이다. 같은 “SDK가 이상하다"는 관찰도 어떤 근거를 붙이느냐에 따라 메인테이너 반응이 완전히 달랐다. 그리고 두 번은 공개 스레드에서 내가 틀렸다는 걸 스스로 정정해야 했다. ...

직접 만든 MCP 서버가 이상하게 굴었다. 어떤 클라이언트에서는 잘 붙는데, 어떤 클라이언트에서는 인증이 통째로 날아가고 데모 데이터만 돌아왔다. 처음엔 클라이언트 쪽 문제라고 생각했다. 원인을 좁혀보니 정반대였다. MCP-Protocol-Version 헤더가 오면 서버가 인증 컨텍스트를 버리고 데모 모드로 강등하고 있었다. 헤더가 없을 때만 정상 동작했다. 그런데 스펙은 2025-06-18 부터 클라이언트가 이 헤더를 반드시 보내라고 요구한다. 즉 규격을 제대로 지키는 클라이언트일수록 반드시 실패하는 구조였다. 버그 자체는 몇 줄이면 고쳐진다. 문제는 그다음이었다. 고치려고 스펙을 열어보니 서버가 협상하던 2025-03-26 은 이미 세 리비전 뒤처진 버전이었다. 그사이 MCP 는 initialize 핸드셰이크를 없애고, 세션 헤더를 없애고, 서버가 클라이언트에게 요청을 되쏘는 모델 자체를 폐기했다. 단순 버그 수정이 아니라 어느 리비전을 타깃할지부터 정해야 하는 상황이었다. ...