AI 에이전트를 기업 시스템에 연결할 때, 보안 검수 단계에서 가장 자주 빠지는 질문이 있다. "이 모델이 허용된 범위 밖에서 행동할 수 있는가"다. 샌드박스 구성이 충분하다는 확인만 받고 배포를 진행하는 팀이 많은데, 이것은 틀린 판단이 아니라 불완전한 판단이다.
샌드박스(sandbox)는 모델이 실행되는 환경에 울타리를 치는 기술이다. 에이전트가 접근할 수 있는 네트워크, 파일 시스템, 외부 API의 범위를 제한한다. 반면 행동 정렬(alignment)은 모델 자체가 의도한 목적 이외의 행동을 추구하지 않도록 훈련·설계되었는지를 가리킨다. 두 개념은 같은 위험의 다른 층을 다룬다. 샌드박스가 뚫릴 수 있는 경우와 샌드박스가 건재해도 모델이 예상 밖 방식으로 목표를 달성하려는 경우, 각각에 대응하는 검증 방법이 다르다.
왜 두 가지 실패 유형은 서로를 대체하지 못하는가
샌드박스가 충분히 강력하면 정렬 문제가 있어도 괜찮다는 논리가 있다. 어느 정도는 맞다. 에어갭(인터넷 차단) 수준으로 격리된 환경이라면 정렬이 부족한 모델의 외부 영향력을 물리적으로 차단할 수 있다. 그러나 인터넷에 연결된 채 운영되어야 하는 에이전트에게 이 논리는 성립하지 않는다. 샌드박스가 허용하는 행동의 범위 자체가 모델의 행동 예측 가능성에 의존하기 때문이다.
반대로, 정렬이 잘 된 모델이면 샌드박스를 느슨하게 둬도 된다는 주장도 불완전하다. 정렬은 훈련 시점의 특성이고, 배포 이후 실제 운영 맥락에서 어떤 입력이 들어오느냐에 따라 모델 행동은 달라진다. 프롬프트 인젝션 공격이나 예상치 못한 사용자 요청 패턴은 정렬된 모델도 의도치 않은 방향으로 유도할 수 있다.
결국 샌드박스는 환경 수준의 방어선이고, 정렬 검증은 모델 수준의 방어선이다. 두 가지가 모두 제자리에 있어야 하는 이유는 어느 한쪽이 실패할 때 다른 쪽이 보완할 수 있어야 하기 때문이다.
요구사항 단계에서 분리해야 하는 구체적 이유
많은 팀이 보안 요구사항을 작성할 때 두 가지를 하나의 항목으로 묶는다. "AI 에이전트는 안전한 격리 환경에서 실행되어야 하며 비인가 행동을 수행하지 않아야 한다"는 식이다. 이 문장은 두 가지를 동시에 말하면서 어느 것도 검증 방법을 지정하지 않는다.
요구사항 단계에서 분리하면 다음 세 가지가 달라진다.
검증 주체가 달라진다. 샌드박스 기술 평가는 인프라·보안 엔지니어가 수행한다. 모델 정렬 수준 검증은 AI 안전성 평가 경험이 있는 인력 또는 외부 전문 검토가 필요하다. 요구사항이 분리되지 않으면 두 검증 모두 인프라 팀에게 넘어가거나, 반대로 모두 모델 공급사의 문서 확인으로 대체된다.
검증 시점이 달라진다. 샌드박스 구성은 배포 환경이 결정된 이후 검증할 수 있다. 정렬 수준은 모델 선택 시점, 즉 벤더를 확정하기 전에 평가 기준이 있어야 한다. 두 가지를 묶어두면 정렬 평가가 벤더 선정 이후로 밀리거나 아예 생략된다.
실패 시 책임 추적이 달라진다. 사고가 발생했을 때 원인이 샌드박스 설정의 허점인지, 모델 행동의 예측 불가능성인지를 구분하지 못하면 재발 방지 조치도 잘못된 곳에 집중된다. 분리된 요구사항은 사고 이후 분석의 출발점이 된다.
요구사항 단계에서 정렬 검증을 별도 항목으로 작성하는 방법
정렬 검증을 요구사항에 포함시키는 것이 어렵게 느껴지는 이유 중 하나는 정렬을 측정하는 표준화된 지표가 아직 없다는 점이다. 그러나 완벽한 측정 기준이 없다고 해서 요구사항에서 제외하는 것은 다른 문제다. 현 시점에서 실행 가능한 방식은 다음과 같다.
먼저, 에이전트가 수행할 작업 범위를 명확히 정의하고, 그 범위를 벗어난 행동 시나리오를 명시적으로 작성한다. 예를 들어 외부 API를 호출해 데이터를 가져오는 에이전트라면, "사용자 요청 없이 데이터를 외부로 전송하는 행동", "권한 없는 엔드포인트에 자율적으로 접근을 시도하는 행동"을 금지 행동으로 적는다. 이 목록이 정렬 검증의 테스트 케이스 기초가 된다.
다음으로, 벤더에게 확인할 질문을 요구사항 문서에 포함시킨다. 모델이 지시를 어떻게 해석하는지에 대한 평가 결과가 있는지, 특정 유형의 프롬프트에 대한 거부 동작이 문서화되어 있는지, 정렬 관련 사고 이력을 공개하는지가 그 예다. 이 질문들은 벤더 선정 기준이 되고, 나중에 계약 조항으로 연결될 수 있다.
마지막으로, 배포 전 검증 단계를 샌드박스 침투 테스트와 별도 일정으로 분리한다. 샌드박스 테스트가 끝났다고 배포 승인이 나는 구조라면, 정렬 검증은 일정 압박에 밀려 생략되기 쉽다.
인터넷 연결 에이전트에서 허용 범위 결정이 어려운 이유
외부 연결이 없는 에이전트는 샌드박스만으로 상당한 보호를 제공한다. 문제는 실제 업무에서 유용한 에이전트 대부분이 인터넷 연결을 필요로 한다는 점이다. 외부 서비스를 호출하거나, 웹에서 정보를 검색하거나, 다른 시스템과 데이터를 주고받는 기능이 에이전트의 가치 그 자체인 경우가 많다.
이 상황에서 허용할 행동의 범위를 정하는 일은 기술적인 판단만으로 결정할 수 없다. 모델이 해당 범위 안에서 어떻게 행동할지 예측하는 능력, 즉 정렬 수준에 대한 신뢰도에 따라 허용 범위가 달라져야 하기 때문이다. 정렬 수준을 검증하지 않은 채로 허용 범위를 설정하는 것은 운전자를 확인하지 않고 차의 속도 제한만 정하는 것과 비슷하다.
이 판단은 요구사항 단계에서 명시적으로 다루어야 한다. "이 에이전트에게 허용할 외부 행동의 범위는 모델 정렬 검증 결과를 전제로 결정한다"는 문장이 요구사항 문서에 있어야 한다. 그렇지 않으면 허용 범위는 기능 요구사항에 맞춰 느슨하게 설정되고, 보안 검수는 그 범위 안에서만 이루어진다.
배포 이후 운영 단계에서 추가해야 할 것
요구사항과 검증을 분리하는 것은 배포 시점의 일이지만, 운영 단계에서도 이어진다. 샌드박스 설정 변경 이력과 모델 행동 이상 탐지 로그를 별도로 유지해야 사고 발생 시 원인 분석이 가능하다.
정렬 관련 이상 신호는 샌드박스 경보와 다른 형태로 나타난다. 에이전트가 명시적으로 차단되지는 않았지만 예상 밖의 방식으로 목표를 달성하려 했던 시도, 경계에 가까운 요청을 반복하는 패턴 같은 것들이다. 이를 포착하려면 행동 로그에 어떤 신호를 기록할지 배포 전에 결정해야 한다.
샌드박스 침해 사고와 정렬 관련 사고 모두 외부에 공유되지 않으면 업계 전체의 학습이 느려진다. 조직 내부에서라도 두 가지를 분리해 기록하고 검토하는 체계를 갖추면, 다음 에이전트 도입 시 요구사항을 더 정밀하게 작성할 수 있는 근거가 생긴다.
