오스마니 기술 — AI 코드 품질, 리뷰 전에 막아야 할 것 | DAKER 커뮤니티
무엇 : diff 대기열이 리뷰 속도보다 빨리 쌓이는 순간, 품질은 사람 눈 하나에만 기대기 어렵다. Addy Osmani가 오늘 붙잡은 핵심은 에이전트 코드 품질이 하네스와 환경 안의 제약, 즉 quality gate에서 먼저 걸러져야 한다는 점이다. 사람은 사라지는 것이 아니라, 자동 가드레일이 깨지는 지점과 의도·아키텍처 판단이 필요한 순간으로 이동한다.
언제 쓰나 : Claude Code나 Codex에 리팩터링, 테스트 보강, 대량 이슈 처리, 마이그레이션을 맡길 때 쓴다. 에이전트가 코드를 제안하는 화면에서 바로 병합 버튼을 보지 말고, 그 제안이 통과해야 할 검증선을 먼저 세운다. 특히 사람이 모든 줄을 읽기 어려운 속도로 변경이 생길 때, 검증 capacity와 에이전트 change rate를 함께 조절해야 한다.
핵심 원리
- 제약은 에이전트가 무엇을 해도 되는지 정하는 실행 장치다. 단위 테스트, 속성 테스트, 인수 테스트, 타입 검사, 보안 스캔, 성능 기준, 복잡도 기준처럼 서로 다른 신호가 각자 맡은 문을 지킨다.
- 역압은 불량 변경을 다음 단계로 보내지 않는 힘이다. 컴파일러가 거절하고, 테스트가 실패하고, 보안 정책이 막고, CI가 배포를 멈추면 사람은 더 주관적인 의도와 구조 판단에 집중할 수 있다.
- 검증 루프가 밀리면 선택지가 생긴다. 검증 용량을 늘리거나, 에이전트가 새 변경을 만드는 속도를 줄이거나, 품질 기준을 낮추는 결정을 명시적으로 내려야 한다.
짧게 비유하면, 에이전트 코딩의 품질 관리는 마지막 계산대가 아니라 공장 중간중간의 안전문에 가깝다. 문이 자주 막히면 문을 없앨지, 생산 속도를 줄일지, 문을 더 만들지 결정해야 한다.
적용 방법
- 오늘 맡길 에이전트 작업을 위험도별로 나눈다. 문서 수정, 테스트 추가, UI 문구 변경처럼 낮은 위험과 인증, 결제, 마이그레이션처럼 높은 위험을 같은 줄에 두지 않는다.
- 낮은 위험 작업에는 자동 quality gate를 먼저 둔다. lint, typecheck, unit test, 접근성 검사, 보안 규칙, 변경 파일 제한처럼 실패하면 즉시 멈출 신호를 정한다.
- 에이전트 출력에는 결과 증거와 경로 증거를 함께 요구한다. 무엇이 통과했는지뿐 아니라 어떤 파일을 건드렸고 어떤 검증을 우회하지 않았는지 본다.
- 자동 가드레일이 깨진 변경만 사람에게 올린다. 사람 리뷰는 모든 줄을 다시 읽는 병목이 아니라, 모호한 의도와 아키텍처 trade-off를 판단하는 마지막 장면이어야 한다.
- 검증 대기열이 쌓이면 기준을 조정한다. 새 에이전트 작업을 줄일지, 검증 도구를 늘릴지, 지금은 낮춰도 되는 기준이 있는지 기록으로 남긴다.
실수 방지 체크는 다음 세 가지다.
- 테스트 개수만 늘리고 품질이 좋아졌다고 말하지 않는다. 각 검사는 correctness, security, performance, maintainability, comprehensibility 중 어떤 신호를 맡는지 분명해야 한다.
- 사람 리뷰를 완전히 없애지 않는다. 자동 검사는 넓게 막고, 사람은 intent, taste, architecture처럼 자동화하기 어려운 판단에 남긴다.
- CI 마지막 단계에만 의존하지 않는다. 실패가 마지막에 몰리면 재작업 비용이 커지므로 가능한 이른 단계에서 역압을 만든다.
이미지 차트
공식 검증 : Addy Osmani 공식 사이트에서 게시일, quality gate, constraint, back-pressure, human judgment, verification capacity 관련 핵심 항목 8개를 확인했다. 원문 링크는 공개 본문에 싣지 않았고, 검증 메모는 비공개 노트에만 남겼다. DAKER 안에서 이어 볼 글은 클로드 코드 디렉터리에서 확인할 수 있다.
오늘 에이전트에게 새 작업을 맡긴다면, 프롬프트 첫 줄보다 먼저 검증선을 한 줄 적어 보자. “이 문을 통과하지 못하면 사람에게 올리지 않는다.” 그 한 줄이 리뷰 대기열의 표정을 바꾼다.