MCP 서버는 안전합니다. 하지만 그 뒤의 원장은 그렇지 않습니다.

최근 Unite.AI에 실린 글에서 Gil Feig는 안전한 MCP 서버를 구축하기 위한 6가지 모범 사례를 제시했습니다. 타당한 조언이며, MCP 서버를 출시하는 사람이라면 누구나 따라야 합니다. 각 통합에 “자체적인 세분화된 역할을 부여하고, 필요한 권한으로 엄격히 제한하라”는 그의 조언은 정확합니다. 하지만 이 조언은 상대 시스템에도 세분화된 역할이 있다는 점을 전제로 합니다. 여기에는 좀처럼 명시되지 않는 더 큰 전제가 담겨 있습니다. 바로 서버 뒤에 있는 시스템도 같은 수준으로 안전하게 보호할 수 있다는 것입니다.

비즈니스 소프트웨어에서는 그렇지 않은 경우가 많습니다. 저는 32개의 회계 및 ERP 시스템에 연결되는 통합 계층을 구축하는 엔지니어링 팀을 이끌고 있으며, 그 위에 선택적으로 MCP 서버를 얹을 수 있습니다. 우리 쪽에서는 인증과 권한 범위 설정, 로그 기록이 제대로 된 에이전트가 시스템에 데이터를 쓰지만, 그 시스템은 에이전트가 개입했다는 사실조차 알 방법이 없는 경우를 자주 봅니다.

이 글에서는 문제의 나머지 절반을 다룹니다. 업스트림 시스템이 실제로 무엇을 제공하는지, 통합 계층에서 무엇을 제어할 수 있는지, 그리고 그 제어가 어디에서 끝나는지 살펴봅니다.

MCP 명세가 책임을 넘기는 지점

해당 MCP 권한 부여 명세는 자체 경계를 명확히 규정한다. MCP 서버는 클라이언트를 위한 OAuth 리소스 서버다. 업스트림 API를 호출할 때는 업스트림 시스템이 발급한 별도의 토큰을 사용하는 별개의 OAuth 클라이언트로 동작한다. 클라이언트의 토큰을 그대로 전달하는 것은 명시적으로 금지되어 있다.

이는 올바른 설계입니다. 또한 누가 무엇을 할 수 있는지, 그 활동을 어떻게 기록하는지를 비롯해 업스트림 호출에 관한 모든 사항이 전적으로 업스트림 시스템에 달려 있다는 뜻이기도 합니다. 명세는 업스트림 시스템이 제공하지 않는 기능을 만들어낼 수 없습니다.

마찬가지로 과도한 자율성에 관한 OWASP 지침에도 해당한다. 이 지침은 에이전트의 확장 기능이 다른 시스템에서 보유하는 권한을 필요한 최소한으로 제한하고, 에이전트가 대리하는 사용자의 맥락에서 작업을 실행할 것을 권고한다. 두 가지 모두 좋은 조언이다. 두 가지 모두 다른 시스템에 최소 권한과 사용자 맥락을 표현할 방법이 있다고 전제한다.

업스트림 시스템이 실제로 제공하는 것

저희가 연결하는 32개의 회계 및 ERP 시스템을 통합업체의 관점에서 살펴보면 다음과 같습니다.

3분의 1은 OAuth를 전혀 지원하지 않는다

32개 시스템 중 21개는 OAuth를 사용합니다. 나머지 11개는 API 키, 사용자 이름과 비밀번호, 또는 한 쌍의 토큰 같은 정적 자격 증명에 의존합니다. 이러한 키 중 일부는 만료되지 않습니다. 널리 사용되는 한 시스템은 사용자가 존재하는 동안 API 토큰의 유효 기간에 제한이 없다고 문서에 명시하고 있습니다.

긴 유효 기간, 미흡한 폐기 기능

OAuth도 기대만큼 도움이 되지는 않습니다. 한 공급업체는 유효 기간이 약 20년인 갱신 토큰을 발급합니다. 이는 토큰을 사용하는 에이전트와 에이전트가 구축된 프레임워크보다 오래 지속되도록 설계된 자격 증명이며, 어쩌면 “허용”을 클릭한 사람보다도 오래갈 수 있습니다. 또 다른 시스템에서는 액세스 토큰조차 만료되지 않습니다.

자격 증명이 발급된 뒤에는 누가 이를 비활성화할 수 있는지가 문제입니다. 이를 위한 표준인 OAuth 토큰 폐기(RFC 7009)는 2013년부터 존재해 왔습니다. 그런데도 시스템 10개 중 대략 4개는 통합업체가 자격 증명을 폐기할 기술적 방법을 제공하지 않습니다. API 키를 사용하는 시스템은 모두 이 범주에 속합니다. 남은 유일한 방법은 고객에게 직접 액세스 권한을 삭제해 달라고 요청하는 것입니다.

