AI에게 “내 GitHub issue를 보고 오늘 먼저 볼 일을 정리해줘”라고 말했는데, 답이 어딘가 비어 있을 때가 있다.

이상한 일이 아니다. AI는 내가 권한을 열어주지 않은 issue, 캘린더, Drive 문서를 그냥 볼 수 없다. 이 글에서 가져갈 기준은 단순하다. AI가 일을 잘 못한 것이 아니라, 지금 필요한 자료를 볼 통로가 없었는지 먼저 보자는 것이다.

예를 들어 이런 장면이다.

  • 고객 미팅 전에 캘린더와 회의 메모를 같이 본다.
  • GitHub issue 목록을 보고 오늘 손댈 순서를 정한다.
  • Drive 문서 여러 개에서 최신 정책 문구만 찾아온다.
  • 배포 뒤 확인해야 할 화면과 체크 결과를 한곳에 모은다.

이 요청들은 모두 “AI가 지금 바깥에 있는 자료를 볼 수 있는가”라는 문제로 이어진다. 여기서 MCP(Model Context Protocol)가 나온다. 어려운 이름을 잠깐 빼고 말하면, MCP는 AI 앱이 외부 자료와 도구를 정해진 방식으로 연결하기 위한 통로다.

혼자 아는 AI와 연결된 AI를 나누고, 연결된 AI가 MCP 서버를 거쳐 도구와 자료에 접근하기 전에 권한을 확인하는 구조.

이미지는 이 글의 핵심 구분을 보여준다. 혼자 아는 AI는 대화에 들어온 말만 본다. 연결된 AI는 MCP 서버에서 도구와 자료를 보지만, 그 앞에는 권한 확인이 있어야 한다.

먼저 문제는 기억력이 아니다

AI가 내 문서를 모른다고 해서 모델의 기억력이 부족한 것은 아니다.

대부분의 경우 이유는 더 단순하다. 그 문서가 대화에 없고, AI 앱에도 그 문서를 읽는 연결이 없었던 것이다. 캘린더도, issue도, 고객지원 문서도 마찬가지다.

그래서 “왜 이걸 모르지?”라고 묻기 전에 이렇게 나눠보는 편이 낫다.

  • 지금 대화에 이미 들어온 내용인가.
  • 파일이나 문서를 내가 직접 붙여넣었는가.
  • AI 앱이 외부 서비스에 연결되어 있는가.
  • 연결되어 있다면 읽기만 가능한가, 바꾸기도 가능한가.

첫 두 항목이면 프롬프트나 첨부 문제다. 마지막 두 항목이면 연결과 권한 문제다. MCP는 이 중에서 연결과 권한을 생각할 때 나오는 말이다.

MCP는 공용 출입문이다

서비스마다 따로 문을 만드는 방법도 있다.

어떤 AI 앱은 GitHub 연결을 따로 만들고, 어떤 앱은 캘린더 연결을 따로 만든다. 또 다른 앱은 문서 저장소 연결을 별도로 둔다. 한두 개는 괜찮지만, 연결이 늘어날수록 앱마다 방식이 달라진다.

MCP는 이 부분을 줄이려는 약속이다. 공식 MCP 문서는 MCP를 AI 애플리케이션에 context를 제공하는 공개 표준으로 설명한다. 여기서 context는 모델이 판단할 때 보는 자료, 도구, 상태를 뜻한다.

쉽게 말하면 이렇다.

AI 앱이 외부 자료와 도구를 매번 새 방식으로 붙이지 않도록,
서로 알아들을 수 있는 공용 출입문을 정한 것.

공용 출입문이 생기면 연결 방식은 단순해진다. 하지만 그 문으로 누가 들어오고, 무엇을 들고 나가는지는 따로 확인해야 한다. 그래서 MCP를 이해할 때는 “편한 연결”과 “권한 경계”를 항상 같이 봐야 한다.

실제 장면에 붙이면 더 쉽다

Drive 문서 검토를 예로 들어보자.

AI에게 “최근 계약서 초안에서 개인정보 관련 문구만 찾아서 검토해줘”라고 부탁했다고 하자. AI에 Drive 연결이 없다면 내가 문서를 하나씩 열고, 내용을 복사해서 붙여넣어야 한다. 문서가 두세 개면 괜찮지만, 폴더 단위가 되면 금방 힘들어진다.

MCP로 연결된 문서 서버가 있다면 흐름은 달라진다. AI 앱은 연결된 서버에 문서 검색과 읽기가 허용됐는지 묻는다. 서버는 허용된 범위 안에서 검색 결과나 문서 내용을 돌려준다. AI는 그 결과를 보고 답한다.

GitHub issue도 비슷하다.

