리뷰어는 같은데 결과가 다르다 — AI 구현 품질은 리뷰 앞에서 갈린다

결론부터 말하면, AI 가 짠 코드의 품질은 리뷰어가 얼마나 똑똑한지보다 리뷰 앞에서 정해진다. 코드를 한 줄도 쓰기 전에 사람이 설계를 승인했는지, 사람이 처음 보는 PR 이 이미 한 번 걸러졌는지. 이 두 가지다. 다 읽고 나면 내 작업에 어느 방식을 쓸지 작업 크기로 고를 수 있다.

원래 하던 방식

꽤 오래 이렇게 일했다.

Claude Code 에 "만들어" → 구현 → PR → 리뷰 커맨드 → 화면 Before/After 캡처

문구 하나, 설정값 하나 바꾸는 일이면 이게 제일 빠르다. 불만도 없었다.

그러다 회사(Rails 로 만든 SaaS)에 AI 구현 하네스가 들어왔다. 하네스는 AI 에게 일을 시키는 순서와 멈추는 곳을 팀이 미리 정해 둔 틀이다.

/plan → plan.md (설계 요약) 를 사람이 읽고 approved: true
  → /implement (git worktree 에서 구현 → spec → rspec · rubocop
                → 셀프 리뷰 → Draft PR → 사전 리뷰 → 스스로 고치기 최대 2회)
  → 사람이 Ready → 최종 리뷰

처음 든 생각은 솔직히 이랬다. 「최종 리뷰는 내가 쓰던 리뷰 커맨드랑 같은 리뷰어인데, 뭐가 달라지나?」

나란히 놓고 보니 차이는 리뷰가 아니라 그 앞에 있었다.

갈라지는 지점

단계	「만들어」	하네스
설계	대화하다 보면 암묵적으로 정해짐	plan.md 로 고정. 사람이 승인하기 전엔 코드 0줄
요구 해석	티켓에 적힌 해결책을 그대로 짜기 쉬움	「티켓의 해결책을 믿지 말고 상위 요구로 돌아가라」는 단계가 따로 있음
멈추는 곳	그날 세션 판단	규칙으로 4곳 — 설계 승인 · 전제 확인 · 마이그레이션 직후 · 보고
spec	구현 뒤에 맞춰 씀	테스트 케이스 표 1행 = example 1개
사람이 처음 보는 PR	날것	사전 리뷰로 한 번 걸러진 Draft
「왜 이렇게 했나」	세션 닫으면 사라짐	plan.md 로 남음

늘어난 건 자동화가 아니라 「멈추는 곳」

표를 다시 보면 하네스가 더한 건 대부분 멈추는 지점이다. 사람이 판단하는 자리를 코드 앞쪽으로 당겨서 고정했다.

방향이 틀린 걸 다 짠 코드에서 잡으면 그 코드는 통째로 버린다. plan.md 단계에서 잡으면 버리는 건 설계 메모 한 장이다. 리뷰어를 아무리 좋은 걸 써도 이 비용 차이는 못 메운다.

하네스는 Ready 와 머지를 일부러 안 한다. 생성된 코드의 책임은 Ready 를 누른 사람에게 있다. 책임 경계를 버튼 하나에 묶어 둔 건데, 이게 꽤 마음에 들었다.

그렇다고 상위 호환은 아니다

화면 확인이 빠져 있다. 원래 방식엔 Before/After 캡처가 흐름 안에 있었는데, 하네스엔 「화면 확인은 사람이 한다」 한 줄뿐이다. 화면이 바뀌는 PR 이면 결국 옛 도구를 뒤에 붙이게 된다.

작은 작업엔 무겁다. 승인을 건너뛰는 모드가 있어도 worktree 와 사전 리뷰 비용은 그대로다.

plan.md 를 손으로 못 고친다. 손으로 고치면 조사 결과와 어긋난 채 구현되기 때문에 대화로 다시 만들어야 한다. 은근히 귀찮다.

브랜치가 묶인다. git 은 같은 브랜치를 두 worktree 에서 동시에 checkout 하지 못한다. 하네스가 worktree 에 브랜치를 잡고 있는 동안 기존 리뷰 사이클 커맨드를 돌리려면 worktree 부터 치워야 한다.

어느 쪽을 쓸까

작업	고르는 쪽
문구 · 설정값 하나	「만들어」
방법은 뻔한데 파일이 여러 개	어느 쪽이든. 하네스면 승인 생략 모드
설계 선택지가 있다 · DB 변경 · 영향 조사가 필요	하네스
화면이 바뀐다	하네스 + 끝에 Before/After 캡처를 덧붙임

아직 못 잰 것

숫자는 아직 없다. 같은 크기의 티켓을 두 방식으로 하나씩 돌려서 걸린 시간과 리뷰 지적 수를 비교해 볼 생각이다. 그 전까지 「방향이 틀린 걸 코드 전에 잡는다」는 흐름의 구조가 그렇다는 얘기지, 잡은 사례로 증명한 건 아니다.

프롬프트를 잘 쓰는 것과 하네스를 짜는 게 어떻게 다른지는 하네스 vs 프롬프트 엔지니어링에 따로 적어 뒀다.

팀에 AI 구현 흐름을 들이면서 어디서 멈추게 할지 고민 중이라면 negabaro 에 물어봐도 된다. 우리도 지금 이 순서를 실제 업무에서 굴려 보는 중이다.