현장 운영 일정 관리를 위한 원격 MCP 서버 구축 과정

MCP 서버는 단순히 데모에 그치지 않고 실제 업무 흐름을 처리하기 시작할 때 비로소 가치를 발휘합니다. Crisphive에 있어 그 업무 흐름은 바로 현장 운영 일정 관리였습니다. 이는 작업자가 채팅 창에 모든 정보를 일일이 복사해 넣을 필요 없이 작업, 인력, 위치, 일정 가능 여부, 배차 맥락을 확인하는 복잡하고 일상적인 작업입니다. 이 개발 노트는 Crisphive의 원격 MCP 서버 탄생에 관한 이야기입니다. 왜 이 서버를 구축했는지, 어떤 아키텍처를 선택했는지, OAuth를 어떻게 적용했는지, 그리고 Claude Connectors Directory로 나아가는 과정을 어떻게 구상했는지 공유합니다.

배경

현장 운영 일정 관리는 단 한 번의 깔끔한 작업으로 끝나지 않습니다. 배차 담당자는 작업이 준비되었는지 확인하고, 적절한 기술자를 찾으며, 마지막 고객 메시지 이후 변경된 사항을 파악하고, 그 과정에서 새로운 일정 충돌이 발생하지 않도록 조율해야 합니다. 이는 AI 어시스턴트에 단순한 프롬프트 이상의 기능이 필요한 업무 영역입니다. 일정 관리 시스템에 정밀한 질문을 던지고 정확한 답변을 받아올 수 있는 도구가 필요합니다.

따라서 원격 MCP 서버 구축의 목표는 명확했습니다. 일정 관리 제품을 일반적인 채팅 장난감으로 만들지 않으면서, AI 클라이언트가 활용할 수 있는 도구 인터페이스 형태로 일정 관리 기능을 제공하는 것이었습니다. Model Context Protocol을 통해 도구를 정의하고, 연동 구조를 예측 가능하게 유지하며, 어시스턴트 경험을 그 뒤에서 작동하는 운영 시스템과 분리할 수 있었습니다. 프로토콜 기본 정보를 확인하고자 하는 독자분들은 modelcontextprotocol.io에서 프로젝트를 살펴보실 수 있습니다.

이러한 접근 방식 덕분에 일반적인 'MCP 서버 2026' 체크리스트를 무작정 따르는 오를 범하지 않을 수 있었습니다. 우리에게 필요했던 질문은 더 구체적이었습니다. 어시스턴트가 시스템에 직접 문의할 때 더 안전하거나 빨라지는 일정 관리 작업은 무엇인지, 그리고 제품 UI 내에서 사람이 직접 판단을 내려야 하는 작업은 무엇인지 구분하는 것이었습니다.

또한 대상 독자에 대해서도 솔직해져야 했습니다. 개발자와 AI 구축자에게 필요한 것은 MCP 서버 소프트웨어에 대한 영업용 설명이 아닙니다. 그들이 알고 싶은 것은 경계선이 어디에 있는지, 즉 어시스턴트가 호출할 수 있는 영역은 무엇이고, 일정 관리 시스템이 계속 제어권을 갖는 영역은 무엇이며, 모호한 요청이 들어왔을 때 어떤 일이 일어나는지입니다. 이 경계 설정이 전체 개발 과정을 주도했습니다.

작동 방식

아키텍처는 로컬 전용 실험이 아닌 원격 MCP 서버에서 출발합니다. 이 서버는 AI 클라이언트와 Crisphive의 일정 관리 API 사이에 위치합니다. 서버는 도구를 정의하고, 입력을 검증하며, 일정 관리 백엔드를 호출하고, 불필요한 내부 구조를 노출하지 않으면서 유용한 응답을 반환합니다. 즉, 단축키처럼 작동하기보다는 신중하게 범위가 제한된 AI 에이전트 도구 API 역할을 수행합니다.