세분화되지 않은 권한 범위, 에이전트 신원 정보의 부재

대부분의 정적 키는 키를 만든 사용자의 모든 권한을 그대로 물려받으며, 일부 시스템에서만 키의 권한을 개별 엔드포인트로 제한할 수 있습니다. 많은 OAuth 시스템에 권한 범위가 있기는 하지만, 대체로 “회계, 읽기 및 쓰기”처럼 세분화 수준이 낮습니다. 또한 32개 시스템 중 어느 곳에서도 API를 통해 하나의 거래에 에이전트와 에이전트가 대리하는 사람을 함께 기록하는 방법을 찾지 못했습니다. 외부 에이전트는 연결을 설정한 사용자 또는 일반 시스템 사용자로 표시됩니다. 흥미롭게도 벤더가 자체 제품에 에이전트를 구축한 경우에는, 예를 들어 Microsoft가 Business Central에서 한 것처럼, 에이전트에 전용 사용자 계정을 부여했습니다. 이는 아래에서 제가 권장하는 것과 같은 방식이지만, 벤더 자체 에이전트에만 적용됩니다.

통합 계층에서 강제할 수 있는 것

그렇다고 포기해야 한다는 뜻은 아닙니다. 에이전트와 회계 시스템 사이에서는 거의 모든 것을 제어할 수 있습니다.

• 자체 계층에 접속하는 에이전트별 자격 증명
• 예를 들어 송장에 대한 읽기 전용 액세스 등 자체적으로 설정하는 권한 범위
• 에이전트가 대리한 사람을 함께 기록하는 모든 에이전트 호출의 감사 로그
• 재시도하는 에이전트가 같은 송장을 두 번 기장하지 않도록 하는 멱등성 키
• 에이전트별 요청 속도 제한
• 쓰기 작업을 수행하기 전의 승인 단계

이러한 기능은 대상 시스템이 무엇을 지원하는지와 무관합니다. 통합 계층에서 충분한 역량을 갖춘 액세스 계층을 구축하는 일은 지금도 가능하며, 에이전트가 금융 데이터에 접근하는 환경이라면 반드시 구축해야 합니다.

제어가 끝나는 지점

할 수 없는 일은 이 계층을 시스템 경계 너머까지 확장하는 것이다. 그 경계를 넘어서면 세 가지 문제가 발생한다.

행위 귀속

회계 시스템에서는 에이전트가 기록한 내용이 연결을 승인한 사람의 이름으로 표시되거나 기술 사용자 계정으로 표시된다. 해당 시스템을 감사하는 사람은 그 사용자가 전표를 기록한 것으로 보게 된다. 사람이 처리했는지 에이전트가 처리했는지는 알 수 없다. 원장에서는 새벽 3시에 송장 400건을 처리하는 에이전트도 매우 성실한 재무 관리자와 똑같이 보인다. 이를 재구성하려면 통합업체의 로그가 필요한데, 이는 기록 시스템과는 별개의 신뢰 체계다. 포렌식 조사나 감사에서 이는 취약한 상황이다.

대부분의 조직도 이 문제에 앞서 있지는 않다. Cloud Security Alliance의 설문조사에서 모든 환경에 걸쳐 에이전트의 동작을 사람이나 시스템과 신뢰할 수 있게 연결해 추적할 수 있다고 답한 응답자는 28%에 불과했으며, 44%는 에이전트에 정적 API 키를 사용하거나 사용할 계획이라고 답했다.

최소 권한

에이전트가 송장만 읽도록 제한할 수는 있다. 하지만 대상 시스템에 범위 설정 기능이 없다면, 계층 뒤에 있는 자격 증명은 여전히 전체 접근 권한을 갖는다. 누군가 그 자격 증명을 손에 넣으면 계층과 그 계층에 설정한 모든 규칙을 완전히 우회할 수 있다.

접근 권한 철회

자체 에이전트의 접근을 즉시 차단할 수는 있다. 하지만 대상 시스템 자체에 대한 자격 증명이 유출되면 소용이 없다. 접근 권한을 철회하는 API 엔드포인트가 없는 시스템 10개 중 4개에서는 고객에게 이메일을 보내는 것이 긴급 차단 수단이다.

실용적인 해법: 에이전트 전용 사용자 계정

오늘 당장 할 수 있는 가장 유용한 일은 그다지 멋지지는 않다. 대상 시스템에 에이전트 전용 사용자 계정을 만들고, 오직 그 계정을 통해서만 에이전트를 연결하는 것이다.

사용자 계정을 만들 수 있는 모든 시스템에서 이 방법을 쓸 수 있으며, 통합 계층만으로는 얻을 수 없는 세 가지 이점을 제공한다.

