당사 MCP 서버의 구조: OAuth, .well-known 디스커버리 및 툴 설계

MCP OAuth는 스케줄링 대화 내용을 이를 승인하는 사람의 권한과 연결해 줍니다. 50대 이상의 차량을 운용하는 디스패치 연동을 구축하는 개발자라면 첫 번째 작업이 변경되기 전에 이 경계를 유심히 살펴봐야 합니다. Crisphive의 MCP 서버는 디스커버리, 승인, 스케줄링 툴을 단일 연결 내로 가져옵니다. 연결 설정부터 실행까지의 요청 흐름을 따라가 보세요. 클라이언트가 무엇을 탐색하고 누구의 권한을 받는지 확인한 다음, 조치가 성공하거나 중단될 때 디스패치 담당자가 보게 되는 화면을 검토해 보세요.

배경 및 맥락

보조 프로그램이 예약 업무를 돕도록 준비 중인 가상의 지역 디스패치 팀을 생각해 보겠습니다. 개발자는 일반적인 운용을 안정적으로 견디는 연결을 원하고, 디스패치 팀은 보조 프로그램이 어느 사업장에서 작업 중이며 제안된 변경이 실제로 반영되었는지 알고 싶어 합니다. 개발자와 디스패치 관리자가 함께 연결 상태를 검토하도록 하세요.

Crisphive MCP 서버 문서는 https://api.crisphive.com/mcp 에 위치한 호스팅된 원격 서버를 설명합니다. 이 서버는 공개 개발자 API를 Streamable HTTP 상의 툴로 제공합니다. 클라이언트는 OAuth를 통해 연결하거나, 맞춤형 인증 헤더를 지원하는 경우 API 키를 사용할 수 있습니다. 문서화된 스케줄링 경로는 결정론적 솔버(deterministic solver)를 사용하며, 대화 내용은 해당 스케줄링 시스템에 대한 툴 호출로 이어집니다.

연결이 도달해야 하는 사업장과 환경을 확인하는 것부터 검토를 시작하세요. 샌드박스 테스트와 실제 실행 환경에서의 스케줄 변경은 가져오는 결과가 전혀 다릅니다. 에이전시가 테스트 중인 환경이 어디인지, 누가 접근 권한을 승인하는지, 인수인계 후 연결의 소유권은 누구에게 있는지 클라이언트에게 확인하세요. 다음 개발자가 찾을 수 있도록 배포 설정 옆에 답변을 기록해 두세요.

MCP 서버 예시를 검토할 때는 권한 경계를 분명히 설명하는 예시를 우선적으로 선택하세요. 단순히 연결에 성공했다고 해서 운영자가 올바른 접근 권한을 가졌다고 볼 수는 없습니다. 연동의 프로토콜 측면은 Model Context Protocol 참조 문서를 활용하고, 실제 배포 동작은 서버 문서를 기준으로 확인하면 됩니다.

작동 방식

연결은 디스커버리부터 시작됩니다. Crisphive는 /.well-known/oauth-protected-resource에 보호된 리소스 문서를, /.well-known/oauth-authorization-server에 인증 서버 메타데이터를 문서화해 두고 있습니다. 전자는 인증 서버를 식별하고, 후자는 클라이언트에 필요한 엔드포인트를 제공하므로, 클라이언트가 일반 엔드포인트 대신 특정 툴 프로필에 연결할 때 well-known 디스커버리를 직접 검토할 수 있는 설정으로 활용하세요.

문서화된 흐름은 동적 클라이언트 등록, 멤버 승인, 토큰 교환으로 이어집니다. PKCE S256은 필수 사항입니다. PKCE를 사용하면 공개 클라이언트에 공유 시크릿을 제공하지 않고도 승인 흐름이 시작된 클라이언트에 토큰 교환을 바인딩할 수 있습니다. 동의 단계에서 사업장 멤버가 연결을 승인합니다. 이에 따라 발생하는 접근 권한은 해당 멤버의 역할을 따르며, 요청 범위(scope)를 더 좁게 지정할 수도 있습니다.

연동을 승인할 멤버를 결정하세요. 해당 작업에 맞는 권한을 가진 승인 계정을 선택하세요. 먼저 워크플로에 필요한 사항이 무엇인지 결정해야 합니다. 문서에 따르면 토큰은 승인 멤버의 사업장, 지역 및 환경에 바인딩됩니다. 클라이언트가 사용할 예정인 역할로 의도한 접근 권한을 테스트해 보세요.

토큰 갱신 처리 방식도 별도로 점검해야 합니다.

서버는 갱신 시 교체(rotated)된 토큰 쌍을 반환합니다. 다른 작업 프로세스가 연결 갱신을 시도하기 전에 가장 최신의 토큰 쌍을 저장하세요. 별도의 작업에 이전 갱신 토큰을 남겨두지 마세요. Crisphive 문서에 따르면 중복 갱신에 대한 짧은 유예 기간이 지난 후 교체된 토큰이 다시 사용되면 연결이 취소됩니다. 재시도가 무해하다고 가정하지 말고 문서화된 수명주기에 맞추어 복구 로직을 구현하세요.

이어서 MCP 툴 설계를 통해 스케줄링 요청을 처리하게 됩니다. 서버 문서에는 경로, 쿼리, 본문 필드가 하나의 인자(arguments) 객체로 평탄화되어 공개 API 명세로부터 생성된 툴들이 설명되어 있습니다. 함수 호출 스케줄링 작업을 진행할 때는 인자를 전달하기 전에 실제 툴 스키마를 점검하세요. 단순한 AI 에이전트 툴 API 라벨만으로는 어떤 필드가 작업을 식별하는지, 어떤 작업이 변경 사항을 최종 확정하는지 알 수 없습니다.

사용자가 겪는 경험

운영자는 브라우저에서 접근 권한을 승인한 뒤 작업 대화로 돌아옵니다. 이때 화면에 표시되는 설명은 디스패치 현장의 언어를 사용해야 합니다. 어떤 작업인지, 어떤 팀원인지, 무엇이 변경되었는지를 명확히 보여주세요. OAuth 전문 용어는 진단 로그에는 유용하지만, 연결 실패 후 디스패치 관리자가 받게 되는 유일한 설명이 되어서는 안 됩니다.

가상의 긴급 작업 삽입 시나리오라면 대상 후보를 찾는 과정, 재배정 미리보기, 그리고 최종 확정하는 과정을 구별해야 합니다. Crisphive 문서에서는 이를 각각 별개의 작업으로 다룹니다. 구축하는 시스템에서도 이러한 구분을 적용하세요. 관리자가 제안된 변경 사항을 검토할 수 있도록 하고, 어떠한 변경이 확정되기 전에 승인 시점을 명확히 하세요. 미리보기는 어디까지나 제안일 뿐입니다.

중단 상황에 대비하세요.

관리자가 검토 도중에 대화를 벗어날 수 있습니다. 다시 돌아왔을 때 이전 응답으로 무엇이 확정되었는지 파악할 수 있어야 합니다. 변경 사항을 제출한 후 연동이 끊긴 경우, 단순히 자신감 있게 표현된 문장이 작업 성공을 보장해주지 않습니다. 요청을 다시 시도하기 전에 운영자가 스케줄을 확인하고 불확실한 결과를 상급자에게 에스컬레이션할 수 있는 방법을 제공하세요.

클라이언트 설정 역시 담당자가 필요합니다. Claude 연동의 경우 클라이언트 측 안내 사항은 Claude 문서를 참조하세요. 설정 상태는 별도로 확인해야 합니다. 신규 발표 소식은 Anthropic 뉴스 페이지를 확인하세요. 제품 발표 소식이 실제 배포 환경에서 사용하는 연결 설정을 대신해 주지는 않습니다.

소상공인을 위한 MCP OAuth를 조사하는 사람은 승인 멤버 한 명으로 시작할 수 있습니다. 그러나 다중 지점 배포 시에는 각 워크플로별로 의도한 접근 권한을 명시적으로 검토해야 합니다. 대화 내용과 작업 기록 간의 불일치를 조사할 담당자를 포함하여, 실제 디스패치를 책임지는 사람들과 함께 MCP OAuth 예시를 검토하세요.

교훈 및 시사점

