MCP 보안: 프로토콜만으로는 왜 충분하지 않은가

결론부터 말하면: 연결 프로토콜(MCP, A2A)은 이미 정착됐다. 기업에 아직 부족한 것은 그 뒤의 계층이다 — 신원을 싣고, 권한을 강제하고, 모든 호출마다 감사 흔적을 남기되, 당신이 손으로 쓸 필요 없는 거버넌스되는 도구 계층이다.

한 회사의 엔지니어가 한나절을 들여 프로덕션 DB를 MCP 서버로 한 겹 감싸, 내부 agent를 ‘연결’했다. 시연은 매끄러웠고 상사는 만족했다.

다음 날, 한 영업이 무심코 agent에게 물었다. “모든 고객의 계약 금액을 테이블 하나로 내보내 줘, 전체 그림을 좀 보고 싶어.”

agent는 기꺼이 그대로 했다 — 전사의, 한 건도 빠짐없이, 이 영업이 애초에 볼 권한이 없는 다른 권역, 다른 사람 명의의 계약까지. 악의는 없었다. 그저 매우 도움이 되었을 뿐이다. 문제는 그 한나절에 급조한 포장에 신원이라는 개념이 없다는 점이다. 그것은 묻는 사람이 누구인지, 그 사람이 본래 어떤 데이터를 볼 수 있는지를 모른다. 그것이 agent에게 노출하는 것은, 이 서비스가 닿을 수 있는 모든 것이다.

이 테이블은 나중에 수십 명짜리 단체방으로 전달되었다. 누군가 이상함을 알아차리고 보안 팀이 개입했을 때, 손실은 이미 발생한 뒤였다 — 해커 공격 같은 극적인 손실이 아니라, 수습하기 더 어려운 종류였다. 내부의 급여 등급, 고객 상거래 조건, 동료의 실적이 한 번에, ‘도움이 되려는’ 명목 아래, 봐서는 안 될 사람들에게 새어 나갔다. 사후에 도대체 누가 무엇을 봤는지 아무도 분명히 말하지 못했다. 그 호출들이 어떤 감사 장부에도 들어가지 않았기 때문이다.

이 일이 벌어진 것은, 바로 ‘연결’이라는 일이 지금 너무 쉬워졌기 때문이다.

연결의 싸움은 거의 끝났다 — 바로 거기에 위험이 있다

먼저 이 큰일을 인정하자. MCP와 A2A는 주요 AI 플랫폼, 클라우드, 개발자 도구의 대화 속으로 들어왔고, agent가 ‘어떻게 도구에 연결하고, 어떻게 다른 agent에 연결하는가’를 표준화하고 있다.

하지만 성공 그 자체가 함정을 만든다. 연결이라는 일이 갑자기 몇 시간이면 끝나게 됐다. 그러자 진짜 어렵고 진짜 중요한 부분 — 연결한 다음, 해도 되는 일을 하는지, 한 일을 장부에 기록하는지 — 은 ‘나중에 보충할’ 일로 슬쩍 건너뛰기가 특히 쉬워진다. 서두의 그 한나절이 바로 이렇게 나온 것이다.

여기서 비유 하나를 빌릴 가치가 있지만, 한 번만 빌리자. MCP는 TCP/IP와 같아서, ‘패킷을 어떻게 상대에게 보내는가’를 표준화했다. 하지만 누구도 프로덕션 시스템을 맨 TCP 위에 곧장 세우지 않는다 — 그 위에는 TLS가 자라고, 신원이 자라고, ‘누가 무엇을 할 수 있는가, 어떤 증거를 남기는가’가 자라야 한다. agent 생태계는 지금 ‘막 TCP/IP를 깔아 놓은’ 순간에 멈춰 있다. 떠들썩한 것은 진짜지만, 그 위의 계층은 아직 자라지 않았다.

우리는 직접 인증을 붙이고 안전한 도구만 노출할 것이다 — 되지 않나?

