MCP 커넥터 공유 계정과 사용자별 권한

MCP 커넥터가 계정 하나를 공유하면 생기는 일

MCP 커넥터를 팀 작업 공간에 붙였는데 인증 창이 처음 딱 한 번만 떴다면, 그 커넥터는 공용 계정 하나로 업스트림에 로그인한 것입니다. 그 뒤로는 누가 질문하든 에이전트가 보는 범위는 같습니다. 그 계정이 볼 수 있는 전부입니다. 팀원 각자가 원래 가지고 있던 열람 권한은 이 경로에서 아무 일도 하지 않습니다.

MCP(Model Context Protocol)는 AI 에이전트가 바깥 도구와 데이터에 닿는 방법을 정한 규격이고, 커넥터는 그 규격을 구현한 서버입니다. 규격은 전송 방식과 인가 절차를 정합니다. "이 사람이 이 문서를 볼 수 있는가"는 정해 주지 않습니다. 그 답은 커넥터가 요청에 어떤 자격증명을 붙이느냐에서 나옵니다. 그래서 이것은 설정 실수가 아니라 구조 선택의 결과입니다.

모양은 두 가지뿐입니다. 서버가 API 키나 서비스 계정 토큰 하나를 들고 전원을 대신하는 방식, 그리고 사람마다 자기 계정으로 직접 인가하는 사용자별 OAuth 방식입니다. 아래에서는 두 모양이 각각 무엇을 보장하고 무엇을 보장하지 않는지 보고, 커넥터를 고르거나 바꿀 때 그대로 쓸 수 있는 확인 목록으로 정리합니다. 이 글은 설치 안내가 아니라 선택과 구조에 대한 글이라 명령어는 나오지 않습니다.

토큰 하나를 들고 있는 커넥터는 모두를 한 사람으로 만듭니다

설정 파일에 NOTION_API_KEY 한 줄이 있거나, 서비스 계정 JSON 파일 경로가 적혀 있거나, 사내 API의 마스터 키가 환경변수로 들어가 있다면 이 방식입니다. 커넥터는 요청마다 그 토큰 하나를 붙입니다. 업스트림 서비스는 요청에 붙은 자격증명만 보고 권한을 판단합니다. 자격증명이 하나면 요청자도 한 명입니다. 그래서 사람별로 걸러 줄 재료 자체가 서버 쪽에 존재하지 않습니다.

여기서 나오는 결과는 네 가지입니다. 첫째, 팀에서 가장 권한이 넓은 사람이 아니라 그 토큰이 가진 권한이 모두의 권한이 됩니다. 둘째, 인사 자료나 미공개 계약서처럼 원래 몇 명만 보던 문서도 그 계정이 볼 수 있으면 에이전트가 요약해 줍니다. 셋째, 업스트림 감사 로그에는 봇 계정 이름만 남습니다. 넷째, 사람 한 명의 접근만 끊고 싶어도 방법이 토큰 교체뿐이라 전원이 함께 끊깁니다.

커넥터 코드 안에 "이 사용자에게는 이 폴더만" 같은 필터를 넣은 구현도 있습니다. 그건 커넥터가 스스로 집행하는 권한이고, 업스트림 쪽은 여전히 전부 열려 있는 상태입니다. 커넥터에 버그가 하나 생기거나 도구 인자 하나가 예상 밖의 값으로 들어오면 그 필터는 조용히 사라집니다. 게다가 필터가 모델의 판단에 기대고 있다면 그건 강제가 아니라 부탁입니다. 문서 본문에 심어 둔 지시문 한 줄이 그 부탁을 뒤집을 수 있고, 이런 경로는 에이전트가 읽은 내용이 그대로 지시가 되는 문제와 뿌리가 같습니다.

사용자별 OAuth는 무엇이 다른가

사용자별 OAuth에서는 팀원 각자가 브라우저에서 자기 계정으로 로그인하고 동의합니다. 커넥터는 사람마다 다른 액세스 토큰을 보관하고, 요청을 보낼 때 그 사람의 토큰을 씁니다. 권한 집행은 업스트림이 계속 맡습니다. 볼 수 없는 문서는 API가 403이나 404로 돌려주고, 그 판단을 내리는 쪽은 커넥터가 아니라 원래 시스템입니다. 그래서 커넥터 코드에 버그가 있어도 권한 경계는 그대로 남습니다.

