한 번 비즈니스 API를 연결하고 모든 에이전트 클라이언트와 MCP를 통해 공유하기
요약
Baize는 팀용 AI 어시스턴트 런타임으로, 여러 에이전트 클라이언트(Cursor, Claude Desktop 등)에서 발생하는 비즈니스 API 연결 및 자격 증명 분산 문제를 해결합니다. OpenAPI 문서를 한 번 가져오고 인증을 중앙 집중화하여, 각 클라이언트에 독립적인 '내보내기' 채널을 통해 안전하게 기능을 공유할 수 있게 합니다.
핵심 포인트
- 비즈니스 API 연결과 인증 관리를 Baize에서 중앙 집중화합니다.
- MCP 서버 내보내기는 상태 비저장 방식의 표준 HTTP를 사용하며, 보안이 강화되었습니다.
- 쓰기 권한은 단순 슬로건이 아닌 4단계 하드 제약 조건으로 구현되어 안전성을 높였습니다.
프로젝트: Baize — 팀용 AI 어시스턴트 런타임 (Go 1.25+, MIT)
레포지토리: https://github.com/rebornace/baize
1. 매우 현실적인 문제점
팀이 AI를 도입할 때 피할 수 없는 문제가 하나 있습니다. 바로 모두가 서로 다른 에이전트 클라이언트를 사용한다는 것입니다.
한 명은 Cursor에서 코딩하고, 다른 한 명은 Claude Desktop을 사용하며, 또 다른 사람은 다른 것을 사용합니다. 비즈니스 API 문서, 로그인 자격 증명, 콜백 URL 등—만약 이 모든 것을 각 클라이언트마다 재설정한다면, 결국 레거시 시스템 하나를 Cursor에 연결하고, 다시 Claude Desktop에 연결하는 식으로, 자격 증명이 사방에 흩어지게 됩니다. 만약 그 레거시 시스템의 인증 방식이 변경되는 날이 오면, 여러분은 각각의 클라이언트를 모두 수정해야 합니다.
Baize는 이 문제에서 '비즈니스 시스템을 연결해 놓는' 측면에 초점을 맞춥니다. OpenAPI 문서는 Baize에 한 번 가져오고(import), 로그인은 Baize 콘솔에서 한 번 완료하며, 쓰기 승인(write-approval)은 Baize에서 한 번 감사(audit)합니다. 남은 질문은 이것입니다: 팀이 이미 사용하고 있는 에이전트 클라이언트들이 이 연결된 기능을 다시 모두 재설정하는 대신 어떻게 재사용하게 할 수 있을까요?
그것이 바로 MCP 서버 내보내기(export)의 목적입니다.
2. 결정이 이루어지는 곳과 그렇지 않은 곳
먼저 알아야 할 점은, Baize가 도구들을 내보낸 후에는 결정이 Baize 측에 달려있지 않다는 것입니다.
Cursor의 Cursor 모델이나 Claude Desktop의 Claude 모델—이들은 여전히
내보내기 채널(export channel)은 상태 비저장 방식의 표준 MCP Streamable HTTP를 통해 작동합니다. 클라이언트가 연결하면 요청 헤더에 Bearer 키를 전송합니다.
서버 측에서는 다음과 같은 절차가 이루어집니다:
- 키가 잘못되었거나 누락된 경우 → 401 응답.
- 키는 평문(plaintext)으로 절대 저장되지 않으며, 오직 해시 값(hashes only)으로만 저장됩니다.
- 각 키는 별도의 내보내기 식별자(export identity)에 매핑됩니다 (예: "Cursor용"과 "Claude Desktop용"은 서로 다른 두 개의 키입니다).
- 키는 언제든지 취소될 수 있으며, 하나를 취소하면 해당 클라이언트는 즉시 연결이 끊어집니다.
- 전체 내보내기 기능에는 마스터 토글(master toggle)이 있어, 이 토글이 꺼져 있을 경우 모든 요청은 503 응답을 반환합니다.
"식별자당 하나의 키"는 형식적인 절차가 아니라, 이후의 로그인 상태 관리 및 격리 동작을 가능하게 하는 핵심 요소입니다.
4. "읽기 전용(Read-only)"은 슬로건이 아닌 네 계층의 하드 제약 조건입니다
외부 클라이언트에게 비즈니스 도구를 노출하는 것에 대한 가장 흔한 반론은 '쓰기는 어떻게 할 것인가?'입니다. Baize는 마케팅 문구에서 단순히 "읽기 전용"이라고 말하지 않습니다. 내보내기 정책에 네 가지 계층을 쌓아 올렸습니다:
계층 1: HTTP 도구는 기본적으로 GET/HEAD만 노출합니다. 도구가 내보내지기 전에 Baize는 해당 도구의 HTTP 메서드를 확인합니다. GET이나 HEAD가 아닌 것은 명시적으로 force_allow로 표시되지 않는 한 내보내지지 않습니다.
계층 2: MCP 출처의 쓰기 도구는 하드 거부됩니다. Baize 자체도 외부 MCP 서버에 클라이언트로 연결합니다. 해당 서버에서 나오는 도구들 중 이름이나 설명에 insert, update, delete, drop, truncate, execute_write 등과 유사한 키워드가 포함된 것은, 누군가 이를 force_allow하려고 시도하더라도 절대 내보내지지 않습니다.
계층 3: 승인이 필요한 도구는 내보내지지 않습니다. Baize에서 "호출 전에 인간의 확인이 필요함(need human confirmation before calling)"으로 표시된 쓰기 작업(예: 레코드 생성)은 단순히 내보내기 인터페이스에 나타나지 않습니다. 이는 내보내기 채널에 승인 카드가 없으며, 이를 노출하는 것은 인간 검토 과정을 우회한다는 의미이기 때문입니다.
레이어 4: 호출 시 정책 재확인. 도구는 MCP 카탈로그에 등록될 때 한 번, 실제로 호출될 때 다시 한번 정책을 전달합니다. 이는 Baize의 백엔드에서 도구를 비활성화하거나 내보내지 않을 경우, 다음 외부 클라이언트 호출이 즉시 실패한다는 것을 의미하며, "카탈로그에는 여전히 목록으로 남아 있지만 이미 꺼져 있는" 공백 상태가 없습니다.
5. 로그인 상태 처리 방식
이는 내보내기 경로에서 가장 미묘한 부분입니다. 레거시 API는 로그인을 요구합니다. 자격 증명은 Baize의 콘솔에 구성되지만, 외부 클라이언트(예: Cursor)가 도구를 호출할 때, 그 호출은 어떤 로그인 상태로 나가는 것일까요?
Baize의 접근 방식은 다음과 같습니다: 각 내보내기 ID는 별도의 내부 ID와 연결됩니다. 이는 자체 세션 네임스페이스(mcp-export-id: 접두사 + 내보내기 ID)를 가지며, 모든 호출은 그 ID를 통해 강제됩니다. 구체적으로 설명하면 다음과 같습니다:
- "Cursor ID"에 대해 Baize 내부에서 한 번 로그인하고 자격 증명을 구성합니다.
- Cursor가 해당 키로 어떤 도구를 호출하더라도, Baize는 이 ID를 사용하여 레거시 시스템에 접근합니다.
- "Claude Desktop 키"는 다른 ID, 즉 다른 로그인 상태를 거치므로, 두 가지는 절대 교차하지 않습니다.
Cursor 내부의 사용자는 레거시 시스템의 로그인 페이지를 결코 보지 못하며, 자격 증명은 이미 Baize 측에서 유지됩니다.
6. 실제 사용 경로
세 단계로 구성됩니다:
- Baize 콘솔에 비즈니스 시스템을 연결합니다 (OpenAPI 문서 가져오기, 로그인 완료, 승인 규칙 구성).
- 내보내기 설정에서 내보내기 ID를 생성하고 키를 발급받습니다.
- Baize의 MCP Streamable HTTP 엔드포인트와 Bearer 키를 에이전트 클라이언트(Cursor, Claude Desktop 등 — 모든 MCP 지원 클라이언트가 동일하게 작동합니다)에 연결합니다.
그 후, 클라이언트에서 무언가를 말하면; 클라이언트 모델은 이미 연결된 Baize 도구 중 무엇을 호출할지 선택하고, Baize는 실행을 처리하고 결과를 반환합니다.
7. 이전 기사와의 관련성
이전 게시물("How I wired a ten-year-old Java legacy system into AI with zero changes")에서는 MCP가 짧은 단락으로만 다루어졌습니다. 초점은 레거시 시스템을 건드리지 않고 가져오는 방법에 있었습니다. 본 기사에서는 MCP 서버 측면을 자세히 다룹니다: Baize는 단순히 레거시 시스템을 자체 도구로 변환하는 것뿐만 아니라, 팀이 이미 사용하는 모든 Agent 클라이언트와 그 도구를 공유할 수도 있습니다.
양방향(bidirectional) MCP를 구현함으로써, 에코시스템 내에서 Baize의 위치가 명확해집니다: 들어올 때는 외부 MCP 도구 서버에 연결하여 다른 사람들의 도구를 가져오고; 나갈 때는 자체 연결된 카탈로그를 MCP를 통해 노출할 수 있어 팀이 어떤 것도 두 번 재구성할 필요가 없습니다.
8. 마무리
"비즈니스 API를 한 번 연결하고, 팀의 모든 Agent 클라이언트가 사용하도록 한다"는 것은 단순히 "도구 카탈로그 공유"처럼 들립니다. 하지만 실제로 구현한다는 것은 다음과 같은 구체적인 질문들이 쌓이는 것을 의미합니다: 쓰기 작업(writes)을 어떻게 차단할지, 키(keys)를 어떻게 관리할지, 로그인 상태(login state)를 어떻게 격리할지, 설정 변경 사항을 즉시 적용하려면 어떻게 할지. Baize는 이 모든 것을 세 가지 영역으로 통합합니다: 내보내기 정책(export policy), 키 관리(key management), 그리고 ID 브리징(identity bridging). 기본값은 보수적입니다 (읽기 전용, 승인 게이트가 있는 항목은 숨겨지고 취소 가능함); 무언가를 열려면 각 단계에서 명시적인 조치가 필요합니다.
이 내보내기 기능은 여전히 발전 중이며, 다양한 클라이언트들이 MCP를 서로 다른 깊이로 지원합니다. 직접 사용해 보시고 이슈를 열어주시거나 — 아니면 댓글로 팀이 비즈니스 도구를 자체 클라이언트에 어떻게 연결하는지 알려주세요. 제가 계속 개선하겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기