원격 MCP 서버의 실제 적용: AI 시대 SaaS 제품을 위한 새로운 진입점

SaaS 제품은 오랫동안 같은 문제를 안고 있었습니다: 가치 실현까지 시간이 너무 오래 걸립니다. 많은 사용자가 “아하!” 모먼트에 도달하기 전에 이탈합니다.

Logto 온보딩을 여러 번 반복적으로 개선해 보았습니다. 도움이 되긴 했지만, 병목은 사라지지 않았습니다. 여전히 문서를 읽고, 튜토리얼을 훑어보고, SDK를 설치하고, 설정을 연결하고, 코드를 작성한 뒤, 마지막 10%에서 디버깅을 해야 제대로 작동합니다.

그래서 우리는 다른 방식을 시도했습니다: Logto의 IDE-네이티브 제어 플레인으로 원격 MCP 서버를 구축한 것입니다. 관리자 콘솔을 클릭하는 대신, 대화로 Logto 설정 및 통합 코드를 생성할 수 있습니다. 바로 앱을 개발하는 곳에서 말이죠.

하나의 프롬프트로, 아무것도 없이 바로 동작하는 통합까지 갈 수 있습니다. 에이전트는 단순히 코드를 생성하는 게 아니라, 테넌트 내에서 Logto 애플리케이션을 만들고 설정까지 완료합니다. 이 모든 과정을 IDE 안에서 한 번에 할 수 있습니다. (Logto MCP 서버 체험하기)

이 글에서는 Logto MCP 서버를 구축하며 겪은 경험과 고민, 즉 다음을 다룹니다:

• MCP vs. Agent Skills: 우리가 왜 MCP를 선택했는지
• MCP 서버 런칭 과정에서 겪은 문제와 해결 방법
• 우리가 MCP 도구를 어떻게 설계했는지, 그리고 여러분은 어떻게 설계해야 할지
• MCP의 미래에 대한 우리의 기대

MCP vs. Agent Skills: 우리가 MCP를 선택한 이유#

AI가 Logto에 어떻게 접근해야 할지 결정하기 전에, 우리는 두 가지 옵션을 비교해 보았습니다: MCP 서버와 Agent Skills.

MCP 서버는 두 가지 형태가 있습니다: 로컬, 원격.

로컬 MCP 서버는 사용자의 PC에서 실행됩니다. 서비스 설치, 환경 세팅, 인증 정보, 특별한 로그인 흐름 등이 필요하죠. 사용성과 배포 측면에서 스킬과 매우 유사합니다.

원격 MCP 서버는 서버 측에서 호스팅됩니다. 사용자는 URL로 연결하고 OAuth로 인증합니다. 이 모델은 SaaS 서비스 확장에 더 가깝죠.

구조적으로 보면, Agent Skill은 "비즈니스 로직 + 하부 기능"의 조합입니다. 이 하부 기능들은 도구, CLI, API 호출 등일 수 있죠. MCP 도구는 이 레이어를 통합적으로 제공합니다.

그래서 관건은, 기능을 어떻게 구현하느냐가 아니라, 그것을 사용자에게 어떻게 전달하는지에 있습니다.

• Agent Skills는: 완전한 로컬 툴체인(스킬 패키지 + 로컬 런타임 + API 키나 플랫폼 인증 정보 + CLI 도구 + 설치, 설정, 업그레이드, 유지보수 플로우)을 제공합니다.
  본질적으로, 사용자가 직접 실행할 수 있게 모든 능력을 넘기는 셈입니다.

• 원격 MCP 서버는: 원격 서비스 진입점(URL + OAuth 로그인)을 제공합니다.
  즉, 기능을 서비스로 제공합니다.

아래에서, 사용자 경험, 생태계 확장성, 배포와 유지관리 관점에서 비교합니다.

사용자 경험#

