Field note
AI 에이전트 권한과 가치 검증: 내가 쓰는 운영 점검 틀
에이전트형 AI의 실행 권한을 네 수준으로 나누고, 승인·감사·롤백과 실제 가치 측정에 필요한 질문을 정리한다.
이 글의 목차
AI 시스템은 답변 생성에 머물지 않고 검색, 파일 읽기, 코드 실행과 외부 시스템 호출까지 수행할 수 있다. 이때 중요한 질문은 “모델이 얼마나 똑똑한가?”보다 “무슨 행동을 허용하고, 누가 승인하며, 실패하면 어떻게 복구할 것인가?”에 가깝다.
이 글의 네 단계 권한 분류와 가치 점검 질문은 공인된 성숙도 모델이 아니다. 에이전트 기능을 설계하거나 검토할 때 내가 사용하는 실무용 분류다. 조직의 규제 환경과 실패 비용에 따라 단계와 통제는 달라져야 한다.
도구를 연결하면 위험의 단위가 달라진다
OpenAI의 도구 사용 문서는 모델 응답에 웹 검색, 파일 검색, 함수 호출과 원격 MCP 서버를 연결하는 방법을 설명한다. 애플리케이션은 모델이 선택할 수 있는 도구와 호출 조건을 제한할 수 있다.
읽기 전용 검색 도구와 결제·배포·메시지 전송 도구는 같은 방식으로 다룰 수 없다. 모델 성능이 같아도 접근 가능한 데이터와 행동의 영향 범위가 달라지기 때문이다.
권한을 네 수준으로 나누기
아래 표는 기능을 처음 분류하기 위한 출발점이다.
| 수준 | 가능한 행동 | 기본 통제 | 경계 사례 |
|---|---|---|---|
| 1. 제안 | 초안, 요약, 선택지 생성 | 출처 표시, 사람의 검토 | 사용자가 그대로 외부에 전송하면 실제 영향은 4수준에 가까워질 수 있다. |
| 2. 조회 | 문서·DB·웹 검색 | 최소 권한, 민감정보 필터, 조회 로그 | 의료·인사 데이터 조회는 읽기 전용이어도 높은 위험을 가진다. |
| 3. 내부 변경 | 코드·파일·업무 데이터 수정 | 변경 범위 제한, diff, 승인, 롤백 | 운영 브랜치 수정이나 권한 변경은 외부 실행과 같은 통제가 필요할 수 있다. |
| 4. 외부 실행 | 배포·결제·메시지 전송 | 실행 직전 승인, 금액·대상 제한, 취소 수단, 감사 로그 | 소액·반복 작업도 누적 영향과 오발송 위험을 계산해야 한다. |
단계 번호만으로 자동 실행 여부를 정하면 안 된다. 같은 조회라도 공개 문서 검색과 환자 기록 조회는 실패 비용이 다르다. 최소한 다음 조건을 별도로 기록해야 한다.
- 영향을 받는 사람과 데이터
- 한 번의 실행으로 바뀔 수 있는 범위
- 승인자와 승인 유효시간
- 중복 실행을 막는 방법
- 취소·롤백 가능 시간
- 사람이 개입해야 하는 예외 조건
감사 가능성은 결과를 재구성하는 능력이다
에이전트 로그는 디버깅 기록만을 뜻하지 않는다. 사고나 분쟁이 생겼을 때 누가 무엇을 요청했고, 어떤 데이터와 도구가 사용됐으며, 누가 실행을 승인했는지 재구성할 수 있어야 한다.
최소 기록 항목은 다음과 같다.
- 요청자, 실행 시각과 요청 식별자
- 모델·프롬프트·도구 버전
- 부여된 권한과 실제 호출한 도구
- 외부 데이터의 출처와 버전
- 제안, 승인, 실행과 검증 결과의 구분
- 실패, 취소와 롤백 기록
모든 원문 데이터를 무기한 저장하자는 뜻은 아니다. 개인정보와 보존 기간 요구사항을 반영해 필요한 증거와 민감정보 최소화를 함께 설계해야 한다.
가치 검증을 위한 세 질문
아래 세 질문도 순차적인 산업 표준이 아니라, 데모 성능과 실제 운영 성과를 혼동하지 않기 위한 점검 틀이다.
| 질문 | 확인할 지표 | 자주 생기는 오해 |
|---|---|---|
| 기능이 필요한 수준으로 작동하는가? | 작업 성공률, 오류 유형, 도구 호출 성공률 | 벤치마크 점수가 실제 업무 성공률과 같다고 본다. |
| 조직 안에서 안전하게 운영할 수 있는가? | 통합 비용, 승인 대기시간, 사고·롤백률 | 연결에 성공하면 도입이 끝났다고 본다. |
| 비용과 위험을 포함해 결과가 나아지는가? | 절감 시간, 재작업률, 단위 비용, 사용자 채택 | 생성량이나 사용 횟수를 곧바로 가치로 해석한다. |
예를 들어 문서 초안 에이전트가 한 달에 1만 건을 생성해도 수정 시간이 줄지 않거나 오류 검토 비용이 늘었다면 생성량만으로 성과를 주장할 수 없다. 반대로 생성량이 작더라도 사고 가능성이 높은 절차에서 누락을 줄였다면 별도의 가치가 있을 수 있다.
측정 기간과 비교 기준도 먼저 정해야 한다. 도입 전 평균 처리시간, 동일 업무를 수행한 비교 집단 또는 이전 버전이 없다면 “몇 퍼센트 개선됐다”는 설명은 설득력을 갖기 어렵다.
이 점검 틀의 한계
이 글은 법률·의료·금융 분야의 규제 준수 체크리스트가 아니다. 권한 수준은 기술적 기능만으로 결정되지 않으며, 조직의 책임 구조와 데이터 민감도에 따라 달라진다.
OpenAI 문서는 특정 제품의 도구 연결 방식을 설명하는 자료다. 일반적인 위험관리 원칙을 위해서는 조직 전반의 AI 위험을 다루는 NIST AI RMF 1.0, 생성형 AI 위험을 확장한 NIST AI 600-1, 에이전트 위협과 완화책을 정리한 OWASP Agentic AI 자료를 함께 참고할 수 있다.
결론
에이전트 기능을 검토할 때 내가 남기려는 질문은 다음 세 가지다.
- 어떤 데이터와 행동을 왜 허용했는가?
- 승인과 실행 결과를 사후에 재구성하고 되돌릴 수 있는가?
- 생성량이 아니라 비용·오류·시간을 포함한 실제 결과가 나아졌는가?
이 질문에 답하지 못한 자동화는 모델 성능과 별개로 운영 준비가 끝났다고 보기 어렵다.