MCP 인가 사양은 이 모양을 표준으로 적어 두었습니다. 2026년 9월 22일에 확인한 MCP 인가 사양 문서 기준으로, HTTP 전송을 쓰는 MCP 서버는 OAuth 2.1의 리소스 서버 역할을 합니다. 서버는 RFC 9728 보호 리소스 메타데이터를 제공해야 하고, 클라이언트는 그 메타데이터를 읽어 인가 서버를 찾습니다. 토큰은 그 MCP 서버를 대상(audience)으로 발급된 것이어야 하며, 서버는 이 대상 검증을 해야 합니다. 사양은 다른 곳에서 발급된 토큰을 받지도 말고 그대로 아래로 흘려보내지도 말라고 못 박습니다. 그 안티패턴의 이름이 토큰 패스스루(token passthrough)입니다.

권한이 모자라면 서버는 필요한 범위를 응답 헤더에 실어 돌려줍니다. 같은 문서에 실린 예시는 이렇게 생겼습니다.

HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

이 응답을 받은 클라이언트는 기존 범위에 files:write를 더해 다시 인가를 받습니다. 처음부터 전체 권한을 받아 두지 않고 필요한 순간에 올리는 방식이라, 사용자가 보는 동의 화면의 항목이 짧아집니다. 사양은 서버가 scopes_supported에 기본 동작에 필요한 최소 범위만 적기를 권합니다. 반대로 all이나 full-access 같은 뭉뚱그린 범위를 요구하는 커넥터는, 토큰이 한 번 새면 피해 범위가 그 뭉치 전체가 됩니다.

여기에 중요한 단서가 하나 붙습니다. 같은 사양은 stdio 전송을 쓰는 구현이 이 인가 절차를 따르지 말고 실행 환경에서 자격증명을 가져오라고 적습니다. 노트북에서 프로세스로 띄우는 로컬 MCP 서버 대부분이 여기 해당합니다. 즉 그 서버들은 구조상 환경변수에 든 토큰 하나로 동작합니다. 그 토큰이 회사 공용 계정 것이라면, 로컬에서 돈다는 사실과 무관하게 공용 계정 커넥터입니다.

권한을 집행하는 쪽이 커넥터인지 원래 시스템인지 확인하세요

커넥터를 평가할 때 던질 질문은 하나로 줄일 수 있습니다. 접근을 거절하는 주체가 누구인가. 원래 시스템이 거절한다면 그 커넥터는 권한 모델을 새로 만들지 않았고, 기존 권한 설정이 그대로 살아 있습니다. 커넥터가 거절한다면 권한 모델이 하나 더 생긴 것이고, 그 모델은 담당자가 따로 관리해야 하며 업스트림 설정과 언젠가 어긋납니다.

확인 방법은 간단합니다. 본인 계정으로는 열리지 않는 문서를 하나 고르세요. 사내 위키의 비공개 공간이나 다른 팀의 드라이브 폴더면 충분합니다. 그다음 에이전트에게 그 문서의 내용을 물어보세요. 요약이 돌아오면 커넥터는 내 권한이 아니라 다른 신원으로 접근하고 있습니다. 업스트림이 막아 준다면 도구 호출은 권한 오류로 끝나고, 에이전트는 접근할 수 없다고 답합니다. 이 시험은 문서를 읽는 것보다 빠르고, 벤더 설명보다 정확합니다.

감사 로그가 "봇이 했다"까지만 말할 때

사고 조사는 로그에서 시작합니다. 공용 계정 커넥터를 쓰면 업스트림 로그의 모든 줄에 서비스 계정 이름 하나만 찍힙니다. 어느 팀원의 요청이 그 조회를 일으켰는지는 그 로그 안에 없습니다. MCP 보안 모범 사례 문서도 토큰 패스스루의 위험으로 같은 문제를 듭니다. 다운스트림 서비스의 로그가 실제로 요청을 보낸 주체가 아니라 다른 신원으로 보이기 때문에 조사와 통제가 어려워진다는 것입니다.

