Claude가 스스로 결과물을 검토하게 했더니 작업 품질이 3배 좋아짐

이번 달 내 Claude Code 워크플로우에서 가장 큰 업그레이드는 더 똑똑한 프롬프트나 새로운 기술이 아니었다. 바로 Claude가 작업을 완료했다고 말하기 전에 스스로 숙제를 검사하게 만든 것이었다.

문제는 이거다: Claude가 코드를 작성하고 테스트를 통과하면 "완료"라고 말하고, 겉보기엔 진짜 끝난 것 같다. 그런데 막상 브라우저를 열어보면 모바일에서 모달이 넘치고, 버튼은 작동 안 하고, 태블릿 너비에서는 레이아웃이 깨져 있다. 전형적인 상황이지. 테스트 통과는 코드가 올바르다는 걸 검증할 뿐, 기능이 실제로 작동한다는 걸 보장하지는 않는다.

그래서 이제는 Claude가 직접 눈으로 확인하기 전까지는 어떤 것도 완료된 것으로 간주하지 않는다. Chrome DevTools MCP를 사용해서 다음을 수행하게 한다:

• 방금 변경한 페이지로 이동
• 모바일, 태블릿, 데스크톱 너비에서 스크린샷 촬영
• 그 스크린샷을 직접 보고 UI가 제대로 렌더링되었는지 확인
• 흐름을 따라 클릭해보기 (모달 열기, 폼 제출, 엣지 케이스 확인)
• 깨진 부분 수정 후, 다시 스크린샷을 찍어 확인

중요한 사고방식의 전환은 이것이다: "내가 검토할 수 있게 스크린샷을 찍어라"가 아니라, "스크린샷을 찍고, 네가 직접 보고, 뭐가 잘못됐는지 말해줘"라는 것이다. Claude는 코드에서 추론하는 대신 렌더링된 화면을 빤히 쳐다보고 있을 때 시각적 버그를 잡아내는 데 정말 능숙하다.

이 방식을 시작한 이후로 Claude가 먼저 잡아내지 못한 버그를 내가 발견하는 일은 거의 없어졌다. 1차 통과 품질이 대략 3배 정도 올라갔고, 내가 QA 부서 역할을 할 필요도 없어졌다.

자동으로 하고 싶다고? CLAUDE .md 파일에 이걸 넣으면 요청하지 않아도 UI가 변경될 때마다 실행된다:

솔직한 트레이드오프: 공짜는 아니다.

스크린샷은 이미지이고, 이미지는 토큰을 많이 잡아먹는다. 3개의 뷰포트와 수정 후 재촬영까지 더해지면 금방 쌓이기 때문에, 예전엔 간단한 코드 수정이었던 작업이 이제는 컨텍스트 윈도우와 사용량 제한을 꽤 많이 소모하게 된다. 긴 세션에서는 그 추가적인 이미지 로드가 더 빨리 압축(compaction)을 유발하는데, 주의하지 않으면 오히려 품질이 떨어질 수도 있다.

또한 더 느리다. 루프마다 이동, 스크린샷, 분석, 수정, 재검증 과정을 거치므로 작업당 실제 소요 시간은 늘어난다.

그리고 만능 해결책은 아니다. 에뮬레이션된 뷰포트는 실제 iOS Safari가 아니므로 기기별 특이사항은 여전히 빠져나갈 수 있고, 미묘한 로직이나 레이스 컨디션보다는 시각적/레이아웃 버그를 훨씬 더 잘 잡아낸다. 초록색 스크린샷들만 보고 안심하지 마라.

나에게는 여전히 이 계산이 이득이다: 토큰 비용은 사용자에게 깨진 모달을 배포하고 나중에 버그 리포트를 처리하는 비용보다 훨씬 저렴하다. 하지만 예산이 빠듯하거나 긴 세션을 진행 중이라면, 모든 작업에 실행하지 말고 실제로 UI를 건드리는 변경 사항에만 적용해라.

다른 사람들도 이런 자체 검증 루프를 돌리는지, 그리고 어디까지 활용하는지 궁금하다.