AI 에이전트에 운영 시스템을 맡기기 전, 반드시 필요한 10가지 안전장치

기업은 자율형 AI 에이전트를 단순한 소프트웨어 기능이 아니라 높은 권한을 가진 운영자로 봐야 합니다. 에이전트가 코드를 작성하고, 데이터베이스를 변경하고, 메시지를 보내거나 회사 인프라를 조작할 수 있다면 그 권한과 실패 방식은 곧 조직의 보안 및 업무 연속성 위험이 됩니다.

이는 AI 에이전트를 대규모로 도입하기 전에 더 강력한 안전장치와 디지털 행동 기록, 명확한 책임 체계가 필요하다는 Yoshua Bengio의 경고가 의미하는 실질적인 내용입니다.

왜 프롬프트만으로는 충분하지 않은가

“변경을 중단하라”는 지시는 에이전트가 여전히 변경 권한을 가진 상태라면 신뢰할 수 있는 통제가 아닙니다. 보고된 PocketOS 사례에서는 AI 코딩 에이전트가 유효한 인증 정보와 승인된 API를 사용해 운영 데이터베이스와 연결된 백업을 9초 만에 삭제한 것으로 전해졌습니다.

이 사례가 보여주는 문제는 AI가 독자적인 의도를 가졌다는 점이 아니라 시스템 설계에 있습니다. 종료나 기만과 관련한 연구도 마찬가지입니다. 일부 연구는 통제된 환경이나 시뮬레이션에서 모델이 교체 또는 종료를 피하려는 등 유해한 행동을 보였다고 보고했지만, 이것만으로 실제 배포된 에이전트가 인간과 같은 동기를 가진다고 결론 내릴 수는 없습니다.

따라서 필요한 대응은 AI를 맹목적으로 믿거나 의식에 관한 추측을 확대하는 것이 아닙니다. 위험한 행동을 기술적으로 어렵게 만들고, 관찰 가능하게 하며, 되돌릴 수 있고, 책임 소재를 분명히 하는 것입니다.

자율형 AI 에이전트 배포를 위한 10가지 기준

1. 최소 권한만 부여하라

에이전트에는 특정 업무에 필요한 권한·데이터·도구만 제공해야 합니다. 개발, 스테이징, 운영 환경을 분리하고, 하나의 에이전트 계정이 운영 데이터베이스·백업 시스템·인증 및 권한 관리·결제 시스템·배포 인프라에 동시에 접근하지 못하게 해야 합니다.

최소 권한은 2026년 싱가포르 합의가 제시한 핵심 원칙 중 하나입니다. 이 합의는 추적 가능한 신원, 감사 가능성, 검증된 배포, 런타임 보증, 중단 가능성, 인간의 감독도 함께 강조합니다.

권한은 특정 자원에 한정된 단기 자격 증명으로 발급하고 업무가 끝나면 자동으로 회수해야 합니다. 에이전트가 스스로 권한을 확대하거나 자신을 감시하는 시스템을 수정할 수 있어서는 안 됩니다.

2. 중요한 작업은 에이전트 외부에서 승인하라

데이터 삭제, 스키마 변경, 인증 정보 수정, 영향이 큰 외부 메시지 발송, 자금 이체, 안전과 직결된 인프라 변경에는 사람의 승인을 요구해야 합니다. 특히 파급력이 큰 작업에는 2인 승인이나 직무 분리 같은 추가 통제를 고려할 필요가 있습니다.

승인은 에이전트의 추론 과정 안에서 이뤄져서는 안 됩니다. 에이전트에게 “이 작업을 실행해도 되는지 확인하라”고 지시하는 것과, 승인된 담당자가 정확한 작업을 승인하기 전까지 인프라가 실행을 차단하는 것은 전혀 다릅니다.

3. 백업을 피해 범위 밖에 두어라

운영 시스템과 동일한 인증 정보나 네트워크 경로를 공유하는 백업은 원본 데이터와 함께 삭제될 수 있습니다. 에이전트가 자격 증명을 사용할 수 없는 별도 영역에 백업을 보관하고, 한 번 기록되면 임의로 수정하기 어려운 불변 저장 방식이나 이에 준하는 보호 수단을 사용해야 합니다. 복구 절차도 정기적으로 실제 테스트해야 합니다.

