하루 3만 건 이상의 코드 병합, 2억 줄이 아닌 수십 GB 규모의 저장소, 그리고 수많은 AI 코딩 에이전트. AI가 코드를 작성하는 속도가 빨라지면서 소프트웨어 개발 인프라 자체가 변화하고 있다.

2026년 10월 13일, Claude 를 개발한 AI 기업 Anthropic(앤트로픽) 은 자사의 엔지니어링 블로그를 통해 기존 Git 을 대체하는 자체 버전 관리 시스템인 Scion(사이언) 을 개발하고, 내부 모노레포(Monorepo)를 완전히 이전했다고 발표했다.

Git은 2005년 리누스 토르발스(Linus Torvalds) 가 개발한 이후 전 세계 소프트웨어 개발의 사실상 표준으로 자리 잡았다. GitHub, GitLab을 비롯한 수많은 개발 플랫폼이 Git을 기반으로 작동하며, 개인 개발자부터 글로벌 기업까지 폭넓게 사용하고 있다.

그런데 Anthropic은 왜 20년 넘게 검증된 Git을 떠나 새로운 시스템을 직접 개발했을까?

이번 발표는 단순히 새로운 개발 도구의 등장을 의미하지 않는다. AI가 소프트웨어를 생산하는 속도가 인간 중심으로 설계된 개발 인프라의 처리 능력을 넘어서기 시작했다는 점에서 주목할 필요가 있다.

특히 소프트웨어 엔지니어, DevOps 전문가, 플랫폼 엔지니어, 머신러닝 엔지니어에게 이번 사례는 앞으로 개발 환경이 어떻게 변화할지 보여주는 중요한 신호다.

1. Anthropic에서는 무슨 일이 일어나고 있을까?

Anthropic 이 공개한 수치부터 살펴보자.

Anthropic 에서는 Claude 를 활용한 AI 코딩 에이전트들이 소프트웨어 개발 과정에 적극적으로 참여한다. 이들은 코드 작성뿐 아니라 기존 코드 수정, 성능 최적화, 테스트, 버그 수정 등 다양한 작업을 수행한다.

기존에는 개발자가 코드를 작성하는 속도가 전체 개발 과정의 주요 제약이었다.

하지만 AI 에이전트가 대량의 코드를 생성하면서 상황이 달라졌다.

코드 생성 속도가 빨라지자 오히려 다음과 같은 작업이 병목으로 떠오르기 시작했다.

• Source Control: 코드 변경 사항을 저장하고 관리하는 작업
• Code Review: 변경된 코드의 정확성과 안전성을 검토하는 작업
• CI/CD: 변경 사항을 빌드하고 테스트하며 배포하는 작업
• Merge: 여러 개발자와 AI 에이전트가 생성한 코드를 통합하는 작업

Anthropic 은 이러한 문제를 해결하기 위해 Scion 이라는 자체 버전 관리 시스템을 개발했고, 약 5개월 만에 내부 모노레포 이전을 완료했다.

Scion 과 함께 Antique 라는 코드 리뷰 도구, 코드 검색 시스템, 접근 권한 관리 기능 등도 구축했다.

흥미로운 점은 AI가 만들어낸 개발 병목을 해결하기 위해 AI를 활용해 새로운 개발 인프라를 구축했다는 사실이다.

2. Git 은 왜 한계에 부딪혔을까?

Git 의 핵심 설계 철학

Git은 분산 버전 관리 시스템(Distributed Version Control System, DVCS) 이다.

Git의 가장 큰 특징 중 하나는 개발자가 원격 저장소를 복제(Clone) 하면 로컬에서도 저장소의 변경 이력을 관리할 수 있다는 점이다.

일반적인 Git 작업 흐름은 다음과 같다.

이 구조는 많은 장점이 있다.

개발자는 인터넷에 연결되지 않은 상태에서도 커밋을 생성하거나 변경 이력을 확인할 수 있다. 또한 로컬에서 브랜치를 만들고, 변경 사항을 비교하고, 여러 개발자의 작업을 병합할 수 있다.

이러한 분산 구조는 Git 이 오랫동안 성공할 수 있었던 핵심적인 이유다.

그러나 Anthropic 의 개발 환경은 일반적인 소프트웨어 프로젝트와 상당히 다르다.

거대한 Monorepo와 수천만 번의 Checkout

