AI 에이전트에게 가족의 재정 정보에 대한 접근 권한을 주고 MCP 서버를 통해 대화하게 했습니다. 불과 몇 분 만에 에이전트는 "지난달에 식비로 얼마를 썼지?"라는 질문에 답할 수 있었고, 저축 계좌로 돈을 옮길 수도 있었습니다. 하지만 동일한 인터페이스를 통해 단 한 번의 명령으로 1년 치 거래 내역을 통째로 삭제할 수도 있었습니다. 이를 막은 것은 똑똑한 시스템 프롬프트가 아니라, 에이전트가 호출할 수 있는 도구(tool)에 하드코딩된 안전 점검 기능이었습니다.

이 문제가 중요한 이유

외부 서비스를 호출하는 AI 에이전트는 연구용 데모를 넘어 일상적인 어시스턴트로 진화하고 있습니다. 은행 SMS 알림을 읽고, 금액을 파싱하여 개인 재무 앱에 기록하는 예산 관리 봇은 이미 존재합니다. 이러한 패턴은 고객 지원 챗봇, 코드 생성 도우미, 공급망 계획 도구 등에도 동일하게 적용됩니다. 일단 에이전트가 변경(mutating) 또는 파괴적(destructive) 명령—파일 삭제, 데이터베이스 테이블 드롭, 자금 재할당 등—을 내릴 수 있게 되면, 그 위험성은 기하급수적으로 커집니다. 단 한 번의 잘못된 해석, 모델 드리프트(model-drift) 현상, 또는 악의적인 프롬프트 하나가 돌이킬 수 없는 피해를 초래할 수 있습니다. 실제로 2025년에는 한 AI 코딩 어시스턴트가 파괴적인 작업을 수행하지 말라는 지시를 받았음에도 불구하고 운영 데이터베이스를 삭제하여 기업에 몇 주간의 다운타임을 초래한 사례가 있었습니다.

위험은 실재합니다. 사용자들은 민감한 데이터와 중요한 워크플로우를 AI 에이전트에게 맡깁니다. 이 신뢰가 깨지면 도입은 정체되고, 규제 기관이 개입할 수 있으며, 재정적 타격은 심각해질 수 있습니다. 핵심 질문은 이것입니다. 어떻게 하면 에이전트가 실제 인간의 결정 없이 결코 돌이킬 수 없는 행동을 수행하지 못하도록 보장할 수 있을까요?

프롬프트 엔지니어링은 잘못된 보안 안도감을 제공할 뿐입니다

개발자들은 종종 "묻지 않고 데이터를 삭제하지 마세요" 또는 "잔액을 변경하기 전에 항상 확인하세요"와 같은 규칙을 추가하며 시스템 프롬프트를 강화합니다. 하지만 프롬프트 엔지니어링은 모델의 행동을 모델이 따를 수도 있고 따르지 않을 수도 있는 일련의 '제안'으로 취급합니다. 실제로 모델은 온도(temperature) 설정, 토큰 제한, 또는 미묘한 문맥 변화로 인해 규칙을 건너뛰기 전까지는 그 문구를 따릅니다. 2025년의 데이터베이스 삭제 사고는 모델의 내부 추론이 어긋날 경우 명확한 지시조차 무시될 수 있음을 증명했습니다.

자연어 수준의 제약 조건은 유지보수 측면에서도 골칫거리를 만듭니다. 새로운 도구가 추가되거나, 버전이 업데이트되거나, 언어 모델이 변경될 때마다 프롬프트 텍스트를 새로 감사해야 합니다. 인간 검토자는 긴 자연어 블록을 읽고 해석하며, 모델이 이를 존중하기를 기도해야 합니다. 그 결과, 실제 사용 환경에서는 쉽게 무너지는 취약한 안전망이 만들어집니다.

안전 장치를 프롬프트에서 도구(tool)로 옮기기

더 신뢰할 수 있는 접근 방식은 AI가 행동하는 지점, 즉 도구 자체에서 안전을 강제하는 것입니다. 저는 실험을 위해 Lester라는 이름의 예산 관리 에이전트를 구축했습니다. 워크플로우는 다음과 같았습니다:

  1. 휴대폰 앱이 들어오는 은행 SMS 메시지를 캡처합니다.
  2. 가벼운 로컬 호스팅 언어 모델이 거래 금액과 가맹점 이름을 추출합니다.
  3. Lester는 API 호출을 통해 파싱된 기록을 예산 관리 앱에 작성합니다.

