같은 주간, 정반대의 사례가 동시에 터졌다
한쪽에서는 AI 에이전트가 새벽에 혼자 보안 리뷰를 돌리고, 아침 출근 전에 SSRF와 네트워크 설정 취약점을 담은 'Security Review Digest'를 개발자 받은편지함에 떨어뜨렸다. 다른 한쪽에서는 수십 년간 신뢰받던 rsync에 AI 보조 코드가 유입된 뒤, 백업이 멈추고 CPU가 100%로 치솟는 회귀 버그가 보고되면서 GitHub 이슈 트래커가 전쟁터가 됐다.
dev.to의 Antigravity Agent 사례와 GeekNews를 통해 퍼진 rsync 진영의 충돌—두 사건을 나란히 놓으면, AI 코드 리뷰 자동화가 팀에 줄 수 있는 실익과 리스크가 동시에 선명해진다.
Antigravity Agent: AI가 잠든 사이 보안 리뷰를 끝낸다
Antigravity Agent의 scheduled tasks 기능은 사용 패턴 자체를 바꾼다. 개발자가 자리를 비운 5시간 동안 에이전트가 리포지토리 전체를 훑고, 아키텍처·데이터 처리·사용자 인터랙션 흐름을 검토한다. GitHub에서 유사 코드를 찾아 CVE·CWE와 교차 검증하고, 발견된 취약점에 대해 Threat Severity Matrix까지 자동 생성한다. 더 나아가 수정 코드를 직접 작성해두기도 한다.
이게 왜 의미 있냐면, 보안 리뷰는 원래 '생각하는 비용'이 높은 작업이기 때문이다. 집중 개발 중에 보안 체크리스트를 들이밀면 컨텍스트 스위칭 비용이 크다. 하지만 밤사이 에이전트가 요약본을 만들어놓으면, 개발자는 아침에 우선순위 판단만 하면 된다. 인지 부하를 시간축으로 분산하는 설계다.
ROI 측면에서도 꽤 현실적이다. 5시간 사용 제한 창이 자신이 자는 동안 돌아가도록 스케줄링하면, 유료 플랜의 사용 효율이 올라간다. FinOps 관점에서 AI 도구 비용을 최적화하는 방식으로도 참고할 만하다.
rsync 사태: AI 보조 코드가 신뢰 인프라에 들어갔을 때
rsync는 '그냥 동작하는 도구'의 대명사였다. 백업, DFIR, 시스템 동기화—수십 년간 핵심 인프라 역할을 해왔다. 그런데 Claude Code가 포함된 커밋(30656c5e)이 병합된 이후, Linux Mint Timeshift 사용자들 사이에서 회귀 버그가 보고되기 시작했다. 일일 백업 중 CPU 사용률이 비정상적으로 치솟는 문제였다.
논쟁은 빠르게 'AI 보조 개발의 신뢰성' 전반으로 번졌다. DFIR 업무에 rsync를 쓰는 사용자는 "AI 도구가 관여했다는 사실만으로 조직 내 추가 보안 검토 절차가 생겼다"고 밝혔다. 다운스트림 패키지 매니저들은 버전 피닝과 포크를 논의하기 시작했다.
사태를 복잡하게 만든 건 단순히 버그가 생겼다는 게 아니다. 이미 신뢰를 쌓은 인프라 도구에서 AI 보조 코드가 어떻게 감사되고 검증됐는지가 불투명했기 때문이다. 유지보수자는 보안 CVE 수정 과정에서 LLM을 활용했고, 코드 한 줄씩 검토했다고 밝혔다. 하지만 회귀 테스트가 엣지 케이스를 놓쳤고, 그 결과는 사용자 시스템에서 드러났다.
두 사례가 공통으로 가리키는 것
두 사례를 이분법으로 읽으면 놓치는 게 있다. 'AI 코드 리뷰는 좋다', 'AI 코딩은 위험하다'가 아니다. 핵심은 AI가 어느 레이어에서, 어떤 검증 구조 위에서 작동하느냐다.
Antigravity Agent 사례는 AI가 리뷰어 역할에 머문다. 코드를 직접 프로덕션에 밀어 넣지 않고, 요약과 우선순위 판단을 인간에게 돌려준다. 에이전트가 수정 코드를 제안해도, 개발자가 아침에 검토하고 적용 여부를 결정한다. 인간이 최종 게이트를 쥔 구조다.
rsync 사태는 AI가 생성한 코드가 충분한 회귀 테스트 없이 안정 릴리스 브랜치에 병합됐다는 게 문제의 본질이다. 유지보수자가 줄 단위로 검토했다 해도, 장기 안정 소프트웨어에서 엣지 케이스를 커버하는 회귀 테스트 없이 변경을 반영하면 리스크는 누적된다. AI를 쓰든 안 쓰든 이 원칙은 동일하지만, AI 보조 코드는 '그럴듯하게 보이는 코드'를 빠르게 생성하기 때문에 검토자가 놓치기 쉽다.
팀 단위 AI 코드 리뷰 도입 전 따져야 할 세 가지
첫째, AI를 어느 레이어에 놓을지 먼저 결정하라. 코드 생성과 코드 리뷰는 다른 역할이다. AI를 리뷰어·감사자 역할로 제한하면 품질 리스크가 낮아진다. AI가 생성한 코드를 AI가 리뷰하는 루프는 편향이 증폭될 수 있다.
둘째, 안정성 요구사항이 높은 코드베이스일수록 회귀 테스트 커버리지가 먼저다. rsync 사태에서 한 기여자가 짚었듯, 30656c5e 직전 커밋에 회귀 테스트를 더 넣고 앞으로 리베이스하는 게 정석이다. AI가 코드를 수정할수록, 그 코드를 잡아줄 테스트 망이 촘촘해야 한다.
셋째, AI 보조 개발 사실을 커밋 메시지와 PR 설명에 명시하라. rsync 논쟁에서 불필요하게 갈등이 커진 이유 중 하나는 투명성 부재였다. 다운스트림 사용자와 감사자가 어떤 변경이 AI 보조로 이뤄졌는지 추적할 수 있어야, 이슈가 생겼을 때 원인 분석이 빨라진다. DFIR 사용자가 '조직 정책상 AI 도구로 재분류해야 했다'고 말한 건 과민반응이 아니라 현실적인 거버넌스 요구다.
전망: AI 코드 리뷰의 진짜 가치는 속도가 아니다
Antigravity Agent 방식은 앞으로 더 확산될 것이다. 스케줄링된 보안 리뷰, PR 병합 전 자동 취약점 스캔, Threat Severity Matrix 자동 생성—이 파이프라인을 팀 단위로 설계하면 시니어 개발자의 보안 리뷰 부담을 실질적으로 줄일 수 있다.
하지만 rsync 사태는 AI 코딩 도입의 속도가 거버넌스 설계 속도를 앞서면 어떤 일이 벌어지는지를 공개적으로 보여줬다. 핵심 인프라 도구의 신뢰가 한 번 흔들리면, 다운스트림 전체가 버전 피닝과 포크 논의에 들어가고, 오픈소스 커뮤니티의 에너지가 기여가 아닌 방어로 소진된다.
AI 코드 리뷰 자동화를 팀에 도입하려는 테크 리드라면, 지금 던져야 할 질문은 '어떤 AI 도구를 쓸까'가 아니다. 'AI가 어느 단계에서 인간의 판단을 보조하고, 어느 단계에서 인간이 최종 게이트를 쥘 것인가'—이 설계가 먼저다. 속도는 그다음이다.