Monorepo 는 여러 프로젝트나 서비스를 하나의 거대한 저장소에서 관리하는 방식이다.

Anthropic이 공개한 내부 저장소 규모는 다음과 같다.

Anthropic은 이미 Git의 Shallow Clone, Sparse Checkout, 내부 Git Mirror 등 다양한 최적화 기법을 사용하고 있었다.

한때 수백 대의 내부 Git Mirror 를 운영하기도 했다.

그럼에도 코드 병합 속도가 증가하면서 저장소 복제, 변경 이력 조회, 캐시 관리 등에 필요한 비용과 복잡성이 커졌다.

결국 Anthropic 은 근본적인 질문을 던졌다.

AI 에이전트와 CI 작업이 대부분 온라인 상태에서 실행된다면, 모든 클라이언트가 독립적인 Git 저장소를 유지할 필요가 있을까?

이 질문이 Scion 설계의 출발점이었다.

3. Scion 의 핵심 아키텍처: Git과 무엇이 다른가?

Scion의 가장 중요한 설계 변화는 분산형 Git 모델에서 서버 중심의 버전 관리 모델로 이동했다는 것이다.

Git과 Scion 의 아키텍처 비교

3.1 서버에서 커밋과 병합을 처리한다

Git 에서는 개발자가 로컬에서 커밋을 생성한 뒤 원격 저장소로 Push 한다.

반면 Scion 에서는 커밋 생성, Merge, Rebase 등 주요 작업을 서버가 처리한다.

이 구조에서는 각 AI 에이전트가 저장소의 모든 변경 이력을 가지고 있을 필요가 없다.

서버에 필요한 작업을 요청하고 결과를 전달받으면 된다.

특히 수많은 에이전트가 짧은 시간에 작업을 수행하는 환경에서는 로컬 저장소 관리 부담을 줄일 수 있다.

3.2 Changeset 과 Content-Addressed Storage

Scion은 Git의 커밋과 유사한 개념으로 Changeset 을 사용한다.

하지만 내부 데이터 구조에는 차이가 있다.

Git 의 커밋은 특정 시점의 파일 트리(Tree)를 가리킨다. 반면 Scion 의 Changeset 은 첫 번째 부모 Changeset 을 기준으로 변경된 파일 목록과 해당 파일 콘텐츠를 참조하는 정보를 저장한다.

파일 콘텐츠는 Content-Addressed Storage 방식으로 관리된다.

이는 데이터의 저장 위치를 임의의 파일 이름이 아니라 콘텐츠를 기반으로 생성한 식별자로 참조하는 방식이다.

Scion 은 Changeset 을 Write-Ahead Log 에 기록하며, 변경 이력 조회와 같은 작업에 필요한 추가 인덱스를 별도로 계산한다.

예를 들어 다음과 같은 정보다.

• 특정 파일을 마지막으로 수정한 커밋
• 특정 코드 라인을 변경한 개발자 또는 작업
• 두 Changeset의 공통 조상
• 특정 파일 경로의 변경 이력

이러한 데이터를 Anthropic은 Derived Data 라고 부른다.

Derived Data 는 필요에 따라 미리 계산하거나 요청 시점에 계산할 수 있다.

이를 통해 저장소 전체를 매번 분석하지 않고도 필요한 정보를 효율적으로 제공할 수 있다.

3.3 수평 확장과 계층형 캐싱

Scion 은 서버와 캐시를 여러 계층으로 분리한다.

각 계층은 필요한 데이터를 캐시하고, 데이터가 없을 때 상위 계층에 요청한다.

Scion 은 변경되지 않는 콘텐츠 기반 객체를 활용하기 때문에 캐시 서버 간 복잡한 동기화 없이도 데이터를 재사용하기 쉽다.

Anthropic 에 따르면 각 캐시 계층의 적중률은 99%를 넘는다.

그 결과 기존 Git Mirror 인프라와 비교해 CPU 및 메모리 사용 규모를 약 200분의 1 수준으로 줄였다.

CI 와 연구 작업의 코드 Checkout 시간도 수분에서 수초 수준으로 단축됐으며, CI 에서는 약 25%의 CPU 용량 절감 효과를 얻었다.

이러한 수치는 Scion 이 단순히 Git 을 다른 도구로 대체한 것이 아니라, Anthropic 의 특수한 워크로드에 맞춰 개발 인프라를 재설계했다는 사실을 보여준다.

4. 머신러닝 엔지니어에게도 중요한 이유

