[레딧-클로드코드] "처음부터 다시 만든다면?" 회고 프롬프트와 구현-리뷰 자동 루프 + 유저 댓글.

LLM에게 복잡한 기능을 맡기면 한 번에 완성하지 못하고, 반복 지시해도 코드만 쌓일 뿐 리팩토링은 하지 않는다. 15년차 Principal SWE가 "LLM은 훌륭한 코더지만 형편없는 소프트웨어 엔지니어"라는 관찰에서 출발한 워크플로우다.

"처음부터 다시 만든다면?" — 회고 프롬프트

• 컨텍스트 윈도우가 75% 찼거나 LLM이 고전할 때, "지금까지 알게 된 것을 바탕으로, 이 기능을 처음부터 다시 구현한다면 어떻게 달리 하겠는가? 특히 코드 복잡성과 파편화를 줄이는 리팩토링 관점에서"라고 묻는다
• 상태 머신의 "rewind" 기능 구현에서 3일간 엣지 케이스와 씨름하다, 이 프롬프트 후 재시작하니 클린 버전을 한 번에 완성
• 핵심은 LLM에게 매몰 비용(sunk cost)을 버릴 허가를 주는 것. 스스로는 기존 접근법을 포기하지 않는다

구현-리뷰 자동 루프: get-it-right 워크플로우

• 구현 에이전트가 코드를 작성하면, 리뷰 에이전트가 리팩토링 후 재시작할지 계속 진행할지 판단한다. 리뷰어가 완료를 선언할 때까지 루프가 반복된다
• 리뷰 에이전트는 완전히 새로운 스레드에서 실행되며, 서브에이전트를 스폰하여 코드를 분석한다
• 리뷰 히스토리를 다음 이터레이션에 넘길지, 초기 프롬프트만 다시 줄지 실험 중. 전체 히스토리는 매몰 비용 문제를 재도입할 수 있어, "시도한 것과 실패 이유"만 요약해서 넘기는 구조적 핸드오프가 유망하다

커뮤니티 인사이트 (댓글)

• 사전 리팩토링 지시("코드를 스캔하고 리팩토링 기회를 찾아라")는 콜 사이트와 터치 포인트에 대한 컨텍스트 없이는 잘 작동하지 않음. 한 번 구현을 시도한 후에 리팩토링을 요청하면 효과가 훨씬 좋다
• Opus로 계획·태스크 분해 후, 별도 세션에서 Sonnet/Haiku로 구현하는 워크플로우도 있음. 18개 섹션으로 구성된 계획 스킬을 사용하여 플랜 모드에서 리팩토링 기회를 사전 탐색
• 기능 추가 전에 "debt scan"을 먼저 요청하면("기능 X를 추가하기 전에, 유지보수를 어렵게 만들 기존 패턴을 플래그하라") 리팩토링 시점을 앞당길 수 있음