에이전트가 production 배포 권한을 가질 수 있는가

지난 분기, 같은 한 줄짜리 질문을 7 고객사 보안팀에 던졌다.

"에이전트에게 production 배포 권한을 줄 수 있나요?"

답이 완전히 갈렸다. 3 곳은 원칙적으로 안 됨, 2 곳은 조건부로 가능, 2 곳은 이미 줬음. 같은 질문에 다른 답 이 나오는 이유는 조직마다 다른 4가지 변수 때문이다.

이 글은 그 4 변수와, 우리가 현장 7개 사례에서 본 경계의 패턴이다.

4 변수가 답을 가른다

변수 1 — 결정과 실행이 분리되어 있나

가장 결정적. production 배포 결정 (코드를 production 에 보낼지) 과 production 배포 실행 (실제 배포 명령) 이 같은 행위인가, 다른 행위인가?

이걸 분리 해 둔 조직은 에이전트에게 실행 만 줄 수 있다 (결정은 사람). 분리 안 한 조직은 에이전트가 결정+실행 둘 다 갖게 되고, 보안 검토에서 거의 항상 막힌다.

변수 2 — 권한이 시간 / 상황 조건 을 가질 수 있나

권한 모델이 영구적 (RBAC) 인지, 조건부 (시간·상태·승인 후) 인지. 영구적 권한 모델 위에서 에이전트에게 production 권한을 주는 건 24/7 배포 가능 에이전트 를 만드는 것 — 이건 보안팀이 거의 항상 거부.

조건부 권한 모델이면 PR 승인 후 30분 안에만, staging 통과한 commit 만, 09:00~18:00 KST 만 같은 좁은 윈도우 안에서만 에이전트가 동작 가능. 이건 통과 가능성 높음.

변수 3 — 감사 trail 이 사람과 동일한 형식 인가

에이전트의 행위가 사람의 행위와 같은 audit log 에 같은 schema 로 기록되나? 아니면 별도 시스템 에 기록되나?

같은 schema 면 사후 감사가 자연스럽다 — 누가 (사람 or 에이전트) 무엇을 언제 했나 가 한 쿼리. 별도면 사후 인과 재구성 이 수동 작업 — 보안팀이 거부할 명분.

변수 4 — 에이전트의 의사결정이 결정론적 인가

에이전트가 같은 입력에 같은 출력 을 내나, 비결정적 인가? LLM 기반 에이전트는 본질적으로 비결정적. 비결정적 에이전트가 production 권한을 가지면 재현 불가능한 행위 가 발생 가능.

해결: 비결정적 모델을 쓰되, 결정 단계 를 결정론적 룰 로 감싸는 방식. 모델은 후보 액션 제안, 룰이 검증 후 실행.

7 사례의 답이 갈린 이유

사례   | 결정/실행 분리 | 조건부 권한 | 감사 동일 schema | 결정론적 wrapping | 결과
─────┼──────────────┼────────────┼────────────────┼────────────────┼─────
A    |     X         |    X       |       X         |       X         | 거부
B    |     X         |    X       |       O         |       X         | 거부
C    |     O         |    X       |       O         |       X         | 거부
D    |     O         |    O       |       O         |       X         | 조건부 가능
E    |     O         |    O       |       O         |       O         | 가능
F    |     O         |    O       |       O         |       O         | 이미 운영 중
G    |     O         |    O       |       O         |       O         | 이미 운영 중

4 변수 모두 O 인 조직만 현실적으로 에이전트 production 권한이 가능. 3 개 만 만족하면 조건부 (특정 service tier 만 등). 2 개 이하 면 거의 항상 거부.

우리가 추천 하는 경계

                  사람                              에이전트
                  ─────                            ─────────
대안 생성          O (옵션 A or B)                  O (옵션 A,B,C,D 제안)
1차 평가          O (어느 게 좋다)                  O (점수 매김)
승인              O                                X (가장 중요한 경계)
실행              X (귀찮음)                        O (자격 검증 후 실행)
사후 검토          O                                X (스스로 검토 X)
회수              O                                X (스스로 회수 X)

이 한 표가 우리가 7 사례에서 수렴한 경계다. 승인 은 사람만, 실행 은 에이전트, 사후 검토 와 회수 는 사람만. 이 셋만 사람이 유지하면 나머지 는 에이전트가 가져가도 audit 통과 가능.

그래서 답은 — 조건부 가능

질문에 단일 답이 없다. 조건부 가능 이 정확한 답이고, 그 조건이 위 4 변수다. 만약 4 변수 중 2 개 이하 만 만족한다면, 지금 그 권한을 주려는 게 아니라 4 변수를 채우는 게 먼저.

우리가 반대 하는 패턴

위 4 변수를 모두 무시하고 빠르게 도입 하려는 패턴 — 보통 데모용. 데모는 통과해도 production 으로 들어가는 순간 3개월 안에 사고가 난다. 그 사고는 보안팀의 향후 모든 에이전트 도입을 거부 하는 명분이 된다 — 한 사고가 다음 5년의 가능성을 닫는다.

누가 이 글을 읽으면 좋은가

지금 AI 에이전트의 권한 경계 를 결정하려는 CIO·CISO·플랫폼 리드. 위 4 변수가 조직에 갖춰져 있는지 의 점검이 에이전트 자체의 모델 선택 보다 결정적. 모델은 바꿀 수 있다. 권한 모델은 바꾸기 어렵다.