Scion 은 소프트웨어 개발자를 위한 도구지만, 이번 변화는 머신러닝과 AI 인프라를 다루는 엔지니어에게도 중요한 의미가 있다.

특히 AI 모델을 개발하는 환경과 AI 에이전트를 활용해 소프트웨어를 개발하는 환경이 점점 더 밀접하게 연결되고 있기 때문이다.

4.1 AI 연구와 실험의 자동화

전통적인 머신러닝 개발에서는 연구자가 직접 모델을 수정하고, 실험을 실행하고, 결과를 비교하는 작업이 일반적이었다.

예를 들어 다음과 같은 과정을 생각해 볼 수 있다.

하지만 AI 에이전트가 이 과정에 참여하면 상황이 달라진다.

에이전트가 코드 수정, 실험 실행, 성능 분석, 다음 실험 설계의 일부를 자동화할 수 있다.

이렇게 되면 한 명의 연구자가 여러 실험을 병렬로 실행할 수 있다.

문제는 실험이 늘어날수록 코드 변경, 실행 환경, 모델 버전, 결과를 관리하는 부담도 함께 증가한다는 점이다.

Scion 이 직접 모델 가중치나 학습 데이터의 버전 관리를 해결하는 시스템은 아니다. 그러나 대규모 AI 연구에서 코드와 실험 인프라의 처리량이 얼마나 중요한지 보여주는 사례라고 할 수 있다.

4.2 Reproducibility와 Experiment Tracking

머신러닝에서는 실험 결과를 재현할 수 있는 능력(Reproducibility) 이 중요하다.

일반적으로 실험을 재현하려면 다음 정보가 필요하다.

• Source Code Version
• Dataset Version
• Model Configuration
• Hyperparameters
• Dependencies 및 실행 환경
• Random Seed
• Evaluation Metrics

MLflow, Weights & Biases, DVC 등의 도구는 이러한 실험 및 아티팩트 관리에 활용된다.

AI 에이전트가 수많은 실험을 자동으로 생성한다면, 개별 실험을 추적하는 것뿐 아니라 실험 간 관계를 파악하는 일도 중요해진다.

예를 들어 특정 모델의 성능이 개선되었을 때, 어떤 코드 변경과 설정 변경이 영향을 미쳤는지 빠르게 확인할 수 있어야 한다.

Scion 의 서버 기반 변경 이력 조회와 API 중심 설계는 이런 환경에서 참고할 만한 접근법이다.

다만 Scion 자체가 MLflow 나 DVC 를 대체하는 것은 아니다. 코드 버전 관리와 머신러닝 실험 관리는 서로 연결되지만 별개의 문제이기 때문이다.

4.3 AI Agent 를 위한 개발 인프라

기존 CI/CD 파이프라인은 주로 사람이 생성한 코드 변경을 처리하도록 설계되어 있다.

일반적으로 개발자는 Pull Request 를 생성하고, 자동화된 테스트를 실행한 뒤, 코드 리뷰를 거쳐 변경 사항을 병합한다.

하지만 수백 개의 AI 에이전트가 동시에 코드를 수정한다면 어떻게 될까?

예를 들어 다음과 같은 문제가 발생할 수 있다.

첫째, 테스트 결과가 오래된 코드 상태를 기준으로 생성될 수 있다.

AI 에이전트가 코드를 수정하는 동안 다른 에이전트가 새로운 변경 사항을 병합할 수 있다. 테스트를 시작했을 때와 실제 배포 시점의 코드 상태가 달라지는 것이다.

둘째, Merge Queue 가 병목이 될 수 있다.

변경 사항을 순차적으로 병합하는 방식은 코드 변경량이 적을 때 효과적이다. 그러나 수천 개의 변경 사항이 동시에 대기한다면 병합 대기 시간이 전체 개발 속도를 제한할 수 있다.

셋째, 코드 리뷰의 방식이 달라져야 한다.

AI 가 생성한 모든 코드를 사람이 한 줄씩 검토하는 방식은 변경량이 급격히 증가할수록 유지하기 어려워진다. Anthropic 역시 이러한 문제를 경험했고, Scion 과 함께 개발 워크플로 자체를 재검토하고 있다.

특히 기존의 전역 잠금(Global Lock) 에 의존하는 Merge Queue 대신, 병합 이후와 배포 이전에 수행하는 자동화 테스트를 강화하고 있다고 설명했다.

