MCP 기본 구조
3줄 요약
- MCP는 AI 애플리케이션이 외부 도구와 데이터에 연결되는 방식을 표준화하려는 프로토콜이다.
- 핵심 구성은 host/client/server이며, server는 tool, resource, prompt 같은 기능을 노출한다.
- 백엔드 개발자에게 MCP는 사내 API, DB, 파일, 업무 시스템을 모델에게 안전하게 연결하는 계약 문제다.
핵심 정리
- MCP는 Model Context Protocol의 약자다. 모델 자체의 기능이라기보다 모델을 쓰는 애플리케이션이 외부 컨텍스트와 도구에 접근하는 표준 인터페이스에 가깝다.
- MCP server는 도구와 리소스를 제공하고, MCP client는 이 server와 통신해 AI 애플리케이션에 기능을 연결한다.
- tool은 실행 가능한 동작이고, resource는 읽을 수 있는 데이터이며, prompt는 재사용 가능한 프롬프트 템플릿이다.
- function calling은 특정 모델 provider의 도구 호출 기능에 가깝고, MCP는 도구와 리소스를 노출하는 외부 프로토콜 계층에 가깝다.
- 기업에서는 MCP server 하나가 사내 시스템의 새로운 진입점이 될 수 있으므로 인증, 권한, 감사, 네트워크 경계가 중요하다.
헷갈리는 지점
- MCP를 agent framework라고 생각하기 쉽다. 도구 호출과 함께 자주 등장하기 때문이다.
- 핵심은 MCP가 agent의 의사결정 루프가 아니라 도구와 컨텍스트를 연결하는 프로토콜이라는 점이다.
- agent는 MCP tool을 사용할 수 있지만 MCP 자체가 agent는 아니다.
- MCP server를 만들면 내부 API를 그대로 노출해도 된다고 생각하기 쉽다. 표준 프로토콜이기 때문이다.
- 핵심은 표준화가 보안을 대신하지 않는다는 점이다.
- 노출 범위, 인증, 권한, 감사 로그, idempotency를 별도로 설계해야 한다.
확인 질문
- MCP가 해결하려는 문제는 무엇인가?
- AI 애플리케이션이 외부 도구, 데이터, 프롬프트를 일관된 방식으로 발견하고 호출하도록 만드는 문제다.
- MCP와 function calling의 관계는 무엇인가?
- function calling은 모델에게 도구 호출 의도를 표현하게 하는 provider 기능이고, MCP는 실제 도구와 리소스를 외부에서 제공하는 프로토콜 계층이다.
3줄 요약
- MCP server는 tool, resource, prompt를 노출할 수 있지만 각각의 위험이 다르다.
- read-only resource와 side effect가 있는 write tool은 반드시 분리해야 한다.
- 도구 설명은 모델을 위한 API 문서이므로 입력 schema, 권한, 실패 조건을 명확히 드러내야 한다.
핵심 정리
- resource는 읽기 데이터다. 문서, 설정, 파일, DB 조회 결과처럼 모델에게 context가 될 수 있다.
- tool은 실행 동작이다. 티켓 생성, 메일 발송, 주문 취소, 배포 트리거처럼 side effect가 있을 수 있다.
- prompt는 재사용 가능한 템플릿이다. 조직의 업무 규칙을 반복해서 적용할 때 유용하다.
- tool schema는 사람과 모델 모두에게 계약이다. 어떤 입력이 필요한지, 어떤 결과가 오는지, 실패하면 무엇을 반환하는지 명확해야 한다.
- write tool은 승인, idempotency key, audit log, rate limit 없이는 운영에 붙이지 않는 편이 안전하다.
헷갈리는 지점
- 모든 내부 API를 tool로 감싸면 agent가 똑똑해진다고 생각하기 쉽다. 할 수 있는 일이 많아지기 때문이다.
- 핵심은 도구 수가 늘수록 선택 오류와 보안 위험도 늘어난다는 점이다.
- 자주 쓰고 안전한 read-only tool부터 작게 시작하는 편이 낫다.
- resource와 tool을 비슷하게 보기 쉽다. 둘 다 외부 시스템에서 정보를 가져오기 때문이다.
- 핵심은 resource는 읽기 중심이고 tool은 행동 중심이라는 점이다.
- side effect가 있으면 tool로 보고 더 강한 통제를 둔다.
확인 질문
- read-only tool과 write tool을 분리해야 하는 이유는 무엇인가?
- side effect, 권한, 감사, retry 위험이 완전히 다르기 때문이다.
- tool description이 중요한 이유는 무엇인가?
- 모델이 언제 어떤 도구를 어떤 입력으로 호출할지 판단하는 근거가 되기 때문이다.
인증 인가 감사 로그
3줄 요약
- MCP server는 사내 시스템의 새 입구가 될 수 있으므로 인증과 인가가 API 서버 수준으로 중요하다.
- tool 호출은 누가, 어떤 목적, 어떤 입력, 어떤 결과로 실행했는지 감사 가능해야 한다.
- 사용자 권한을 모델 프롬프트에만 맡기지 말고 MCP server와 백엔드에서 강제해야 한다.
핵심 정리
- MCP server는 “AI가 호출하는 서버”가 아니라 “사용자 대신 행동할 수 있는 서버”다.
- 인증은 호출 주체가 누구인지 확인하고, 인가는 그 주체가 특정 resource나 tool을 사용할 수 있는지 확인한다.
- tool 권한은 최소 권한으로 설계한다. 문서 조회 tool과 티켓 수정 tool이 같은 권한을 가지면 안 된다.
- 감사 로그에는 actor, tenant, tool name, input summary, result status, trace id, idempotency key가 남아야 한다.
- 민감한 input과 output은 전문 저장 대신 마스킹, hash, 별도 보안 저장소를 고려한다.
헷갈리는 지점
- LLM이 판단해서 권한 없는 작업을 하지 않을 것이라고 믿기 쉽다. 프롬프트에 규칙을 적었기 때문이다.
- 핵심은 권한은 모델이 아니라 서버가 강제해야 한다는 점이다.
- 모델은 실수하거나 공격 입력에 흔들릴 수 있다.
- 감사 로그는 write tool에만 필요하다고 생각하기 쉽다. 읽기는 안전해 보이기 때문이다.
- 핵심은 민감 데이터 조회도 보안 사고의 일부라는 점이다.
- read-only tool도 누가 무엇을 조회했는지 남겨야 한다.
확인 질문
- MCP server에서 권한을 프롬프트에만 맡기면 안 되는 이유는 무엇인가?
- 모델은 보안 경계가 아니며 prompt injection이나 실수로 권한 없는 작업을 요청할 수 있기 때문이다.
- audit log에 최소로 남길 정보는 무엇인가?
- actor, tenant, tool, input summary, status, trace id, idempotency key다.
3줄 요약
- MCP tool은 외부 API 호출과 같으므로 timeout, retry, idempotency, rate limit을 가져야 한다.
- read-only tool은 비교적 재시도하기 쉽지만 write tool은 중복 실행 사고를 만들 수 있다.
- tool 결과는 다시 모델 context로 들어가므로 실패 메시지와 결과 텍스트도 prompt injection 관점에서 다뤄야 한다.
핵심 정리
- tool timeout이 없으면 agent loop 전체가 멈출 수 있다.
- retry는 tool 유형별로 달라야 한다. 조회 tool은 retry가 가능하지만 주문 취소, 메일 발송, 결제 같은 tool은 idempotency가 없으면 위험하다.
- idempotency key는 같은 요청이 여러 번 들어와도 한 번만 실행되게 만드는 핵심 장치다.
- tool 결과는 모델 입력이 된다. 외부 시스템 응답에 “이전 지시를 무시하라” 같은 텍스트가 들어 있어도 지시가 아니라 데이터로 취급해야 한다.
- tool 호출 실패는 모델에게 자연어로만 넘기지 말고 구조화된 status와 error code로 제공하는 편이 안전하다.
헷갈리는 지점
- tool 호출이 실패하면 agent가 알아서 다시 하면 된다고 생각하기 쉽다. agent는 반복할 수 있기 때문이다.
- 핵심은 반복이 side effect와 비용을 증폭시킨다는 점이다.
- tool별 재시도 정책과 idempotency가 먼저다.
- tool 결과는 사내 시스템에서 왔으니 안전하다고 생각하기 쉽다. 내부 데이터이기 때문이다.
- 핵심은 내부 데이터에도 사용자 입력과 외부 텍스트가 섞일 수 있다는 점이다.
- tool result는 신뢰된 명령이 아니라 인용된 데이터로 감싸야 한다.
확인 질문
- write tool에 idempotency key가 필요한 이유는 무엇인가?
- retry나 중복 메시지로 같은 작업이 두 번 실행되는 것을 막기 위해서다.
- tool 결과를 모델 context에 넣을 때 조심할 점은 무엇인가?
- 결과 텍스트 안의 지시문을 시스템 지시로 취급하지 않도록 구조화하고, prompt injection 가능성을 고려해야 한다.
MCP 도입 판단과 인프라 협업
3줄 요약
- 개인 프로젝트에서는 MCP를 로컬 도구 연결과 개발 생산성 향상에 작게 활용할 수 있다.
- 기업에서는 MCP server가 내부 시스템 접근 경로가 되므로 보안, 네트워크, 배포, 관측성을 인프라팀과 합의해야 한다.
- MCP는 최신 기술이므로 공식 SDK와 활발히 유지보수되는 구현을 우선 사용하고, 낡은 agent 데모 패턴은 깊게 따르지 않는다.
핵심 정리
- MCP는 실전성이 빠르게 커지고 있지만 생태계 변화도 빠르다. 공식 문서와 공식 SDK를 기준으로 삼는다.
- 개인 프로젝트에서는 파일 검색, 노트 조회, 간단한 read-only tool부터 시작하는 것이 좋다.
- 기업에서는 MCP server를 누가 배포하고, 어떤 네트워크에서 접근하며, 어떤 secret을 가지는지 명확히 해야 한다.
- 인프라팀은 MCP server 수 증가, tool별 outbound, secret, audit log, 장애 격리, rate limit을 걱정한다.
- 보안팀은 tool 권한, prompt injection, 데이터 유출, 감사 가능성, 사용자 동의 범위를 걱정한다.
헷갈리는 지점
- 최신 기술이므로 모든 것을 MCP로 바꿔야 한다고 생각하기 쉽다. 표준화 흐름이 강해 보이기 때문이다.
- 핵심은 MCP가 도구 연결 표준이지 모든 통합의 정답은 아니라는 점이다.
- 단순 서버 내부 기능은 기존 API나 service call이 더 단순할 수 있다.
- 개인 프로젝트에는 MCP가 과하다고 생각하기 쉽다. 기업 통합 이야기가 많기 때문이다.
- 핵심은 작은 read-only tool과 로컬 자동화에는 개인 프로젝트에서도 유용할 수 있다는 점이다.
- 다만 write tool과 공개 배포는 신중해야 한다.
확인 질문
- 기업에서 MCP 도입 전 인프라팀과 합의할 것은 무엇인가?
- 배포 위치, 네트워크 접근, secret, rate limit, observability, audit log, 장애 격리다.
- MCP를 처음 적용할 때 안전한 시작점은 무엇인가?
- read-only resource나 조회 tool부터 작게 시작하는 것이다.