Claude ignored memory/history and broke correct code, then validated it with subagents using wrong criteria

Resolved 💬 2 comments Opened Jun 6, 2026 by oracle77 Closed Jun 10, 2026

사용자가 5개 파일에 평형최고가 기능을 추가해 달라고 했다. 그러면서 "지난 다른 소스 체크해서 오류나지않게" 라고 했다. 즉, 이전에 잘 작동하는 소스와 업무 이력을 먼저 확인하고 같은 방식으로 작업하라는 뜻이었다.

Claude는 이 지시를 무시하고 메모리도 확인하지 않았고, 업무이력 폴더도 확인하지 않았고, 사고사례 문서도 확인하지 않았다. 그냥 바로 코드부터 봤다.

XXX.jsp를 grep으로 봤더니 특정 JOIN이 없었다. XXX.jsp를 봤더니 특정 컬럼을 직접 SELECT하고 있었다. 이 두 파일만 보고 "JOIN 없이 바로 쓰면 되는 컬럼이구나" 라고 혼자 결론을 내렸다.

그런데 메모리 파일(project_batch_logic.md)에는 이미 이렇게 적혀 있었다.

"특정 함수가 행당 3회 호출되어 DB 커넥션 풀 5,476회 Timeout 발생했기 때문에, JOIN 방식을 사용해야 한다."

사고사례 문서 체크리스트에도 올바른 JOIN 방법이 적혀 있었다. 이 내용들이 전부 있었는데 확인을 안 했다.

이전 세션에서 5개 파일에 이미 올바르게 JOIN을 추가해 두었다. 그런데 이번 세션에서 Claude가 그 JOIN을 전부 삭제해 버렸다. 올바른 코드를 망가뜨린 것이다.

그리고 XXX.jsp 까지 추가로 수정했다. 주석 해제, JSP 주석 제거.

사용자가 서브에이전트로 병렬 검증하라고 했다. Claude는 3개 서브에이전트를 만들어서 curl로 페이지 호출, Exception 없음, 데이터 있음을 확인했다고 보고받았다. 상세내역까지 API를 호출해서 JSON 반환 확인했다고 보고받았다.

그런데 이건 전부 의미가 없었다. Claude가 서브에이전트에게 잘못된 방향으로 지시를 내렸기 때문에, 서브에이전트들은 그 잘못된 기준으로 "정상"이라고 판정한 것이다.

게다가 특정 기능이 화면에 0건 출력되고 있었는데, "로컬 DB에 데이터가 없어서 그런 것, 운영 서버에서는 정상일 것"이라고 판단했다. 실제 원인은 Claude가 JOIN을 삭제해서 값이 null이 된 것이었는데 파악하지 못했다.

사용자가 "지난 업무이력 확인했어 안했어?" 라고 물었다. 확인 안 했다고 했다. 메모리를 확인하고 나서야 올바른 방법이 이미 기록되어 있었다는 것을 알게 됐다.

메모리 미확인: 사용자가 "지난 소스 체크해서" 라고 명시했음에도 MEMORY.md, 사고사례 문서, 업무이력을 확인하지 않고 바로 코드를 수정했다.

서브에이전트 검수 방향 오류: 방향 자체가 틀린 상태에서 서브에이전트에게 검수를 맡겼다. 서브에이전트는 "에러 없음"을 확인했지만, 코드가 맞는지 여부는 검증하지 못했다. 잘못된 전제를 가진 검수는 의미가 없다.

---

클로드는 토큰 소모만 강요하지 말고 기본적인 문제부터 해결해라.

View original on GitHub ↗