- Imprint는 PR 증가로 리뷰 시간이 길어지자, 제한된 조건을 충족하는 변경을
small-change
로 분류해 빠르게 승인하는 방식을 도입함
- 자격은 사람이 바꿀 수 없는
CI/CD 검사로 판정하며, 코드 규모, 자동 리뷰 결과, 작성자의 해당 서비스 경험, 변경 범위와 민감 경로를 함께 확인함
review-small-change
스킬은 조건을 만족하는 PR을 승인하거나 무시할 뿐 댓글을 달지 않아, AI가 만든 리뷰 댓글을 사람이 중계하는 병목을 피함
- 개별 PR의 지식 공유는
PR 묶음 리뷰로 옮기고, small-change
에서 발생한 오류는 개인이 아닌 자동 리뷰, 검증, CI/CD, 하네스의 개선으로 해결하도록 함
- 초기에는 변경의
약 10% 가 대상이며, 유의미한 성과를 판단하기에는 아직 이름. 적용 비율 확대의 성패는 검증 체계를 얼마나 포괄적으로 강화할 수 있는지에 달려 있음
PR 처리량 증가와 리뷰 병목
-
Imprint의 엔지니어 1인당 평균 PR 병합 수는
2년 전의 4배로 늘어남
-
두 팀은 같은 기간 PR 병합 수가 10배로 늘어남
-
한 엔지니어의 주간 병합 수는 2년 전 평균 엔지니어의 25배이며, 여러 엔지니어가 그 수준에 접근하고 있음
-
현재 추세라면 1년 뒤 평균은 현재 p50보다 p90에 훨씬 가까워질 것으로 예상함
-
처리량 증가와 함께
품질도 개선됨
-
직전 반기 대비 장애는 42%, 심각한 장애는 78% 감소함
-
이 경험에서는 품질과 속도를 상충 관계로 보는 틀이 유용하지 않음
-
PR 리뷰 완료 시간의
중앙값은 33분에서 77분으로 늘어났으며, 증가 추세는 PR 병합 수와 밀접하게 연관됨
-
Anthropic의 코드 리뷰 사례처럼 PR 리뷰가 병목이 됨
small-change
는 이를 완전히 해결한 방식이 아니라, 좁고 통제된 범위에서 새 관행을 검증하는 시도임
PR 리뷰의 네 가지 목적과 대안
지식 공유: 소프트웨어 엔지니어링은 대체로 도제식으로 학습하며, 리뷰는 숙련된 엔지니어가 좋은 소프트웨어를 가르치는 주요 수단임
- 현재 PR 규모에서는 개별 PR보다
PR 묶음을 대상으로 지식을 공유하는 방식으로 이동해야 한다고 봄
오류 예방: 리뷰는 원래도 오류를 잡는 데 비용이 많이 드는 단계임
- 효과적인 CI/CD와 poteto의 pstack 같은
하네스 검증 기법이 리뷰보다 효과적인 오류 예방 수단이라고 판단함
악의적 행동 방지: 경험상 신중한 코드 리뷰도 능숙하게 숨긴 악의적 행동은 대체로 놓치지만, 다행히 실제 악의적 행동 대부분은 능숙하지 않음
- 특정 객체, 클래스, 파일 변경 시 리뷰를 요구하는 고정 규칙, LLM 기반 회원 지원에서 발전시킨 악용 방지 수단, 감사와 감사 로그 검사를 조합하는 편이 낫다고 봄
문서화된 통제의 준법 의무: 현재 일부 저장소는 변경 작성자와 독립된 사람의 리뷰를 요구함
- 통제는 변경할 수 있고 각 목적에 더 나은 대안이 있다고 보지만, 전환은 매우 신중하게 진행하려 함
small-change 자격 판정
-
PR이 준비 상태가 되면
CI/CD가 자격을 판정하고 통과한 GitHub 검사로 표시함
-
가시성을 위한 라벨도 있지만, 실제 자격은 빌드가 관리하며 사람이 수정할 수 없는 검사 결과로 결정함
-
라벨로 먼저 필터링하더라도 검사 결과는 별도로 검증함
-
자격을 얻으려면 다음
조건을 모두 충족해야 함
-
코드가
1,000줄 미만이어야 함
-
자동 리뷰 봇
ai-code-review
에서 p1 또는 p2 지적이 없어야 함
- 작성자는 해당 서비스나 애플리케이션 디렉터리에
이전에 병합된 PR이 10개 이상이어야 하며, 여러 서비스에 걸친 변경이면 모든 대상에서 이 경험을 갖춰야 함
- 영향을 받는 서로 다른 서비스나 애플리케이션 수가
N
미만이어야 함. N
은 프런트엔드 모노레포에서 1, 백엔드 모노레포에서 3임
- 공유 라이브러리와 유틸리티 파일은 대상에서 제외함
- 저장소별
.small_change
파일로 경로별 동작을 조정하며, 자금 이동을 처리하는 서비스 등을 제외할 수 있음
- 백엔드에서는 일반적인 변경이 gRPC 서비스와 공통 HTTP 게이트웨이를 함께 수정함
- 기존
Slack 자동화는 PR을 참조할 때 테스트 실패, 승인 후 테스트 진행 중, 병합 준비 완료 등의 상태를 이모지 반응으로 표시함
- 여기에
small-change
자격 충족 여부를 알리는 반응을 추가함
승인 스킬과 시스템 차원의 책임
- 내부 스킬 저장소에 두 스킬을 만들고 여러
하네스에 배포함
review-small-change
는 저장소 목록을 받아 열려 있는 비초안 small-change
PR을 검토함
small-change
를 포함한 모든 검사가 통과하고 결제나 보안 같은 민감한 주제를 건드리지 않으면 승인할 수 있음
- 선택지는 승인 또는 무시뿐이며, PR에 댓글을 남기지 않음
review-pr-cluster
는 PR 묶음을 검토해 공통 주제를 찾고, 논의하거나 검증을 추가할 기회를 제안함
small-change
로 인한 오류는 시스템의 실패로 간주함
ai-code-review
, 검증 수단, CI/CD, 하네스 등을 개선해 시스템 수준에서 해결해야 함
- 구현과 배포는 간헐적으로 작업하며
약 이틀이 걸렸지만, 세부 조정은 오랫동안, 어쩌면 계속 필요할 것으로 예상함
AI 리뷰를 사람이 중계하는 병목
meat proxy 리뷰 는 처음에는 해결책처럼 보이지만 오히려 리뷰 부담을 키움
-
리뷰에 압도된 팀이 로컬 하네스로 PR을 검토하기 시작함
-
타당한 것과 타당하지 않은 것이 섞인 댓글이 대량으로 생기며, 검토 전에는 둘을 구별하기 어려움
-
어떤 댓글이 실제 리뷰어의 판단인지도 불명확해, 리뷰어조차 동의하지 않을 수 있는 댓글을 반박하는 데 상당한 노력이 듦
-
이후 하네스가 만든 댓글에 하네스로 응답하면, 학습에 도움이 되지 않고 다른 팀원의 참여 없이도 가능한 형식적 절차가 됨
-
이런 방식 대신
중앙화된 리뷰 체계와 그 피드백을 처리하는 하네스 반복 루프에 투자하고, 리뷰어는 승인만 하는 편이 더 나은 결과를 낸다고 봄
fleet을 통한 별도의 리뷰 부담 축소
fleet
은 클라우드에서 고도로 통제된 환경으로 소프트웨어를 구현하고 검증하는 중앙 조율형 하네스임
독립 평가 수단으로 각 변경에 필요한 독립 리뷰어 수를 결정함
이 코드를 작성하고 사람 한 명이 리뷰하는 식으로, 리뷰어 수를 한 명까지 줄일 수 있음
초기 결과와 확대 조건
- 초기에는 변경의
**약 10%가 **small-change
에 해당하며, 유의미한 결과를 내놓기에는 아직 이름
-
대상 변경은 매우 빠른 승인을 받을 수 있고, 보통 실제로 그렇게 처리됨
-
다만 보안이나 자금 관련 주제를 건드려 경고에 걸리면 예외가 됨
-
앞으로 몇 달간
검증 범위를 확대하면서 대상 비율을 높이는 능력이 성패를 좌우함
-
규모 복잡성은 낮고 도메인 복잡성은 높은 소프트웨어에서는 검증 개선에 더 어려운 기법이 필요함
-
규모 복잡성은 높고 도메인 복잡성은 낮은 제품에서는 점진적 출시 같은 기법이 매우 효과적임
-
사용자마다 설정과 행동이 다른 경우에도 점진적 출시는 유효하지만, 검증 범위는 더 제한적임
-
구성원 모두가 이 변화에 열광하는 것은 아니며,
좋은 엔지니어가 되는 법으로 배워 온 관행을 크게 바꾸는 일이기도 함
-
오래 유지한 모범 사례가 단지 교조적 관행이 되었는지 재평가하는 일은 불편함
-
익숙한 관행을 매주 다시 검토할 수 있다는 점은 활력을 주지만, 재평가를 멈추면 뒤처질 가능성이 있다는 점은 부담임
댓글과 토론