좋은 사례 공유 감사합니다. 유형별로 쪼개는 구조가 확실히 늘고 있는 것 같습니다.

저도 최근에 리뷰 작업을 세 개로 쪼개서 돌려봤는데, 쪼갠 것 자체보다 무엇을 기준으로 쪼갰는지가 결과를 갈랐습니다. 저는 “동작하는가 / 규칙이 허용하는가 / 본문 주장이 코드와 맞는가” 세 축으로 나눴는데, 앞의 두 개를 한 곳에 묶었을 때는 거의 항상 “동작하니까 통과”로 끝나더군요.

다만 쪼개면 새로 생기는 비용도 있었습니다. 셋 중 하나가 끝까지 결과를 안 냈고, 다른 하나는 보고에 숫자가 틀려 있었습니다. 산문 속 숫자는 diff 검토로는 안 걸려서 따로 대조해야 했습니다.

그래서 요즘은 쪼갤지 말지를 이렇게 정합니다 — “이 관점이 없으면 놓치는 게 구체적으로 무엇인가”에 답할 수 있으면 쪼개고, 아니면 합칩니다. 관점 수를 늘리면 검증할 것도 같이 늘어나서요.

세 관점으로 나눠 돌려본 기록에 브리프 원문까지 정리해뒀습니다. 혹시 참고되실까 해서 남깁니다.