에이전트 운영 설계 노트 (6/9) — 권한 설계: allow / ask / deny

-

에이전트가 실제로 파일을 읽고, 수정하고, 명령을 실행하고, 외부로 무언가를 보낼 수 있게 되는 순간부터 품질 문제와 안전 문제는 분리되지 않는다. 많은 팀이 권한 설계를 "막을 것인가, 열어둘 것인가"의 문제로 보지만, 실전에서는 더 중요한 질문이 있다. 무엇을 기본 허용하고, 무엇은 사람에게 물어보게 하고, 무엇은 구조적으로 금지할 것인가.

핵심 요약

  • 좋은 권한 설계의 핵심은 allow / ask / deny 세 칸을 만드는 것 자체가 아니라, 어떤 행동이 어느 칸으로 들어가야 하는지 일관되게 자르는 기준을 세우는 데 있다.
  • 같은 "도구 사용"이라도 읽기, 수정, 실행, 외부 전송, 발행은 위험도가 다르다. 이들을 한 버킷으로 묶으면 권한 모델이 빠르게 흐려진다.
  • Anthropic의 Claude Code 권한 문서는 ask, deny, allow, canUseTool, hooks 같은 여러 층을 결합해 설명하고, OpenAI Agents SDK는 input/output/tool guardrails와 sandbox를 따로 둔다. 공통점은 권한을 문구가 아니라 구조로 다룬다는 점이다.
  • 권한 모델은 보안만의 문제가 아니다. 잘못 자르면 에이전트가 자꾸 멈추고, 너무 느슨하면 실패 반경이 커진다. 결국 권한 설계는 품질 설계이기도 하다.

1. 권한 설계는 왜 에이전트 품질 문제이기도 한가

권한 이야기는 흔히 안전이나 보안 문맥에서만 다뤄진다. 물론 맞는 말이다. 하지만 실제 운영에서는 권한 설계가 곧 품질 문제이기도 하다.

이유는 단순하다.

  • 너무 넓게 허용하면 잘못된 행동 한 번의 반경이 커진다.
  • 너무 자주 묻게 만들면 작업 흐름이 끊기고 사람이 병목이 된다.
  • 너무 많이 금지하면 에이전트는 할 수 있는 일보다 우회할 일을 더 많이 찾게 된다.

즉 권한 설계는 "얼마나 안전한가"만이 아니라 얼마나 안정적으로 끝까지 일하게 만드는가의 문제다.

OpenAI가 2026-04-15 발표에서 sandbox execution과 harness를 함께 묶고, Anthropic이 권한 규칙과 hooks, canUseTool 콜백을 같은 권한 표면 안에서 설명하는 이유도 여기 있다. 실제 운영에서는 도구 노출, 승인 흐름, 실행 경계가 한 구조로 맞물리기 때문이다.

2. 기본 프레임: allow / ask / deny는 세 칸이 아니라 세 종류의 책임이다

많은 팀이 권한 설정을 이렇게 본다.

  • allow: 그냥 허용
  • ask: 사람에게 물어봄
  • deny: 금지

하지만 실전에서는 이 셋이 단순 버튼이 아니다. 각각이 다른 운영 책임을 뜻한다.

구간 뜻 운영 책임
allow 자동으로 지나가도 되는 행동 사후 검증과 로그로 충분한가
ask 사람이 중간에서 판단해야 하는 행동 누구에게, 어떤 정보와 함께, 얼마나 자주 물을 것인가
deny 구조적으로 금지해야 하는 행동 예외를 둘 것인가, 정책 위반 기록을 남길 것인가

핵심은 이것이다.

ask는 "위험하다"의 동의어가 아니라, 현재의 자동 판단 모델만으로는 조직이 책임지기 어려운 행동이라는 뜻이다.

이 기준이 없으면 ask가 남발된다. 그리고 ask가 남발되면 사람은 곧 모든 팝업을 같은 눈으로 넘기기 시작한다.

3. 첫 번째 기준: 읽기, 수정, 실행, 전송, 발행을 한 버킷에 넣지 말 것

권한 설계가 빠르게 망가지는 가장 흔한 이유는 표면상 비슷해 보이는 행동을 한 버킷으로 묶기 때문이다.

