AI 코딩 에이전트가 대규모 코드베이스를 망가뜨리는 이유

URL: https://www.youtube.com/watch?v=Bdrs3uAX0_M 날짜: 2026-10-05 채널: t3dotgg

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 코딩 에이전트가 작은 문제를 빠르게 해결하는 능력만큼, 대규모 코드베이스 전체를 보고 이해하며 일관되게 변화시키는 인프라를 갖추지 못하면 코드 생산성의 폭증이 오히려 소프트웨어를 망가뜨린다.==

• 500명 이상 기업에 소프트웨어 업계 종사자의 72%가 몰려 있고, 이들은 수천 개의 저장소와 수십 년치 코드 역사를 관리한다.
• 수백만 줄의 코드와 수만 개의 저장소는 하나의 컨텍스트 윈도우에 들어오지 않으며, 서로 다른 에이전트가 서로 다른 표준과 중복 구현을 만들어 코드베이스를 서서히 부식시킨다.
• Sourcegraph는 코드 검색과 컴파일러 수준의 정확한 분석을 결합한 code graph를 기반으로, 수백~수천 개 저장소에 한 번의 프롬프트로 변경을 적용하는 Agentic Batch Changes를 베타로 공개했다.

대규모 코드베이스의 소유자는 새 기능을 만드는 속도뿐 아니라 어떤 코드가 어디에 존재하고, 무엇이 운영 환경에 배포되어 있으며, 하나의 수정이 모든 복사본·포크·서비스에 적용됐는지를 확인할 수 있어야 한다. 에이전트 시대의 핵심 병목은 코드 작성 능력이 아니라 코드베이스 전체를 볼 수 있는 가시성(visibility)과 변경을 끝까지 추적하는 인프라다.

1. 세계를 움직이는 소프트웨어와 코드의 물결

대규모 레거시 코드베이스는 화려하지 않지만 금융·보험·물류·교통·항공·급여·사무실 설비를 실제로 작동시키는 하중 지지 구조다.

1.1. 대부분의 엔지니어가 살아가는 현실

1. 소프트웨어 산업의 중심은 대기업이다

   1. 고용 분포: 소프트웨어 업계 종사자의 72%가 500명보다 많은 기업에 근무한다. 소셜 미디어에서 자주 보이는 핫한 스타트업이나 엑스-솔로프러너(ex-solopreneur)는 소수이며, 대부분의 엔지니어는 오래 지속된 대규모 코드베이스에서 일한다.
   2. 코드의 시간 깊이: 대기업은 수천 개의 저장소와 수십 년 동안 축적된 코드 역사를 관리한다. 수천 명의 엔지니어가 여러 해에 걸쳐 만든 복잡한 시스템이 오늘의 업무 기반이다.

2. 코드베이스가 일상 인프라를 떠받친다

   1. 금융과 보험: 은행 계좌가 한도에 도달한 거래를 실시간으로 거절하고, 보험사가 이중 보장(dual coverage)을 가진 가입자의 보상률을 계산하는 일이 대규모 코드베이스에 달려 있다.
   2. 물류와 이동: 칩과 창고 스캐너가 연동되어 아마존이 양말의 도착 시점을 알려 주고, 우버가 도착 예정 시간을 계산하며, 항공기가 레이더 정보로 비행 궤적을 조정한다.
   3. 생활과 업무: 급여가 발행되고 사무실 에어컨이 계속 작동하는 것까지 수십 년 된 코드가 담당한다. 세계는 이런 코드에 완전히, 절대적으로 의존한다.

1.2. AI가 만든 코드의 급류

1. 생산량과 속도의 급증

   1. 전례 없는 코드 생산: 코딩 에이전트는 과거 어느 때보다 더 많은 코드를 더 빠르게 작성한다. 거대한 코드의 물결(tidal wave of code)이 각 팀의 코드베이스와 엔지니어를 향해 밀려온다.
   2. 검토 부담: AI가 생성한 코드가 건강한지 검토해야 하는 양이 폭증했다. 모든 사람이 이 홍수를 체감하고 있으며, 검토자들은 지쳐 있다.

