AI가 짠 코드, 왜 리뷰하면 항상 뭔가 아쉬울까?

커서맛피자(@cursormatfia)님 금일 강의 발췌.
AI가 짠 코드, 왜 리뷰하면 항상 뭔가 아쉬울까?
AI가 모르는 게 2가지 있기 때문임.

기준과 의도
① 우리 팀이 생각하는 "예쁜 코드"의 기준
② 이 작업을 왜 이렇게 설계했는지의 의도
code-convention.md → 코드 스타일 기준
adr.md → 기술적 결정사항 기록
프로젝트가 시작되면 만들고, 계속 업데이트하는 살아있는 문서야.
이 두 문서가 있으면 AI가 "왜 이렇게 짰는지"를 이해하고
리뷰 퀄리티가 완전히 달라짐.
없으면 그냥 일반론적인 피드백밖에 못 함.

code-convention.md

adr.md

하네스 핵심 3대장
일단 하네스 핵심 3대장을 알아야함.
skills - 반복 지식을 파일로 만들어 항상 참고시키는 것
sub agent - 별도 세션을 띄워서 독립 작업 시키는 것 (fresh eye)
fork - 현재 컨텍스트를 복제해서 재활용하는 것

sub agent vs fork
이 둘 언제 쓰냐고?
판단 기준은 "컨텍스트를 살릴 것이냐, 비울 것이냐"임.
* 코드리뷰 → sub agent.
맥락 없는 fresh eye가 오히려 좋음.
선입견 없이 코드만 보고 판단해야 하니까.
(에이전트도 자기가 한 작업에 확증편향이 생김)
대신 평가 기준 문서는 따로 먹임. 편향 없이, 기준은 있게.
* 기능 확장, 문서 생성 → fork.
이미 쌓아놓은 컨텍스트가 아까울 때.
다른 세션에 처음부터 다시 설명하기 싫을 때.
컨텍스트 복제본을 만들고 1회성으로 쓰고 버린다.
(리뷰로 예시를 들자면, ADR과 가이드문서를 메인세션에서 작성해가지고 컨텍스트 오염을 시키기 싫잖아?)

실전 워크플로우
실제로 돌리는 플로우는 이렇게 생김.
① 메인 세션에서 요구사항 구체화 + 아키텍처 설계 (사람이 직접 개입)
→ 그 뒤에, fork 세션에서 설계 의도 문서 생성 + ADR 업데이트
② sub agent가 평가 기준 수립
→ code-convention + ADR + 설계 의도 문서 읽고
→ code-quality-guide.md 생성
③ 구현 (메인 세션)
→ code-quality-guide.md 먹이고 진행
④ 리뷰 (sub agent)
→ code-quality-guide.md 먹이고 진행
기준을 먼저 만들고, 그 기준으로 짜고, 그 기준으로 검수.

code-quality-guide.md

그리고 중요한 거.
* 리뷰 반영은 반드시 작업한 메인 세션이 해야 함.
새 세션 열어서 하면 디테일한 뉘앙스가 유실됨.
코드는 옮겨지는데 "왜 이렇게 짰는지"가 사라짐.

자동화 방향도 눈치 빠른 사람은 보일 것임.
나는 개인적으로 /fork 활용법이 인상적이었음!
이상, 커서맛피아(@cursormatfia)님의 금일 라이브강의 핵심 내용에서 얻은 인사이트를 정리해보았음.
풀버전 링크도 남길게. (나 허락받고 포스팅하는것임..)