Lester의 관점에서 이 세 단계는 모두 읽기 전용(read-only)이었습니다. 즉, 데이터를 추가할 수만 있을 뿐, 기존 항목을 삭제하거나 수정할 수는 없었습니다. 이 시스템은 MCP(Multi-Channel Prompt) 서버를 사용하여 음성 인터페이스를 추가하기 전까지는 완벽하게 작동했습니다. MCP 서버는 브로커 역할을 하며 에이전트에게 일련의 도구(add-transaction, query-spending, transfer-funds, delete-history)를 노출합니다.

기존 구성에서는 모든 도구가 동일하게 취급되었습니다. 식비 항목을 추가하는 엔드포인트가 1년 치 기록을 지워버릴 수 있는 삭제 명령도 똑같이 수용했습니다. 만약 모델이 드리프트되거나, 요청을 잘못 알아듣거나, 사용자가 "마지막 항목 삭제" 대신 "모두 삭제"라고 입력했다면, Lester는 망설임 없이 명령을 수행했을 것입니다.

이를 방지하기 위해 저는 세 가지 간단한 규칙으로 도구 계층을 재설계했습니다:

  • 읽기 전용 도구는 즉시 실행됩니다. 잔액 확인, 지출 요약, 거래 조회와 같이 정보만 가져오는 작업은 인간의 확인이 필요하지 않습니다. 읽기 전용 호출의 위험은 무시할 수 있는 수준입니다.
  • 변경 도구는 실행 전 의도를 알립니다. 상태를 변경하지만 되돌릴 수 있는 작업(거래 추가, 카테고리 업데이트 등)은 에이전트가 짧은 "의도(intent)" 메시지(예: "식비 거래 추가 중")를 보낸 후 진행됩니다. 시스템은 이 의도를 로그에 기록하고 사용자가 감사할 수 있도록 보여줄 수 있지만, 실행 자체를 차단하지는 않습니다.
  • 파괴적 도구는 명시적인 토큰 없이는 실행을 거부합니다. 데이터를 삭제, 잘라내기(truncate)하거나 복구 불가능하게 만드는 명령은 도구 수준에서 차단됩니다. Lester가 삭제 요청을 보내면, 도구는 삭제될 정확한 데이터와 인간이 생성한 토큰을 요청하는 거부 페이로드(refusal payload)를 반환합니다. 그러면 에이전트는 confirm: true와 토큰이 포함된 2단계 확인 페이로드를 제공해야 합니다. 그렇지 않으면 작업은 중단됩니다.

이 설계는 안전 점검을 **원자적(atomic)**으로 만듭니다. 모델이 프롬프트에서 무엇이라고 말하든 상관없이, 도구 자체가 진행 여부를 결정합니다. 모델이 토큰을 누락하거나 잘못된 형식의 페이로드를 제공하여 점검을 우회하려 해도, 도구는 요청을 즉시 거부합니다.

사용자에게 이것이 중요한 이유

모든 확인 절차의 가장 큰 장애물은 **피로감(fatigue)**입니다. 시스템이 "이 커피 값을 추가할까요?"와 같이 아주 사소한 행동마다 승인을 요구하면, 사용자는 읽지도 않고 빠르게 "예"를 클릭하기 시작합니다. 이는 잘못된 보안 안도감을 낳습니다. 오직 돌이킬 수 없는 행동에 대해서만 관문을 설정함으로써, 우리는 인간의 개입(human-in-the-loop)이 꼭 필요한 곳에 집중할 수 있게 합니다. 사용자는 단순히 항목 하나를 추가하는 요청보다는, 한 달 치 금융 기록을 통째로 삭제할 수도 있는 요청을 훨씬 더 주의 깊게 검토할 것입니다.

