Claude가 코딩을 시작하기 전에, 작업 중 발견한 중복 코드를 고치겠다는 서약을 낭독하게 함. 중복을 찾기는 하지만 대개 버그를 알려줬을 때만 수정 모드로 들어가 CLAUDE.md의 DRY 선호를 실제로 적용함
원 논문도 plan_first 프롬프트로 개선 효과를 확인했지만 최종 통과율에는 영향이 없었음. 이 방식은 기능 구현 후 에이전트가 알아서 리팩터링한다고 가정하지만, 실제로는 기능 추가가 아니라 버그 수정을 지시해야 의미 있는 리팩터링을 하는 듯함
벤치마크는 테스트를 숨기고 실패에서 통과로 바뀌는 피드백도 주지 않으므로 성능 저하가 단조롭게 이어졌을 수 있음

그건 그냥 미신임

최근 이 논문과 벤치마크를 접했는데, 프로덕션 코드에서 늘 중요했던 비기능적·장기적 요구사항을 평가하려는 첫 시도에 가까움. 이제 모델이 단발성 문제 대부분을 풀 만큼 좋아져 특히 시의적절함
결정적인 점수가 나온다는 것도 좋음. ‘유지보수 가능성’은 여러 신호가 구성하는 고차원 공간에 가까우며, 그 공간을 파악하려면 사람의 레이블링이 필요할 가능성이 큼
또 하나의 신호는 시스템의 상태 공간이며, 최근 형식 기법도 자주 등장하고 있음

시스템의 상태 공간뿐 아니라 이를 모델이 접근하고 볼 수 있게 만드는 방법도 중요함. 모델에 적합한 형태로 상태를 ‘보여주면’ 놀라운 성과를 내는 경우가 많음
환경에 CLI 하나를 추가하는 것만으로 큰 돌파구가 생기는 이유도, 복잡한 상태를 구조적으로 관찰하고 조작할 수 있게 해주기 때문임

‘유지보수 가능성’을 단일 지표로는 유용하지 않은 다차원 공간이라고 표현한 것이 간결하고 정확함
데이터베이스나 제3자 서비스에 의존하는 프로덕션 소프트웨어 전체의 상태 공간은 측정하기 너무 어려울 수 있음. 하지만 시스템 일부를 경계가 명확한 상태 기계로 분리한다면, 깔끔한 인터페이스 뒤에 있는 모듈의 가치 지표로 활용할 수 있을 듯함 Kubernetes 제어 루프가 좋은 사례임. 범위가 제한된 구성 요소들이 잘 정의된 상태 기계의 제어 루프를 맡아, 대부분의 네트워크 분할이나 중단에서도 작동하고 복구함. CRDT의 약속을 더 실용적으로 구현한 접근에 가까움

대형 연구소들이 이 벤치마크를 강화학습 파이프라인에 활용하길 바람. 생성 코드의 복잡도를 줄이는 것이 최우선이어야 하며, 이상적인 모델은 올바른 추상화를 선택해 기능을 구현하면서도 코드 줄 수를 줄여야 함
이 벤치마크로 코드 복잡도를 낮추는 프롬프트와 스킬을 반복 개선할 수 있다는 점도 좋음

코드 줄 수를 줄인다는 명목으로 너무 많은 로직을 한 줄에 몰아넣는 방향으로 치우치기도 쉬움

연구소들은 적어도 공식적으로는 벤치마크 데이터로 학습하지 않음. 비슷한 문제로는 학습할 수 있지만, 벤치마크에 포함된 특정 문자열은 학습 말뭉치에서 적극적으로 걸러내야 함

좋긴 하지만 사람의 성능과 비교해야 훨씬 유용할 것임. 어렵다는 점은 이해하지만, 많은 이가 제목의 수치만 보고 Opus 5가 인간 개발자의 4분의 1 수준이라고 오해할 가능성이 큼

Opus 5는 Opus 4.8보다 확실히 개선됐지만, Fable에서 느꼈던 것처럼 혁명적이지는 않다는 내 체감과 일치함
이제 Opus 4.8 xhigh 대신 Opus 5 medium을 쓰며 토큰도 덜 들고 더 빠름. 문체를 싫어하는 반응은 이해하지만 실제 작업에는 전혀 거슬리지 않아 만족하며 사용 중임

Fable은 성능이 의도적으로 약화된 듯함. 처음 나왔을 때는 정말 혁명적이었지만, 금지 조치 이전과 지금의 모델은 같지 않음

Fable의 어떤 부분이 혁명적으로 느껴졌는지 더 자세히 듣고 싶음

왜 medium을 high 대신 선택했는지 궁금함. 본 성능 차트에서는 medium에서 high로 갈 때 향상이 상당했고, high에서 xhigh로 갈 때는 그만큼 크지 않았음

지금까지의 해결책은 별도로 전체 코드베이스 리뷰를 주기적으로 실행하고, 가능하면 Fable로 검토한 뒤 결과에 따라 여러 차례 리팩터링하는 방식임

나도 이 방식을 선호함. 그렇지 않으면 지나치게 깊은 국소 최적점에 빠질 위험이 큼

원시 테스트 결과를 보고 싶음. 대부분의 모델이 database_migration의 체크포인트 2 테스트에서 default_value를 놓칠 것 같음. 이를 JSON 리터럴과 SQL 표현식 중 어느 쪽으로도 해석할 수 있기 때문임
논문에서 든 원인과 무관한 이유로 실패하기 쉬운 테스트가 더 있을 수도 있음. 의존성이 허용하는 범위에서 체크포인트 순서를 3→2→5→4처럼 바꾸면, 각 체크포인트의 난이도 차이를 통제할 수 있어 흥미로운 실험이 될 것임

체크포인트 순서를 바꿔 결과를 비교하는 발상이 마음에 듦. 난이도를 높이거나 낮추는 방법으로도 활용할 수 있겠음
정보를 유출하지 않으면서 결과 일부를 묶어 공개하기가 얼마나 쉬운지 살펴보겠으며, 아마 가능할 듯함

한동안 대화에 참여하지 않았지만 이 결과를 만들어낸 것은 반가움. Opus 5는 큰 개선이 아니라고 느끼며, 진정한 놀라움을 준 것은 Opus 4, 4.6, 그리고 Trump 행정부의 성능 약화 조치 이전 Fable뿐이었음

이번 작업은 새 모델로 가장 빠르고 저렴하게 시도할 수 있는 출발점에 불과함
앞으로 sol과 Fable도 포함하고, 더 많은 언어를 탐색하며, 벤치마크를 더 폭넓게 반영하도록 문제 세트를 다듬고 싶음
개인적으로 Opus 4.5가 4.1보다 둔하게 느껴졌음. 4.5가 2.5배 빠르고 2.5배 저렴하다는 점 때문에 더 작은 모델이라고 추측해 편향됐을 수도 있음

코드 중복과 전체 코드 줄 수에 벌점을 주는 적대 모델을 제공하면 이 벤치마크의 성능을 어느 정도 유도할 수 있을지 궁금함