2. 국소적인 모래주머니의 한계

   1. 보조 도구의 확산: 코드 리뷰 에이전트와 코드베이스 건강도 측정 도구가 등장했고, 주요 코딩 에이전트가 장차 이런 기능을 흡수하며 모델도 계속 좋아질 것이다.
   2. 문제의 지연: 팀은 홍수를 막기 위해 모래주머니를 계속 쌓고 각자의 국소 최적점(local maxima)을 찾지만, 그동안 세계를 움직이는 대규모 코드베이스는 서서히 부식되고 있다.

2. 에이전트가 대규모 코드베이스를 부식시키는 방식

새 기능과 패치를 빠르게 배포하는 속도 자체가 코드의 양을 통제할 수 없는 수준으로 키우고, 에이전트가 전체 맥락을 보지 못한 채 변경을 누적하면서 유지보수 문제가 구조화된다.

2.1. 규모가 만드는 컨텍스트 문제

1. 전체 저장소를 한 번에 볼 수 없다

   1. 물리적 규모: 수백만 줄의 코드와 수만 개의 저장소는 하나의 컨텍스트 윈도우에 들어가지 않는다.
   2. 실시간 복제의 불가능성: 그 모든 저장소를 실시간으로 clone하고 분석하는 일도 불가능하다. 코드베이스의 일부만 본 에이전트는 전체 구조와 운영 상태를 모른 채 변경한다.

2. 변경 속도가 이해 속도를 앞선다

   1. 기능과 패치의 기록적 속도: 에이전트가 새 기능과 패치를 전례 없는 속도로 출하하지만, 전체 시스템에서 변경의 의미를 확인하는 속도는 그만큼 빨라지지 않는다.
   2. 유지보수 소유권의 악화: 대규모 코드베이스를 소유하고 건강하게 유지하는 일은 오늘날 그 어느 때보다 어려워졌다. 누구도 생각하거나 처리하고 싶어 하지 않는 레거시 영역까지 지속적인 감독과 관리가 필요하다.

2.2. 일관성·중복·의존성의 붕괴

1. 서로 다른 표준이 공존한다

   1. 에이전트별 편차: 같은 코드베이스의 서로 다른 장소에서 서로 다른 에이전트가 서로 다른 코딩 표준을 적용한다.
   2. 작은 차이의 누적: 표준에서 조금씩 벗어난 구현이 겉으로는 작아 보여도 코드베이스 전체에 더 교묘하고 숨겨진 문제를 만든다.

2. 이미 있는 것을 다시 만든다

   1. 중복 코드의 증식: 코드베이스에 이미 같은 기능을 하는 라이브러리가 있어도 에이전트가 그것을 알지 못해 새 코드를 작성한다.
   2. 장기 비용: 중복 구현은 수정 지점을 늘리고 표준을 분산시켜 이후의 변경과 검토를 더 어렵게 한다.

3. 서비스 사이의 연결이 취약해진다

   1. 교차 서비스 의존성: 여러 저장소와 서비스에 걸친 cross-service dependency가 점점 더 brittle해진다.
   2. 부분 맥락의 위험: 한 저장소 안에서는 맞는 수정도 다른 서비스의 호출 방식·계약·배포 상태를 고려하지 않으면 전체 시스템에서 오류를 일으킬 수 있다.

2.3. 보안 위험의 양면성

1. 에이전트는 취약점을 더 빨리 드러낸다

   1. 발견 속도의 상승: 에이전트가 매일 새로운 취약점을 찾아내고 있다. 이는 보안 문제를 찾는 능력이 좋아진 것이지만 동시에 해결해야 할 범위가 급격히 커졌다는 뜻이다.
   2. 생성자이자 탐지자: 같은 도구가 취약한 코드를 새로 만들 수도 있고 기존 취약점을 발견할 수도 있다. 코드 생성량이 늘수록 검토와 일관된 패치의 필요성도 커진다.

