에이전트가 할 수 있는 일과 없는 일

“AI가 사고 치면 어쩌나”는 가장 먼저 나오는 질문입니다. 답은 단순해야 했습니다 — AI는 제안만 하고, 결정은 사람이 합니다. 문제는 이 원칙을 말이 아니라 시스템 구조로 강제하는 것이었습니다. 신뢰는 선언이 아니라 게이트로 만듭니다. 이 글은 에이전트의 권한 경계를 어떻게 코드로 못 박았는지의 기록입니다.

HITL·정책 게이트·RED_LIST

용어: HITL (Human-in-the-Loop, 사람 개입)

AI가 일을 끝까지 혼자 하지 않고, 중요한 길목에서 사람의 확인·승인을 거치게 하는 구조입니다. “사람이 고리 안에 들어 있다”는 뜻입니다.

용어: 정책 게이트(policy gate)

에이전트가 어떤 도구를 실행하기 직전에 통과해야 하는 검문소입니다. “이 도구를 지금 이 상황에서 실행해도 되는가”를 정책이 판정하고, 안 되면 막습니다.

용어: RED_LIST

아무리 신뢰가 쌓여도 에이전트가 절대 혼자 실행하지 못하게 박아 둔 행위 목록입니다. 영구 금지선입니다.

기본은 막혀 있고, 결재로만 열린다

가장 흔한 실수는 AI 기능을 일단 다 켜 두고 위험한 것만 골라 막는 것입니다. 이렇게 하면 “막는 걸 깜빡한” 위험이 항상 새어 나갑니다. 우리는 정반대로 설계했습니다 — **모든 자율 행동은 기본적으로 비활성(off)**이고, 책임자의 결재로만 하나씩 열립니다.

신입사원에게 첫날부터 회사 인감을 주지 않듯이, 에이전트에게도 신뢰가 쌓인 만큼만 권한을 줍니다. 모든 도구 실행은 사전에 정책 게이트를 통과해야 합니다. 정책이 허용하지 않으면 그 도구는 실행되지 않고, 대신 “왜 막혔는지”가 기록됩니다. 켜고 끄는 것은 코드 수정이 아니라 정책 플래그이고, 그 플래그를 바꾸는 건 사람의 결재입니다.

왜 “기본 off”가 더 안전한가

“기본 on, 위험만 차단”은 차단 목록을 빠뜨리면 뚫립니다 — 막아야 할 걸 깜빡하는 순간 사고가 납니다. “기본 off, 승인으로 개방”은 승인을 빠뜨리면 그냥 안 열릴 뿐입니다 — 실수의 방향이 안전한 쪽입니다. 두 설계의 차이는 “실수했을 때 어느 쪽으로 넘어지는가”이고, 후자는 항상 막히는 쪽으로 넘어집니다.

	기본 on (위험만 차단)	기본 off (승인으로 개방)
실수 지점	차단 목록을 빠뜨림	승인을 빠뜨림
실수의 결과	위험 행동이 실행됨 (사고)	기능이 안 열림 (무사고)
넘어지는 방향	열리는 쪽 (위험)	막히는 쪽 (안전)
권한 확대 방식	이미 다 열려 있음	신뢰가 쌓인 만큼 결재로 개방

이 차이가 사소해 보여도, 실제로 사고가 나느냐 마느냐를 가릅니다. 사람은 반드시 무언가를 빠뜨립니다. 그렇다면 빠뜨렸을 때 안전한 쪽으로 넘어지는 설계를 골라야 합니다. “기본 off”는 그 원칙을 권한 모델에 박은 것입니다.

영원히 자율 실행 금지 — RED_LIST

정책 게이트가 “신뢰가 쌓이면 열 수 있는 문”이라면, RED_LIST는 “신뢰가 아무리 쌓여도 열지 않는 문”입니다. 아무리 에이전트가 똑똑해지고 실적이 좋아져도, 이 목록의 행위는 항상 사람 결재입니다.

