재고 조회 하나 붙였다가 삭제 권한까지 열려버린 이야기 — MCP 서버 보안 설계

재고 조회 하나 붙였다가 삭제 권한까지 열려버린 이야기 — MCP 서버 보안 설계

복사-붙여넣기의 한계

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 자체를 만들지 않거나, 만들더라도 실행 전 별도 확인 단계를 반드시 넣습니다.

결론

MCP는 에이전트와 외부 시스템을 연결하는 표준화된 방법입니다. 처음 시작할 때는 조회(Tool)부터 만드는 게 구현 순서상 효율적입니다. 다만 편의성을 이유로 조회와 변경을 한 함수에 몰아넣고 싶은 유혹은 처음부터 차단하세요. 권한 분리와 인증 관리를 설계 초기 단계부터 포함시키는 게, 나중에 사고가 나고 수습하는 것보다 훨씬 쉽습니다.

자주 묻는 질문

Q. 모든 사내 시스템을 다 MCP로 연결해야 하나요? 아닙니다. Claude가 자주 참조해야 하는 시스템부터 우선순위를 매겨 연결하고, 나머지는 필요할 때마다 추가하는 게 안전합니다.

Q. 삭제나 결제 같은 위험한 작업은 아예 Tool로 만들면 안 되나요? 반드시 필요하다면 만들 수는 있지만, 실행 전 사람의 명시적 확인을 요구하는 단계를 반드시 넣어야 합니다. 확인 없이 바로 실행되는 위험한 Tool은 처음부터 만들지 않는 게 가장 안전합니다.

질문이나 지적할 부분이 있으면 문의로 알려주세요.

Questions or corrections? Let us know via Contact.

AI

AI map Ontology

기업 IT·데이터 조직에서 20년 넘게 실무를 해온 사람이 씁니다. 모든 사례는 익명화·일반화합니다. 소개 보기 →

AI

AI map Ontology

Written by someone with 20+ years in enterprise IT and data. All cases are anonymized and generalized. About us →

다음으로 읽어볼 글

개념을 이해했다면, 실제 설계와 활용 방법을 이어서 살펴보세요.

온톨로지 Foundry AIP 기업 AI 전략

Keep reading

Once you understand the concept, continue on to real design and usage patterns.

Ontology Foundry AIP Enterprise AI Strategy