AI로 VS Code를 월간 릴리스에서 주간 릴리스로 전환한 방법

URL: https://www.youtube.com/watch?v=I2LL_wd89-A
날짜: 2026-10-04
채널: aiDotEngineer
발표자: Harald Kirschner

---

📌 핵심 질문·주장과 근거

AI의 가치는 코드를 더 많이 생성하는 데 있지 않고, 개발·검증·릴리스·학습 전체의 피드백 루프를 다시 설계해 더 좋은 제품을 더 빠르게 만드는 데 있다.

• 에이전트가 작성한 코드의 실제 채택률을 추적하고 하네스(harness)와 모델을 개선한 결과, GPT-4.1 초기 55%였던 코드 생존율(code survival)이 Claude Opus 4.6에서 86%까지 올랐다.
• 코드베이스를 AGENTS.md와 도메인 스킬(skill)로 정리하고, TypeScript Go로 빌드를 10배 빠르게 하며, UI 스크린샷 차이와 Playwright 기반 실행 검증을 자동화했다.
• AI가 늘린 Issue와 에러 로그를 필터링·분류·번역·할당하고, 자동 수정 PR까지 연결하되 인간의 피드백과 승인을 남겼다.
• 100% 일괄 배포 대신 단계적 롤아웃과 모니터링을 적용하고, VSCBench 평가와 일일 프로토타입으로 사용자 신호에서 제품 판단까지의 시간을 줄였다.

핵심은 AI 사용량이나 토큰 사용량을 최대화하는 것이 아니다. 코드 생성 속도가 올라갈수록 다음 병목은 코드 리뷰, 배포 위험, 제품 판단, 그리고 학습 속도로 이동하므로, 한 병목을 풀 때마다 새로 드러난 병목에 맞춰 시스템과 피드백 루프를 계속 고쳐야 한다.

1. 월간 릴리스에서 주간 릴리스로 바뀐 배경

VS Code는 10년 넘게 월간 릴리스를 유지하다가 AI를 활용한 새로운 워크플로에 맞춰 주간 릴리스로 이동했다.

1.1. 발표의 출발점과 범위

1. 가벼운 농담으로 청중과 연결하기

   1. 앞선 공연 뒤에 발표하기가 어렵고 사람들이 왜 모두 떠났는지 모르겠다는 농담으로 시작했다.
   2. 전날 위층에서 했던 강연을 반복하는 자리이지만 전날보다 더 나은 내용일 것이며, 이 자리를 고른 청중이 옳았다고 말했다.

2. 논의의 초점 정하기

   1. VS Code와 Copilot AI 등 제품을 만드는 과정에서 에이전트(agent)를 어떻게 사용하는지가 중심이다.
   2. VS Code 안에 에이전트를 넣는 방법이나 부스에서 볼 수 있는 데모 자체가 아니라 제품을 만드는 시스템의 변화가 대상이다.
   3. 에이전트와 AI 사용을 늘리면 기존 방식이 더 이상 작동하지 않는 지점이 생기므로 일하는 방식 자체를 다시 설계해야 한다.
   4. 아주 작은 팀이 5,000만 명이 넘는 사용자에게 제품을 제공한다는 규모가 변화의 배경이다.

1.2. 코드 생존율이 보여준 신뢰의 상승

1. 코드 생존율(code survival) 정의하기

   1. 에이전트가 작성한 코드 중 실제로 승인되어 커밋되는 비율을 측정한다.
   2. 에이전트가 쓸모없는 코드를 얼마나 만들었는지, 사람이 읽고도 믿지 못해 버리거나 삭제한 양이 얼마나 되는지를 확인하는 지표다.

2. 55%에서 86%로 올라간 채택률

   1. GPT-4.1을 사용하던 초기 코드 생존율은 55%였다.
   2. 하네스를 개선하고 새로운 모델을 도입하면서 Claude Opus 4.6에서는 86%까지 상승했다.
   3. 상승한 수치는 개발자가 AI가 만든 코드를 더 신뢰하고, 제품에 더 빨리 반영하며, 더 많은 코드를 생성하게 된 과정을 보여준다.

3. 성공이 만든 새로운 부담

   1. VS Code는 GitHub에서 가장 큰 오픈소스 프로젝트 중 하나이거나 가장 큰 프로젝트일 수 있다.
   2. AI가 Issue 작성을 도우면서 고품질 Issue와 자동 생성된 저품질 Issue가 동시에 늘었다.
   3. 팀 내부 개발 속도가 올라가 팀 PR이 많아졌고, 커뮤니티 PR도 많아졌다.
   4. 쓸모없는 PR만 폭증할 것이라는 예상과 달리 실제로는 커뮤니티에서 병합되는 PR도 증가해 더 많은 기여를 끌어냈다.

