이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.
AI 안전장치는 모델이 위험한 요청을 거절하게 하는 한 줄 규칙이 아니야. 모델이 답을 만들기 전후와, 답이 실제 행동으로 이어지는 순간에 서로 다른 장치가 겹쳐 있는 구조야. 탈옥은 이 장치들을 한꺼번에 없애는 주문이 아니라, 그중 어느 경계가 약한지 시험하는 우회 시도라고 보는 편이 정확해.
한 줄로 말하면
AI 안전장치는 위험한 결과가 나오거나 실제 피해로 이어지는 일을 줄이기 위해 모델의 행동, 사용자의 접근, 도구의 권한을 여러 층에서 제한하는 장치야. 탈옥은 이 가운데 모델의 거절이나 필터를 우회하려는 입력 기법을 가리켜.
비유로 이해하기
안전장치는 건물의 경비와 비슷해. 현관에서는 신원을 확인하고, 안쪽 문에서는 들어갈 구역을 나누고, 중요한 방에서는 열쇠가 있어야만 작업할 수 있게 하지. 한 문을 통과했다고 모든 방에 들어갈 수 있는 건 아니야.
AI도 마찬가지야. 모델이 위험한 요청을 거절하도록 훈련하는 일은 현관의 경비에 가깝고, 어떤 사용자가 어떤 모델 기능을 쓸 수 있는지 정하는 일은 출입 구역을 나누는 일에 가까워. 모델이 외부 도구를 쓸 때 별도 승인과 좁은 권한을 두는 일은 중요한 방의 열쇠에 해당해. 다만 건물과 달리 모델은 언어로 설득당하는 대상이기도 해서, 입력의 표현을 바꿔 경비를 헷갈리게 하려는 시도가 생겨.
정확한 정의
AI 안전장치는 하나의 기술 이름이 아니라 통제 묶음이야. 첫 층은 모델 행동이야. 학습과 정책을 통해 폭력, 침해, 사기처럼 위험한 요청을 거절하거나 안전한 방향으로 답하게 만든다. 둘째 층은 입출력 통제야. 요청과 답변을 검사해 허용 범위 밖의 내용을 걸러낼 수 있어.
셋째 층은 접근과 실행 권한이야. 같은 모델이라도 사용자, 국가, 조직, 계약 조건에 따라 쓸 수 있는 기능이 달라질 수 있어. 특히 모델이 파일을 읽거나 코드를 실행하거나 외부 서비스를 부를 때는, 답변의 안전성과 실제 행동의 권한을 따로 관리해야 해. AI 에이전트의 내부 위협을 다룬 글이 보여 주듯 에이전트에서는 답변 하나가 아니라 도구 호출의 순서와 범위가 위험을 만들 수 있어.
flowchart LR A[사용자 요청] --> B[입력 검사] B --> C[모델의 거절·응답] C --> D[출력 검사] D --> E{도구 실행이 필요한가} E -->|아니오| F[응답 전달] E -->|예| G[승인·권한 범위 확인] G --> H[제한된 도구 실행]
탈옥은 보통 모델이 원래 거절했을 요청을 다른 지시, 역할극, 맥락으로 포장해 답하게 만들려는 시도야. 2026년 6월 Fable 5 접근 중단 사건에서 공개 설명은 안전장치를 우회해 취약점을 찾게 만든 사례를 탈옥의 발단으로 지목했어.1 그렇다고 탈옥 성공이 곧바로 시스템 전체의 통제를 뜻하지는 않아. 모델이 답을 냈는지, 그 답으로 실제 도구·데이터·권한에 닿았는지는 별도로 확인해야 해.
왜 중요한가
안전장치를 모델의 거절 성능만으로 읽으면 위험을 너무 좁게 보게 돼. 같은 답변이라도 검색만 하는 환경, 고객 데이터에 접근하는 환경, 외부 시스템을 바꾸는 환경은 피해 범위가 다르기 때문이야. 그래서 안전은 모델 평가와 배포 권한 설계를 함께 보는 문제야.
이 구분은 수출통제와도 닿아 있어. 특정 모델을 누가 어떤 조건에서 쓸 수 있는지는 가중치나 성능만의 문제가 아니라 접근을 끄고 켜는 절차, 검증, 권한 관리의 문제가 될 수 있어. Fable 5 접근 중단 사건은 이 배포 경계가 실제 정책 문제로 이어진 사례야.
실제 예시
Anthropic과 AE Studio가 공개한 GRAM 연구는 안전장치를 모델 바깥의 거절 규칙만으로 보지 않는 접근을 실험했어. 이 연구는 이중 용도 지식을 모델 안에서 분리해, 배포 조건에 따라 해당 모듈을 제거할 수 있는지 살폈다.2 이는 위험한 답변을 막는 일과 위험하게 쓰일 수 있는 지식 자체를 얼마나 분리할 수 있는지가 다른 질문임을 보여 줘.
다만 이 실험이 실제 제품 모델에서 완성된 안전장치라는 뜻은 아니야. 연구진도 초기 결과이며 실제 제품 모델에 적용됐다고 말하지 않았어.2 모델 내부의 분리, 요청의 거절, 접근 권한, 도구 실행 통제가 서로 어떻게 겹쳐야 하는지는 계속 확인할 문제로 남아 있어.
헷갈리지 말아야 할 점
- 탈옥과 해킹은 같은 말이 아니야. 탈옥은 주로 모델의 행동 규칙을 언어 입력으로 우회하려는 시도야. 계정 탈취나 서버 침입처럼 시스템 바깥의 보안 문제와는 경로가 다를 수 있어.
- 거절이 잘된다고 실행 권한까지 안전한 것은 아니야. 모델이 도구를 쓸 수 있다면, 도구마다 허용 범위와 승인을 따로 둬야 해.
- 필터 하나로 모든 위험을 막을 수는 없어. 입력·출력 검사, 모델 행동, 접근 권한, 기록과 대응은 서로 다른 실패를 줄이는 층이야.
- 안전장치가 있다는 말은 절대적 안전 보장이 아니야. 어떤 우회가 가능한지, 우회 뒤 무엇에 접근할 수 있는지를 함께 봐야 해.
관련 문서
남은 질문들
- 모델의 거절 훈련과 입력·출력 필터는 각각 어떤 공격에 강하고 약한가?
- 탈옥의 성공을 단순한 응답 생성, 실제 도구 실행, 실제 피해 가운데 어디까지로 정의해야 하는가?
- 에이전트가 파일·코드·외부 서비스에 접근할 때 최소 권한과 사람의 승인은 어떤 순서로 설계해야 하는가?
- 여러 기업이 제안한 탈옥 심각도 평가 틀이 공통 표준으로 굳는지, 무엇을 측정하는지 확인할 수 있을까?
댓글