Claude가 멍청한 게 아니라, 제가 일을 개떡같이 줬습니다 - 인프런

저는 Claude Code를 꽤 자주 욕했습니다. 분명 기존 패턴 따라가라고 했는데 새 유틸 파일을 만들고, 테스트 깨지면 안 된다고 했는데 테스트 이름을 바꾸고, 새 구조 만들지 말라고 했는데 어디선가 당당하게 새 구조를 들고 옵니다. 그때 제 반응은 대충 이랬습니다. 아, 또 혼자 달린다. 사실 그건 Claude가 튄 게 아니라, 제 지시들이 서로 박치기하기 시작했다는 신호였습니다.

로그를 다시 보다가 조용해졌습니다. 요구사항을 중간에 바꾼 것도 저였습니다. 실패한 테스트 로그를 네 덩어리째 던진 것도 저였습니다. "아까 말한 방식"이라고 적어놓고, 정작 그 방식이 어디에 있는지는 안 남긴 것도 저였습니다. Claude가 멍청했던 게 아니라, 제가 일을 개떡같이 줬습니다.

장면 요약: 정리 없는 인계는 도움 요청이 아니라 파일탑 주문서에 가깝습니다.

먼저 결론부터 말하면, 긴 세션에서는 `tasks.md` 같은 작업 기준표에 최소한 세 가지를 남겨야 합니다.

지금 목표와 완료 기준
절대 건드리면 안 되는 파일이나 결정
이미 실패해서 버린 접근

처음엔 Claude를 욕했습니다

AI 코딩이 이상해지는 순간은 묘하게 익숙합니다. 처음에는 잘합니다. 파일도 읽고, 기존 패턴도 따라오고, 테스트도 돌립니다. 그래서 방심합니다. 초반 성공을 보고 기준 정리를 생략합니다. UI 조금 고치고, 테스트 하나 보고, 리팩터링은 보류하고, 새 요구사항을 끼워 넣고, 중간에 "이 파일은 건드리지 말라"고 말합니다. 그러고 나서 두 시간 뒤에 Claude가 이상한 코드를 만들면 모델이 아직 멀었다고 말합니다.

솔직히 말하면 편한 핑계입니다. 모델 탓을 하면 제가 만든 난장판은 안 봐도 되니까요.

근데 로그를 보니 제가 더 수상했습니다

긴 세션의 대화 로그를 보면 꽤 민망합니다. 처음에는 "기존 패턴만 따라가라"고 했습니다. 40분 뒤에는 "아, 이 파일은 건드리지 말라"고 덧붙였습니다. 한 시간 뒤에는 테스트 기준을 바꾸면서, 이미 실패해서 버린 접근은 따로 적어두지 않았습니다. 그러고 나서 Claude가 새 유틸 파일을 만들면 화를 냈습니다. 왜 갑자기 이걸 만들었지?

답은 로그에 있었습니다. 제가 판을 계속 바꿨고, 무엇이 아직 유효한지 한 번도 정리하지 않았습니다. Claude 입장에서는 이게 전부 같은 컨텍스트입니다. 오래된 제약, 실패 로그, 버린 시도, 지금 기준이 한 대화 안에 섞여 있습니다. 그런데 저는 그중에서 현재 기준만 정확히 꺼내오길 바랐습니다. 이건 똑똑한 도구를 쓰는 태도가 아닙니다. 그냥 운에 기대는 겁니다.

운 좋으면 멀쩡한 코드가 나오고, 운 나쁘면 자신감 넘치는 사고가 납니다. 더 무서운 건 후자입니다. Claude는 틀릴 때도 속도가 빠릅니다.

긴 프롬프트는 성의가 아니라 쓰레기봉투였습니다

저도 한동안 프롬프트를 길게 쓰면 해결된다고 믿었습니다. 규칙을 더 붙이고, 예외를 더 적고, "절대 하지 마세요"를 더 많이 넣으면 나아질 줄 알았습니다. 짧은 작업에서는 통합니다. 하지만 긴 작업에서는 긴 프롬프트가 성의가 아니라 쓰레기봉투가 됩니다. 중요한 결정, 오래된 대화, 버린 아이디어, 아직 살아 있는 규칙이 전부 한 봉투에 들어갑니다. 그러면 Claude는 추측합니다.

방금 바뀐 테스트가 진짜 완료 기준인가?
금지했던 파일은 지금도 건드리면 안 되는가?

기준표가 없으면 Claude는 눈치껏 실행합니다. 그다음에는 아무도 시키지 않은 새 유틸 파일이 튀어나오고, 건드리지 말라던 테스트 이름이 바뀝니다. 추측이 들어간 순간부터 결과는 랜덤입니다. 다만 랜덤인데 빠릅니다. 그래서 더 위험합니다.

장면 요약: 컨텍스트를 다 붓는다고 현재 기준이 살아나지는 않습니다.

자동 compaction은 기억상실 보험이 아닙니다

