생성형 AI가 답변만 만들던 단계에서 실제 업무를 수행하는 AI 에이전트 단계로 이동하고 있습니다. 이제 에이전트는 고객 정보를 검색하고, 견적 초안을 만들고, 메일을 보내고, CRM 상태를 바꾸고, 경우에 따라 결제나 설비 제어까지 시도합니다. MCP(Model Context Protocol) 같은 연결 표준은 이런 도구 통합을 빠르게 만들었습니다. 하지만 연결이 쉬워질수록 더 중요한 질문이 생깁니다. AI가 무엇을 할 수 있고, 누구의 권한으로, 어느 순간 사람에게 멈춰 서야 하는가?
많은 팀이 에이전트 프로젝트를 모델과 프롬프트 중심으로 시작합니다. 데모에서는 잘 작동합니다. 그러나 운영 환경에 연결하면 문제의 중심은 모델 성능에서 권한과 통제로 옮겨갑니다. 잘못된 답변은 수정할 수 있지만, 잘못 발송된 메일이나 삭제된 고객 데이터, 중복 실행된 환불은 되돌리기 어렵습니다.
핵심: 에이전트의 안전성은 “모델이 실수하지 않게 만드는 것”이 아니라 “실수해도 피해 범위를 제한하고, 중요한 행동은 검증하며, 모든 과정을 재구성할 수 있게 만드는 것”이다.
MCP는 무엇을 해결하고, 무엇을 해결하지 않는가
MCP는 AI 애플리케이션이 데이터와 도구를 표준화된 방식으로 발견하고 호출하도록 돕습니다. CRM마다, 문서 저장소마다, 사내 API마다 별도의 접착 코드를 반복해서 만드는 부담을 줄일 수 있습니다. 2026-07-28 규격에서는 인증 강화, 추적 가능한 메타데이터, 장기 실행 작업 같은 운영 기능도 발전했습니다.
하지만 MCP 서버를 연결했다고 권한 설계가 자동으로 완성되는 것은 아닙니다. 프로토콜은 통로를 정의합니다. 어떤 도구를 노출할지, 어떤 사용자에게 어떤 범위를 줄지, 외부 문서의 지시를 신뢰할지, 실행 전에 승인받을지는 애플리케이션과 조직이 결정해야 합니다.
이를 사내 API 게이트웨이에 비유할 수 있습니다. HTTP를 사용한다고 API 보안이 저절로 생기지 않는 것처럼, MCP를 사용한다고 에이전트 보안이 저절로 생기지는 않습니다. 오히려 에이전트는 자연어를 해석하고 여러 도구를 연속으로 선택하기 때문에 기존 API보다 더 세밀한 경계가 필요합니다.
가장 위험한 착각: 사용자의 권한을 그대로 복제하기
직원 A가 CRM 관리자라고 해서 A가 사용하는 AI 에이전트에도 관리자 토큰을 그대로 주면 안 됩니다. 사람은 화면을 보고 맥락을 판단하지만, 에이전트는 이메일·웹페이지·첨부파일에 숨은 악성 지시를 업무 요청으로 오해할 수 있습니다. NIST가 다루는 에이전트 하이재킹은 이 문제를 보여줍니다. 공격자가 에이전트가 읽을 데이터에 간접 프롬프트를 심어 의도하지 않은 행동을 유도하는 방식입니다.
OWASP가 말하는 과도한 대행 권한(Excessive Agency)도 같은 지점을 짚습니다. 필요 이상의 기능, 범위, 자율성을 한 번에 주면 작은 판단 오류가 실제 피해로 확대됩니다. “사용자가 할 수 있으니 에이전트도 할 수 있다”가 아니라, 이번 업무를 수행하는 데 필요한 최소 행동만 한시적으로 허용한다가 기본 원칙이어야 합니다.
안전한 구조의 중심: 액션 게이트웨이
에이전트가 업무 시스템을 직접 호출하게 두는 대신 중간에 액션 게이트웨이를 둡니다. 에이전트는 실행 명령이 아니라 구조화된 ‘행동 제안’을 게이트웨이에 보냅니다. 게이트웨이는 사용자 신원, 허용 범위, 입력 스키마, 정책, 승인 여부, 호출 예산을 확인한 뒤 실제 시스템에 요청합니다.
이 구조가 중요한 이유는 확률적인 판단과 결정적인 통제를 분리하기 때문입니다. 모델은 “이 고객에게 환불이 필요하다”고 제안할 수 있지만, 환불 가능 기간과 최대 금액, 담당자 승인 여부는 코드로 검사합니다. 모델이 정책을 설명하게 할 수는 있어도 정책 집행 자체를 자연어 지시에만 맡기면 안 됩니다.
게이트웨이가 확인할 8가지
- 주체: 현재 사용자와 에이전트 인스턴스는 누구인가
- 목적: 어떤 업무 티켓과 사용자 요청을 위해 실행하는가
- 도구: 이 역할에 노출해도 되는 도구인가
- 범위: 어떤 고객·프로젝트·폴더·기간의 데이터까지 접근 가능한가
- 인자: 입력이 엄격한 스키마와 업무 규칙을 통과하는가
- 위험: 외부 전송, 금전, 삭제, 권한 변경처럼 중요한 행동인가
- 승인: 누가 무엇을 보고 승인했고 승인 후 내용이 변하지 않았는가
- 예산: 호출 횟수, 금액, 시간, 데이터량 한도를 넘지 않았는가
도구는 CRUD가 아니라 업무 의도로 설계한다
에이전트에게 execute_sql, call_any_api, write_file처럼 범용 도구를 주면 개발은 빠릅니다. 하지만 모델이 선택할 수 있는 행동 공간이 너무 커집니다. 운영 도구는 기술 명령이 아니라 제한된 업무 의도로 설계하는 편이 안전합니다.
예를 들어 update_customer 하나보다 add_customer_note, request_address_change, close_resolved_case처럼 동작을 쪼갭니다. 각 도구에 허용 필드, 최대 길이, 상태 전이, 승인 조건을 넣을 수 있습니다. SQL을 만들게 하는 대신 고객 ID와 메모 본문만 받으면 다른 테이블을 건드릴 가능성도 사라집니다.
읽기 도구도 무제한이면 안전하지 않습니다. 전체 고객 목록을 한 번에 내보내는 검색, 개인 메일함 전체를 읽는 기능, 문서 저장소를 재귀적으로 훑는 기능은 데이터 유출 통로가 될 수 있습니다. 테넌트, 프로젝트, 날짜, 건수 제한을 도구 내부에서 강제해야 합니다.
권한은 연결 시점이 아니라 요청마다 확인한다
MCP의 HTTP 인증은 OAuth 기반 흐름과 대상 리소스에 묶인 토큰 검증을 다룹니다. 여기서 실무적으로 중요한 것은 토큰 전달 금지와 대상 확인입니다. 한 서버에서 받은 토큰을 다른 하위 시스템에 그대로 넘기면 권한 경계가 무너질 수 있습니다.
권장 흐름은 다음과 같습니다. 사용자는 자신의 신원으로 에이전트 호스트에 로그인합니다. 호스트는 해당 MCP 서버용으로 범위가 제한된 토큰을 얻습니다. MCP 서버는 요청마다 사용자, 테넌트, 스코프를 검증하고 내부 시스템을 호출할 때는 별도의 서비스 자격증명 또는 토큰 교환을 사용합니다. 로그에는 비밀 토큰이 아니라 주체와 승인된 스코프의 식별자만 남깁니다.
장기 작업에서는 권한이 시작 시점 이후 바뀔 수 있습니다. 퇴사, 역할 변경, 승인 철회가 발생하면 진행 중인 작업도 중단되어야 합니다. 작업 생성 때 한 번 확인하고 끝내지 말고 중요한 단계마다 권한을 다시 확인해야 합니다.
자율성은 한 번에 열지 않고 단계별로 올린다
‘에이전트를 도입한다’는 말에는 서로 다른 수준이 섞여 있습니다. 사내 자료를 검색하는 기능과 실제 송금 기능을 같은 방식으로 출시할 수 없습니다. 위험이 증가할수록 권한과 검증을 추가하는 자율성 사다리를 사용하면 출시 범위를 명확히 할 수 있습니다.
- 1단계 — 읽기: 제한된 자료를 검색하고 출처와 함께 보여준다.
- 2단계 — 초안: 메일·보고서·티켓을 만들되 사람이 직접 제출한다.
- 3단계 — 가역적 실행: 라벨 추가, 임시 저장처럼 쉽게 되돌릴 수 있는 행동을 수행한다.
- 4단계 — 승인 실행: 외부 발송, 환불, 계약 변경 등은 최종 내용을 고정한 뒤 사람이 승인한다.
- 5단계 — 제한 또는 금지: 대량 삭제, 권한 승격, 비밀정보 반출처럼 피해가 큰 행동은 별도 시스템이나 사람만 수행한다.
좋은 도입 전략은 처음부터 완전 자율을 목표로 하지 않습니다. 1~2단계에서 실제 실패 사례를 모으고 평가한 뒤, 가역성과 영향 범위를 기준으로 다음 단계의 도구를 하나씩 엽니다.
사람 승인은 팝업 하나가 아니다
승인 화면이 있어도 사용자가 무엇을 승인하는지 알 수 없다면 의미가 없습니다. “계속하시겠습니까?” 대신 대상, 변경 전후, 외부 수신자, 금액, 사용 데이터, 되돌릴 수 있는 시간과 예상 영향을 보여줘야 합니다.
승인 후 에이전트가 인자를 다시 바꾸는 문제도 막아야 합니다. 승인 화면에 표시한 정규화된 요청의 해시를 만들고, 실행 시 동일한 요청인지 검증합니다. 승인에는 만료 시간을 두고 일회성으로 소비합니다. 대량 작업은 일부 샘플만 승인받지 말고 전체 대상 집합과 상한을 확정해야 합니다.
프롬프트 인젝션은 입력 필터만으로 막기 어렵다
“앞의 지시를 무시하라” 같은 문장을 차단하는 것만으로 충분하지 않습니다. 공격 지시는 PDF의 흰색 글자, 웹페이지의 숨은 영역, 이메일 서명, 검색 결과, 이미지 안의 문자에 들어갈 수 있습니다. 정상 문서와 악성 지시의 경계가 문맥에 따라 달라 완벽한 분류기는 기대하기 어렵습니다.
따라서 외부 콘텐츠는 기본적으로 데이터이지 명령이 아니다라는 경계를 유지합니다. 검색·문서 읽기 단계와 행동 결정 단계를 분리하고, 외부 콘텐츠가 도구 이름이나 수신자, 권한 범위를 직접 결정하지 못하게 합니다. 민감한 도구 호출은 별도의 정책 엔진과 사람 승인으로 막습니다. 탐지 모델은 방어 계층 중 하나일 뿐 최종 권한 통제가 아닙니다.
결과가 아니라 실행 경로를 평가한다
일반 챗봇 평가는 최종 답변의 정확성과 유용성을 중심으로 합니다. 에이전트는 경로까지 평가해야 합니다. 정답을 만들었어도 고객 데이터 전체를 불필요하게 조회했거나, 같은 메일을 두 번 보냈거나, 실패 후 무한 재시도했다면 안전한 에이전트가 아닙니다.
운영 전 평가 세트에는 정상 업무뿐 아니라 다음 시나리오가 포함되어야 합니다.
- 외부 문서에 도구 실행을 유도하는 악성 지시가 들어 있는 경우
- 다른 고객이나 프로젝트의 식별자를 인자로 넣는 경우
- 승인 직전과 실행 직전에 금액이나 수신자가 바뀌는 경우
- 네트워크 타임아웃 뒤 동일 작업이 재실행되는 경우
- 도구 설명이 모호하거나 서로 비슷해 잘못 선택하는 경우
- 호출 횟수·비용·처리 시간 한도에 도달하는 경우
- 작업 도중 사용자 권한이 철회되는 경우
평가지표도 작업 성공률 하나로 끝내지 않습니다. 불필요한 도구 호출 비율, 권한 거부 정확도, 승인 없는 중요 행동 수, 중복 실행률, 평균 복구시간, 감사 로그 완전성, 사용자 개입률을 함께 봅니다.
관측 가능성: 한 요청을 끝까지 추적한다
사용자 요청 하나가 모델 추론, MCP 클라이언트, 여러 서버, 내부 API, 메시지 큐를 거치면 일반 애플리케이션 로그만으로 원인을 찾기 어렵습니다. 모든 단계에 같은 트레이스 ID를 전달하고, 도구 제안·정책 판단·승인·실행·결과를 하나의 타임라인으로 묶어야 합니다.
다만 프롬프트와 응답을 무조건 원문 저장하면 개인정보와 영업비밀이 로그에 복제됩니다. 기본은 구조화된 메타데이터와 해시, 정책 결과를 남기고, 원문은 마스킹·암호화·보관 기간·접근 승인을 별도로 적용해야 합니다. 장애 분석에 필요한 정보와 저장하면 안 되는 정보를 먼저 분류해야 합니다.
실패와 재시도를 정상 흐름으로 설계한다
에이전트는 여러 단계를 수행하므로 중간 실패가 필연적입니다. 네트워크 응답을 못 받았다고 같은 환불을 다시 실행하면 안 됩니다. 모든 변경 도구는 멱등성 키를 받고, 실행 결과를 조회할 수 있어야 합니다. 다단계 작업은 각 단계의 상태와 보상 작업을 정의합니다.
재시도 횟수와 총 행동 수에도 상한을 둡니다. 실패가 반복되면 모델이 새로운 우회 경로를 계속 찾게 하지 말고 사람에게 넘깁니다. OpenAI의 에이전트 구축 가이드도 실패 임계치와 중요 행동을 사람 개입의 대표적인 조건으로 제시합니다.
4주 안에 만드는 최소 안전 기반
1주차: 행동 목록과 위험 분류
에이전트가 읽고 쓰려는 시스템과 도구를 모두 적습니다. 각 행동을 읽기, 초안, 가역적 변경, 외부 영향, 금전·권한·삭제로 나누고 데이터 범위와 업무 책임자를 지정합니다.
2주차: 좁은 도구와 정책 계층
범용 API를 업무 의도별 도구로 쪼개고 JSON 스키마, 테넌트 경계, 상태 전이, 호출·금액 한도를 코드로 강제합니다. 에이전트가 직접 운영 자격증명을 보지 못하게 게이트웨이에 보관합니다.
3주차: 승인·멱등성·감사 추적
중요 행동의 승인 화면을 만들고 승인된 인자를 고정합니다. 변경 호출에 멱등성 키를 넣고, 사용자 요청부터 실제 시스템 결과까지 하나의 트레이스로 연결합니다.
4주차: 공격·실패 시나리오 평가
간접 프롬프트 인젝션, 경계 밖 데이터 접근, 중복 실행, 권한 철회, 공급 시스템 장애를 시험합니다. 통과한 도구만 제한된 사용자에게 열고 실제 실패 데이터를 다음 평가 세트에 추가합니다.
네이처프랙탈이 보는 에이전트 프로젝트의 성공 조건
에이전트 프로젝트는 챗 화면을 만드는 일이 아니라 기존 업무 시스템의 권한과 상태 변화를 재설계하는 일입니다. 네이처프랙탈은 업무 흐름과 위험도를 먼저 정리하고, 작은 도구 집합으로 PoC를 만든 뒤, 기존 API·DB·인증 체계와 연결합니다. 이후 평가, 승인, 추적, 운영 대시보드까지 이어져야 실제 현장에서 반복 사용할 수 있습니다.
MCP는 연결 속도를 높이는 좋은 표준입니다. 하지만 경쟁력은 커넥터 개수에서 나오지 않습니다. 업무 가치가 높은 행동을 얼마나 작고 안전하게 정의하고, 문제가 생겼을 때 얼마나 빨리 멈추고 설명할 수 있는가에서 나옵니다.
도입 전 체크리스트
- 에이전트가 사용하는 자격증명이 개인 관리자 권한과 분리돼 있는가?
- 사용자·테넌트·프로젝트 범위를 요청마다 검증하는가?
- 범용 실행 도구 대신 업무 의도별로 좁은 도구를 제공하는가?
- 외부 콘텐츠를 데이터로 취급하고 행동 명령과 분리하는가?
- 금전·외부 발송·삭제·권한 변경은 사람이 구체적인 내용을 보고 승인하는가?
- 승인 후 실행 인자가 바뀌지 않았음을 검증하는가?
- 중복 실행 방지, 재시도 상한, 중단과 롤백 절차가 있는가?
- 모든 도구 호출을 하나의 트레이스로 재구성할 수 있는가?