일정 관리 데이터는 실제 운영 데이터이기 때문에 OAuth 적용이 매우 중요했습니다. 배차 맥락을 읽거나 이에 기반해 작업을 수행하는 커넥터는 자신이 어떤 작업 공간에서 작동하고 있는지, 어떤 권한이 적용되는지 반드시 인지해야 합니다. 원격 서버를 통해 권한 부여 경로를 한곳에서 처리하고, 올바른 계정 맥락을 연결하며, 도구 호출이 출처 불명의 백엔드 트래픽으로 남지 않도록 막을 수 있습니다.

초기 도구 인터페이스는 현장 운영 사용 사례에 밀접하게 맞추어 개발되었습니다. 이는 일반적인 CRUD 방식이 아닌 일정 관리에 특화된 함수 호출 구조를 고민했음을 의미합니다. 유용한 도구는 작업, 일정 가능 여부, 할당, 시간대, 고객 맥락, 배차 제약 조건 등 작업자의 언어로 소통해야 합니다. 이 작업에 가장 적합한 MCP 서버는 가장 많은 도구를 가진 서버가 아니라, 검증할 수 있을 만큼 간결하고 실제 활용이 가능할 만큼 구체적인 도구를 갖춘 서버입니다.

Claude 측 작업 방식은 전체 패키징 방식에 영향을 주었습니다. 제품 변경 사항이 발표되는 공개 Anthropic 뉴스 페이지를 비롯한 Anthropic의 커넥터 생태계를 분석하면서, 상용 커넥터의 가치는 참신함 못지않게 신뢰성으로 평가받는다는 점이 명확해졌습니다. 이에 따라 디렉토리 입점 준비를 출시 당일의 번거로운 작업이 아닌, 제품의 주요 제약 조건으로 다루었습니다.

사용자가 경험하는 것

사용자 경험은 아키텍처보다 훨씬 직관적이고 차분해야 합니다. 배차 담당자가 어떤 도구가 호출되었는지, 또는 원격 MCP 서버가 계정 맥락을 어떻게 처리했는지까지 알 필요는 없습니다. 그저 일정 관련 질문을 던지고, 자신들이 관리하고 있는 현장 운영 현황이 반영된 답변을 얻을 수 있어야 합니다.

소규모 사업장의 경우 이러한 차이는 매우 실질적입니다. 작업자의 이동이 지연되거나, 고객이 더 이른 시간대로 변경을 요청하거나, 관리자가 내일 경로에 작업 하나를 더 추가할 수 있는지 확인하고 싶어 하는 상황을 생각해 볼 수 있습니다. 어시스턴트는 일정 관리 맥락을 안전하게 점검할 수 있는 수단이 있을 때만 도움을 줄 수 있습니다. 이것이 소상공인을 위한 MCP 서버가 적용 범위에 대해 명확한 기준을 가져야 하는 이유입니다. 백엔드에서 처리할 수 있다는 이유만으로 모든 기능을 노출해서는 안 됩니다.

또한 커넥터가 불확실성을 명확히 드러내도록 설계했습니다. 요청 처리에 사람의 판단이 필요하다면 도구 응답에 이를 명시해야 합니다. 일정 변경이 도구가 파악할 수 없는 정책에 의존한다면 작업을 멈추어야 합니다. 이는 개발 과정에서 얻은 매우 유용한 MCP 서버 관련 팁 중 하나입니다. 즉, 성공적인 호출만큼이나 책임감 있는 거절 동작도 세심하게 설계해야 한다는 점입니다.

충실한 문서화 역시 사용자 경험의 일부입니다. Claude 연동과 관련된 세부 구현 내용은 작업자용 워크플로 내부보다는 docs.claude.com에 더 가깝게 작성되어야 합니다. 이러한 영역을 분리해 두면 개발자는 배차 제품을 엔지니어링 콘솔처럼 만들지 않고도 문제를 디버깅할 수 있습니다.

습득한 교훈

첫 번째 교훈은 Model Context Protocol이 제품 의사결정의 절반에 불과하다는 점이었습니다. 나머지 절반은 도구 설계에 있습니다. MCP 서버 예시들을 보면 프로토콜 적용이 쉬워 보일 수 있지만, 현장 운영 일정 관리 분야에서는 더 까다로운 질문을 던지게 됩니다. 무엇을 읽기 전용으로 두고, 무엇을 실행 가능하게 만들며, 제품의 안전성이 검증될 때까지 어떤 작업을 어시스턴트 경로에서 제외할 것인가 하는 점입니다.

