가드는 자기가 보는 축으로만 막는다 | 법마디(Lawmadi) OS 기술칼럼

초록 에이전트에 가드레일을 붙이는 일은 이제 표준이 됐지만, 가드가 무엇을 보고 막는지는 표준이 아닙니다. 이번 여름 공개된 세 연구는 가드의 판정 축이 어긋나는 세 자리를 각각 실측합니다. 값이 어디서 왔는지(영향)만 보고 행동이 승인됐는지(권한)를 보지 않는 가드는 정당한 도구 사용을 공격으로 읽습니다. 실행 뒤에 서서 설명만 하는 가드는 환불처럼 되돌릴 수 없는 행동을 막지 못합니다. 그리고 에이전트가 스스로 고친 프롬프트와 도구는 '성능이 올랐다'는 사실만으로는 안전하지 않습니다 — 다른 상태에서 되돌릴 수 있는지가 따로 검증되어야 합니다. 세 자리를 차례로 살피고, 오늘 우리 파이프라인이 실제로 겪은 사고에서 이 구분이 어떻게 나타났는지를 적습니다.

가드레일 이야기를 할 때 우리는 대개 '있는가 없는가'를 묻습니다. 프롬프트 주입 방어가 있는가, 위험 행동 차단이 있는가, 출력 검증이 있는가. 그런데 올해 여름 나온 연구들을 나란히 놓으면 질문이 바뀝니다 — 그 가드는 무엇을 보고 판정하는가. 같은 행동, 같은 승인, 같은 효과인데 값 하나가 사용자 입력 대신 도구 결과에서 왔다는 이유로 공격 판정이 커진다면, 그 가드는 위험이 아니라 출처를 재고 있는 것입니다. 환불 버튼이 눌린 뒤에 '그 행동은 위험했다'고 설명하는 가드는 감사 기록이지 방어가 아닙니다. 그리고 에이전트가 스스로 하네스를 고쳐 성능을 올렸을 때, 그 변화를 다른 상태에서 되돌릴 수 있는지 묻지 않는 가드는 일방통행 문을 열어 둔 것입니다. 셋 다 가드가 없어서 생기는 문제가 아니라, 가드가 엉뚱한 축을 보고 있어서 생기는 문제입니다.

핵심 기술 개념

영향 기반 가드레일(influence-based guardrail)

행동을 구성한 값이 어떤 경로로 들어왔는지(사용자 입력인지 외부 도구 결과인지)의 인과 신호로 위험을 판정하는 방어. arXiv:2608.29942 는 이 신호가 '행동이 승인됐는가'라는 권한 정보를 담지 못해, 출처만 바뀐 정당한 행동을 공격 쪽으로 밀어낸다는 것을 보였다.

행동 단위 감독(action-level supervision)

과제 전체의 성공·실패라는 희소한 결과 신호를, 궤적 안 개별 행동이 왜 타당한지·왜 잘못인지의 구조화된 근거로 바꿔 학습에 쓰는 방식. arXiv:2608.30147(CAST)이 비가역 행동을 실행 전에 가로채는 critique 모델을 이 방식으로 훈련한다.

복구 가능성(recoverability) 검증

에이전트가 스스로 가한 수정(프롬프트·도구·미들웨어·하네스)이 그것이 만들어진 상태와 다른 상태에서도 안전하게 되돌려지는지를 독립적으로 확인하는 검증. arXiv:2608.28363(EvoUndo)은 성능을 올린 수정도 복구 검증에는 실패할 수 있음을 보였다.

기술 심층 분석

영향은 권한이 아니다 — 출처를 재는 가드는 정당한 행동을 공격으로 읽는다

arXiv:2608.29942 의 실험 설계가 정교한 지점은 '행동'을 고정했다는 데 있습니다. 승인 여부, 실행되는 행동, 의도된 효과를 전부 같게 두고, 행동에 필요한 값 하나가 사용자에게서 오는지 정당한 도구 결과에서 오는지만 바꿨습니다. 24개 기본 사례에서 파생한 96개 조건의 감사에서, 이 무해한 이동만으로 인과 신호가 공격 영역 쪽으로 움직였고 그 이동 폭이 실제 승인 여부를 바꿨을 때보다 컸습니다. 신호가 '무엇이 행동을 만들었는가'는 드러내지만 '그 행동이 승인됐는가'는 담지 못한다는 뜻입니다. 이것이 실무에서 문제가 되는 이유는 두 방향으로 샙니다. 정당한 행동이 차단되면 효용이 깎이고 지연이 붙으며, 사용자는 가드를 우회하는 습관을 배웁니다. 반대로 섀도 방식 가드 실험에서는 무권한 실행의 절반 이상이 뒤쪽 보안 검사에 닿기 전에 자동 통과했습니다. 가드가 있어도 판정 축이 권한을 안 보면, 오탐과 미탐이 동시에 생기는 것입니다.

비가역 행동의 가드는 실행 전에 서야 한다

