AI 에이전트 권한 설계: computer use를 운영에 넣기 전 막아야 할 7가지

AI 에이전트에 computer use 기능을 붙이면 데모는 빨라집니다. 브라우저를 열고, 버튼을 누르고, 관리자 화면에서 값을 바꾸는 장면은 설득력이 큽니다. 하지만 운영 환경에서는 이 기능이 가장 위험한 자동화가 될 수 있습니다. API 호출은 파라미터와 권한을 비교적 명확히 제한할 수 있지만, 화면 조작은 사람이 보는 것과 비슷한 방식으로 시스템을 건드립니다. 그만큼 권한 경계가 흐려집니다.

OpenAI Agents API가 computer use를 지원하고, Codex가 클라우드 환경과 코드 리뷰 흐름으로 확장되면서 개발팀은 새로운 질문을 마주하게 됐습니다. “어떤 일을 자동화할 수 있는가”보다 “어떤 일을 자동화하면 안 되는가”가 먼저입니다. 이 글은 실제 서비스에 computer-use 에이전트를 넣기 전에 정해야 할 권한 설계 기준을 정리합니다.

문제: 에이전트는 사람처럼 보이지만 책임은 코드가 져야 한다

사람이 관리자 화면에서 버튼을 잘못 누르면 누가 했는지 로그가 남습니다. 실수한 사람이 맥락을 설명할 수도 있습니다. 반면 에이전트는 클릭과 입력을 실행하지만, 책임 소재는 시스템을 만든 팀에게 돌아갑니다. “모델이 그렇게 판단했다”는 운영 설명이 될 수 없습니다.

특히 computer use는 API보다 재현이 어렵습니다. 같은 프롬프트라도 화면 상태, 로그인 세션, 팝업, 로딩 지연, A/B UI에 따라 결과가 달라질 수 있습니다. 따라서 권한 설계는 프롬프트보다 강해야 합니다. 프롬프트에 “삭제하지 마”라고 쓰는 것은 안전장치가 아닙니다. 삭제 버튼 자체에 접근하지 못하게 하거나, 접근하더라도 승인 없이 클릭하지 못하게 해야 합니다.

원칙 1: allowlist부터 만들기

첫 번째 원칙은 허용 목록입니다. 에이전트가 접근할 수 있는 도메인, URL 패턴, 화면, 액션을 명시해야 합니다. “사내 도구 전체” 같은 넓은 권한은 금물입니다. 예를 들어 고객지원 에이전트라면 /admin/tickets, /admin/users/read-only, /admin/refunds/request처럼 범위를 나눠야 합니다.

반대로 denylist만 두는 방식은 약합니다. 새 메뉴가 생기거나 URL이 바뀌면 금지 목록을 우회할 수 있습니다. 운영에서는 기본 차단, 필요한 것만 허용이 맞습니다. 이 원칙은 클라우드 실행 환경에서도 동일합니다. Codex 같은 개발 에이전트가 접근할 수 있는 저장소, 브랜치, secret, 배포 명령을 allowlist로 관리해야 합니다.

원칙 2: 읽기와 쓰기를 분리하기

두 번째 원칙은 읽기와 쓰기의 분리입니다. 대부분의 에이전트 PoC는 처음부터 변경 작업을 시키려 합니다. 하지만 안전한 순서는 읽기 전용, 제안형, 승인형, 자동 실행형입니다.

읽기 전용 단계에서는 에이전트가 화면을 탐색하고 요약만 합니다. 제안형 단계에서는 변경 계획을 만들지만 적용하지 않습니다. 승인형 단계에서는 사람이 승인한 작업만 실행합니다. 자동 실행형은 실패 비용이 낮고 롤백이 쉬운 작업에만 허용합니다. 예를 들어 “티켓에 내부 메모 추가”는 자동화 후보가 될 수 있지만, “환불 실행”은 승인형에 남겨야 합니다.

원칙 3: 위험 액션은 별도 도구로 감싸기

삭제, 결제, 배포, 권한 변경, 외부 발송은 화면 클릭으로 처리하지 않는 편이 좋습니다. 이런 액션은 별도 API 또는 내부 도구로 감싸고, tool schema 안에 승인 절차를 넣어야 합니다. 에이전트가 화면에서 버튼을 찾게 하는 대신 request_refund_approval, prepare_deploy_plan, draft_user_email처럼 중간 단계를 만들면 통제가 쉬워집니다.