내부 감사나 개인정보 처리 현황 점검에서는 "누가 언제 무엇을 조회했는가"를 묻습니다. 공용 계정은 이 질문에 답하지 못합니다. 대화 로그를 대신 내밀 수도 있지만, 그건 에이전트 쪽 기록이고 데이터를 보관하는 시스템의 기록이 아닙니다. 두 기록을 사람이 손으로 맞춰야 한다면 그 절차는 사고가 난 다음 주에 작동하지 않습니다.

커넥터를 고르거나 교체할 때 쓰는 체크리스트

1. 사용자별 OAuth를 지원하는가. 벤더 문서에서 사용자별 인증이나 per-user OAuth 같은 표현과 동의 화면 이미지를 찾으세요. 설치 안내가 API 키 발급으로 시작한다면 공용 토큰 방식입니다.
2. 승인 전에 범위가 보이는가. 동의 화면에 요구 범위가 항목으로 나오는지, 읽기만 필요한 일에 쓰기 권한까지 요구하지 않는지 보세요. 범위를 보여 주지 않는 화면에서는 무엇을 승인했는지 나중에 확인할 방법이 없습니다.
3. 집행 주체가 업스트림인가. 위의 비공개 문서 시험을 그대로 해 보세요. 커넥터가 자체 필터로 막는 구조라면 관리할 권한 모델이 하나 늘어난 것입니다.
4. 감사 로그에 사람 이름이 남는가. 업스트림 로그에서 최근 한 건을 골라 실제 사람과 연결할 수 있는지 확인하세요. 봇 이름만 나온다면 그게 사고 당일 받게 될 로그입니다.
5. 사람이 나갈 때 접근이 어떻게 끝나는가. 계정 비활성화로 끝나는지, 토큰을 따로 회수해야 하는지, 회수하면 다른 사람 것까지 끊기는지 미리 확인하세요.
6. 토큰이 어디에 저장되고 누가 읽을 수 있는가. 설정 파일에 평문으로 남는지, 모델 컨텍스트에 실려 들어갈 여지가 있는지 보세요. 이 부분은 자격증명을 에이전트 컨텍스트 밖에 두는 방법에서 따로 다룹니다.
7. 확인한 날짜를 적어 두세요. 커넥터의 인증 방식은 공지 없이 바뀝니다. 오늘 공용 토큰만 지원하던 제품이 다음 분기에 사용자별 OAuth를 추가하기도 하고, 그 반대 방향의 축소도 일어납니다. 그래서 이 글은 특정 제품이 지금 어떤 방식인지 단정하지 않습니다. 판단 기준만 제공하고, 확인은 각 제품의 현재 문서에서 하세요.

내 VPS에 직접 올린 MCP 서버라면 어떻게 하나

사내용으로 직접 만든 MCP 서버에는 사용자별 OAuth를 붙이기 어려운 경우가 많습니다. 업스트림이 사내 API인데 그 API가 OAuth를 지원하지 않고 발급된 키만 받는다면, 사용자별 토큰이라는 것이 애초에 존재하지 않습니다. 이때 정직한 답은 공용 토큰을 쓰되 그 토큰이 대신하는 사람의 수를 줄이는 것입니다. 구조를 어떻게 잡을지는 MCP 서버를 VPS에 직접 올려 운영하는 방법에서 더 자세히 다룹니다.

먼저 인스턴스를 나눕니다. 서버 하나에 모두의 요청을 받게 하지 말고, 사람마다 또는 역할마다 인스턴스를 따로 띄우고 각 인스턴스에는 그 역할의 키만 넣습니다. 영업팀 인스턴스는 영업 데이터만 읽는 키를 가지고, 개발팀 인스턴스는 다른 키를 가집니다. 이렇게 하면 한 사람의 접근을 끊는 일이 그 인스턴스의 키 하나를 교체하는 일로 줄어듭니다. 인스턴스를 늘리는 비용은 서버가 요청 사이에 상태를 들고 있지 않을 때 가장 싸지고, 그 설계는 상태를 보관하지 않는 MCP 서버 설계 쪽에서 설명합니다.

다음은 키의 범위입니다. 읽기만 하는 에이전트에게는 읽기 전용 키를 주세요. 쓰기 권한은 실제로 쓰기를 시키는 인스턴스에만 줍니다. 범위를 좁히는 일은 토큰이 샜을 때의 피해를 줄이는 동시에, 에이전트가 예상 밖의 도구를 잘못 호출했을 때의 피해도 같이 줄입니다.

