TL;DR

• 일본 SMB(중소기업) 대상 SaaS 중 공식 MCP가 존재하지 않는 것만을 대상으로 한 커넥터 모음 mcp-jp를 OSS(Open Source Software)로 공개하고 있습니다 (자체 구현 30+).
• REST API만 있다면 MCP 커넥터 자체는 몇 시간 만에 작성할 수 있습니다. 개수는 차별화 요소가 되지 않습니다.
• 정말 소모적인 것은 "수요가 없는 것을 만드는 것", "조만간 공식 버전이 나올 것을 지금 만드는 것" 이 두 가지였습니다. 이를 사람의 기억에 의존하지 않고 시스템으로 막는 것이 설계의 주된 주제가 되었습니다.
• 이를 위해 도입한 것이 (1) 착수 전 후보 선정 매트릭스 (2) 공식 MCP와의 중복을 CI(Continuous Integration)에서 걸러내는 순회 체크 (3) 공식이 출시된 커넥터를 archive/로 퇴피(정리)하는 운영의 세 가지 포인트입니다. 본 기사는 그 구현에 관한 이야기입니다.

배경: 만드는 것은 간단하다는 현실

MCP (Model Context Protocol) 커넥터 구현은 대상에 안정적인 REST API가 있다면 놀라울 정도로 빠릅니다. 인증을 환경 변수로 받고, 엔드포인트를 호출하여, 응답을 LLM이 처리할 수 있는 형태로 정형화합니다. 커넥터 하나당 툴(Tool) 5개 내외라면 반나절도 걸리지 않습니다.

실제로 mcp-jp에는 일본 SMB를 중심으로 30개 이상의 커넥터가 있습니다 (KING OF TIME, SmartHR, Kaonavi, Smaregi, CloudSign, L-Step ……). 하지만 개수를 자랑하는 글을 쓰고 싶지는 않았습니다. REST API가 있는 한 누구나 재현할 수 있고, 공식 MCP가 나오는 순간 진부해지기 때문입니다.

진부화는 추상적인 리스크가 아니라 이미 일어났습니다. freee, Money Forward, kintone이 잇따라 공식 MCP를 출시하면서, 제가 자체 구현했던 커넥터들은 단번에 존재 의의를 잃었습니다. 실제로 30개 이상을 archive/로 퇴피했습니다.

그래서 설계의 질문은 "어떻게 빨리 만들 것인가"가 아니라 다음과 같이 바뀌었습니다:

공식이 나오면 사라질 것을, 어떻게 너무 많이 만들지 않고·떠안지 않고 운영할 것인가.

시스템 1: 착수 전 후보 선정 매트릭스

"API가 있으니까 만든다"를 그만두고, 착수 전에 4개 축으로 스코어링을 하고 있습니다 (각 0~3점, 12점 만점).

판정은 심플하게, 합계 9점 이상은 착수 후보, 6~8점은 보류, 5점 이하는 반려로 하고 있습니다.

그리고 A가 0(공식 있음/직근 GA)이라면 다른 항목이 만점이라도 반려합니다. 추월당하는 것이 확정된 것에 공수를 투입하지 않는다는 제동 장치를 규칙의 최우선에 두고 있습니다.

지루하지만 효과적인 것은 "착수하면 매트릭스에 행을 추가하고, 스코어·확인 날짜·출처를 남기는" 운영입니다. 나중에 "왜 만들었는지/만들지 않았는지"를 재현할 수 있습니다.

시스템 2: 공식 MCP와의 중복을 CI에서 걸러내는 순회 체크

매트릭스는 착수 시점의 판단일 뿐입니다. 문제는 가동 중인 커넥터의 대상에, 나중에 공식 MCP가 나오는 케이스입니다. README의 "공식 MCP 목록"을 수동으로 관리하면 반드시 부패합니다.

그래서 가동 중인 커넥터가 "공식 제공 완료"와 중복된다면 CI에서 탈락시키는 순회 체크를 배치했습니다 (tools/check_official_mcp.py + tools/official_mcp_state.json). 공식 MCP가 확인된 서비스를 상태 파일에 기록하고, 그것이 현역 커넥터와 충돌하면 빌드를 실패하게 만듭니다.

