AI 코딩 에이전트 시대, 대규모 코드베이스를 지키는 가시성 인프라

URL: https://www.youtube.com/watch?v=oeL0uP-NO-U 날짜: 2026-10-06 채널: Tech Bridge 발표자: Dan Adler, Sourcegraph

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

==AI 코딩 에이전트가 코드를 더 빠르게 쓰는 동안, 수만 개 저장소로 이루어진 대규모 코드베이스를 누가 보고·이해하고·건강하게 유지할 것인가?==

• 소프트웨어 산업의 중심은 소수의 신생 스타트업이 아니라 수천 개 저장소와 수십 년의 역사를 가진 대기업의 장수 코드베이스다.
• 에이전트는 기능과 패치를 기록적인 속도로 생성하지만, 서로 다른 표준·중복 구현·취약한 서비스 의존성·새로운 취약점을 함께 늘린다.
• 작은 문제를 푸는 에이전트의 능력과 대규모 코드베이스 전체를 이해하는 능력 사이에는 커다란 인프라 격차가 있다.
• 에이전트가 안전하게 대규모 변경을 수행하려면 검색(Search), 코드 그래프(Code Graph), 컴파일러 수준의 정확한 분석, 단계적 실행, CI·PR 피드백, 감사 가능성이 결합되어야 한다.

대규모 코드베이스의 소유권은 AI 시대에 덜 중요해지는 관리 업무가 아니라 핵심 인프라 업무가 된다. 코드 생산 속도만 높이면 코드의 양과 복잡도가 시스템을 압도할 수 있으므로, 가시성(Visibility)과 변경의 완전성·일관성·추적 가능성을 함께 확장해야 한다.

1. 세계를 움직이는 소프트웨어는 크고 오래되고 지저분하다

대부분의 개발자는 소셜 미디어에 자주 등장하는 최신 스타트업이 아니라 오랜 시간 축적된 복잡한 코드베이스를 운영한다.

1.1. 소프트웨어 산업의 실제 중심

1. 대기업에 집중된 고용 구조

   1. 72%라는 비중: 소프트웨어 산업 고용의 72%가 직원 500명 초과 기업에 속한다.
   2. 대기업의 운영 범위: 이런 기업은 수천 개의 저장소(repository)와 수십 년 동안 쌓인 코드베이스의 역사를 관리한다.
   3. 스타트업 환상과 현실: 소셜 미디어에서 접하는 인기 스타트업이나 소셜 피드만으로 생계를 꾸리는 1인 사업자는 개발자 집단의 일부에 불과하다.
   4. 대부분의 개발자 환경: 실제로는 많은 개발자가 대규모·장수(long-lived) 코드베이스에서 일한다.

2. 오래된 코드가 담당하는 생활 인프라

   1. 금융 거래: 은행 계좌가 한도에 도달한 거래를 실시간으로 거절하는 판단을 코드가 수행한다.
   2. 보험 산정: 보험사가 이중 보장(dual coverage)을 가진 가입자의 보상률(reimbursement rate)을 계산하는 과정이 코드 위에서 작동한다.
   3. 물류와 배송: 칩과 창고 스캐너가 Amazon에 양말이 도착할 시점을 알려주는 물류 흐름을 구현한다.
   4. 이동과 항공: Uber의 도착 예정 시간(ETA) 계산과 항공기의 레이더 기반 궤적 조정이 코드에 의존한다.
   5. 일상 운영: 급여 지급과 사무실 에어컨 가동도 수많은 코드의 지속적인 실행으로 가능해진다.

1.2. 코드베이스 소유가 맡는 보이지 않는 책임

1. 세계의 작동을 떠받치는 누적 자산

   1. 수십 년에 걸쳐 수천 명의 엔지니어가 만든 거대하고 복잡한 코드베이스가 금융·보험·물류·교통·급여 같은 기능을 계속 제공한다.
   2. 이 코드가 아름답거나 최신이거나 깨끗하지 않다는 사실은 결함이라기보다 실제 비즈니스와 운영이 축적된 결과다.

2. 소유자의 역할

   1. 코드베이스 소유자는 새로운 기능만 출시하는 사람이 아니라 기존 시스템이 계속 작동하도록 구조와 의존성을 기억하고 관리해야 한다.
   2. 이 업무는 화려하지 않지만(load-bearing), 장애가 발생하지 않도록 세계의 일상 흐름을 지탱하는 하중 지지 구조에 해당한다.

