MCP로 자사의 시스템을 외부에 개방한다는 판단은 2026년에 들어서며 갑자기 현실적이 되었습니다. 세계 최대 규모의 SaaS도, 회계 소프트웨어의 양대 산맥도, 자사의 업무 시스템을 외부의 AI 에이전트(AI Agent)가 호출할 수 있는 형태로 재구축하기 시작했습니다.

하지만 여기서 많은 개발자가 망설입니다. 외부의 AI에게 자사의 시스템을 조작하게 해도 정말 괜찮은 것인가, 하고 말입니다.

이 불안은 정당합니다. MCP로 외부에 개방하면, 지금까지 자사의 관리 화면 안에서 완결되었던 처리가 두 가지 새로운 리스크에 노출됩니다. 데이터 주권(Data Sovereignty) 문제와 새로운 공격 표면(Attack Surface) 문제입니다.

이 기사에서는 그 두 가지를 FORMLOVA의 구현 사례와 각사의 1차 정보를 바탕으로, 서버 측에서 어떻게 통제할지에 초점을 맞춰 정리합니다. 결론부터 말씀드리면, 답은 "서버 측에서 고삐를 쥐는 것"입니다. AI에게 판단을 맡기는 것이 아니라, 허용된 범위 내에서만 움직일 수 있는 구조를 서버 측에서 만들어 두는 것입니다.

MCP로 개방할 때 발생하는 두 가지 리스크

먼저, 무엇이 일어나는지 정확히 짚어보겠습니다.

첫 번째는 데이터 주권입니다. MCP의 구조상, 자사의 기능을 호출한 결과는 사용자가 사용 중인 채팅 화면, 즉 외부 AI 사업자의 처리 기반을 반드시 한 번 거치게 됩니다.

기존: 사용자 -> 자사의 관리 화면 -> 자사의 서버 -> 자사의 DB
MCP: 사용자 -> 외부 AI의 채팅 -> 자사의 MCP 서버 -> 자사의 DB
↑
...

금융 거래 데이터, 의료 정보, 기업의 기밀 문서. 외부에 내보내서는 안 된다고 여겨져 온 데이터가 자사의 관리를 벗어나 외부 AI의 처리를 통하게 됩니다. 이는 계약상으로나 법률상으로나 쉽게 허용될 수 없는 일이었습니다.

두 번째는 새로운 공격 표면입니다. 외부의 AI 에이전트에게 자사의 시스템을 조작하게 하면 공격의 입구가 하나 늘어납니다. 그중에서도 경계해야 할 것이 프롬프트 인젝션(Prompt Injection)이라 불리는 수법입니다. AI에게 악의적인 지시를 몰래 읽히게 하여, 본래는 허용되지 않는 조작을 수행하게 하는 공격입니다. 정보 보안 단체인 OWASP는 이를 AI 관련 보안 리스크 1위로 꼽고 있습니다.

이 두 가지 장벽 때문에 민감한 데이터를 다루는 업계는 지금까지 MCP로 외부에 개방하는 것에 신중했습니다. 그런데 이 장벽을 허무는 설계가 지금 급속도로 발전하고 있습니다. 핵심은 서버 측에서의 제어 구현입니다.

생각하는 방식은 단 하나로 집약됩니다. AI 에이전트에게 "무엇을 해도 되는지"를 판단하게 하지 않는다. 서버 측이 "여기까지만 움직일 수 있다"를 구조로서 결정한다. 이것을 고삐라고 부르기로 하겠습니다.

고삐는 세 가지가 있습니다. 액세스 권한의 엄격한 제한, 특정 조작에 대한 다단계 승인, 모든 호출에 대한 검증 가능한 기록. 순서대로 살펴보겠습니다.

고삐 그 첫 번째: 권한을 로그인 사용자의 범위 내로 한정하기

첫 번째 고삐는 액세스 권한의 제한입니다.

여기서 가장 중요한 원칙은 심플합니다. 외부의 AI에게 무제한의 권한을 주지 않는 것입니다. 원래 그 사용자가 가지고 있는 권한의 범위 내에서만 움직일 수 있도록 합니다.

일본의 Money Forward와 freee는 2026년 3월, 회계라는 금융의 핵심 분야에서 MCP 서버를 공개했습니다. 양사의 공통점은 AI 에이전트가 조작할 수 있는 범위를 로그인 중인 사용자의 권한 내로 엄격히 제한하고 있다는 점입니다. freee는 "로그인 사용자의 권한 이상의 조작은 수행되지 않는다"라고 명시하고 있습니다.

이 문장에는 중요한 함의가 있습니다. 기존 SaaS가 오랜 시간에 걸쳐 만들어온 권한 관리 메커니즘을 그대로 AI 에이전트 제어에 유용할 수 있다는 뜻입니다. 새로운 권한 모델을 발명할 필요는 없습니다. AI 에이전트를 "권한을 가진 별도의 사용자"가 아니라 "어떤 사용자의 대리인"으로 취급하면 됩니다. 대리인은 본인의 권한을 일절 초과할 수 없습니다.