이 방식의 장점은 로그와 정책을 코드로 유지할 수 있다는 점입니다. 누가 요청했는지, 어떤 입력이 들어갔는지, 승인자가 누구였는지, 실제 실행은 언제 됐는지 남길 수 있습니다. 화면 클릭만 기록하면 비즈니스 의미를 나중에 해석해야 하지만, 도구 호출은 처음부터 의미가 구조화됩니다.

원칙 4: 감사 로그는 스크린샷까지 포함하기

computer-use 에이전트의 로그는 일반 API 로그보다 더 풍부해야 합니다. 최소한 작업 ID, 사용자 요청, 모델 입력, 모델 출력, 방문 URL, 클릭/입력 이벤트, 전후 스크린샷, 최종 결과, 승인 여부를 남겨야 합니다. 가능하면 DOM snapshot이나 접근성 트리도 함께 저장하는 것이 좋습니다.

로그를 남기는 이유는 장애 대응만이 아닙니다. 에이전트 품질 개선에도 필요합니다. 어떤 화면에서 자주 실패하는지, 어떤 승인 단계에서 사람이 자주 거부하는지, 어떤 작업은 자동화해도 안전한지 판단하려면 실행 데이터가 있어야 합니다. 로그가 없으면 매번 감으로 프롬프트를 고치게 됩니다.

원칙 5: 세션과 자격 증명을 짧게 유지하기

에이전트 실행 세션은 짧아야 합니다. 장시간 유지되는 로그인 세션과 넓은 권한의 API 키는 위험합니다. 가능하면 작업마다 임시 토큰을 발급하고, scope와 만료 시간을 제한해야 합니다. 브라우저 세션도 작업 종료 후 폐기하는 것이 기본입니다.

개발 에이전트도 마찬가지입니다. 저장소 전체 write 권한, 프로덕션 secret 접근, 배포 권한을 한 번에 주면 안 됩니다. 코드 수정은 feature branch로 제한하고, secret은 읽지 못하게 하며, 배포는 별도 승인 파이프라인을 통과하게 해야 합니다.

원칙 6: 실패 모드를 먼저 정하기

에이전트가 모르면 멈춰야 합니다. 화면이 예상과 다르거나, 버튼 이름이 바뀌었거나, 확신도가 낮거나, 외부 발송이 필요한 경우에는 재시도보다 중단이 안전합니다. “어떻게든 완료”가 목표가 되면 위험합니다.

실패 모드는 세 가지로 나누면 운영하기 쉽습니다. 첫째, 사용자에게 추가 정보를 요청합니다. 둘째, 사람 검토 큐로 넘깁니다. 셋째, 자동으로 롤백하거나 아무 변경 없이 종료합니다. 이 기준을 정하지 않으면 에이전트가 애매한 상황에서 임의로 판단합니다.

원칙 7: 작은 업무부터 제품화하기

가장 좋은 시작점은 반복적이고, 실패 비용이 낮고, 결과 검증이 쉬운 업무입니다. 예를 들어 티켓 분류, 리포트 초안 작성, 내부 메모 추가, PR 요약, 테스트 실패 원인 정리 같은 작업입니다. 반대로 환불, 계정 정지, 데이터 삭제, 대량 발송, 운영 배포는 늦게 가져가야 합니다.

도입 기준은 간단합니다. 사람이 같은 업무를 하루 10번 이상 반복하는가. 작업 입력과 결과가 명확한가. 실수해도 복구 가능한가. 로그만 보고 결과를 검증할 수 있는가. 이 네 가지에 모두 예라고 답할 수 있으면 첫 후보가 됩니다.

실행 체크리스트

• 에이전트가 접근 가능한 URL과 금지 URL을 allowlist 방식으로 정의합니다.
• 읽기 전용, 제안형, 승인형, 자동 실행형 권한 단계를 분리합니다.
• 삭제, 결제, 배포, 권한 변경, 외부 발송은 항상 별도 승인 도구로 감쌉니다.
• 클릭 이벤트뿐 아니라 전후 스크린샷, DOM 상태, 모델 판단을 함께 저장합니다.
• 작업마다 짧은 수명의 토큰과 제한된 scope를 사용합니다.
• 화면이 예상과 다르면 재시도보다 중단하도록 실패 모드를 설계합니다.
• 운영 투입 전 50회 이상 staging 실행 로그를 보고 자동화 가능 범위를 좁힙니다.

computer use는 강력합니다. 하지만 강력한 기능일수록 프롬프트가 아니라 시스템 설계로 제어해야 합니다. 좋은 에이전트 운영은 모델 성능 경쟁이 아니라 권한, 로그, 승인, 롤백을 얼마나 촘촘하게 만들었는지에서 결정됩니다.