[글로벌 AI·AX 핫뉴스 5/100] 앤트로픽 Scion, AI 코드가 늘어난 뒤 개발 흐름을 바꾸다

코드를 만드는 속도가 빨라지면 변경을 받아들이는 과정도 함께 움직여야 한다. 새 파일을 저장한 다음에는 기존 코드와 맞는지 살피고, 시험을 통과했는지 확인하며, 서비스에 반영할 변경을 정하는 일이 이어진다. AI가 작성한 코드가 늘어나는 개발 조직에서 이 후속 과정의 무게가 커지고 있다.

앤트로픽은 10월 13일 자체 소스 관리 체계 ‘Scion’의 내부 운영 사례를 공개했다. 회사가 밝힌 하루 평균 병합 변경은 5월 약 2500건, 9월 3만 건 이상이다. 변경 처리량을 제품 품질이나 개인의 생산성으로 읽을 수는 없다.

내부 운영 사례와 외부 제품 출시는 다른 소식이다

앤트로픽은 약 다섯 달에 걸쳐 내부 단일 저장소의 소스 관리를 Git에서 Scion으로 옮겼다고 설명했다. 필요한 파일을 서버에서 가져오고 이력과 차이 비교를 서버에서 처리하는 방식이다. 회사가 운영하는 대규모 저장소와 많은 변경 요청에 맞춘 설계라는 점이 발표의 출발점이다.

회사는 Scion을 범용 Git 대체재와 구분했다. 이번 글은 외부 API·서비스의 출시나 한국 제공 조건을 발표한 공지가 아니다. 내부 체계가 실제로 어떻게 운영되는지 설명하는 자료다.

기술 이름보다 주목할 내용은 개발의 어느 단계가 달라졌는지다. 코드를 작성하는 기능과 작성된 코드를 조직이 받아들이는 시스템은 적용 범위가 다르다. 작성 도구를 비교하는 기준만으로 승인과 시험에 필요한 기능까지 판단하기 어렵다. 사람이 읽는 계획, 파일에 기록된 구현, 실행으로 확인한 결과도 같은 기록은 아니다.

큰 저장소를 다루는 문제는 AI 이전에도 있었다

단일 저장소를 운영하는 고민은 AI 코딩 이후에 처음 생긴 일이 아니다. 구글이 2016년에 발표한 대규모 코드 저장소 연구도 하나의 중앙 저장소를 유지하는 이유와 이를 뒷받침하는 별도 관리 체계를 다뤘다. 이 연구는 오래된 기술적 맥락이다. 2026년 Scion의 성능을 독립적으로 검증한 자료로 읽을 수는 없다.

Git의 공식 문서는 하나의 저장소에 여러 작업 트리를 만들어 각 작업의 파일과 브랜치를 나눠 둘 수 있다고 설명한다. 병렬 작업이 같은 파일 상태를 건드리지 않게 하는 방법이다. 작업 공간을 나누는 기능이 있다는 사실과 여러 변경을 최종적으로 합쳐 서비스에 반영할 수 있다는 판단은 별개의 단계다.

각 작업이 자기 공간에서 실행되더라도 공통 기능과 의존 관계는 최종 코드에서 만난다. 한 작업의 시험 결과는 그 작업이 사용한 코드 상태에 대한 기록이다. 다른 변경과 합쳐진 뒤의 동작까지 자동으로 증명하지 않는다. AI가 여러 작업을 병렬로 수행하는 환경을 읽을 때도 저장소의 구조와 검증 결과의 범위를 함께 봐야 하는 이유다.

변경의 의도와 코드의 동작을 누가 확인하는가

앤트로픽은 사람의 검토가 모든 코드 줄을 읽는 방식보다 변경 요청의 의도를 살피는 방향으로 움직였다고 설명했다. 이 설명은 검토가 없어졌다는 뜻과 다르다. 어떤 조건을 지켜야 하는지 정하고, 조건을 어긴 변경을 받아들이지 않는 책임이 함께 남는다. 작성과 승인에 필요한 판단을 나눠 본 사례다.

Claude Code의 공식 작업 흐름 안내는 계획을 세우고 변경을 검토하며 시험하는 과정을 설명한다. 별도 작업 트리에서 여러 작업을 진행하는 방법도 포함한다. 이미 안내되는 이런 작업 기능과 회사 내부의 소스 관리 변경은 서로 연결될 수 있지만 같은 제품이나 새 기능으로 묶을 수는 없다.

