하루 전, 저는 Claude Fable 5가 출시되었지만 아직 사용해 보지 못했다고 글을 썼습니다. 그리고 이를 통해 실제 결과물을 만들어내면 후속 글을 쓰겠다고 약속했습니다. 이것이 바로 그 후속 글입니다. 그리고 결과는 제가 예상했던 대로 흘러가지 않았습니다.

Fable 5를 위한 저의 첫 번째 실제 작업은 일상적인 것이었습니다. 바로 제 자신의 앱을 보안 버그(security bugs)에 대해 검토하는 것이었습니다. 익스플로잇 개발(exploit development)이나 공격적인 작업이 아니라, 그저 _"내 코드를 읽고 어디에 구멍이 있는지 알려달라"_는 것이었습니다. 프로덕션(production)에 배포하기 전에 제가 수행하는 검토 방식과 같습니다.

Fable 5는 요청 자체를 차단(flagged)했습니다.

실제로 일어난 일

검토 대신, 저는 안전 경고(safety notice)를 받았습니다. Fable 5의 안전 조치(safety measures)가 제 메시지를 차단한 것입니다. 배너에는 그 이유가 매우 솔직하게 명시되어 있었습니다. 현재 이 조치들은 "의도적으로 광범위하게(intentionally broad)" 설정되어 있으며, 안전하고 일상적인 프로그래밍, 사이버 보안(cybersecurity), 또는 생물학(biology) 관련 작업을 차단할 수 있다는 것이었습니다. 이는 의도적인 트레이드오프(trade-off)로 설명되었습니다. 즉, 광범위한 가드레일(guardrails)을 통해 더 강력한 기능을 더 빨리 출시하고, 개선 작업은 추후에 진행하겠다는 전략입니다.

그다음 제가 예상하지 못한 일이 일어났습니다. 시스템이 조용히 저를 Opus 4.8로 전환시켰고, 해당 모델은 검토를 수행했습니다. 저는 차단된 것이 아니라, 경로가 재지정(rerouted)된 것이었습니다.

이 디테일은 차단(flag) 자체보다 더 중요합니다. 실패 모드는 단호한 "거절"이 아니라, 안전 계층(safety layer)이 이러한 종류의 작업을 신뢰할 수 있는 모델로 우아하게 다운그레이드(graceful downgrade)하는 방식이었습니다. 제 작업은 여전히 완료되었지만, 제가 선택한 모델이 수행하지 않았을 뿐입니다.

왜 보안 검토가 모델에게 무섭게 보이는가

여기 불편한 사실이 있습니다. 토큰(token) 수준에서 _"내 코드에서 보안 구멍을 찾아줘"_와 _"다른 사람의 코드에서 보안 구멍을 찾아줘"_는 거의 동일하게 보입니다. 차이점은 의도(intent)에 있는데, 의도는 모델이 완전히 소유하지 못한 컨텍스트(context)에 존재합니다. 즉, 이 앱이 누구의 것인지, 발견된 내용을 가지고 무엇을 할 것인지, 그리고 제가 그것을 다룰 권한이 있는지와 같은 정보들입니다.

광범위한 가드레일을 가진 초기 모델은 이러한 모호함을 보수적으로 해결합니다. 모델은 정당한 감사(audit)와 구분할 수 없는 정찰(recon) 작업에 초록불을 켜주기보다는, 차라리 정당한 감사를 차단하는 쪽을 택합니다. 모델의 생애 초기 단계에서는 그것이 정직한 기본 설정입니다. 사용자 입장에서는 짜증 나는 일이지만, 정직한 방식입니다.

이것은 에이전트 도구(agent tooling)를 구축하는 동안 계속 부딪히는 동일한 경계 문제입니다. 어려운 부분은 거의 '가드레일(guardrail)' 자체가 존재하는 것이 아닙니다. 어려운 부분은 둘 다 같은 표면 텍스트를 생성할 때, 일상적인 작업과 실제 위험을 구분해내는 것입니다. 이것은 더 큰 키워드 차단 목록이 아니라, 맥락(context)과 출처(provenance)로 해결합니다. 누가 요청하는지, 어떤 리소스를 대상으로 하는지, 그리고 어떤 권한으로 요청하는지를 말입니다. 모델 프롬프트만으로는 충분한 정보를 담고 있는 경우가 드물기 때문에, 모델은 신중하게 행동합니다.

제가 얻은 교훈

경험을 통해 몇 가지 실질적인 메모를 남깁니다:

• 대체 모델(fallback model)을 연결해 두세요. 이번 테스트에서 가장 좋았던 점은 막다른 길에 다다르지 않았다는 것입니다. Opus 4.8로 전환함으로써 작업이 계속될 수 있었습니다. 만약 스택이 하나의 모델에 고정되면, 광범위한 가드레일은 우회로가 아니라 완전한 중단(hard stop)이 됩니다.
• 무해한 작업을 명확하게 구성하세요. 저는 필터를 통과시키려고 무언가를 몰래 하려 한 것이 아니었지만, 이 교훈은 일반화됩니다. 실제 작업과 실제 범위를 설명해야 합니다. 단순히 '취약점을 찾아라(find exploits)'라고 하는 것보다 '내 앱을 검토해 줘(Review my app)'가 더 큰 무게를 가집니다. 같은 의미를 전달하더라도 말입니다.
• 시간이 지나면서 느슨해지기보다, 더욱 엄격해질 것이라고 예상하세요. 배너에는 현재는 가드레일이 광범위하다고 나와 있었습니다. 그것은 스냅샷일 뿐 영구적인 상태가 아닙니다. 만약 새로운 모델의 거부(refusal)를 첫 주에 벤치마킹한다면, 나중에 재테스트해야 합니다. 경계는 움직입니다.
• 플래그는 판결이 아니라 데이터입니다. 플래그 처리되었다는 것은 이 모델의 현재 선이 어디에 위치하는지에 대해 유용한 정보를 알려주었습니다. 이것은 제가 이 모델을 전체 작업군에 의존하기 전에 알아두면 가치가 있습니다.

솔직한 평가

그래서, Fable 5를 사용해 볼 수 있었나요? 어쩌다 보니요. 저는 그 안전 계층이 판단을 내리는 것을 지켜보았고, Opus 4.8로부터 검토 결과를 받았습니다. 계획했던 정면 대결(head-to-head)은 아니었지만, 깨끗한 벤치마크보다 더 흥미로운 첫 접촉이었습니다.

광범위하게 적용한 뒤 정교화하는 방식(Broad-then-refined)은 프런티어 모델(frontier model)을 출시하는 합리적인 방법입니다. 저는 새로운 모델이 보안 작업에 대해 과도하게 조심스러워하다가 시간이 지나며 더 날카로워지는 편이, 그 반대의 상황보다 낫다고 생각합니다. 마찰(friction)은 실제로 존재하지만, 대체 수단(fallback) 덕분에 견딜 만했습니다. 그리고 제가 왜 플래그(flagged)되었는지에 대한 투명성은 제가 실제로 높게 평가하는 부분입니다.

계속해서 테스트를 이어가겠습니다. 다음번에는 Fable 5가 의심할 이유가 전혀 없는 내용을 전달하여, 가드레일(guardrails)이 핵심 이슈가 아닐 때 모델이 어떻게 작동하는지 살펴보겠습니다.

본인의 셀프 호스팅 스택(self-hosted stack)에서 직접 작성 및 게시되었습니다.

ai #anthropic #claude #devtools