이제 난 끝났다, 얘들아

핵심 요약

Fable 모델의 강력한 성능과 한계를 경험한 사용자가 모델 사용 종료를 앞두고 남긴 회고록입니다.

Fable 모델 성능 — Opus보다 훨씬 강력한 미사일급 성능을 보여줌

비용 효율성 문제 — 사소한 작업에 쓰기엔 너무 비싸고 신중한 사용이 필요함

코드 아키텍처 한계 — 기존 코드를 재설계하기보다 덧씌우려는 경향이 있음

문서화 의존성 — 학습 데이터가 부족한 복잡한 프레임워크에서는 오류를 범함

꽤 괜찮은 경험이었다. 이번에 배운 점들:

Opus가 소총이라면, Fable은 탄도 미사일이다.
Fable은 기존에 쓰던 모델들처럼 다루면 안 된다. 사소한 작업에 낭비하기엔 너무 비싸고, 대충 던져주기엔 너무 강력하다. 제대로 안 쓰면 돈만 엄청나게 날리면서 예쁜 쓰레기만 잔뜩 뽑아내기 딱 좋다. 제대로 써먹으려면 known/unknown knowns/unknowns부터 확실히 정리해둬야 한다.
만능 해결사는 아니다. 모델이 학습했을 법한 데이터와 거리가 먼 특수한 케이스(내 경우엔 엄청나게 복잡하고 특이한 UIKit 앱 & UI)라면, 미리 가르쳐주지 않는 이상 엣지 케이스에서 픽픽 쓰러진다. 복잡한 소프트웨어의 런타임 동작을 완벽하게 추론하는 건 무리다. (아래 예시 참고)
Sonnet 5랑 궁합이 아주 좋다. 나는 CC를 실험적인 팀 모드(적절한 모델을 써서 에이전트를 가장 일관되게 돌릴 수 있는 모드)로 설정하고, Sonnet 5를 써서 조사나 리뷰를 시키는 방식으로 썼다.
여전히 '제대로 일하는' 본능은 부족하다. 아키텍처를 뜯어고치려 하면 저항하고, 기존 코드 위에 덧씌우는 방식을 고집한다. Opus 4.8보다는 새로운 작업을 할 때 아키텍처를 훨씬 잘 잡긴 한다. 하지만 Opus 4.8처럼, 이미 있는 코드를 한 발 물러서서 정리하거나 재설계하는 건 시켜도 잘 안 한다. 코드베이스를 꿰뚫고 있는 사람만큼 깔끔하고 단순한 구현 방식을 '알아보는' 눈은 아직 부족하다.

구독 플랜으로 빨리 풀렸으면 좋겠다. 생각했던 것만큼 아쉽지는 않을 것 같다. 이 모델이 보여준 발전도 기대되지만, 결국 좋은 소프트웨어를 만들려면 아직은 사람의 세심한 가이드와 전문 지식이 필수적이라는 사실이 더 흥미롭다.

Fable이 삽질했던 예시: Apple's docs에는 이렇게 적혀 있다:

Recurring event identifiers are the same for all occurrences. If you wish to differentiate between occurrences, you may want to use the start date.

이건 거짓말이다. 시리즈에서 분리된 앵커 이벤트는 겉보기엔 같은 시리즈인 것처럼 동작하지만, 실제 인스턴스들과는 ID가 다르다. Fable이 이 잘못된 정보를 핵심 가정으로 삼아서 3000줄짜리 PR을 날린 뒤에야 피눈물 흘리며 알게 된 사실이다. 모델 스스로는 이 버그를 찾아내지도 못했다. 아마 학습 데이터로 쓸만한 문서나 공개된 논의, 오픈소스 코드가 풍부한 언어나 프레임워크라면 이런 문제는 훨씬 덜할 거다.