MCP 서버로 Claude에 한국 SaaS 붙이기, 막히는 건 인증부터다

이미지: lifehardmode 자체 제작

Model Context Protocol은 2025년 11월 공식 발표 이후 1년이 채 안 됐는데 이미 사실상 표준이다. Notion, Slack, GitHub, Google Drive 같은 글로벌 SaaS는 공식 커넥터가 다 있다.

문제는 한국 SaaS다. 토스, 카카오워크, 네이버웍스, 자체 ERP, 사내 GitLab. 글로벌 카탈로그에 없으니 직접 만들어야 하고, 그때 첫 번째로 막히는 게 인증이다.

MCP는 도구를 표준화했지만 인증을 표준화하진 못했다. 한국 SaaS에 붙일 때 진짜 비용은 OAuth 설계에서 발생한다.

핵심만 보면

• 한국 SaaS 다수는 OAuth 2.0을 쓰지만 콜백 URL 화이트리스트, 토큰 만료 정책이 제각각이다
• MCP 서버 자체 구현은 하루면 끝나는데, 인증 부분만 한 주가 걸린다
• 로컬 stdio MCP는 토큰을 환경변수로 받지만, 원격 SSE/HTTP MCP는 별도 인증 흐름을 설계해야 한다

무슨 일이 있었나

Anthropic이 MCP를 발표한 2025년 11월 이후, 한국 개발자 커뮤니티에서는 사내 도구를 Claude에 붙이는 시도가 본격화됐다. 2026년에 들어선 GitHub의 awesome-mcp-servers 저장소에서 한국어 README를 단 서버가 늘기 시작했고, 카카오워크와 네이버웍스용 비공식 MCP도 등장했다.

다만 공식 커넥터는 아직 없다. 한국 SaaS 벤더 입장에서 MCP는 트래픽 보장이 적은 신규 프로토콜이라 우선순위가 낮다. 그래서 한동안은 개인이 직접 만들어 쓰는 구간이 이어진다.

1. 로컬 stdio MCP가 가장 안전하다

처음 만들 때 권장 형태는 stdio 기반 로컬 MCP다. Claude Desktop이나 Claude Code가 자식 프로세스로 띄우고, 표준입출력으로 통신한다.

장점은 분명하다.

• 토큰을 환경변수로 받으면 끝이다
• 외부에 노출되는 엔드포인트가 없으니 보안 표면이 좁다
• 한 컴퓨터에서만 동작하지만 사내 개인 개발자에겐 충분

@modelcontextprotocol/sdk Python·TypeScript 버전 모두 stdio 서버 템플릿이 들어있다. 첫 도구 하나 붙이는 데 30분이면 된다.

2. OAuth 토큰은 갱신을 가정해야 한다

한국 SaaS 다수는 access token이 1~24시간 만에 만료된다. MCP 서버를 매번 띄울 때마다 수동 로그인을 강요할 수는 없다.

해결책은 평범하다.

• 처음 한 번만 OAuth 로그인을 띄워 refresh token을 받는다
• refresh token은 OS 키체인 또는 디스크 암호화 파일에 저장한다
• MCP 서버 시작 시 refresh token으로 access token을 갱신하고 메모리에 둔다

keyring 라이브러리 한 줄로 macOS Keychain·Linux Secret Service·Windows Credential Manager를 동시에 지원할 수 있다. 사내 가이드에 이 부분을 안 쓰면 동료들이 매번 토큰을 평문으로 떨군다.

3. 한국 SaaS 콜백 URL 화이트리스트 함정

네이버웍스, 카카오워크, 일부 자체 ERP는 OAuth 콜백 URL을 사전 등록해야 한다. http://localhost:가변포트 형태를 거부하는 경우가 많다.

대응은 두 가지다.

• 고정 포트(예: 53682)를 잡아두고 콘솔에 미리 등록한다
• 사내 도구라면 사내 도메인에 콜백 프록시를 두고, 거기서 로컬로 리다이렉트한다

이 부분은 SaaS 콘솔 가이드에 거의 안 나와 있다. 토스 비즈 같은 결제 API는 IP 화이트리스트까지 요구하는데, 한국 정책상 이건 협상 가능한 영역이다.

4. 원격 SSE/HTTP MCP는 인증 한 층 더 필요하다

팀 단위로 공유하려면 stdio가 아니라 원격 MCP가 필요하다. Anthropic이 표준화한 HTTP+SSE 트랜스포트를 쓰면 되는데, 이때 SaaS 토큰 외에 MCP 서버 자체 인증이 한 층 더 들어간다.

토큰을 두 단계로 본다. 사용자가 MCP 서버에 인증하는 토큰, MCP 서버가 한국 SaaS에 인증하는 토큰.

이 두 토큰을 한 사용자가 다 들고 있어야 일이 된다. OIDC를 받쳐주는 사내 IdP가 있으면 흐름이 간단하지만, 그렇지 않다면 자체 발급 API 키로 시작해도 된다.

5. 도구 설명문이 결국 품질을 결정한다

기술적인 부분이 다 풀려도 Claude가 도구를 안 부르면 의미가 없다. MCP 도구 설명문 한 줄이 작동 여부를 가른다.

• 도구 이름은 한국어가 아닌 영어로 짓되, 동사로 시작한다 (search_kakaowork_messages)
• 설명문에 입력·출력·실패 조건을 한 문장씩 적는다
• 인자에 한국어 예시를 두 개 이상 박는다

Claude는 도구 설명을 읽고 호출 여부를 결정한다. 사내 한국어 문서를 다루는 도구라면, 한국어 예시가 안 박혀 있으면 안 부른다.

과장하면 안 되는 부분

MCP는 만능이 아니다. 도구 호출 한 번이 수십 ms 단위 지연을 만들고, 5개 이상 도구를 한 세션에 등록하면 Claude가 도구 선택을 헷갈리기 시작한다. 핵심 도구 2~3개부터 시작해 점진적으로 늘리는 게 정석이다.

또 한국 SaaS 다수가 공식적으로 MCP를 지원하지 않는다는 점은 그대로다. 비공식 커넥터를 사내에 깐다면 SaaS 약관 위반 가능성을 법무팀과 먼저 검토해야 한다. 특히 자동 메시지 발송, 대량 조회 같은 동작은 rate limit과 별개로 약관 이슈가 생긴다.

마지막으로 보안 검토를 빼면 안 된다. MCP 서버가 access token을 들고 있다는 건, 그 머신이 뚫리면 한국 SaaS 계정 전체가 뚫린다는 뜻이다. 회사 데이터 접근 권한이 있는 도구라면 감사 로그와 토큰 폐기 절차를 같이 설계해야 한다.

한국 독자가 볼 지점

사내에 카카오워크나 네이버웍스를 쓰는 회사가 많다. 메시지 검색·답신 정도부터 시작해 점진적으로 늘리는 게 합리적이다. 결제 API나 인사 시스템 같이 권한이 큰 도구는 처음부터 붙이지 말고, 읽기 전용 도구로 한 달 정도 운영해본 뒤 결정하는 게 안전하다.

또 사내 GitLab을 MCP에 붙이는 흐름은 GitHub MCP의 공식 구현을 그대로 옮길 수 있다. GitLab API가 GitHub와 호환되는 영역이 넓어, 도구 설명만 바꾸면 동작한다.

지금 체크할 것

• 어떤 한국 SaaS를 먼저 붙일지 도구 단위로 2~3개 정해두기
• OAuth 콜백 URL 정책을 SaaS 콘솔에서 먼저 확인하기
• access token·refresh token 저장 위치를 키체인으로 정하기
• 도구 설명문에 한국어 예시 박기
• 권한이 큰 도구는 읽기 전용으로 먼저 운영하기

참고

• Model Context Protocol 공식 사이트
• Anthropic Docs — MCP
• awesome-mcp-servers (GitHub)
• Naver Works Developers
• Kakao Work API