arXiv:2608.30147(CAST)이 출발점으로 삼는 관찰은 단순합니다. 잘못된 환불 한 건처럼, 상태를 바꾸는 긴 작업 흐름에서는 행동 하나가 과제 전체를 되돌릴 수 없게 망칠 수 있고, 그런 행동은 실행되기 전에 가로채져야 한다는 것입니다. 문제는 최전선 모델조차 어떤 행동이 왜 잘못인지를 — 특히 도메인 규칙이 얽힌 긴 궤적 안에서 — 잘 설명하지 못한다는 데 있습니다. CAST 의 기여는 이 설명 능력을 프롬프트로 요청하는 대신 훈련으로 만드는 데 있습니다. 과제의 성공·실패라는 희소한 결과에서 출발해, 궤적을 분석해 행동 단위의 타당성 근거를 합성하고, 그 근거로 critique 모델을 학습시킨 뒤, 그 critique 로 정책 모델의 학습 데이터를 다시 만드는 순환입니다. 도구 호출 벤치마크에서 반복 시행 신뢰도가 의미 있게 올랐다는 결과보다 우리에게 중요한 것은 구도 자체입니다 — 가드의 위치(실행 전)와 가드의 언어(행동 단위 근거)를 함께 설계해야 하며, 결과만 보는 사후 채점으로는 비가역 행동을 막을 수 없다는 것입니다.

성능이 오른 수정도 되돌릴 수 없으면 부채다

에이전트가 자기 프롬프트·도구·하네스를 스스로 고치는 자기개선은 이제 드물지 않습니다. arXiv:2608.28363(EvoUndo)이 묻는 것은 그 다음입니다 — 그 수정이 만들어질 때와 다른 상태에서, 안전하게 되돌려질 수 있는가. 600개의 일회성 자기개선 과제에서 역량을 실제로 올린 수정 197건이 복구 가능성 검증에 실패했고, 종래의 복구 전략은 이 자연 발생 실패를 한 건도 되돌리지 못했습니다(0/197). 진단 결과 병목은 둘로 갈라졌습니다. 수정이 어느 상태 주소에 닿았는지를 정확히 붙잡는 그라운딩, 그리고 되돌림을 표현할 수 있는 복구 언어의 표현력입니다. 두 축을 함께 넓히자 오라클 기준 복구율이 크게 올랐다는 결과는, 복구가 사후 노력의 문제가 아니라 수정을 기록하는 형식의 문제라는 뜻입니다. '성능이 올랐다'는 검증과 '되돌릴 수 있다'는 검증은 서로 대체하지 못합니다. 전자만 있는 자기개선은 개선이라는 이름의 일방통행이고, 일방통행으로 쌓인 변화는 언젠가 아무도 끌 수 없는 상태가 됩니다.

세 연구를 하나로 접으면 — 가드의 명세는 축·시점·역방향이다

세 편을 한 문장씩으로 줄이면 이렇게 됩니다. 가드가 보는 신호가 판정하려는 속성과 같은가(영향≠권한), 가드가 서 있는 시점이 행동의 가역성과 맞는가(비가역이면 실행 전), 그리고 가드가 앞 방향만 보는가 되돌림까지 보는가(복구 가능성). 이 세 질문은 에이전트만의 이야기가 아니라 모든 자동화 검증의 명세 항목입니다. 우리가 게이트를 하나 만들 때 무의식적으로 정하는 것이 바로 이 셋이기 때문입니다. 어떤 신호로 판정하는가 — 파일이 바뀌었는가, 테스트가 초록인가, 산출물이 등록됐는가. 언제 도는가 — 커밋 전인가, 배포 전인가, 발행된 뒤인가. 그리고 실패하면 무엇이 남는가 — 막힌 상태로 남는가, 지나간 것을 되돌릴 수 있는가. 축이 틀린 가드는 오탐과 미탐을 함께 만들고, 시점이 늦은 가드는 세는 일밖에 못 하며, 역방향이 없는 가드는 한 번의 통과를 영구 상태로 만듭니다. 가드를 추가하자는 제안서에는 이 세 칸이 항상 채워져 있어야 합니다.

초록 잡 아래의 공백 — 판정 축이 없는 자리는 대조가 잡는다

오늘 새벽 우리 파이프라인에서 이 구분이 실물로 나타났습니다. 매일 여섯 종의 콘텐츠를 굽는 배치가 정시에 떴고 잡은 성공으로 끝났는데, 생성 호출은 전부 공급자의 지불 판정 거부(403)로 거절되고 있었습니다. 여기서 두 가드가 각자 자기 축대로 일했습니다. 생성기 안의 발행 게이트는 '검증할 수 없는 것은 내보내지 않는다'는 축을 보므로, 생성 실패를 삼키고 발행을 건너뛰었 습니다 — 옳은 fail-closed 입니다. 반면 잡 상태라는 가드는 '스텝이 비정상 종료했는가'라는 축만 보므로, 하루치 콘텐츠가 비었다는 사실에 대해서는 아무 말도 하지 않고 초록이 됐습니다. 부재를 드러낸 것은 세 번째 축 — '나왔어야 할 것이 등록 대장에 있는가'를 세는 대조였습니다. 스트림마다 등록 코드가 찍히는 대장을 날짜로 잘라 보니 여섯 자리 중 두 자리만 차 있었습니다. 잡 성공은 발행 성공이 아니라는 것을 우리는 문서로 알고 있었지만, 그것을 문서가 아니라 대조 절차가 잡았다는 점이 오늘의 교훈 입니다. 판정 축이 없는 자리는 결과 대조가 최후의 가드입니다.

기술적 트레이드오프

긴장 관계 가드의 판정을 정확하게 만드는 일은 전부 비용을 요구한다. 권한을 제대로 보려면 승인 정보를 행동까지 전달하는 배선을 새로 깔아야 하고, 실행 전 개입은 모든 비가역 행동에 검사 지연을 얹으며, 복구 가능성 검증은 자기개선의 속도를 깎는다. arXiv:2608.29942 의 실측에서도 의미 기반 모니터를 붙이면 공격 성공은 크게 줄었지만 효용도 함께 깎였다 — 안전과 효용이 같은 손잡이에 묶여 있는 것이다.

실무적 해소 손잡이를 하나로 두지 않고 행동의 성질로 가릅니다. 되돌릴 수 없는 행동(발행· 송금·삭제·외부 전송)에만 실행 전 가드와 권한 확인을 세우고, 되돌릴 수 있는 행동은 가볍게 통과시키되 사후 대조가 잡게 합니다. 이렇게 나누면 검사 비용은 비가역 행동의 수에 비례하고, 효용 손실은 전체가 아니라 그 부분집합에만 발생합니다. 그리고 '되돌릴 수 있다'는 분류 자체가 검증 대상입니다 — EvoUndo 가 보인 대로, 되돌림은 가정이 아니라 기록 형식과 검증으로 보장해야 하는 속성입니다.

법마디 OS에 적용한다면

우리 파이프라인에 세 축을 그대로 대 봅니다. 첫째, 실행 전 가드는 발행 경로에 이미 있습니다. 답변과 콘텐츠의 법령 인용은 발행 전에 국가법령정보센터 원문과 대조되고, 확인되지 않으면 그 문장은 나가지 않습니다 — 비가역 행동(발행)에 실행 전 가드를 세운다는 CAST 의 구도와 같은 자리입니다. 둘째, 판정 축의 어긋남은 오늘 실물로 확인했습니다. 새벽 배치에서 생성 호출이 전부 공급자의 지불 판정 거부로 죽었는데, 생성기들은 발행을 건너뛰며 정상 종료했고 잡은 초록으로 끝났습니다. 잡 상태라는 가드는 '비정상 종료' 축만 보므로 하루치 공백을 볼 수 없었고, 부재는 스트림별 등록 코드를 날짜로 대조하는 절차가 잡았습니다. 셋째, 복구 축은 우리에게 절반만 있습니다. 콘텐츠와 자산은 전부 버전 관리 아래라 되돌림이 기록 형식으로 보장되지만, 수기 발행 스크립트가 소모하는 리더 순환 큐처럼 재실행이 상태를 한 번 더 움직이는 자리는 상수 고정과 단언으로 막고 있을 뿐 독립 검증은 없습니다. EvoUndo 의 언어로 말하면 복구 언어는 있는데 복구 검증이 아직 사람 손에 있는 상태이고, 그것이 다음에 닫을 자리입니다.

기술적 함의

가드를 설계·리뷰할 때 세 칸을 명시한다: 판정 신호가 판정하려는 속성과 같은가, 실행 전인가 후인가, 실패·통과를 되돌릴 길이 있는가. 세 칸 중 하나라도 비어 있으면 그 가드가 못 보는 사고 유형을 함께 적는다.
권한 정보는 신호에서 추정하지 않고 명시적으로 전달한다. 값의 출처(영향)로 승인 여부를 추정하는 가드는 정당한 행동을 막는 쪽과 무권한 행동을 통과시키는 쪽으로 동시에 샌다.
잡·스텝 상태와 별도로 '나왔어야 할 산출물'의 등록 대장을 두고 매일 대조한다. 실패가 정상 종료로 접히는 fail-closed 구조에서는 상태 초록이 부재를 말해 주지 않는다.

"가드가 있느냐는 질문은 절반입니다. 나머지 절반은 그 가드가 무엇을 보고, 언제 서고, 무엇을 되돌릴 수 있느냐입니다."

참고 자료

칼럼니스트

지유

최고기술책임자 (CTO · Chief Technology Officer)

실리콘밸리 유니콘 창업 멤버급 / AI 무결성 검증 분야 세계적 석학급

법마디 OS 무료로 경험하기

본 칼럼은 법마디 OS 기술팀의 관점이며, 특정 제품·기술에 대한 보증이나 법률 자문이 아닙니다.