도구와 권한, 컨텍스트 한계를 둔 AI 어시스턴트 설계법

시스템 프롬프트에 ‘메시지를 보내지 말라’고 적어도 어시스턴트에 발송 도구와 유효한 자격 증명이 있다면 경계는 닫히지 않는다. 업무용 AI의 경계는 금지 문장이 아니라, 어떤 사용자가 어떤 정보와 도구로 어느 자원에 작업할 수 있는지 정한 실행 가능한 서비스 계약이어야 한다. 조회, 요약, 초안, 수정과 발송을 하나의 권한으로 묶지 않고 기능마다 정보 범위, 실행 주체, 승인, 중지 조건과 책임자를 정해야 출시 전 통제와 변경 영향을 검사할 수 있다.

어시스턴트에 어떤 업무까지 허용해야 할까?

먼저 적격 사용자, 허용 업무, 승인된 정보, 허용 결과와 명시적 비목표를 한 문장으로 고정해야 한다. 실무 헌장은 “누구에게, 어시스턴트는 어떤 승인 정보로 어떤 업무군을 수행해 어떤 결과를 만들 수 있지만, 어떤 결정이나 결과는 만들 수 없다”는 구조면 충분하다. 그다음 ‘지원한다’나 ‘관리한다’처럼 범위가 넓은 동사를 검색, 요약, 제안, 초안, 수정, 발송, 삭제, 승인으로 분해한다. NIST AI RMF가 제시하는 목적, 배포 환경, 지원 업무, 지식 한계, 사람의 감독과 위험 허용 범위도 이 단계에서 기록한다. OWASP의 최소 도구 기능 원칙을 적용하면 개방형 도구를 연결하기 전에 정말 필요한 작업만 남길 수 있다. 이 기능 단위 방법은 두 기관의 의무 규격이 아니라 관련 통제 원칙을 실무에 맞게 종합한 편집 방법론이다.

• 대상: 누가 어떤 인증을 거쳐 사용할 수 있는지 적는다.
• 업무: 성공으로 인정할 구체적인 요청과 결과를 한 가지 작업 단위로 쓴다.
• 감독: 검토자, 위험 책임자, 접근 권한 책임자와 서비스 운영자를 구분한다.
• 비목표: 금지된 결정, 외부 약속, 파괴적 변경과 지원하지 않는 업무를 명시한다.
• 도구 연결 전 점검: 기능 이름이 ‘도와주기’나 ‘관리하기’처럼 여러 권한을 숨기고 있지 않은지 확인한다.

각 기능은 어떤 정보까지 사용할 수 있을까?

컨텍스트 한계는 모델의 토큰 예산이 아니라 기능마다 허용되는 정보 봉투다. 승인된 시스템과 레코드 종류, 정보 등급, 객체 필터, 날짜 범위, 최신성 기대치, 사용자에게 원래 부여된 열람 권한과 금지 데이터를 함께 적어야 한다. 검색된 문서, 외부 메시지, 첨부파일과 API 응답은 서비스 지시가 아니라 신뢰하지 않는 콘텐츠로 분리하고 검증한다. 세션 기록과 영구 메모리도 하나로 묶지 않는다. 각각 무엇을 저장할 수 있는지, 사용자와 세션 사이를 어떻게 격리할지, 저장 전 무엇을 검증할지, 언제 만료·삭제할지, 절대로 남기지 않을 정보가 무엇인지 정한다. 필요한 근거가 없거나 오래됐거나 접근할 수 없다면 답을 제한하거나 거절해야 한다. 더 큰 컨텍스트 창은 새로운 열람 권한을 만들지도, 근거 없는 내용을 사실로 바꾸지도 않는다.

• 출처 범위: 허용 시스템, 레코드 종류, 계정·조직·사례 필터와 정보 등급
• 시간 범위: 조회 기준일, 최신성 요구와 오래된 근거를 처리하는 방식
• 신뢰 범위: 내부 지시, 검증된 데이터와 외부·검색 콘텐츠를 구분하는 규칙
• 기억 범위: 세션 기록과 영구 메모리의 저장 자격, 격리, 검증, 만료와 삭제
• 거절 조건: 필수 근거가 없거나 접근 권한이 없고 최신성을 확인할 수 없는 상태

신원, 도구와 권한은 어떻게 경계를 강제해야 할까?