예를 들어 아래는 모두 "도구 사용"처럼 보일 수 있다.

행동 겉보기 실제 위험
로컬 문서 읽기 단순 조회 비교적 낮음
초안 파일 수정 쓰기 중간
셸에서 테스트 실행 실행 환경에 따라 중간~높음
외부 API 호출 네트워크 데이터 유출 가능성
블로그 발행 콘텐츠 전송 되돌리기 어려움
자격 증명 파일 접근 읽기 매우 높음

겉모습만 보면 read / write / execute 정도로 나뉘는 것 같지만, 실제 운영에서는 그보다 더 세밀해야 한다.

실무적으로는 최소한 아래 정도는 분리하는 편이 좋다.

  1. 읽기
  2. 로컬 수정
  3. 코드/명령 실행
  4. 외부 전송
  5. 발행/배포
  6. 자격 증명/보호 자산 접근

이 구분이 없으면 allow가 지나치게 넓어지고, ask는 점점 애매해지고, deny는 너무 늦게 붙는다.

4. 두 번째 기준: ask는 "고위험"이 아니라 "사람 판단이 필요한 경계"에만 붙일 것

많은 권한 모델이 ask를 사실상의 기본값처럼 쓰면서 스스로 무너진다. 위험해 보이면 일단 묻게 만들고, 나중에 사람이 누적된 팝업을 처리하는 구조다.

하지만 ask는 공짜가 아니다.

  • 사람 응답 대기가 생긴다.
  • 컨텍스트가 끊긴다.
  • 승인 기준이 사람마다 흔들릴 수 있다.
  • 자주 묻게 만들수록 진짜 중요한 ask의 신호가 희석된다.

그래서 ask는 아래와 같이 경계가 불명확한 행동에만 붙이는 편이 좋다.

  • 외부로 나가는 메시지나 게시
  • 원복이 어려운 쓰기
  • 비용이 큰 명령 실행
  • 데이터 범위를 넓히는 접근
  • 권한 상승이 필요한 단계

반대로 읽기 전용 문서 조사나 작업 디렉터리 안의 제한된 초안 수정처럼, 실패 반경이 작고 사후 검증이 쉬운 행동까지 ask로 묶으면 시스템은 지나치게 느려진다.

5. 세 번째 기준: deny는 "절대 금지"보다 "왜 금지하는지 설명 가능한 금지"여야 한다

deny는 가장 단순해 보이지만, 운영적으로는 가장 강한 정책이다. 그래서 무엇을 금지할지보다 왜 그 행동이 금지되는지 설명 가능한가가 중요하다.

예를 들어 아래는 deny로 두기 쉬운 항목이다.

  • 자격 증명 파일 직접 접근
  • 승인 없는 외부 발행
  • 허용 범위 밖 파일 수정
  • 승인 없는 네트워크 전송
  • 보호된 브랜치나 운영 스크립트 직접 변경

그런데 deny가 설명되지 않으면 에이전트도 사람도 우회 경로를 찾기 시작한다. "왜 막혔는지"가 안 보이면 정책은 곧 마찰처럼만 느껴진다.

좋은 deny는 보통 아래 조건을 가진다.

  • 범위가 명확하다
  • 우회 허용 경로가 있다면 별도로 정의돼 있다
  • 정책 위반 로그가 남는다
  • 사람이 예외를 여는 조건이 문서화돼 있다

즉 deny는 벽이라기보다 조직의 비가역 경계에 가깝다.

6. Claude Code와 OpenAI Agents SDK가 보여주는 공통점

Anthropic과 OpenAI는 구현 디테일은 다르지만 공통된 방향을 보여 준다.

Anthropic의 Claude Code 권한 문서는 권한 처리 순서를 PreToolUse hook -> ask rules -> deny rules -> permission mode -> allow rules -> canUseTool -> PostToolUse hook처럼 설명한다. 이건 권한이 한 줄 설정이 아니라, 여러 단계의 정책 표면이라는 뜻이다.

