복사-붙여넣기의 한계
Claude에게 사내 재고 데이터를 물어볼 때마다, 매번 엑셀을 열어서 데이터를 복사해 붙여넣는다고 해봅시다. 한두 번은 괜찮지만, 하루에도 몇 번씩 반복되는 질문이라면 이건 지속 가능하지 않습니다. 게다가 복사해서 붙여넣는 순간 데이터는 이미 과거 시점의 스냅샷입니다.
MCP(Model Context Protocol) 서버는 이 반복 작업을 없애줍니다. Claude가 사내 시스템에 표준화된 방식으로 직접 연결해서, 항상 최신 데이터를 실시간으로 가져오게 만드는 겁니다.
MCP 서버의 세 가지 구성 요소
| 유형 | 목적 | 활용 예시 |
|---|---|---|
| Tool | 에이전트가 실행하는 함수 | 재고 수량 조회, 티켓 시스템 조회 |
| Resource | 읽을 수 있는 데이터 | 매출 리포트 |
| Prompt | 미리 정의된 템플릿 | 보고서 자동 요약 |
최소 구성 예제 — 재고 조회 Tool 만들기
Python의 FastMCP SDK를 쓰면 몇 줄로 시작할 수 있습니다.
from fastmcp import FastMCP
mcp = FastMCP("inventory-server")
@mcp.tool()
def get_stock_level(item_code: str) -> dict:
"""특정 품목 코드의 현재 재고 수량을 조회합니다."""
# 내부 재고 API 호출 로직
return {"item_code": item_code, "quantity": 42}
if __name__ == "__main__":
mcp.run()@mcp.tool() 데코레이터로 함수 하나를 등록하면, 이 함수가 Claude가 호출할 수 있는 도구가 됩니다. 이후 claude mcp add 명령으로 이 서버를 Claude 클라이언트에 연결하면, “A 품목 재고 얼마나 남았어?”라는 질문에 Claude가 이 함수를 직접 호출해서 답합니다.
그리고 누군가 “재고를 바로 수정하는 기능도 넣어달라”고 한다
여기까지는 순조롭습니다. 문제는 다음 요청에서 시작됩니다. “재고 조회할 때 바로 수정도 되게 해주면 편하지 않을까요?” 이 요청을 그대로 받아들여서, 조회 함수 하나에 수정 로직까지 얹으면 위험한 상황이 만들어집니다.
예를 들어 이렇게 짜면 안 됩니다.
@mcp.tool()
def manage_stock(item_code: str, action: str, quantity: int = None) -> dict:
"""재고를 조회하거나 수정합니다. action: 'get' 또는 'update' 또는 'delete'"""
if action == "delete":
# 재고 기록을 삭제하는 로직
...이렇게 하나의 Tool 안에 조회·수정·삭제를 다 몰아넣으면, Claude가 “재고 좀 확인해줘”라는 단순한 요청을 처리하다가 맥락을 잘못 해석해 action="delete"를 호출할 가능성이 생깁니다. 실제로 이런 구조에서 의도치 않게 삭제 작업이 실행된 사례들이 보고된 적 있습니다. 조회와 변경을 같은 함수에 묶어두는 순간, 조회만 하려던 요청이 삭제로 이어질 위험을 함께 열어두는 셈입니다.
보안 설계 원칙 3가지
읽기와 쓰기를 반드시 분리합니다. get_stock_level(조회)과 update_stock_level(수정)을 서로 다른 Tool로 나누세요. 이렇게 하면 Claude가 조회를 요청받았을 때 수정 함수를 호출할 여지 자체가 없습니다.
인증 정보는 코드에 절대 넣지 않습니다. API 키는 환경 변수로 관리하고, 프롬프트나 코드에 평문으로 노출되지 않도록 합니다.
위험한 작업은 별도 승인 절차를 거칩니다. 삭제, 결제, 발송처럼 되돌리기 어려운 작업은 Tool 자체를 만들지 않거나, 만들더라도 실행 전 별도 확인 단계를 반드시 넣습니다.
권한을 Tool 단위로 최소화하기
읽기/쓰기를 분리하는 것만으로는 충분하지 않습니다. 실무에서는 각 Tool이 접근할 수 있는 시스템 권한 범위(scope) 자체를 최소한으로 제한해야 합니다.
- 서비스 계정은 Tool별로 분리:
get_stock_level이 쓰는 서비스 계정에는 재고 테이블 읽기 권한만 부여하고, 다른 테이블이나 쓰기 권한은 아예 포함시키지 않습니다. 코드 레벨에서 “쓰기 함수를 안 만들었으니 안전하다”가 아니라, 인증 토큰 자체가 쓰기를 할 수 없는 상태를 만드는 게 더 안전합니다. - Tool 설명(description)을 명확히 쓰기: Claude는 Tool의
description을 보고 언제 그 Tool을 호출할지 판단합니다. “재고를 조회하거나 수정합니다” 같은 모호한 설명 대신 “현재 재고 수량만 읽어옵니다. 이 Tool은 데이터를 변경하지 않습니다”처럼 범위를 명시하면 오작동 확률이 줄어듭니다. - 감사 로그를 Tool 호출 단위로 남기기: 어떤 Tool이 언제, 어떤 파라미터로 호출됐는지 로그를 남겨두면, 사고가 났을 때 원인 추적이 빨라집니다.
권한 설계 체크리스트
| 점검 항목 | 확인 질문 |
|---|---|
| Tool 분리 | 조회와 변경이 서로 다른 함수로 분리돼 있는가 |
| 서비스 계정 범위 | 이 Tool이 쓰는 인증 정보가 꼭 필요한 권한만 갖고 있는가 |
| 되돌리기 어려운 작업 | 삭제·결제·발송 류에 승인 단계가 있는가 |
| 로그 | Tool 호출 이력이 누가, 언제, 무엇을 했는지 추적 가능한가 |
| 설명 명확성 | Tool description이 수행 범위를 명확히 제한하고 있는가 |
결론
MCP는 에이전트와 외부 시스템을 연결하는 표준화된 방법입니다. 처음 시작할 때는 조회(Tool)부터 만드는 게 구현 순서상 효율적입니다. 다만 편의성을 이유로 조회와 변경을 한 함수에 몰아넣고 싶은 유혹은 처음부터 차단하세요. 권한 분리와 인증 관리를 설계 초기 단계부터 포함시키는 게, 나중에 사고가 나고 수습하는 것보다 훨씬 쉽습니다.
자주 묻는 질문
Q. 모든 사내 시스템을 다 MCP로 연결해야 하나요? 아닙니다. Claude가 자주 참조해야 하는 시스템부터 우선순위를 매겨 연결하고, 나머지는 필요할 때마다 추가하는 게 안전합니다.
Q. 삭제나 결제 같은 위험한 작업은 아예 Tool로 만들면 안 되나요? 반드시 필요하다면 만들 수는 있지만, 실행 전 사람의 명시적 확인을 요구하는 단계를 반드시 넣어야 합니다. 확인 없이 바로 실행되는 위험한 Tool은 처음부터 만들지 않는 게 가장 안전합니다.
MCP 서버를 사내 시스템에 연결하기 전 점검할 6가지
- 각 Tool이 읽기 전용인지 변경을 일으키는지 목록으로 구분했는가
- 변경을 일으키는 Tool은 별도 서버·별도 승인으로 분리했는가
- Tool마다 필요한 최소 권한만 주고, 서비스 계정에 전체 권한을 주지 않았는가
- 입력값(품목 코드, 수량 등)을 검증하고 허용 범위를 제한했는가
- 호출 기록을 누가·언제·무엇을 단위로 로그로 남기는가
- 프로토타입 수준의 최소 예제를 운영에 그대로 올리지 않았는가
추가로 자주 나오는 질문
Q. 처음에는 조회 Tool만 만들어도 되나요? 좋은 시작입니다. 조회 전용으로 효과를 검증한 뒤, 변경 기능이 정말 필요한지 따져서 위험을 통제한 방식으로 추가하세요.
Q. 편의를 위해 수정 기능도 같은 서버에 넣으면 안 되나요? 권장하지 않습니다. 같은 서버에 있으면 조회 요청이 삭제 권한까지 열어 주는 경로가 될 수 있습니다. 조회와 변경은 분리해 두는 편이 안전합니다.
Q. MCP 서버만 만들면 AI가 안전하게 쓰나요? 아닙니다. 연결 표준을 제공할 뿐 권한과 검증은 서버 설계자의 책임입니다. 프롬프트로 ‘쓰지 마라’고 지시하는 것은 보안 장치가 아닙니다.