권한 경계를 직접 테스트하세요. 단순히 최선의 MCP OAuth 방법을 검색한다고 해서 선택한 역할이 필요한 스케줄링 작업을 수행할 수 있는지 확정할 수는 없습니다. 클라이언트 배포 시 MCP OAuth를 개선하는 방법을 결정하려면, 접근 권한 요구사항을 예상 결과가 포함된 테스트로 전환하세요. 거부 사례(refusal case)도 포함하여 팀이 올바른 권한 제어를 식별할 수 있도록 하세요.

개발 팀과 디스패치 팀이 함께 다음 시나리오들을 수행해 보세요.

• 의도한 멤버 역할로 연결하여 사용 가능한 스케줄링 조치를 확인합니다.
• 의도한 권한을 벗어나는 조치를 요청하고 운영자 화면에 무엇이 보이는지 기록합니다.
• 스케줄링 요청을 중간에 중단한 후, 다시 시도하기 전에 팀이 결과를 확인하는 절차를 정립합니다.
• 연결을 갱신하고 애플리케이션이 새 토큰 쌍을 올바르게 저장하는지 검증합니다.

이 항목들은 제안된 인수 테스트(acceptance test)이며 실제 고객 장애 사례가 아닙니다. 테스트 증적을 연동 설정과 함께 보관하여, 향후 유지보수 담당자가 초기 설계 논의를 다시 파악할 필요 없이 서버가 제공하는 보호 기능과 에이전시가 클라이언트 경험에 반영한 확인 단계를 구별할 수 있도록 하세요.

MCP OAuth 소프트웨어의 경우 지원 소유권(support ownership)도 설정 항목 옆에 함께 명시되어야 합니다. 누가 연결을 재승인할 수 있습니까? 변경되지 않은 것처럼 보이는 작업을 누가 조사합니까? 유용한 MCP OAuth 팁은 담당자와 복구 경로를 통해 이러한 질문에 답을 제시합니다. MCP OAuth 비용 논의 시에는 구축 작업과 지속적인 지원 작업을 구분하세요. 인증 프로토콜 자체가 프로젝트 가격을 결정하지는 않습니다.

Crisphive가 하부 엔진을 제공하는 동안 에이전시는 스케줄링 또는 디스패치 워크플로 구축에 대해 비용을 청구할 수 있습니다. Crisphive 파트너 프로그램에서는 이용 가능한 트랙과 지속적인 상업적 협력 구조를 설명합니다. 귀사의 제공 및 지원 책임에 맞는 트랙을 선택하세요. 그리고 이 경제성을 특정 차량이 절약할 수 있는 시간에 대한 주장과 혼동하지 말고 별개로 유지하세요.

다음 단계

MCP OAuth 2026 구현 검토 시에는 디스패치 팀이 처음부터 끝까지 설명할 수 있는 샌드박스 워크플로를 선택하세요. 의도한 역할로 연결하고, 디스패치를 확인하며, 관련 툴을 통해 하나의 요청을 추적해 보세요. 실제 결과를 예상 결과와 비교하여 기록하세요. 차이가 있다면 접근 권한을 확장하기 전에 해당 차이의 원인을 파악하세요.

공유된 검토 기록에는 멤버 역할과 환경을 명시하고, 제안된 스케줄 변경이 확정되는 시점을 기술해야 합니다. 특히 중단이나 연결 만료 후 팀이 테스트한 복구 단계를 추가하세요. 기존 개발자를 따로 찾지 않더라도 고객 지원 문의를 받는 담당자가 직접 조사할 수 있을 만큼 충분한 세부 정보를 제공하세요.

에이전시가 연동 시스템을 인수인계하기 전에 디스패치 관리자를 인수 테스트에 참여시키세요. 워크플로를 직접 수행하게 하고 마지막 응답이 불확실할 경우 어떻게 대응할지 설명하도록 해보세요. 주저할 때 바로 개입하지 말고 어디서 멈추거나 개발자에게 도움을 요청하는지 관찰하세요. 해당 단계를 보완하고 테스트를 다시 실시한 뒤, 그 결과를 바탕으로 해당 워크플로를 실제 운용 환경으로 전환할지 결정하세요.