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

처음 JSON-RPC 요청을 손으로 만들어 보면 누구나 한 번은 멈칫하는 자리가 있다. id에 1을 적어 넣는 순간이다. "이걸 내가 1로 정해도 되나? 같은 서버에 접속한 다른 클라이언트도 1을 쓰면 응답이 섞이지 않나?" 그럴듯한 걱정이다. 그리고 이 걱정이 어디서 어긋났는지 따라가다 보면 JSON-RPC라는 프로토콜의 설계 의도가 거의 통째로 드러난다.이 글은 그 한 줄짜리 의문에서 출발한다. id는 누가, 어떻게 정하는가? 다른 클라이언트가 같은 id를 쓰면 정말 무슨 일이 벌어지는가? 그리고 보통 어떤 식으로 id를 정하며, 그 선택이 실제로 어떤 문제를 막아 주는지 — 사례 중심으로 풀어 본다.먼저, JSON-RPC 요청 한 개의 생김새JSON-RPC는 "함수 하나를 원격으로 호출하는 약속"을..

MCP(Model Context Protocol, AI 모델과 외부 도구·데이터를 잇는 공개 표준 — 흔히 "AI용 USB-C 포트"라 불린다) 서버를 직접 개발하려고 명세를 펼쳐보면, 와이어 포맷이 두 종류의 약속이 포개진 모양을 하고 있다. 가장 바깥은 JSON-RPC 2.0이라는 호출 규약, 그 안은 MCP가 메서드별로 정한 구조다. inputSchema·content·tools/call 같은 이름이 어느 쪽 약속에 속하는지부터 헷갈리는 게 보통이다. 결론부터 적으면 JSON-RPC는 봉투 6단어만 정의하고, 그 안의 내용물은 전부 MCP가 채운다. MCP를 다루기 전에 그 봉투부터 먼저 짚고 넘어가자 — 이 글은 JSON-RPC 2.0의 봉투 6단어를 MCP 도구 호출 사례로 풀어본다.배경: JS..