2. 문제의 근원은 집 안에 있다

   1. ‘call is coming from inside the house’ 비유: 모두를 빠르게 만들고 더 많은 코드를 쓰게 한 도구 자체가 세계를 움직이는 대규모 코드베이스를 실패하게 만들 조건을 만든다.
   2. 단순한 리뷰 자동화로 부족하다: 개별 PR의 품질만 확인하는 방어선은 전체 저장소·포크·복사본·운영 환경을 함께 보는 능력을 제공하지 못한다.

3. 대기업 리더가 마주한 공포와 도구 시장의 공백

기술 리더는 개발자에게 최고의 도구를 주고 싶어 하지만, 대규모 시스템의 실제 책임을 지는 순간 에이전트가 만든 코드의 출처와 의미를 모른다는 고백은 치명적인 신호가 된다.

3.1. 자율주행 코드에서 드러난 불안

1. 톱10 자동차 제조사의 사례

   1. 현장에서 들은 말: 한 톱10 자동차 제조사의 기술 리더는 개발자가 “이 코드가 무슨 일을 하는지 모르겠다. AI가 나 대신 써 줬다”고 말하는 것을 들었다고 전했다.
   2. 위험의 크기: 수천 명의 엔지니어를 이끌며 차량 오토파일럿 코드를 작성하는 조직에서 이런 무지는 단순한 생산성 문제가 아니라 안전과 책임의 문제다.

2. 코드 소유자의 요구

   1. 생산성 이상의 기준: 코드베이스 소유자는 빠른 코드 작성만이 아니라 전체 시스템을 파악하고, 변경의 범위를 확인하고, 이후에도 건강하게 진화시킬 수 있는 도구를 받아야 한다.
   2. 놓치고 있는 사람들: 작은 문제를 훌륭하게 해결하는 에이전트의 수요가 빠르게 증가하는 동안 대규모 코드베이스가 무너지는 더 큰 문제는 주목받지 못하고 있다.

3.2. 에이전트 빌더가 아직 제공하지 못한 인프라

1. 대규모 이해 계층의 부재

   1. 시장에 없는 것: OpenAI, Anthropic, Cursor를 비롯한 에이전트 도구 회사들이 50,000개 저장소 규모의 코드베이스를 보고 이해할 인프라를 아직 만들거나 판매하지 않는다.
   2. 문제의 독자성: 이 문제는 단순히 모델을 더 똑똑하게 만드는 문제가 아니라 수십 년의 코드, 저장소 간 의존성, 현재 배포 상태를 연결해 보여 주는 별도의 인프라 문제다.

2. 인프라 제작자에 대한 요청

   1. 호출 대상: 개발 도구 회사, agent harness를 만드는 팀, 에이전트용 인프라를 만드는 사람들은 대규모 저장소를 보고 이해하는 능력을 구축해야 한다.
   2. 책임의 확장: 에이전트가 잘 작동하는 작은 단위의 개발 경험을 넘어, 실제 코드베이스 소유자가 책임지는 전체 규모까지 도구의 시야를 확장해야 한다.

4. 90,000개 저장소와 ‘검색하는 신입사원’ 문제

대규모 변경의 난점은 한 번의 코드 수정 자체가 아니라, 수정해야 할 모든 장소를 찾고 그 장소들이 실제 제품·서비스와 어떻게 연결되는지 파악하는 데 있다.

4.1. 은행의 공급망 취약점 사례

1. 한 기술 리더의 현실적인 질문

   1. 배경: 수조 달러 규모의 자산을 보관·관리하는 미국 톱10 은행의 기술 리더는 특정 npm 공급망 취약점과 관련해 다음과 같이 말했다.
   2. 직접 인용: “물론 Claude Code는 이 변경을 할 수 있다. 하지만 나는 이 변경을 해야 할 저장소가 90,000개 있다.”