여기서 설계상 놓치기 쉬운 함정이 있습니다. 많은 MCP 서버는 내부 DB 액세스를 관리자 권한으로 실행합니다. 실행 속도나 구현의 단순함 때문입니다. FORMLOVA도 마찬가지로, 모든 MCP 도구가 서비스 역할(Service Role, 행 수준 보안(Row-Level Security)을 우회하는 권한)로 DB에 액세스하고 있습니다.

이는 편리하지만 위험하기도 합니다. DB의 행 수준 보안이 작동하지 않는 이상, "이 사용자가 이 데이터에 접근할 수 있는가"에 대한 판정은 애플리케이션 계층이 유일한 방어선이 됩니다. 이곳을 단 한 군데라도 뚫리면 AI 에이전트는 타인의 데이터에 도달할 수 있게 됩니다.

따라서 데이터를 취득하는 모든 경로에 소유권 체크를 필수적으로 적용합니다. 개념을 의사 코드(Pseudo-code)로 작성하면 다음과 같습니다.

// 위험: 필터 없이 가져오면 타인의 데이터도 반환될 수 있음
const form = await adminDb.from("forms").select().eq("id", formId).single();
// 안전: 반드시 「이 사용자의 것인가」를 소유권 체크(Ownership Check)로 제한함
...

FORMLOVA에서는 이를 getMcpContext(userId, { formId, requiredRole })나 checkFormAccess(formId, userId)와 같은 공통 함수로 묶어, 새로운 툴(Tool)을 추가할 때마다 반드시 이 중 하나를 통과하도록 규칙을 정하고 있습니다. 쿼리에 .eq("user_id", userId)를 명시적으로 추가하는 것도 같은 목적입니다. 리뷰 시에는 "관리자 권한으로 필터 없는 쿼리가 있는지"를 최우선으로 확인합니다.

마지막 NotFoundError도 고삐의 일부입니다. "존재하지 않음"과 "권한이 없음"을 구분해서 반환하면, 공격자는 ID를 전수 조사(Brute-force)하여 "존재하지만 권한이 없는 ID"를 찾아낼 수 있습니다. 구분하지 않고 둘 다 동일하게 "찾을 수 없습니다"를 반환하면, ID의 유효성 그 자체를 노출하지 않을 수 있습니다.

권한 제한은 데이터 주권(Data Sovereignty)의 벽을 세우는 데에도 효과적입니다. 외부 AI에 전달되는 것은 권한이 제한된 후의, 해당 사용자가 본래 볼 수 있는 데이터뿐입니다. 무엇이든 무분별하게 흘려보내는 것이 아니라는 구조가 여기서 담보됩니다.

고삐 그 두 번째: 불가역적인 조작에 다단계 승인을 요구하기

두 번째 고삐는 특정 조작에 대한 다단계 승인(Multi-stage Approval)입니다.

여기서 고려해야 할 점은, 모든 조작을 동일한 수준으로 보호할 필요는 없다는 것입니다. 분석이나 목록 표시와 같은 읽기 작업과, 이메일 일괄 전송이나 데이터 삭제를 동일한 무게로 다루면, 확인 절차가 너무 많아져서 사용할 수 없게 됩니다.

따라서 조작을 영향 범위에 따라 단계별로 나눕니다. FORMLOVA에서는 MCP 툴을 네 단계로 분류하고 있습니다.

L0 읽기 전용: 즉시 실행 (확인 없음)
L1 가역적인 변경: 즉시 실행 (버전 히스토리로 복구 가능)
L2 응답자에게 파급됨: 서버 측의 review state machine (공개 조작)
...

핵심은 어떤 단계에 속하는지를 서버 측에서 결정하는 것입니다. AI 에이전트에게 "이것은 무거운 조작이니 확인하자"라고 판단하게 해서는 안 됩니다. AI는 확인했다고 거짓말을 할 수 있습니다. "이미 확인했습니다, 전송하겠습니다"라고 자신만만하게 답변할 수도 있습니다. 그렇기에 확인 필요 여부를 AI의 판단 영역 밖에 둡니다.

L3의 불가역적인 조작에는 확인 토큰(Confirmation Token)을 요구합니다. FORMLOVA에서는 이메일 전송이나 삭제 등 11개의 툴이 이에 해당합니다. 토큰은 HMAC-SHA256으로 서명되며, 유효 기간은 5분입니다.

개념을 의사 코드(Pseudo-code)로 나타내면 다음과 같은 흐름입니다.

