Fable 5 논란, 보안 AI의 허용선

문제는 jailbreak였나, 방어 루프였나

The Register 보도는 Fable 5 논란의 핵심을 다르게 해석한다. 보도에 따르면 연구자 케이티 무수리스는 문제의 요청이 복잡한 jailbreak가 아니라 단순한 fix this code에 가까웠다고 주장했다. 모델이 취약점을 찾고, 고치고, 테스트하는 루프를 수행한 것을 위험 신호로 본 셈이다.

이 논쟁은 Anthropic 하나의 문제가 아니다. 보안 AI는 공격과 방어가 같은 기술을 공유한다. 취약점 설명, 익스플oit 가능성 분석, 패치 코드 작성, 회귀 테스트 생성은 공격자도 쓸 수 있지만 방어자에게도 필수다.

보안 정책은 이중용도를 피할 수 없다

OWASP Top 10 for LLM Applications은 과도한 에이전시, 민감정보 노출, 프롬프트 인젝션 같은 위험을 다룬다. 하지만 보안 도구가 모든 취약점 분석을 막으면 실제 방어 업무가 망가진다. CVE 프로그램이 취약점 공개와 식별 체계를 만든 이유도 정보를 숨기기보다 관리하기 위해서다.

NIST AI Risk Management Framework는 AI 위험을 식별, 측정, 관리, 거버넌스의 반복 과정으로 본다. 보안 모델도 단순 허용과 차단을 넘어 사용자 역할, 대상 시스템 소유권, 실행 환경을 함께 판단해야 한다.

방어자를 막는 모델은 현장에 못 들어간다

기업 보안팀이 원하는 것은 완전히 순한 챗봇이 아니다. 로그를 읽고, 취약한 함수를 찾고, 패치를 제안하고, 테스트를 돌리는 조수다. 이 과정이 막히면 보안 AI는 보고서 요약기 이상이 되기 어렵다. Anthropic 보안 하네스, 취약점 대응을 제품화하다는 보안 루프를 제품으로 묶는 흐름을 다뤘다.

Fable 경고, 보안 AI의 허용선을 묻다는 같은 논쟁의 앞선 신호였다. 이번 보도는 허용선이 너무 좁아질 때 생기는 역효과를 보여준다. 모델이 취약점 수정을 거부하면 방어자는 더 약한 도구나 비공식 우회로로 이동한다.

한국 보안팀의 운영 원칙

한국 기업과 공공기관은 보안 AI를 도입할 때 세 가지를 분리해야 한다. 첫째, 소유한 코드와 시스템에 대한 방어 작업은 넓게 허용한다. 둘째, 제3자 대상 공격 자동화는 엄격히 제한한다. 셋째, 모든 실행은 샌드박스와 감사 로그 안에 둔다. OpenAI Agents SDK 하네스와 샌드박스가 말한 실행 통제는 보안 AI에서 특히 중요하다.

또한 프롬프트 문구만으로 위험을 판단하면 안 된다. fix this code는 정상 업무일 수 있고, 겉보기에 평범한 질문도 실제 공격 체인의 일부일 수 있다. 정책은 문장보다 사용자 권한, 대상 자산, 실행 가능성, 출력의 구체성을 함께 봐야 한다.

자주 묻는 질문

Q1: Fable 5 논란의 핵심은 무엇인가요?

A: 모델이 취약점을 찾고 고치는 요청을 수행한 것이 위험한 jailbreak인지 정상 방어 업무인지에 대한 해석 차이다.

Q2: 보안 AI는 왜 어려운가요?

A: 공격과 방어가 같은 지식과 도구를 공유하기 때문에 단순 차단 규칙으로는 현장 요구를 만족시키기 어렵다.

Q3: fix this code 요청은 위험한가요?

A: 맥락에 따라 다르다. 소유한 코드의 패치라면 방어 업무지만, 제3자 공격 준비라면 위험할 수 있다.

Q4: 기업은 어떻게 통제해야 하나요?

A: 사용자 권한, 대상 자산, 샌드박스 실행, 감사 로그, 속도 제한을 함께 설계해야 한다.

Q5: 한국 보안팀에 가장 중요한 점은 무엇인가요?

A: 모델 거부율을 낮추는 것보다 방어 루프를 안전한 실행 환경에 넣는 것이 더 중요하다.