함정: RED_LIST에 들어가는 것들

일정 금액 이상의 구매, 외부 메일·견적 발송, 거래처 등록·단가 변경, 인사 결정, 계약 서명, 급여 확정, 회계 마감 — 이런 일은 항상 사람 결재입니다. 에이전트가 이걸 시도하면 시스템이 자동으로 승인 대기함으로 돌립니다. 5년이 지나도 이 선은 사람이 지킵니다. 신뢰의 문제가 아니라 책임의 문제이기 때문입니다 — 계약 서명의 법적 책임은 사람이 져야 합니다.

에이전트가 도구를 실행하려면 두 관문을 통과합니다. 먼저 RED_LIST(영구 금지선)에 걸리면 무조건 사람 결재로 돌고, 통과해도 정책 게이트(기본 off)가 다시 판정합니다. 막히면 "왜 막혔는지"가 함께 기록됩니다.

HITL — 1차는 AI, 결정은 사람

그렇다고 AI를 단순 조회 도구로만 쓰자는 게 아닙니다. 그러면 AI를 도입한 의미가 없습니다. 핵심은 역할 분담입니다. 에이전트가 데이터를 보고 판단해 초안과 추천을 만들어 오면, 사람은 백지에서 시작하는 대신 그 초안을 검토하고 승인하거나 고칩니다. 이게 HITL입니다 — AI가 80%를 해 오고 사람이 마지막 20%(판단과 책임)를 맡는 구조입니다.

일의 종류	에이전트의 권한	사람의 역할
위험도 낮음 (조회·보고서·단순 알림)	바로 처리	사후 확인
중요한 일	승인 대기함에 올림	눌러야 확정
RED_LIST	실행 불가	무조건 사람 결재

여기에 한 번에 전부 멈추는 비상 스위치를 더했습니다. 문제가 감지되면 에이전트 전체를 즉시 정지시킬 수 있고, 모든 행동은 사후에도 추적 가능한 기록으로 남습니다. “막을 수 있고, 멈출 수 있고, 되짚어 볼 수 있다”는 세 가지가 갖춰져야 비로소 자율성을 조금씩 풀 수 있었습니다.

근거 없는 답은 신뢰할 수 없다

마지막 의무는 근거(Evidence) 표시입니다. 에이전트가 “이 결재는 이 사람에게 올리세요”라고 추천하면, 왜 그렇게 판단했는지를 함께 보여야 합니다. 추천만 던지고 이유를 숨기면, 사람은 그 추천을 검증할 방법이 없어 그냥 따르거나 그냥 무시하게 됩니다. 둘 다 위험합니다.

그래서 회사 데이터에 관한 사실을 답할 땐 그 근거가 된 기록을 인용하게 하고, 모르면 **“데이터 없음”**이라고 답하게 했습니다. 추측을 사실처럼 말하는 환각이야말로 가장 위험한 실패이기 때문입니다. “아마 그럴 것이다”를 “그렇다”로 말하는 순간, 그 답을 믿은 사람이 잘못된 결정을 내립니다. 모른다고 말하는 AI가, 그럴듯하게 지어내는 AI보다 훨씬 안전합니다.

교훈

에이전트의 권한 경계는 선언이 아니라 구조로 강제해야 합니다. ① 기본은 off로 두고 결재로만 여세요 — 실수해도 안전한 쪽으로 넘어집니다. ② 어떤 신뢰가 쌓여도 자율 실행을 영원히 금지하는 RED_LIST를 두세요 — 신뢰가 아니라 책임의 문제입니다. ③ AI는 1차 수행과 추천까지만, 결정은 사람이. ④ 모든 판단에 근거를 붙이고, 모르면 “데이터 없음”이라 답하게 하세요. 이 경계가 분명할수록 오히려 AI에게 더 많은 일을 안심하고 맡길 수 있습니다. 막아 둔 만큼 신뢰가 자라고, 그 신뢰는 자가학습으로 누적됩니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.