MCP란 무엇인가#
MCP(Model Context Protocol)는 AI 에이전트가 외부 도구와 데이터에 접근하는 표준입니다. 쉽게 말해, 에이전트가 GitHub, 데이터베이스, 사내 API, 파일 시스템, 브라우저를 사용할 수 있게 해 주는 연결 방식입니다.
MCP 이전에는 도구마다 연결 방법이 달랐습니다. GitHub는 API를 직접 호출하고, 데이터베이스는 드라이버를 쓰고, 사내 시스템은 별도 코드를 작성해야 했습니다. MCP는 그 연결을 표준화합니다. 에이전트는 MCP를 통해 도구를 호출하고, 결과를 받아 작업을 이어갑니다.
MCP 이전에는 무엇이 불편했나#
- 도구마다 인증과 호출 방식이 달랐습니다.
- 이슈나 문서를 읽으려면 별도 API나 도구 연동을 구현·관리해야 했습니다.
- 도구마다 접근 범위와 권한을 따로 파악해야 했습니다. MCP도 실제 권한 설계를 대신하지는 않습니다.
- 사내 시스템은 별도 코드를 작성해야 해서, 재사용이 어려웠습니다.
MCP는 이 문제를 호스트·클라이언트·서버 구조로 풉니다. 에이전트는 호스트에서 실행되고 MCP 클라이언트가 서버와 통신하며 MCP 서버가 실제 도구를 제공합니다.
호스트·클라이언트·서버 구조#
[사용자] → [호스트(에이전트)] → [MCP 클라이언트] → [MCP 서버] → [외부 도구/데이터]
- 호스트: Mirr Code 같은 에이전트 환경입니다.
- 클라이언트: MCP를 통해 서버와 통신하는 부분입니다.
- 서버: GitHub, Linear, Notion, PostgreSQL 등 실제 도구를 MCP로 제공합니다.
| 구성 | 담당하는 일 | 별도로 확인할 경계 |
|---|---|---|
| 호스트 | 모델과 대화·도구 사용 흐름 관리 | 어떤 자료를 모델에 전달하고 무엇을 승인하는가 |
| 클라이언트 | 서버 연결과 프로토콜 통신 | 전송 방식·인증 지원과 실제 연결 상태 |
| 서버 | 도구·자료 노출과 서비스 호출 | 서비스 계정 권한, 제공 도구와 데이터 처리 |
이 구분은 MCP 공식 구조 설명을 참고했습니다(2026-11-02 확인). 구조가 같아도 모든 클라이언트·서버 조합의 호환성을 보장하지는 않습니다.
이 구조 덕분에 에이전트는 파일과 명령만 쓰는 것이 아니라, 외부 도구를 직접 호출할 수 있습니다.
MCP로 연결할 수 있는 것#
| 대상 | 할 수 있는 일 |
|---|---|
| GitHub | 이슈 조회, 브랜치, PR 생성, 리뷰 코멘트 |
| Linear | 이슈 읽기, 상태 변경, 작업 할당 |
| Notion | 기획 문서 읽기, 문서 검색, 문서 갱신 |
| Slack | 대화 검색, 스레드 요약, 알림 전송 |
| PostgreSQL | 스키마 설명, 쿼리 초안, EXPLAIN 확인 |
| Playwright | 로그인, 폼 제출, 화면 확인, 스크린샷 |
| 사내 API | 이슈, 배포, 로그, 사내 문서 조회 |
중요한 것은 연결만 하는 것이 아니라, 그 결과를 작업에 쓰는 것입니다. 이슈를 읽고, 코드를 고치고, PR을 만들고, 테스트를 실행하는 흐름이 한 작업 안에서 이어집니다.
연결 방법: HTTP와 로컬 서버#
HTTP 연결은 원격 MCP 서버에 붙는 방식입니다. 공식 MCP 엔드포인트나 사내 MCP 서버에 연결합니다.
/mcp add my-service --http https://example.com/mcp
로컬 서버는 내 컴퓨터에서 MCP 서버를 실행하는 방식입니다. 로컬 파일이나 도구를 쓸 때 적합합니다.
어떤 방식을 쓸지는 클라이언트·서버의 전송 방식과 인증 지원, 조직 정책에 따라 다릅니다. 로컬 서버도 외부 API를 호출할 수 있고 사용자 계정 권한으로 파일이나 명령에 접근할 수 있어 자동으로 더 안전하다고 볼 수 없습니다.
권한과 보안: 무엇을 허용하는가#
MCP는 연결 표준이므로, 안전은 서버와 권한에 달렸습니다.
- 쓰기 권한은 도구 단위로 따로 엽니다. 읽기 도구와 쓰기 도구를 나누고, 쓰기 도구는 호출 전에 확인 창을 거치게 합니다.
- 최소 권한으로 토큰을 발급합니다. 전체 저장소나 전체 조직 권한은 주지 않습니다.
- 사용할 도구만 열기를 선택합니다.
/mcp tools로 노출된 도구를 확인합니다. - 토큰과 로그를 관리합니다. 토큰은 환경 변수나 비밀 관리에 두고, 접근 기록을 확인합니다.
PostgreSQL은 운영 DB 대신 민감정보를 제거한 테스트 DB에서 시작하세요. 테이블 SELECT만으로 읽기 전용이 완성되지는 않습니다. 스키마 USAGE, 역할 상속과 소유권, PUBLIC·함수 EXECUTE 권한까지 확인해야 합니다. PostgreSQL 권한 기준과 PostgreSQL MCP 점검표를 참고하세요. 실제 접속 계정으로 허용된 조회와 금지된 변경을 따로 검증해야 하며 차단 결과는 아직 확인되지 않았습니다.
한국 개발자에게 왜 중요한가#
한국 개발자의 작업에는 사내 시스템과 국내 도구가 많이 쓰입니다. 사내 이슈 트래커, 내부 API, 한국어 문서, 국내 SaaS도 필요합니다. MCP는 이들을 에이전트와 연결합니다.
- 사내 이슈를 읽고, 관련 코드를 찾고, PR을 만듭니다.
- 한국어 기획 문서를 읽고, 그에 맞게 구현합니다.
- 사내 로그를 보고, 원인을 찾고, 테스트를 만듭니다.
즉, 한국어로 된 사내 도구를 한국어로 된 작업 흐름에 붙이는 것이 MCP의 실제 가치입니다.
예제: /mcp로 연결하고 도구 확인하기#
/mcp add my-service --http https://example.com/mcp
/mcp tools my-service
위 주소는 실제 서비스가 아닌 형식 예시이며 실행 기록이 아닙니다. 연결 상태와 사용 가능한 도구를 확인하고 도구가 보이지 않으면 인증, URL, 포트, 프록시, 권한을 확인하세요.
GitHub는 임의 주소 대신 공식 서버와 인증 안내를 확인하세요. 아래 명령은 가상의 주소로 형식만 보여 줍니다.
/mcp add github-mcp --http https://example.com/github-mcp
/mcp tools github-mcp
연결되더라도 이슈 조회·PR 생성 가능 여부는 서버 도구와 서비스 계정 권한에 따라 다릅니다. /mcp tools로 노출 도구를 확인하고 읽기부터 범위를 제한하세요. 실제 /mcp add 실행 화면과 연결 transcript는 아직 없습니다.
- 서버 출처·전송 방식과 실제 엔드포인트를 확인합니다.
- 서비스 계정과 클라이언트의 도구 권한을 각각 제한합니다.
- 연결 상태·도구 목록·허용한 조회 결과를 확인하고 쓰기는 별도 검토합니다.
자주 묻는 질문#
MCP가 안전한가요?#
MCP 자체는 연결 표준이므로 안전은 서버와 권한에 달렸습니다. 읽기 전용으로 시작하고 필요한 도구만 열고 토큰은 최소 권한으로 발급하세요.
공식 서버와 커뮤니티 서버는 어떻게 구분하나요?#
공식 문서와 저장소를 확인하세요. 공식 서버는 벤더가 유지하고, 커뮤니티 서버는 개인이나 팀이 유지합니다. 버전과 권한을 먼저 확인하고, 신뢰할 수 있는 서버만 연결하세요.
MCP로 무엇을 연결할 수 있나요?#
GitHub, Linear, Notion, Slack, PostgreSQL, Playwright, 사내 API 등을 연결할 수 있습니다. 이슈 조회, 문서 읽기, DB 조회, 브라우저 확인 등을 한 작업 안에서 처리할 수 있습니다.
HTTP와 로컬 서버는 언제 쓰나요?#
원격 서버는 HTTP로 통신할 수 있고 로컬 서버는 보통 클라이언트가 실행한 프로세스와 통신합니다. 로컬이라고 데이터가 외부로 나가지 않는 것은 아닙니다. 실제 네트워크 경로, 실행 권한과 서버의 처리 조건을 확인하세요.
한국어로 된 사내 도구도 연결할 수 있나요?#
네. 사내 API가 MCP를 지원하면 연결할 수 있습니다. 한국어로 된 사내 문서나 시스템도 MCP로 읽고 쓸 수 있습니다. 권한과 데이터 경계는 먼저 정해야 합니다.
연결이 안 되면 어떻게 하나요?#
/mcp로 연결 상태를 확인하고, /mcp tools로 사용 가능한 도구를 확인하세요. 인증, URL, 포트, 프록시, 권한을 먼저 확인하세요. 공식 문서의 설치 명령과 비교해 보는 것이 좋습니다.
연결 성공 다음에 확인할 것#
서버 이름이 목록에 나타나고 인증을 마쳤다는 사실만으로 원하는 업무가 가능한 것은 아닙니다. 연결에는 성공했지만 필요한 도구를 서버가 제공하지 않을 수 있고, 도구는 보여도 현재 계정이 대상 문서나 저장소를 볼 권한이 없을 수 있습니다. 연결 상태, 도구 목록, 서비스 접근 결과를 따로 보세요.
예를 들어 공개 연습 이슈의 제목을 읽는 일을 생각해 봅시다. 연결이 준비되면 조회 도구의 입력 항목과 반환 범위를 먼저 확인합니다. 도구 이름에 조회라는 말이 있어도 첨부나 댓글까지 함께 반환하는지 알아야 합니다. 필요한 제목만 요청했는데 긴 댓글과 사용자 정보가 돌아왔다면 다음 모델 요청에 무엇이 전달되는지도 검토하세요. 이 사례는 점검 순서를 설명한 가정이며 실제 GitHub나 Mirr 실행 결과가 아닙니다.
도구·자료·프롬프트는 무엇이 다른가#
MCP 공식 구조 문서는 서버가 제공하는 도구, 자료와 프롬프트를 구분합니다. 도구는 호출할 수 있는 동작이고, 자료는 문맥에 넣을 데이터이며, 프롬프트는 재사용할 입력 틀입니다. 같은 데이터베이스 서버가 스키마 자료와 조회 도구를 함께 제공할 수도 있습니다. 모든 서버가 세 종류를 전부 제공하는 것은 아니므로 실제 목록과 클라이언트 지원을 확인해야 합니다.
구분을 알면 설치 안내를 읽기도 쉽습니다. 문서 검색 기능을 기대했는데 프롬프트만 제공하는 서버라면 연결 오류가 아니라 기능 범위의 차이일 수 있습니다. 반대로 도구가 추가됐다고 모든 호출을 자동 승인할 이유는 없습니다. 도구 입력과 대상, 반환 데이터가 어떤 권한을 사용하는지 확인한 뒤 필요한 호출만 허용합니다.
전송 방식마다 신뢰 경계가 다르다#
MCP 명세의 전송 규정을 보면 로컬 연결과 원격 연결이 실제로 다르게 작동합니다. stdio 방식에서는 클라이언트가 서버를 하위 프로세스로 직접 실행하고, JSON-RPC 메시지를 표준 입력과 표준 출력으로 주고받습니다. 메시지는 줄바꿈으로 구분되며, 서버는 표준 출력에 유효한 MCP 메시지가 아닌 내용을 써서는 안 됩니다. 로그는 표준 오류(stderr)로 내보낼 수 있다고 명세는 정합니다. 원격 연결에 쓰는 Streamable HTTP 방식은 하나의 엔드포인트에서 POST와 GET을 처리합니다.
HTTP 방식에는 추가 보안 요구가 붙습니다. 명세는 서버가 DNS 리바인딩 공격을 막기 위해 모든 연결의 Origin 헤더를 검증하고, Origin이 있으면서 유효하지 않으면 403으로 응답하도록 정합니다. 로컬에서 실행할 때는 모든 네트워크 인터페이스(0.0.0.0)가 아니라 127.0.0.1에만 바인딩하고, 모든 연결에 인증을 두라고 권합니다. 이 보호가 없으면 공격자가 DNS 리바인딩으로 원격 웹사이트에서 로컬 MCP 서버와 상호작용할 수 있다는 경고도 명세에 실려 있습니다.
아키텍처 문서는 규모의 차이도 설명합니다. 로컬 stdio 서버는 보통 하나의 클라이언트만 상대하고, 원격 Streamable HTTP 서버는 보통 여러 클라이언트를 상대합니다. 그래서 원격 서버의 권한 검토는 한 사용자의 설정이 아니라 연결된 모든 클라이언트가 공유하는 범위를 기준으로 하는 편이 안전합니다.
로컬 서버를 연결하기 전에 볼 실행 명령#
MCP 보안 권장 사항은 로컬 서버를 같은 기기에서 내려받아 실행되는 실행 파일로 취급합니다. 서버는 클라이언트의 권한으로 실행되므로, 악성 시작 명령이 설정에 끼어들거나 서버 자체에 악성 코드가 들어 있으면 임의의 명령이 실행될 수 있습니다. 원클릭으로 로컬 서버를 설정하는 클라이언트는 실행될 명령을 인자까지 잘리지 않게 보여 주고, 클라이언트와 같은 권한으로 실행된다고 경고해야 합니다.
그래서 /mcp add나 설정 파일의 명령을 붙여 넣기 전에 실행 파일의 출처, 인자, 환경 변수를 한 줄씩 확인하세요. 명령 뒤에 다른 명령이 이어 붙어 있지 않은지, 출처를 알 수 없는 패키지를 내려받지 않는지도 함께 보세요. 같은 권고는 로컬 서버를 최소 권한의 샌드박스에서 실행하고, 파일 시스템과 네트워크 접근을 제한하며, 추가 권한은 사용자가 명시적으로 허용하도록 정합니다.
인증 정보는 전송 방식에 따라 다르게 다룬다#
인증 명세의 적용 범위도 전송 방식에 따라 나뉩니다. 명세는 HTTP 기반 전송이 인증 명세를 따르도록 권고하고, STDIO 구현은 그 명세를 따르지 않는 대신 환경에서 자격 증명을 가져오라고 권합니다. 로컬 stdio 서버에서는 자격 증명을 OAuth 흐름이 아니라 실행 환경에서 가져오는 방식이 명세의 권고입니다. 환경 변수가 셸 기록이나 공유 설정 파일에 남지 않는지도 확인하세요.
HTTP 서버에는 더 엄격한 규칙이 있습니다. 클라이언트는 해당 MCP 서버의 인가 서버가 발급한 토큰만 보내야 하고, 서버는 자신을 대상으로 발급된 토큰만 받아들여야 합니다. 서버가 클라이언트에게서 받은 토큰을 하위 API에 그대로 넘기는 토큰 패스스루는 명세가 명시적으로 금지합니다. 사내 MCP 서버를 운영하는 팀이라면 이 조건을 구현 요구사항으로 적고, 사용자는 연결 후 토큰의 대상과 범위를 확인하세요.
권한은 작게 시작하고 필요할 때 늘린다#
보안 권장 사항은 처음에는 읽기처럼 위험이 낮은 최소 범위만 주고, 특권 작업을 처음 시도할 때 범위를 추가하는 점진적 최소 권한 모델을 권합니다. 반대로 files:, db:, admin:* 같은 넓은 범위를 한꺼번에 주면, 토큰이 유출됐을 때 관련 없는 도구와 자료까지 접근될 수 있고 감사 기록도 흐려진다고 설명합니다.
도구 명세는 사람의 개입도 요구합니다. 신뢰와 안전을 위해 도구 호출을 거부할 수 있는 사람이 항상 개입해야 한다고 권고하고, 실행 전에 확인 창을 띄우는 것이 좋다고 말합니다. 또 클라이언트는 신뢰할 수 있는 서버에서 온 것이 아니라면 도구 annotations를 신뢰할 수 없는 정보로 다뤄야 합니다. 도구 설명에 읽기 전용이라고 적혀 있더라도, 서버의 출처를 확인하기 전에는 그 설명만으로 쓰기 가능성을 배제하지 마세요.
도구 목록이 바뀐 뒤 확인할 것#
서버가 기능을 추가하거나 도구를 바꾸면 도구 목록도 달라집니다. 도구 명세는 listChanged 기능을 선언한 서버가 목록이 바뀌면 notifications/tools/list_changed 알림을 보내도록 권고합니다. 아키텍처 문서도 목록이 고정된 것이 아니라 동적으로 바뀔 수 있다고 설명합니다.
그래서 서버를 업데이트했다면 /mcp tools로 목록을 다시 열어 보고, 새로 생긴 도구마다 권한을 따로 검토하세요. 클라이언트가 이 알림을 지원하지 않는다면 목록이 자동으로 갱신되지 않을 수 있으므로, 연결을 다시 맺은 뒤 목록을 확인하는 편이 안전합니다.
PUBLIC에 주어지는 PostgreSQL 기본 권한#
PostgreSQL 권한 문서는 대부분의 객체가 처음에는 소유자(와 슈퍼유저)만 쓸 수 있고, 다른 역할에게는 권한을 명시적으로 줘야 한다고 설명합니다. 다만 일부 객체 종류에는 PUBLIC 역할에게 기본 권한이 주어집니다. 테이블, 열, 시퀀스, 스키마에는 기본 권한이 없지만, 데이터베이스에는 CONNECT와 TEMPORARY가, 함수와 프로시저에는 EXECUTE가, 언어와 자료형에는 USAGE가 PUBLIC에 기본으로 부여됩니다.
소유자는 기본 권한과 명시적으로 준 권한을 모두 REVOKE로 회수할 수 있습니다. 객체를 만든 같은 트랜잭션에서 회수하면 다른 사용자가 쓸 틈이 생기지 않는다고 문서는 적고 있습니다. 기본값은 ALTER DEFAULT PRIVILEGES로 바꿀 수도 있으니, 테스트 DB에서는 MCP 역할로 접속해 허용된 조회가 되는지, 쓰기와 함수 실행이 실제로 거부되는지를 따로 시험해 보세요. 이 순서는 제안이며 결과를 대신하는 증거가 아닙니다.
MCP로 연결한 도구에 실제로 어떤 권한이 전달되는지는, 연결된 서버가 제공하는 도구 목록과 각 도구가 읽기·쓰기·실행 중 어떤 범위에 해당하는지를 대조해서만 알 수 있습니다. 도구 목록이 바뀌면 허용 범위도 함께 바뀔 수 있으니, 연결 이후에 도구가 추가되거나 제거됐는지 정기적으로 확인하는 편이 안전합니다. 로컬 서버가 외부로 전송하는지 여부도 함께 보지 않으면 '내 컴퓨터 안에서만'이라는 가정이 성립하지 않습니다.
편집 메모#
편집 메모 (2026-11-02): 두 SQL 명령만으로 삭제를 차단한다는 잘못된 보장을 제거하고 로컬 서버의 외부 전송 가능성을 명시했습니다. 구조 표와 공식 출처를 보충했으며 실제 연결 실행은 검증하지 않았습니다. 기존 2026-10-31 표시는 전체 재검증일로 갱신하지 않았습니다.