모델 출력은 실행 명령이 아니라 검증해야 할 제안이며, 실제 실행 책임은 권한과 상태를 아는 애플리케이션에 있습니다.
도구 호출은 언어모델이 외부 기능을 사용할 수 있게 하지만, 모델이 데이터베이스 권한과 최신 상태를 완전히 아는 것은 아닙니다. 어떤 함수를 고르고 어떤 인수를 넣을지 제안할 수 있어도, 그 호출이 허용되고 안전한지는 시스템이 독립적으로 판단해야 합니다.
AI 핵심 지식 52편 중 33편입니다. 제품 화면이 바뀌어도 남는 원리와 판단 기준을 다룹니다.
모델과 애플리케이션의 책임
| 주체 | 담당 | 담당하면 안 되는 것 |
|---|---|---|
| 모델 | 의도 해석·도구 후보·인수 초안 | 권한과 실행 성공을 스스로 확정 |
| 애플리케이션 | 스키마·권한·대상·상태·부작용 검증 | 모델 말투를 승인으로 간주 |
| 사용자·운영자 | 고위험 행동 승인·정책·감사 | 모든 세부 호출을 맹목 확인 |
안전한 도구 호출 경로
- 도구를 읽기·쓰기·외부 영향과 권한 범위로 분류한다.
- 모델 제안 인수를 스키마와 업무 규칙으로 검증한다.
- 대상·현재 상태·사용자 권한·승인 필요성을 확인한다.
- 실행 결과와 실패를 모델에 반환하고 로그·중단 조건을 적용한다.
모델은 호출을 제안하고 시스템이 실행한다
함수 호출 형식은 모델이 자연어 의도를 구조화된 도구 이름과 인수로 표현하게 합니다. Toolformer 연구는 모델이 언제 어떤 API를 호출하고 결과를 다음 예측에 반영할지 학습할 수 있음을 보여 줍니다. 하지만 구조화된 호출이 곧 실행 권한을 뜻하지는 않습니다. 모델은 사용자의 실제 계정 상태, 데이터베이스 제약, 네트워크 오류, 최신 승인 여부를 완전히 알지 못할 수 있습니다. 존재하지 않는 ID나 허용되지 않은 값을 그럴듯하게 만들 수도 있습니다. 따라서 실행기는 호출을 외부에서 들어온 입력처럼 취급하고 스키마와 업무 규칙을 검증해야 합니다. 도구 이름이 허용 목록에 있는지, 필수 인수가 있는지, 대상이 실제로 존재하는지 확인합니다. 모델이 ‘사용자가 승인했다’고 말해도 시스템의 승인 기록과 일치하지 않으면 실행하지 않습니다. 책임을 나누면 모델 선택 오류를 코드에서 차단할 수 있고, 모델을 바꿔도 권한 계약을 유지할 수 있습니다. 도구 호출의 핵심 인터페이스는 자유로운 자연어와 실제 부작용 사이에 독립 검증 계층을 두는 것입니다.
도구 정의는 최소 기능과 명확한 의미를 가져야 한다
하나의 도구가 조회, 수정, 삭제를 모두 수행하고 넓은 인수를 받으면 모델의 작은 선택 오류가 큰 결과로 이어질 수 있습니다. 읽기와 쓰기를 분리하고, 고위험 행동은 더 구체적인 함수와 좁은 스키마를 사용하는 편이 좋습니다. 함수 이름과 설명은 언제 써야 하고 언제 쓰면 안 되는지 드러내야 합니다. 서로 비슷한 도구가 많으면 모델이 잘못 선택할 가능성이 커지므로 중복을 줄이고 차이를 명시합니다. 기본값이 위험한 행동을 만들지 않게 하며, 생략된 필드를 시스템이 넓은 범위로 해석하지 않습니다. 입력 문자열을 코드, SQL, 경로로 직접 연결하지 말고 허용 값과 이스케이프, 샌드박스를 적용합니다. 응답도 단순 성공 문자열보다 변경된 대상과 상태, 오류 코드를 구조화해 반환해야 다음 판단이 가능합니다. 사용하지 않는 도구는 제거하고 사용자·과업별로 필요한 기능만 노출합니다. OWASP가 말하는 과도한 기능·권한·자율성을 줄이는 일은 프롬프트 경고보다 도구 표면을 작게 만드는 설계에서 시작합니다.
권한과 승인은 행동의 영향으로 결정한다
모든 도구 호출에 같은 승인 절차를 붙이면 사용자는 경고에 익숙해지고 실제 위험을 놓칠 수 있습니다. 읽기 전용 조회, 내부 임시 계산, 되돌릴 수 있는 초안 저장, 외부 전송·결제·삭제처럼 행동을 영향과 복구 가능성으로 분류합니다. 사용자의 현재 권한이 해당 대상에 적용되는지 실행 시점에 다시 확인합니다. 외부 데이터가 호출 인수에 영향을 주는 경우 간접 프롬프트 인젝션을 고려해 출처와 신뢰 수준을 표시합니다. 사람 승인이 필요할 때는 모델이 만든 요약만 보여 주지 말고 실제 대상, 변경 내용, 수신자, 비용, 되돌리기 가능성을 시스템이 렌더링해야 합니다. 공격자가 외부 문서로 승인 설명을 조작할 수 있기 때문입니다. 대량 행동은 개별 호출이 허용돼도 총량 제한과 이상 탐지가 필요합니다. 승인은 책임을 사용자에게 떠넘기는 버튼이 아니라 시스템이 위험 정보를 정확히 보여 주고 의도를 재확인하는 통제입니다. 승인 뒤에도 실행 결과와 부분 실패를 기록하고 예상과 다르면 중단·복구 경로를 제공해야 합니다.
관찰 결과와 오류도 신뢰 경계를 가진다
도구가 반환한 결과는 다음 모델 호출의 입력이 되지만 항상 신뢰할 수 있는 것은 아닙니다. 웹페이지와 이메일에는 악성 지시가 포함될 수 있고, API는 오래된 캐시나 부분 결과, 오류 메시지를 반환할 수 있습니다. 결과를 시스템 지시와 분리해 데이터로 표시하고 출처·시간·성공 여부를 유지합니다. 모델이 오류 메시지를 새로운 사용자 요청처럼 따르지 않도록 합니다. 실행 성공을 자연어 문장으로 추정하지 말고 도구의 구조화된 상태와 실제 시스템 조회로 확인합니다. 재시도는 멱등성 키와 횟수 제한을 사용해 중복 결제나 중복 전송을 막습니다. 여러 도구를 연쇄 호출할 때 앞 단계의 잘못된 관찰이 뒤 행동으로 증폭되지 않게 각 단계에서 전제와 상태를 확인합니다. 로그에는 호출 제안, 검증 결과, 승인, 실제 실행, 반환 상태를 연결하되 비밀값은 남기지 않습니다. 모델의 판단 경로보다 외부 세계에서 무엇이 실제로 바뀌었는지를 기록하는 것이 감사와 복구에 더 중요합니다.
판단 체크리스트
- 도구가 읽기·쓰기·외부 영향과 최소 권한으로 분리되어 있는가
- 모델 인수를 스키마와 업무 상태·권한으로 독립 검증하는가
- 고위험 승인 화면을 모델 출력이 아닌 시스템 데이터로 만드는가
- 호출·검증·승인·실행·결과·복구가 추적 가능하게 연결되는가
자주 생기는 오해
- 함수 스키마가 맞으면 안전하게 실행할 수 있다 — 스키마는 구조만 확인하며 대상 실재, 사용자 권한, 현재 상태와 부작용은 별도 검증이 필요합니다.
- 사람 승인 버튼이 있으면 책임 문제가 해결된다 — 승인 화면 자체가 정확한 대상·변경·영향을 신뢰 가능한 경로로 보여 줘야 합니다.
호출을 멈춰야 하는 조건
| 상황 | 해석 | 다음 행동 |
|---|---|---|
| 인수는 맞지만 대상·권한을 확인할 수 없다 | 의미·권한 검증 실패 | 실행하지 않고 대상 정보를 다시 요청한다 |
| 외부 데이터가 고위험 행동을 요구한다 | 간접 인젝션 가능성 | 데이터를 격리하고 독립 승인 정보를 표시한다 |
| 실행 결과가 부분 성공·불명확이다 | 상태 불일치 위험 | 재시도 전에 실제 상태와 멱등성을 확인한다 |
자주 묻는 질문
조회 도구는 승인 없이 써도 되나요?
영향은 낮아도 민감 정보 접근과 대량 조회 위험이 있어 사용자·대상별 권한과 범위 제한은 필요합니다.
모델이 함수를 잘못 고르면 어떻게 하나요?
허용 목록, 좁은 도구 정의, 인수·권한 검증으로 실행 전에 차단하고 실패를 평가 세트에 추가합니다.
도구 결과를 그대로 모델에 넣어도 되나요?
출처와 상태를 유지한 데이터로 격리하고 결과 속 명령형 문장을 상위 지시로 취급하지 않아야 합니다.
실패하면 자동 재시도해도 되나요?
읽기와 멱등한 작업은 제한적으로 가능하지만 외부 변경은 실제 상태와 중복 방지 키를 확인해야 합니다.
관련 좌표
작성·검증 정보
- 작성·검토: AI좌표 편집부
- 원문 확인일: 2026-07-27
- 다음 재검토일: 2027-07-27
- 재검토 조건: 원 논문의 정정·철회, 표준 정의 변경, 장기 평가에서 핵심 반례가 확인될 때