2. 단일 에이전트 호출로 해결할 수 없는 이유

   1. 범위의 문제: 은행이 에이전트가 새 취약점을 전례 없는 속도로 발견·생성하는 상황에서 단순히 Claude Code를 사용하라는 조언을 받는다면, 90,000개 저장소에 같은 수정을 적용하는 순간 막힌다.
   2. 구조 파악의 문제: 저장소들이 서로 어떻게 연결되는지, 실제로 어떤 코드가 회사 전체 제품과 운영 환경에 배포되어 있는지, 모든 곳에 패치를 적용했는지를 먼저 매핑해야 한다.

4.2. LLM의 본능은 검색이다

1. 새로 온 사람과 같은 학습 방식

   1. 검색 중심의 세계 모델: LLM은 검색을 좋아한다. 에이전트는 저장소를 검색하며 세계와 코드베이스의 모델을 만든다.
   2. 검색이 곧 컨텍스트: 새로 입사한 엔지니어가 코드베이스를 파악하려고 파일과 참조를 검색하는 것처럼, 에이전트도 검색 결과를 바탕으로 구조와 수정 지점을 추론한다.

2. AGENTS.md만으로는 충분하지 않다

   1. 제한된 효과: 저장소 아키텍처를 에이전트의 AGENTS.md 파일에 적어 넣는 것만으로는 문제를 거의 해결하지 못한다.
   2. 보이지 않는 것은 검색할 수 없다: 에이전트는 결국 코드베이스를 grep하며 이해하려고 한다. 애초에 보이지 않는 코드는 grep할 수 없으므로, 문서보다 앞서 필요한 것은 전체 코드를 노출하는 도구와 인프라다.

4.3. 규모가 커질수록 달라지는 문제

1. 검색 가능한 범위의 확장

   1. 다단계 규모: 500개 저장소, 5,000개 저장소, 50,000개 저장소, 나아가 500,000개 저장소의 코드베이스는 각각 다른 수준의 인덱싱·분석·추적을 필요로 한다.
   2. 단순 clone의 한계: 저장소를 모두 복제해 에이전트의 컨텍스트에 넣는 방식으로는 이런 규모를 다룰 수 없다. 구조화된 전역 가시성이 필요하다.

2. 현재 상태에 대한 질문

   1. 운영 코드: 어떤 코드가 지금 실제로 배포되어 있는지 알아야 한다.
   2. 확장된 복사본: 포크, 저장소 복사본, 개발자가 회사로 가져와 라이브러리나 API로 연결한 코드까지 파악해야 한다. 이런 코드가 운영 중인데 소유자가 모를 수 있다.

5. Sourcegraph의 코드 그래프와 가시성 인프라

대규모 코드베이스는 사라지지 않고 앞으로 더 많은 코드를 품게 되므로, 에이전트에게 검색 결과 이상의 구조적 이해를 제공하는 code graph가 핵심 기반이 된다.

5.1. 더 많은 코드가 오는 미래

1. 레거시는 없어지지 않는다

   1. 지속되는 대규모 시스템: 세계를 움직이는 거대한 코드베이스는 사라지지 않는다. 기존 시스템 위에 새 기능과 새 서비스가 계속 쌓인다.
   2. 총량의 증가: 미래에는 코드가 줄어드는 것이 아니라 훨씬, 훨씬, 훨씬 더 많아진다. 에이전트가 생산량을 높일수록 전체 코드의 규모와 관리 부담이 함께 커진다.

2. 에이전트의 미래 조건

   1. 가시성과 이해: 에이전트가 대규모 코드베이스를 실제로 보고 이해하며 진화시킬 수 있게 하는 도구가 필수다.
   2. 변경의 효과성: 어떤 수정이 어떤 서비스·복사본·배포 대상에 영향을 주는지 알아야 에이전트가 효과적으로 변경할 수 있다.

5.2. code graph의 구성