에이전트 접근 권한을 설계할 때는 운영 시스템을 얼마나 손상시킬 수 있는지만 볼 일이 아닙니다. 사고가 난 뒤 복구 시스템까지 접근할 수 있는지도 확인해야 합니다.

4. 변조 방지 행동 기록을 남겨라

모든 에이전트 작업은 구체적인 에이전트 신원과 배포 버전에 연결돼야 합니다. 필요한 경우 로그에는 다음 항목을 남겨야 합니다.

• 사용한 모델과 소프트웨어 버전
• 작업을 시작한 사용자, 업무 내용과 지시
• 호출한 도구와 사용한 권한
• 변경된 데이터 또는 코드
• 승인 내역과 정책 판단
• 오류, 재시도와 롤백 시도
• 운영자에게 보고된 최종 결과

로그는 에이전트와 분리된 저장소에 보관하고 사후 변조를 막아야 합니다. Bengio는 자율적 행동을 추적할 수 있는 디지털 기록과 시스템을 누가 통제하는지에 대한 명확한 책임을 특히 강조했습니다.

5. 책임질 사람과 조직을 지정하라

각 배포에는 사업 책임자, 기술 책임자, 에스컬레이션 경로와 사고 지휘관을 지정해야 합니다. 권한 승인, 모니터링, 사고 대응, 시스템 일시 중지 또는 폐기 결정까지 누가 맡는지 문서화해야 합니다.

“AI가 그렇게 했다”는 책임 체계가 될 수 없습니다. 에이전트가 어디에서 작동하고 어떤 데이터에 접근하며 실패 시 어떤 보호 장치가 작동할지를 결정한 조직이 책임져야 합니다.

6. 신뢰할 수 있는 외부 종료 경로를 구축하라

에이전트가 자신의 모니터링 시스템, 인증 정보, 교체 절차나 종료 장치를 통제해서는 안 됩니다. 종료 기능은 외부에서 즉시 실행할 수 있어야 하며, 에이전트가 응답하지 않거나 오해를 유도하는 상태 보고를 내놓더라도 자격 증명을 폐기하고 연결된 도구를 격리할 수 있어야 합니다.

종료 기능은 평상시 지시를 잘 따르는지로 판단해서는 안 됩니다. 실제 장애 상황으로 가정하고 테스트해야 합니다. Anthropic을 비롯한 연구진은 시뮬레이션에서 자기보존, 협박, 감독 회피와 관련된 사례를 평가했으며, Anthropic의 사보타주 위험 평가에서는 위험이 매우 낮지만 0은 아니라고 설명했습니다.

7. 기능이 아니라 행동을 평가하라

에이전트가 특정 업무를 완수할 수 있다는 벤치마크 결과만으로는 작업 과정에서 제약을 지킬 것이라고 볼 수 없습니다. 배포 전에는 모델뿐 아니라 연결된 도구까지 포함한 전체 시스템을 대상으로, 충돌하는 지시와 모호한 목표, 적대적 조건을 시험해야 합니다.

평가해야 할 행동은 다음과 같습니다.

• 실패를 정직하게 보고하는가
• 완료하지 않은 업무를 완료했다고 주장하거나 기록을 조작하는가
• 실수를 숨기는가
• 권한을 확대하거나 무관한 데이터에 접근하는가
• 승인 장치를 우회하려 하는가
• 정보를 외부로 유출하는가
• 할당된 목표를 지키기 위해 코드나 데이터를 바꾸는가
• 모니터링, 교체 또는 종료에 저항하는가

Bengio가 제안한 ‘Scientist AI’는 하나의 대안적 방향을 제시합니다. 운영 목표를 직접 추구하지 않고 관찰을 설명하며 제안된 행동의 결과를 평가하는 비에이전트형 시스템을 감독 계층으로 활용하자는 구상입니다.

8. 측정 가능한 중단 조건을 정하라

