AI에게 일을 맡길 때, 권한과 판단은 다른 문제다

며칠 전부터 블로그 운영을 반쯤 자동화하는 파이프라인을 Claude Code로 짜기 시작했다. 후보 수집, 채점, 이미지 기획까지 여러 단계를 스크립트로 엮었는데, 그중 일부는 다른 AI 도구를 백그라운드로 띄워 병렬로 돌렸다. 이때 codex 같은 CLI 도구에 승인 절차를 건너뛰는 옵션을 줬다. 매번 "이 파일 써도 될까요"를 확인받으면 백그라운드 작업 자체가 의미가 없어지기 때문이다. 그런데 이 옵션을 켜는 순간 드는 생각이 있었다. 내가 지금 열어준 게 정확히 뭘까. 권한을 열어준 것과, 판단까지 맡긴 것은 같은 걸까.

권한을 여는 건 편한 만큼 위험하다

Claude Code에는 --dangerously-skip-permissions라는 옵션이 있다. 켜면 파일 쓰기, 명령 실행, 네트워크 호출까지 매 단계 승인 없이 전부 통과된다. 이름부터 "위험하게"라는 경고가 박혀 있는 데는 이유가 있다. 2025년 12월, 한 사용자가 저장소 패키지를 정리해달라고 요청했는데 AI가 rm -rf tests/ patches/ plan/ ~/라는 명령을 생성했고, 맨 끝의 ~/가 홈 디렉터리 전체로 확장되면서 바탕화면 파일, 키체인 비밀번호, 앱 데이터까지 통째로 삭제된 사고가 있었다(관련 가이드). 승인 절차 하나가 빠졌을 뿐인데 돌이킬 수 없는 손실로 이어진 사례다.

그렇다고 매번 승인 창을 붙잡고 있는 것도 답은 아니다. Anthropic이 최근 공개한 자료에 따르면, 사용자들은 승인 요청의 93퍼센트를 그냥 수락하고 있었다(Anthropic 공식 글). 열에 아홉은 어차피 승인할 걸 매번 멈춰 서서 확인하느라 "승인 피로"만 쌓인 셈이다. 그래서 Anthropic은 수동 승인과 완전 개방 사이에 auto mode라는 중간 지점을 만들었다. 모델 기반 분류기가 사용자 메시지와 도구 호출만 보고 위험한 작업(범위가 갑자기 커지는 명령, 지정 안 된 자격증명 탐색, 외부로의 민감정보 전송 같은 패턴)을 걸러낸다. 실제 트래픽에서 오탐률 0.4퍼센트, 위험 행동을 놓치는 비율 17퍼센트라는 수치를 공개하면서, "완벽하진 않지만 완전 개방보다는 훨씬 낫다"고 인정한다.

그런데 권한을 안전하게 열어도, 판단은 또 다른 문제였다

권한 문제를 잘 풀어도 그다음 벽이 남는다. 오늘 이 파이프라인으로 다른 글을 쓰던 중에 실제로 겪었다. 예전에 써둔 글을 언급하며 내부 링크를 하나 붙였는데, AI가 그럴듯한 블로그 URL을 만들어 붙여줬다. 형식은 멀쩡했다. 그런데 다시 훑어보다 확인해보니, 그 링크는 전혀 다른 글, 그것도 아직 발행조차 안 된 글의 URL이었다. 자가발전 루프를 다룬 글을 언급하려던 건데, 링크는 취리히 여행기 URL을 그대로 가져다 붙인 것이었다. 이건 권한의 문제가 아니었다. 파일을 쓰고 링크를 넣는 행위 자체는 이미 허락된 범위 안에 있었다. 문제는 그 판단, 즉 "이 URL이 맞는 자리를 가리키는가"를 AI 스스로 검증하지 못했다는 점이었다. 권한은 열려 있었고 아무 사고도 감지되지 않았지만, 결과는 틀렸다.