1.3. 릴리스 속도와 AI 사용량을 혼동하지 않기

1. 월간 릴리스의 역사

   1. VS Code 1.0 이후 10년 넘게 매달 새 버전을 내놓았다.
   2. 1월 릴리스가 실제로는 2월에 나오는 운영 방식도 있었다.
   3. 2월에 1월 릴리스 노트를 읽는 것이 한 달 늦은 것이 아니라, 이터레이션(iteration)을 그렇게 관리한 결과라는 농담이 나왔다.

2. 주간 릴리스의 목적

   1. 릴리스 간격을 개발 속도에 맞추는 것이 직접적인 목적이었다.
   2. 그러나 매일 AI를 더 쓰거나 토큰 사용량을 최대화하는 것이 해답은 아니었다.
   3. AI가 전체 소프트웨어 전달 프로세스에서 더 효과적으로 일하도록 개발·검증·운영 시스템을 진화시켜야 속도 증가가 코드 양 증가로 끝나지 않는다.

2. 개발 속도가 먼저 만들고 드러낸 다음 병목

빠르게 코드를 내보내는 단계는 비교적 쉽지만, 품질과 제품 판단까지 빠르게 만들려면 다른 시스템이 필요하다.

2.1. 코드 생성 속도에서 품질 문제로 이동하기

1. 생산성 100배 엔지니어의 패턴

   1. 스킬, MCP(Model Context Protocol), 플러그인으로 확장 가능한 훌륭한 시스템을 만든 엔지니어가 코드를 매우 빠르게 쏟아낼 수 있다.
   2. 팀원들이 같은 패턴을 채택하면 더 많은 코드가 더 빠르게 생성된다.

2. 코드 리뷰가 새 병목이 되기

   1. 코드가 빨리 나오면 자주 망가지지 않는 고품질 코드를 어떻게 배포할지 고민해야 한다.
   2. VS Code는 사용자 기기에 실행 파일(binary)을 배포하므로 문제가 생겼을 때 복구 비용이 웹 서비스보다 크다.

3. 제품 판단이 가장 어려운 질문이 되기

   1. 고품질 코드를 자신 있게 빠르게 릴리스한 뒤에는 그것이 정말 올바른 기능인지, 애초에 내보내야 하는 기능인지 판단해야 한다.
   2. AI의 최종 역할은 코드를 더 많이 쓰는 것이 아니라 더 빨리 학습하고 더 나은 제품을 만드는 데 있다.
   3. 코드 양을 늘리는 동안 제품 감각(product taste)과 학습한 내용을 제품에 적용하는 능력을 놓치기 쉽다.

2.2. 속도·품질·학습의 세 단계

1. 더 빠르게 개발하기

   1. 에이전트가 병렬로 코드를 만들고 팀이 같은 패턴을 채택하면서 개발 산출량이 커진다.
   2. 이 단계만으로는 리뷰와 배포 위험이 뒤따르므로 충분하지 않다.

2. 더 빠르게 릴리스하기

   1. 코드베이스 준비, 빌드 속도, UI 검증, 자동 코드 리뷰, Issue·에러 처리, 단계적 배포가 필요하다.
   2. 인간은 자동화 결과를 감독하고 잘못된 결과를 교정하는 신호를 시스템에 되돌려야 한다.

3. 더 빠르게 학습하기

   1. 실제 사용자 시나리오를 평가에 넣고 오프라인에서 개선한 뒤 온라인 실험으로 넘어가야 한다.
   2. 프로토타입과 일일 피드백을 사용하면 제품 경험에 대한 판단을 코드 병합보다 빠르게 반복할 수 있다.

3. 에이전트가 일할 수 있는 코드베이스 만들기

좋은 코드베이스 문서와 개발자 경험(developer experience)은 사람뿐 아니라 에이전트가 저장소의 지도를 읽고 올바른 위치에서 작업하게 한다.

3.1. AGENTS.md를 살아 있는 지도와 계약으로 사용하기

1. 가벼운 저장소 지도 만들기

   1. AGENTS.md에 코드베이스의 구조와 각 영역을 살펴볼 위치를 간결하게 적는다.
   2. 문서가 모든 내용을 복사한 무거운 매뉴얼이 아니라 에이전트가 방향을 잡는 지도(map)가 되어야 한다.

