10월 14일 수요일

AI가 만든 변경을 더 많이 통과시키면서도 품질·보안·운영 위험을 키우지 않으려면 검증 책임을 어디에 어떻게 배치해야 하는가?

AI가 PR의 수와 크기를 함께 늘리면 생산성의 병목은 코드 작성에서 중앙 검증으로 이동한다. 모든 변경을 사람이 촘촘히 읽으면 배포가 느려지고, 검토를 고무도장처럼 처리하면 장애 위험이 커진다. 해법은 리뷰 모델 하나를 추가하는 것이 아니라 변경의 전 생명주기를 제어면으로 묶는 것이다. 독립 worktree에서 작업을 격리하고, 코드·실행 영상·전후 화면·성능 수치·테스트를 증거로 남기며, CI 실패의 원인을 분류하고 수정·재검증을 반복한다. 이 흐름 위에 결과물이 실제로 존재하는지, 수치와 주장이 원문과 맞는지, 맞는 사실에서 잘못된 결론을 냈는지를 서로 다른 검토자로 확인해야 한다. 조직 맥락도 같은 원칙을 따른다. 현재 코드가 동작의 기준을 제공하고 과거 문서는 결정 이유를 제공하지만, 충돌하는 자료의 권위는 사람이 표시해야 한다. 검증 자동화는 사람을 제거하는 장치가 아니라 사람이 승인해야 할 위험과 읽어야 할 증거를 더 선명하게 만드는 장치다.

1. 01

   병목을 생성량이 아니라 검토 용량으로 본다

   PR 생성 속도가 빨라져도 CI와 리뷰의 처리량이 그대로면 실패는 수 시간에서 수일의 외부 루프로 돌아온다. Atlassian의 AutoDev가 팀원당 주 3~5개 PR 같은 진행량 제한을 예로 들고, 모호한 작업은 사람에게 되묻는 이유도 여기에 있다. 자동화 용량은 모델의 토큰 예산이 아니라 팀이 증거를 읽고 병합 여부를 판단할 수 있는 용량을 넘지 않아야 한다. 작은 변경을 순차적으로 내보내고 작업별·주간 비용 상한을 두는 것이 검증 가능한 흐름의 첫 번째 제약이다.

2. 02

   완료 주장을 세 종류의 증거로 분해한다

   첫 단계는 파일 위치·지문·검사 명령으로 수행 사실을 확인하고, 작업을 보낸 쪽이 검사를 다시 실행하는 것이다. 두 번째는 같은 지시를 받은 독립 결과들을 통제 합계와 원문에 한 줄씩 대조하는 것이다. 세 번째는 주장마다 측정·출처 대조·추론·가정을 표시하고, 원래 결론을 모르는 역할 기반 검토자가 반례를 찾게 하는 것이다. 이 층들은 대체 관계가 아니다. 위험이 커질수록 결과물 검증 위에 사실 대조와 적대적 추론 검토를 누적해야 한다.

3. 03

   확률적 판단과 결정적 검사를 겹친다

   에이전트 리뷰는 의도와 수정 방법을 폭넓게 읽지만, 경고를 많이 만드는 것만으로 신뢰할 수 없다. 실제로 중요한 문제를 골라야 하며, 자연어 표준만으로는 반복 가능한 이진 게이트를 보장하지 못한다. 따라서 taint·control flow·data flow·software composition analysis 같은 프로그램 분석, 인수 조건 체크리스트, 재현 가능한 실행 결과를 에이전트 판단과 겹쳐야 한다. 한쪽은 맥락과 조치안을, 다른 쪽은 일관된 구조 검사를 제공한다. 서로 다른 실패 모드를 가진 검사들을 합치는 것이 단일 리뷰어의 자신감보다 강한 근거다.

4. 04

   자율성은 관찰에서 병합까지 단계적으로 올린다

   도입 순서는 리뷰 결과 관찰, 문제 있는 PR의 차단, 자동 수정과 재검증, 조건부 승인·병합으로 올라간다. 각 단계에서 실행 영상·스크린샷·측정값·테스트와 미해결 리뷰를 남기고 사람이 실제 제품을 사용해 최종 판단한다. 과거 결정과 현재 코드를 연결하는 맥락 계층은 계획과 리뷰를 돕지만, 오래된 문서나 모호한 티켓을 자동으로 권위 있는 사실로 만들면 안 된다. 검토자가 이해할 수 있는 작은 변경, 명시된 인수 조건, 되돌릴 수 있는 자동화부터 신뢰를 쌓아야 한다.

검증형 SDLC의 성공 지표는 에이전트가 만든 코드량이 아니라 어떤 변경이 어떤 근거로 통과했고, 실패가 어디에서 차단됐으며, 사람이 어느 위험에 승인권을 행사했는지 재현할 수 있는가다. 세션 약 10건 중 4건에서 중요한 오류를 관찰했다는 수치나 AI 리뷰 댓글 해결률 약 40% 같은 값은 각각 한 사용자의 분석과 회사 발표 맥락에 묶여 있으므로 보편적 오류율로 일반화하면 안 된다. 팀은 자체 저장소에서 오탐·미탐, 재현 성공률, 수정 후 회귀, 검토 대기시간, 변경당 비용을 측정해야 한다. 그 데이터가 쌓일 때만 차단·자동 수정·병합 권한을 한 단계씩 넓힐 수 있다.