이러한 방식에는 동시 변경으로 인한 충돌이나 통합 오류의 위험이 존재한다. 따라서 빠른 병합 뿐 아니라 자동 복구, 테스트 격리, 배포 차단 장치가 함께 중요해진다. 

5. Claude 는 Scion 개발에 얼마나 기여했을까?

이번 발표에서 특히 흥미로운 부분은 Scion의 개발 과정이다.

Anthropic 에 따르면 7명의 엔지니어가 약 5개월 동안 Scion, 코드 리뷰 도구 Antique, 그리고 여러 관련 시스템을 개발하고 이전 작업까지 완료했다.

Claude 는 이 과정에서 상당한 역할을 수행했다.

대표적인 사례가 Git 에서 Scion으로 데이터를 이전하기 위한 Ingestion Pipeline 이다.

초기 버전은 엔지니어들이 직접 작성했지만, 이후 Claude 의 초기 내부 모델을 활용해 다시 구현했다.

Anthropic 이 공개한 결과에 따르면 개선된 버전은 다음과 같은 성능을 보였다.

이 수치는 해당 파이프라인의 개선 결과이며, Claude가 모든 종류의 코드를 같은 수준으로 최적화한다는 의미는 아니다.

그럼에도 AI 가 단순한 코드 자동 완성을 넘어 시스템 최적화와 인프라 개발에 실질적으로 참여할 수 있다는 점을 보여준다.

Anthropic 은 Claude 를 활용해 다양한 테스트 시뮬레이션과 Fuzz Testing 도 구축했다고 밝혔다.

Fuzz Testing 은 프로그램에 예측하기 어려운 다양한 입력을 제공해 오류나 취약점을 찾는 테스트 기법이다.

대규모 분산 시스템에서는 정상적인 요청 뿐 아니라 네트워크 장애, 데이터 불일치, 동시성 문제, 부분적인 시스템 실패까지 고려해야 한다.

AI 가 이러한 테스트를 대량으로 작성할 수 있다는 것은 개발 생산성 뿐 아니라 소프트웨어 품질 관리에도 영향을 줄 수 있다.

그렇다면 인간 엔지니어의 역할은 무엇일까?

Anthropic 은 AI가 코드 작성에서 매우 높은 능력을 보였지만, 엔지니어의 역할이 사라진 것은 아니라고 강조했다.

오히려 엔지니어들은 다음과 같은 문제에 집중했다.

• 시스템 전체 아키텍처 설계
• 성능과 복잡성 사이의 Trade-off 판단
• 분산 시스템의 일관성과 안정성 검증
• 보안 및 접근 제어 정책 설계
• AI가 제안한 불필요하거나 위험한 구현 방지

특히 AI 에이전트가 특정 문제를 해결하는 과정에서 시스템 전체의 설계 원칙을 위반하거나 불필요하게 복잡한 코드를 생성하는 사례도 있었다.

이러한 상황에서는 엔지니어가 AI의 제안을 거절하거나 설계 방향을 수정해야 했다.

Anthropic의 경험은 앞으로 소프트웨어 엔지니어의 역할이 코드 작성 자체에서 설계, 검증, 의사결정, 시스템 운영으로 더욱 확장될 가능성을 보여준다.

6. 전 GitHub CEO 도 새로운 개발 플랫폼을 만들고 있다

Anthropic 만 기존 개발 환경의 변화를 고민하는 것은 아니다.

2026년 2월, 전 GitHub CEO인 Thomas Dohmke 는 AI 시대를 위한 새로운 개발 플랫폼 기업 Entire 를 설립했다고 발표했다.

Entire 는 설립 당시 약 6,000만 달러의 시드 투자를 유치했으며, 기업 가치는 약 3억 달러로 평가됐다.

Entire 가 주목하는 문제는 Scion 과 다소 다르다.

Scion 이 대규모 코드 변경과 저장소 운영의 효율성에 집중한다면, Entire 는 AI 에이전트가 코드를 생성하는 과정에서 발생하는 맥락(Context)과 의사결정 이력을 관리하는 데 초점을 맞추고 있다.

예를 들어 개발자가 AI 에이전트에 다음과 같이 요청했다고 가정해 보자.

기존 인증 시스템을 JWT 기반으로 변경하고, 만료된 토큰에 대한 예외 처리를 추가해 줘.