2. 초안에서 살아 있는 문서로 발전시키기

   1. 현재 사용하는 에이전트의 slash command로 좋은 초안을 만들 수 있다.
   2. 에이전트가 실수하거나 작업을 수행할 때마다 문서를 보완한다.
   3. 코드베이스가 바뀌면 문서도 함께 바뀌어야 하므로 한 번 만들고 끝내는 정적 파일이 아니다.

3. 개발자 경험 투자의 복리 효과

   1. 문서화와 신규 개발자 온보딩에 투자한 팀은 에이전트도 그 자료를 읽고 사람처럼 활용하게 만들 수 있다.
   2. 에이전트 친화성은 별도 AI 기능보다 기존 개발자 경험의 품질에 크게 의존한다.

3.2. 전문 지식을 재사용 가능한 스킬로 만들기

1. 접근성(accessibility) 스킬의 사례

   1. VS Code는 이전부터 접근성에 크게 투자했고, 접근성 모범 사례와 팀의 접근성 철학을 하나의 스킬에 담았다.
   2. 모든 팀원이 같은 스킬을 사용하므로 각 기능을 만들 때 접근성 기준을 반복해서 적용할 수 있다.

2. 전문가 한 명에게 몰리던 피드백 분산하기

   1. 예전에는 특정 전문가를 불러 접근성 피드백을 받아야 했다.
   2. 지금은 해당 분야 담당자가 스킬을 검토하고 유지하면서, 어디서나 적용되어야 할 지식을 팀 전체에 배포한다.
   3. 늘 질문을 받는 소수 전문가의 시간을 보호하려면 그들의 판단을 스킬로 코드화해야 한다.

3. PM이 저장소에서 직접 작업하는 기준

   1. PM인 Harald가 VS Code 저장소에서 효과적으로 바이브 코딩(vibe coding)을 할 수 있는지가 이 체계가 제대로 작동하는지 보여주는 실용적 테스트다.
   2. 결과물이 얼마나 많은 추가 작업을 만들고, 즉시 실행되는지, 로컬에서는 작동하지만 출시 후 깨지지 않는지를 엔지니어링 팀이 검증한다.
   3. 이런 품질 개선이 누적되면 직무와 관계없이 모든 사람이 저장소에서 더 효율적으로 작업할 수 있다.

4. 빠른 CI/CD와 제품 작업 환경

에이전트가 여러 개 동시에 움직이면 사람이 기다리는 시간보다 빌드·린트·CI/CD 병목이 훨씬 크게 증폭되므로 기반 도구 자체를 빠르게 해야 한다.

4.1. TypeScript Go로 빌드 병목 줄이기

1. 사람과 에이전트가 느린 파이프라인을 다르게 겪기

   1. 사람은 빌드나 린트, CI/CD가 실행되는 동안 PR을 리뷰하거나 다른 작업으로 전환할 수 있다.
   2. 에이전트 10개나 20개가 같은 느린 단계에서 동시에 막히면 한 번의 병목이 모든 작업에 반복된다.

2. 10배 빌드 개선

   1. VS Code는 TypeScript Go로 전환해 빌드 프로세스를 10배 빠르게 만들었다.
   2. 에이전트가 대량의 PR을 만들고 코드를 고치며 CI/CD 루프에서 피드백을 받아야 하는 환경에서 이 변화는 매우 크다.

3. 질문 도구 PR의 사례

   1. Harald는 연초에 꼭 필요하다고 생각한 질문 도구를 도입하는 큰 PR을 제출하고 팀이 제품에서 시험하도록 했다.
   2. 첫 PR은 거칠었지만, 명확한 아이디어와 경험의 토대가 있었기 때문에 몇 주 만에 세련되고 잘 설계된 경험으로 발전했다.
   3. 초기 구현이 대화를 시작할 수 있을 정도로 구체적이었고, 그 토대 위에서 팀원 모두가 논의와 개선에 참여할 수 있었다.

5. UI를 직접 보고 고치는 피드백 루프

에이전트가 UI를 만들었다고 주장하는 것만으로는 충분하지 않으며, 실제 애플리케이션을 조작하고 화면 변화를 확인하는 검증이 필요하다.

5.1. 시각적 회귀를 Component Browser로 잡기

1. 자동화된 UI 검증이 필요한 이유

   1. 에이전트는 UI가 완벽하다고 말하지만 실제로 열어 보면 요소 배치가 모두 어긋나는 일이 있다.
   2. SVG를 사용하거나 최신 모델을 사용해도 이런 문제가 여전히 발생한다.