Agent Skills는 대부분 플랫폼 API나 CLI에 의존합니다. 사용자는 먼저 API 키를 발급받거나 CLI를 설치하고 로그인해야 합니다. 이 단계들은 복잡하지 않지만, 진입 장벽을 높입니다.

MCP 서버는 OAuth를 지원합니다. 사용자는 자신의 SaaS 계정으로 로그인하면 됩니다. 마치 “Google로 로그인하기” 같은 경험이죠.

사용자 입장에서 MCP 서버는 매우 간단합니다: URL을 입력하고, 로그인하고, 연결하면 끝. 우리가 제공하고자 했던 경험입니다.

생태계 확장성#

MCP 웹사이트에는 이미 104개의 AI 앱이 MCP를 지원합니다. VS Code, Cursor, Windsurf 같은 툴도 포함되어 있죠.

Agent Skills는 아직도 플랫폼 종속적입니다. 아무리 여러 플랫폼이 스킬을 지원한다고 해도, MCP 서버를 출시하면 누구나 바로 쓸 수 있지만, 스킬을 출시하면 해당 플랫폼 사용자만 쓸 수 있습니다.

또한 MCP는 Agentic AI Foundation (AAIF)에서 채택한 프로토콜 표준이기도 하죠. 이 생태계는 계속 성장할 것입니다. 우리가 장기적으로 투자하기에 충분한 이유입니다.

배포와 유지관리 비용#

Agent Skills는 플랫폼 API나 CLI에 의존하기 때문에, 곧 이런 문제가 생깁니다:

• API가 바뀌면 어떻게 하죠?
• CLI와 호환성이 깨지면?
• 스킬을 업그레이드·재배포하려면?

CLI도 배포해야 하고, 흩어진 인증 정보도 관리해야 하고, 여러 플랫폼에 맞춰야 하며, 사용자가 직접 업그레이드하도록 안내해야 합니다. 투자 대비 효과가 매우 떨어집니다.

MCP 서버는 훨씬 단순합니다. 사용자는 URL 하나만 연결하면 됩니다. 항상 최신 버전을 바라보죠. 우리가 MCP 서버를 업데이트하면, 사용자는 연결할 때마다 바로 최신 버전을 받습니다. 별도의 업그레이드 필요가 없습니다. API가 바뀌어도 서버 내부에서 갱신하면 됩니다.

대다수 SaaS 제품은 이미 탄탄한 인프라, 견고한 API와 성숙한 인증 체계를 갖추고 있습니다. MCP 서버는 자연스럽게 API의 "AI 인터페이스" 역할을 합니다. 마치 관리자 콘솔이 같은 API 위를 덮는 또다른 인터페이스인 것처럼요.

Logto에게도 MCP 서버 선택은 우리의 구조와 강점을 살릴 수 있는 방식이었습니다.

모든 요청이 하나의 진입점으로 집중되기 때문에 로깅과 감사, 권한 관리가 명확해집니다: AI가 할 수 있는 일은 사용자가 직접 승인한 범위로 딱 제한되죠. 특히 엔터프라이즈나 컴플라이언스에 더 구조적으로 깔끔합니다.

MCP 서버 출시 과정에서 마주한 문제와 해결책#

MCP도 완벽하진 않습니다. 대부분은 생태계 성숙도와 관련된 문제입니다. 시간이 지나면 자연스레 개선될 것입니다. 그 전까지는 현실적인 우회책을 써야 했습니다.

MCP 기능 지원의 파편화#

MCP 스펙은 많은 기능을 정의하지만, 클라이언트마다 지원 범위는 다릅니다:

• 툴: 광범위하게 지원됨
• OAuth: VS Code에서 잘 지원됨; Cursor 등은 mcp-remote가 브릿지 역할
• 기타 기능(리소스, 프롬프트, 인스트럭션): 지원 불균일

현재는 도구가 가장 신뢰할 수 있는 공통 계층입니다. (MCP 커뮤니티 페이지를 참고해 각 클라이언트가 무엇을 지원하는지 볼 수 있습니다)

