우리는 AI 에이전트가 스크린샷이나 시뮬레이션된 클릭을 통해서가 아니라, 실제 프로덕션 앱(콘텐츠, 카탈로그, 푸시 알림 등)을 네이티브하게 관리하기를 원했습니다. 그래서 우리는 MCP 서버를 구축했습니다. 그 이유와 방법, 실제 세션, 그리고 여전히 부족한 점까지 모든 과정을 소개합니다.

맥락을 이해하기 위한 한 줄의 설명: GoodBarber는 (2011년부터 운영 중인) 노코드 (no-code) 앱 빌더입니다. 고객은 웹 백오피스에서 앱을 구성하며, 플랫폼은 네이티브 iOS 및 Android 빌드와 PWA를 컴파일합니다. 우리가 답하고자 했던 질문은 이것입니다: AI 에이전트가 앱 소유자가 하는 방식 그대로, 앱을 엔드 투 엔드(end-to-end)로 운영할 수 있을까?

이미 API가 있었습니다. 그것이 핵심이 아니었습니다.

이 플랫폼은 수년 동안 API를 보유해 왔습니다. 엔드포인트(endpoints)를 노출하는 것은 전혀 문제가 되지 않았습니다. 문제는 모든 "어시스턴트 연결" 통합 방식이 커스텀 Glue Code(접착 코드)라는 점이었습니다. 특정 벤더를 위해 작성된 도구 정의(tool definitions), 인증 흐름(auth flow), 재시도 로직(retry logic), 모델이 읽을 수 있도록 작성된 문서 등이 필요했습니다. 그러고 나서 다음 어시스턴트를 위해 이 모든 과정을 다시 반복해야 했습니다. 전형적인 N×M 통합의 혼란, 즉 N개의 어시스턴트 × M개의 플랫폼 문제였습니다.

Model Context Protocol (2024년 11월 Anthropic에 의해 도입되었고, 2025년 말 Linux Foundation에 기부됨)은 우리가 계속해서 다시 작성해 왔던 바로 그 부분들을 표준화합니다:

• Discovery (탐색). 클라이언트가 서버에 어떤 도구가 있는지 묻습니다. 에이전트 측에 하드코딩된 카탈로그가 필요 없습니다.
• Typing (타이핑). 모든 도구는 JSON Schema를 함께 제공합니다. 모델은 호출하기 전에 어떤 인자(arguments)가 유효한지 알 수 있습니다.
• Auth (인증). OAuth는 별도의 맞춤형 설정 문서가 아니라 프로토콜 대화의 일부가 됩니다.

실질적인 차이는 명확합니다. 기존 API를 사용하면 각 에이전트마다 통합 코드를 작성해야 합니다. 하지만 MCP 서버를 사용하면, 어떤 MCP 클라이언트(Claude, ChatGPT, Claude Code, Cursor, n8n)든 연결하여 스스로 앱을 구동하는 방법을 찾아냅니다. 우리는 서버 하나를 배포함으로써 현재와 미래의 모든 MCP 클라이언트를 무료로 얻었습니다.

따라서 우리의 목표는 결코 "또 다른 API"를 만드는 것이 아니었습니다. 목표는 앱 자체를 에이전트가 구동할 수 있게 만드는 것이었습니다. 그 구조는 다음과 같습니다.

아키텍처 (The architecture)

Claude · ChatGPT · Cursor · n8n        (any MCP client)
      │      자연어 → 타입이 지정된 도구 호출 (typed tool calls)
      ▼
...

미리 명확히 해두자면: 서버 자체는 호스팅된 GoodBarber 서비스이며, 여러분이 설치하는 오픈 소스 패키지가 아닙니다. 오픈 소스인 부분은 아래의 Skills 레이어입니다. 독자 여러분이 재현할 수 있는 부분은 연결 과정입니다: 엔드포인트를 MCP 클라이언트에 연결하고 로그인하면, 불과 몇 분 만에 에이전트가 실제 앱을 구동하게 됩니다.