2. Component Browser의 동작

   1. VS Code가 바뀔 때마다 자동 빌드가 실행되고 모든 컴포넌트의 스크린샷을 백그라운드에서 생성한다.
   2. 이전 화면과 현재 화면의 차이를 보여주어 변경하지 않은 컴포넌트까지 움직였는지 확인한다.

3. 커스터마이즈 화면의 Back 버튼 사례

   1. 커스터마이즈 화면에 Back 버튼을 추가하자 광범위한 변경의 영향을 전체 컴포넌트에 걸쳐 확인했다.
   2. 한 컴포넌트 변경의 연쇄 효과로 다른 요소가 이동하거나 아이콘이 사라지는 예기치 않은 회귀(regression)를 잡을 수 있었다.
   3. PR을 처음부터 실행하지 않아도 실제 시각적 결과를 보고 빠르게 리뷰할 수 있다.

4. 동영상·스크린샷 첨부에서 자동화로

   1. 이전에는 모든 개발자에게 구현한 내용을 보여주는 동영상이나 스크린샷을 최소 하나 첨부해 달라고 요청했다.
   2. 모든 것을 처음부터 실행하지 않고도 빠르게 평가하고 피드백하기 위해서였다.
   3. 이제 Component Explorer가 이 증거 수집과 비교를 자동화한다.

5.2. Playwright와 /launch로 실행 경로 검증하기

1. VS Code의 구조가 주는 장점

   1. VS Code는 Electron 위에서 실행되는 웹 애플리케이션이며 내부적으로 HTML 기반이므로 브라우저 조작을 자동화하기 쉽다.
   2. Playwright로 브라우저 안의 클릭과 여러 사용자 동작을 자동화할 수 있다.

2. /launch 스킬

   1. /launch는 VS Code를 실행하고 특정 시나리오에 따라 VS Code 안을 클릭해 진행한다.
   2. 진행 중 로그를 수집해 문제를 진단하고, 수정 전후의 동작을 비교한다.
   3. 사람이 직접 클릭하며 기다리지 않고 실행을 시작한 뒤 다음 작업으로 이동했다가 에이전트의 검증이 끝난 후 돌아올 수 있다.

3. 다른 플랫폼으로 확장하기

   1. Xcode MCP는 Xcode를 직접 열지 않고도 VS Code 안에서 iOS 앱을 만들고 실행하며 화면을 탐색하고 스크린샷을 찍는다.
   2. Harald는 이 흐름이 마법처럼 느껴질 정도로 조밀한 피드백 루프를 만든다고 평가했다.
   3. Android에도 같은 목적의 도구가 있어 플랫폼별 UI 검증 루프를 만들 수 있다.

6. 코드 리뷰와 Issue 흐름을 품질 게이트로 바꾸기

자동화가 만든 산출량을 사람이 감당하려면 리뷰와 Issue 처리를 대기열이 아니라 품질을 높이는 자동화된 게이트로 설계해야 한다.

6.1. 자동 코드 리뷰를 필수 단계로 만들기

1. Copilot 리뷰의 개선

   1. GitHub Copilot 자동 코드 리뷰를 처음 켰을 때는 충분히 믿을 만하다고 느끼지 못했다.
   2. 몇 주와 몇 달 동안 크게 개선되었고, 이제는 누군가 PR을 열 때마다 필수 리뷰로 실행한다.

2. 위험도에 따른 리뷰 비용 조정

   1. 앞으로 저장소의 위험 크기에 맞춰 코드 리뷰 노력을 낮음·중간·높음으로 선택할 수 있게 된다.
   2. 위험이 다른 변경에 같은 비용을 쓰지 않고 비용 대비 효과(cost-benefit)를 조정하는 방식이다.

3. 인간 리뷰의 시작 조건

   1. VS Code의 운영에서는 자동 리뷰가 끝난 뒤 모든 댓글에 대응하고 해결할 때까지 사람이 PR을 검토하지 않는다.
   2. 자동 리뷰의 지적을 먼저 소화해 인간의 판단이 반복적인 댓글 처리에 묶이지 않게 한다.

6.2. Issue를 다국어 신호로 정제하기

1. Issue가 중요한 이유

   1. GitHub 기반 프로젝트에서 Issue는 사용자 문제가 무엇인지 알려주는 강력하고 유용한 신호다.
   2. AI 덕분에 다양한 언어적 배경을 가진 사람이 좋은 Issue를 작성할 수 있어 품질이 좋아진 경우도 있다.
   3. 청중에게 GitHub에 문제를 올려본 적이 있는지, VS Code에서 문제를 겪은 적이 있는지 물었고 손을 든 사람이 많았다.
   4. 앞선 장소에서는 손을 든 사람이 더 적었다는 말로 현장 반응을 가볍게 웃음으로 연결했다.