OpenAI Agents SDK 문서는 agent-level input/output guardrails만으로는 부족하고, manager나 handoff, delegated specialist가 있는 워크플로우라면 tool guardrails를 별도로 써야 한다고 설명한다. 즉 워크플로우가 복잡해질수록 권한과 검증은 도구 호출 지점까지 내려가야 한다는 뜻이다.

이 둘을 함께 보면 공통 메시지는 분명하다.

  • 권한은 모델 바깥의 구조다.
  • 권한은 도구와 분리되지 않는다.
  • 권한은 워크플로우 복잡도에 따라 더 세분화된다.

7. 권한 모델을 자를 때 가장 실용적인 질문 5개

allow / ask / deny를 어디에 놓을지 고민할 때는 추상 원칙보다 아래 질문이 더 실용적이다.

  1. 이 행동은 실패해도 사후 복구가 쉬운가
  2. 이 행동은 외부 세계에 흔적을 남기는가
  3. 이 행동은 보호 자산이나 넓은 범위에 닿는가
  4. 이 행동은 사람이 승인할 때 실제로 더 나은 판단을 할 수 있는가
  5. 이 행동은 로그만으로 충분한가, 아니면 사전 차단이 필요한가

이 질문에 대한 답으로 간단히 나누면 보통 이런 구조가 된다.

질문 결과 기본 권장
실패 반경이 작고 복구 쉬움 allow
사람 판단 가치가 큼 ask
비가역적이거나 보호 자산 접근 deny 또는 강한 ask

물론 이 표가 그대로 모든 조직에 맞지는 않는다. 하지만 최소한 ask를 습관처럼 남발하는 실수는 줄여 준다.

8. 흔한 실패 패턴 세 가지

8.1 모든 쓰기를 ask로 묶는다

처음엔 안전해 보이지만, 곧 사람 병목이 된다. 초안 수정처럼 복구 쉬운 쓰기까지 모두 ask로 가면 승인의 품질이 떨어진다.

8.2 외부 전송과 로컬 실행을 같은 위험도로 본다

둘 다 "실행"처럼 보여도 되돌리기 난이도가 다르다. 외부 전송은 흔적이 남고 회수가 어렵다.

8.3 deny를 너무 늦게 붙인다

처음엔 다 allow/ask로 열어두고 운영 중 사고가 난 뒤 deny를 붙이는 경우가 많다. 하지만 자격 증명 접근이나 무승인 발행 같은 것은 처음부터 deny 또는 강한 ask로 두는 편이 낫다.

9. 실무 체크리스트: 우리 권한 모델이 흐려지고 있는가

아래 다섯 가지 중 두세 개 이상에 해당하면 권한 모델을 다시 자를 시점일 가능성이 크다.

  • ask 팝업이 너무 많아 사람이 거의 자동으로 승인한다
  • 같은 종류의 행동이 상황마다 다르게 처리된다
  • 외부 전송과 로컬 수정이 같은 규칙으로 묶여 있다
  • 정책 위반이 났는데 왜 막지 못했는지 설명하기 어렵다
  • 에이전트가 일을 못 하는 이유가 모델보다 권한 모호성에 더 가깝다

좋은 권한 모델은 에이전트를 무력화하지 않는다. 오히려 작은 allow를 넓게, 진짜 ask를 선명하게, 비가역 deny를 분명하게 만든다.

10. 결론: allow / ask / deny는 설정값이 아니라 운영 철학이다

권한 설계는 안전팀만의 문제가 아니다. 에이전트가 실제로 일하는 환경에서는 권한 모델이 곧 품질 모델이 된다.

무엇을 기본 허용할지, 어디서 사람에게 물을지, 무엇을 구조적으로 금지할지는 결국 아래 질문으로 돌아간다.

  • 실패 반경을 얼마나 작게 만들 것인가
  • 사람 승인을 어디에만 쓰게 만들 것인가
  • 어떤 경계를 절대 넘기지 않을 것인가

즉 allow / ask / deny는 단순한 설정값 세 개가 아니다. 조직이 에이전트에게 어느 정도의 자율성과 어느 정도의 책임 경계를 줄 것인가를 표현하는 운영 철학이다.

함께 읽으면 좋은 글

참고 자료

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »