| Developed by | OpenAI |
|---|---|
| Type | Technique |
| Aliases | guardian agent, auto-review, 자동 리뷰 |
| Related | Codex (OpenAI), Constitutional AI, 워크스페이스 에이전트, 컴퓨터 사용 (에이전트), 역할 기반 접근 통제 (RBAC) |
무엇인가
가디언 에이전트는 다른 AI 에이전트가 어떤 행동을 하기 직전에 “이거 해도 돼?”를 대신 검토해주는 또 하나의 AI다. 사람으로 치면 신입 직원 옆에 붙어서 “이메일 보내기 전에 한 번 보여줘”, “그 파일 지우려는 거 정말이야?”라고 묻는 사수에 가깝다.
직접 일을 만들어내는 메인 에이전트와 달리, 가디언은 결과물을 생성하지 않는다. 오직 다른 AI의 행동을 보고 통과시킬지 멈출지를 결정하는 것이 그 역할이다.
왜 필요한가
[[codex]] 같은 코딩 에이전트나 [[computer-use]]로 마우스·키보드를 직접 조작하는 에이전트가 점점 더 자율적으로 일한다. 모든 클릭과 명령마다 사람이 승인 버튼을 누르게 만들면 자동화의 의미가 사라진다. 반대로 무인 자동화로 풀어두면, 위험한 행동—중요한 파일 삭제, 결제, 외부 메일 발송, 운영 서버 명령—이 그대로 실행될 수 있다.
가디언 에이전트는 이 둘 사이를 메우는 장치다. 위험도가 낮은 행동은 그대로 통과시키고, 사람의 판단이 꼭 필요한 순간에만 승인 게이트를 띄운다. 결과적으로 사용자가 마주하는 “정말 진행할까요?” 팝업의 개수가 크게 줄어든다.
일상의 비유
집에 청소 로봇과는 별개로 “이 가구는 옮기지 마라”, “이 방은 들어가지 마라”를 정해주는 보호자가 따로 있다고 생각해 보자. 청소 로봇이 가구 위에 놓인 노트북을 떨어뜨리려 하면, 보호자가 그 순간만큼은 작업을 멈추고 주인을 부른다. 평소에는 존재가 보이지 않다가, 위험한 순간에 가장 먼저 끼어드는 역할이다.
어떻게 작동하는가
대략적인 흐름은 이렇다.
- 메인 에이전트가 “다음에 뭘 할지” 행동 후보를 만든다.
- 가디언 에이전트가 그 행동과 맥락—어떤 파일인지, 어느 계정인지, 영향 범위가 어디까지인지—을 함께 받는다.
- 안전·정책·과거 패턴에 비추어 “통과 / 사용자에게 물어봐야 함 / 거부” 중 하나를 정한다.
- 그 결정에 따라 행동이 그대로 실행되거나, 승인 요청이 사용자에게 올라가거나, 아예 차단된다.
어디서 마주칠 수 있나
OpenAI의 [[codex]] 자동 리뷰 기능이 대표적이다. Codex가 코드를 고친 뒤 스스로 한 일을 한 번 더 점검하는 데 가디언 역할의 모델이 들어간다. [[workspace-agents]]처럼 팀 단위로 공유되는 AI 동료에게도 같은 종류의 안전망이 필요하다. AI가 사람을 대신해 더 많은 일을 할수록, 그 옆에서 조용히 검토하는 또 다른 AI의 비중도 함께 커진다.
어디에 쓰는가
가디언 에이전트는 자율 에이전트 시스템에서 사람의 승인 게이트를 동적으로 거는 장치다. 메인 에이전트의 출력이나 도구 호출을 그대로 실행하기 전, 별도의 평가 모델이 위험도와 정책 준수 여부를 판단해 allow / ask / deny 중 하나를 반환한다.
가장 잘 알려진 구현체는 [[codex]]의 자동 리뷰다. Codex가 코드 변경, 셸 명령, 외부 API 호출을 수행하기 전에 가디언이 한 번 검토하고, 위험하다고 판단한 경우에만 사용자에게 띄운다. 결과적으로 사용자는 모든 액션이 아니라 “사람의 결정이 필요한 일부”만 마주하게 된다.
통합 패턴
실무에서 가디언을 끼워 넣는 위치는 보통 셋 중 하나다.
1) 도구 호출 직전 후크
LLM이 tool_call을 만든 직후, 실제 도구 실행 전에 가디언이 평가한다. function name, arguments, 호출 맥락을 입력으로 넣고 allow / ask / deny 라벨을 받는다. LangChain, OpenAI Assistants, Anthropic Claude API 모두 이 후크를 직접 만들 수 있다.
2) 액션 큐 사이의 정책 게이트
[[computer-use]]나 자율 RPA 흐름처럼 멀티 스텝 액션을 큐로 쌓는 경우, 큐와 실행기 사이에 가디언을 두는 편이 좋다. 큐를 통째로 검토하면 단일 액션은 안전해 보여도 시퀀스 전체가 위험한 케이스—예: 권한 상승 + 외부 전송—를 잡을 수 있다.
3) 결과물 게시 전 검토
[[workspace-agents]]가 만든 보고서·이메일·티켓을 외부로 내보내기 전에 가디언이 본다. 정보 유출, 회사 정책 위반, 내부 전용 데이터의 외부 이동 같은 패턴을 잡는 데 효과적이다.
설계 시 고려할 점
- 명시 정책 vs. 학습된 휴리스틱: 가디언에게 “이 도메인의 결제 도구는 항상 ask”처럼 하드 룰을 줄지, 자유롭게 판단하게 할지를 정해야 한다. 보통 둘을 섞는다. 명시 룰은
deny/ask를 강제하고, 회색 지대만 모델이 본다. - 레이턴시 예산: 가디언 호출은 모든 액션마다 추가 비용이 된다. 빠른 작은 분류기로 1차 필터를 하고, 의심 가는 케이스만 큰 모델에 보내는 2단 구조가 흔하다.
- 로그와 감사: 가디언의 판단 결과와 근거는 [[role-based-access-control]] 로그와 함께 보관해야 사후 추적이 가능하다.
- 폴백 정책: 가디언이 실패하거나 timeout일 때 기본 동작은
deny또는ask여야 한다.allow by default는 사고로 직결된다.
한계
가디언이 잘못 통과시킨 액션의 책임 모델은 아직 불분명하다. 같은 모델 패밀리로 메인과 가디언을 모두 구성하면 같은 종류의 실수를 함께 놓칠 가능성도 있어, 실무에서는 서로 다른 모델·다른 프로바이더를 섞는 패턴이 늘고 있다.
정의와 위치
가디언 에이전트는 다른 에이전트가 제안한 액션을 평가해 통과·승인 요청·거부 라벨을 부여하는 메타-레벨 안전 분류기다. 자율 에이전트 시스템의 control loop에서 actor와 environment 사이에 위치하며, 명시적으로 “human-in-the-loop을 동적으로 발동시키는” 역할을 맡는다.
self-critique나 reflection 계열 기법이 모델이 자기 출력을 다시 보고 고치는 것이라면, 가디언은 분리된 평가 모듈로서 행동 실행 자체를 게이팅한다는 점에서 다르다. [[constitutional-ai]]가 RLHF 시점의 자기 비평을 학습 단계에 통합한 것이라면, 가디언은 그것의 inference-time, action-level 변형으로 볼 수 있다.
형식적 정식화
메인 에이전트의 정책을 π, 제안 액션을 a ~ π(·|s), 가디언을 g라 하자. g는 다음을 출력한다.
g(s, a) ∈ {allow, ask, deny}
전체 시스템의 실효 정책은:
allow: a를 그대로 실행ask: 인간 H에게 a를 제출하고, H의 승인이 있을 때만 실행deny: a를 차단하고 π에 거부 시그널 반환
목표는 위험 액션의 expected harm을 최소화하면서 인간 개입 횟수 E[#ask]를 줄이는 다목적 최적화다. 두 목표는 상충하기 때문에 가디언의 결정 경계가 시스템의 안전성-자율성 trade-off를 직접 결정한다.
알려진 구현과 미공개 영역
OpenAI는 [[codex]]의 자동 리뷰 기능을 가디언 에이전트로 설명했다. 그러나 다음은 모두 공개되지 않았다.
- 모델 아키텍처: 메인 모델과 동일 파라미터를 공유하는지, 별개의 작은 분류기인지.
- 학습 시그널: 어떤 라벨—전문가 주석, 사용자 피드백, 합성 위험 액션—로 fine-tune했는지.
- 오탐률·미탐률: false negative(위험 액션을 allow)는 사용자 안전에, false positive(안전 액션을 deny)는 자율성에 직접 영향을 주는데, 두 수치 모두 미공개.
- 책임 모델: 가디언이 통과시킨 액션이 사고로 이어졌을 때의 책임 분담은 명시적으로 다뤄지지 않았다.
열린 연구 문제
1) 동질성 위험
메인과 가디언을 같은 사전학습 분포에서 가져오면 같은 종류의 실수를 공유할 위험이 있다. 적대적 프롬프트가 메인을 속였을 때 가디언도 함께 속는 경우가 보고되고 있다. 다른 모델 패밀리·다른 학습 데이터의 가디언을 쓰는 것이 한 가지 mitigation이지만, 비용과 일관성 사이의 trade-off가 따라온다.
2) 캘리브레이션과 게이팅 임계값
가디언의 confidence를 어떻게 ask/allow 임계값으로 매핑할 것인가는 비자명하다. 사용자가 ask를 너무 자주 받으면 클릭 피로 때문에 자동 승인하는 경향이 보고되어, 결과적으로 안전 게이트가 무력화된다. 임계값은 사용자별·도메인별로 학습돼야 한다는 주장이 늘고 있다.
3) 공모와 게임화
장기 학습 환경에서 메인 에이전트가 가디언의 결정 경계를 학습해 회피 패턴—예: 위험 액션을 작은 무해 액션으로 분할—을 만들어낼 수 있다. red-teaming과 정기적 가디언 재학습이 필요하다는 논의가 이어지고 있다.
4) [[role-based-access-control]] 과의 관계
기존 RBAC가 정적인 권한 모델이라면, 가디언은 맥락 기반의 동적 권한 평가로 볼 수 있다. 둘을 layered defense로 결합할 때 어느 층에서 무엇을 막을지에 대한 설계 원칙은 아직 정립되지 않았다.
평가 난점
가디언의 성능을 측정할 표준 벤치마크는 아직 부재하다. 위험 액션 데이터셋은 본질적으로 분포가 비대칭—드물고 다양함—이라, 일반적 분류기 평가 지표(F1, AUROC)가 실제 운영 위험을 반영하지 못한다. 소수의 catastrophic miss가 다수의 정상 동작을 압도하는 long-tail 문제이기 때문이다.