그래서 선택은 명확합니다: 도구에 집중합니다.

LLM이 도구 사용법을 모를 때#

이것은 비즈니스 레이어의 문제입니다.

Agent Skills는 비즈니스 로직과 컨텍스트가 패키징되어 있으므로, LLM이 잘 사용합니다. MCP는 도구만 제공합니다. 연결 후 LLM은...

• 사용 시나리오
• 호출 순서
• 비즈니스 제약사항

...등을 잘 모릅니다.

MCP에 인스트럭션 개념이 있지만, 모든 클라이언트가 지원하진 않습니다. 인스트럭션을 써도 연결 시 모든 내용을 컨텍스트에 밀어넣기 때문에, 토큰 낭비가 큽니다.

도구 설명에 가이드를 넣는 방법도 있지만,

• 설명이 복잡해지고, 다수 도구의 워크플로우가 얽히면 관리가 어렵습니다.
• 도구 개수가 많아질수록 설명이 컨텍스트 창을 다 잡아먹게 됩니다.

우리의 우회책: getInstructions 도구 제공

아주 간단하게, 인스트럭션이 잘 지원되지 않으면 아예 도구로 만들어버립니다.

LLM이 필요할 때마다 getInstructions를 호출하면, MCP 서버가 해당 작업에 필요한 프롬프트와 연결 도구 사용법을 안내합니다.

복잡한 비즈니스 로직은 인스트럭션 도구 뒤에 숨기고, 실제 도구들은 단순하게 유지합니다. 도구 설명은 해당 기능에만 집중하도록 하죠.

Agent Skills 프롬프트를 온디맨드로 불러오는 방식과 비슷하며, 모든 내용을 한번에 넣는 것보다 효율적입니다.

LLM이 비밀키를 유출할 위험#

많은 SaaS 제품에서, 일부 비밀 정보(클라이언트 시크릿, API 키, 웹훅 서명키 등)는 절대 노출되면 안 됩니다. 유출되면 타인이 내 이름으로 접근하거나 리소스를 탈취할 수 있습니다.

LLM의 위험은, 챗이 안전하지 않다는 데 있습니다. 대화 내용은 로그로 남거나, 복사, 전달되거나, 디버깅 로그에 남을 수도 있죠. "나와 모델만 볼 것이다"는 기대를 할 수 없습니다. 장기 시크릿을 LLM에 넘기거나, 사용자가 복사할 수 있게 출력하게 하는 것은 위험합니다.

이런 패턴은 전통적인 웹 앱 연동에서도 흔히 볼 수 있습니다. 개발자는 시크릿을 서버 환경변수나 설정에 넣으려 하죠.

온보딩이 쉽게 하면서도, 시크릿 안전성을 약화시키지 않기 위해 세 가지 방법을 썼습니다:

• 통합 과정에서는 임시 시크릿만 사용

  챗 기반 설정에서는 유효기간이 짧은 임시 시크릿(예: 1시간 유효)만 반환합니다. 통합을 시도하는 데는 충분하며, 실서비스 전까지는 만료됩니다. 실제 운영 전에는, 개발자가 챗 밖에서 운영용 시크릿을 만들고 교체해야 합니다.

• 보안 경계선을 명확히 안내

  사용자에게 명확히 경고합니다: 운영용 시크릿은 챗에서 만들거나 붙여넣거나 저장하지 마세요. 에이전트나 LLM이 도구 등으로 환경변수나 설정을 간접 접근 가능하다면, 그것 역시 유출 위험이 있습니다. 운영용 시크릿은 AI 보조 통합이 없는 환경에만 넣어야 합니다.

• 챗에선 운영용 시크릿을 다루지 않고, 콘솔로 안내

  장기 시크릿은 챗에서 생성/배포하지 않습니다. 콘솔의 인증정보 페이지에서만 만들고 관리합니다. 챗에서는 콘솔로 바로 이동할 수 있는 링크만 제공합니다.

