2026년 10월 03일 약 3분 소요 작성자 Meydo Editorial Team

Function Calling은 권한이 아니다: AI 도구를 위한 안전 모델

검증과 최소 권한, 확인, 감사 가능한 도구 실행을 통해 모델의 제안과 애플리케이션의 권한을 분리하는 방법.

A proposed tool action stopped at a permission checkpoint

모델이 생성한 함수 호출은 구조화된 형태의 제안이다. 그 제안이 유효하고 권한이 있으며 안전하게 실행할 수 있는지 결정하는 주체는 모델이 아니라 애플리케이션이다.

제어 경계를 이해하라

Function Calling을 사용하면 모델이 선언된 작업을 선택하고 인수를 만들 수 있다. Google 문서는 실행 경계를 분명히 한다. 함수 코드를 실행하는 것은 애플리케이션이다. 이 분리가 안전한 설계의 토대다.

문법적으로 유효한 인수를 권한으로 취급해서는 안 된다. 모델은 사용자를 오해하거나, 주입된 지시를 반복하거나, 지나치게 큰 작업을 선택할 수 있다. 인증은 사용자를 식별하지만, 인가는 요청한 리소스와 작업을 다시 확인해야 한다.

범위가 좁은 도구를 설계하라

draft_refund와 submit_refund처럼 역할이 나뉜 도구를 임의의 내부 API를 호출할 수 있는 범용 엔드포인트보다 우선한다. 각 도구에는 필요한 최소 데이터 범위와 부작용 수준만 부여한다. 식별자, 목적지, 작업 유형에는 허용 목록을 쓴다.

설명에는 전제 조건과 하지 않는 일을 적는다. 도구 스키마에 비밀을 넣거나 불필요한 개인정보를 반환하지 않는다. 모델에 필요한 것은 올바르게 선택할 정도의 맥락이지, 백엔드에 대한 무제한 접근이 아니다.

일반 코드로 검증하라

엄격한 스키마로 파싱하고 값을 표준화한 뒤 비즈니스 규칙을 적용한다. 가격과 권한은 서버에서 다시 계산한다. 검색된 콘텐츠에 숨어 권한 확대를 시도하는 지시는 거부한다. 작업을 현재 사용자, 세션, 승인된 리소스에 결속한다.

반복 가능한 쓰기에는 멱등성 키를 사용하고 시험 실행과 확정을 분리한다. 시간 초과나 모호한 응답은 작업을 중복시킬 수 있는 맹목적 재시도가 아니라 읽기 확인으로 조정해야 한다.

결과의 무게에 맞춰 확인을 받아라

위험이 낮고 되돌릴 수 있는 조회는 자동 실행해도 된다. 외부 메시지, 구매, 삭제, 권한 변경, 공개 게시에는 미리보기나 명시적 확인이 필요하다. 원시 JSON이 아니라 수신자, 금액, 대상, 효과처럼 사용자에게 의미 있는 매개변수를 보여준다.

확인은 정확히 동결된 페이로드에 결속해야 한다. 모델이 이후 인수를 바꾸면 다시 묻는다. 승인은 만료되게 하고, 한 번의 확인으로 사용자가 보지 못한 연속 작업까지 허용하지 않는다.

판단과 결과를 감사하라

사용자 요청, 선택된 도구, 검증된 인수, 정책 판단, 확인, 결과를 기록한다. 비밀은 가리되 사고 검토에 충분한 증거를 보존한다. 거부된 호출, 반복되는 재시도, 이례적인 도구 순서를 감시한다.

직접 프롬프트 인젝션과 도구가 반환하는 악성 콘텐츠를 시험한다. 목표는 모델이 나쁜 호출을 절대 제안하지 않게 하는 것이 아니라, 나쁜 제안이 실행 경계를 넘지 못하게 하는 시스템이다.

실전에 적용하는 방법

먼저 Function Calling과 권한을 분리하는 AI 도구 안전 설계를 적용할, 범위가 명확한 워크플로 하나를 고른다. 시스템을 바꾸기 전에 현재 완료 시간, 품질 검사, 흔한 실패 범주, 에스컬레이션 경로, 결과 담당자를 한 페이지에 정리한다. 가장 깔끔한 사례만 고르지 말고 대표 표본을 선택한다. 일반 사례와 어려운 경계 사례, 그리고 멈추거나 추가 정보를 요청하는 것이 정답인 사례를 최소 하나 포함한다.

후보 시스템이 기존 절차를 대체하도록 허용하기 전에 두 시스템을 나란히 운영한다. 오류율이 낮아져도 영향이 큰 새로운 실패를 감출 수 있으므로 성공한 출력과 실패한 출력을 모두 검토한다. 각 시험에 사용한 정확한 구성을 기록하고, 다른 검토자가 결과를 재현할 수 있는 산출물을 보관한다. 파일럿이 끝나면 가장 인상적인 시연을 보고 뒤늦게 판단하지 말고, 미리 합의한 기준에 따라 확대·수정·중단을 결정한다.

벤더나 내부 팀에 물어볼 질문

핵심 주장을 뒷받침하는 증거가 무엇인지, 그 증거를 만든 시스템과 데이터의 버전은 무엇인지, 어떤 조건이 제외됐는지 묻는다. 실제 배포에서 맞닥뜨릴 언어, 입력 유형, 위험 범주별 결과를 요청한다. 변경 사항을 어떻게 알리고 회귀를 어떻게 탐지하는지, 고객이 사고 검토에 필요한 로그를 내보낼 수 있는지도 확인한다.

확신도가 낮거나 의존성이 실패하거나 요청이 지원 범위를 벗어날 때 시스템이 어떻게 작동하는지도 묻는다. 신뢰할 수 있는 제품에는 더 매끄러운 답변만이 아니라 정의된 실패 상태가 있어야 한다. 책임 주체도 중요하다. 누가 워크플로를 멈출 수 있는지, 누가 예외를 승인하는지, 중대한 오류가 운영 환경으로 빠져나갔을 때 누가 영향받은 사용자에게 알리는지 정한다.