MCP 구축 상용 겸험 및 이에 필요한 관리 요소 문의 - 구범준 Bro님 행사 사전 질문

Ask a Question
1

구범준님이 이번 “Kubestronaut와 함께하는 커뮤니티 데이” 행사에 사전질문으로 주신 내용을 공유합니다.

  • MCP 구축하여 실제로 적용한 경험이 있으신지 궁금합니다. 실질적으로 어떤 긍정적인 업무 변화가 있었는지 궁금하며 도입 이후에 필요한 관리 요소는 없었을지 궁금합니다.

전문가 Bro님들의 Insight 공유 부탁드립니다.

1 Like
2

제가 소소하게 MCP 를 구축하여 업무에 적용해본 사례입니다.

  1. 개발팀의 디자인 시스템 문서 제공 MCP:
    1. 문제: 개발팀은 Storybook 을 사용하여 디자인 시스템을 문서화하고 있지만 LLM은 Storybook 을 직접 이해하지 못하고, 웹 문서를 매번 읽는것은 여러모로 비효율적인 문제가 있음.
    2. 리서치: context7 과 같은 MCP는 내부 문서를 LLM이 이해할 수 있는 형태로 변환하여 제공하는 기능이 있으나 내부 문서를 임베딩하기 어려운 환경이었음.
    3. 결정: context7 MCP 대신 자체 RAG + MCP 구축으로 context7 과 유사한 구조를 직접 구현하기로 결정. (개발팀 내에서 상당히 효과적인 MCP로 평가됨)
    4. 준비: Storybook 문서(mdx)의 내용을 더 자세한 이용 사례, 인터페이스를 포함하여 풍부하게 보완.
    5. 해결: Storybook 문서(mdx)를 AST 파싱 → 스토리북 코드까지 포함된 Markdown으로 변환 → Markdown 임베딩하여 RAG 구축 → RAG 기반 MCP 구축
    6. 결과: LLM이 디자인 시스템을 이해하여 엉뚱한 인터페이스를 참조하거나 추론하여 코드를 생성하는 문제 해결.
    7. 유지보수 요소: 디자인 시스템 컴포넌트 레포지토리에 임베딩 및 MCP 서버 빌드 자동화 파이프라인 구축하여 별도 관리 없이 최신 문서 반영 가능.
    8. NOTE: 오버 엔지니어링인듯 싶지만 개발 사이클에 잘 녹아들어 동작하는 모습을 보니 좋은 경험이었다고 생각중입니다
  2. Self-hosted/SaaS 플랫폼 Custom MCP 개발:
    1. 문제: LLM 기반 코드리뷰 봇에서 Context 참조를 위해 조회해야 할 플랫폼에서 API만 지원하고 MCP를 제공하지 않음.
    2. 리서치: 자체적으로 MCP를 구축하는 방안과, third-party MCP 솔루션을 검토.
    3. 결정: 유지보수/기능 부족 문제로 자체적으로 MCP 구축하는것이 유리하다고 판단.
    4. 해결: 간단하게 필요한 기능을 모두 포함하는 MCP 서버 개발
    5. 결과: LLM 기반 코드리뷰 봇에서 플랫폼 컨텍스트를 효과적으로 참조하여 Context 확장, 코드리뷰 품질 향상.
    6. 유지보수 요소: 플랫폼 API 변경에 따른 MCP 서버 업데이트 필요 가능성 있음.
    7. NOTE: 자체 MCP 구축은 초기 개발 비용이 들지만, 간단한 경우 프로젝트 설정부터 배포까지 몇시간 이내로 구축 가능하니 앞으로도 활용할 방법인듯 싶습니다.
3 Likes
3

실제 프로젝트에 적용해 운영했던 이력은 없습니다. 다만 관련 도서 1권과 교육 프로그램 1개를 통해 개념과 적용 방향을 학습한 정도이며, 그 범위 안에서 예상되는 변화나 관리 요소를 정리해보면 아래와 같습니다.

우선 MCP를 도입했을 때 가장 먼저 나타날 변화는 도구와 모델 간의 컨텍스트 전달 방식이 일정한 규칙으로 통일된다는 점입니다. 기존에는 솔루션마다 API 활용 방식이나 프롬프트 설계 방식이 제각각이라, 여러 도구를 한 흐름으로 엮을 때마다 어댑터나 중간 계층이 필요했던 것으로 알고 있습니다. MCP는 이러한 ‘각자도생’ 구조를 상당 부분 줄여주기 때문에, 실제 현장에서는 도구 통합과 자동화 흐름이 좀 더 자연스러워질 가능성이 있다고 추정됩니다.

둘째로는 개발자 경험(DX) 개선 효과가 기대됩니다.
MCP를 사용하면 모델이 접근할 수 있는 리소스(파일, 명령, 도구 등)를 표준 스키마로 정의하게 되므로, 개발팀은 도구마다 새로 규칙을 파악할 필요가 줄어들 것 같습니다. 특히 AI 기반 자동화나 문서 생성, 내부 툴 조작 같은 작업에서는 모델이 어떤 정보를 언제, 어떤 방식으로 참고하는지가 더 명확해지기 때문에 업무 흐름이 덜 불투명해지는 효과가 있을 것으로 보입니다.

물론 MCP 도입 이후에는 일정한 관리 부담도 뒤따를 것으로 예상됩니다.

  • 스키마 정의 및 업데이트 작업
    도구가 늘어날수록 MCP 스키마를 지속적으로 정비해야 하고, 버전 관리도 필요할 것 같습니다.

  • 모델 접근 권한의 범위 조정
    MCP는 모델이 접근할 수 있는 정보가 구조적으로 드러나기 때문에, 보안팀이나 운영팀이 접근 범위를 세밀하게 설정해야 할 것 같습니다.

  • 기존 내부 서비스와의 호환성 점검
    이미 구축된 API나 내부 도구를 MCP 형태로 노출하려면 초기 정비가 어느 정도 필요할 것이라고 예상됩니다.

정리하면, MCP는 “지금까지의 AI 통합 방식이 너무 제각각이었다”는 문제를 해결하기 위한 표준화 방향이라는 점에서 의미가 있으며, 도입 시 초기 작업은 다소 있겠지만, 장기적으로는 개발 흐름을 정리하고 자동화의 품질을 높이는 데 긍정적으로 작용할 가능성이 있어 보입니다.