이 글은 편의상 반말로 작성되었습니다.
지난 7월 Fable 5가 한국에 공개되었다. 미국에서는 먼저 공개되었지만 미국 정부에서 제재를 해서 다른 나라는 더 늦게 Fable을 접할 수 있게 되었다. Anthropic은 처음에 이를 한시적으로 Max 플랜에 포함시키고, 이후에는 API 비용으로 별도 처리될 것이라고 했다. 하지만 지금은 영구적으로 Max 플랜에 통합된 상태이다.
Fable 5는 분명히 강력한 모델이고 이를 부정하는 사람은 없을 것이다. 엔지니어까지 갈 것 없이 9시 뉴스에도 나올 정도였다.
하지만 이 2-3주 간의 과도기 동안에 Fable 5가 문제를 만들어내기도 했고, 저 한시적 정책에 의한 스트레스도 많이 받았던 것 같다.
그래서 이 글에서는 저 2-3주의 시간 동안 뭘 겪고 느꼈으며, 앞으로 내가 어떤 방향성을 가져야 할지 정리하려고 한다.
막연함을 해결하는 강력한 성능
Fable은 이전 시점까지 출시되었던 모델과는 확실히 좀 달랐다. 특히 직전 모델이었던 Opus 4.7 ~ 4.8의 성능이 영 만족스럽지 않았는데 이들과는 차원이 다른 퍼포먼스를 보여 주었다.
Fable의 가장 큰 장점은 답이 정해지지 않은 문제, 혹은 Zero base에서 출발점을 찾아 나가고 이를 실행시키는 능력이었다. Unknown task를 탐색하는 방식에 관한 글에서 설명하는 것처럼, 무엇을 해야 할지부터 불명확한 문제를 조사하고 구조화하는 데 특히 강했다.
팀 전체가 계정을 2개씩 결제해 사용할 정도로 Fable에 열광했다. 나는 Fable을 두 가지 큰 작업에 사용했다.
첫 번째는 Aperture의 아키텍처와 초기 데모를 설계하는 일이었다. Aperture는 초급 수준의 바이브 코딩과 아이디어 수준에 머물러 있었다. 제품의 경계와 구현 방식이 모두 정해지지 않은 상태에서 GTM을 위한 데모가 필요한 상황이었는데, Fable을 통해 큰 구조를 잡고, 여러 가능성을 비교하고, 실제 가상의 회사를 기반으로 쓸만한 데모를 만들어 낼 수 있었다.
두 번째는 Moss에서 WalkMe나 Pendo 같은 기존 DAP를 대체하기 위한 솔루션의 초안을 만드는 일이었다. 고객의 요구사항과 그에 기반한 다른 팀원의 아키텍쳐 설계는 있었지만, 기존 코드와 완전히 독립이면서 코어 로직을 공유하고 정해지지 않은 세부 구현사항을 구체화시키는 작업이 필요했다. 자세한 내용을 현 시점에서 공개할 수는 없지만, 0에서 시작하는 것과는 다른 종류의 복잡한 문제였다.
그 밖에도 미뤄 두었던 문서 정리, Compliance, 기타 수많은 업무를 모두 Fable이 있을 때 방향을 정하고 싶었다. 제품부터 회사 내부 도구, 개인 생산성까지 가리지 않고 Fable을 투입했다. 계속 고민하고 있던 난제도 Fable에게 분석을 시켜 보았다. 복잡한 계획을 세우거나, 0에서 1을 만들거나, 원인을 찾기 어려운 문제의 해결책을 제시할 때 Fable은 실제로 괜찮은 결과를 냈다. Fable이 충분한 맥락을 이해하고 만든 계획을 그대로 진행했을 때 큰 기술적 결함이 생기는 경우도 많지 않았고, 구현은 Opus나 Codex에게 위임해도 문제가 없었다.
Fable의 진입장벽과 문제점
Fable의 일차적인 문제는 토큰이 비싸다는 것이었지만, 종량제가 아니었기 때문에 그것이 큰 문제는 아니었다. 오히려 문제는 Fable이 다루기 쉬운 모델이 절대 아니었다는 것이다. 오히려 다루기 매우 어려운 편이고, 개발자임에도 이를 잘 다루는 것이 쉽지 않았다.
먼저 Fable은 무언가를 지시하면 백그라운드에서 대부분을 처리하고 결과만 보고하는 경우가 많았다. 기술적으로는 무언가 계속 만들어지고 있었지만, 사용자인 나는 프로젝트가 어디까지 진행되었고 왜 그 방향으로 가고 있는지 놓치기 쉬웠다.
그리고 Fable의 사고 결과와 설명, 그리고 Fable이 작성한 문서는 과도하게 복잡했다. 이해하고 나면 정말 단순한 주제도 Fable의 표현을 거치면 복잡하게 꼬인 경우가 많았다. 쉽고 직관적으로 설명하라고 아무리 규칙을 추가해도 이는 잘 해결되지 않았다. Anthropic 모델이 원래 이 부분에서 약하긴 하지만 Fable은 그 정도가 더 심했다. 사람이 바로 읽고 행동할 수 있는 문서는 기본 사양의 Codex가 비교되지 않을 정도로 잘 작성했다.
이 2가지가 합쳐져서 Fable에게 맡겨 둔 문제가 오히려 방향성을 잃어 버리고 수습을 하는 데 더 고생하는 경우가 많았다.
이를 대표적으로 겪은 것이 DAP 작업이었다. 인수인계받은 맥락을 따라가면서 세부사항을 검토하고 발전시켜야 했는데, Fable이 알 수 없는 Ticket number를 열거해 가면서 설명하니 우선순위를 정하거나 방향성을 잡는 것이 매우 어려웠다. 당장 앞에 보이는 것을 하나씩 PR로 만들면서 구현은 진행되었지만 계속 겉도는 느낌이 있었다.
그리고 중간 결과를 팀에 공유한 뒤, 모두 따라가지 못하고 무언가 잘못되고 있다는 생각을 했다. Fable로 인해 산으로 간 맥락이 Blocker가 되고 있었다.
다행히도 진행했던 것은 인프라와 코어 로직에 해당하는 초기 단계였다. 그리고 이 코어 부분은 Fable이 초안을 잘 짜고 내가 가까스로 Follow-up하며 견고하게 구성했기 때문에 이후에 제품 세부 구현을 바꿀 때도 거의 변하지 않았다. 하지만 Fable의 알 수 없는 설명과 계획에 의존해 그대로 진행했다면 팀이 원했던 방향과는 상당히 다른 결과가 나올 뻔했다. Fable의 장점과 단점을 동시에 볼 수 있었던 시간이었다.
더 쉽고 직관적으로
방향을 잃지 않고 진행하기 위해서는 사람의 피드백이 필요했다. 그리고 그 피드백을 가장 직관적으로 이끌어낼 수 있는 건 데모였다.
강력한 성능의 Fable에게 데모는 아주 쉬운 일이었고 Fable은 바로 데모를 만들었다.
작동하는 화면을 직접 보면서 수정하고, 다듬고, 팀원에게 공유하고 나서야 의미 있는 피드백이 나오기 시작했다. 어디까지 했는지, 팀이 기대한 것과 무엇이 다른지가 비로소 명확해졌다. 이를 다시 피드백하면서 데모를 완성시키는 데는 2-3일이면 충분했다. 이 데모는 그대로 고객에게도 공유되어 프로젝트를 진행시키는 초석이 되었다.
그 다음 Fable에게 다시 데모와 계획 문서를 대조시켜 팀이 원하는 방향과의 Gap을 분석하고 계획을 수정하게 했다. 데모를 본 뒤였기 때문에 Fable이 이상한 단어를 들고 오거나 방향을 벗어나도 교정을 하는 것이 훨씬 쉬워졌다. 그래도 이해를 할 수 없을 때는 Codex의 도움을 받았다.
이 기점으로 Fable을 좀 더 잘 다루게 되고, Agent를 다루는 방식에 대해 다시 생각하게 되었다.
Fable로 인한 FOMO
지금까지는 Fable을 어떻게 더 잘 다루느냐에 대해 겪은 내용을 정리했다. 하지만 이보다 더 크게 나에게 영향을 주었던 것은 Fable로 인한 조급함과 허탈함이었다.
Cursor부터 시작하여 각종 AI 모델과 코딩 서비스가 빠르게 발전하는 동안에도 나는 크게 흔들리지 않는 편이었다고 생각한다. 어차피 모든 도구를 다 쓸 수도 없는 거고, 큰 트렌드만 따라가면서 내 방식대로 필요한 만큼 AI를 사용하면 된다고 생각했고, 실제로 그 계획대로 나름 AI를 만족스럽게 쓰고 있었다. 26년 초까지만 해도 AI에 대한 FOMO가 크게 공감되지는 않았고, 나만의 가치만 잘 정리해 나가면 된다는 마인드였다.
그런데 강력한 Fable이 기간제로 나오고, 회사의 일이 많은 상황까지 겹치니 나도 휩쓸렸다. 처음 공개된 며칠 동안 잠을 줄여 가며 Fable을 사용했고, 계정도 두 개씩 만들었다. 평소 미뤄 두었던 일까지 이 기간에 모두 처리해야 할 것 같아 일단 Fable을 돌리고 시작했다.
그래서 분명히 7월 7일까지였던 Fable이 12일로 연장되었을 때는 허탈함이 먼저 들었다.
어차피 이럴 거였으면 왜 나는 시한부마냥 Fable을 돌렸을까?
그 뒤로 Fable은 다시 19일로 연장되고, 20일부터는 영구적으로 MAX 플랜에 들어갔다. 그리고 2주도 지나지 않아 Fable보다 벤치마크가 좋다고 주장하는 Opus 5가 나왔다. OpenAI도 가만히 있지 않고 GPT 5.6을 출시했다. 결국 1달 전과 비교하면 Fable의 사용량은 급감했다. 생각해 보면 시간이 지날 수록 더 강한 모델이 나오고, 경쟁사에서도 가만히 있지 않을 테니 당연한 결과일지도 모르겠다.
지금 시대의 개발자가 이래서 어려운 것 같다. 당장은 AI에 맞서 개발자라는 직업을 유지하기 위해, AI 트렌드를 계속 따라가고, 최신 모델을 빠르게 쓰고, 생산성을 폭발시켜야 한다. 하지만 그 과정에서 오는 과부하를 생각해야 하고, AI가 빠르게 올라올 때 나는 개발 외에 무엇을 할 수 있는지를 생각해야 한다.
이에 대한 결론은 당연히 나지 않았지만, Fable로 인해 나는 분명히 스스로를 채찍질하며 강한 과부하를 줬던 것 같다.
이를 반면교사 삼아 앞으로는 이런 흐름에 휩쓸리지 않고 “나”를 지키는 것을 항상 생각해야 할 것 같다.
마치며
Fable 5의 첫인상은 확실히 충격이었다.
하지만 진짜 문제는 Fable을 쓰면서 드러났고, 7월은 많은 업무를 수행하기도 했지만, 이 문제들을 되돌아보고 Fable의 잔재를 갈무리하는 시간이기도 했다.
지금도 어떻게 해야 삶을 챙기면서도, 요즘 시대 개발자에게 필요한 생산성도 가져갈 수 있을지 끝없이 고민하고 있다. 한 쪽에 치우친 것은 항상 좋지 않은 결말이 될 확률이 높다. 균형을 잘 잡을 수 있도록 정리를 잘 해 두어야 할 것 같다.