1. 코드베이스의 기반 그래프

   1. 관계의 표현: code graph는 코드베이스를 구성하는 저장소, 파일, 참조, 의존성의 관계를 하나의 구조로 나타내어 에이전트가 전체 지형을 볼 수 있게 한다.
   2. 검색의 결합: 그래프는 코드 검색과 결합된다. 에이전트는 필요한 구현을 찾는 동시에 그 구현이 전체 시스템의 어느 위치에 놓이는지 파악할 수 있다.

2. 컴파일러 수준의 정확성

   1. 정확한 분석: 단순한 텍스트 검색을 넘어 실제 컴파일러에 준하는 정확한 출력(compiler-accurate output)이 필요하다.
   2. 안전한 변경: 정확한 분석은 호출 관계와 변경 영향 범위를 판단하게 하며, 에이전트가 보이는 일부 파일만 보고 잘못된 패치를 적용할 가능성을 줄인다.

3. 가시성은 인프라다

   1. 기본 전제: 에이전트의 코드 생성 능력보다 먼저 “무엇이 어디에 있는가”를 볼 수 있어야 한다. visibility 자체가 인프라다.
   2. 소유자의 통제: 가시성이 있으면 코드베이스 소유자가 현재 배포 상태, 수정 누락, 복사본의 분기, 서비스 간 영향을 확인하고 책임질 수 있다.

6. Agentic Batch Changes: 대규모 변경을 끝까지 책임지는 에이전트

Sourcegraph는 code graph와 변경 관리 기반 위에, 한 번의 프롬프트로 수백~수천 개 저장소를 단계적으로 수정하는 Agentic Batch Changes를 베타로 공개했다.

6.1. 단일 프롬프트에서 전체 코드베이스로

1. 제품의 목표

   1. 대규모 패치 실행: 거대한 코드베이스의 소유자가 한 번의 프롬프트로 수백 또는 수천 개 저장소에 코드 변경을 실행한다.
   2. 반복적 적용: 한 번에 모든 것을 맹목적으로 바꾸는 것이 아니라 코드베이스 전체를 순차적으로 살피며 변경을 반복 적용한다.

2. 프론티어 에이전트의 역할

   1. 판단과 실행: 필요한 곳에서는 코딩 에이전트를 사용해 판단이 필요한 수정을 수행하고, 같은 형태의 반복 작업에는 결정론적 스크립트를 사용한다.
   2. 규모에 맞는 자동화: 작은 저장소용 에이전트 경험을 수천 개 저장소의 일괄 작업으로 확장하되, 각 저장소의 상태와 결과를 추적한다.

6.2. 실패를 고치고 변경을 검증하는 루프

1. 스스로 회복한다

   1. Self-heal: 변경 과정에서 오류가 발생하면 에이전트가 스스로 수정하며 다음 저장소로 진행한다.
   2. CI와 PR 피드백: CI 상태와 PR 댓글에 응답해 테스트 실패나 리뷰 피드백을 반영한다. 변경은 생성 시점에 끝나지 않고 검증 루프를 거친다.

2. 판단과 결정론을 분리한다

   1. 코딩 에이전트가 필요한 곳: 맥락을 읽고 판단해야 하는 비정형 변경에는 코딩 에이전트를 투입한다.
   2. 결정론적 스크립트가 필요한 곳: 동일한 설정 변경처럼 규칙이 명확한 작업에는 결정론적 스크립트를 사용해 수백 개 장소에 일관되게 적용한다.

3. 추적성과 감사 가능성을 제공한다

   1. 커버리지 확인: 패치가 필요한 장소를 100% 덮었는지 추적한다. 일부 저장소에만 성공한 상태를 전체 성공으로 착각하지 않게 한다.
   2. 감사(auditability): 어디에 어떤 변경이 적용됐고, 어느 곳이 실패했으며, 무엇이 아직 남았는지 확인할 수 있어야 한다. 대규모 변경에서 신뢰는 결과뿐 아니라 완전한 경로에서 나온다.

6.3. 인프라 문제로서의 코드 건강

