"투자자용 MCP"라는 요청을 6개의 실제 업무로 정의하고 구현하기까지

구체적이지 않은 고객 요청을 실제 납품 가능한 제품으로 전환하는 전 과정을 단독으로 담당했습니다.

“투자자를 위한 MCP 서버를 만들어주세요.”

고객 요청 전문

요청에는 기술 이름은 있었지만 제품은 정의되어 있지 않았습니다. 세 가지 질문에 답해야 했습니다.

1. 투자자는 LLM으로 어떤 업무를 처리하려 하는가?
2. 그중 고객 플랫폼이 보유한 데이터로 지원할 수 있는 업무는 무엇인가?
3. LLM 클라이언트가 고객의 보안 체계를 유지하면서 올바른 회사 데이터에 어떻게 접근할 것인가?

플랫폼 API를 그대로 감싼 범용 MCP 서버를 만들 수도 있었습니다. 하지만 그렇게 만든 도구가 실제 업무를 해결한다는 보장은 없었습니다.

API보다 사용자 업무를 먼저 조사했습니다. VC 투자자 3명을 대상으로 다음을 인터뷰했습니다.

• 반복적으로 수행하는 투자 업무
• 업무에서 LLM을 사용하는 방식
• 플랫폼, 문서, LLM 사이에서 정보를 복사하거나 전달하는 지점
• 포트폴리오, 보고, 펀드, 알림 데이터를 함께 검색해야 하는 질문

이후 각 후보 업무를 고객 플랫폼이 실제로 보유한 데이터와 대조했습니다. 유용해 보이지만 안정적으로 지원할 수 없는 아이디어는 제외하고, 사용자 요구를 구체적인 제품 명세로 전환했습니다.

개발 순서는 API 구현 편의성이 아니라 관찰된 사용자 가치로 결정했습니다. 이후 6개 기능을 모두 완성했습니다.

• Claude나 GPT에서 MCP 서버를 연결해 사용할 때도 고객 로그인과 회사 컨텍스트가 유지되어야 했습니다. 조사에서 확인한 CLI 업무 방식도 포함됩니다.
• MCP 도구 호출에는 일반적인 브라우저 세션이 유지되지 않았습니다.
• 고객의 기존 인증 시스템이 계속 사용자 신원의 기준이 되어야 했습니다.
• 한 명의 투자자가 여러 회사에 소속될 수 있었습니다.
• 모든 도구 호출은 올바른 회사 컨텍스트를 사용하고 회사별 데이터 격리를 유지해야 했습니다.
• 고객 플랫폼에 필요한 데이터가 존재하는 기능만 제품으로 정의할 수 있었습니다.
• 별도 시스템에 포트폴리오 데이터를 복제하지 않고 기존 API와 연동해야 했습니다.

이 과정이 프로젝트에서 가장 어려운 통합 문제였습니다. 6개 기능이 유용하더라도 인증이나 회사 컨텍스트가 신뢰할 수 없다면 제품 전체가 작동하지 않습니다.

사용자가 가장 먼저 필요하다고 답한 보고 자료 수집 현황 기능의 예시입니다. 값은 모두 대체 데이터이며 고객 데이터는 포함되어 있지 않습니다.

같은 요청이라도 회사 컨텍스트가 다르면 다른 결과가 반환되며, 두 회사가 함께 반환되는 경우는 없습니다. 회사 격리는 응답을 잘라내는 방식이 아니라 API로 가는 경로에서 적용됩니다.

제품 범위 정의와 서버 구현을 함께 진행했습니다.

1. VC 투자자 3명의 업무와 LLM 사용 방식을 인터뷰했습니다.
2. 후보 업무를 115개 플랫폼 API 및 보유 데이터와 대조했습니다.
3. 6개 기능을 정의하고 사용자 사전 테스트로 우선순위를 정했습니다.
4. Claude / GPT MCP 상호작용 방식과 도구 구성을 명세했습니다.
5. 서버 아키텍처와 고객 인증 연동 구조를 설계했습니다.
6. 사용자 소속 회사 조회와 회사 컨텍스트 전환을 구현했습니다.
7. MCP 서버와 6개 업무별 도구 핸들러를 모두 직접 작성했습니다.
8. 고객 자체 로그인과 다중 회사 컨텍스트 연동을 완성했습니다.
9. 전체 시스템을 테스트하고 2개월 안에 납품했습니다.

고객이 특정 기술을 요청하더라도 제품은 별도로 발견하고 정의해야 합니다. 실제 명세는 사용자의 업무, 플랫폼이 보유한 데이터, 고객이 운영하는 보안 체계가 만나는 지점에서 만들어졌습니다.

기능 목록은 시스템의 일부에 불과했습니다. 인증과 회사 컨텍스트는 모든 업무 결과를 신뢰할 수 있는지를 결정하기 때문에, 처음부터 제품 동작의 일부로 설계해야 했습니다.