인증, 권한 부여와 승인은 별개의 결정으로 처리하고, 실제 자원과 작업 제한은 모델이 아니라 도구 게이트웨이와 하위 시스템이 강제해야 한다. 인증은 사용자·클라이언트·워크로드가 누구인지 확인하고, 권한 부여는 그 주체가 보호 자원에 어떤 작업을 할 수 있는지 판단하며, 승인은 제시된 특정 행동을 받아들일지 결정한다. 실행 주체도 사용자의 위임 권한인지 제한된 워크로드 신원인지 명시해야 하며, 권한이 큰 운영자 계정을 묵시적으로 물려주면 안 된다. 도구는 ‘메일함 사용’ 대신 ‘승인된 초안 발송’처럼 좁은 작업과 검증된 매개변수만 노출한다. 실행 경로에서는 동작, 자원, 객체, 필드, 대상, 자격 증명 유효기간과 토큰 대상을 제한한다. 보호되는 MCP 연동에서는 최소 권한 범위와 자원 대상 검증을 적용할 수 있지만, MCP 규격을 모든 도구 구조의 보편 요구사항으로 확대해서는 안 된다.

• 인증: 지금 요청하는 사용자, 클라이언트 또는 워크로드는 누구인가?
• 권한 부여: 그 주체가 이 보호 자원의 이 작업을 수행할 수 있는가?
• 승인: 현재 화면에 제시된 대상과 매개변수의 행동을 책임자가 수락했는가?
• 실행 제한: 도구와 하위 시스템이 같은 판단을 매 요청마다 다시 검증하는가?

대화는 하나로 이어져 보여도 권한은 작고 독립적으로 강제되는 기능들로 나뉘어야 한다.

한 기능에 어느 정도의 실행 권한을 줄 수 있을까?

모든 기능에는 외부 상태를 어디까지 바꿀 수 있는지 나타내는 명시적인 행동 상한이 필요하며, 결과가 커질수록 모델 밖의 독립 통제를 강화해야 한다. 답변과 요약, 제안, 초안, 되돌릴 수 있는 제한적 수정, 중대한 외부 행동, 금지된 결정은 같은 권한 단계가 아니다. 초안 작성과 발송, 되돌릴 수 있는 필드 수정과 파괴적 변경, 제안과 책임 있는 의사결정을 각각 분리한다. 외부 효과가 큰 행동은 실행 전에 대상과 내용을 확인 가능한 형태로 보여 주고, 행위자, 도구, 대상 자원, 정규화된 매개변수, 승인 시점과 만료에 승인을 결속한다. 승인 이후 수신자나 내용이 달라지면 다시 검증해야 한다. 승인은 누락된 권한을 보충하거나 상시 권한을 넓히지 않으며, 금지된 결정을 허용된 결정으로 바꾸지도 않는다.

1. 답변·요약: 허용된 정보에서 근거를 제시하며 외부 상태는 바꾸지 않는다.
2. 추천·제안: 다음 행동을 검사 가능한 제안으로 만들되 실행하지 않는다.
3. 초안: 비최종 작업 공간에 편집 가능한 결과를 만들고 검토자를 지정한다.
4. 제한적 가역 수정: 허용된 객체와 필드만 검증해 바꾸고 중복 방지나 복구 수단을 둔다.
5. 중대한 외부 행동: 유효한 권한, 행동 단위 승인, 독립 정책 검사와 사고 대응 경로를 요구한다.
6. 금지된 결정: 기능과 실행 권한 자체를 제공하지 않고 별도로 통제되는 적격 전문가나 책임자에게 보낸다.

어시스턴트가 경계에 닿으면 어떻게 동작해야 할까?

거절, 안전한 부분 지원, 사람에게 넘기기와 보안 에스컬레이션은 예외 문구가 아니라 정상적인 서비스 결과로 설계하고 실제 중지 조건을 둬야 한다. 이유는 업무 범위 밖, 사용할 수 없는 정보, 권한 부족, 승인 필요, 근거 누락·노후화, 전문 판단 필요, 도구 장애, 운영 한도 도달, 보안 신호 감지처럼 운영자가 구분할 수 있어야 한다. 어시스턴트는 민감한 정책 세부를 노출하지 않으면서 경계를 평이하게 설명하고, 실행하지 않은 조회·승인·수정을 성공했다고 말해서는 안 된다. 가능한 경우 초안, 확인표 또는 누락 정보 요청처럼 안전한 부분만 제공한다. 인계에는 원래 목표, 비민감 맥락, 시도한 기능, 이유, 확인된 근거와 누락된 근거, 다음 단계와 추적 식별자를 담는다. 일반 상담 인계, 업무 승인과 보안 사고는 목적지가 다르며, 담당자가 처리하는 동안 실행은 멈춰야 한다.