두 번째 교훈은 관찰 가능성에서 출발해야 한다는 것이었습니다. 도구 호출에는 어시스턴트 요청, 인증된 작업 공간, 백엔드 호출, 실행 결과를 연결하는 로그가 필요합니다. 이 추적 체계가 없으면 부적절한 응답이 프롬프트, 도구 설명, 일정 관리 API, 혹은 사용자의 표현 방식 중 어디서 비롯되었는지 파악하기 어려워집니다. MCP 서버 품질을 개선하는 방법은 화려한 프롬프트 작성보다 건조하더라도 확실한 추적 로그를 구축하는 데서 시작하는 경우가 많습니다.

세 번째 교훈은 절제였습니다. 커넥터는 인상적인 기능을 갖추는 동시에 취약해질 수 있습니다. 유용해 보이는 모든 아이디어를 무작정 집어넣는 방식을 피했습니다. 대신 일정 관리 업무 흐름을 중심으로 역산하여 각 도구가 실제 배차 담당자가 더 나은 결정을 내리는 데 도움이 되는지 검토했습니다. 이를 통해 모든 기능을 어설프게 감싸는 우를 범하지 않을 수 있었습니다.

마지막 교훈은 기술적이면서도 상업적인 영역이었습니다. MCP 서버 비용은 단순히 호스팅 비용에 그치지 않습니다. 검토 시간, 권한 모델링, 유지보수, 그리고 어시스턴트가 실제 운영 작업에 관여할 때 발생하는 지원 부담이 포함됩니다. 이러한 비용을 아키텍처의 일부로 다룸으로써 보다 현실적인 구축이 가능해졌습니다.

향후 계획

다음 단계는 커넥터의 기능을 과시하는 것이 아니라 신뢰성을 더욱 높이는 것입니다. 이는 일정 관리 업무 흐름에 명확히 도움이 되는 부분으로만 도구 범위를 확장하고, 모호한 요청에 대한 검증을 강화하며, 도구 결과와 작업자의 다음 조치 사이의 피드백 루프를 개선하는 것을 의미합니다.

앞으로의 개선 작업은 단계적으로 진행될 것입니다. 더 명확한 도구 설명 제공, 오류 메시지 개선, 각 도구가 반환할 수 있는 데이터 범위에 대한 엄격한 검토 등이 포함됩니다. 이러한 다듬기 작업은 출시 화면에 화려하게 드러나지 않지만, 커넥터를 단순한 호기심을 넘어 지속적으로 신뢰받는 도구로 만들어 줍니다.

또한 제품 개발 과정 내부에서 활용할 수 있는 더 나은 예시를 구축하고자 합니다. 공개용 홍보나 연출된 데모가 아니라, 배차 담당자가 실제로 어떻게 도움을 요청하고 어시스턴트가 어느 시점에서 멈춰 서야 하는지를 보여주는 내부 MCP 서버 예시를 만드는 것입니다. 이러한 예시야말로 원격 MCP 서버를 단순한 프로토콜 연동에서 현장 운영 업무 흐름의 유용한 일부로 발전시키는 동력이 됩니다.

전반적인 방향성은 분명합니다. AI 구축자들은 앞으로도 어시스턴트를 실제 운영 시스템에 계속 연결할 것입니다. 현장 운영 분야 역시 일정 관리 도구 자체를 만들 때와 동일한 엄격함으로 구축된 커넥터를 누릴 자격이 있습니다. 소형화된 도구, 명시적인 권한, 세심한 로그 기록, 그리고 채팅 인터페이스가 인간의 판단력을 대체할 수 있다는 착각을 배제하는 태도가 필요합니다. 이것이 이 MCP 서버를 단순한 개발 노트에서 실제 실무 도구로 발전시켜 가며 우리가 충족하고자 하는 기준입니다.