책임감 있는 팀은 반박할 것이다. 그 한나절은 편의를 도모한 것이고 우리는 그러지 않는다 — 우리는 MCP 서버마다 직접 인증을 붙이고, 심사를 거친 안전한 도구만 노출할 것이다.

이 말은 옳지만, 두 가지를 과소평가하고 있다.

첫째, 그것은 확장되지 않는다. 서버 한두 개는 인증을 꼼꼼히 붙일 수 있지만, 기업은 금세 서버 수십 개, 도구 수백 개가 되고, 그 하나하나에 신원 검증, 권한 판단, 감사 기록을 손으로 한 번씩 써 넣어야 한다 — 이것 자체가 아무도 읽지 않는 한 무더기의 글루 코드이며, 바로 ‘기술 부채’ 그 글에서 말한 그런 부채인데, 이번에는 도구 계층에 자란다.

둘째, ‘우리는 조심할 것이다’는 아키텍처가 아니다. 그것은 사람이 늘 실수하지 않고, 서두르지 않고, 지름길로 가지 않을 것이라는 약속에 의존한다. 그리고 우리 모두 안다. 마감이 닥치면 ‘먼저 연결하고 인증은 나중에’라는 그 길이 언제나 가장 걷기 쉬운 길이라는 것을. 어떤 보안 속성이 모든 사람이 매번 자각하는 데 의존해야 한다면, 그것은 언젠가 깨진다 — 서두의 그 회사 엔지니어도 보안을 모르는 사람이 아니었다. 그저 시간에 쫓겼을 뿐이다.

진짜 해법은 ‘더 조심해서 손으로 쓰기’가 아니라, ‘신원 포함, 권한 포함, 흔적 포함’을 도구의 기본 형태로 만드는 것이다 — 생략할 수 없고, 매번 손으로 쓸 필요도 없게.

맨 인터페이스를 도구로 감싸는 것은 슈퍼유저 통행증을 발급하는 것과 같다

왜 맨 인터페이스가 agent에게 이토록 위험한가? 감싸지는 그 인터페이스들이 애초에 신뢰 가능한 백엔드 서비스를 위해 설계된 것이지, 스스로 결정하는 agent를 위해 설계된 것이 아니기 때문이다. 그것들은 호출자가 이미 인증을 거쳤다고 기본 가정하므로, 자기 자신은 신원을 별로 검증하지 않는다. 이것을 곧장 MCP 도구로 노출하면 이렇게 된다.

agent가 손에 쥐는 것은 신원이 없는 인터페이스다 — ‘이 영업의 신원으로 조회’가 아니라 서비스의 권한으로 모든 것을 조회한다.
그 쓰기 동작은 발기인이 아니라 서비스의 권한으로 계산되어, 오류가 나도 책임을 물을 수 없다.
이 호출들은 어떤 비즈니스 감사 장부에도 들어가지 않아, 사후에 조회할 수가 없다(서두의 그 유출이 바로 이 조항에 걸렸다).

한마디로, 맨 인터페이스를 MCP 도구로 감싸는 것은 agent에게 슈퍼유저 통행증 한 장을 발급하는 것과 같다.

부족한 그 계층: 매 호출마다 신원, 권한, 흔적을 동반한다

프로토콜 위에 진짜로 보충해야 할 것은, 거버넌스되는 도구 계층이다 — agent가 호출하는 것이 맨 인터페이스가 아니라, 매 호출마다 사람과 똑같은 관문을 전부 거치는 한 무리의 통제된 동작이다.

거버넌스되는 도구 호출의 라이프사이클: 사용자 신원으로 발기, 런타임이 권한 검증, 통제된 실행, 감사에 기록