2. AI 트리아지(triage) 파이프라인

   1. 과거에는 엔지니어가 Issue를 수작업으로 분류했다.
   2. 현재는 AI가 스팸을 걸러내고, 정보를 보강하고, 번역하고, 각 영역 담당자에게 할당한다.
   3. 이 과정은 전체 양을 단순히 줄이는 것이 아니라 노이즈 대비 유용한 신호의 비율을 높인다.

3. 인간의 교정 루프

   1. 에이전트가 잘못 분류할 수 있으므로 Issue 처리 단계에는 인간 확인을 남긴다.
   2. 중복 Issue를 고칠 수 있는 Chrome 확장 기능을 만들고 있다.
   3. 에이전트가 일하는 동안 사람이 수정한 내용을 다시 초기 작업에 반영해 다음 처리의 품질을 높인다.

7. 에러 텔레메트리에서 자동 수정 PR까지

VS Code는 자체 데이터와 자체 도구를 사용해 대규모 에러 신호를 분류하고, 담당자 할당과 수정 PR 생성을 자동으로 연결한다.

7.1. 510억 건의 원시 텔레메트리 압축하기

1. 자체 데이터 파이프라인

   1. 예외가 발생할 때마다 대부분의 애플리케이션처럼 에러 스택 보고가 쌓인다.
   2. 외부 도구에 의존하지 않고 자체 데이터와 자체 구축 도구로 처리한다.
   3. 머신러닝 분류 시스템은 이전부터 있었고, 현재는 여러 기준을 결합해 더 정교하게 분류한다.

2. 필터·그룹·분류 순서

   1. 하루 약 510억 건의 원시 텔레메트리(raw telemetry)를 수집한다.
   2. 완전한 스택이 들어 있는 유효한 에러 보고만 남기도록 필터링한다.
   3. 비슷한 특징을 추출해 같은 문제를 식별하고 그룹화한 뒤 분류한다.
   4. 모든 처리가 끝나면 최종적으로 10개의 Issue를 만들고 각 도메인 담당자에게 할당한다.
   5. 각 문제를 고치려는 PR도 자동으로 생성한다.

7.2. 실제 오류를 조사해 병합하기

1. 오류 페이지의 운영 정보

   1. 오류 페이지에서 전체 스택과 발생 횟수, 영향을 받은 사용자 수를 함께 볼 수 있다.
   2. 새 문제가 얼마나 자주 발생하고 누구에게 영향을 주는지 알 수 있어 빠르게 대응할 수 있다.

2. 검색 심볼 오류 사례

   1. 자동 파이프라인이 초기 진단이 담긴 Issue와 PR을 만든다.
   2. 에이전트가 원인을 조사하고 어떤 변경이 문제를 유발했는지 추적한다.
   3. 사례에서는 심볼 검색과 관련된 변경이 추가되어 있었고, 취소 요청이 RPC 프로토콜에 포함되지 않았다는 사실을 찾아냈다.
   4. 에이전트가 이미 수정 PR을 열었으므로 팀은 내용을 확인하고 병합하면 됐다.

3. 다중 에이전트와 인간 승인

   1. 초기 트리아지는 에이전트와 결정론적 시스템(deterministic system)의 조합으로 진행한다.
   2. 만들어진 Issue는 다중 에이전트 PR 시스템으로 전달된다.
   3. 수정 반영은 대부분 자동으로 진행하지만 PR 승인 같은 핵심 단계에는 인간의 감독을 둔다.
   4. 목적은 에러 자체에 사람이 매몰되는 것이 아니라 코드베이스의 안정성을 지속적으로 높이는 것이다.

8. 단계적 릴리스로 설치형 제품의 위험 줄이기

에이전트가 만든 변경을 100% 한 번에 배포하는 방식은 설치형 애플리케이션의 복구 비용을 키우므로 점진적 배포와 운영 관측이 필요하다.

8.1. YOLO 배포에서 점진적 롤아웃으로

1. 기존의 일괄 배포

   1. 과거에는 릴리스 당일 모든 것이 안정적인지 테스트한 뒤 모든 사용자에게 100% 배포했다.
   2. 문을 한꺼번에 활짝 여는 “YOLO” 릴리스 방식이었다.

2. 단계적 배포와 모니터링

   1. 현재는 작은 범위에서 시작해 단계적으로 배포를 넓힌다.
   2. 배포가 진행되는 동안 에러 로그, Issue, 그 밖의 운영 정보를 계속 감시한다.
   3. 웹 애플리케이션의 좋은 운영 관행을 설치형 앱에도 적용한 셈이다.

