Claude Opus 4.8, 코딩 에이전트로 쓰기엔 뭔가 망가졌다는 HN 제보

• HN에 Claude Opus 4.8이 코딩 에이전트로 쓰기엔 이상하게 망가진 것 같다는 제보가 올라옴

  • 작성자는 첫 1시간 사용 경험을 두고 “GPT-2 시절로 돌아간 느낌”이라고 표현함
  • 문제 상황은 Rails 앱에서 평소처럼 프로젝트 파일을 읽고 작업시키는 맥락이었음

• 핵심 불만은 모델이 실제 파일을 읽는 대신, 없는 경로를 지어내고 계속 실패했다는 점임

  • 예를 들어 실제 파일은 app/workers/gmail/sync_worker.rb인데, 모델은 app/services/gmail/sync_worker.rb 같은 존재하지 않는 경로를 만들어냈다고 함
  • 그 상태로 sed를 쓰거나 파일을 읽으려다 No such file or directory 오류를 15번 연속 냈다는 얘기임
  • 사용자가 왜 올바른 경로에서 파일을 읽지 않느냐고 묻자, 모델은 자신이 파일명을 추측했고 Read 도구 대신 sed나 cat을 썼다고 인정함

• 더 골 때리는 건 사과가 한 번으로 끝난 게 아니라는 점임

  • 작성자 말로는 같은 세션에서 이미 5번째 사과였다고 함
  • 모델은 방금 가져온 목록에서 실제 메시지 ID를 읽지 않고, 검증 단계에 또 가짜 메시지 ID를 입력했다고 스스로 설명함
  • 즉, “내가 같은 실수를 반복하고 있다”는 식으로 반성은 하는데 행동은 안 고쳐지는 전형적인 에이전트 실패 패턴임

• 컨텍스트 창이 꽉 찬 상태도 아니었다는 점이 불만을 키움

  • 작성자는 당시 컨텍스트 창 사용량이 15%였다고 적었음
  • 긴 대화 때문에 문맥이 밀려난 상황이라기보다는, 모델 또는 도구 호출 쪽 품질 자체가 흔들린 것처럼 보인다는 문제 제기임

• 체감 성능도 나빴다고 함

  • 응답이 “참을 수 없을 정도로 느리다”고 했고, Cancelled: parallel tool call Bash errored 같은 오류가 10개 넘게 계속 나온다고 함
  • 단순히 한두 번 헛소리한 게 아니라, 파일 탐색, 도구 호출, 검증 단계가 연쇄적으로 삐걱댄 케이스임

• 이 글이 흥미로운 이유는 벤치마크가 아니라 실사용자의 코딩 루프에서 터진 불만이라는 점임

  • 모델 카드나 리더보드에서는 좋아 보여도, 실제 개발자는 “파일을 제대로 읽는가”, “없는 경로를 만들지 않는가”, “실패 후 같은 실수를 반복하지 않는가”를 먼저 봄
  • 특히 한국 개발자들도 Cursor, Claude Code, OpenAI Codex류 도구를 업무에 붙여 쓰는 흐름이라, 이런 도구 사용 안정성 이슈는 꽤 현실적인 체크포인트임

---

기술 맥락

• 여기서 문제의 본질은 Claude Opus 4.8의 일반 지식이 아니라, 코딩 에이전트가 파일 시스템을 다루는 방식이에요. 실제 프로젝트에서는 모델이 답을 바로 쓰기보다 먼저 파일을 읽고, 경로를 확인하고, 그 결과를 바탕으로 수정해야 하거든요.

• 작성자가 화난 지점은 모델이 틀린 답을 낸 게 아니라 검증 가능한 정보를 추측했다는 거예요. 파일 경로는 도구로 확인하면 되는 값인데, 그걸 상상해서 sed를 날리면 개발자는 모델을 도와주는 사람이 아니라 모델의 실수를 감시하는 사람이 돼요.

• Context Window가 15%였다는 디테일도 중요해요. 문맥이 꽉 차서 예전 정보를 잃어버린 상황이라면 어느 정도 설명이 되지만, 아직 여유가 있는데도 같은 실수를 반복했다면 에이전트 실행 정책이나 도구 호출 안정성 쪽 문제가 의심되거든요.

• 코딩 보조 도구를 고를 때는 모델 이름만 보면 부족해요. 실제로는 Read 같은 안전한 도구를 우선 쓰는지, 실패한 명령을 반복하지 않는지, 방금 얻은 값을 다음 단계에서 제대로 재사용하는지가 업무 체감 품질을 크게 갈라요.