GitHub Copilot CLI 1.0.90의 MCP OAuth 개선: AI 도구 권한을 서버 단위로 나누라는 신호

GitHub Copilot CLI 1.0.90 계열 업데이트에서 눈에 띄는 부분은 MCP OAuth 로그인과 도구 호출 신뢰성 개선입니다. 특히 GitHub 계정 인증을 승인된 MCP 서버 origin에 맞춰 제한하는 옵션은 작지만 중요한 변화입니다. AI 도구가 외부 시스템을 호출하는 방식이 많아질수록, 권한을 한 덩어리로 주는 방식은 위험해집니다.

MCP는 AI 모델이 파일, 이슈, PR, 데이터베이스, 사내 도구에 접근하기 위한 공통 인터페이스로 자리 잡고 있습니다. 편리하지만 동시에 권한 경계가 흐려지기 쉽습니다. “AI에게 GitHub 접근 권한을 준다”가 아니라 “어떤 MCP 서버가 어떤 GitHub 권한을 어떤 origin에서 쓸 수 있는가”로 질문을 바꿔야 합니다.

이번 글은 Copilot CLI 업데이트를 계기로, 개발팀이 MCP OAuth와 CLI 인증을 어떻게 바라봐야 하는지 정리합니다. 결론부터 말하면, AI 개발도구의 보안 단위는 이제 사용자 계정이 아니라 도구 서버, origin, scope, 감사 로그입니다.

MCP 권한은 편의 기능이 아니라 공격면입니다

MCP 서버 하나가 GitHub, Slack, Notion, 내부 API를 모두 호출할 수 있다면 모델은 매우 편해집니다. 하지만 보안 관점에서는 공격면이 넓어집니다. 프롬프트 인젝션, 잘못된 도구 선택, 권한 오설정, 로그 유출이 한 번에 연결될 수 있습니다.

예를 들어 문서 요약용 MCP 서버가 PR 수정 권한까지 가지고 있다면 문제가 됩니다. 사용자는 문서 요약만 요청했는데 모델이 잘못된 도구를 호출하거나, 외부 문서에 포함된 악성 지시문을 따라 PR을 만들 수 있습니다. 실제 사고는 거창한 해킹보다 권한 경계가 흐린 상태에서 시작되는 경우가 많습니다.

서버 단위 인증 제한은 이런 위험을 줄입니다. MCP 서버별로 허용 origin과 scope를 분리하면, 한 서버가 침해되거나 잘못 구성되어도 피해 범위를 줄일 수 있습니다. 이것은 웹 서비스에서 OAuth 앱별 권한을 나누는 것과 같은 원리입니다.

승인된 origin 개념이 중요한 이유

origin은 단순한 URL 문자열이 아닙니다. 어떤 클라이언트와 서버 조합에서 인증이 유효한지 정하는 경계입니다. AI CLI가 MCP 서버를 통해 GitHub에 접근할 때, 승인되지 않은 origin에서도 같은 인증이 통하면 권한 탈취나 혼동 가능성이 커집니다.

개발팀에서는 다음 질문을 해야 합니다.

• 이 MCP 서버는 누가 운영하는가
• 로컬 서버인지 원격 서버인지 구분되어 있는가
• GitHub 인증이 어떤 origin에서만 허용되는가
• 개인 계정 토큰과 조직 앱 권한이 섞여 있지 않은가
• 서버 로그에 토큰이나 민감한 응답이 남지 않는가

이 질문에 답하지 못하면 아직 운영 준비가 덜 된 것입니다. AI 도구는 사용성이 좋아서 빠르게 퍼지지만, 권한 모델은 보통 뒤늦게 정리됩니다. 그 사이에 개발자 개인 토큰이 사실상 팀 자동화 토큰처럼 쓰이는 일이 생깁니다.

모델 오류와 권한 오류를 분리해야 합니다

AI CLI에서 “도구 호출 실패”가 발생하면 많은 사용자가 모델이 잘못했다고 생각합니다. 하지만 실제 원인은 권한 부족, OAuth 만료, origin 미승인, rate limit, 서버 응답 스키마 변경일 수 있습니다. 이 원인을 분리하지 않으면 디버깅 시간이 길어집니다.

로그 설계가 필요합니다. 최소한 아래 필드는 남아야 합니다.

• 호출한 MCP 서버 이름
• 사용한 도구 이름
• 요청한 OAuth scope
• origin 또는 client id
• 응답 상태 코드
• 모델 판단 로그와 도구 실행 로그의 분리 여부
• 민감 정보 마스킹 여부

이 정보가 있어야 보안팀과 개발팀이 같은 화면을 볼 수 있습니다. 모델이 잘못 도구를 골랐는지, 도구 권한이 없었는지, OAuth 정책이 막은 것인지 구분할 수 있습니다.

Copilot CLI 업데이트를 보고 팀이 바꿔야 할 운영 기준

이번 흐름에서 배울 점은 “CLI도 SaaS 제품처럼 권한 설계를 해야 한다”는 것입니다. 예전에는 CLI가 개인 로컬 도구에 가까웠습니다. 이제 AI CLI는 레포를 읽고, 이슈를 만들고, PR을 고치고, 배포 로그까지 볼 수 있습니다. 사실상 사내 자동화 클라이언트입니다.

운영 기준은 다음처럼 잡는 것이 좋습니다.

1. 개인 토큰 대신 조직 승인 OAuth 앱을 우선 사용합니다.
2. MCP 서버마다 필요한 최소 scope만 부여합니다.
3. 읽기 전용 서버와 쓰기 가능 서버를 분리합니다.
4. 승인된 origin 목록을 코드 리뷰 대상에 넣습니다.
5. 로컬 개발용 MCP와 운영 자동화용 MCP를 분리합니다.
6. 도구 호출 로그는 30일 이상 보관하되 토큰은 저장하지 않습니다.
7. 권한 변경은 PR 또는 변경 요청으로 남깁니다.

이 정도만 해도 “AI가 뭘 했는지 모르는 상태”를 크게 줄일 수 있습니다.

작은 업데이트를 크게 봐야 하는 이유

MCP OAuth 개선은 화려한 모델 발표가 아닙니다. 하지만 개발 조직에는 더 직접적인 의미가 있습니다. 앞으로 AI 도구는 더 많은 시스템을 연결할 것이고, 연결이 늘어날수록 권한 분리가 생산성의 전제가 됩니다. 보안팀이 막아서 느려지는 것이 아니라, 권한이 정리되어 있어야 개발팀이 안심하고 자동화를 키울 수 있습니다.

지금 팀이 해야 할 일은 거창하지 않습니다. 사용 중인 MCP 서버 목록을 만들고, 각 서버가 가진 GitHub 권한을 적어 보세요. 읽기만 필요한데 쓰기 권한이 있다면 줄이고, 개인 토큰으로 돌고 있다면 조직 승인 앱으로 옮기는 계획을 세우면 됩니다.

마지막 체크리스트입니다.

• MCP 서버 목록과 담당자를 문서화했는가
• 서버별 OAuth scope가 최소 권한인지 확인했는가
• 승인된 origin을 명시적으로 관리하고 있는가
• 개인 GitHub 토큰이 팀 자동화에 쓰이지 않는가
• 읽기 전용 도구와 쓰기 가능 도구를 분리했는가
• 도구 호출 로그에서 모델 판단과 API 실행을 구분하는가
• 토큰, 응답 본문, 개인정보 마스킹 기준이 있는가
• 권한 변경 이력이 PR이나 변경 요청으로 남는가