이 둘을 같은 문제로 뭉뚱그리면 안 된다는 걸 그 순간 알았다. 권한은 "무엇을 할 수 있는가"를 정하는 축이고, 판단은 "무엇을 할지 누가 정하는가"를 정하는 축이다. rm -rf 사고는 권한이 너무 넓게 열려 있어서 생겼다. 내 링크 오류는 권한과 무관하게, 판단을 완전히 AI에게 맡겨서 생겼다. 권한을 아무리 촘촘하게 관리해도 판단을 다 맡기면 이런 종류의 실수는 막을 수 없다.

AI가 왜 판단에서 자주 틀리는지는 다른 글에서도 봤다

최근 읽은 해외 개발자 글 하나가 이 지점을 정확히 짚고 있었다(원문). Claude, GPT, Deepseek 같은 모델을 여러 개 구독해서 코드 리뷰부터 보드게임 웹앱 개발까지 실제로 굴려본 개발자의 글인데, 결론이 명확했다. 코드 리뷰나 리팩토링, 일회성 스크립트처럼 검증하기 쉬운 일에서는 가장 큰 가치를 얻었지만, 결정을 많이 요구하는 복잡한 작업에서는 거의 쓸모가 없었다고 썼다. AI 에이전트 성능을 추적하는 벤치마크 연구도 비슷한 그림을 그린다. 과제 하나를 끝내는 데 걸리는 시간과 성공률 사이의 상관관계가 0.83에 달할 만큼, 작업이 길고 복잡해질수록 성공률은 가파르게 떨어진다(METR 연구). 판단 단계가 늘어날수록 어디선가는 꼭 어긋난다는 뜻이다. 채점 기준이 코드 밖, 그러니까 내 상황과 맥락 안에만 있는 일일수록 이 격차가 크다.

goal과 loop로 자율성을 주더라도, 범위는 좁혀야 한다

그렇다고 판단을 아예 안 맡길 수도 없다. 매번 사람이 붙어 있어야 하면 자동화라는 말 자체가 무색해진다. 여기서 진짜 안전한 중간 지점은 "권한은 넓게, 판단은 좁게" 주는 쪽이었다. /loop나 /schedule 같은 반복 실행 기능과 승인 생략을 같이 켜면, AI가 감시하고 판단하고 고치는 일을 사람 개입 없이 계속 돌리는 완전 자율 에이전트가 된다. 이건 도커 컨테이너나 격리된 가상머신처럼 실패해도 피해가 그 안에서 끝나는 환경에서만 쓰라고 안내되어 있다. 반대로 목표(goal)를 좁게 정의해서 "이 파일들만, 이 조건까지만, 이 결과가 나오면 멈춰라"처럼 범위를 명시하고 반복 주기마다 결과를 다시 확인하게 만들면, 판단의 폭 자체가 줄어들어서 틀릴 여지도 함께 줄어든다. 오늘 내가 codex를 백그라운드로 돌릴 때도 실제로는 이 원칙을 썼다. 권한은 넓게 열어줬지만, 시킨 일은 정해진 브리핑 하나를 정해진 형식으로 써서 파일 하나에 저장하는 것뿐이었고, 나온 결과는 내가 다시 읽고 골라 썼다. 넓은 권한과 좁은 목표를 같이 주는 것과, 넓은 권한과 넓은 판단을 같이 주는 것은 겉보기엔 비슷해도 완전히 다른 선택이다.

결국 두 축을 따로 설계해야 했다

돌이켜보면 오늘 자동화를 짜면서 내가 실제로 한 일은 코드를 짠 게 아니라 이 두 축을 따로 설계한 것에 가까웠다. 권한 축에서는 어디까지 승인 없이 돌게 둘지, 판단 축에서는 어디서 멈춰 사람에게 물어볼지. 둘을 하나로 뭉쳐서 "AI를 얼마나 믿을 것인가"로만 생각하면 rm -rf 같은 사고와 잘못된 링크 같은 실수를 같은 잣대로 다루게 되고, 그러면 둘 다 제대로 못 막는다. 권한은 안전장치와 격리된 환경으로 관리하고, 판단은 검증 가능한 일과 판단이 필요한 일을 나눠 후자에는 사람이 확인하는 지점을 박아두는 것. 다음에 또 뭔가를 자동화한다면, 나는 이 일에 얼마만큼 권한을 줄지와 얼마만큼 판단을 맡길지를 각각 따로 정하는 데서 시작할 것 같다.