앤트로픽은 2025년 11월 장시간 작업하는 에이전트의 실험에서도 기능을 시험하기 전에 완료로 판단하는 문제를 다뤘다. 진행 기록과 기능별 검증 상태를 다음 작업에 남기는 방법을 설명한 기존 사례다. 코드가 생성됐다는 기록과 사용자가 기능을 끝까지 이용할 수 있다는 확인이 다른 문제라는 맥락을 보여 준다. 이번 Scion 발표와는 시점과 실험 대상이 다르다.

코드 작성량을 개발 성과로 읽으려면 어떤 변경이 합쳐졌고 어떤 문제를 해결했는지가 필요하다. 수정 건수가 늘어도 되돌림과 재작업이 함께 증가했다면 서비스 운영의 부담은 다르게 나타난다. 검토가 의도 중심으로 바뀌었다면 실제 동작을 확인한 시험의 범위도 중요해진다. 코드의 양만으로 품질과 고객이 경험하는 안정성을 설명하기 어려운 지점이다.

국내 적용의 질문은 저장소 크기와 접근 범위에서 시작한다

국내 개발 조직에 이 사례가 던지는 질문도 기존 환경의 조건에 달려 있다. 저장소를 여러 개로 운영하는 회사와 큰 단일 저장소를 쓰는 회사는 파일을 가져오는 비용과 변경의 결합 방식이 다르다. 같은 AI 코딩 도구를 사용해도 코드 작성 이후에 시간이 걸리는 단계가 같다고 전제할 수는 없다.

Claude Code의 대규모 코드 안내는 작업에 필요한 디렉터리와 파일을 좁혀 읽는 방법을 설명한다. 관련 없는 파일과 지침까지 읽으면 문맥을 차지하고 비용과 수행 품질에 영향을 줄 수 있다는 취지다. 필요한 경로만 펼치는 작업 트리와 하위 디렉터리의 지침도 다룬다. 저장소 전체를 읽는 일과 맡은 작업을 이해하는 일 사이의 범위를 조정하는 기능이다.

접근 범위를 줄이는 설정을 보안 격리로 받아들여서도 안 된다. 같은 문서는 파일 읽기 제한이 모든 하위 프로세스의 파일 접근까지 통제하는 것은 아니라고 안내한다. 어떤 파일을 기본적으로 읽는지와 어떤 권한으로 실행되는지는 다르다. 국내 이용에서도 기밀 코드에 대한 접근 책임을 제품의 문맥 설정 하나로 설명할 수 없는 이유다.

공개 사례의 성과와 자기 조직의 결과 사이에 남은 거리

Scion의 수치는 앤트로픽 내부 환경에서 관찰된 결과다. 다른 조직의 비용 절감이나 한국 도입 성과를 입증하지 않는다. 각 개발 조직의 결과는 자신들의 변경과 서비스 운영 기록에서 읽어야 한다.

현재 공개된 작업 트리와 경로 제한 기능은 작업 공간과 문맥을 나누는 수단이다. 어떤 변경을 승인했고 합친 코드가 어떤 시험을 통과했는지, 실제 배포 뒤 어떤 문제가 생겼는지까지 대신 답하지 않는다. 작성 단계의 기능과 변경을 받아들이는 기록이 연결돼야 개발 과정의 어느 부분이 빨라지고 어느 부분에 부담이 남았는지 읽을 수 있다.

확인할 내용은 특정 관리 체계를 따라 만들 계획보다 실제 변경의 결과다. 의도와 구현이 맞았는지, 함께 배포된 코드의 검증 범위가 충분했는지, 문제가 생겼을 때 수정의 책임과 근거를 찾을 수 있는지가 그 내용이다. AI가 코드 작성에 들어온 뒤에도 서비스를 유지하는 조직의 판단은 이 기록에 남는다. 내부 사례의 설명만으로 이 판단이 끝났다고 볼 수는 없다.

AI 코드의 증가는 개발 과정 중 작성 단계가 달라졌다는 신호다. 그 코드가 조직의 검토와 시험을 거쳐 어떤 서비스의 변화로 이어졌는지는 다음 기록에서 확인된다. Scion 사례가 보여 준 것은 많은 코드를 받아들이는 환경의 재구성이며, 코드의 양과 서비스의 성과 사이를 읽는 책임은 여전히 남아 있다.

글로벌 AI·AX 핫뉴스 연재 모아보기 →