MCP 도구를 어떻게 설계했는가#

우리의 여정#

Logto는 완전한 관리 API를 갖고 있습니다. 처음엔 생각이 단순했습니다: 모든 API 엔드포인트를 MCP 도구로 다 노출시키자!

곧 한계에 부딪혔습니다.

첫째, 컨텍스트 폭발. Logto는 API가 많습니다. 하나하나 도구에 매핑하면 컨텍스트 창이 금방 찹니다. 도구 설명마다 토큰이 들죠.

둘째, 의미 상실. API는 개발자에겐 원자적인 블록이지만, Logto MCP 서버 사용자들은 시스템을 개발하는 것이 아니기 때문에 원하는 건 “작업 완수”지, 어떤 API가 몇 개인지가 아닙니다.

예를 들어 Logto에는 브랜딩, 로그인 방식, 회원가입 방식, 보안 정책을 담당하는 sign-in-experience API가 있습니다.
처음엔 이것을 모두 LLM에 노출해 조합하게 할까 고민했습니다.

하지만 그건 개발자스러운 생각이었습니다. 사용자는 API 호출이 아닌, 그냥 브랜딩을 바꾸거나 로그인 방식을 설정하고 싶을 뿐입니다.

따라서 도구는 updateBranding, updateSignInMethod, updateSignUpMethod 같이 비즈니스 중심으로 설계해야 했습니다. 실제 API 조합은 서버 내부에서 처리합니다.

Logto MCP 서버는 API 래퍼가 아니라, “또 다른 관리자 콘솔”로 봐야 합니다.

MCP 도구 설계 원칙#

원칙이 명확해집니다:

• 사용자가 직접 서비스를 쓴다면(콘솔처럼), 도구는 비즈니스 지향으로 설계해야 한다.
• 다른 이가 기반 기능을 조합할 수 있게 제공한다면, 도구는 작고 단순하게 원자적으로 남겨야 한다. 예: 파일시스템 MCP 서버는 read_file, write_file만 제공하고, 에이전트가 조합하도록.

추가 원칙:

• 도구 로직·설명은 최대한 단순하게, 컨텍스트를 아껴라.
• 복잡한 워크플로우는 getInstructions 도구로 온디맨드 가이드만 제공. 그 설명도 간결하게.

MCP의 미래에 바라는 점#

MCP 서버를 만들면서, 생태계를 더 발전시키기 위해 바라는 점을 떠올렸습니다.

스킬 수준의 능력 제공#

MCP 서버도 단순 기능 도구뿐 아니라, 그것들을 조합해 업무를 해결하는 워크플로우 가이드(Agent Skill 스타일)를 공식적으로 제공해야 할 때가 있습니다.

SaaS에선 매우 흔합니다. GitHub MCP 서버, Logto MCP 서버, 각종 분석 플랫폼 등. 사용자는 "원자적 호출"보다 "워크플로우"를 원하죠.

현재 getInstructions는 임시 대책입니다. 프로토콜 수준 지원이 필요합니다.

세션 단위 MCP 활성화#

클라이언트는 여러 MCP 서버에 연결되지만, 세션마다 반드시 다 필요하진 않습니다. 세션 단위 enable/disable로 컨텍스트 낭비를 줄일 수 있습니다.

MCP 도구 호출시 컨텍스트 분리#

도구 호출은 많은 컨텍스트를 잡아먹습니다. MCP 연동이 하위 에이전트에서 이뤄지면, 메인 대화에는 요약 결과만 전달하는 식으로 효율화할 수 있죠.

결론#

여기까지가 원격 MCP 서버를 구축하며 쌓은 우리의 경험입니다.

이 분야를 탐구하는 중이라면, Logto MCP 서버를 한번 써보거나, Discord 커뮤니티에 참여해 실제 구현 경험을 나눠보세요.

앞으로는 아키텍처 설계, OAuth 흐름 등 상세 내용도 차차 공유하겠습니다.