• 범위 밖 업무 또는 사용할 수 없는 정보
• 권한 부족 또는 별도 승인 필요
• 근거 누락·노후화 또는 적격 전문가 판단 필요
• 도구·의존 서비스 장애 또는 운영 한도 도달
• 승인 우회, 권한 상승, 데이터 유출, 메모리 오염이나 재귀적 도구 남용 신호

경계를 실제 운영 설계로 어떻게 바꿀 수 있을까?

사용자가 요청할 수 있는 작업마다 기능 설계 캔버스 한 행을 만들고 강제 가능한 통제, 증적, 시험, 운영 지표와 책임자에 연결한다. 적격 사용자와 인증, 정보 봉투, 메모리 규칙, 좁은 도구 작업, 실행 신원, 자원 범위, 행동 상한, 승인, 서비스별 운영 한도, 거절, 로그, 평가와 인계 목적지를 기록한다. 한도는 공통 수치가 아니라 실제 피해 가능성과 운영 용량에 맞춘다. 이 캔버스와 행동 단계는 NIST·OWASP·NCSC 원칙을 연결한 편집상 종합이며 특정 기관의 인증 양식이 아니다. 각 필드는 실행 정책, 관측 신호 또는 책임자의 결정권으로 이어져야 한다.

출시와 지속 운영에는 어떤 증거가 필요할까?

출시하려면 허용된 서비스와 예상된 거절이 실제 배포와 비슷한 조건에서 모두 작동한다는 증적이 필요하고, 출시 뒤에는 모니터링과 변경 영향 재평가가 이어져야 한다. 정상 요청만 시험하지 말고 교차 계정 접근, 허가되지 않은 도구, 오래됐거나 오염된 검색 콘텐츠, 금지 데이터, 승인 우회, 승인 뒤 매개변수 변경, 중복 재시도, 의존 서비스 장애, 데이터 유출 시도와 멈추지 않는 행동 연쇄를 포함한다. 로그는 누가 무엇을 요청했고 어떤 기능·정책·출처·도구 범주가 적용됐으며 어떤 권한·승인 판단과 결과가 발생했는지 버전과 함께 재구성할 수 있어야 한다. 다만 비밀정보와 무제한 원문 컨텍스트는 남기지 않는다. 서비스 행동, 접근 권한, 업무 인계와 보안 사고의 책임자에게 기능을 중지·수정·폐기할 권한도 부여한다.

• 성공 시험과 거절 시험을 같은 출시 증적에 포함한다.
• 예상 밖 도구 사용, 반복 거절, 권한 실패, 승인 변경, 비정상 행동 순서, 지연과 자원 사용을 기능별로 관찰한다.
• 로그에 비밀정보를 넣지 않고 상세 내용의 접근·보존은 개인정보와 기록관리 요구사항에 맞춘다.
• 모델, 프롬프트, 검색, 메모리, 도구, 권한, 정책, 데이터, 공급자나 운영 환경이 바뀌면 영향받는 시험을 다시 연다.
• 알려진 한계와 실패 방식을 운영자와 사용자에게 전달하고 책임자가 변경 권한의 확대 여부를 검토한다.

첫 출시는 작지만 쓸모 있는 기능으로 시작한다. 허용 요청의 성공과 금지 요청의 관측 가능한 거절을 확인한 뒤, 검토된 변경 절차로 권한을 넓힌다. 민감정보, 영구 메모리, 특권 접근, 외부 약속, 파괴적 변경이나 사고 대응은 보안, 신원, 개인정보, 기록관리, 위험과 서비스 책임자가 함께 검토한다. 결제, 접근 권한 부여, 운영 배포와 고위험 전문 판단은 결정론적 정책과 적격한 사람의 책임 아래 두고, 법률·규제 판단은 별도 통제 절차로 보낸다.