포인트는, 진부화를 "알아차리면 고친다"에서 "CI가 지적할 때까지 머지(Merge)할 수 없다"로 끌어내리는 것입니다. 퇴피 누락을 사람의 기억에 의존하지 않도록 하고 있습니다.

# tools/check_official_mcp.py (발췌)
# 가동 중인 커넥터 = src/*_mcp/server.py를 가진 최상위 디렉토리
def active_connectors() -> list[str]:
...

신선도 체크(공식 MCP 목록의 최종 리뷰로부터 90일 경과 시 경고)도 동일한 스크립트에 포함시켜, 분기별 검토를 잊더라도 CI 측에서 재촉이 오도록 구성했습니다.

분기마다 공식 MCP의 신규 제공 여부를 검토하고, 출시된 것은 상태 파일에 추가하는 운영과 세트로 돌리고 있습니다.

구조 3: 공식 버전이 출시되면, 공식 MCP가 출시된 커넥터는 삭제하는 것이 아니라 archive/로 이동시켜 보관하고, README에 "신규 이용은 공식 MCP를 사용해 주세요"라고 명시하여 링크를 겁니다.

• 코드를 삭제하지 않는 이유는 전환기에 참조하고 싶은 사람이 있을 수 있고, 판단의 이력을 남기기 위해서입니다.
• 다만 현역 목록에서는 제외하고, 유지보수 대상이 아님을 선언합니다.
• 이를 통해 "목록에 있는 커넥터는 전부, 공식 버전이 없더라도 제대로 동작한다"라는 목록의 신뢰성을 유지할 수 있습니다.

OSS (Open Source Software)로서 공개하는 이상, **간판은 개수가 아니라 "목록에 있는 것이 전부 동작한다는 것"**이라고 생각합니다. 테스트, 에러 처리, README를 갖추고, 순회 체크를 통해 노후화된 것을 걸러냅니다. 수를 쫓지 않는 것이 결과적으로 유지 비용과 신뢰를 모두 지켜주고 있습니다.

설계상의 작은 공통화

구현 측에서 의도적으로 통일한 것도 이러한 철학과 맞닿아 있습니다.

• 응답 정형화(Response formatting)와 에러 처리는 공통 헬퍼인 _http.py (format_response / error_response)에 집약되어 있습니다.
• API 에러는 가공되지 않은 스택 트레이스(Stack trace)가 아니라, 원인과 대처 방법을 나타내는 메시지로 변환합니다.
• 너무 큰 응답은 LLM의 컨텍스트(Context)를 넘치게 하지 않도록 자릅니다.
• 외부 의존성을 늘리지 않기 위해, _http.py는 각 패키지에 동봉되어 있습니다 (공유 라이브러리화하지 않습니다).
• 각 커넥터는 독립된 pip 패키지로, 하나만 설치해서 사용할 수 있습니다.

# 각 커넥터의 src/<name>_mcp/_http.py (모든 커넥터에서 동일 · vendoring)
MAX_CHARS = 20000
def format_response(data, *, max_chars: int = MAX_CHARS) -> list[types.TextContent]:
...

"동작함의 보장"을 테스트/CI를 통해 기계적으로 지키고, 인간은 "무엇을 만들 것인가 / 접을 것인가"의 판단에 집중하는 분담 구조로 만들었습니다.

요약: 가치는 커넥터의 "위"에 있다

솔직히 말하면, 커넥터 본체는 거의 차별화 요소가 되지 않습니다. 가치가 실리는 곳은 그 위의 운영 레이어(Layer) — 키 관리, 호스팅(Remote MCP화), 감사(Audit)·권한 — 이며, OSS 커넥터 모음은 그곳을 향한 신뢰의 증명이자 리드(Lead) 획득의 입구로서 배치하고 있습니다.

따라서, 만약 "자사에서 매일 사용하고 있지만 공식 MCP가 없는 SaaS를 AI에서 호출하고 싶다"는 요구가 있다면 꼭 알려주세요. 수요로서 기록하고, 매트릭스 상위 항목부터 만들어 나가겠습니다.

Discussion