3. 롤백 비용의 현실

   1. 설치형 애플리케이션은 문제가 생긴 뒤 롤백하는 비용이 매우 크다.
   2. 에이전트 활용으로 변경량과 속도가 커진 만큼 더 일찍 이런 위험 관리에 투자했어야 한다는 반성이 남는다.

9. 평가로 더 빠르게 학습하기

품질을 유지한 채 빨리 배포하는 것보다 더 어려운 과제는, 어떤 제품을 만들어야 하는지 더 빨리 배우는 일이다.

9.1. VSCBench를 개발 라이프사이클에 연결하기

1. 에이전트 제품에는 상시 평가가 필요하다

   1. VS Code는 에이전트에 의존하는 제품이므로 자체 제품을 평가하는 시스템을 항상 준비해야 한다.
   2. 평가 시스템은 새로운 시나리오를 쉽게 추가하고 규모를 키울 수 있어야 한다.

2. GitHub Issue에서 평가 시나리오 만들기

   1. VSCBench의 모든 작업은 GitHub Issue로 관리한다.
   2. 새 시나리오 추가 Issue를 만들면 에이전트가 템플릿을 사용해 시나리오 뼈대를 작성한다.
   3. Issue, 고객 대화 등 여러 경로에서 발견한 개발자 사용 시나리오를 평가에 쉽게 넣는다.

3. 오프라인 검증 후 온라인 실험

   1. 새 변경이 기존 시나리오를 개선하는지 먼저 오프라인에서 확인한다.
   2. 오프라인 지표가 좋아진 뒤 실제 사용자 환경에서 온라인 실험을 진행한다.
   3. 이 흐름은 기존 제품 개발 라이프사이클을 에이전트 제품에 맞게 확장한 것이다.

9.2. “hello world” 평가가 보여준 모델 비용 차이

1. 가장 단순한 하네스 테스트

   1. 평가 하네스가 처음부터 끝까지 작동하는지 확인하기 위해 파일 하나에 “hello world”를 쓰는 단순한 시나리오를 만들었다.
   2. 각 모델이 동일한 작업과 평가 하네스에 어떻게 반응하는지 비교하는 실험이었다.

2. 같은 결과, 70배의 토큰 차이

   1. 같은 파일을 만드는 작업인데 가장 비싼 모델은 다른 모델보다 70배 많은 토큰을 사용했다.
   2. 그 모델은 특별히 강한 추론 모델도 아니었다.
   3. 구체적인 모델명은 공개하지 않았지만, 모델이 자체 작업 방식과 하네스에 어떻게 반응하는지 아는 것만으로도 중요한 운영 지식이 된다.

10. 프로토타입과 일일 피드백으로 제품 판단 가속하기

PR은 대화를 시작하기 좋은 형식이지만, 모든 아이디어를 실제 제품 PR로 만들 필요는 없으며 빠른 프로토타입이 더 적합한 경우가 많다.

10.1. PR보다 짧은 대화 루프

1. PR로 만들 필요가 없는 작업 구분하기

   1. Harald는 자신이 하는 작업 대부분을 VS Code PR로 병합하고 싶은 것이 아니라는 사실을 깨달았다.
   2. PR은 토론을 시작하는 데 좋지만 많은 경우 원하는 것은 짧은 대화와 방향 확인이다.

2. 매일 갱신하는 프로토타입

   1. 팀은 매일 모여 “이것이 아이디어이고, 이렇게 보일 수 있으며, 이렇게 하면 어떨까”를 빠르게 논의한다.
   2. 다음 날 업데이트된 프로토타입을 가져와 같은 대화를 이어간다.
   3. 실제 화면이 있으면 추상적인 설명보다 제품 경험이 어떻게 되어야 하는지 더 깊이 토론할 수 있다.

3. 월간에서 주간, 일간으로 짧아진 주기

   1. 월간 릴리스 사이클은 주간 사이클로, 다시 일일 스프린트와 일일 작업으로 세분화됐다.
   2. 작은 팀과 작은 작업 단위가 명확한 담당 영역을 맡아 우선순위를 정하고 밀어붙인다.
   3. 지속적으로 책임지는 담당 체계가 있어야 짧은 루프가 실제 진전으로 이어진다.

10.2. 병목을 계속 찾아 피드백 루프를 재설계하기

1. 다음 병목이 계속 나타나는 구조

   1. 더 높은 품질로 더 빠르게 배포하고 더 빨리 배우려면 현재 가장 느린 단계를 먼저 찾아야 한다.
   2. 한 병목을 해결하면 시스템의 다음 병목이 드러난다.

2. 에이전트와 피드백 경로를 함께 조정하기

   1. 에이전트와 일하는 방법만 조정해서는 충분하지 않다.
   2. 에이전트가 어디에서 어떤 피드백을 받고, 사람이 어떻게 교정하며, 그 신호가 다음 작업에 어떻게 반영되는지도 설계해야 한다.
   3. 자동화할수록 자동화 결과를 모니터링하고 수정하는 루프가 더 중요해진다.

3. 끝없는 반복

   1. 한 번의 성공으로 프로세스를 고정하지 말고 더 빠르게 진행하지 못하게 하는 다음 문제를 찾아야 한다.
   2. 개발·릴리스·학습의 모든 사이클에서 피드백 루프를 계속 개선하는 것이 주간 릴리스를 지속시키는 방법이다.
   3. 마지막에는 VS Code 부스에 들러 더 이야기해 달라는 초대와 “즐거운 코딩을”이라는 인사, 박수와 음악으로 마무리했다.

주요 발언 모음

“AI의 사용량이나 토큰 사용량을 늘리는 것이 목표가 아니다. 전체 시스템을 발전시켜 프로세스 전반에서 AI를 더 잘 활용하는 것이 목표다.”

“더 빠르게 고품질 코드를 내보낼 수 있게 된 다음에는, 우리가 올바른 것을 내보내고 있는지, 애초에 내보내야 하는지 알아야 한다.”

“AGENTS.md는 에이전트에게 코드베이스의 지도를 보여주는 가벼운 문서이며, 에이전트가 실수하고 작업하는 과정에서 계속 진화하는 살아 있는 문서다.”

“에이전트가 애플리케이션이나 제품을 직접 사용해 모든 것이 작동하는지 확인하는 피드백 루프를 만들 수 없다면, UI를 다룰 때마다 효과를 내는 큰 투자가 필요하다.”

“에이전트가 일하는 동안에도 인간의 피드백을 받아야 한다.”

“설치형 애플리케이션은 롤백 비용이 매우 크기 때문에 웹 애플리케이션처럼 단계적으로 배포하고 관측해야 한다.”

“다음 병목을 찾아 해결하라. 에이전트와 일하는 방식뿐 아니라 에이전트가 피드백을 얻는 방식과 반복 루프를 만드는 방식도 조정하라.”

핵심 데이터 & 수치

• 사용자 규모: 아주 작은 VS Code 팀이 5,000만 명이 넘는 사용자에게 제품을 제공한다.
• 코드 생존율: GPT-4.1 초기 55%에서 하네스 개선과 새 모델 도입 후 Claude Opus 4.6 기준 86%로 상승했다.
• 릴리스 역사: VS Code 1.0 이후 10년 넘게 월간 릴리스를 유지하다 주간 릴리스로 전환했다.
• 동시 에이전트 병목: 에이전트 10~20개가 동일한 느린 CI/CD 단계에 걸리면 사람 한 명이 겪는 병목이 여러 작업에 반복된다.
• 빌드 속도: TypeScript Go 전환으로 빌드 프로세스가 10배 빨라졌다.
• 원시 텔레메트리: 하루 약 510억 건을 수집한 뒤 완전한 스택만 필터링하고 그룹화·분류한다.
• Issue 자동 생성: 분류가 끝나면 최종적으로 10개의 Issue를 만들고 도메인 담당자에게 할당하며 수정 PR도 자동 생성한다.
• 평가 비용: 단순한 “hello world” 파일 작성에서 가장 비싼 모델이 같은 결과에 다른 모델보다 70배 많은 토큰을 사용했다.
• 배포 방식: 과거에는 100% 일괄 배포했지만 현재는 에러 로그와 Issue를 관찰하는 단계적 롤아웃을 사용한다.

결론 및 시사점