2. AI가 코드 생산을 폭증시키면서 유지보수 부담을 키운다

코딩 에이전트는 이전보다 많은 코드를 빠르게 작성하지만, 코드베이스의 건강성을 같은 속도로 보장하지는 못한다.

2.1. 다가오는 코드의 물결

1. 생산 속도의 급상승

   1. 코딩 에이전트는 과거 어느 때보다 빠르게 더 많은 코드를 작성하고 있다.
   2. 이 속도는 개별 개발자의 생산성 향상인 동시에 팀과 전체 코드베이스로 밀려오는 거대한 코드의 물결(tidal wave)이다.
   3. 팀은 AI가 생성한 코드가 건강한지 검토해야 하며, 이미 많은 엔지니어가 이 검토량에 지쳐 있다.

2. 기존 대응의 한계

   1. 코드 리뷰 에이전트와 코드베이스 건강성 측정 도구가 등장해 생성 코드의 문제를 찾아내려 한다.
   2. 주요 코딩 에이전트에 이런 도구와 검사 결과를 더 많이 통합하고 모델을 개선하는 방식도 시도된다.
   3. 조직은 문제를 막기 위해 모래주머니(sandbag)를 쌓듯 국소적인 해결책(local maxima)을 계속 추가하지만, 전체 코드베이스의 구조적 부패를 멈추지는 못한다.

2.2. 빠른 변경이 만드는 구조적 부채

1. 규모가 컨텍스트 창을 초과한다

   1. 대규모 시스템에는 수백만 줄의 코드와 수만 개의 저장소가 존재한다.
   2. 전체 내용을 하나의 컨텍스트 윈도우(context window)에 넣을 수 없고, 실시간으로 전부 복제(clone)해 분석하는 것도 불가능하다.
   3. 에이전트가 작은 작업의 국소 맥락을 잘 처리해도, 조직 전체에 존재하는 관련 구현과 영향을 동시에 파악하지 못할 수 있다.

2. 일관성의 붕괴

   1. 서로 다른 에이전트가 코드베이스의 서로 다른 장소에 서로 다른 코딩 표준을 적용한다.
   2. 이미 같은 일을 하는 라이브러리가 존재해도 에이전트가 이를 모르면 중복 코드가 증식한다.
   3. 서비스 간 의존성이 점점 더 취약해지고, 표준에서 조금씩 벗어난 구현이 코드베이스 곳곳에 숨은 문제를 만든다.

3. 보안 위험의 확대

   1. 에이전트는 매일 새로운 취약점을 발견하지만, 그만큼 새로운 취약점을 만들어낼 가능성도 커진다.
   2. 대규모 레거시 코드베이스는 계속된 감독(oversight)과 유지관리(upkeep)가 필요하다.
   3. 누구도 다루고 싶어 하지 않는 오래된 시스템을 방치하면 AI가 늘린 코드량이 실패 조건을 만든다.

2.3. “집 안에서 전화가 걸려 온다”는 역설

1. 가속 도구가 위험의 원인이 된다

   1. 문제의 전화는 외부가 아니라 “집 안에서” 걸려 온다(call is coming from inside the house).
   2. 모두의 개발 속도를 높이고 코드를 더 빨리 쓰게 하는 도구 자체가, 세계를 움직이는 대규모 코드베이스가 실패할 조건을 만들고 있다.

