MCP 로드맵, 작업·서버 이벤트·HTTP 통합·에이전트 신원 인증을 우선순위로 제시

MCP 카탈로그를 대화 흐름에 따라 조금씩 공개하는 progressive discovery는 너무 늦었음. 여러 하니스에서 이미 MCP 지연 로딩을 직접 구현했고, 이제는 아예 code mode로 옮기는 중임.

나도 code mode가 정확히 뭘 뜻하는지 궁금함.

이 구조는 액터 모델이 떠오름.

에이전트 신원, DPoP, 워크로드 ID 연합, 토큰 교환까지 서버들이 실제로 얼마나 다 구현할지 의문임.

지금도 MCP 서버가 보안 옵션을 전부 직접 구현할 필요는 없음. agentgateway 같은 걸 인증 프록시로 앞에 둘 수 있음.

이건 과설계처럼 보임. 그냥 OAuth를 쓰면 안 되나.

브라우저에서 사람이 매번 승인하는 건 이미 병목임. 진지한 사용자는 점점 못 받아들일 테고, 그 전환 작업도 에이전트가 맡게 될 것 같음.

기존 자격 증명과 RFC 7523, OIDC discovery를 쓰는 흐름과 요청마다 서명 증명을 붙이는 DPoP 흐름이 있음. 둘을 대규모로 같이 쓸 수 있는지, 아니면 DPoP 때문에 갈라질지가 궁금함.

사람 개입을 줄인 완전한 에이전트가 되면 좋겠음. projects.dev 같은 사례도 있고 보안 문제는 많지만 내가 원하는 방향임.

원격 MCP 서버를 일반 HTTP 워크로드처럼 만든 건 잘한 일임. 처음에 별도 프로토콜을 만든 건 꽤 나쁜 선택이었음.

나는 MCP를 한 번도 안 써도 아쉬운 게 없었음. AI 소프트웨어를 만들어도 이 과장된 기술이 왜 필요한지 모르겠음.

개인 금융 앱에 MCP를 붙여 Claude로 테스트했는데, 원예 상담을 하다가 월간 집수리 예산 한도와 은퇴 계획 진척을 함께 알려주더라. 에이전트가 내 맥락을 더 알면 예상 못 한 방식으로 쓸모가 생김.

나도 MCP는 시간 낭비였음. HTTP API와 OpenAPI 명세면 에이전트가 필요한 작업을 다 할 수 있고, 수십 년 쌓인 HTTP 도구와 인프라도 그대로 씀. JSON-RPC POST 전용 구조는 관측과 로깅에 별도 도구가 너무 많이 필요함.

개발자 관점만 보면 그럴 수 있음. 60세 고객이 Claude 스킬을 CLI로 쓰진 않을 테고, 고객 AI가 제품과 상호작용해야 하면 MCP가 가장 현실적인 경로임.

사양이 계속 바뀌면 기존 구현도 계속 고쳐야 함. MCP가 무상태 쪽으로 가는 것 같아 벌써 적응 방법이 걱정되며, 최소 3년 된 기술만 쓰라는 선배들 말을 이제 이해함.

v1에서 MCP를 상태 있게 만든 건 배포에 너무 불리했음. 영속 계층이 필요해졌는데, 결국 OpenSchema API를 AI에 보이게 하는 장치에 가까움.