1. AI 도입의 성공 기준을 프롬프트 수나 토큰 수가 아니라 제품 개선 속도와 학습 속도로 설정해야 한다.
2. 먼저 AGENTS.md와 좋은 개발자 문서로 코드베이스의 지도를 제공하고, 접근성처럼 반복되는 전문 지식을 스킬로 코드화해야 한다.
3. 에이전트 수가 늘어날수록 빌드·린트·CI/CD 병목이 증폭되므로 개발자 도구의 지연을 먼저 줄여야 한다.
4. UI는 코드 diff만으로 품질을 보장할 수 없으므로 컴포넌트 스크린샷 비교와 실제 앱 조작을 포함한 시각·행동 검증을 구축해야 한다.
5. 자동 코드 리뷰를 필수 게이트로 두되 저장소 위험도에 따라 리뷰 비용을 조정하고, 인간은 해결된 결과의 의미와 제품 적합성을 판단해야 한다.
6. Issue 트리아지와 에러 처리를 AI·결정론적 시스템·다중 에이전트로 자동화하되 인간의 교정과 승인을 피드백으로 남겨야 한다.
7. 설치형 제품에서는 YOLO식 100% 배포보다 단계적 롤아웃과 운영 모니터링이 복구 비용을 줄인다.
8. VSCBench처럼 실제 Issue와 고객 대화에서 나온 시나리오를 평가에 넣고 오프라인 검증 후 온라인 실험으로 이어가야 한다.
9. 모든 아이디어를 PR로 만들기보다 매일 갱신하는 프로토타입으로 제품 경험을 빠르게 논의하는 편이 판단 속도를 높일 수 있다.
10. 한 병목을 해결하면 즉시 다음 병목을 찾고, 자동화·모니터링·조정의 사이클을 멈추지 않는 것이 월간에서 주간, 일간으로 나아가는 운영 원리다.

핵심 요약 (20줄)

1. VS Code는 10년 넘게 유지한 월간 릴리스를 AI 기반 개발·검증·운영 체계와 함께 주간 릴리스로 전환했다.
2. 작은 팀이 5,000만 명이 넘는 사용자에게 제품을 제공하므로 릴리스 속도와 품질을 동시에 높이는 시스템이 필요했다.
3. 에이전트가 작성해 실제 커밋된 코드의 비율인 코드 생존율은 GPT-4.1의 55%에서 Claude Opus 4.6의 86%로 올랐다.
4. AI 활용이 늘면서 고품질 Issue와 저품질 자동 Issue, 팀 PR과 커뮤니티 PR이 모두 증가했다.
5. AI 도입의 목표는 토큰 사용량이나 코드 양이 아니라 더 좋은 제품을 더 빠르게 학습하고 출시하는 것이다.
6. AGENTS.md는 에이전트에게 코드베이스의 구조와 탐색 위치를 알려주는 가벼운 살아 있는 지도다.
7. 접근성 모범 사례 같은 전문 지식은 스킬로 코드화하면 소수 전문가의 반복 피드백을 팀 전체에 확장할 수 있다.
8. TypeScript Go 전환으로 빌드가 10배 빨라져 여러 에이전트의 CI/CD 피드백 대기 병목이 크게 줄었다.
9. 컴포넌트 스크린샷 비교는 한 UI 변경이 다른 요소를 움직이거나 아이콘을 사라지게 하는 시각적 회귀를 찾아낸다.
10. Playwright와 /launch 스킬은 에이전트가 VS Code를 직접 실행하고 클릭하며 로그와 수정 전후 결과를 검증하게 한다.
11. Xcode MCP와 Android용 도구도 앱을 만들고 실행하고 화면을 조작하는 조밀한 피드백 루프를 제공한다.
12. GitHub Copilot 자동 리뷰는 개선을 거쳐 모든 PR의 필수 단계가 되었고 저장소 위험도에 따른 리뷰 강도 조절도 추진된다.
13. AI 트리아지는 Issue의 스팸 제거, 정보 보강, 번역, 담당자 할당으로 유용한 신호의 비율을 높인다.
14. 하루 약 510억 건의 텔레메트리는 완전한 에러 스택만 남긴 뒤 그룹화·분류되어 10개의 담당 Issue와 자동 수정 PR로 압축된다.
15. 검색 심볼 변경에서 취소 요청이 RPC 프로토콜에 빠진 오류를 에이전트가 찾아 PR을 열면서 사람이 병합만 할 수 있었다.
16. VS Code는 100% 일괄 배포인 YOLO 릴리스에서 에러 로그와 Issue를 관찰하는 단계적 롤아웃으로 바뀌었다.
17. VSCBench는 GitHub Issue와 고객 대화에서 나온 개발자 시나리오를 평가에 넣고 오프라인 개선 뒤 온라인 실험을 진행한다.
18. 단순한 “hello world” 파일 평가에서도 가장 비싼 모델이 같은 결과에 70배 많은 토큰을 사용해 하네스 이해의 중요성을 보여줬다.
19. 매일 갱신하는 프로토타입은 PR을 기다리지 않고 제품 경험에 대한 짧고 깊은 대화를 가능하게 한다.
20. 자동화의 다음 단계는 항상 새로운 병목이므로 에이전트 작업과 피드백 루프를 함께 조정하며 계속 반복해야 한다.