2. 경영진이 체감하는 공포

   1. 대기업의 기술 임원들은 AI 도입의 생산성 기대와 코드 이해 가능성의 상실을 동시에 체감한다.
   2. 한 기술 리더가 미국 상위 10대 자동차 제조사에서 들은 말은 “이 코드가 무엇을 하는지 모르겠다. AI가 나를 대신해 작성했다(I don't know what this code does. AI wrote it for me)”였다.
   3. 수천 명의 엔지니어가 있는 조직에서 차량의 오토파일럿(autopilot) 코드를 다룰 때, 작성자가 코드를 이해하지 못하는 상황은 단순한 품질 문제가 아니라 안전 문제다.

3. 작은 문제를 잘 푸는 에이전트와 대규모 맥락의 격차

에이전트는 개발자의 일상적인 작은 문제를 매우 잘 해결하지만, 대규모 코드베이스 전체를 보고 이해하는 기반 시설은 아직 부족하다.

3.1. 50,000개 저장소를 볼 수 없는 에이전트

1. 현재 도구의 초점

   1. OpenAI·Anthropic·Cursor를 비롯한 주요 도구 제공자는 소규모 문제 해결 능력을 빠르게 발전시켰다.
   2. 이 능력이 좋아질수록 개발자 수요는 커지지만, 대규모 코드베이스가 무너지기 시작하는 더 큰 문제는 눈에 띄지 않게 된다.
   3. 50,000개 저장소를 보고 이해하는 인프라는 아직 충분히 만들어지거나 판매되지 않는다.

2. 대규모 변경의 현실

   1. 미국 상위 10대 은행 중 한 곳의 기술 리더는 수조 달러 규모의 자산을 보관·관리하는 조직의 현실을 다음과 같이 표현했다.
      • “Claude Code가 이 변경을 할 수는 있다. 하지만 그 변경을 해야 할 저장소가 90,000개 있다(Sure, Claude Code can make this change, but I have 90,000 repositories to make it in).”
   2. 이 말은 Claude Code의 개별 변경 능력을 부정하는 것이 아니라, 적용 대상의 완전한 목록·생산 환경·서비스 관계를 파악할 수 없는 조직 규모의 문제를 지적한다.

3.2. 검색은 에이전트의 세계 모델을 만드는 기본 행동이다

1. LLM과 신규 입사자의 공통점

   1. LLM은 검색(search)을 좋아하며, 저장소를 검색하면서 세계의 모델을 만든다.
   2. 이 과정은 코드베이스에 새로 들어온 신입사원이 구조와 관례를 익히는 과정과 비슷하다.
   3. 에이전트에게 제공되는 agents.mmd 같은 저장소 아키텍처 문서만으로는 문제를 조금 완화할 뿐이며, 전체 이해를 크게 바꾸기에는 부족하다.

2. 보지 못하는 것은 이해할 수 없다

   1. 에이전트는 검색을 반복하며 코드베이스를 이해하려 하지만, 실제로 보지 못한 코드와 관계는 추론할 수 없다.
   2. “이해(understanding)는 컨텍스트 문제”이며, 컨텍스트를 제공하는 핵심은 에이전트가 필요한 범위를 볼 수 있게 하는 도구와 인프라다.
   3. 500개·5,000개·50,000개·50만 개 저장소 규모의 코드베이스를 깊게 검색하고 이해하는 기반이 현재 에이전트 빌더의 표준 구성에 포함되어 있지 않다.

4. 대규모 코드베이스를 위한 가시성 인프라

대규모 변경의 품질은 모델의 문장 생성 능력만으로 결정되지 않으며, 코드 구조를 정확하게 표현하고 검색하는 인프라에 좌우된다.

4.1. 코드 그래프와 컴파일러 정확성

1. 코드 그래프(Code Graph)의 역할

   1. 코드 그래프는 저장소와 서비스, 호출 관계, 심볼, 의존성을 연결해 코드베이스의 구조를 표현하는 기반 그래프다.
   2. 코드 그래프에는 강력한 검색과 실제 컴파일러에 가까운 정확한 분석 결과가 함께 들어가야 한다.
   3. 에이전트가 변경 전에 영향 범위와 관련 구현을 파악하려면 이런 구조적 지식이 필요하다.

2. 가시성은 인프라다

   1. 대규모 코드베이스의 가시성(visibility)은 편의 기능이 아니라 에이전트가 안전하게 변경을 실행하기 위한 인프라다.
   2. 검색만으로 놓칠 수 있는 서비스 간 관계와 실제 컴파일 결과를 코드 그래프가 보완한다.
   3. 더 많은 코드가 만들어질 미래에는 코드의 생성 능력보다 코드 전체를 볼 수 있는 능력이 시스템 신뢰성을 결정한다.

4.2. 더 많은 코드가 예정된 미래

1. 거대 코드베이스는 사라지지 않는다

   1. 기업의 오래된 코드베이스와 대규모 저장소는 AI 때문에 없어지지 않는다.
   2. 오히려 앞으로 코드의 양은 훨씬 더 많아진다.
   3. 따라서 대규모 코드베이스를 실제로 보고 이해하고 진화시키는 도구는 소프트웨어 산업의 필수 요소가 된다.

2. 코드베이스 소유자의 우선순위 변화

   1. 소유자는 “에이전트가 코드를 쓸 수 있는가”만 묻지 않고 “필요한 모든 위치를 빠짐없이 찾았는가”를 확인해야 한다.
   2. 변경이 일관되게 적용됐는지, CI와 PR 피드백을 통과했는지, 운영 코드에 어떤 영향이 있는지까지 추적해야 한다.

5. 수천 개 저장소에 변경을 확장하는 실행 모델

Sourcegraph가 제시한 에이전트형 배치 변경(Agentic Batch Changes)은 대규모 코드베이스의 가시성과 변경 실행을 결합하는 사례다.

5.1. 단일 프롬프트에서 단계적 배포까지

1. Agentic Batch Changes의 범위

   1. 이 제품은 발표 당일 베타(beta)로 공개된 새로운 에이전트형 배치 변경 제품이다.
   2. 대규모 코드베이스 소유자가 하나의 프롬프트로 수백 또는 수천 개 저장소에 코드 변경을 실행하게 한다.
   3. 한 번에 무차별적으로 수정하지 않고 코드베이스 전체에 변경을 반복적·단계적으로 전개한다.

2. 에이전트와 결정론적 도구의 분업

   1. 판단이 필요한 장소에는 코딩 에이전트를 사용한다.
   2. 동일한 패턴을 일괄 적용하는 작업에는 결정론적 스크립트(deterministic script)를 사용한다.
   3. 각 방식의 강점을 구분하면 모델의 불필요한 변동성을 줄이고 반복 변경의 일관성을 높일 수 있다.

5.2. 실패에 대응하는 운영 루프

1. 자동 복구와 피드백 반영

   1. 실행된 변경은 CI 상태를 확인하고 결과에 따라 스스로 복구(self-heal)할 수 있어야 한다.
   2. PR 댓글(comments)을 읽고 변경을 조정하는 피드백 루프가 필요하다.
   3. 에이전트는 단순히 패치를 생성하는 데서 끝나지 않고, 코드 호스팅과 검증 과정의 실제 상태에 반응해야 한다.

2. 추적성과 감사 가능성

   1. 어떤 저장소가 처리됐고 어떤 곳이 누락됐는지 추적해야 한다.
   2. 변경이 필요한 모든 위치의 100%를 다뤘다는 사실을 확인할 수 있어야 한다.
   3. 대규모 조직에서는 “작동하는 두 개의 예시”가 아니라 적용 범위 전체를 입증하는 감사 가능성(auditability)이 신뢰의 기준이다.

6. 보안 패치 사례가 보여주는 대규모 변경의 가치

실제 대규모 마이크로서비스 조직에서는 작은 범위에서 확인한 취약점이 전체 코드베이스에 훨씬 넓게 존재할 수 있다.

6.1. Mercari의 GitHub 코드 인젝션 문제

1. 조직과 시스템의 규모

   1. 일본의 글로벌 쇼핑 서비스 Mercari는 수백 개가 넘는 독립 마이크로서비스를 운영하는 대규모 코드베이스를 가진다.
   2. 각 마이크로서비스가 운영 환경에서 독립적으로 실행되므로 동일한 설정 위험이 여러 저장소에 반복될 수 있다.

2. 두 저장소에서 시작한 점검

   1. 사용자는 GitHub 코드 인젝션(code injection) 문제를 해결하기 위해 환경 변수(environment variable)를 올바르게 설정해야 하는 패치를 수행했다.
   2. 먼저 해당 문제가 존재한다는 사실을 알고 있던 두 저장소에 변경을 실행했다.
   3. 이후 에이전트에게 나머지 코드베이스도 탐색하도록 요청했다.

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

1. 탐색 결과

   1. 나머지 코드베이스를 탐색한 결과, 동일하거나 유사한 위험이 있는 잠재 취약점 80개가 추가로 발견됐다.
   2. 위험은 주로 설정 파일(config file)에 존재했으며, 단일 저장소에서만 고치는 방식으로는 해결되지 않았다.

2. 일관된 일괄 수정

   1. 발견된 위치를 한 번에 스캔하고 모두 패치하는 결정론적 스크립트를 적용했다.
   2. 같은 변경을 위험이 존재하는 100개 위치에 일관되고 효과적으로 적용할 수 있었다.
   3. 이 과정에서 중요한 결과는 코드 생성 자체가 아니라, 위험이 있는 모든 위치를 찾았다는 확신(confidence)이다.

주요 발언 모음

“소프트웨어 산업 고용의 72%는 직원 500명 초과 기업에 있다.”

“코드의 물결이 여러분에게, 여러분의 코드베이스에, 그저 고개를 물 위로 유지하려는 팀의 모든 엔지니어에게 다가오고 있다.”

“이 코드가 무엇을 하는지 모르겠다. AI가 나를 대신해 작성했다.”

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

“LLM이 무엇을 좋아하는지 안다면, LLM은 검색을 정말 좋아한다.”

“말 그대로 볼 수 없는 것은 grep할 수 없다.”

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

“에이전트 코딩 시대에 확신이란, 위험이 존재하는 100개 위치 모두에서 변경이 이뤄졌다는 것을 아는 것이다.”

핵심 데이터 & 수치

• 72%: 소프트웨어 산업 고용 중 직원 500명 초과 기업이 차지하는 비중이다.
• 수천 개 저장소: 대기업이 수십 년의 코드 역사와 함께 관리하는 전형적인 규모다.
• 수백만 줄의 코드: 대규모 코드베이스의 전체 맥락을 단일 컨텍스트 윈도우에 넣을 수 없게 만드는 양이다.
• 500·5,000·50,000·50만 개 저장소: 코드베이스 가시성 인프라가 대응해야 하는 규모의 범위다.
• 90,000개 저장소: 미국 상위 10대 은행 중 한 곳의 기술 리더가 한 변경을 적용해야 한다고 제시한 대상 규모다.
• 수조 달러 자산: 위 은행이 보관 또는 관리하는 자산 규모의 맥락이다.
• 80개 잠재 취약점: Mercari가 두 저장소의 알려진 문제에서 출발해 전체 코드베이스를 탐색한 뒤 추가로 발견한 수다.
• 100개 위치: 결정론적 스크립트로 같은 설정 위험 패치를 일관되게 적용해야 했던 전체 위치의 규모다.
• 수백~수천 개 저장소: Agentic Batch Changes가 하나의 프롬프트로 변경을 확장하는 목표 범위다.

전체 흐름

1. 세계의 금융·보험·물류·교통·급여·건물 운영은 오래되고 복잡한 대규모 코드베이스에 의존한다.
2. 소프트웨어 고용의 다수는 이런 시스템을 보유한 대기업에 있으며, 코드베이스 소유는 필수적이지만 눈에 잘 띄지 않는 업무다.
3. AI 코딩 에이전트가 코드 생산량을 기록적으로 늘리면서 검토량, 중복, 표준 편차, 의존성 취약성, 보안 위험도 함께 늘어난다.
4. 수백만 줄과 수만 개 저장소는 하나의 컨텍스트 창이나 실시간 복제로 다룰 수 없으므로, 에이전트의 작은 문제 해결 능력만으로는 부족하다.
5. 90,000개 저장소의 은행 변경 사례와 오토파일럿 코드의 “AI가 썼지만 무엇을 하는지 모른다”는 발언은 규모와 안전의 간극을 보여준다.
6. 에이전트가 보지 못한 코드를 이해할 수 없으므로 검색·코드 그래프·컴파일러 정확성에 기반한 가시성 인프라가 필요하다.
7. 대규모 변경에는 에이전트의 판단, 결정론적 스크립트의 일관성, CI·PR 피드백, 단계적 실행, 추적성과 감사 가능성이 함께 필요하다.
8. Mercari의 80개 잠재 취약점 발견 사례는 작은 샘플에서 시작해 전체 코드베이스를 탐색할 때 얻는 운영상의 확신을 보여준다.

결론 및 실용적 시사점

1. 코드 생성량보다 코드베이스 가시성을 먼저 확보해야 한다

   1. 에이전트를 도입하기 전에 조직 전체 저장소, 서비스, 의존성, 운영 위치를 검색하고 연결하는 기반을 마련해야 한다.
   2. agents.mmd 같은 설명 문서만으로는 충분하지 않으며, 실제 코드 관계와 컴파일러 수준의 분석 결과가 필요하다.

2. 변경 대상을 완전하게 찾는 능력을 측정해야 한다

   1. “두 저장소에서 패치가 통과했다”가 아니라 “위험이 있는 100개 위치를 모두 처리했다”를 성공 기준으로 삼아야 한다.
   2. 처리·누락·실패·재시도 상태를 저장해 감사 가능한 변경 이력을 만들어야 한다.

3. 작업 유형에 따라 에이전트와 스크립트를 나눠야 한다

   1. 맥락과 판단이 필요한 변경은 코딩 에이전트에 맡긴다.
   2. 같은 패턴의 설정 변경처럼 규칙이 명확한 작업은 결정론적 스크립트로 일관되게 적용한다.

4. CI와 PR을 변경 루프 안에 포함해야 한다

   1. 일괄 변경은 실행으로 끝내지 않고 CI 결과와 PR 댓글을 읽어 수정·복구해야 한다.
   2. 단계적 롤아웃으로 작은 범위의 실패를 확인한 뒤 다음 저장소 묶음으로 확장해야 한다.

5. 코드베이스 소유 업무를 전략적 인프라로 격상해야 한다

   1. 대규모 시스템의 건강성, 보안, 일관성, 의존성 관리는 AI 시대에 더 중요해진다.
   2. 개발 도구 회사와 에이전트 하네스(harness) 제작자는 단일 저장소의 코드 생성이 아니라 500개에서 50만 개 저장소를 이해하고 진화시키는 능력을 제품의 중심에 둬야 한다.

6. AI 시대의 신뢰는 ‘무엇을 바꿨는가’와 ‘무엇을 빠뜨리지 않았는가’를 함께 증명하는 데서 나온다

   1. 대규모 코드베이스는 앞으로 더 커지므로, 검색 가능한 구조적 맥락과 전체 적용 범위를 증명하는 추적성이 개발 생산성만큼 중요한 품질 요소가 된다.
   2. AI가 코드를 많이 쓰는 시대의 최종 경쟁력은 더 많은 코드를 생성하는 능력이 아니라, 필요한 모든 곳에 안전하고 일관되게 적용하고 그 결과를 설명하는 능력이다.

핵심 요약 (20줄)

1. 소프트웨어 산업 고용의 72%는 직원 500명 초과 기업에 집중되어 있다.
2. 대기업은 수천 개 저장소와 수십 년의 코드 역사를 관리한다.
3. 은행 거래와 보험 산정부터 배송·이동·항공·급여·냉방까지 오래된 코드가 일상을 움직인다.
4. 코딩 에이전트는 과거보다 훨씬 빠르게 더 많은 코드를 생산한다.
5. AI가 만든 코드의 홍수는 엔지니어에게 검토와 건강성 확인 부담을 떠넘긴다.
6. 수백만 줄의 코드와 수만 개 저장소는 하나의 컨텍스트 창에 담을 수 없다.
7. 서로 다른 에이전트가 서로 다른 표준을 적용하면 코드베이스의 일관성이 무너진다.
8. 에이전트가 기존 라이브러리를 찾지 못하면 중복 코드가 빠르게 증식한다.
9. 서비스 간 의존성의 취약성과 작은 표준 편차가 숨은 장애를 만든다.
10. AI 에이전트는 새로운 보안 취약점을 발견하고 만들어내는 속도도 높인다.
11. 자동차 오토파일럿 코드의 작성자가 코드를 이해하지 못하는 상황은 안전 문제다.
12. 미국 상위 10대 은행의 90,000개 저장소는 단일 에이전트 명령만으로 관리할 수 없다.
13. LLM은 검색으로 코드베이스의 세계 모델을 만들지만 보지 못한 코드는 이해할 수 없다.
14. agents.mmd 같은 아키텍처 문서만으로는 대규모 맥락 문제를 해결하기 어렵다.
15. 500개에서 50만 개 저장소를 다루려면 검색과 코드 그래프 인프라가 필요하다.
16. 코드 그래프는 검색과 컴파일러 수준의 정확한 분석을 결합해야 한다.
17. Agentic Batch Changes는 하나의 프롬프트로 수백~수천 개 저장소에 변경을 확장한다.
18. 판단이 필요한 작업은 에이전트가, 반복적이고 규칙적인 작업은 결정론적 스크립트가 맡아야 한다.
19. Mercari 사례는 두 저장소에서 시작한 점검으로 80개의 잠재 취약점을 추가 발견했다.
20. AI 코딩 시대의 신뢰는 필요한 모든 위치를 찾고 일관되게 패치했음을 감사 가능하게 증명하는 데서 나온다.