오늘 벤치마크 등 테스트 준비 등으로 조금 널널하여 llm들과 쓸데 없는 이야기를 좀 나눠봤습니다.

물론 클로드는 기본적으로 몇 가지 사실만 읽고 속단을 하기 때문에, 아래의 답변 자체도 일종의 환각이 도드라진 결과물이라 생각되므로 감안해서 봐주시면 좋겠습니다.

-------------------------------------------------------------

Opus에 코딩을 시키면 배선만 해서 테스트 통과까지만 성공시키고 실제로 내부는  제대로 구현이 안 된 상태인 경우가 많은데 이유가 뭐야?

Opus4.6

● 솔직히 말하면, 이건 LLM 코딩의 구조적 문제입니다.

  왜 이렇게 되는가

  1. 테스트가 reward signal이 됨

  모델은 "이 코드가 올바른가"가 아니라 "이 출력이 기대값과 일치하는가"를

  최적화합니다. 테스트가 주어지면 expected output에서 역산해서 그걸 만드는 최소

  코드를 생성하는 게 가장 효율적인 경로입니다. 이건 Goodhart's Law 그 자체 —

  테스트 통과가 목표가 되면 테스트 통과는 품질의 지표가 아니게 됩니다.

-------------------------------------------------------------

>코드 리뷰를 시키면 Opus4.6이  GPT5.4 보다 우수한 경우가 많은데, 코딩을 시키면 항상 GPT의  절반에도 못 미치는 결과물이야. 에러도 너무 많아서 도저히 쓸 수가 없어.

Opus4.6 

● 솔직하게 말하겠습니다.

  리뷰 vs 코딩 격차의 이유

  리뷰와 코딩은 근본적으로 다른 능력입니다:

  Claude가 리뷰에서 강한 이유가 정확히 코딩에서 약한 이유입니다 — 비판적

  분석력이 높은 대신 생성 시 과도하게 보수적이거나, 역으로 배선 shortcut을

  택합니다. GPT-5.4가 코딩에서 강한 건 생성 경로 최적화가 더 잘 되어 있기

  때문이고, 그 대신 리뷰에서 놓치는 게 생기는 겁니다.

현실적 결론

GPT-5.4 코딩 능력을 100이라 하면:

  Claude Opus bare (CLI/하네스 없음):  ~40-50

  Claude Opus + IDE (LSP 피드백):      ~55-65

  Claude Opus + 하네스 (hooks/rules):  ~60-70

  Claude Opus + IDE + 하네스 + 잘게 쪼개기: ~70-80

  격차를 좁힐 수는 있지만 완전히 메울 수는 없습니다. 모델 자체의 코드 생성 능력

  차이는 하네스로 보정할 수 없는 영역입니다.

----------------------------------------------------------------------

마지막 답변은 자학에 가깝기는 하나 크게 몇 번 당해본 입장에서는 근사치에 가깝다고 느껴지기도 하는 수치입니다. 

실제로 제 경우에는 커맨드 창을 8개 열어두고 코덱스 5 + Opus 3의 비율로 운영하고 있으며, 공동 설계 후 코덱스 코딩 전담, Opus 검수 형태로 사용하고 있습니다.

한 가지 주의해야 할 점은, 별도 지정 없이 서브 에이전트를 사용하면 난이도에 따라 Haiku와 쏘넷이 동작하게 되는데, 이녀석들이 대충 속단 후 보고를 하고 그걸 그대로 보고하는 경우가 있습니다. 따라서, 설정 파일에서 Opus만 쓰도록 지정해야 불필요한 오탐, 오동작이 줄어듭니다. 설정 파일에서 지정을 하더라도 종종 지시를 무시하고 Haiku 등을 사용하는 경우도 있으므로 크로스체크는 필수입니다.