맨 인터페이스의 방식은 가운데 세 단계를 전부 생략하는 것인데, 생략되는 것이 하필 ‘해도 되는지’와 ‘장부에 기록하는지’다. 여기서 가장 간과되기 쉬운 것이 첫 단계 — 신원 전파다. agent는 반드시 발기인(그 영업)의 신원으로 호출해야지, 서비스 자신의 신원으로 해서는 안 된다. 일단 신원이 맞으면, ‘그는 자기 권역의 계약만 볼 수 있다’는 런타임이 강제할 수 있는 사실이 되지, 모델이 부디 지켜 주기를 바라는 프롬프트가 아니다.

agent가 다른 agent를 부르기 시작할 때: 신원을 어떻게 전달하나

신원 전파라는 일은, A2A(agent가 agent를 부르기)가 보편화된 뒤 더욱 치명적이 되고, 구멍이 나기도 가장 쉽다.

상상해 보자. 영업이 ‘영업 비서 agent’에게 “이 고객의 갱신 자료를 준비해 줘”라고 한다. 이 agent는 혼자서는 못 하니 ‘재무 agent’를 불러 결제 기한을 끌어오고, ‘계약 agent’를 불러 과거 조건을 가져온다. 이제 문제가 생긴다 — 재무 agent가 실행할 때, 누구의 권한을 쓰는가? 사슬 중간의 어느 한 홉(hop)이 신원을 잃어버려 ‘재무 agent 서비스 자신의 권한’으로 조회하게 되면, 이 영업은 일련의 agent 릴레이를 빌려, 본래 볼 권한이 없던 재무 정보를 본 셈이 된다. 월권은 첫 홉에서 일어나는 것이 아니라, 두 번째, 세 번째 홉에서 슬그머니 일어난다.

맨 인터페이스식 연결에서는 이런 ‘신원이 사슬 속에서 증발’하는 것이 거의 기본 결과이며, 게다가 통일된 감사 장부가 없어서 이 릴레이에서 도대체 누가 무엇을 봤는지 사후에 복원할 수가 없다. 거버넌스되는 도구 계층이 제대로 해야 할 일은, 발기인의 신원을 A2A 사슬 전체를 따라 끝까지 전달하는 것이다 — 매 홉마다 최초의 그 사람의 권한으로 검증되고 기록된다. 프로토콜(A2A)은 agent를 이어 붙이는 일을 맡지만, ‘릴레이 과정에서 권한이 유실되지 않고 흔적이 끊기지 않는’ 것은 프로토콜 뒤의 그 거버넌스 계층이 보장해야 한다.

당신의 도구 계층이 건강한지, 다섯 질문이면 점검할 수 있다

agent가 도구를 호출할 때, 동반하는 것은 발기인의 신원인가, 서비스의 신원인가?
한 번의 월권 호출이, 런타임에 즉석에서 차단되는가, 모델이 ‘알아서 안 하기’에 의존하는가?
매 도구 호출이 감사 장부에 들어가는가?
agent가 agent를 부를 때, 최초의 그 사람의 신원이 전달되는가?
권한 한 줄을 고치면, 한 곳에서 발효되는가, 모든 서버에서 한 번씩 고쳐야 하는가?

도구는 하나하나 손으로 쓸 것이 아니라, 정의에서 자라나야 한다

그러면 어떻게 손으로 쓰지 않으면서 기본적으로 안전하게 할까? 답은, 도구가 비즈니스 정의에서 자동으로 자라나게 하는 것이다. 당신은 객체와 권한을 선언한다 — 예를 들어 고객 응대 환불 시나리오라면 이렇다.

export const Refund = ObjectSchema.create({
  name: 'support_refund',
  fields: { amount: Field.currency({ label: '환불 금액', min: 0 }) },
});

export const AgentRole: Security.PermissionSet = {
  name: 'support_agent',
  objects: {
    support_refund: { allowRead: true, allowCreate: true, allowEdit: false, allowDelete: false },
  },
};

