Claude가 쓸모없는 테스트를 1800개나 돌리고, 내 지시를 무시하고 더 만들어내네요

😂😂

내 프로젝트가 커지면서 이게 엄청난 문제였음. 시간의 7.8%를 빌드하는 데 쓰고 있었거든.

/insight를 실행해서 Claude가 참고하고 비교할 수 있는 내구적인 기준점(yardstick)을 측정할 아티팩트를 몇 개 만드는 걸 추천함.

나한테 효과가 있었던 해결책은 두 개의 세션을 쓰는 거였음. 세션 1은 사람이 쓰는 터미널임. 여기서 fable로 다음 큰 아이디어나 단계를 연구하고 계획함. 다른 하나는 opus를 쓰는 빌더임. 이건 24/7 돌아가면서 차/기차를 정리하고, 하루에 4번만 실행하며 전체 테스트는 하루에 한 번만 돌림.

시간당 4k loc 처리하던 게 90% 가동률로 30k까지 올라감.

서브 에이전트 작업자를 3~4개로 제한해서 5시간 창당 사용량 제한에 걸리지 않게 함. 내가 터미널에 있을 땐 8~12개까지 늘림.

그다음엔 프로젝트에 커스텀 스킬을 써서 다중 일 오케스트레이션 상황에서도 정돈된 상태를 유지함.

세션 2는 압축(compaction)을 사용해 250k 컨텍스트를 돌림. 드리프트 문제는 없음. 훅이나 적절한 claude.md를 쓰면 컨텍스트에 의존하지 않고도 결정론적으로 일이 진행됨.

서브 에이전트는 90턴이나 200k 토큰까지 압축 없이 실행됨. 작업을 끝내지 못하면 새 작업자가 배포됨. 새 작업자는 이전 작업자가 하던 곳부터 신선한 컨텍스트로 이어받음.

opus 5 이후로는 그런 문제 겪은 적 없음. opus 4는 가끔 그랬지. 오케스트레이터로 opus 5.5 쓰고 있음?

팁 하나 주자면, 커스텀 테스터 서브 에이전트를 만드셈. 그 에이전트는 기본적으로 자기만의 'agent.md' 파일을 가지고 매번 새로 시작함. 거기에 규칙을 넣으셈. 전체 스위트를 돌리지 말라는 식으로. 그다음 메인 오케스트레이터 에이전트한테 테스트를 테스터 에이전트한테 위임하라고 지시하셈. 수정된 파일에 직접적으로 관련된 테스트에 집중하라고 하셈. 오케스트레이터가 뭘 테스트할지 결정해서 테스터 에이전트한테 넘기게 하거나, 오케스트레이터가 수정된 파일을 테스터 에이전트한테 넘기고 테스터가 뭘 테스트할지 알아내게 할 수 있음. 그 서브 에이전트는 haiku나 sonnet low 같은 저렴한 모델을 돌리면 됨. 그러고 나서 오케스트레이터한테 보고하는 거지.

그리고 선택된 테스트만 실제로 실행할 수 있는지 확인하셈. 대부분의 테스트 프레임워크는 테스트 그룹을 만드는 메서드가 있으니, 예를 들어 'fast/unit' 테스트 그룹을 만들고 느린 테스트는 다른 그룹으로 빼두는 게 가치 있음. 그다음 그 그룹들을 테스터 에이전트한테 입력해주면 어떤 옵션이 있는지 알게 될 거임.

튜닝 값을 하나 바꿔보고 테스트가 몇 개나 깨지는지 봐봐. 수십 개는 깨질걸, 왜냐면 그 테스트들은 아무것도 유용한 걸 테스트하고 있지 않으니까. 내 프로그램에 이런 저품질 테스트가 많으면 LLM이 저품질 테스트를 더 많이 만들어낸다는 걸 알게 됐음.

난 LLM이 작업 중인 내용을 개발할 때 테스트를 쓰게 놔두고, 나중에 그 테스트들을 지운 뒤 내가 수동으로 지정한 고수준 통합 테스트로 대체하는 좋은 균형점을 찾았음.

그러니까 테스트를 전부 다 뜯어내고, 몇 시간이나 하루 정도 시간을 들여서 뜯어낸 테스트들을 살펴보고, 그걸 실제 시스템 동작을 테스트하는 기반으로 삼으셈.

하지 말라고 말하는 대신, 뭘 해야 할지 말해주셈. 작업을 어떻게 확인하고 싶은지 알려주면 됨.

항상 일어나는 일임. 내가 하는 방식은 계획을 세우고 목표 프롬프트를 만드는 명령어를 만드는 거임.
계획은 각 단계마다 규칙을 읽고 서브 에이전트를 사용하도록 명시적으로 업데이트됨(서브 에이전트는 기본적으로 작업에 대한 규칙을 메모리에 로드함). 그다음 목표 프롬프트가 Claude 자신의 규칙에 반하지 않는 효과적인 목표 프롬프트를 생성함.
규칙의 일부는 컨텍스트가 25~30%를 넘을 수 없다는 거임. 넘어가면 압축(메인 스레드)하거나 핸드오프를 작성해서 새 서브 에이전트한테 넘겨줌.

난 테스트 스위트 같은 건 존재하지 않고, 테스트를 위해 소프트웨어를 실행할 수 없다고 말함. 내 경험상 그게 대체로 잘 먹힘. 테스트가 필요하면 테스트 생성만을 위한 세션을 따로 만들 거임.

하지만 맞음, Claude는 그 검증이 실제로 가치가 있든 없든 강박적일 정도로 확인하는 걸 좋아함.

신선한 터미널에 새 컨텍스트를 띄우고 이 포스트에 쓴 내용을 그대로 복사해서 붙여넣으셈. "수정한 섹션에 대해서만 로컬 및 CI에서 테스트를 실행할 것" 같은 인간적인 제안을 추가하고, 변경 사항의 범위를 PR이나 브랜치 단위로 조금 더 작게 좁히면 도움이 될 거임.

난 속도를 우선시하고 싶을 때 Claude한테 "빨리 움직이고 부숴버려(move fast and break things)"라고 말하는데, 거짓말 안 하고 진짜 효과 있음. 그냥 얘가 실수로 궤도를 벗어나서 테크노 봉건주의 감시 국가를 한 방에 만들어버리지 않길 바랄 뿐임. 좀 더 진지하게 말하자면, 그렇게 말하는 게 효과가 있는 이유가 서로 다른 개발 철학에 대한 학습 데이터와 관련이 있는지 궁금하긴 함.