도구 설계 (Tool design). 도구들은 도메인별로 네임스페이스(cms_*, shop_*, classic_*)가 지정되어 있으며, 백오피스(back office)에서 수행할 수 있는 기능과 일대일로 매핑됩니다. 기계가 읽을 수 있는 전체 인벤토리는 서버 카드 (server card)에 공개되어 있습니다. 이 글을 쓰는 시점(2026년 7월) 기준으로 150개의 도구가 있습니다. 해당 카드가 계약(contract) 역할을 합니다: 플랫폼이 성장하면 카드도 확장되며, 연결된 에이전트들은 새로운 도구들을 자동으로 인식합니다.

범위 지정 (Scoping). 로그인은 OAuth 2를 사용하며, 모든 세션은 인증된 고객의 앱으로 범위가 제한(scoped)됩니다. 앱 A에 연결된 에이전트는 앱 B를 보거나 건드릴 수 없습니다. 여러 고객 앱을 운영하는 대행사는 각 앱을 별도로 연결합니다.

서버 측 가드레일 (Server-side guardrails). 어떤 검토에서도 옹호할 수 있는 두 가지 설계 결정 사항입니다:

1. 쓰기 작업 시 강제 재읽기 (Forced read-back on writes). 모든 쓰기(write) 작업은 _mcp_policy.verification_required: true를 반환합니다. 에이전트는 방금 생성하거나 변경한 객체를 다시 읽어(re-read) 결과를 확인해야 합니다. 우리가 가장 경계하는 실패 모드는 환각(hallucination)에 의한 성공 보고입니다.
2. 기능 게이팅 (Feature gating). 푸시(push)가 설정되지 않은 앱은 푸시 도구를 전혀 노출하지 않습니다. 에이전트는 존재하지 않는 기능을 호출할 수 없습니다.

오픈 소스 레이어: 44개의 Claude Skills. 우리는 서버 위에 goodbarber-skills를 공개합니다. 이는 44개의 오픈 소스 Claude Skills로, 일반적인 워크플로우(변형 옵션이 있는 제품 생성, 푸시 캠페인 예약, 주문 환불 등...)를 래핑(wrap)한 단순한 마크다운 레시피입니다. 두 가지 별개의 결과물로 구성됩니다. 서버는 실시간 연결(live connection)이며, Skills는 서버를 호출하는 큐레이션된 진입점(entry points)입니다. 이 리포지토리(repo)는 의도적으로 화이트 라벨(white-label) 친화적으로 설계되어, 에이전시가 브랜드를 재설정하고 재배포할 수 있습니다.

실제 세션: 이커머스 카탈로그를 관리하는 에이전트

이론은 이 정도로 하죠. 서버가 연결된 Claude에서 실행되는 실제 작업입니다:

29유로 가격의 검은색 "Storm" 티셔츠를 S, M, L 사이즈로 추가하고, 이를 Summer 2026 컬렉션에 넣은 뒤, 출시를 알리는 푸시를 오후 6시에 예약해줘.

에이전트가 실제로 수행하는 작업:

shop_list_collections      → "Summer 2026"을 컬렉션 ID로 해결(resolve)
shop_create_product        → 제품 생성 (이름, €29, 컬렉션)
                             ← verification_required: true
...

그 후 에이전트는 아무것도 예약하기 전에 저에게 푸시 문구를 보여주며 멈춥니다. Claude와 같은 인터랙티브 클라이언트(interactive clients)는 쓰기(write) 작업을 실행하기 전에 먼저 확인을 요청합니다. 에이전트는 배관 작업(plumbing, ID 해결, 인자 포맷팅, 시퀀싱, 검증)을 수행하고, 저는 나가는 내용을 승인합니다. 백오피스(back office)에서 이 작업은 수십 개의 화면을 거쳐야 하지만, 대화를 통해서는 단 하나의 프롬프트와 하나의 승인으로 끝납니다.

