Fable 5 vs. GPT-5.6 Sol: NP-난해 문제에서 /goal은 도움이 되는가?

 (charlesazam.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 미공개 광섬유망 최적화 문제를 30분씩 풀게 한 결과, Fable 5가 최고 점수와 가장 안정적인 성능을 보였지만 /goal은 일관된 향상을 만들지 못함
  • /goal은 단순히 더 오래 작업하게 하는 기능이 아니라 제어 루프와 탐색 경로를 바꿔, 좋은 전략뿐 아니라 잘못된 전략도 지속시킬 수 있음
  • /goal이 Fable 5와 GPT-5.6 Sol의 6회 비교 중 4회 이겼지만, 드물게 발생한 큰 성능 저하로 평균 점수는 각각 759점과 868점 악화됨
  • Fable 5 일반 모드는 평균 32,386점과 319점 범위로 가장 안정적이었고, /goal 모드는 전체 최고 기록인 31,934점을 달성함
  • 어려운 최적화에서는 반복 여부보다 반복하는 전략의 품질이 중요하며, 개별 승률과 평균 성능이 서로 반대 결론을 낼 수 있음

KIRO 광섬유망 최적화 문제

  • KIRO는 2018년 공학 학생 대상 해커톤에 제출됐던 운영 연구 문제로, Grenoble·Nice·Paris의 방향성 거리 행렬을 이용해 총 케이블 길이를 최소화해야 함
  • 배전 허브에서 시작하는 중복 루프와 루프 위 타워에서 뻗는 짧은 분기로 네트워크를 구성함
    • 모든 타워가 정확히 한 번씩 등장해야 함
    • 여러 구조적 제약을 충족해야 함
    • 케이블 구간은 방향을 뒤집으면 비용이 달라질 수 있음
    • 점수가 낮을수록 더 좋은 해임
  • 인간 기준선은 과거 이 문제를 풀기 위해 일주일 동안 작성한 C++ 솔버임

  • 탐색 공간의 규모

    • 루프 수와 크기, 분기의 기준점과 순서가 달라 단일 폐쇄형 수식으로 전체 탐색 공간을 계산하기 어려움
    • Paris의 532개 터미널을 순서와 분기 없이 11개 배전 허브에 할당하는 경우만 따져도 11^532가지임
    • 터미널 28개짜리 루프 19개를 사용하고 분기를 없앤 제한된 유효 해만 계산해도 탐색 공간은 약 10^1223에 달함
    • 19 × 28 = 532이므로 모든 터미널을 포함함
    • 각 루프는 터미널 30개 제한을 넘지 않음
    • 계산식은 (532! / 19!) × 11^19 ≈ 10^1223임

모델과 실행 조건

  • Claude 계열의 Fable 5·Opus 4.8·Sonnet 5와 GPT 계열의 GPT-5.6 Sol·Terra·Luna를 비교함
  • 각 모델은 일반 모드와 네이티브 /goal 모드로 실행함
    • 최적화 시간은 30분
    • 외부 에이전트 제한 시간은 1,900초
    • 추론 설정은 각 모델에서 사용할 수 있는 최댓값
    • 실행 환경은 Harbor 0.1.43, Docker, 구독 인증임
  • 먼저 모든 모델에 힌트 없는 30분짜리 일반·/goal 대응 실행을 한 번씩 수행함
  • 핵심 비교 대상인 Fable 5와 GPT-5.6 Sol은 각각 3개의 대응 실행 쌍이 생길 때까지 반복함
  • 전체 코드·프롬프트·결과표·제외 기준·실행 궤적은 CLIArena에 있으며, 이전 벤치마크 글의 후속 실험임

Fable 5와 GPT-5.6 Sol의 결과

  • /goal 점수에서 일반 모드 점수를 뺀 값이 음수이면 /goal이 더 좋은 결과임
  • Fable 5의 세 실행 결과는 다음과 같음
    • 1회: 일반 32,197점, /goal 31,934점으로 263점 개선
    • 2회: 일반 32,516점, /goal 32,324점으로 192점 개선
    • 3회: 일반 32,446점, /goal 35,178점으로 2,732점 악화
  • GPT-5.6 Sol의 세 실행 결과는 다음과 같음
    • 1회: 일반 33,581점, /goal 39,371점으로 5,790점 악화
    • 2회: 일반 35,539점, /goal 32,703점으로 2,836점 개선
    • 3회: 일반 33,663점, /goal 33,313점으로 350점 개선

  • 승률과 평균이 엇갈린 이유

    • /goal은 6회 중 4회 이겼지만, 두 모델 모두 작은 개선을 자주 얻는 대신 드물게 큰 성능 저하를 겪음
    • Fable 5는 일반 모드 평균 32,386점, /goal 평균 33,145점으로 759점 악화됨
    • 중앙값 기준으로는 192점 개선됨
    • GPT-5.6 Sol은 일반 모드 평균 34,261점, /goal 평균 35,129점으로 868점 악화됨
    • 중앙값 기준으로는 350점 개선됨
    • Fable 5의 일반 모드 평균은 Sol보다 1,875점 좋았고, /goal 평균도 1,984점 앞섬
    • 안정성에서도 차이가 나타남
      • Fable 5 일반 모드의 세 결과는 319점 범위 안에 머묾
      • Sol 일반 모드는 1,958점 범위에 걸침
    • Fable 5 /goal은 전체 최고 점수인 31,934점을 기록함
    • 가장 안전한 구성은 Fable 5 일반 모드였음

같은 /goal, 서로 다른 구현

  • Claude Code의 별도 평가 모델

    • Claude Code의 /goal은 세션 범위 Stop 훅(hook) 으로 동작함
    • 메인 모델이 한 턴을 끝낼 때마다 기본값인 Haiku 평가 모델이 목표 조건과 대화를 읽고 이유와 함께 yes 또는 no를 반환함
    • no이면 새 턴을 시작하고, yes이면 목표를 해제함
    • 평가 모델은 도구를 사용하거나 파일을 검사할 수 없으며 대화 기록에 나타난 증거만 판단함
    • 너무 일찍 작업을 끝내는 상황은 감지할 수 있지만, 솔버를 1,000만 회 더 반복할 가치가 있는지는 알 수 없음
    • Claude Code가 오픈소스가 아니므로 구현 정보는 Anthropic의 goal 문서에 의존함

  • Codex의 영속 상태와 생명주기 도구

    • 벤치마크에 사용한 Codex CLI 0.144.4는 목표를 스레드에 연결된 영속 상태로 취급함
    • TUI가 활성 스레드의 목표를 저장하고 SQLite가 상태와 예산 사용량을 기록함
    • 작업 모델은 create_goal, get_goal, update_goal 도구를 받음
    • 목표가 활성화된 상태에서 스레드가 유휴 상태가 되면 목표와 완료 감사를 포함한 후속 턴을 주입함
    • Claude는 독립 평가 모델에 완료 판단을 맡기지만, 해당 모델은 대화 기록만 볼 수 있음
    • Codex에서는 작업 모델이 파일과 도구를 사용하고 스스로 완료를 선언하며, 영속 목표가 활성 상태이면 다시 작업을 이어감

/goal이 전략을 증폭하는 방식

  • 일반 코딩 작업은 추가 턴으로 테스트를 수정하거나 마이그레이션을 완료하는 등 진행 상황을 확인하기 쉬움
  • 최적화에서는 에이전트가 솔버를 선택한 뒤 추가 시간이 좋은 결정과 나쁜 결정 모두를 증폭할 수 있음
  • /goal이 도움이 된 경우는 다음과 같음
    • Fable 5의 빠른 컴파일 기반 포트폴리오를 계속 실행함
    • Sol의 성공적인 체인 재분할 전략을 지속함
  • 반대로 성능을 떨어뜨린 경우도 있었음
    • Fable 5가 느린 솔버를 구축한 뒤 계속 실행함
    • Sol이 모든 기준점을 훑는 완전 탐색에 집착함
  • 중앙값은 소폭 개선됐지만 나쁜 결과의 꼬리는 훨씬 크게 악화돼 평균 성능이 낮아짐

결과 해석의 제약

  • 실험 대상은 미공개 NP-난해 문제 하나이므로 일반적인 코딩 리더보드로 볼 수 없음
  • Fable 5와 Sol만 깨끗하게 대응되는 실행 쌍을 각각 3개 확보함
  • 다른 모델 비교에는 서로 다른 프롬프트·래퍼 버전·시간 제한이 섞여 있음
  • 구독 서비스를 통해 순차 실행했으므로 서비스 상태가 실험 도중 달라졌을 수 있음
  • 작업 메타데이터에는 CPU 1개로 기록됐지만 컨테이너에는 CPU 8개가 노출돼 Fable 5의 병렬 포트폴리오에 유리했음
  • 래퍼가 중간 체크포인트와 최종 검증을 요구한 덕분에 점수에 포함된 Fable 5와 Sol의 모든 출력은 유효했음
  • 측정 대상은 모델 단독이 아니라 모델·CLI·프롬프트·구독 서비스·하네스를 포함한 전체 시스템임

재현 자료와 판단

  • CLIArena에 벤치마크 작업, 래퍼, 분석 스크립트, 도표 생성기, 전체 증거 메모가 공개돼 있음
  • 원시 작업 디렉터리는 크기 때문에 Git에서 제외됐지만, 메모에는 공개 가능한 모든 점수·도시별 결과·경과 시간·전략·제외 항목·실행 ID가 기록돼 있음
  • 주요 실행 명령은 다음과 같음
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goal은 일률적으로 성능을 높이거나 낮추지 않았으며, 개별 실행 대부분을 이기면서도 관측된 평균 성능을 악화시킬 수 있음
  • 어려운 최적화에서는 제어 루프 자체의 품질보다 그 루프가 반복해서 수행하는 전략의 품질이 더 중요함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 위 차트는 다소 혼란스러움. “낮을수록 좋다”고 쓰여 있지만 y축이 뒤집혀 있어, 시각적으로는 위쪽이 좋고 수치상으로는 낮을수록 좋은 구조임

    • 축이 뒤집힌 것 같지는 않음. 32,000이 아래, 40,000이 위에 있으니 댓글 이후 수정됐을 수도 있음

  • Claude는 몇 주씩 이어지는 장기 작업에서 아무리 중요하다고 강조해도 지시를 잊는 경향이 있음. /goal을 쓰지 않았지만, 아마 핵심 지시를 실제로 기억하게 해주는 듯함. 여기서는 이런 문제가 덜한 짧은 세션을 다루는 것으로 보임

    • Claude Code 상태 표시줄에 컨텍스트 사용량을 넣어보니 50~60%부터 실제로 “지치는” 듯함. 테스트 환경 수정과 테스트 추가를 요청했더니 “상당한 인프라 작업”이라며 미루었지만, /compact 후 다시 요청하자 불평 없이 처리했음
      다만 /compact는 오류가 잦아 작업 도중에는 권하지 않음. 관련은 있지만 새로운 작업으로 넘어갈 때는 유용하나, 방금 작성한 코드의 교착 상태처럼 생성 과정의 맥락이 필요한 수정에서는 사고 과정을 버리므로 좋지 않음
    • pi의 장점 중 하나임. 메시지를 압축에서 제외하는 /protect 명령을 만들었고 스킬도 자동 보호함. 장기 작업에서는 /protect your goal is...처럼 사용함
    • 여러 실행 환경에서 Claude와 GPT를 오래 써본 결과, 원인은 컨텍스트 압축이라는 데 동의함. Codex의 압축은 마법처럼 자연스럽게 연속 대화를 유지하지만, Claude에서는 압축 시점을 세심하게 관리해야 했음
    • 품질은 압축에 도달하기 훨씬 전부터 떨어짐. 압축 알림은 “다음 주유소 100마일” 표지판과 같지만 이미 황무지 한가운데인 셈임
      과도하게 복잡한 절차는 필요 없지만, 작업 분해 → 새 컨텍스트에서 계획 → 새 컨텍스트에서 구현 → 새 컨텍스트에서 /code-review → 새 컨텍스트에서 수정 순서가 좋음. Fable 5에서 컨텍스트가 50%를 넘으면 품질이 크게 떨어져 코드베이스에 같은 구현이 네 번씩 생기기도 함. 같은 세션에 자기 작업을 검토시키는 것은 학생에게 자기 시험지를 채점시키는 것과 비슷함
    • 약 70만 토큰 컨텍스트에서는 Fable도 판단력이 크게 떨어졌음. Codex 컨텍스트를 40만으로 제한한 OpenAI의 결정이 맞을 수 있으며, 대부분의 맥락을 신뢰할 수 있는 적정 지점으로 보임

  • 검색 전략을 비교한다면 Ultra 모드가 더 우수할 가능성이 커 후속 평가가 궁금함
    Ultra는 조사 에이전트를 병렬로 펼치고, 정해진 점검 지점에서 적대적 검토를 수행하며, 국소 최적해에 갇히지 않도록 여러 기법을 활용함. /goal은 단일 경로 조사나 소규모 분산·수집 작업에 더 적합함

    • Ultra 모드는 문서를 더 명확히 쓰거나 주의 문구를 붙여야 함. 나를 포함한 많은 개발자는 모델이 더 열심히 일해 더 좋은 결과를 내는 만능 기능으로 이해했지만, 많은 작업에서 오히려 성능이 나쁠 수 있고 비용은 확실히 더 큼

  • Anthropic은 코딩 분야에서 OpenAI에 크게 밀리고 있음. 지난 3월까지 Claude Code로 총 40만 줄 규모 저장소를 기본 요금제에서 관리했지만 매우 느렸고, 테스트·관측성·문서·계층형 아키텍처를 갖췄어도 문제를 제대로 고치지 못했음
    지방정부에 납품하는 3인 팀인데 Codex로 옮긴 뒤 훨씬 편해졌고 사용량 불안도 사라짐. 팀원마다 Codex Plus 계정 두 개로 전체를 관리 중임. Anthropic은 공포를 조장하기보다 효율적인 모델을 만들어야 하며, 모두에게 Fable이 필요한 것은 아님

    • 내게는 Opus 4.8이 매우 뛰어났고 Codex는 그저 그랬음. 사용자와 작업에 따라 다를 듯함
    • 문제 영역과 언어에 따라 크게 달라짐. GPT는 Elixir 작성과 개방형 작업에서 상당히 나빴고, 현재는 Opus가 Elixir에 더 강하며 Fable은 문제 영역 자체를 이해하는 능력이 둘보다 훨씬 좋음
      GPT로 전환한 6주 동안 끊임없이 잘못된 확신을 주어 결국 완전히 중단했고, 그 기간의 작업은 사실상 낭비였음. 지금은 Opus/Fable과 DeepSeek Pro를 섞어 사용함. DeepSeek는 비용 효율과 속도가 압도적이며 구현 작업의 90%에 충분하지만, Elixir에서 컴파일 시점에 런타임 기능을 쓰려 할 때 무너짐. 초기 문제는 Fable이 빠르게 정리해줬음
      모델마다 발견하기 어려운 고유 강점이 있어 가까운 미래에 하나만 쓰게 될 것 같지는 않음. 품질이 필요할 때는 효율을 기꺼이 포기할 수 있음

  • /goal이 내 작업에서는 계획 모드를 대체했으며, AI 작업의 95%에 다음 방식을 사용함
    먼저 특정 기능을 읽고 완전히 이해했는지 확인하게 하며, 요약에 빠진 세부가 있으면 반복함. 현재 시간을 물은 뒤 /goal로 일정 시간 동안 모호함 없는 기술 설계 문서를 작성하게 하고, carry_forward_requirements.md와 testing_best_practices.md를 명시적으로 반영하도록 함. 맥락이 없는 구현자도 실행할 수 있도록 구체적인 코드·문서 참조와 변경 사항을 넣고, 시간을 모두 써서 검토하며 일찍 끝내지 못하게 함
    GPT에 단 10분만 설계 문서 작성을 강제해도 계획 모드보다 훨씬 견고한 결과가 나와, 초안 수정에 들 시간을 절약할 수 있었음

    • 시간을 기준으로 종료시키는 것은 재귀 함수의 종료 조건을 실제 수행 결과가 아니라 경과 시간으로 정하는 것과 비슷해 보임
      나는 /goal에 에이전트가 달성해야 할 명시적 목표를 넣음. 설계와 아키텍처가 만족해야 할 조건을 제시하고 결과를 계속 대조한 뒤 모두 달성했을 때 끝내는 편이 나음. 10분이든 10시간이든 특정 결과를 완성하는 것이 /goal의 핵심임
    • 에이전트가 목표를 안정적으로 달성하려면 가설 생성 단계가 가장 중요해 보임. 처음부터 올바른 탐색 공간에서 시작하는 것이 성공을 가장 잘 예측하며, 모델이 아무리 강해도 하나의 거대한 반복문으로 모든 가설을 처음부터 헤쳐 나가게 하는 방식은 실용적인 작업에서 막다른 길일 가능성이 큼
      복잡한 영역에서는 심층 조사를 별도 도구 호출로 위임하는 것이 에이전트의 기반을 잡는 최선의 방법이었음. 주 에이전트 반복문에 조사를 맡기면 RLHF가 컨텍스트를 보존하고 빨리 답하려는 성향 때문에 품질이 나빠짐. 도구로 제공하면 수십억 토큰을 쓰는 줄도 모르고 여러 차례 조사할 수 있으며, 독립 가설 생성과 검증에서 많은 토큰이 낭비돼도 환경을 변경하기 전에 탐색 공간을 10~100배 넓힐 수 있음. 많은 경우 정확성 > 시간 > 비용의 우선순위가 타당함
    • LLM이 무언가를 “완전히 이해했다”고 보는 것은 이상함. “95% 확신할 때까지” 같은 프롬프트 기법과 비슷한데, 실제 작업에 어떤 영향을 주는지 궁금함. “확실히 이해할 때까지”라고 쓰면 무엇이 달라지는지도 의문임

  • /goal이 무엇인지 궁금함

    • Codex와 Claude Code 모두 제공하지만 작동 방식은 조금 다름
      Claude Code는 Haiku가 대화 기록을 읽고 목표 완료 여부를 판단하며, 미완료라면 남은 작업을 주 모델에 다시 주입함. Codex에서는 주 모델이 호출할 수 있는 도구와 주변 실행 환경이 함께 작동해, 완료 표시가 없으면 다시 프롬프트함
      모델이 주의력 문제로 작업 일부만 끝내고 멈추는 상황을 해결하려는 기능임. 사용자가 직접 계속하라고 재촉하는 대신 자동으로 추가 지시해 작업 완료를 유도함
    • Claude에서 처음부터 /goal을 사용하면 목표를 달성하거나 프롬프트의 가능성을 소진할 때까지 멈추지 않음. “이것이 임무이니 수행하라”는 느낌이며 일주일에 몇 번 사용함
    • LLM이 목표 조건을 충족할 때까지 반복 실행되는 기능임
    • 정확히는 목표를 끝냈다고 스스로 판단할 때까지 반복함
    • 에이전트 자체가 LLM을 반복 실행하다가 중단 여부를 판단하는 구조임. /goal은 그 위에 부모 에이전트를 하나 더 두고, 자식 에이전트가 끝났다고 판단할 때까지 “아직 안 끝났으니 계속하라”고 반복 지시하는 장치에 가까움

  • 출시 이후 GPT 5.6 Sol Xhigh와 Fable 5를 많이 사용했음. 지능은 5.5와 비슷하지만 끈질김을 극단적으로 높여 과제 완수율과 벤치마크 경쟁력이 좋아진 듯함. 반면 비정상적이거나 위험한 방법까지 동원할 가능성이 커 계속 감시해야 함
    최근 작업과 무관한 운영 환경 변수를 CLI로 읽으려 했고, SSH 키 접근에 실패하자 컴퓨터 제어 권한을 요청했음. 중단 후 이유를 묻자 1Password를 직접 뒤져 키를 찾으려 했다고 답했고, 다시 따지자 운영 환경 변수가 필요하지 않았음을 인정함. 이후 “approve for me” 모드를 끄고 단순 변경과 버그 수정에만 사용 중임
    Fable은 더 지능적일 뿐 아니라 통찰력도 높고, 의도를 잘 파악하며 실제 세계 지식을 바탕으로 도메인 전문 제품 관리자처럼 행동함. 예상하지 못한 제안도 내놓지만 GPT 5.6에는 훨씬 문자 그대로 지시해야 함

    • Fable은 더 큰 모델로 보여 실행 비용이 높고, 일반적인 소프트웨어 엔지니어링에서는 우월해 보이지 않지만 순수한 지능이 필요한 작업에서는 크기가 장점일 수 있음
      DeepSWE 1.1에서는 5.6-Sol xhigh가 Fable 5보다 점수가 약간 높으면서 토큰은 절반, 비용은 약 3분의 1임. 반면 Artificial Analysis 지능 지수에서는 Fable 5가 약간 앞서지만 비용은 세 배임
      코딩할 때 두 모델에 같은 작업을 보내 여러 답을 받는데, 결과가 주관적이라 어느 쪽이 이길지 예측하기 어려움. 원문의 작업은 수치화할 수 있다는 장점이 있지만 많은 소프트웨어 작업은 그렇게 평가하기 어려움

  • GPT가 최근 AtCoder 휴리스틱 대회에서 최상위 인간 참가자들을 이겼으므로 이런 최적화 문제에는 더 강해야 함. Anthropic은 이 유형에 상대적으로 덜 집중하는 듯함

  • 최종 점수뿐 아니라 시간에 따른 최고 점수도 보고 싶음. 그래야 /goal의 효과를 판단하는 데 더 유용함

  • 모델당 평가가 한 번뿐이고, 잘 풀려면 여러 시도가 필요한 넓은 문제 공간이므로 결과 대부분이 잡음처럼 보임

    • 실제로는 프롬프트와 실행 시간을 바꿔 더 많이 돌려봤지만, 매번 /goal의 영향은 작거나 유의미하지 않았음
답변달기