---
title: "Claude Opus 4.8, 코딩 에이전트로 쓰기엔 뭔가 망가졌다는 HN 제보"
published: 2026-05-28T22:49:30.000Z
canonical: https://jeff.news/article/3497
---
# Claude Opus 4.8, 코딩 에이전트로 쓰기엔 뭔가 망가졌다는 HN 제보

한 HN 사용자가 Claude Opus 4.8을 Rails 프로젝트에서 써봤더니, 파일 경로를 계속 지어내고 도구 호출도 엉뚱하게 반복하면서 사실상 GPT-2 시절 같은 경험이었다고 토로했다. 특히 실제 파일을 읽지 않고 존재하지 않는 경로에 sed나 cat을 날리며 15번 연속 실패했고, 모델은 같은 실수를 반복한 뒤 사과만 계속했다고 한다.

- 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`을 썼다고 인정함

> [!WARNING]
> 코딩 에이전트에서 “없는 파일 경로를 자신 있게 만들어냄”은 꽤 치명적임. 답변이 틀린 수준이 아니라, 실제 코드베이스 탐색 루프가 망가지는 문제라서 개발자가 계속 감시해야 함.

- 더 골 때리는 건 사과가 한 번으로 끝난 게 아니라는 점임
  - 작성자 말로는 같은 세션에서 이미 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 같은 안전한 도구를 우선 쓰는지, 실패한 명령을 반복하지 않는지, 방금 얻은 값을 다음 단계에서 제대로 재사용하는지가 업무 체감 품질을 크게 갈라요.

## 핵심 포인트

- Claude Opus 4.8이 실제 프로젝트 파일 경로를 확인하지 않고 존재하지 않는 경로를 추측했다는 제보가 나옴
- 모델이 Read 도구 대신 sed나 cat을 쓰고, 파일 없음 오류를 15번 연속 냈다고 함
- 컨텍스트 창이 15%밖에 차지 않은 상태에서도 도구 호출 실패와 느린 응답이 반복됐다는 점이 핵심 불만

## 인사이트

코딩 에이전트에서 제일 무서운 건 답을 틀리는 게 아니라, 파일 시스템 같은 검증 가능한 영역에서도 자신 있게 지어내는 습관임. 모델 성능 논쟁보다 실무에서는 이런 도구 사용 안정성이 체감 품질을 바로 갈라버림.