
Fable 5가 돌아왔다. 하지만 나의 번역 워크플로우는 예전으로 돌아가지 않는다.
요약
Anthropic의 Fable 5 모델 사용 중단과 복구 과정을 통해, 특정 AI 모델의 미묘한 특성이 작업 워크플로우에 미치는 의존성을 분석합니다. 모델의 성능 차이가 단순한 오류가 아닌 결과물의 정서적 깊이와 판단 품질에 미치는 영향을 다룹니다.
핵심 포인트
- 특정 모델의 미묘한 스타일과 정서적 포착 능력이 워크플로우의 핵심이 될 수 있음
- 모델 의존성은 API 실패처럼 명시적이지 않고 결과물의 품질 저하로 조용히 나타남
- 단순 번역을 넘어 문학적 은유와 뉘앙스를 유지하는 모델 선택의 중요성
2026년 6월 12일, 나는 내 번역 QA (Quality Assurance) 워크플로우의 절반을 조용히 구축해 온 모델에 대한 접근 권한을 잃었다.
18일 후, 보도에 따르면 미국 상무부(U.S. Department of Commerce)가 Anthropic의 Fable 5와 Mythos 5에 대한 수출 통제를 해제했으며, Anthropic은 7월 1일부터 접근 권한 복구를 시작할 것이라고 했다.
인터넷의 반응은 예측 가능했다: 안도, 밈 (memes), “우리는 돌아왔다(we are so back)”, 그리고 마치 방 안에 산소가 다시 공급된 것처럼 이야기하는 수많은 개발자들.
그 기분을 이해한다. 나 역시 Fable 5가 그리웠다.
하지만 나는 내 워크플로우를 예전 방식으로 되돌리지 않을 것이다.
내가 Fable 5를 사용했던 용도
나는 소프트웨어 엔지니어가 아니라 번역 전공 학생이다. 나는 문학 번역 실험, 용어 확인 (terminology checks), 병렬 비평 (side-by-side critique), 코퍼스 (corpus) 정리, 그리고 오직 CSV 파일이 가혹하기 때문에 존재하는 가끔의 Python 스크립트 작성 등, 묘하게 섞인 작업들을 위해 모델을 사용한다.
18일간의 중단이 있기 전, Fable 5는 매우 특정한 작업에 있어 내가 가장 좋아하는 모델이 되었다:
번역이 기술적으로는 정확하지만 정서적으로는 틀렸을 때 이를 포착하는 데 탁월했다.
다소 추상적으로 들릴 수 있지만, 이는 실제적인 실패 모드 (failure mode)이다.
여기에 내가 작성하는 노트 스타일로 만든 작은 가상의 예시가 있다:
Swedish source:
Han log som om rummet redan hade förlåtit honom.
...
성능이 낮은 모델은 보통 이를 더 매끄럽게 만든다:
He smiled as if everyone in the room had already forgiven him.
이것이 형편없는 것은 아니다. 적절한 맥락이라면 출판이 가능할 수도 있다.
하지만 무언가 상실되었다. 원문은 '방(room)'에 주체성을 부여한다. 그것은 약간 기묘한(uncanny) 느낌을 준다. 더 매끄러운 버전은 은유를 그대로 두는 대신 은유를 설명해 버린다.
Fable 5는 그런 종류의 상실을 포착하는 데 유난히 뛰어났다. 항상 그런 것은 아니었지만, 내가 과도하게 신뢰하기 시작할 정도로 자주 그러했다.
첫 일주일은 짜증스러웠다
접근 권한이 사라졌을 때, 나는 당연한 일을 했다: Fable 5를 사용 가능한 다른 무엇인가로 대체하는 것이었다.
단순한 번역 확인용으로는 괜찮았다. DeepL은 여전히 DeepL이 잘하는 일을 해낸다. 다른 LLM(Large Language Models)들도 여전히 요약하고, 비교하며, 괜찮은 대안들을 만들어낼 수 있다.
문제는 내 워크플로우(workflow)가 멈춘 것이 아니었다.
문제는 내 워크플로우의 어떤 부분들이 특정 모델의 취향에 의존하고 있었는지 구분하기가 더 어려워졌다는 점이었다.
그것은 다른 종류의 의존성이다.
만약 당신의 빌드 파이프라인(build pipeline)이 하나의 API에 의존한다면, 당신은 그 사실을 알게 된다. 그것은 요란하게 실패하기 때문이다.
만약 당신의 판단 파이프라인(judgment pipeline)이 하나의 모델에 의존한다면, 그것은 조용히 실패한다. 결과물은 여전히 나온다. 다만 결과물이 약간 더 평면적으로 느껴지고, 약간 덜 의심스러우며, 첫 번째로 나온 괜찮은 답변을 너무 쉽게 수용하려는 경향을 보일 뿐이다.
내가 예전의 노트들을 가지고 있었기에 겨우 알아챌 수 있었다.
내가 구축한 폴백 스택 (The Fallback Stack I Built)
5일째 되는 날, 나는 Fable 5를 "대체"하려고 노력하는 것을 멈추고 작업을 더 작은 확인 단계로 나누기 시작했다.
결국 내가 사용하게 된 폴백 스택(fallback stack)은 다음과 같다:
1. DeepL
용도: 1차 EU 언어 번역, 특히 실용적인 텍스트.
사용 금지: 문학적인 어조 결정.
...
이것은 "최고의 모델을 사용하라"는 말보다 덜 인상적으로 보일 수 있다.
하지만 더 정직한 방법이다.
내가 다시 사용하기 시작한 프롬프트 (The Prompt I Started Reusing)
중단 기간 동안 내가 작성한 가장 유용한 것은 영리한 번역 프롬프트가 아니었다. 그것은 의존성 프롬프트(dependency prompt)였다.
나는 이제 번역 작업에서 모델을 테스트할 때마다 이것을 실행한다:
당신은 아직 번역을 하지 않습니다.
소스 텍스트를 읽고 어떤 종류의 난이도가 포함되어 있는지 식별하십시오.
...
중요한 문구는 다음과 같다: 최종 번역을 생성하지 마십시오.
모델들은 작업을 끝마치는 것을 좋아한다. 때때로 나는 모델이 속도를 늦추고 이것이 어떤 종류의 작업인지 나에게 말해주기를 원한다.
그 한 가지 변화가 내 워크플로우를 Fable 5에 훨씬 덜 의존하게 만들었다. 모델에게 최종 결정을 내리는 대신 위험 요소를 분류하도록 요청한다면, 더 약한 모델이라도 여전히 유용할 수 있다.
Fable 5의 귀환이 바꾸는 것들
나는 그것을 다시 사용할 것이다. 당연히 그럴 것이다.
만약 Fable 5가 예상대로 7월 1일에 출시된다면, 나는 그것을 다시 나의 실험 과정에 넣을 것이다. 사용하지 않기에는 너무나 유용했기 때문이다.
하지만 그것은 더 이상 나의 기본 판정관 (default judge)이 되지 않을 것이다.
지난 18일 동안 한 가지 사실이 매우 명확해졌다. 당신의 워크플로우 (workflow)에서 가장 뛰어난 모델은, 질문하기를 멈추기에 가장 위험한 모델이기도 하다는 점이다.
그 모델이 나빠서가 아니다.
그 모델이 보이지 않을 정도로 충분히 훌륭하기 때문이다.
트레이드오프 (The Trade-off)
이전의 워크플로우는 더 빨랐다:
원문 (source) → Fable 5 비평 (critique) → 수정 (revision) → 최종 인간 검토 (final human pass)
새로운 워크플로우는 더 느리다:
원문 (source) → 위험 분류 (risk classification) → 여러 모델 통과 (multiple model passes) → 불일치 사항 비교 (compare disagreements) → 최종 인간 검토 (final human pass)
이전의 워크플로우는 우아하게 느껴졌다.
새로운 워크플로우는 더 많은 번거로움을 남긴다.
하지만 새로운 워크플로우는 불확실성이 어디에 있는지를 나에게 보여준다. 지금의 나에게는 그것이 속도보다 더 중요하다.
내가 주시하고 있는 한 가지
수출 통제 (export-control) 이야기는 나의 작은 번역 워크플로우보다 훨씬 더 큰 문제다. Wired, The Verge, Axios 등의 보도에 따르면 보안 위험, 탈옥 (jailbreaks), 그리고 프런티어 모델 (frontier models)에 대한 접근권을 둘러싼 복잡한 협상이 진행 중이라고 한다.
나는 그 기사의 정책 버전을 작성할 자격은 없다.
하지만 사용자로서 이렇게 말할 수 있다. 만약 모델이 18일 동안 사라지는 것이 당신의 업무를 완전히 망가뜨린다면, 그 모델은 단순한 도구가 아니었다. 그것은 인프라 (infrastructure)였다.
그리고 그것이 인프라였다면, 당신에게는 장애 대응 계획 (failure plan)이 필요하다.
설령 당신이 에든버러의 어느 아파트에서 고양이가 키보드 위에 앉으려고 애쓰는 동안 시를 번역하고 있을 뿐이라 할지라도 말이다.
Marmalade는 수출 통제 따위에는 관심이 없었다. 아마 이것이 건강한 상태였을 것이다.
나의 새로운 규칙
나는 이제 간단한 규칙을 지키고 있다:
어떤 모델도 번역가와 판정관의 역할을 동시에 맡을 수 없다.
한 모델이 초안을 작성한다면, 다른 모델이 비평을 해야 한다. 한 모델이 어조(tone) 문제를 지적한다면, 나는 그것을 수동으로 검증한다. 만약 어떤 모델이 지나치게 확신에 찬 어조로 말한다면, 나는 그 모델에게 무엇을 놓치고 있을 수 있는지 질문한다.
이 방식은 더 느리다.
하지만 이것은 내가 현재 나의 워크플로우(workflow) 안에서 정신을 바짝 차리고 있을 수 있는 유일한 방법이다.
당신은 어떤가?
만약 당신의 스택(stack)에서 모델 하나가 18일 동안 사라진다면, 무엇이 가장 먼저 조용히 고장 날 것인가?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기