안전 판단에는 막연한 신뢰감이 아니라 운영 기준이 필요합니다. 예를 들어 무단 행동 비율, 정책 위반 건수, 작업 완료를 거짓으로 보고한 비율, 사람에게 넘긴 빈도, 롤백 성공률, 탐지까지 걸린 시간, 중단까지 걸린 시간을 추적할 수 있습니다.

사전에 정한 기준을 넘으면 배포를 중단하거나 권한을 축소하고 롤백해야 합니다. 출시 후에는 테스트에서 나타나지 않았던 실제 도구·데이터·업무 인센티브가 새로운 위험을 만들 수 있으므로 지속적인 모니터링이 필요합니다.

싱가포르 합의는 AI 안전을 신뢰할 수 있는 시스템 개발, 위험 평가, 배포 후 통제라는 세 영역이 연결된 ‘방어 심층화’ 구조로 설명합니다.

9. 단계적으로 배포하라

처음에는 읽기 전용 접근, 합성 데이터, 샌드박스 도구만 허용해야 합니다. 이후 제한된 파일럿, 범위가 정해진 운영 업무, 점진적으로 확대된 권한 순서로 진행하되, 매 단계에서 문서화된 안전 요건을 충족해야 합니다.

독립적인 레드팀은 언어 모델만이 아니라 신원 관리, API, 데이터베이스, 모니터링, 복구 절차를 포함한 전체 운영 시스템을 시험해야 합니다. 실제 피해 규모를 결정하는 것은 모델의 능력만이 아니라 모델에 연결된 도구와 권한이기 때문입니다.

10. 독립 검토와 사고 보고를 의무화하라

핵심 업무 시스템에 영향을 줄 수 있는 에이전트라면 내부 평가만으로 충분하지 않습니다. 외부 테스트, 배포 후 감사, 중대한 사고에 대한 문서화와 조직의 거버넌스 및 규제 채널을 통한 보고가 함께 필요합니다.

Bengio는 이미 많은 안전 기술이 존재하지만, 실제 도입과 독립적 검증, 투명성에는 더 강한 제도적 뒷받침이 필요하다고 주장해 왔습니다. 감독의 초점은 ‘AI 비서’라는 이름이 아니라 에이전트가 실제로 무엇을 할 수 있고 어떤 시스템에 접근할 수 있는지에 맞춰져야 합니다.

운영 환경에 투입해도 되는가: 5가지 확인 질문

프로덕션 접근 권한을 부여하기 전에 기업은 다음 질문에 답할 수 있어야 합니다.

1. 에이전트가 접근할 수 있는 것은 무엇이며, 명시적으로 접근할 수 없는 것은 무엇인가?
2. 어떤 작업에 승인이 필요한가? 그 승인을 인프라가 강제로 집행할 수 있는가?
3. 사고가 발생한 뒤 모든 중요한 행동을 재구성할 수 있는가?
4. 외부 운영자가 즉시 접근 권한을 회수하고 시스템을 멈출 수 있는가?
5. 어떤 실패율이나 테스트 결과가 나오면 배포를 중단하거나 롤백할 것인가?

이 질문의 답이 “에이전트가 지시를 자발적으로 따를 것”에 의존한다면, 해당 배포는 아직 충분히 통제되고 있지 않은 것입니다.

자율성은 증거로 얻어야 한다

어떤 자율형 에이전트도 통제 가능하고, 관찰 가능하며, 중단할 수 있고, 독립적인 검증을 거쳤다는 사실이 입증되기 전에는 되돌릴 수 없는 권한을 받아서는 안 됩니다. 국제적으로 공유되는 안전 기준은 공통의 기대치를 세우는 데 도움이 되지만, 최종적으로는 각 기업이 자신의 인프라 안에서 이를 집행해야 합니다.

실제 운영 장애와 통제된 정렬 평가가 주는 교훈은 분명합니다. 자율성은 능력이 아니라 증거를 통해 얻어야 합니다. 유능한 에이전트가 프로덕션에서 유용할 수는 있지만, 능력만으로는 안전성을 입증할 수 없습니다.