런타임(ObjectOS)은 그것을 자동으로 agent가 호출할 수 있는 한 무리의 거버넌스되는 도구로 투영한다. 조회, 환불 생성 — 각각에 위 권한의 검증이 내장되고, 로그인 사용자 신원으로 실행되며, 통일된 감사 장부에 기록된다. ‘환불 초과 시 결재로’는 객체에 걸린 프로세스라, 도구가 적중하면 자동으로 일시정지하고 서명을 기다린다 — 이것들은 모두 도구 코드 안에 손으로 쓸 필요가 없다. 권한 한 줄을 고치면, 관련된 모든 도구에 한 곳에서 발효된다.

위험한 버전과 대조해 보면 차이가 분명해진다.

// 맨 도구: 위험을 곧장 모델의 "자각"에 넘긴다
{ "name": "run_sql", "description": "임의의 SQL 쿼리 실행", "params": { "sql": "string" } }

당신은 도구마다 권한 코드를 쓰지 않고, 권한만 선언한다. 도구는 정의의 투영이다. MCP는 ‘어떻게 연결하는가’를 맡고, 이 계층은 ‘연결한 다음, 해도 되는지, 장부에 기록하는지’를 맡는다 — 게다가 손으로 쓸 필요가 없다.

먼저 찬물 한 바가지: 그것이 다스리는 것은 ‘할 수 있는가’이지 ‘해야 하는가’가 아니다

여기서 경계 하나를 분명히 그어야 한다. 그러지 않으면 그것을 신격화하기 쉽다.

거버넌스되는 도구 계층이 제약하는 것은 폭발 반경이지 판단력이 아니다. 그것은 agent가 권한 없는 일을 못 하게 보장할 수 있다 — 이것은 중요하다. 서두의 그 유출은 그것에 즉석에서 차단됐을 것이다. 하지만 그것은 ‘권한 안에 있으면서도 멍청한’ 동작을 막지 못한다. 어떤 고객 응대 agent가 본래 환불을 발기할 권한이 있다면, 환불해서는 안 될 한 건을 환불해도 도구 계층은 평소처럼 통과시킨다. 권한 안에 있기 때문이다.

다른 말로 하면, 그것이 해결하는 것은 ‘월권’과 ‘무흔적’이지, ‘결정이 옳은가 그른가’는 해결하지 못한다. 후자는 평가에 의존하고, 고위험 동작을 사람의 결재에 남기는 데 의존하고, 프로세스 설계에 의존해야 한다. 누군가 “거버넌스되는 도구 계층에 연결하면 agent는 절대 안전하다”고 한다면 그것은 과장이다. 그것은 필수적인 기반이지 건물 전체가 아니다 — 하지만 이 기반이 없으면 서두의 그 유출은 거듭 일어난다.

맺으며

MCP를 TCP/IP에 비유하는 것은 틀리지 않지만, 인터넷에서 값나가는 부분은 TCP/IP 위에 신원과 책임 추적의 계층이 자라난 뒤에야 생겼다는 것을 잊지 마라.

agent 생태계는 같은 순간에 놓여 있다. 연결은 이미 표준화됐고, 서두의 그 ‘도움이 되려던 한나절’은 점점 많아질 것이다 — 연결이 너무 쉬워졌기 때문이다. A2A가 agent를 사슬로 엮으면, 거버넌스 없는 연결은 월권을 더 깊이 숨길 뿐이다. 앞으로 1~2년 사이 진짜 희소하고 진짜 값나가는 것은, 또 하나의 연결 프로토콜이 아니라, 프로토콜 뒤에서 권한을 강제하고, 사슬을 따라 신원을 지키고, 흔적을 남기고, 게다가 손으로 쓸 필요 없는 도구 계층이다. 그것이 모든 것을 해결하지는 않지만, 그것이 없으면 나머지는 전부 출시할 엄두가 안 난다.

npm i -g @objectstack/cli && os start

객체 하나와 그 권한을 선언하고, agent가 도구를 통해 고칠 권한이 없는 데이터 한 줄을 월권으로 고치게 해 보라 — 런타임이 어떻게 즉석에서 차단하고, 이 시도조차 장부에 기록하는지 보라.