세 번째는 계정입니다. 담당자 본인의 사번 계정으로 키를 발급해 서버에 넣는 관행이 가장 흔하고 가장 나쁩니다. 그 사람이 휴직하거나 부서를 옮기면 서비스가 멈추고, 로그에는 그 사람이 한 것으로 남습니다. 에이전트 전용 계정을 따로 만들고 필요한 권한만 부여하세요. 이유와 발급 방법은 에이전트에게 사람 계정이 아닌 자기 신원을 주는 이유에 정리해 두었습니다.

네 번째는 앞단입니다. MCP 서버 자체가 사용자를 구분하지 못하더라도, 앞에 인증 프록시를 두면 최소한 어떤 사람이 어떤 인스턴스에 접속했는지는 기록으로 남습니다. 직접 운영하는 Authentik SSO를 앞에 세우고 인스턴스별로 접근 그룹을 나누면, 사람 단위의 접속 기록과 퇴사 시 일괄 차단이라는 두 가지를 한 번에 얻습니다. 완전한 사용자별 권한은 아니지만, 아무것도 없는 상태와는 크게 다릅니다.

마지막은 격리입니다. 인스턴스를 나눴는데 모두 같은 디렉터리의 같은 설정 파일을 읽는다면 나눈 의미가 없습니다. 컨테이너마다 별도 사용자와 별도 볼륨을 주고, 키 파일의 소유자와 모드를 그 사용자에게 맞추세요. 컨테이너 안팎에서 사용자 번호가 어긋나 파일이 엉뚱하게 열리는 상황은 PUID와 PGID가 컨테이너 파일 권한을 어떻게 정하는지를 보면 대부분 정리됩니다. 참고로 MCP 사양은 세션을 인증 수단으로 쓰지 말라고 하고, 세션 식별자를 사용자 식별자와 묶어 보관하라고 권합니다. 인스턴스를 나눌 때도 같은 원칙이 적용됩니다.

회사 계정과 개인 계정을 한 노트북에서 섞을 때

한국에서 아주 흔한 상황이 하나 있습니다. 같은 노트북에 회사 계정과 개인 계정을 함께 로그인해 두고 쓰는 경우입니다. 회사 구글 워크스페이스와 개인 지메일, 회사 노션과 개인 노션이 브라우저 프로필만 다른 채로 한 기기에 있습니다. 문제는 MCP 클라이언트의 커넥터 설정이 보통 사용자 단위 파일 하나라는 점입니다. 회사 커넥터와 개인 커넥터가 같은 목록에 올라가고, 에이전트는 그 목록에 있는 도구를 필요하다고 판단하면 씁니다.

그래서 "회사 위키에서 이번 분기 내용을 정리해서 내 노션에 넣어 줘"라는 한 번의 요청이 사내 자료를 개인 계정 공간으로 옮깁니다. 악의도 실수도 아니고, 시킨 대로 한 것입니다. 반대 방향도 같습니다. 개인 자료가 회사 공간에 들어가면 그건 회사 기록이 됩니다. 두 경우 모두 나중에 되돌리기 어렵습니다.

규칙 하나면 대부분 정리됩니다. 회사 데이터를 읽는 커넥터와 개인 데이터에 쓰는 커넥터를 같은 프로필에 두지 않습니다. 클라이언트가 프로필이나 작업 공간 분리를 지원하면 그것을 쓰고, 지원하지 않으면 회사용 커넥터는 회사 장비에만 둡니다. 개인 계정 자격증명으로 회사 자료에 접근하는 커넥터는 퇴사할 때 회수할 방법이 없습니다. 반대로 회사 계정 키를 개인 노트북의 로컬 서버 설정 파일에 넣어 두면, 그 파일은 회사의 자산 관리 밖에 있는 사본이 됩니다. 어느 쪽이든 경계는 사람이 기억하는 것이 아니라 설정이 지켜 주어야 합니다.

사람이 나가면 그 접근은 어떻게 끝나는가