issue 목록을 복사해서 붙여넣으면 한 번은 된다. 하지만 issue가 바뀌면 다시 복사해야 한다. 연결된 서버가 조회 기능을 제공하면 AI는 현재 issue 목록을 읽고 우선순위 초안을 만든다.

캘린더는 더 조심해야 한다. 일정을 읽는 것과 새 일정을 만드는 것은 위험도가 다르다. 회의 시간을 확인하는 정도는 읽기 권한에 가깝지만, 일정을 삭제하거나 초대장을 보내는 일은 쓰기 권한이다. 같은 “캘린더 연결”이어도 권한이 전혀 다르다.

읽기와 쓰기를 나누면 장면이 더 선명해진다.

문서 검토: 문서 검색, 문서 읽기 -> 먼저 열어볼 만함
issue 정리: issue 조회, label 변경 -> 조회와 변경을 분리해야 함
캘린더 확인: 일정 읽기, 일정 생성/삭제 -> 쓰기는 승인 뒤에만 열어야 함
배포 확인: 상태 조회, 배포 실행 -> 실행은 되돌리기 어려운 행동으로 봐야 함

서비스 이름보다 이 구분이 먼저다. “캘린더 MCP”라는 말만으로는 충분하지 않다. 읽기 전용인지, 일정 생성과 삭제까지 허용하는지 확인해야 한다.

처음에는 네 역할만 보면 된다

MCP를 설명하는 글에는 여러 기술 용어가 나온다. 처음부터 다 외울 필요는 없다.

먼저 아래 네 역할만 보면 흐름이 보인다.

  • AI 앱: 내가 말을 거는 화면이다. 채팅 앱, 코딩 에이전트, 업무용 AI 도구가 여기에 들어간다.
  • MCP 서버: 외부 서비스와 AI 앱 사이에서 자료나 기능을 내보내는 쪽이다.
  • 도구: issue 조회, 문서 검색, 일정 생성처럼 어떤 일을 실행하는 기능이다.
  • 자료: 문서 내용, 파일 목록, 일정 정보처럼 AI가 읽고 판단에 쓰는 내용이다.

AI 앱이 연결 담당자를 거쳐 MCP 서버와 만나고, 서버가 도구와 자료를 내보내는 흐름.

이 그림은 직접 연결을 만들거나 문제를 찾을 때 보는 조금 더 자세한 지도다. 처음 읽을 때는 AI 앱, MCP 서버, 도구, 자료만 먼저 봐도 된다.

요청은 AI 앱으로 들어간다. AI 앱은 연결된 MCP 서버가 무엇을 제공하는지 확인한다. 서버는 허용된 도구나 자료를 돌려준다. AI는 그 결과를 보고 답하거나 다음 행동을 제안한다.

이 정도만 알아도 처음 판단에는 충분하다. host, client, transport, JSON-RPC 같은 말은 직접 서버를 만들거나 연결 문제를 디버깅할 때 천천히 봐도 된다. 초반에는 “어떤 자료를 읽고, 어떤 행동을 실행하는가”가 더 중요하다.

MCP가 바꾸는 것은 현재성이다

MCP가 있다고 AI가 갑자기 모든 일을 더 잘하는 것은 아니다.

달라지는 지점은 “지금 상태”를 가져오는 방식이다. 모델은 예전에 학습한 정보 대신 연결된 서버가 방금 돌려준 issue, 일정, 문서, 파일 상태를 본다.

나는 MCP의 쓸모를 세 가지로 나눴다.

  • 현재 자료를 본다. 최신 문서, 열린 issue, 오늘 일정처럼 계속 바뀌는 자료에 맞다.
  • 반복 복사를 줄인다. 매번 목록을 붙여넣는 대신 연결된 서버에서 가져온다.
  • 정해진 행동을 맡긴다. 조회만이 아니라 label 변경, 일정 생성, 문서 검색 같은 도구 호출도 후보가 된다.

다만 세 번째가 나오면 바로 권한 문제가 따라온다. 조회는 비교적 되돌리기 쉽지만, 수정과 삭제는 다르다. 그래서 MCP를 “AI에게 손과 눈을 붙이는 방식”이라고만 말하면 반쪽 설명이 된다. 눈을 붙이면 무엇을 보게 할지 정해야 하고, 손을 붙이면 무엇을 못 하게 할지 정해야 한다.

MCP가 대신하지 않는 것

MCP는 외부 현재 상태를 가져오는 통로다. 반복 기준이나 작업 원칙은 별도로 남겨야 한다.

예를 들어 “고객정보를 공개 문서에 그대로 쓰지 않는다”는 기준은 MCP가 만들어주지 않는다. “배포 전에는 확인 화면을 본다”는 기준도 MCP가 만들어주지 않는다. 그런 것은 규칙 문서, 검수 절차, 승인 흐름으로 남겨야 한다.