async function sendBulkEmail(input: BulkEmailInput, userId: string) {
// 1. 사용자의 명시적 승인 플래그 확인
if (!input.userConfirmed) {
...

토큰은 사용자가 실제로 승인했을 때만 서버가 발행합니다. AI 에이전트가 추론만으로 유효한 토큰을 생성하는 것은, 서명 키(Signing Key)를 가지고 있지 않는 한 구조적으로 불가능합니다. 이것이 다단계 승인의 본질입니다. 확인을 "대화상의 합의"가 아닌 "서버가 발행한 서명"으로 대체하는 것입니다.

공개(Publish)와 같이 응답자에게 파급되는 조작(L2)은 또 다른 방식의 방어 체계를 갖춥니다. 단발성 토큰이 아니라 상태 머신(State Machine)으로 취급합니다. FORMLOVA의 공개 툴은 매번 "다음에 필요한 액션"과 "부족한 요건"을 반환합니다. 프리뷰 확인, 중복 응답 방지 설정, 개인정보 처리방침 필요 여부 등이 순차적으로 갖춰져야 비로소 확인 토큰을 발행합니다. AI에게 공개 진행 판단을 맡기지 않고, 서버가 반환한 순서를 따르게 하는 방식입니다.

ServiceNow가 2026년 5월에 발표한 Action Fabric도 바로 이러한 개념으로 만들어졌습니다. 외부 에이전트가 자사 시스템을 조작하는 모든 행위를 본인 확인, 권한 제한, 조작 기록, 그리고 승인 체인(Approval Chain)을 통과하게 함으로써 통제합니다. 외부로 개방하는 동시에, 외부로부터의 조작을 완전히 감시 하에 두는 것입니다. 개방과 통제를 양립시키는 설계입니다. 승인 체인은 ServiceNow와 같은 거대 SaaS에서도 고삐의 핵심 요소로 자리 잡고 있습니다.

고삐 그 세 번째: 모든 호출을 사후 검증 가능한 형태로 기록하기

세 번째 고삐는 검증 가능한 기록입니다.

외부의 AI 에이전트가 무엇을 했는지 나중에 확실히 추적할 수 있는 것. 이는 사고가 발생했을 때의 조사를 위한 것뿐만이 아닙니다. 기록이 존재한다는 사실 그 자체가 억제력이 되며, 신뢰의 근거가 됩니다.

기록해야 할 것은 읽기 이외의 모든 조작입니다. FORMLOVA에서는 L1 이상의 조작, 즉 폼 편집, 멤버 관리, Webhook 설정, 상태 변경, 메일 전송을 모두 감사 로그 (Audit Log) 테이블에 기록합니다. 누가, 언제, 무엇을, 어떤 리소스에 대해 수행했는지를 기록합니다.

type AuditLogEntry = {
  actorId: string; // 조작한 사용자
  actorType: "human" | "agent"; // 사람인지 에이전트인지
  ...
}

여기서 설계상 두 가지만 지키면 효과적입니다.

첫 번째는 추가 전용 (Append-only)으로 만드는 것입니다. 기록을 덮어쓰기(Overwrite)로 지울 수 있는 설계라면 기록의 의미가 퇴색됩니다. 새로운 사실은 과거의 기록을 지우지 않고, 새로운 행(Row)으로 추가합니다.

두 번째는 사람과 에이전트를 구분하여 기록하는 것입니다. 동일한 조작이라도 사람이 직접 했는지, AI 에이전트를 경유했는지를 기록 단계에서 나누어 둡니다. 이것이 없으면 나중에 "이 삭제는 AI의 폭주였는가, 사람의 의도였는가"를 알 수 없게 됩니다.

인증 인프라의 대기업인 Auth0가 2026년 5월 6일에 "Auth for MCP"를 정식으로 제공하기 시작한 것도 이러한 흐름 속에 있습니다. AI 에이전트가 SaaS에 접근할 때의 본인 확인과 권한 관리 (Authorization)를 업계 표준 메커니즘으로 담보하는 것입니다. AI 에이전트와 SaaS 사이에 서서 부정 조작을 감시하고, 권한을 제어하며, 모든 조작을 기록합니다. 기록은 인증 (Authentication) 및 인가 (Authorization)와 세트로, 검문소 기능의 일부로서 표준화되기 시작하고 있습니다.

도구의 입도(Granularity) 또한 고삐의 일부

지금까지의 세 가지 고삐는 모두 "도구가 호출된 이후"의 제어였습니다. 마지막으로 그 전 단계인 도구 설계 자체에 대해 언급하겠습니다. 이것 또한 고삐의 효력을 좌우하기 때문입니다.

과거에는 기존 시스템의 기능을 그대로 얇게 감싸서 MCP 도구로 만들면 된다고 생각되었습니다. 하지만 그렇게 해서는 제대로 작동하지 않는다는 사실이 밝혀졌습니다.

이유는 얇은 래퍼 (Wrapper)라면 고삐를 일관되게 채울 수 없기 때문입니다. AI 에이전트가 여러 개의 세밀한 도구를 스스로 조합하여 목적을 달성하려 할 때, 조합의 경계에서 권한 체크나 확인의 허점이 생깁니다.

따라서 도구는 사용자의 목적 단위로 다시 묶어야 합니다. 결제 서비스인 Stripe를 비롯하여 60개가 넘는 MCP 서버를 운용해 온 Block사와 같은 선구 기업들이 이러한 지견을 공개하기 시작했습니다.

FORMLOVA의 "응답자에게 메일 답장하기"라는 도구가 그 예입니다. 이 도구 하나 안에 여러 제어가 통합되어 구현되어 있습니다.

reply_to_respondent의 내부 처리
1. 사용자 승인 플래그 확인 ← 고삐 2 (다단계 승인)
2. 확인 토큰 검증 (HMAC, 5분) ← 고삐 2
...

"메일에 답장하기"라는 하나의 조작 안에 인가, 상한선, 억제 리스트, 실제 전송, 상태 전이까지 포함되어 있습니다. AI 에이전트는 이 일련의 과정을 분해하여 개별적으로 호출할 수 없습니다. 따라서 고삐의 중간을 빠져나갈 수도 없습니다. 이것이 에이전트 시대에 필요한 "도구 한 개의 무게"라고 생각합니다.

얇은 래퍼는 얼핏 보면 유연하고 좋아 보입니다. 하지만 고삐를 쥐는 입장에서 보면, 목적 단위로 다시 묶은 도구가 허점이 더 적습니다.

남아있는 벽에 대해서도 솔직하게 적어둡니다

여기까지 읽으면 모든 벽이 무너진 것처럼 들릴지도 모릅니다. 하지만 솔직하게 적어두고 싶은 것이 있습니다.

서버 측에서 아무리 고삐를 쥐더라도, 걸러낸 뒤의 데이터는 외부 AI의 처리를 거칩니다. 계약상 혹은 법령상 데이터를 특정 AI 사업자의 처리 기반에 일절 통과시킬 수 없는 영역에서는 고삐 설계만으로 해결할 수 없습니다. 일부 극히 민감한 의료 데이터나, 지리적인 데이터 주권 규제가 적용되는 데이터 등이 이에 해당합니다.

이는 기술의 문제가 아니라 계약과 제도의 문제입니다. 이를 해결하기 위해서는 조직이 승인한 특정 AI만 접속할 수 있도록 하거나, AI의 처리 장소까지 통제하는 등 별도의 계층 메커니즘이 업계 표준으로서 갖춰져야 합니다. 여기에는 아마 몇 년이 걸릴 것입니다.

다만, 이 남아있는 벽은 전체로 보면 제한된 일각에 불과합니다. 세계 업무 데이터의 대부분은 적절한 고삐 설계가 있다면 MCP로 안전하게 다룰 수 있는 영역에 들어와 있습니다. 그리고 그 일각 또한 시간이 흐름에 따라 제도가 따라잡아 머지않아 움직이게 될 것입니다.

요약

MCP로 자사 시스템을 외부에 개방할 때, AI 에이전트(AI Agent)에게 "무엇을 해도 되는지"를 판단하게 해서는 안 됩니다. 서버 측에서 "여기까지만 움직일 수 있다"를 구조적으로 결정해야 합니다. 이것이 바로 고삐입니다.

고삐는 세 가지가 있었습니다.

• 액세스 권한(Access Permission)을 로그인한 사용자의 범위 내로 한정한다. 기존의 권한 관리(Permission Management)를 AI 에이전트의 대리인 모델(Agentic Model)에 유용한다.
• 불가역적인 조작에는 서명된 토큰(Signed Token)을 통한 다단계 승인을 요구한다. 확인 과정을 대화상의 합의가 아닌, 서버가 발행한 서명으로 대체한다.
• 읽기 이외의 모든 조작을 사람과 에이전트를 구분하여, 추가 전용(Append-only)으로 기록한다.

그리고 툴(Tool)은 사용자의 목적 단위로 다시 묶어야 합니다. 얇은 래퍼(Thin Wrapper)는 고삐 중간에 구멍을 만들기 때문입니다.

허용된 범위 내에서만 AI가 움직일 수 있는 설계. 이것이 데이터 주권(Data Sovereignty)과 안전성의 벽을 허문 가장 큰 요인이라고 생각합니다. MCP로 외부에 개방한다는 판단은 이제 "개방할 것인가"가 아니라, "어떻게 고삐를 쥐고 개방할 것인가"의 단계에 진입했습니다.

그 배경에 있는 SaaS 업계 전체의 구조적 변화에 대해서는 이곳에 적어두었습니다.

Discussion