AI는 관련 코드를 분석하고 여러 파일을 수정한 뒤 테스트를 실행할 수 있다.

그런데 나중에 다른 개발자가 해당 코드를 검토한다면 다음과 같은 질문이 생길 수 있다.

왜 이 구조를 선택했을까? 어떤 대안을 검토했을까? AI 에게 어떤 요구사항이 전달됐을까?

기존 Git 은 최종적으로 변경된 코드와 커밋 이력을 저장하지만, AI 와 개발자가 주고받은 작업 맥락까지 자동으로 기록하지는 않는다.

Entire 는 이러한 문제를 해결하기 위해 AI 에이전트의 작업 맥락을 Git 커밋과 연결하는 Checkpoints 라는 오픈소스 도구를 공개했다.

여기에는 프롬프트, 작업 과정, 의사결정에 관한 정보 등이 포함될 수 있다.

Entire 가 구상하는 장기적인 플랫폼 역시 Git 과의 호환성을 유지하면서 AI 에이전트와 인간 개발자가 협업할 수 있는 환경을 구축하는 데 초점을 맞추고 있다.

즉, 두 기업은 서로 다른 접근법을 취하고 있다.

Anthropic Scion: AI 에이전트가 생성하는 방대한 코드 변경을 어떻게 효율적으로 처리할 것인가?

Entire: AI 에이전트가 생성한 코드의 의도와 작업 맥락을 어떻게 기록하고 이해할 것인가?

두 접근법 모두 기존 개발 인프라가 AI 시대에 맞춰 변화해야 한다는 공통된 문제의식에서 출발한다.

7. Git 은 이제 사라지는 것일까?

Scion 의 등장만으로 Git 의 시대가 끝났다고 판단하기는 어렵다.

Anthropic 역시 Scion이 일반적인 개발 환경에서 Git 을 대체하기에 적합한 시스템은 아니라고 설명했다.

대부분의 개발 조직은 하루 수만 건의 코드 병합이나 수천만 번의 Checkout 을 처리하지 않는다.

또한 Git에는 오랜 기간 축적된 생태계가 있다.

GitHub, GitLab, IDE, CI/CD 플랫폼, 보안 도구, 오픈소스 프로젝트 등이 Git을 중심으로 연결되어 있다.

Scion 과 같은 새로운 시스템으로 이전하려면 버전 관리 도구뿐 아니라 코드 리뷰, 코드 검색, CI/CD 등 개발 과정의 상당 부분을 함께 변경해야 한다.

따라서 일반적인 기업이나 개발자가 Scion 과 같은 자체 시스템을 개발할 필요는 없다.

오히려 이번 사례에서 주목할 부분은 Git 을 대체해야 한다는 결론이 아니라, Git 을 사용하는 방식과 주변 인프라가 변화할 가능성이다.

Anthropic 도 GitHub, GitLab 및 오픈소스 커뮤니티와 협력해 기존 Git 생태계의 확장성을 개선할 수 있기를 기대한다고 밝혔다.

서버 측 API 강화, 효율적인 데이터 전송 프로토콜, Sparse Checkout 개선 등은 Git 기반 환경에서도 적용할 수 있는 아이디어다.

8. 개발자와 IT 직장인들은 무엇을 준비해야 할까?

이번 사례가 모든 개발자에게 새로운 버전 관리 시스템을 공부해야 한다는 메시지를 전달하는 것은 아니다.

오히려 더 중요한 변화는 소프트웨어 개발 과정에서 인간과 AI 가 담당하는 역할이 재편되고 있다는 점이다.

첫째, 시스템 설계와 아키텍처 이해가 더욱 중요해질 수 있다

AI 가 코드를 빠르게 생성하더라도 그 코드가 전체 시스템에 어떤 영향을 미치는지 판단하는 것은 별개의 문제다.

분산 시스템, 데이터 일관성, 네트워크, 데이터베이스, 캐싱, 장애 복구 등 기본적인 컴퓨터공학 지식은 여전히 중요하다.

특히 시스템이 커질수록 단순한 코드 작성 능력보다 적절한 아키텍처를 선택하고 기술적 Trade-off 를 판단하는 능력이 필요하다.

둘째, AI 를 활용하는 능력과 AI 를 검증하는 능력을 함께 갖춰야 한다

AI 코딩 도구를 활용하면 반복적인 개발 작업을 줄일 수 있다.

그러나 AI 가 생성한 코드가 항상 정확하거나 효율적인 것은 아니다.

