10분 일하고 60분 테스트하기

전 TDD 팬이라서 이런 방식이 좋네요.

그건 수정 사항을 배포하기가 얼마나 쉬운지, 그리고 위험이 어느 정도인지에 따라 다릅니다.

임베디드 시스템은 업데이트가 거의 없고 물리적 접근이 필요한 경우처럼 업데이트가 매우 번거로울 수 있죠. 웹은 업데이트가 암묵적으로 이루어지고요.

은행, 군사, 의료처럼 항상 작동해야 하는 중요한 시스템이라면 추가 검사가 필요할 겁니다. 하지만 의료용 대시보드라면... 뭐... 그냥 배포하세요.

전체 테스트 스위트를 돌릴 필요가 없다면 하지 말라고 시키면 되죠 🤷🏻‍♂️. 언제 무엇을 테스트할지 지시하세요.

그래도 맞는 말이긴 합니다.

나도 정확히 이 문제 때문에 'lean-tests' 스킬을 만들어서 다듬어왔음. 모든 앱이 테스트랑 소스 코드 비율이 2:1이 되고, 파이프라인은 한참 걸리고, 로컬 테스트 실행도 엄청 오래 걸림. 전체 워크플로우가 느려짐. 똑같이 해보는 거 추천함. 그냥 테스트 감사를 시키는 거임. 절대 실패할 리 없는 테스트, 중복되는 테스트, 더 빠르게 최적화할 수 있는 테스트 같은 것들 말이야. Claude한테 스킬을 만들게 시켰고, 여러 레포지토리에 걸쳐서 계속 다듬었음. 커버리지 체크도 해서 테스트가 누락되지 않게 함. 나는 Opus가 초기 분석을 해서 시간 잡아먹는 부분을 찾게 하는 플로우를 씀. 그다음 여러 서브 에이전트한테 일을 넘김(보통 GPT 6.1 sol이나 sonnet한테 넘김). 그러고 나서 새로운 에이전트가 각 단계를 분석해서 빈틈이나 놓친 부분을 찾음. 마지막으로 필요한 테스트만 복구하는 식임.

테스트를 중요하게 생각하지 않는다면, 이 부분은 Gemini 모델이 Claude보다 약간 더 나은 점입니다.

하지만 맞아요, Claude는 테스트가 메인 미션과 관련이 없어도 테스트에 집착하죠...

그냥 Claude의 특성이라고 생각하렵니다.

풀스택 프로젝트에서 Claude Code로 겪은 일인데, 폼 필드 하나 추가하고 나니 테스트 12,000개를 돌리더군요. 45분 걸렸습니다. 테스트 스위트가 앱보다 더 빨리 커지고 있어요.

Claude에게 관련 모듈만 테스트하라고 시키고, 커밋하고 푸시할 때 전체 워크플로우를 실행하는 CI 워크플로우(GitHub 등)를 구축하세요. 문제가 있으면 그때 수정하면 됩니다.

그래서 저는 스프린트 모델을 선택했습니다. 스프린트 마지막에 전체 E2E 테스트를 수행하고, 작업 중에는 업데이트된 부분에 대해서만 E2E를 돌리죠. 제 애플리케이션이 너무 커져서 스프린트 마감에 거의 하루가 걸리기 때문에, 4일 코딩하고 1일은 스프린트 마감하는 주간 스프린트를 운영합니다. Claude에게 스토리 포인트를 추정하게 하고 스프린트당 80~100포인트를 목표로 하는데, 4일 코딩 분량으로는 꽤 정확합니다.