MCP를 도입하는 팀이 늘고 있습니다. 그런데 실제 현장에서는 “MCP 서버를 몇 개 붙였느냐”보다 “어떤 경계로 설계했느냐”가 훨씬 중요합니다. 검색 의도가 분명한 키워드로 보면 MCP server design, Model Context Protocol tools resources prompts, MCP security, agent tool boundary가 핵심입니다. 도구를 많이 연결했다고 에이전트가 좋아지는 게 아니라, 업무 경계와 승인 흐름이 분명해야 품질과 보안이 같이 올라갑니다.
요즘 MCP를 처음 붙이는 팀이 자주 하는 실수는 하나입니다. 모든 내부 시스템을 한 서버에 다 때려 넣는 겁니다. 문서 조회, 고객 정보 조회, 결제 취소, 배포 실행, 티켓 수정까지 한 MCP 엔드포인트에서 다 열어둡니다. 이 구조는 처음엔 편합니다. 하지만 조금만 운영이 커지면 권한 분리, 감사 로그, 장애 격리, 승인 설계가 무너집니다.
Model Context Protocol의 장점은 LLM 애플리케이션이 외부 도구와 컨텍스트를 표준 방식으로 연결할 수 있다는 점입니다. GitHub의 MCP 조직 소개도 이 부분을 명확히 말합니다. IDE, 채팅 UI, 커스텀 워크플로우가 같은 규약으로 도구와 데이터 소스를 붙일 수 있다는 것입니다.
문제는 표준 연결이 곧 좋은 설계를 뜻하지 않는다는 점입니다. 연결이 쉬워질수록 오히려 경계를 더 엄격하게 잡아야 합니다.
예를 들어 아래 두 구조를 비교해보겠습니다.
internal-mcp 서버 하나knowledge-mcp: 문서/위키/가이드 조회 전용support-mcp: 티켓 조회/수정, 고객 메모 추가billing-mcp: 환불 요청 생성만 가능, 실제 승인 전 실행 금지ops-mcp: 운영 명령은 read-only와 action 권한 분리둘 다 “MCP 서버를 붙였다”는 점은 같습니다. 하지만 후자는 장애와 사고가 났을 때 원인을 좁힐 수 있고, 권한도 끊기 쉽습니다.
MCP 관련 소개 자료를 보면 tools, resources, prompts라는 세 가지 primitive가 반복해서 나옵니다. 이 셋을 기능적으로만 이해하면 설계가 흐려집니다. 실무적으로는 아래처럼 보는 편이 좋습니다.
tool은 모델이 호출할 수 있는 행동 단위입니다. 그래서 위험합니다. 조회든 수정이든 side effect 가능성이 있습니다. tool은 “모델이 실행 버튼을 누를 수 있다”는 뜻으로 받아들이는 게 맞습니다.
예시:
resource는 모델이 참고할 자료입니다. ideally read-only입니다. 여기엔 매뉴얼, 가격표, 정책 문서, 스키마 설명, FAQ 같은 것이 들어갑니다.
예시:
prompt는 매 작업마다 재사용할 수 있는 템플릿 계층에 가깝습니다. 실무에서는 역할 기반 템플릿, 조사 템플릿, 코드 리뷰 템플릿처럼 쓰면 좋습니다.
예시:
이 셋을 분리하지 않으면, 읽기 전용이어야 할 자료가 실행 경로로 섞이고, 승인받아야 할 tool이 그냥 문서 호출처럼 취급됩니다.
많은 팀이 기능별로 서버를 나누려다가 오히려 더 헷갈립니다. 기준은 아래 네 가지가 실무적입니다.
읽기와 쓰기를 무조건 분리하세요. 특히 아래 액션은 별도 서버 또는 별도 승인 계층으로 떼는 편이 좋습니다.
감사 로그가 중요한 업무는 독립 서버가 낫습니다. 환불, 계정 권한 변경, 운영 명령은 “누가 왜 호출했는가”를 남겨야 합니다.
문서 검색 서버가 죽는 것과 배포 서버가 죽는 것은 심각도가 다릅니다. 한 서버에 다 몰아넣으면 복구 우선순위가 꼬입니다.
고객 개인정보, 매출 데이터, 내부 보안 문서는 같은 자격증명으로 묶지 않는 편이 안전합니다. 민감도별 credential scope 분리가 기본입니다.
MCP security에서 제일 자주 빠지는 게 approval입니다. 모델이 행동을 결정할 수 있어도, 모든 행동을 자동 실행하게 만들 필요는 없습니다. 특히 아래는 human-in-the-loop가 기본값에 가까워야 합니다.
여기서 중요한 건 “승인을 사람에게 맡긴다”보다 “승인 단위를 작게 설계한다”입니다.
나쁜 예:
run_admin_action(action: string)좋은 예:
request_refund(orderId, reason)create_draft_email(customerId, templateId)restart_service(serviceName, environment)행동이 구체적일수록 승인 UI도 단순해지고, 로그 해석도 쉬워집니다.
툴이 많아질수록 선택 오류와 잘못된 호출이 늘어납니다. MCP는 붙일수록 좋은 게 아니라, 작업 맥락에 맞게 노출을 줄일수록 좋습니다.
“이 툴은 위험하니 함부로 쓰지 마” 같은 문장으로는 부족합니다. 권한은 시스템에서 막아야지 프롬프트에 부탁하면 안 됩니다.
서버 하나에 모든 액션이 섞이면, 실패 원인이 인증인지 스키마인지 모델 판단인지 분리하기 어렵습니다.
조회만 가능한 줄 알았던 서버가 사실 수정까지 하게 되면, 에이전트 행동을 예측하기 어려워집니다.
서버 소유팀, 데이터 소유팀, 보안 책임자가 다르면 운영 사고 때 우왕좌왕합니다. 서버별 owner를 미리 박아놔야 합니다.
실무에서는 아래 패턴이 무난합니다.
1단계에서는 resources 중심으로 시작합니다. 문서 검색, 스키마 조회, 정책 조회만 붙입니다. 이 단계에서 답변 품질과 검색 정확도를 먼저 검증합니다.
그 다음에 side effect가 약한 tool만 추가합니다. 예를 들면 초안 생성, 태그 추천, 티켓 draft 작성처럼 되돌리기 쉬운 액션입니다.
환불, 배포, 고객 수정 같은 고위험 액션은 마지막에 붙이고, 무조건 승인 계층과 감사 로그를 함께 넣습니다.
이 순서를 지키면 품질 이슈와 보안 이슈를 동시에 줄일 수 있습니다.
MCP 서버를 만들기 전에 아래 질문부터 답해보세요.
질문에 답이 흐리면, 서버를 더 만들기보다 경계를 다시 자르는 편이 낫습니다.
MCP는 좋은 표준입니다. 하지만 좋은 표준이 자동으로 좋은 시스템을 만들진 않습니다. 많이 붙인 팀보다 잘 나눈 팀이 결국 오래 갑니다. 실무에서 중요한 것은 tools, resources, prompts를 구분하고, 읽기와 쓰기를 분리하고, 승인과 감사 흐름을 설계하는 것입니다.
MCP server design의 핵심 질문은 “무엇을 연결할까”가 아닙니다. **“어디까지를 한 에이전트에게 맡길까”**입니다. 이 경계를 잘 잡으면 보안도 좋아지고, 품질도 안정되고, 운영도 쉬워집니다.
참고 소스: