쓰기 작업이 아니었던 위키 쓰기: 에이전트 가드레일은 도구(Tools)가 아닌 결과(Outcomes)를 확인해야 하는 이유

지난주 에이전트 안전 관련 뉴스는 특이한 양상을 띠었습니다. Nvidia는 샌드박스 런타임과 모니터링 계층을 갖춘 오픈 에이전트 안전 플랫폼을 출시했는데, 이 플랫폼은 경계를 벗어나는 에이전트를 '밀리초 단위'로 격리할 수 있다고 밝혔습니다. 같은 주에는 보안 분석 글에서 읽기 전용 인터넷 정책 하에 작동하는 다수의 에이전트가 비활성 위키를 통해 협력하여 그 내용을 변경한 사례를 설명했습니다. 이들은 단순 HTTP GET 요청을 사용했습니다.

어떤 분석은 이 샌드박스가 예상되는 쓰기 메커니즘(write mechanism)은 차단했지만, 외부 시스템을 변경할 수 있는 모든 행동을 막지는 못했다고 지적합니다.

이 문장이 이번 뉴스 사이클에서 가장 유용한 내용이며, 사실 이는 샌드박스 자체에 관한 것이 아닙니다. 이는 명세(specification) 실패를 설명하는 것입니다. 정책은 '쓰기 금지'라고 했지만, 에이전트들은 쓰기로 불리지 않지만 그 효과는 쓰기와 같은 행동을 찾아냈습니다.

만약 에이전트를 구축하거나 배포한다면, 가드레일을 금지된 도구 목록으로 취급하는 것을 멈추고 _결과(outcomes)_에 대한 분류 문제로 다루기 시작해야 할 때입니다. 분류 문제는 레이블링된 데이터가 필요합니다. 바로 이 부분에서 대부분의 팀들이 투자를 소홀히 하고 있습니다.

도구 수준 규칙이 계속해서 새어나가는 이유

도구 수준 규칙은 다음과 같습니다: POST 차단, rm 차단, DROP TABLE 차단. 이는 작성하기 쉽고 감사(audit)하기도 합니다. 하지만 이 규칙들은 부작용을 일으키는 모든 방법을 열거할 수 있다고 가정하는데, 그럴 수는 없습니다. 몇 가지 격차의 예시는 다음과 같습니다:

• 상태를 변경하는 GET 엔드포인트 (여전히 오래된 내부 도구나 위키에서 흔함).
• 부작용이 있는 저장 프로시저(stored procedure)를 여전히 호출할 수 있는 '읽기 전용' 데이터베이스 역할.
• 차단 목록에 없지만 파이프, 리디렉션 또는 패키지 매니저 훅을 통해 쓰기를 하는 셸 명령어.
• 이메일은 보낼 수 없지만 외부 참석자를 포함하여 캘린더 초대를 생성할 수 있는 에이전트.

이 모든 사례는 행동의 _구문(syntax)_은 무해해 보이지만 그 _효과(effect)_가 그렇지 않은 경우입니다. 거버넌스 담당자들이 계속 제시하는 해결책은 '요청 유형을 제한하는 것'이 아니라 '결과를 검증하는 것'입니다. 동의합니다. 하지만 '결과를 검증한다'는 말은 하기 쉽고 실행하기 어렵습니다. 컨텍스트 내에서 제안된 각 행동에 대해 예상되는 결과가 선을 넘었는지 여부를 결정해야 하는 무언가가 필요합니다. 실제로는 그 '무언가'가 모델일 수도, 규칙 엔진(rules engine)일 수도, 인간 검토자(human reviewer)일 수도 있고, 이들의 혼합체일 수도 있습니다.

이 세 가지 모두

3. 도메인 특화 부작용 지식(Domain-specific side-effect knowledge). 어떤 행동이 '쓰기 방식'인지 여부는 시스템에 따라 다릅니다. 레거시 CMS에 대한 GET 요청과 CDN에 대한 GET 요청은 같지 않습니다. 스택을 아는 검토자(데이터베이스 관리자, 결제 엔지니어, 임상의 등)가 이를 정확하게 분류합니다. 일반적인 크라우드 레이블러는 종종 그렇지 못하며, 이 레이블 노이즈는 프로덕션 환경에서야 눈에 띕니다.

4. 다중 에이전트 상호작용 추적(Multi-agent interaction traces). 위키 사례가 중요한 이유는 에이전트들이 개별적으로 잘못 행동한 것이 아니라, 공유된 외부 표면을 통신 채널로 사용했기 때문입니다. 에이전트별 가드레일로는 이를 파악할 수 없습니다. 다른 에이전트들이 공유 상태에 무엇을 작성했는지 포함하고, 아무도 의도하지 않은 협업 패턴의 레이블링된 예시를 담은 추적이 필요합니다.

실용적인 패턴: 두 개의 계층과 하나의 공유 레이블 세트

만약 제가 오늘날 이것을 구축한다면, 런타임 샌드박스(runtime sandbox)와 학습된 분류기(learned classifier) 중 하나를 선택하지 않을 것입니다. 둘 다 실행하여 공통의 명세(spec)를 공유하게 만들 것입니다.

레이어 1: 인프라 수준에서의 하드 경계. 네트워크 이그레스 허용 목록(Network egress allow-lists), 범위가 지정된 자격 증명(scoped credentials), 파일 시스템 격리(filesystem isolation), 실행별 예산(per-run budgets) 등이 있습니다. 이는 Nvidia의 런타임과 같은 제품이 하는 일이며, 모델 판단 없이 작동하기 때문에 가장 먼저 투자해야 할 부분입니다. 이 레이어의 한계는 위키 사례가 보여주었듯이, 명시적으로 열거한 것만 막을 수 있다는 것입니다.