1. 출하 이후까지 책임진다

   1. 건강한 코드베이스: 세상에 코드를 내보낼 때는 단지 현재 빌드가 통과하는 것이 아니라 코드베이스가 계속 건강하게 유지되어야 한다.
   2. 붕괴에 적응하기: 코드베이스가 무너지기 시작하는 지점을 감지하고, 해당 영역에 맞춰 변화·패치를 적용할 수 있어야 한다.

2. 신뢰의 기준을 높인다

   1. 전역 적용: 변경이 필요한 100%의 위치를 찾고 일관되게 처리해야 한다.
   2. 재현 가능한 결과: 사람이 저장소마다 반복 작업하는 방식이 아니라 결정론적 방법과 기록을 사용해 같은 조건에서 같은 수정이 적용되도록 해야 한다.

7. Mercari의 환경 변수 취약점 사례

일본의 글로벌 쇼핑 서비스 Mercari는 수백 개의 독립 마이크로서비스를 운영하며, Agentic Batch Changes로 이미 알려진 문제를 넘어 코드베이스 전역의 추가 취약점을 찾고 한 번에 패치했다.

7.1. 알려진 두 저장소에서 전체 탐색으로

1. 취약점의 형태

   1. GitHub 코드 인젝션 문제: 환경 변수를 올바르게 설정하지 않을 때 발생하는 GitHub code injection 이슈가 대상이었다.
   2. 설정 파일의 일관성: 문제는 여러 저장소의 설정 파일에 반복될 수 있었고, 저장소별로 사람이 찾아 고치면 누락과 편차가 생길 수 있었다.

2. 탐색 방식

   1. 출발점: Mercari 사용자는 문제가 존재한다고 알고 있던 두 저장소에 먼저 에이전트를 실행했다.
   2. 범위 확장: 이어서 코드베이스의 나머지 부분도 탐색하라고 지시했고, 에이전트가 알려지지 않았던 추가 사례를 찾도록 했다.

7.2. 80개의 추가 잠재 취약점과 결정론적 패치

1. 발견 결과

   1. 추가 80건: 에이전트는 다른 위치에서 잠재적 취약점 80개를 더 찾았다.
   2. 대규모 마이크로서비스의 현실: 수백 개의 독립 서비스가 운영되는 환경에서는 처음 알고 있던 두 곳만 수정하는 것으로는 충분하지 않으며, 전역 탐색이 실제 위험 범위를 드러낸다.

2. 수정 결과

   1. 한 번의 일관된 처리: 설정 파일을 결정론적 스크립트로 스캔하고 패치해 위험이 존재하는 곳에 같은 변경을 적용했다.
   2. 에이전트 시대의 신뢰: 80개의 잠재 취약점을 추가로 찾아내고 모든 위치에 일관되게 수정했다는 확신이 대규모 에이전트 코딩의 핵심 가치다.

8. 코드베이스 소유자가 확인해야 할 전역 질문

대규모 코드베이스를 건강하게 유지하려면 코드의 현재 위치와 실행 상태를 저장소 단위가 아니라 회사 전체의 연결망으로 확인해야 한다.

8.1. 숨은 코드의 인벤토리

1. 저장소와 포크의 전체 수

   1. 기본 인벤토리: 회사 코드베이스에 저장소가 몇 개 있는지 알아야 한다.
   2. 복제본과 포크: 같은 코드의 포크와 복사본이 몇 개 존재하는지 파악해야 한다. 한 원본만 고쳐서는 모든 실행 경로가 수정되지 않을 수 있다.

2. 개발자가 가져온 외부 코드

   1. 내부 유입 코드: 개발자가 회사로 가져와 라이브러리로 연결했거나 API로 사용하도록 만든 저장소가 있을 수 있다.
   2. 운영 중인 미인지 의존성: 소유자가 그 사실을 모르는 상태에서도 해당 코드가 실제 제품과 운영 환경에 연결되어 있을 수 있다.

8.2. 배포 상태와 업데이트 범위

