AI 코드 품질, 리뷰 전에 막아야 하는 이유 | DAKER 커뮤니티

에이전트가 코드를 빠르게 만들어내는 환경에서는, 사람 리뷰만으로 품질을 지키기 어려워지는 순간이 금방 찾아옵니다. diff 대기열이 리뷰 속도보다 빨리 쌓이기 시작하면, 문제는 코드 생성 능력이 아니라 그 변경을 걸러내는 방식에 생깁니다.

Addy Osmani가 짚은 핵심도 여기에 있습니다. 에이전트 코드 품질은 사람의 최종 확인에만 기대는 것이 아니라, 하네스와 환경 안의 제약, 즉 quality gate에서 먼저 걸러져야 합니다. 사람의 역할이 사라지는 것이 아니라, 자동 가드레일이 놓치거나 의도와 아키텍처 판단이 필요한 지점으로 이동하는 셈입니다.

에이전트 코딩에서 먼저 세워야 할 것은 검증선입니다

Claude Code나 Codex에 리팩터링, 테스트 보강, 대량 이슈 처리, 마이그레이션을 맡길 때는 제안된 코드를 바로 병합 대상으로 보기보다, 그 변경이 어떤 검증을 통과해야 하는지부터 정하는 것이 좋습니다. 특히 사람이 모든 줄을 읽기 어려운 속도로 변경이 생길수록, 검증 capacity와 에이전트 change rate를 함께 조절해야 합니다.

품질 관리는 마지막 리뷰 단계가 아니라, 변경이 다음 단계로 넘어가기 전에 작동하는 검증선에서 시작됩니다.

quality gate가 맡는 역할

제약은 에이전트가 무엇을 해도 되는지 정하는 실행 장치입니다. 단위 테스트, 속성 테스트, 인수 테스트, 타입 검사, 보안 스캔, 성능 기준, 복잡도 기준처럼 서로 다른 신호가 각자 맡은 문을 지킵니다. 이 문들이 많을수록 무조건 좋은 것이 아니라, 각각이 어떤 품질 신호를 담당하는지 분명해야 합니다.

역압은 불량 변경을 다음 단계로 보내지 않는 힘입니다. 컴파일러가 거절하고, 테스트가 실패하고, 보안 정책이 막고, CI가 배포를 멈추면 사람은 더 주관적인 의도와 구조 판단에 집중할 수 있습니다.

자동 검사는 넓게 막고, 사람은 intent, taste, architecture처럼 자동화하기 어려운 판단에 남는 구조가 효과적입니다.

검증 루프가 밀리기 시작하면 선택지도 분명해집니다. 검증 용량을 늘리거나, 에이전트가 새 변경을 만드는 속도를 줄이거나, 품질 기준을 낮추는 결정을 명시적으로 내려야 합니다. 이 판단을 흐릿하게 두면 병목만 커지고 책임은 사람 리뷰에 다시 몰리게 됩니다.

공장 중간의 안전문처럼 설계해야 합니다

짧게 비유하면, 에이전트 코딩의 품질 관리는 마지막 계산대가 아니라 공장 중간중간의 안전문에 가깝습니다. 문이 자주 막히면 문을 없앨지, 생산 속도를 줄일지, 문을 더 만들지 결정해야 합니다. 중요한 점은 문제가 마지막에 한꺼번에 드러나지 않도록, 가능한 이른 단계에서 역압을 만드는 것입니다.

실무에 적용할 때 보는 기준

위험도가 다른 작업을 같은 줄에 두지 않습니다

문서 수정, 테스트 추가, UI 문구 변경처럼 낮은 위험 작업과 인증, 결제, 마이그레이션처럼 높은 위험 작업은 같은 방식으로 다루지 않는 것이 좋습니다. 에이전트에게 맡길 작업을 위험도별로 나누면, 어떤 검증선을 먼저 세워야 하는지도 더 분명해집니다.

낮은 위험 작업일수록 자동 gate를 먼저 둡니다

lint, typecheck, unit test, 접근성 검사, 보안 규칙, 변경 파일 제한처럼 실패하면 즉시 멈출 신호를 정해두면 됩니다. 이렇게 하면 사람이 모든 줄을 다시 읽는 대신, 자동으로 걸러진 결과를 바탕으로 더 중요한 판단에 시간을 쓸 수 있습니다.

결과뿐 아니라 경로도 확인합니다

에이전트 출력에는 무엇이 통과했는지뿐 아니라 어떤 파일을 건드렸고 어떤 검증을 우회하지 않았는지도 함께 보는 것이 좋습니다. 결과 증거와 경로 증거를 같이 봐야, 통과한 변경이 어떤 방식으로 만들어졌는지까지 판단할 수 있습니다.

사람 리뷰는 병목이 아니라 마지막 판단이어야 합니다

자동 가드레일이 깨진 변경만 사람에게 올리는 구조가 바람직합니다. 사람 리뷰는 모든 줄을 다시 읽는 과정이 아니라, 모호한 의도와 아키텍처 trade-off를 판단하는 마지막 장면이어야 합니다.

대기열이 쌓이면 기준 조정도 기록으로 남깁니다

검증 대기열이 쌓이면 새 에이전트 작업을 줄일지, 검증 도구를 늘릴지, 지금은 낮춰도 되는 기준이 있는지 결정해야 합니다. 이때 어떤 기준을 왜 조정했는지 기록으로 남겨두면, 이후 품질 저하나 병목의 원인을 되짚기 쉬워집니다.

놓치기 쉬운 세 가지

테스트 개수만 늘리고 품질이 좋아졌다고 말하기는 어렵습니다. 각 검사가 correctness, security, performance, maintainability, comprehensibility 중 어떤 신호를 맡는지 분명해야 합니다.

사람 리뷰를 완전히 없애는 것도 적절하지 않습니다. 자동 검사는 넓게 막을 수 있지만, 의도와 취향, 구조 판단은 여전히 사람의 몫으로 남습니다.

또한 CI 마지막 단계에만 의존하지 않는 것이 좋습니다. 실패가 마지막에 몰리면 재작업 비용이 커지기 때문에, 가능한 이른 단계에서 역압을 만드는 편이 효율적입니다.

이미지 차트

참고 자료

Addy Osmani 관련 원문을 바탕으로 quality gate, constraint, back-pressure, human judgment, verification capacity에 대한 핵심 내용을 정리했습니다. 함께 볼 글은 https://daker.ai/community?directory=claude-code에서 확인할 수 있습니다.

여러분은 에이전트에게 작업을 맡길 때 사람 리뷰보다 먼저 어떤 검증선을 두고 계신가요?