반대로 규칙 문서를 잘 써도 AI가 캘린더나 Drive 문서를 자동으로 보지는 못한다. 그건 연결의 문제다.

이렇게 나누면 헷갈림이 줄어든다.

  • 반복 기준: 무엇을 조심해야 하는지, 언제 멈춰야 하는지 정한다.
  • 연결 통로: 지금 필요한 외부 자료와 도구를 가져온다.
  • 실행 경계: 삭제, 배포, 권한 변경처럼 되돌리기 어려운 행동을 막거나 승인하게 만든다.

MCP는 외부 자료를 가져오는 연결 통로다. 실행 경계와 맞닿아 있으므로 권한도 함께 봐야 한다.

권한은 기능보다 먼저 본다

새 연결을 켤 때 가장 먼저 보고 싶은 것은 “무엇을 할 수 있나”다. 하지만 실제로는 “무엇까지 허용되는가”를 먼저 봐야 한다.

문서 검색 서버와 캘린더 서버는 위험도가 다르다. 문서 목록 읽기와 외부 전송은 영향 범위가 벌어진다. GitHub issue 조회와 label 변경도 같은 권한으로 묶지 않는다. 배포 상태 확인과 배포 실행 사이에는 더 강한 경계가 필요하다.

OpenAI의 MCP와 connector 문서는 외부 서비스 연결과 도구 호출을 다룰 때 승인 흐름을 고려한다고 설명한다. MCP 공식 보안 문서도 신뢰하는 서버, 권한, 토큰 처리, 프롬프트 주입 같은 문제를 별도로 다룬다. 세부 구현은 도구마다 달라도 운영 기준은 크게 다르지 않다.

처음에는 아래 순서가 안전하다.

  • 공식 문서나 신뢰하는 제공자를 먼저 본다.
  • 읽기 전용으로 시작한다.
  • 쓰기, 삭제, 배포, 권한 변경은 자동 실행하지 않는다.
  • 민감한 도구는 사람의 승인 뒤에만 실행되게 둔다.
  • 어떤 데이터가 서버로 나가는지 확인한다.

특히 고객정보, 내부 문서, 비공개 일정처럼 민감한 자료가 들어가면 더 보수적으로 봐야 한다. “AI가 필요할 것 같아서”라는 이유만으로 넓은 권한을 열면 나중에 추적하기 어렵다.

언제 써볼 만한가

MCP가 항상 필요한 것은 아니다.

한 번 읽고 끝낼 짧은 문서는 그냥 붙여넣는 편이 더 단순하다. 오늘만 필요한 체크리스트도 프롬프트에 쓰면 된다. 반복 기준은 규칙 문서나 절차 파일로 남기는 편이 낫다.

MCP는 외부의 현재 상태가 자주 필요할 때 쓸 만하다.

  • 문서 저장소에서 최신 문서를 찾아야 한다.
  • GitHub issue나 PR처럼 계속 바뀌는 목록을 읽어야 한다.
  • 캘린더, Drive, 메일처럼 계정 권한이 붙은 자료가 필요하다.
  • 고객지원 기록이나 내부 API처럼 매번 값이 바뀌는 자료를 조회해야 한다.
  • 조회를 넘어 정해진 도구를 실행해야 한다.

반대로 아래 상황이면 기다리는 편이 낫다.

  • 어떤 권한을 주는지 이해하지 못했다.
  • 서버 제공자를 신뢰하기 어렵다.
  • 삭제, 결제, 배포, 권한 변경이 승인 없이 열려 있다.
  • 민감한 고객 데이터나 비공개 문서가 어디로 가는지 확인되지 않는다.

내 기준에서는 “읽기 전용, 신뢰 가능한 서버, 민감한 행동은 승인 필요”가 첫 출발점이다. 처음부터 자동 실행을 넓게 열면 연결 성공보다 검토 비용이 더 커진다.

통로를 열기 전에 남길 질문

MCP를 어렵게 느끼는 이유는 이름이 낯설어서만은 아니다. 연결, 권한, 보안, 도구 실행이 한꺼번에 나오기 때문이다.

그래서 처음에는 정의를 외우기보다 질문을 남기는 편이 낫다.

이 AI가 지금 봐야 할 자료는 무엇인가?
그 자료는 대화에 있는가, 외부 서비스에 있는가?
연결된 서버는 무엇을 읽을 수 있는가?
연결된 서버는 무엇을 바꿀 수 있는가?
되돌리기 어려운 행동은 승인 뒤에만 실행되는가?

이 질문에 답하고 나면 MCP라는 말이 조금 덜 무섭다. 결국 핵심은 하나다. AI가 모르는 현재 상태를 어떻게 가져올 것인가, 그리고 그 통로에 어떤 권한을 줄 것인가.

시리즈 연결

참고

아래 문서는 2026-06-30에 확인했다.