이 세션의 어떤 것도 Claude 전용이 아닙니다. 동일한 흐름이 ChatGPT 커넥터, Claude Code, 또는 Cursor에서도 작동합니다. 또한 도구들이 타입(typed)화되어 있기 때문에, 실패 모드(failure mode)가 정직합니다. 잘못된 형식의 가격을 전달하면 제품이 조용히 망가지는 것이 아니라 스키마 에러(schema error)를 반환받게 됩니다.

(아직) 작동하지 않는 것들

대부분의 글에서 생략하는 부분인 만큼, 솔직한 목록을 작성하겠습니다:

• 의도적으로 디자인 도구는 제외했습니다. 서버는 콘텐츠, 카탈로그, 캠페인, 주문, 통계와 같은 운영(operations)을 다룹니다. 레이아웃과 디자인은 빌더(builder)에 그대로 남겨둡니다. 우리는 텍스트 형태의 도구를 통해 시각적 디자인을 밀어넣는 방식이 좋은 앱을 만들어낸다고 믿지 않습니다.
• 앱별 도구 서브셋(subsets)이 에이전트를 당황하게 합니다. 기능 게이팅(Feature gating)으로 인해 두 앱이 서로 다른 도구 목록을 노출하게 됩니다. 이는 올바른 동작이지만, 일반적인 레시피를 따르는 에이전트는 존재하지 않는 도구를 찾으려 할 수 있습니다. 스킬(Skills)이 이를 처리하지만, 가공되지 않은 프롬프팅(raw prompting)은 때때로 이를 처리하지 못합니다.
• 쓰기(Writes) 작업은 설계상 수다스럽습니다. 강제된 읽기 피드백(read-back)은 모든 변이(mutation) 작업마다 토큰과 지연 시간(latency)을 소모합니다. 우리는 이 트레이드오프(trade-off)를 수용합니다. 검증된 쓰기가 빠른 허구(fast fiction)보다 낫기 때문입니다.

우리가 서버에 구축하지 않기로 선택한 한 가지는 바로 **의무적인 승인 흐름(mandatory approval flow)**입니다. 에이전트가 어느 정도의 자율성을 가질지는 클라이언트에서 운영자가 결정할 문제입니다. Claude와 같은 대화형 어시스턴트는 행동하기 전에 물어보지만, n8n에 연결된 동일한 도구들은 완전히 무인(unattended) 상태로 실행됩니다. 서버의 역할은 앱별 OAuth 범위(scope), 타입이 지정된 도구(typed tools), 그리고 검증된 쓰기를 통해 두 모드 모두를 안전하게 유지하는 것입니다.

우리는 이를 더욱 발전시킬 의도가 분명합니다. 위의 목록은 단지 현재 우리가 솔직하게 선을 그어둔 지점일 뿐입니다.

직접 시도해 보세요

GoodBarber 앱을 사용 중이라면: Claude(또는 모든 MCP 클라이언트)에서 커스텀 커넥터를 추가하고, https://mcp.goodbarber.dev/mcp/sse를 가리킨 뒤, 계정으로 로그인하여 작은 것부터 요청해 보세요. "내 최신 기사의 오타를 수정해줘"가 좋은 첫 번째 테스트가 될 것입니다. 전체 MCP 가이드에서 클라이언트별 설정 방법을 다룹니다.

자신만의 플랫폼을 위해 MCP 서버를 구축하고 있다면: 우리가 프로덕션에서 검증한 패턴은 지루하지만 모방할 가치가 있습니다. 도메인별로 네임스페이스(namespaced) 처리된 타입 지정 도구, 테넌트별(per-tenant) OAuth 스코핑, 기능 게이팅된 도구 노출, 그리고 모든 쓰기 작업에 대한 강제된 읽기 피드백(read-back)입니다.

질문은 댓글로 환영합니다. 가능한 경우 실제 페이로드(payloads)와 함께 답변해 드리겠습니다.