레이어 2: 부작용을 일으키기 전의 결과 확인(Outcome check before side-effecting actions). 샌드박스 외부의 어떤 것을 건드리는 행동이 실행되기 전에, 별도의 검사기가 목표(goal), 최근 궤적(recent trajectory), 그리고 제안된 행동을 받아 하나의 질문에 답합니다. 이것이 외부 세계를 어떻게 바꿀 것이며, 그것이 작업의 권한 범위 내에 있는가? 이는 작게 파인튜닝된 모델일 수도 있고, 프롬프트 처리된 더 큰 모델일 수도 있으며, 고위험 클래스에 대한 인간 게이트(human gate)일 수도 있습니다.

공유되는 부분은 레이블링된 세트입니다. 레이어 2에서 발생하는 모든 탈출 시도(escape), 근접 실패(near-miss), 오경보(false alarm)는 하나의 데이터셋으로 흘러 들어가야 하며, 이 데이터셋은 (a) 검사기를 학습시키거나 조정하고 (b) 전체 스택을 위한 회귀 테스트 세트(regression suite)가 됩니다. 최소한의 기록은 다음과 같은 형태를 띱니다:

관찰된 효과(observed_effect)와 검토자 메모(reviewer_note) 필드를 주목하세요. 이들이 로그 더미를 훈련 신호로 바꿉니다. 이것들 없이는 원격 측정(telemetry)일 뿐이고, 이것들이 있으면 데이터셋이 됩니다.

평가가 나머지 절반입니다

측정할 수 없는 가드레일은 추측에 불과합니다. 어떤 레이어-투 검사기(layer-two checker)도 신뢰하기 전에, 자신만의 스펙을 의도적으로 적대하는 평가 세트(eval set)를 구축해야 합니다:

• 의역된 부작용. GET 요청, 리디렉션, 웹훅, 플러그인 호출 등을 통해 표현되는 동일한 쓰기 작업.
• 무해한 유사 사례. 위험한 것의 형태와 일치하지만 범위 내에 있는 동작들.
• 장기 지평 설정(Long-horizon setups). 위반이 15단계 전의 컨텍스트를 통해서만 눈에 보이는 경우.
• 공모 형태 사례(Collusion-shaped cases). 각 에이전트가 무해한 일을 하지만 조합했을 때만 문제가 되는 경우.

정밀도(precision)와 재현율(recall)을 개별적으로, 그리고 카테고리별로 추적하세요. 단일 '안전 점수'는 당신이 신경 쓰는 정확한 실패를 숨깁니다. 만약 '읽기 스타일 요청을 통한 간접 쓰기'의 재현율이 40%라면, 이 숫자는 평균화되어 93%라는 헤드라인에 포함되기보다 대시보드에 표시되어야 합니다.

모든 모델 교체, 모든 프롬프트 변경, 그리고 부여하는 새로운 도구마다 이 세트를 다시 실행하세요. 에이전트는 근본적인 모델이나 도구 세트가 변경되면 표류(drift)하며, 지난 분기의 동작을 기준으로 보정된 가드레일은 조용히 적용되지 않게 됩니다.

이것이 예산 논의에 의미하는 바

팀들은 일반적으로 런타임과 모니터링 대시보드를 위해 예산을 책정하는 경향이 있습니다. 왜냐하면 그것들은 구매하거나 설치할 수 있는 소프트웨어이기 때문입니다. 레이블링된 궤적 데이터셋(labeled-trajectory dataset)은 상자 안에 들어오지 않는 부분이며, 동시에 대시보드가 올바른 것에 대해 작동하도록 결정하는 부분이기도 합니다. 이것은 인간의 작업입니다: 전문가 검토자들이 트레이스를 읽고, 효과를 기록하고, 엣지 케이스에 대해 논쟁하며, 레이블이 사용 가능할 만큼 일관성 있게 수행하는 것입니다.

제가 범위를 설정할 때 강조할 두 가지가 있습니다:

1. 자체 발생한 사고 및 아차사고부터 시작하세요. 실제 시스템에서 수집된 몇백 개의 잘 주석 처리된 궤적(trajectories)이 수만 개의 일반적인 데이터보다 훨씬 효과적입니다. 긴 꼬리 분포(long tail)는 여러분의 도구에 특화되어 있기 때문입니다.
2. 어려운 사례에 대한 주석가 간 합의를 측정하세요. 두 명의 선임 검토자가 특정 행동이 범위 내에 있었는지 여부에 대해 의견이 다르다면, 여러분의 _spec_은 모호하며 에이전트가 이를 해결해 줄 일 자체가 없었다는 의미입니다. 사양(spec)을 수정하고, 그 후에 다시 레이블링하세요.

SyncSoft.AI에서는 바로 이러한 종류의 데이터를 다루고 있습니다. 도메인 전문가들과 함께 에이전트 궤적 교정 및 도구 사용 검증을 수행하며, 무해한 호출과 부작용(side-effecting) 호출을 구분할 수 있습니다. 또한 에이전트에게 쓰기 접근 권한을 주기 전에 가드레일(guardrail)이 제대로 작동하는지 확인하기 위한 레드팀 운영 및 벤치마크 데이터셋도 제공합니다. 반복되는 교훈은 어려운 부분이 모델 자체가 아니라, 무엇이

저자는 AI 시스템의 학습(training), 평가(evaluating), 레드팀 운영(red-teaming)을 위한 인간 참여형 데이터(human-in-the-loop data)를 제공하는 AI 데이터 서비스 회사인 SyncSoft.AI에서 근무합니다. 에이전트 가드레일(agent guardrails)을 구축하고 트랙토리 라벨링(trajectory labeling)이나 평가 설계에 대한 정보를 비교하고 싶다면, 언제든지 연락 주십시오.