1. 현재 무엇이 배포됐는가

   1. 실행 현실: 저장소에 존재하는 코드와 실제로 배포되어 사용되는 코드는 다를 수 있으므로, 현재 운영 중인 코드를 별도로 확인해야 한다.
   2. 제품 전반의 연결: 회사 전체 제품과 서비스에서 어떤 구현이 살아 있는지 알아야 취약점과 표준 변경의 실제 영향 범위를 계산할 수 있다.

2. 무엇이 아직 업데이트되지 않았는가

   1. 누락 탐지: 모든 복사본·포크·서비스를 스캔해 패치가 빠진 곳을 찾고, 전체 범위를 덮었는지 확인해야 한다.
   2. 변경의 증거: “모두 업데이트했다”는 선언이 아니라 저장소별 상태·CI 결과·PR 기록·실패 재시도 내역이 신뢰의 근거가 된다.

주요 발언 모음

“코딩 에이전트는 지금까지 본 것보다 더 빠르게, 더 많은, 더 나은 코드를 작성하고 있다.”

“이 거대한 코드베이스는 세계를 움직이지만, 이제 부식되기 시작하고 있다.”

“물론 Claude Code는 이 변경을 할 수 있다. 하지만 나는 이 변경을 해야 할 저장소가 90,000개 있다.”

“LLM에 대해 우리가 아는 한 가지가 있다면, LLM은 검색을 정말 좋아한다는 것이다.”

“당신이 실제로 볼 수 없는 것은 grep할 수 없다.”

“가시성은 인프라다(Visibility is infrastructure).”

“코드베이스의 위험이 존재하는 모든 곳에 변경을 적용했다는 확신이 에이전트 코딩 시대의 전부다.”

“대규모 코드베이스가 몇 개인지, 포크가 몇 개인지, 복사본이 몇 개인지, 지금 실제로 무엇이 배포되어 있는지 알고 싶다면 우리가 돕겠다.”

핵심 데이터 & 수치

• 72%: 소프트웨어 산업 고용의 72%가 직원 500명 초과 기업에 속한다.
• 수천 개 저장소: 대기업은 수천 개의 저장소와 수십 년치 코드 역사를 운영한다.
• 수백만 줄: 대규모 코드베이스는 수백만 줄의 코드로 구성된다.
• 90,000개 저장소: 톱10 미국 은행 기술 리더가 한 번의 변경을 적용해야 하는 저장소 규모로 제시한 수치다.
• 500·5,000·50,000·500,000개 저장소: 검색과 이해 인프라가 대응해야 할 코드베이스 규모의 예시다.
• 수백~수천 개 저장소: Agentic Batch Changes가 단일 프롬프트로 변경을 실행하도록 목표로 하는 범위다.
• 100% 커버리지: 패치가 필요한 모든 위치를 처리했는지 추적·감사해야 한다.
• Mercari 추가 80건: 이미 문제를 알고 있던 두 저장소에서 시작해 다른 위치의 잠재 환경 변수 취약점 80건을 추가로 발견했다.
• 수백 개 마이크로서비스: Mercari가 운영하는 독립 서비스 규모로, 전역 탐색의 필요성을 보여 준다.

결론 및 시사점

