작년에는 “에이전트가 도구를 쓸 수 있다"가 데모 포인트였다면, 2026년 실무에서는 “어떤 조건에서 어떤 도구를 호출하게 할 것인가"가 운영 핵심 이슈가 됐습니다.

MCP(Model Context Protocol) 자체는 도구 연결 표준을 제공하지만, 표준만으로는 사고를 막을 수 없습니다. 실패한 팀의 공통점은 연결 속도만 높이고 권한·감사·승인 체계를 뒤에 둔 것입니다.

이 글에서 얻는 것

  • MCP 도입 시 가장 먼저 설계해야 할 보안/운영 기준을 우선순위로 정리합니다.
  • “모든 툴 오픈” 방식이 왜 단기 생산성은 높고 장기 리스크는 큰지 이해합니다.
  • 팀 규모가 작아도 바로 적용 가능한 승인 흐름과 로그 정책을 가져갑니다.

핵심 개념/이슈

1) 문제는 프로토콜이 아니라 권한 경계

MCP로 연결 가능한 도구가 늘면 에이전트의 작업 범위가 넓어집니다. 문제는 이때 권한이 사용자 권한과 혼합되기 쉽다는 점입니다.

대표 사고 패턴:

  • 읽기 전용이어야 할 에이전트가 쓰기/삭제 API까지 호출
  • 운영 채널 공지 도구를 테스트 환경에서도 동일 권한으로 사용
  • 승인 없는 외부 전송(메일/메신저) 실행

즉, “연결 성공"과 “안전한 실행"은 별개입니다.

2) 2026년 팀들이 채택하는 최소 거버넌스

실무에서 검증된 기본선은 아래 3가지입니다.

  1. 툴 등급화: read / write / external-send / destructive
  2. 호출 정책화: 사용자 명시 지시 + 조건 충족 시에만 실행
  3. 감사 로그: 누가, 어떤 입력으로, 어떤 도구를, 언제 실행했는지 남김

특히 external-send(외부 발신)와 destructive(삭제/대량수정)는 자동 실행보다 “승인 후 1회 실행"이 사고 비용을 크게 낮춥니다.

3) 측정 가능한 운영 지표가 필요

운영 안정성을 숫자로 보지 않으면 개선이 멈춥니다.

권장 지표 예시:

  • 무승인 고위험 호출 비율: 0% 목표
  • 툴 호출 실패율(p95): 2% 이하
  • 승인 대기 시간 중앙값: 5분 이하
  • 동일 요청 재전송/중복 발신 비율: 0.5% 이하

이 지표를 대시보드로 보지 않으면, 체감상 “잘 되는 것 같은데 가끔 사고” 상태가 지속됩니다.

실무 적용

1) 권한 매트릭스부터 고정

초기 도입 팀일수록 프롬프트 튜닝보다 권한 표가 먼저입니다.

예시 매트릭스:

  • 개인 생산성 세션: read + 제한적 write
  • 운영 자동화 세션: read + write(승인) + external-send(이중 확인)
  • 배치/크론 세션: read 중심, write는 사전 정의된 경로만 허용

핵심은 “세션 목적"과 “툴 권한"을 1:1로 매핑하는 것입니다.

2) 실행 전 점검(Preflight) 규칙

고위험 작업은 아래 조건을 모두 통과해야 실행합니다.

  • 대상 경로/채널/환경이 명시됨
  • 중복 실행 여부 확인됨(최근 N분/동일 payload)
  • 롤백 가능 여부 확인됨
  • 사용자 승인 또는 정책상 자동 허용 근거 존재

이 단계만 넣어도 잘못된 채널 발송, 운영 파일 오수정 같은 사고가 급감합니다.

3) 승인 UX를 느리게 만들지 말 것

보안을 이유로 승인 단계를 과도하게 늘리면 현업은 우회합니다. 보안은 통과율이 아니라 지속 가능한 사용성까지 포함해야 합니다.

실무 권장:

  • low-risk(read): 자동
  • medium-risk(write): 조건부 자동 + 사후 감사
  • high-risk(external-send/destructive): 명시 승인

이 3단계면 통제와 생산성 균형이 비교적 잘 맞습니다.

트레이드오프/주의점

  1. 통제 강화 vs 속도 저하

    • 승인 단계를 늘리면 사고는 줄지만 리드타임이 늘어납니다.
    • 고위험 영역에만 강한 통제를 적용해야 전체 생산성이 유지됩니다.

  2. 정책 복잡도 증가

    • 팀/채널/시간대/환경 조건이 늘면 규칙 충돌이 발생합니다.
    • 예외를 코드가 아니라 정책 문서와 테스트 케이스로 관리해야 합니다.

  3. 감사 로그의 개인정보 처리

    • 입력/출력 원문을 전부 저장하면 보안 이슈가 생길 수 있습니다.
    • 민감 필드 마스킹, 보관 기간(예: 30일), 접근 권한 분리를 같이 설계해야 합니다.

  4. “모델이 똑똑하면 괜찮다” 착각

    • 모델 성능 향상은 오판 확률을 낮출 뿐, 권한 오남용을 막지 않습니다.
    • 보안은 모델 품질이 아니라 시스템 제약으로 보장해야 합니다.

체크리스트 또는 연습

  • 우리 팀 툴을 read/write/external-send/destructive로 분류했다.
  • high-risk 툴에는 명시 승인 규칙을 적용했다.
  • 실행 로그(요청자, 입력 요약, 도구, 결과, 시간)를 남긴다.
  • 중복 발신 방지 키(idempotency key)를 외부 전송에 적용했다.
  • 월 1회 정책 예외 케이스를 리뷰한다.

연습 과제:

  1. 현재 사용하는 자동화 도구 5개를 골라 위험 등급을 지정해보세요.
  2. 외부 전송 도구 1개를 선택해 승인 플로우(누가, 언제, 무엇을 확인)를 문서화하세요.
  3. “승인 누락으로 잘못 발송” 시나리오를 가정하고 탐지/복구 시간을 측정해보세요.

관련 글