사용자별 OAuth라면 답이 짧습니다. 계정을 비활성화하면 그 사람 몫의 토큰이 무효가 됩니다. 정확히는 인증 서버가 계정 비활성화 시 액세스 토큰과 갱신 토큰을 무효로 처리하도록 설정되어 있어야 하므로, 퇴사 처리 절차에 그 단계가 들어 있는지 한 번은 확인해야 합니다. 확인하는 방법은 실제로 한 건 해 보는 것입니다. 이동한 동료의 계정을 막은 뒤, 그 사람 이름으로 남던 조회 기록이 멈추는지 업스트림 로그에서 보면 됩니다.

공용 토큰이라면 답이 깁니다. 그 토큰 값을 아는 사람이 퇴사하면 회수 수단은 토큰 교체뿐이고, 교체하는 순간 그 커넥터를 쓰던 전원이 끊깁니다. 그래서 교체가 미뤄지고, 미뤄진 토큰은 계속 유효합니다. 인사이동도 같은 문제입니다. 부서가 바뀌면 볼 수 있는 범위가 바뀌어야 하는데 공용 토큰의 범위는 그대로입니다. 앞에서 인스턴스를 사람이나 역할 단위로 나누라고 한 이유가 여기 있습니다. 나눠 두면 교체가 한 사람에게만 영향을 줍니다.

정리하면 선택 기준은 단순합니다. 팀이 여러 명이고 업스트림에 이미 권한 설정이 있다면 사용자별 OAuth를 지원하는 커넥터를 고르세요. 그런 커넥터가 없고 직접 운영해야 한다면 공용 토큰을 쓰되 인스턴스를 쪼개고 범위를 좁히고 전용 계정을 쓰세요. 어느 쪽이든 마지막 확인은 같습니다. 오늘 업스트림 로그를 열었을 때 거기에 사람 이름이 보이는가.

FAQ

쓰고 있는 MCP 커넥터가 사용자별 OAuth인지 어떻게 확인하나요?

가장 빠른 확인은 두 번째 사람입니다. 동료가 같은 커넥터를 처음 쓸 때 브라우저 동의 화면이 뜨면 사용자별 OAuth입니다. 아무 창도 없이 바로 동작하면 공용 자격증명을 쓰고 있습니다. 확실히 하려면 본인 계정으로 열리지 않는 문서를 에이전트에게 물어보세요. 내용이 돌아온다면 그 커넥터는 내 권한이 아닌 다른 신원으로 접근하는 중입니다. 설정 파일에 API 키나 서비스 계정 파일 경로가 적혀 있는지도 같이 보세요.

프롬프트나 시스템 지시로 "이 사람에게는 보여 주지 마"라고 정하면 안 되나요?

그건 권한 설정이 아니라 부탁입니다. 토큰이 이미 그 데이터에 접근할 수 있다면 데이터는 모델이 읽을 수 있는 자리까지 들어옵니다. 그 뒤의 필터는 모델의 판단에 달려 있고, 문서 본문에 섞인 지시문이나 예상 밖의 질문 형태로 뒤집힐 수 있습니다. 접근 통제는 요청이 업스트림에 닿기 전에, 자격증명 단계에서 끝나야 합니다.

사내 API가 API 키만 지원하면 사용자별 권한은 포기해야 하나요?

표준적인 사용자별 OAuth는 포기하게 됩니다. 대신 대신하는 사람 수를 줄이세요. 역할이나 사람 단위로 MCP 서버 인스턴스를 따로 띄우고, 각 인스턴스에 그 역할에 필요한 최소 권한의 키만 넣습니다. 앞단에 SSO 프록시를 두면 누가 어느 인스턴스에 접속했는지는 기록으로 남습니다. 완전하지는 않지만 퇴사자 차단과 사고 조사가 모두 가능해집니다.

회사 계정 커넥터와 개인 계정 커넥터를 한 클라이언트에 같이 둬도 되나요?

권하지 않습니다. 클라이언트는 등록된 도구를 모두 후보로 보고, 한 번의 요청이 회사 자료를 개인 공간으로 옮기는 일이 실제로 일어납니다. 프로필이나 작업 공간을 분리해 회사용과 개인용을 다른 목록에 두세요. 분리 기능이 없다면 회사 커넥터는 회사 장비에만 설정하는 편이 안전합니다.