• 기록 시스템에서 행위자를 식별할 수 있다. 전표에는 6개월 전에 ‘연결’을 클릭한 재무 관리자가 아니라 ‘AP 에이전트’가 기록자로 표시된다.
• API가 없어도 접근 권한을 철회할 수 있다. 고객은 인터페이스에서 해당 사용자를 비활성화할 수 있으며, 이 방법은 접근 권한 철회 API 엔드포인트가 없는 시스템에서도 작동한다.
• 부분적으로 최소 권한을 적용할 수 있다. 시스템에 어떤 형태로든 역할 모델이 있다면, 에이전트 사용자에게 실제로 필요한 모듈에만 접근 권한을 부여할 수 있는 경우가 많다.

실제로 비용이 든다. 온보딩 과정에서 누군가 직접 사용자를 만들어야 하므로, 하필 가장 번거로운 시점에 절차가 추가된다. 시스템의 약 절반은 사용자가 추가될 때마다 요금을 부과하는데, 중소기업용 도구는 월 몇 유로부터, 전체 ERP는 월 100유로를 넘는 경우까지 다양하다. 사용자를 요금제별로 제한하는 시스템도 여럿 있어 사용자 한 명을 더 추가하려면 회사 전체가 더 비싼 요금제로 바꿔야 할 수도 있다. 그리고 소유자가 없는 서비스 사용자는 그 자체로 위험이 되며, Unite.AI가 이전에 다룬 비인간 ID 확산의 일부가 된다. 다른 계정과 마찬가지로 이 계정에도 소유자와 검토일이 필요하다.

범위 설정 기능이 없는 시스템에서는 이 방법으로도 범위 설정 문제를 해결할 수 없다. 하지만 감사자가 실제로 확인하는 시스템 안에서 행위 귀속과 접근 권한 철회를 처리할 수 있게 된다.

구조적인 해법: 위임된 ID

이상적인 해법은 이미 문서상으로 존재한다. OAuth 2.0 토큰 교환(RFC 8693)은 가장과 위임을 구분한다. 위임 방식에서는 에이전트가 자체 ID를 유지하고, 토큰의 “act” 클레임을 통해 에이전트가 특정인을 대신해 행동한다는 사실을 기록한다.

이를 회계에 적용하면 다음과 같은 뜻이다.

• 원장에 이 에이전트가 이 사람을 대신해 전표를 기록했다는 사실이 남는다
• 범위는 사용자별이 아니라 위임 건별로 부여된다
• 사람의 계정에는 손대지 않고 위임 하나만 철회할 수 있다

내가 찾아본 바로는, 이와 유사한 기능을 지원하는 시스템은 32개 중 하나도 없었다. 따라서 지금으로서는 선택지가 아니라 지향점에 머물러 있다. 그러므로 이는 통합업체가 아니라 회계 및 ERP 소프트웨어 제공업체에 요구해야 할 사항이다. 에이전트는 이미 여러분의 원장에 기록을 남기고 있으므로, API도 그 사실을 나타낼 수 있어야 한다.

에이전트가 원장에 접근하기 전에 할 일

에이전트를 회계 또는 ERP 시스템에 연결한다면 다음의 간단한 점검 목록을 확인하자.

1. 각 대상 시스템의 자격 증명 모델을 파악한다. OAuth를 사용하는지 정적 키를 사용하는지, 자격 증명의 유효 기간은 얼마인지, 범위가 설정되어 있는지, 접근 권한을 철회할 수 있는지 확인한다.
2. 어떤 경우든 자체 접근 계층을 구축한다. 대상 시스템의 기능과 관계없이 에이전트별 ID, 범위, 멱등성 및 승인은 자체 계층에서 처리해야 한다.
3. 시스템에서 허용하는 경우 에이전트 전용 사용자를 둔다. 행위자를 식별하기 위한 비용으로 온보딩 작업과 라이선스 비용을 감수한다.
4. 자체 감사 기록은 변조 여부를 확인할 수 있도록 유지한다. 많은 시스템에서 에이전트가 관여했다는 사실을 보여 주는 유일한 기록이 될 것이다.
5. 잔여 위험을 기록하세요. 시스템에 권한 범위와 철회 기능이 없다면, 고객과 자체 위험 등록부에 그 사실을 명시하세요.

경계가 핵심이다

MCP 서버를 보호하는 것은 필수입니다. 하지만 그것만으로는 충분하지 않습니다. 원장에 기록하는 에이전트의 보안은 사용자 계층과 기록 시스템 사이의 경계에서 결정되며, 현재 그 경계는 사용자가 아니라 시스템이 설정합니다.

다행히도 이 격차는 명확히 규정되어 있습니다. 표준은 이미 마련되어 있습니다. 부족한 것은 장부를 관리하는 시스템의 표준 지원입니다.