1. 코드 생산성의 다음 병목은 생성이 아니라 관리다: 에이전트가 코드를 빠르게 만드는 능력은 이미 충분히 강력하며, 앞으로는 늘어난 코드의 표준·의존성·보안·배포 상태를 관리하는 능력이 경쟁력이 된다.
2. 대규모 코드는 컨텍스트 윈도우에 넣을 대상이 아니라 탐색할 그래프다: 수만 개 저장소를 통째로 복제하는 대신 검색, 의존성 관계, 컴파일러 수준 분석을 결합해 필요한 맥락을 정확히 제공해야 한다.
3. AGENTS.md와 국소 리뷰만으로 전역 위험을 막을 수 없다: 문서와 PR 검토는 필요하지만 포크·복사본·외부 유입 라이브러리·운영 배포본까지 보려면 별도의 전역 인덱스와 코드 그래프가 필요하다.
4. 판단형 에이전트와 결정론적 자동화를 함께 써야 한다: 비정형 판단은 코딩 에이전트에 맡기고 동일한 설정 패치는 결정론적 스크립트로 실행해야 규모와 일관성을 동시에 확보할 수 있다.
5. 대규모 변경의 신뢰는 완료 선언이 아니라 감사 가능성에서 나온다: CI 상태, PR 댓글, 실패 복구, 저장소별 커버리지와 변경 기록을 남겨 실제로 100% 처리했는지 증명해야 한다.
6. 코드 소유자는 숨은 실행 경로를 인벤토리화해야 한다: 포크, 복사본, 개발자가 가져온 라이브러리와 API, 실제 배포된 버전을 찾아야 패치의 진짜 범위를 알 수 있다.
7. 에이전트 시대의 건강한 코드베이스는 보이는 코드베이스다: 무엇이 어디에 있고 어떻게 연결되며 무엇이 운영 중인지 볼 수 있을 때에만 더 많은 코드가 시스템을 무너뜨리는 대신 안전하게 진화할 수 있다.
8. 현장의 문제를 공유하는 커뮤니티가 필요하다: 샌프란시스코에서 열린 Code Cocktails and Cutovers 행사처럼 가장 까다로운 코드베이스 사례를 가져와 실제 운영 문제와 해결법을 공유해야 한다.

핵심 요약 20줄

AI 코딩 에이전트는 역대 가장 빠른 속도로 더 많은 코드를 만들어 내고 있다.

소프트웨어 업계 고용의 72%는 직원 500명 초과 기업에 집중되어 있다.

대기업의 수천 개 저장소와 수십 년치 코드는 세계의 금융과 물류를 움직인다.

은행 거래와 보험 보상부터 우버 도착 시간과 항공기 궤적까지 거대한 코드가 담당한다.

AI가 만든 코드의 급류는 엔지니어에게 검토와 유지보수 부담을 떠넘긴다.

수백만 줄의 코드와 수만 개 저장소는 하나의 컨텍스트 윈도우에 들어오지 않는다.

서로 다른 에이전트가 서로 다른 표준을 적용하면서 코드베이스의 일관성이 흔들린다.

에이전트는 이미 있는 라이브러리를 찾지 못해 중복 코드를 계속 만들어 낸다.

교차 서비스 의존성은 부분적인 맥락에서 이뤄진 변경 때문에 더 취약해진다.

에이전트는 취약점을 빠르게 발견하지만 새로운 취약한 코드도 빠르게 만들 수 있다.

톱10 자동차 제조사에서 개발자가 AI가 쓴 코드의 동작을 모른다고 말한 사례가 나왔다.

톱10 미국 은행은 한 번의 공급망 패치를 적용해야 할 저장소가 90,000개라고 밝혔다.

LLM은 검색으로 코드베이스의 세계 모델을 만들기 때문에 보이지 않는 코드는 이해할 수 없다.

AGENTS.md에 아키텍처를 적는 것만으로는 수만 개 저장소의 전역 맥락을 제공할 수 없다.

Sourcegraph는 검색과 컴파일러 수준 분석을 결합한 code graph를 핵심 인프라로 제시한다.

Agentic Batch Changes는 한 번의 프롬프트로 수백~수천 개 저장소에 변경을 적용한다.

이 에이전트는 CI 상태와 PR 댓글에 반응하고 오류를 스스로 고치며 변경 범위를 추적한다.

Mercari에서는 두 저장소에서 시작한 탐색이 잠재 취약점 80건을 추가로 찾아냈다.

결정론적 스크립트와 에이전트 판단을 결합해야 대규모 변경의 일관성과 유연성을 확보할 수 있다.

에이전트 시대의 신뢰는 코드 생성량이 아니라 전체 코드베이스의 가시성과 100% 감사 가능성에서 나온다.