AI가 여러 저장소를 한꺼번에 고칠 때, 완료는 어디까지일까요?

핵심 요약 (TL;DR)

같은 라이브러리를 여러 서비스에서 쓰다 보면 작은 수정도 긴 일이 됩니다. 한곳을 고친 뒤 다른 저장소를 찾고, 서로 다른 설정에 맞춰 바꾸고, 검토를 기다려야 하기 때문입니다. Sourcegraph는 9월 14일 Agentic Batch Changes의 클라우드 정식 제공을 알렸습니다. 코드 탐색과 계획, 저장소별 수정, 병합 상태 추적을 연결하는 도구입니다. 핵심은 코드를 많이 생성하는 것이 아니라, 수정안이 실제로 반영될 때까지 흐름을 이어 간다는 데 있습니다.

단순한 일괄 치환과 무엇이 다를까요?

공식 설명에 따르면 Agentic Batch Changes는 Deep Search로 코드 맥락을 파악하고 변경 계획을 준비합니다. 규칙이 분명한 수정에는 스크립트를 만들 수 있고, 저장소마다 판단이 필요한 부분은 Claude Code나 Codex에 나눠 맡길 수 있습니다. 프로젝트별 차이를 고려하는 접근입니다.

예를 들어 오래된 함수 이름을 바꾸는 일도 호출 방식과 오류 처리 규칙이 서로 다르면 검색·치환만으로 끝나지 않습니다. 공통으로 바꿀 부분과 예외를 따로 식별해야 합니다. 이 도구는 그 과정을 조율한다고 설명하지만, 모든 변경을 정확하게 처리한다는 독립 검증은 아닙니다. 이 글 역시 공개 문서 기반 설명이며 실제 저장소에서 시험한 후기는 아닙니다.

수정안이 생겼는데 왜 아직 끝이 아닐까요?

코드 차이가 생겼다는 것은 검토할 결과가 나왔다는 뜻입니다. 테스트가 통과하고, 다른 변경과 충돌하지 않으며, 담당자가 받아들여야 실제 코드에 반영됩니다. Sourcegraph는 CI가 실패하면 로그를 가져오는 스크립트를 준비하거나 코딩 에이전트에게 수정을 맡기고, 병합 충돌에도 대응할 수 있다고 설명합니다. 사람의 판단이 필요하면 멈춰 질문하는 흐름도 포함합니다.

작은 팀에서도 이 구분은 유용합니다. AI에게 ‘모두 수정해 주세요’라고 맡기기보다 대상 목록, 저장소별 테스트, 검토 담당자, 반영 상태를 남기게 해 보세요. 실패한 항목과 아직 시작하지 않은 항목을 같은 ‘미완료’로 묶지 않으면 다음 작업이 선명해집니다.

처음부터 모든 저장소를 연결해도 될까요?

가장 작은 범위로 시작하는 편을 권합니다. 영향이 낮은 저장소 하나에서 기존 동작을 확인하고, 변경 뒤 같은 테스트를 실행하세요. 그 뒤 범위를 늘리되, 환경 변수나 배포 규칙이 다른 곳은 별도 검토 대상으로 남겨 두면 좋습니다.

완료 조건에는 수정 개수보다 사용자가 지켜야 할 동작을 적으세요. 가령 의존성을 올리는 작업이라면 설치 성공뿐 아니라 로그인과 저장 흐름이 그대로 작동하는지 확인해야 합니다. 자동화가 넓어질수록 사람이 읽는 변경 묶음은 오히려 작아야 합니다. 한꺼번에 생성할 수 있다는 능력이 한꺼번에 승인해야 한다는 의무는 아닙니다.

가격은 어떤 단위로 확인해야 할까요?

공식 변경 기록은 병합된 changeset 단위의 결과 기반 과금을 안내합니다. 최종 크레딧 요율은 Enterprise Portal에서 확인하도록 되어 있습니다. 공개 글만으로 프로젝트 총비용이나 다른 도구보다 저렴한지를 계산할 수는 없습니다. 병합 단위가 계약에서 어떻게 정의되는지 먼저 확인해야 합니다.

FAQ: 자체 호스팅 버전도 같은 날 제공됐나요?

9월 14일 발표는 클라우드 고객 대상입니다. 자체 호스팅은 Sourcegraph 8.0과 함께 9월 16일 제공 예정이라고 안내했습니다. 실제 설치 가능 여부는 해당 환경의 릴리스 상태를 확인하세요.

FAQ: AI가 알아서 병합까지 끝내 주나요?

공식 설명은 변경을 승인·병합할 준비가 될 때까지 반복하고 상태를 추적하는 흐름입니다. 사람의 검토나 저장소 보호 규칙이 사라진다고 해석하면 안 됩니다.

출처: https://sourcegraph.com/changelog/2026-09-14
공식 소개: https://sourcegraph.com/blog/introducing-agentic-batch-changes
확인: 2026-09-16 KST