Anthropic의 Scion 기사 분석을 통한 개인 개발 AI PR 운영 시 사람 리뷰 최소화 방안

검증 환경:

• 개인 개발용 다수 리포지토리 (GitHub Free)
• Cursor의 cloud agent가 PR 생성
• AI 리뷰: Amazon Q Developer for GitHub (시험 사용 중) 등
• 원문 기사: Anthropic "Redesigning source control at Anthropic" (2026-10-13 공개)

배경:

Anthropic의 병합(merge) 건수는 2026년 5월 1일 약 2,500건에서 9월에는 하루 30,000건 이상으로 증가했다. 코드 작성 부분은 더 이상 병목 지점이 아니며, 막히는 곳은 소스 컨트롤(source control), 빌드, CI와 같은 '인간 규모를 위한 인프라'라는 것이다. 이에 사내 VCS로 Scion과 리뷰 기반 시스템 Antique를 구축하고 5개월 만에 git에서 전환했다.

이것은 개인 개발 영역이라 규모는 비교할 수 없을 정도로 작다. 하지만 cloud agent가 PR을 대량 생산하게 되면서, 병목 지점이 작성하는 것에서 '보는 것'으로 옮겨갔다는 체감은 동일하다.

결론:

개인 규모에서 모방할 수 있는 것은 VCS 자체를 재설계하는 것이 아니라, 리뷰에 대한 사고방식이다.

여정:

Scion의 핵심 요점

• 클라이언트(에이전트나 작업)는 항상 온라인이라는 전제하에 설계했다.
• 이력, blame, 병합(merge), 리베이스(rebase)는 서버 측에서 처리하고 API로 제공한다. 워킹 카피가 필수적이지 않으며, sparse checkout을 기본으로 한다.
• CI의 체크아웃 시간이 분 단위에서 초 단위로 줄었고, 인프라는 git 미러 시대보다 CPU 및 메모리 사용량이 200분의 1로 축소되었다.

이 부분은 초대형 monorepo에 관한 이야기라 개인에게 직접적인 관련은 없다. Anthropic 자체도 "git의 범용적인 대체재는 아니다"라고 언급하고 있다.

light와 fatal을 구분하기

light한 PR은 CI pass로 커버할 수 있다고 생각했다. 따라서 CI가 통과하면 자동으로 병합한다.

fatal한 PR은 사람이 승인해야 한다. fatal이란 비밀 정보(secret)·인증, 리포지토리 설정, CI 워크플로우, 릴리스, 파괴적인 변경, private한 정보가 외부에 노출될 위험이 있거나 되돌릴 수 없는 작업을 의미한다. 망설여진다면 fatal로 취급한다.

Anthropic의 Antique도 같은 생각을 하고 있다. 댓글만 추가된 변경과 로직 변경을 구분하여 사람의 리뷰를 영향력이 큰 변경에 집중시키고 있다.

사람은 의도만 본다

Anthropic에서는 여전히 Scion의 변경 요청은 모든 팀 멤버가 리뷰하고 있다. 다만 전체 라인을 읽는 것이 아니라, 변경의 '의도'를 보고 있다.

나 역시 마찬가지로, 의도만 보고 개발 속도를 높이고 문제가 있으면 되돌리는 방식으로 운영하고 있다. 이것이 현재 나의 개발 방식에 적합했다.

Dependabot의 major 업데이트 건은 AI와 사람의 두 단계로 검토한다 (지난 글).

AI 리뷰는 과잉 방어적이 되기 쉽다

원문 기사에는 adversarial review가 유효하지만 근시안적(myopic)이 되기 쉬우며, 가정한 우려에 반응하여 과도한 검증이나 복잡성을 추가해 버리므로, 그렇게 되지 않도록 사람이 제지할 필요가 있다고 한다.

나의 경우에도 비슷한 일이 발생했다. Zenn 기사의 PR에서 Amazon Q가 아직 공개되지 않은 날짜나 새로운 버전 번호를 Critical로 지적했다. 이는 학습 데이터상의 '최신'과 비교하여 오탐지한 것이었다. 대책으로 .amazonq/rules/에 규칙을 설정했다. 오늘 날짜는 언제인지, 버전은 리포지토리의 기술을 진실로 간주하고, 학습 데이터에서 '존재하지 않는다'고 판단하지 않는다는 내용이다.

리뷰 컨텍스트

• 현재 날짜는 2026년 10월 이후입니다. 2026년의 날짜를 미래 또는 유효하지 않은 것으로 표시하지 마십시오.
• 이 저장소에 있는 버전 및 날짜(package.json, workflows, 기사에 명시된 환경)를 진실의 원천으로 간주하십시오. 학습 데이터에 근거하여 버전을 존재하지 않는다고 호출하지 마십시오.
  ...

AI 리뷰가 병합(merge)의 조건은 아니다. 읽고 필요한 것만 고치고 있다.

따라 하지 말아야 할 것 / 따라 하고 싶은 것

• 따라 하지 말아야 할 것: merge queue 폐지. 개인적으로는 PR이 충돌할 정도로 병렬로 실행되지 않는다.
• 따라 하고 싶은 것: '슈퍼팬(superfan)'. Slack 채널에서 하나의 컴포넌트의 건전성만을 감시하게 하는 Claude를 말한다. 릴리스나 CI의 감시 역할을 한다면, 개인용 봇에도 배치할 수 있을 것 같다.

비고

• Anthropic은 사내에서 사용할 토큰량이 다른 회사와는 비교가 안 될 정도로 많다고 스스로 적었다. 그대로 따라 할 만한 것은 아니다.

.amazonq/rules

이것이 오탐지(誤検知)를 줄일 수 있을지는 아직 검증되지 않았다.

참고

토론 (Discussion)