코드 리뷰, 테스트 자동화, 성능 분석, 보안 검증을 수행할 수 있는 역량이 중요하다.

앞으로는 AI 가 작성한 코드의 양보다 실제로 검증되고 안정적으로 운영되는 소프트웨어의 품질이 더욱 중요한 평가 기준이 될 수 있다.

셋째, DevOps와 Platform Engineering 의 역할을 다시 생각해야 한다

AI 가 코드 생성 속도를 높이면 빌드, 테스트, 배포 과정에 더 많은 부하가 발생할 수 있다.

이는 개발 인프라의 확장성과 자동화 수준을 높여야 한다는 의미다.

예를 들어 다음과 같은 분야의 중요성이 커질 수 있다.

• 분산 빌드 및 테스트 시스템
• 효율적인 CI/CD 파이프라인
• 자동화된 코드 검증 및 보안 검사
• AI 에이전트 실행 환경의 격리
• Observability와 자동 장애 대응
• 대규모 개발 환경의 비용 최적화

특히 Platform Engineering 과 MLOps 는 AI 기반 개발 워크플로를 안정적으로 운영하기 위한 핵심 분야가 될 가능성이 있다.

9. 결론: AI 는 코딩 도구뿐 아니라 개발 방식 자체를 바꾸고 있다

Anthropic 의 Scion 은 단순히 Git 보다 빠른 새로운 버전 관리 시스템을 개발했다는 이야기가 아니다.

더 중요한 것은 AI가 소프트웨어를 생산하는 속도가 빨라지면서 기존 개발 인프라의 설계 가정이 달라지고 있다는 사실이다.

과거에는 사람이 코드를 작성하고 도구가 이를 관리했다.

하지만 AI 에이전트가 코드 작성, 수정, 테스트, 최적화에 참여하면서 개발 과정에서 발생하는 작업량과 복잡성이 빠르게 증가하고 있다.

Anthropic 은 이러한 변화에 대응하기 위해 버전 관리 시스템을 재설계했다. Entire 는 AI 가 생성한 코드의 작업 맥락을 관리하는 새로운 개발 플랫폼을 구축하고 있다.

두 사례는 서로 다른 문제를 해결하고 있지만, 공통적으로 하나의 방향을 가리킨다.

앞으로의 개발 플랫폼은 인간 개발자만이 아니라 AI 에이전트와 인간이 함께 일하는 환경을 고려해야 한다는 것이다.

물론 모든 기업이 Anthropic 과 같은 규모의 문제를 경험하는 것은 아니다. Git 역시 당분간 소프트웨어 개발의 핵심 인프라로 남을 가능성이 높다.

그러나 AI 활용이 확대될수록 코드 생성 이후의 검증, 통합, 배포, 운영을 어떻게 효율적으로 처리할 것인지는 더욱 중요한 과제가 될 것이다.

그리고 이러한 변화 속에서 개발자에게 요구되는 역량 역시 달라질 수 있다.

단순히 코드를 빠르게 작성하는 능력을 넘어, 복잡한 시스템을 이해하고 올바른 기술적 결정을 내리며 AI가 생성한 결과물을 검증할 수 있는 역량이 중요해지고 있다.

Anthropic 의 Scion 은 이러한 변화가 이미 실제 엔지니어링 현장에서 시작되었다는 것을 보여주는 사례다.

여러분은 어떻게 생각하시나요?

AI 코딩 에이전트가 발전하면서 Git, GitHub, CI/CD와 같은 기존 개발 도구들도 근본적으로 변화해야 할까요?

또한 AI가 코드 작성의 상당 부분을 담당하게 된다면, 앞으로 소프트웨어 엔지니어에게 가장 중요한 역량은 무엇이 될까요?

KAITA 커뮤니티에서도 개발자, DevOps 엔지니어, 머신러닝 엔지니어 등 다양한 분야에서 일하는 분들의 의견을 나누어 보면 좋겠습니다.

참고 자료

1. Anthropic Engineering (2026.10.13, 10.15 업데이트) — Redesigning source control at Anthropic
2. Entire (2026.02.10) — Former GitHub CEO Thomas Dohmke launches Entire

본 글은 Anthropic의 공식 엔지니어링 발표와 Entire의 공식 자료를 바탕으로 작성했으며, 기술적 해설과 향후 산업 변화에 대한 전망을 포함하고 있습니다.