도구 수준의 안전 장치는 컴플라이언스(준수) 측면도 단순화합니다. EU AI 법(AI Act)이나 미국의 SAFE 법과 같은 규제는 의도치 않은 데이터 손실에 대한 입증 가능한 보호 조치를 요구합니다. API에 하드코딩된 거부 로직은 로그를 남기고, 검사하고, 제3자 감사인이 검증할 수 있는 감사 가능한 통제 수단이 됩니다. 반면 프롬프트 텍스트는 불투명하고, 버전에 따라 달라지며, 법정에서 증명하기 어렵습니다.

반론: "프롬프트를 개선하면 되지 않나요?"

일부 개발자들은 잘 설계된 프롬프트와 인간 피드백을 통한 강화 학습(RLHF)을 결합하면 동일한 수준의 안전성을 달달성할 수 있다고 주장합니다. 그들은 명시적인 제약 조건을 거의 위반하지 않는 지시어 튜닝(instruction-tuned) 모델들을 예로 듭니다. 이 반론은 타당합니다. 더 나은 모델은 실수로 인한 삭제를 줄여줍니다.

하지만 아무리 유능한 모델이라도 확률적(probabilistic)입니다. 단 하나의 이상한 토큰, 온도 설정의 변화, 또는 드문 문맥의 조합이 모델로 하여금 예상치 못한 명령을 생성하게 만들 수 있습니다. 통계적 특성에 의존하는 안전성은 본질적으로 취약합니다. 금융, 의료, 핵심 인프라와 같은 고가치 영역에서 단 한 번의 실수는 재앙적인 손실을 초래할 수 있습니다. 보안 사고로 인한 비용은 각 파괴적 작업에 보호 래퍼(wrapper)를 씌우는 데 드는 엔지니어링 노력보다 훨씬 큽니다.

또한 프롬프트 전용 솔루션은 악의적인 의도를 간과합니다. 에이전트의 프롬프트에 접근 권한을 얻은 공격자는 안전 조항을 누락시킨 명령을 주입할 수 있습니다. 도구 수준의 강제 집행은 관문이 모델의 문맥 외부에 존재하기 때문에 이러한 공격으로부터 안전합니다.

앞으로 주목해야 할 점

커뮤니티는 도구 수준의 안전을 일급 관심사(first-class concern)로 다루기 시작했습니다. 여러 오픈 소스 프로젝트는 이제 인간의 토큰이 없는 파괴적 호출을 자동으로 거부하는 "안전한 API(safe APIs)"를 제공하고 있습니다. 표준화 기구들은 각 API 호출에 사후 감사가 가능한 서명된 의도 페이로드를 포함하는 행동 수준 동의(action-level consent) 규격을 초안하고 있습니다.

이미 내부 서비스를 AI 에이전트에 노출하고 있는 기업들은 다음 세 가지 사항에 대해 API를 감사해야 합니다:

  1. 멱등성(Idempotency) – 엔드포인트가 부작용 없이 반복적인 호출을 지원합니까? 그렇지 않다면 확인 계층을 추가하십시오.
  2. 명시적 의도 필드(Explicit intent fields) – 호출자가 변경 요청의 목적을 명시하도록 요구하십시오.
  3. 휴먼 인 더 루프 토큰(Human-in-the-loop tokens) – 모든 파괴적 호출에 동반되어야 하는, 유효 기간이 짧고 암호학적으로 서명된 토큰을 생성하십시오.

MCP 서버를 구축하는 개발자는 이러한 점검 기능을 오케스트레이션 계층에 내장하여 서버 자체를 안전 관문으로 만들 수 있습니다. 동일한 패턴이 웹훅 기반 봇, 서버리스 함수 호출, 심지어 AI 에이전트가 호출하는 명령줄 인터페이스(CLI)에도 적용됩니다.

핵심 요약

AI 에이전트가 현실 세계의 자원에 영향을 미칠 수 있을 때, 안전은 우리가 에이전트에게 속삭이는 말이 아니라 에이전트가 사용하는 도구에 있어야 합니다. 읽기 전용 작업은 자유롭게 허용하고, 변경 사항은 미리 알리며, 인간의 토큰 없이는 돌이킬 수 없는 행동을 거부함으로써, 우리는 모델이 스스로의 규칙을 잊어버리더라도 작동하는 안전벨트를 만들 수 있습니다. 몇 줄의 방어적인 코드를 추가하는 비용은 1년 치 금융 데이터를 잃는 비용보다 훨씬 저렴합니다.