자동 compaction은 필요합니다. 컨텍스트가 차면 요약해서 다음 흐름으로 넘겨야 합니다. 문제는 그걸 만능 보험처럼 믿는 순간입니다. 자동 요약은 짐을 줄여줍니다. 하지만 무엇이 핵심이고 무엇이 잡동사니인지는 항상 정확히 골라주지 않습니다.

이 파일은 건드리면 안 된다.
이 테스트가 통과해야 끝이다.
이 구현은 일부러 제외했다.
이 UI 버그는 이전에 이미 고쳤다.
이 이름은 팀 컨벤션이라 바꾸면 안 된다.

이런 건 참고 자료가 아닙니다. 작업의 울타리입니다. 울타리가 빠지면 Claude는 넓은 들판을 자유롭게 뜁니다. 문제는 그 들판이 우리 프로덕션 코드라는 겁니다.

위 그림은 예쁜 비유가 아닙니다. 제가 실제로 해야 했던 일입니다. 흩어진 대화와 실패 로그를 다음 실행자가 읽을 수 있는 작업 기준표로 바꾸는 것. 그걸 안 하고 모델 탓을 하고 있었습니다. 그래서 필요한 건 "더 긴 프롬프트"가 아니라 "다음 세션이 바로 읽을 작업 기준표"였습니다.

tasks.md는 다음 세션의 작업 기준표입니다

`tasks.md`는 예쁜 문서가 아닙니다. 다음 세션이 무엇을 믿고 움직여야 하는지 적어두는 작업 기준표입니다. 나쁜 인계는 보통 이렇게 생겼습니다.

로그인 만료 버그 좀 봐줘.
토스트는 그대로 두고, 테스트도 깨지면 안 돼.
아까 실패한 방식은 하지 말고.
적당히 기존 패턴 맞춰서 해줘.

이걸 그대로 던지면 Claude는 "아까"와 "적당히"를 추측합니다. 정리하면 이 정도면 충분합니다.

목표: 로그인 만료 시 사용자를 `/login`으로 보내고, 기존 세션 토스트는 유지한다.
금지: `auth/client.ts`의 public API 이름은 바꾸지 않는다.
검증: `pnpm test auth`와 `pnpm test e2e/login-expiry.spec.ts`가 통과해야 끝이다.
버린 접근: 토큰 TTL을 늘리는 방식은 보안 정책 때문에 제외했다.
다음 세션: 먼저 실패 로그 `logs/auth-expiry-2026-06-22.txt`를 읽고 시작한다.

이걸 안 남기면 Claude는 현재 위치를 추측합니다. 그리고 저는 그 추측을 다시 고치느라 시간을 씁니다. AI에게 일을 맡긴다고 말하면서 작업 기준표를 안 주는 건 이상합니다. 사람한테도 그렇게 일 주면 사고가 납니다. Claude는 다르지 않습니다. 차이가 있다면 사고를 훨씬 빠르게 낸다는 것뿐입니다.

서브 에이전트는 멋이 아니라 격리입니다

서브 에이전트라는 말은 괜히 거창합니다. 여러 AI가 협업하고, 역할을 나누고, 뭔가 미래형 개발 조직처럼 보입니다. 근데 실제 이유는 훨씬 덜 멋있습니다. 한 세션에 다 넣으면 망합니다. 다만 아무 일이나 쪼개라는 뜻은 아닙니다. 파일 범위, 검증 명령, 필요한 맥락이 분리되면 나누고, 같은 파일을 동시에 고쳐야 하면 메인 세션이 직접 잡는 편이 낫습니다.

예를 들어 로그인 만료 버그 하나도 한 세션에 통째로 던지지 않습니다. 메인 세션에는 증상, 금지 파일, 완료 기준만 남깁니다. 그리고 일을 쪼갭니다.

로직 담당은 토큰 만료 판정과 redirect 조건만 봅니다.
UI 담당은 토스트가 사라지지 않는지와 로딩 상태만 봅니다.
테스트 담당은 만료 토큰 재현과 실패 로그만 봅니다.
메인 세션은 세 결과를 합치고 `pnpm test auth`로 끝을 확인합니다.

AI를 많이 쓰자는 이야기가 아닙니다. AI에게 쓸데없는 기억을 먹이지 말자는 이야기입니다.

다음 사고도 Claude 탓으로 넘길 건가요

Claude Code를 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람이 아니었습니다. 작업 기억을 파일로 고정하는 사람이었습니다. 내일부터 바꿀 건 거창하지 않습니다.

다음 프롬프트 전에 목표, 금지사항, 검증 명령을 적습니다.
실패해서 버린 접근은 대화가 아니라 작업 기준표에 남깁니다.
긴 작업은 로직, UI, 테스트처럼 기억 단위별로 분리합니다.

장면 요약: 30초 멈추면 적어도 덜 망합니다.

그건 디버깅이 아닙니다. 실패한 인계를 모델 탓으로 넘기는 일입니다. 다음 프롬프트를 보내기 전에 30초만 멈추면 됩니다. 그 기준표에 목표, 금지사항, 검증 명령이 없으면 아직 시킬 때가 아닙니다.