코딩은 해결됐지만 버그는 아직이다

메타데이터

• 채널: t3dotgg
• 원문 제목: He's right.
• URL: https://www.youtube.com/watch?v=0wemf5SZkW4
• 영상 ID: 0wemf5SZkW4
• 발행일: 2026-08-24
• 주제: AI 코딩 에이전트, 버그 검증, 소프트웨어 엔지니어링
• 핵심 인물: Boris, Matt Pocock, Peter, John Ousterhout, Neal Agarwal, Ryan Carniato

---

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

==AI 에이전트는 명세에 맞는 코드를 빠르게 작성하는 단계에서는 코딩을 사실상 해결했지만, 결과를 실제로 검증하고 버그를 선제적으로 찾아내며 장기적인 구조를 설계하는 소프트웨어 엔지니어링까지 해결하지는 못했다.==

• 코딩(coding)은 키보드로 코드를 입력하는 좁은 행위일 수도 있고, 아이디어를 작동하는 소프트웨어로 만드는 전체 과정일 수도 있다.
• 좋은 계획과 유능한 구현자만으로는 충분하지 않으며, QA·스테이징·프리뷰·점진적 출시처럼 결과를 직접 확인하는 검증 계층(verification layer)이 필요하다.
• 에이전트의 한계는 모델 지능뿐 아니라 로컬 실행, 브라우저·데스크톱 제어, 데이터 재현, 증거 업로드가 어려운 코드베이스와 도구에도 있다.

Boris의 도발적인 표현과 Matt Pocock의 비판은 서로 다른 정의의 코딩을 두고 벌어진 논쟁이다. Boris는 자신이 하는 좁은 의미의 코딩을 Claude가 이미 넘어섰다는 뜻으로 말했고, Matt는 전술적 구현과 전략적 설계를 구분해 장기적인 엔지니어링 판단은 아직 자동화되지 않았다고 지적했다. 두 주장을 함께 놓으면 에이전트가 작성한 코드의 품질보다 그 코드가 실제 사용자 경험을 만족하는지 확인할 수 있는 시스템을 만드는 일이 더 중요한 과제로 남는다.

1. Boris의 선언과 Matt Pocock의 반발

1.1. “코딩은 해결됐다”라는 도발

1. Boris의 과거 발언이 현실에 가까워진 이유

   1. Boris는 과거 Claude Code가 엔지니어를 모두 대체했다거나 Cloud Code가 엔지니어를 대체했다는 식의 글을 무작위로 올려 사람들을 화나게 했다.
   2. 당시 주장은 시점(timeline)이 특히 터무니없이 앞서 있었고 어조도 거슬렸지만, 시간이 흐르면서 “사람이 여전히 손으로 코드를 작성하면 크게 뒤처진다”는 핵심 방향은 점점 현실에 가까워졌다.
   3. t3dotgg는 Boris의 말을 변호하고 싶지 않았지만, 사람들이 그 글을 부당한 방식으로 반박하고 있다고 판단해 직접 변호하겠다고 했다.

2. Matt의 반박과 뜻밖의 양쪽 옳음

   1. Matt Pocock의 반발은 특정 표현을 정면으로 찌르는 아름다운 반박이었다.
   2. 그 글은 “VC 자금의 바닐라 아이스크림에 작은 똥 한 꼬집을 섞은 라즈베리 리플(raspberry ripple)”처럼 느껴진다는 비유를 낳았다.
   3. 도발적인 문구를 문제 삼은 Matt도 옳고, 좁은 의미의 코딩을 두고 Boris가 말한 핵심도 옳다.
   4. 같은 단어를 사용하면서 서로 완전히 다른 대상을 말했기 때문에 논쟁이 커졌다. 단어의 배경과 실제 의도를 분리하면 소프트웨어가 어디로 가는지, 사람들이 현업에서 AI를 어떻게 적용하는지 더 정확히 볼 수 있다.

1.2. 빠른 광고 구간: CI Blacksmith

1. PR 처리량과 GitHub Actions의 병목

   1. 촬영 전날 t3dotgg는 회의가 많은 날에도 PR을 최소 8개, 정정하면 그보다 더 많이 머지했다.
   2. GitHub Actions는 느리고 불안정하다는 인식 때문에 꼭 필요한 작업만 올렸지만, CI Blacksmith를 사용한 뒤 GitHub Actions에 맡길 수 있는 범위가 크게 넓어졌다.

2. 속도 개선의 구체적 수치

   1. Blacksmith의 하드웨어는 기존 환경보다 2배 빠르다.
   2. 캐시 다운로드는 4배 빠르다.
   3. Docker 빌드는 무려 40배 빠르다.
   4. 일부 CI는 실제 실행보다 GitHub Actions 캐시 다운로드에 더 오래 걸렸고, 1분을 훌쩍 넘기는 다운로드도 있었다.

3. 에이전트와 Sticky Disks

   1. Blacksmith의 문서가 에이전트가 읽고 파싱하기 좋게 작성돼 있어, CI를 더 빠르게 만드는 방법을 에이전트에게 물으면 병렬 작업을 늘리는 방법을 찾아낸다.
   2. 에이전트는 Sticky Disks도 발견했다. 실행 사이에 디스크 일부를 유지해 Node 모듈 대량 다운로드, 큰 파일 변환, 오래된 거대한 Git 히스토리 처리 같은 작업을 다시 다운로드하지 않게 한다.
   3. 이미 디스크에 있는 데이터를 재사용하므로 캐시 다운로드가 1분 이상에서 3초로 줄어든다.
   4. 안내 주소는 sidv.link/blacksmith다.

2. Claude Code Desktop의 잘린 텍스트가 드러낸 문제

2.1. Peter의 버그 제보와 Boris의 반응

1. 업데이트 문구가 화면 밖으로 잘린 사례

   1. Peter는 Claude Code Desktop 앱에서 업데이트 텍스트가 합리적인 화면 크기에서도 잘리는 버그를 보여줬다.
   2. Claude Code Desktop은 당시 AI 모델이 할 수 있는 일을 보여주는 사례로는 매우 좋지 않을 만큼 거친 상태였지만, 팀은 피드백을 받아들이고 실제 개선을 빠르게 배포하고 있었다.
   3. 모델이 업데이트 문구 필드를 작성하면서 소스 코드만 읽고, 작은 호출 상자(callout)의 실제 가로·세로 공간이 렌더링되는 텍스트를 수용할 만큼 크지 않다는 사실을 확인하지 못했다.

2. 인간 개발자라면 거쳤을 확인

   1. 사람은 해당 기능을 만드는 동안 브라우저에서 렌더링해 보거나 적어도 변경된 화면을 직접 열어 볼 가능성이 높다.
   2. 화면을 한 번만 확인해도 텍스트가 잘리는 엣지 케이스를 발견하고 동료에게 PR을 보내기 전에 수정할 수 있다.
   3. 사람이 작성하던 시절에는 결과를 한 번도 보지 않은 코드를 PR로 올려 동료의 시간을 낭비하는 일이 일반적이지 않았다.

3. PR 리뷰의 전제가 깨진 상황

   1. 에이전트가 대체로 좋은 코드를 쓰고 안전하게 머지된다는 경험이 쌓이면, 사람은 코드를 빠르게 훑은 뒤 머지 버튼을 누르게 된다.
   2. 과거에는 PR이 올라왔다는 사실 자체가 원래 개발자가 실제 변경을 실행해 버그를 확인했다는 암묵적 신호였다.
   3. 에이전트가 올린 PR에서는 그 전제가 더 이상 성립하지 않는다. 코드 리뷰가 시작됐어도 앱을 실행하거나 출력 결과를 확인했다는 뜻이 아니다.
   4. 에이전트가 코드는 작성했지만 현대 소프트웨어가 가져야 할 동작과 인간 개발자가 확인해야 할 사용자 경험을 놓친 결과가 잘린 문구다.

2.2. 핫 리로드 논점과 “버그가 아니라 UX 문제”라는 주장

1. 24시간 실행 에이전트의 운영 문제

   1. 24시간 실행하도록 설계된 에이전트를 핫 리로드(hot reload)하기 어려운 것도 absurd한 상황이다.
   2. 기술적으로 왜 어려운지는 이해할 수 있으며, T3 Code에서도 비슷한 문제를 조금씩 다루고 있다.
   3. 다만 더 큰 문제는 핫 리로드보다 사용자가 업데이트 텍스트 자체를 읽을 수 없다는 명백한 화면 오류다.

2. 버그의 정의

   1. Boris는 잘린 텍스트가 “버그가 아니라 수정 사항이 있는 UX 문제”라고 답했다.
   2. 모든 합리적인 디스플레이 크기에서 텍스트가 잘리는 것이 의도된 경험일 리 없으므로, 이는 버그다.
   3. 버그와 UX 문제를 나누려면 먼저 coding과 solved의 정의부터 합의해야 한다. 논쟁의 상당 부분은 바로 이 정의의 차이에서 생긴다.

3. 코딩의 범위를 어디까지로 볼 것인가

3.1. 좁은 정의와 넓은 정의

1. 코딩이라는 말의 여러 범위

   1. 아이디어를 설명하고 누군가가 전체 경험을 구현하는 아이디어-경험 변환 전부를 코딩이라고 부를 수 있다.
   2. 텍스트 에디터를 열고 키보드로 코드를 입력하는 행위만 코딩이라고 부를 수도 있다.
   3. Jira 티켓을 pull request로 바꾸는 과정, 코드를 리뷰하는 과정, 다른 사람의 변경을 내려받아 확인하는 과정까지 코딩에 포함할 수도 있다.
   4. 따라서 엔지니어가 사무실에 출근해 퇴근할 때까지 하는 일을 모두 코딩이라고 정의하면 AI는 코딩을 해결하지 못했다.

2. 키보드 입력이라는 좁은 정의

   1. 코딩을 에디터 안에서 키보드로 소스 코드를 타이핑하는 행위로 좁히면 AI가 코딩을 해결했다는 말은 성립한다.
   2. Jira 티켓을 찾고, 사용자의 행동 데이터를 확인하고, 그 경험을 코드로 바꾸는 과정까지 조금 넓혀도 AI는 아이디어에서 작동하는 코드까지 만드는 일을 수행할 수 있다.
   3. 실제로 실행되는 코드를 생성하는 능력만 놓고 보면 AI는 이미 해결 단계에 도달했다.

3.2. Neal Agarwal의 The Password Game 사례

1. 의도적으로 나쁜 경험을 만든 코딩

   1. Neal Agarwal(Neal.fun)의 The Password Game은 웹사이트 가입 절차의 터무니없는 비밀번호 요건을 풍자한다.
   2. 비밀번호 숫자의 합이 25가 되어야 하고, 월 이름을 포함해야 하며, April을 넣어야 하고, 스폰서 이름까지 넣어야 하는 식으로 조건이 계속 추가된다.
   3. 조건을 하나 충족할 때마다 다른 변경을 요구해 사용자가 계속 뒤쫓게 만든다.
   4. 실제 사이트가 이런 비밀번호 시스템을 사용하면 모두가 나쁜 UX라고 비웃겠지만, Neal은 바로 그 불쾌하고 버그처럼 보이는 경험을 의도적으로 만들었다.

2. 코드가 나빠도 코딩은 코딩이다

   1. Neal은 아이디어를 떠올리고 에디터를 열어 코드로 구현한 뒤 사람들이 경험할 수 있는 게임으로 내놓았으므로 분명히 코딩했다.
   2. 같은 정도로 거친 비밀번호 필드가 실제 서비스에 우연히 만들어졌다면 사용자 목표에 맞지 않는 나쁜 결과라도 코딩이 아니라고 할 수 없다.
   3. 코드가 좋거나 유용하지 않다는 평가와 코딩을 수행했다는 사실은 별개다.

3. 의도 부족과 나쁜 요구사항의 차이

   1. “사이트용 비밀번호 시스템을 만들어 달라”는 말만 듣고 좋은 비밀번호 경험을 몰랐던 개발자가 The Password Game 같은 결과를 만들었다면, 계획에 세부 정보가 부족했던 경우다.
   2. 반대로 티켓에 복잡하고 나쁜 규칙을 모두 적어 “반드시 적용하라”고 했다면, 개발자는 나쁜 결정을 충실히 코드로 옮긴 경우다.
   3. 누락된 정보와 잘못된 정보는 모두 나쁜 코드를 만들 수 있지만, 입력이 나빠진 방식은 서로 다르다.

4. 계획과 구현 사이에 필요한 검증 계층

4.1. 계획 품질이 결과의 범위를 결정한다

1. 좋은 계획과 좋은 구현자

   1. 한 명의 엔지니어든 팀이든, 세 명이 스프린트를 수행하든, 계획이 엔지니어링 사이클에 들어가면 결과로 좋은 소프트웨어가 나오기를 기대한다.
   2. 유능한 엔지니어와 좋은 계획의 조합은 대략 10점 만점에 8~10점의 성공 범위를 만들 수 있다.
   3. 계획이 중간에 유실되거나 누군가 다른 방향으로 다시 쓰는 등 여러 변수가 있어도, 일반적인 기대치는 이 범위다.

2. 나쁜 계획과 뛰어난 코더

   1. 나쁜 계획이 들어오면 엔지니어가 “이 방향이 맞는지 확신할 수 없다”고 피드백할 수는 있다.
   2. 그러나 제품팀은 무엇을 만들지 결정하는 역할이고 엔지니어는 그것을 구현하는 역할이라는 이유로, 제품팀이 계획에 대한 반박을 반기지 않을 때가 많다.
   3. 좋은 코드를 빠르게 만드는 뛰어난 코더가 좋은 소프트웨어를 만드는 사람과 같은 것은 아니다.
   4. 계획에 반발하지 않고 실행만 잘하는 코더를 통과한 나쁜 계획은 결국 나쁜 소프트웨어가 된다.
   5. 나쁜 계획의 결과는 엔지니어가 아무리 뛰어나도 1~4점 정도의 낮은 범위에 머물 가능성이 크다.

3. 비어 있는 계획

   1. “대략 이런 것을 원한다”는 수준으로 세부 정보가 없는 빈 계획은 1~10점 전체에 걸쳐 결과가 무작위로 펼쳐진다.
   2. 요청의 복잡도, 소프트웨어 자체의 복잡도, 엔지니어가 사용자의 필요를 이해하는 정도, 엔지니어가 문제를 얼마나 잘 이해하는지가 결과를 좌우한다.
   3. 뛰어난 엔지니어에게 빈 계획을 주고 곧바로 코드를 작성해 PR을 올리는 것만 기대하면 좋은 결과가 나올 가능성은 랜덤하며, 현실적으로 높지 않다.

4.2. QA·스테이징·점진적 출시

1. 입력 개선만으로는 부족하다

   1. 산업 차원의 첫 단계는 계획을 더 잘 쓰는 일이다.
   2. 그러나 항상 계획 품질을 통제할 수 없고, 계획을 받은 구현자가 좋은지조차 모를 때가 있으므로 출력 측의 안전장치가 필요하다.
   3. 계획과 결과가 실제 사용자 요구에 맞는지 확인하는 별도의 계층이 계획-구현 파이프라인을 보완한다.

2. 검증 계층의 구성 요소

   1. QA는 결과가 요구사항과 맞는지 확인한다.
   2. 스테이징 환경은 실제 사용자에게 보내기 전에 변경을 실행할 공간을 제공한다.
   3. 프리뷰 빌드는 개발자가 자신의 컴퓨터에서 실행하기 어려울 때 대체 검증 경로가 된다.
   4. 점진적 출시(slow rollout)는 나쁜 코드가 모든 사용자에게 한 번에 도달하는 일을 막고, 문제가 발생해도 영향을 줄인다.
   5. 직접 로컬에서 실행하거나 프리뷰 빌드를 확인하거나, 에이전트가 테스트 루프를 돌린 뒤 결과 영상을 보여주는 방식 모두 “실제로 사용해 보기”에 해당한다.

3. 좋은 계획도 실행해 봐야 한다

   1. 계획이 좋아 보여도 실제로 구현한 뒤 경험이 나쁠 수 있다.
   2. 좋은 계획과 좋은 엔지니어가 좋은 경험을 만든다는 기대는, 그 엔지니어가 변경 결과를 검증할 시스템을 갖췄을 때만 성립한다.
   3. 나쁜 계획이나 나쁜 엔지니어가 들어오면 검증 계층의 필요성은 오히려 더 커진다.

4.3. 에이전트 스웜과 머지 이후의 비용

1. 실제 구현 주체의 변화

   1. 오늘의 팀은 Claude, Codex가 여러 서브에이전트를 띄우는 에이전트 스웜(agent swarm)으로 대체될 수 있다.
   2. 계획을 전달하면 에이전트들이 각 부분을 실행하고 pull request를 올린다.
   3. 코드를 실제로 실행하지 않았다면 PR은 멀쩡해 보일 뿐, 정말 작동하는지는 아무도 알 수 없다.

2. 확인하지 않은 결과의 전형적인 경로

   1. 잘린 업데이트 문구는 앱을 한 번 실행해 보면 즉시 발견할 수 있는 문제다.
   2. 아무도 앱을 보지 않았기 때문에 문제가 그대로 머지됐다.
   3. 머지 뒤에는 되돌리거나 고치는 마찰이 처음부터 만들고 머지하는 마찰보다 커진다.
   4. 최종 사용자가 직접 불편을 겪고 나서야 문제를 발견하는 구조는 검증 계층이 작동하지 않았다는 뜻이다.

3. 검증 결과의 피드백 루프

   1. 검증 결과가 좋으면 문제 해결 여부와 명백한 사용자 경험을 확인한 뒤 좋은 소프트웨어로 진행할 수 있고, 성공 범위는 8~10점에서 9~10점으로 올라갈 수도 있다.
   2. 결과가 나쁘면 배운 내용을 반영해 계획 단계로 돌아가 계획을 수정해야 한다.
   3. 구현상의 단순한 버그라면 계획까지 되돌아가지 않고 엔지니어 또는 에이전트 스웜으로 돌아가 수정할 수 있다.
   4. 좋은 검증 시스템은 코드가 사용자에게 도착하기 전에 문제를 찾아 작업 중에 고치게 한다.

5. 검증하기 어려운 코드베이스와 Claude Code Desktop

5.1. 인간에게 어려우면 에이전트에게는 더 어렵다

1. 실행 장벽의 역전

   1. 많은 코드베이스에서 로컬에서 실행해 변경을 확인하는 일이 변경 자체보다 복잡하다.
   2. 개발자는 로컬 실행보다 PR을 올리고 프리뷰 빌드가 올라오기를 기다리는 편이 쉽다고 느끼기도 한다.
   3. 사람이 실행·검증하기 어렵다면 에이전트에게는 훨씬 더 어렵다.
   4. 에이전트의 성능을 탓하기 전에 코드베이스를 실제로 실행하고 검증하기 쉽게 만들어야 한다.

2. 에이전트가 눈을 가린 엔지니어라면

   1. 새 엔지니어가 입사해 변경을 맡았는데 테스트 빌드 하나도, 하물며 세 개의 테스트 빌드도 자신의 컴퓨터에서 실행하지 못한다면 에이전트와 같은 상태가 된다.
   2. 많은 코드베이스가 뛰어난 엔지니어조차 불편해하고 결과를 확인할 자원을 갖지 못하게 만든다.
   3. 그 엔지니어의 눈을 가리고 작업하라고 하면 보이지 않는 변경에 대해서는 우연히 괜찮은 결과를 낼 수 있어도, 실제로 확인할 수 있게 했을 때보다 품질이 낮아진다.

5.2. 데스크톱 앱 검증의 비용

1. Claude Code Desktop의 구조적 불리함

   1. Claude Code Desktop은 완전한 데스크톱 기반 Electron 앱이다.
   2. QA를 하려면 각 스레드마다 지원되는 운영체제의 실제 인스턴스를 담은 그래픽 VM을 따로 제공해야 한다.
   3. 그 VM 안에서 빌드를 실행하고 Claude가 앱을 제어하며 상태를 확인하고 화면을 조작해야 한다.
   4. 이 환경을 만드는 일은 비싸고 어렵고 사소하지 않다.
   5. 게다가 Claude 계열 모델은 다른 곳의 모델보다 컴퓨터 사용(computer use) 능력이 떨어져 검증 루프의 품질이 더 낮아진다.

2. 웹 앱과의 차이

   1. Claude Code Web은 웹 기반이라 테스트 루프를 구성하기 쉽고, 하나의 머신에서 에이전트가 서로 다른 개발 빌드 8개를 8개 탭으로 열어도 관리가 가능하다.
   2. 반대로 한 컴퓨터에서 Electron 데스크톱 앱인 Claude Code Desktop 인스턴스 8개를 띄우고 각각을 혼동하지 않게 조작하는 일은 현실적으로 어렵다.
   3. 웹 앱이 계속 개선되고 데스크톱 앱이 상대적으로 정체되는 이유의 상당 부분은 모델의 코딩 능력보다 테스트 가능성(testability)의 차이에 있다.

3. 사람에게도 어려운 병렬 검증

   1. Electron 앱을 10년 동안 만들어 온 경험에 비추어도, 한 컴퓨터에서 서로 다른 PR 두 개를 동시에 실행해 검토하는 일은 쾌적하지 않다.
   2. 따라서 “사람에게 어려운 검증은 에이전트에게 아마 불가능하다”는 원칙이 적용된다.
   3. Claude Code Desktop은 변경을 실제로 실행해 잡아내는 루프가 부족할 때 어떤 문제가 생기는지 보여주는 대표 사례다.

6. 코딩과 소프트웨어 엔지니어링의 경계

6.1. 계획-구현-검증 전체를 무엇이라 부를 것인가

1. 좁은 코딩 정의

   1. 계획이 소스 코드로 변환되는 중간 구간, 즉 사람이 에디터에서 키보드를 누르거나 에이전트가 아이디어를 실행 가능한 코드로 바꾸는 부분만 코딩이라고 부를 수 있다.
   2. 이 정의에서는 에이전트 스웜이 담당하는 구현 구간이 해결된 셈이다.

2. 넓은 코딩 정의

   1. 무엇을 만들지 정하는 계획 단계까지 코딩에 포함할 수 있다.
   2. 변경이 유효한지 확인하는 검증 단계와, 검증 결과를 다시 구현에 반영하는 전체 루프까지 코딩에 포함할 수도 있다.
   3. 사람마다 범위를 다르게 정의하므로 “코딩이 해결됐다”는 대화가 혼란스러워진다.

3. 합의할 수 있는 최소선

   1. 전체 과정은 소프트웨어 엔지니어링(software engineering)이다.
   2. 에이전트가 중간 구간에서 코드를 잘 작성한다는 이유만으로 소프트웨어 엔지니어링이 해결됐다고 하면 안 된다.
   3. 소프트웨어 엔지니어링은 작은 코드 작성 상자 하나가 아니라, 그 상자들이 하루 수백 번 효과적으로 실행되고 누적될 수 있도록 아키텍처와 플랫폼을 만드는 일까지 포함한다.

6.2. 엔지니어링이 책임지는 것

1. 버그와 검증 루프

   1. 버그는 소프트웨어 엔지니어링의 일부다.
   2. 좋은 검증 루프를 만드는 일도 소프트웨어 엔지니어링의 일부다.
   3. 자신 있게 변경할 수 있도록 시스템을 설계하는 일도 소프트웨어 엔지니어링의 일부다.

2. 코드 몽키라는 오해

   1. 엔지니어링은 컴퓨터 앞에 앉아 키보드로 글자를 입력하는 코드 몽키의 업무만을 뜻하지 않는다.
   2. 뛰어난 신규 엔지니어라도 코드베이스에서 테스트 빌드조차 실행할 수 없으면 에이전트와 똑같이 제한된다.
   3. 좋은 엔지니어를 채용한 뒤 그 사람이 작업을 확인할 자원을 제공하지 않는 조직은, 에이전트에게 같은 제약을 걸고 좋은 결과를 기대하는 셈이다.

7. Boris의 주장을 가장 공정하게 해석하기

7.1. 명세가 있으면 구현은 강하다

1. Boris가 말한 “코딩 해결”의 범위

   1. 잘 작성된 명세(spec)의 변경을 에이전트에게 주면 99%의 확률로 지시받은 변경을 수행한다.
   2. 변경이 실제로 원하는 결과와 다르면 무엇이 잘못됐는지 알려주면 95%의 확률로 수정한다.
   3. 이는 요구사항을 코드로 옮기고 피드백에 따라 고치는 구현 능력이 매우 강해졌다는 뜻이지, 에이전트가 스스로 모든 버그를 예방한다는 뜻이 아니다.

2. 자율적 버그 발견은 별개의 문제

   1. 버그를 자율적으로 찾고 예방하는 일은 훨씬 어렵다.
   2. 이유는 모델이 멍청해서만이 아니라 코드베이스가 실행·테스트·반복 검증을 위한 환경을 제공하지 않기 때문이다.
   3. 시스템·아키텍처·앱을 테스트하기 쉽게 만들고, 에이전트가 반복 가능하고 검증 가능한 방식으로 그 시스템에 접근할 수 있는 도구를 제공해야 한다.

7.2. 에이전트가 검증했다는 증거

1. 도구 제공자의 책임

   1. 에이전트가 변경을 확인했다는 사실을 보여주는 시스템을 만들고, 그것을 정상적인 개발 과정으로 정착시켜야 한다.
   2. GitHub는 에이전트가 작업 증거인 이미지나 영상을 저장소에 커밋하지 않고 PR에 첨부할 수 있게 해야 한다.
   3. 증거 영상을 저장소에 억지로 넣는 방식은 여러 프로젝트에서 재난을 만들었다.
   4. 새로운 GitHub CLI 업데이트가 이미지·영상 업로드를 실제로 추가했으며, 이는 올바른 검증 체계를 만드는 중요한 발판이다.

2. 증거도 맹신할 수 없다

   1. 에이전트가 작업이 성공했다는 영상을 공유해도 영상 자체가 작동하지 않는 모습을 보여주는 경우가 있다.
   2. “잠깐, 네가 공유한 영상은 기능이 작동하지 않는다는 걸 보여주는데 무엇을 본 거지?”라고 물으면 에이전트가 자신의 판단 오류를 알아차리고 수정하기도 한다.
   3. 따라서 증거 제출 기능뿐 아니라 사람이 증거를 실제로 읽고 검증하는 습관도 필요하다.

8. 버그를 해결할 수 있는 조건과 T3 Code의 사례

8.1. 상세한 버그 명세와 최소 검증

1. 현재도 충분히 해결 가능한 버그

   1. 무엇이 잘못됐고 수정 결과가 어떤 모습이어야 하는지 상세한 버그 리포트로 명세하면, 최소한의 검증 시스템만 추가해도 대부분의 프런티어급 에이전트가 버그를 해결할 수 있다.
   2. 에이전트가 버그 없는 소프트웨어를 자동으로 출하한다는 뜻은 아니다.
   3. 계획과 검증이 예상하지 못한 엣지 케이스는 언제나 남으며, 버그를 선제적으로 찾아 고치는 빈도도 인간이 기대하는 수준에는 미치지 못한다.
   4. 그래도 버그를 식별하기 쉽게 만들고 모델이 고치는 능력을 높이면 버그 역시 어느 정도 “해결”되기 시작한다.

2. 스스로 검증 환경을 만드는 미래

   1. 에이전트가 코드를 수정한 뒤 테스트하려는데 저장소나 도구가 준비되지 않았다는 사실을 알게 될 수 있다.
   2. 미래의 에이전트는 검증에 필요한 조각을 직접 만들고, 저장소 설정을 개선하자는 제안이나 그 설정만을 위한 새 PR까지 작성할 수 있다.
   3. 그렇게 되면 에이전트가 출하하는 버그의 수를 크게 줄일 수 있다.

8.2. T3 Code와 Tailscale

1. 원격 개발 환경의 문제

   1. T3 Code를 Tailscale로 연결된 원격 머신에서 사용할 때, 다른 네트워크에 있는 사용자는 로컬호스트 링크를 클릭해 개발 서버를 볼 수 없다.
   2. 원격 사용자가 볼 수 있도록 개발 서버를 Tailscale 환경을 통해 노출해야 한다.

2. 검증 가능성을 높인 실제 작업

   1. t3dotgg는 T3 Code에서 개발 서버를 Tailscale 환경으로 실행하기 쉽게 만드는 변경을 수천 줄 단위로 진행했다.
   2. 기존 데이터의 읽기 전용 스냅샷(read-only snapshot)을 함께 가져오게 해 테스트가 실제 상황에 더 가까워지도록 만들었다.
   3. 이 작업은 사람이 에이전트의 변경을 확인하기 쉽게 만드는 동시에, 에이전트가 자신의 결과를 직접 검증하기 쉽게 만드는 작업이다.

3. 현재의 책임

   1. 에이전트가 이런 기반을 스스로 마련하기 전까지는 사람이 검증에 필요한 시스템을 만들고 버그가 발생하면 에이전트에게 알려야 한다.
   2. 좋은 개발 환경을 구축하는 일은 부수적인 편의 작업이 아니라 에이전트의 자율성을 높이는 핵심 엔지니어링이다.

9. 코드 리뷰에서 결과 확인으로

9.1. 코드를 읽어서 발견할 수 있는 것과 없는 것

1. 화면 버그는 코드 리뷰에서 놓친다

   1. 잘린 업데이트 텍스트는 코드만 읽어서는 잡히지 않는다.
   2. 코드가 그럴듯했기 때문에 사람도 에이전트도 문제를 발견하지 못했고, 실제 앱을 사용했어야만 확인할 수 있었다.
   3. 코드 리뷰에서 잡을 수 있는 버그는 에이전트의 개발 루프에서도 거의 잡을 수 있으므로, 코드를 읽어 버그를 찾는 시대는 사실상 끝났다.

2. 코드 읽기가 여전히 유효한 영역

   1. 아키텍처의 실패를 확인할 수 있다.
   2. 써야 할 것을 쓰지 않았거나 쓰지 말아야 할 것을 사용했는지 확인할 수 있다.
   3. 이번 변경이 건드리면 안 되는 영역을 건드렸는지 확인할 수 있다.
   4. 불필요한 테스트를 작성했거나 필요한 테스트를 작성하지 않았는지 판단할 수 있다.
   5. 다만 이런 문제는 전통적인 의미의 런타임 버그와는 다른 구조·설계·품질 문제다.

9.2. 최소한의 결과 검증

1. 코드를 내려받아 사용하기

   1. 변경을 자신의 머신에 내려받아 실행하고, 의도한 문제를 실제로 해결하는지 확인해야 한다.
   2. 사람이 직접 확인하지 못한다면 최소한 에이전트가 스스로 확인한 결과를 보여줘야 한다.
   3. 에이전트가 계획-구현-실행-검증 전체 루프를 자율적으로 돌릴 때까지 버그가 해결됐다고 말할 수 없다.

2. 검증 대상을 코드에서 결과로 바꾸기

   1. 에이전트가 코드를 잘 썼는지보다 결과가 사용자의 문제를 해결하는지 확인해야 한다.
   2. 좋은 코드처럼 보이는 PR은 실제 사용자 경험을 보장하지 않는다.
   3. 결과를 테스트하는 자동화와 사람이 직접 사용하는 확인 절차가 함께 있어야 한다.

10. Matt의 전술적 프로그래밍과 Boris의 3단계 전망

10.1. Matt가 Boris의 글을 불쾌하게 읽은 이유

1. 도발적인 문장의 효과

   1. “코딩은 해결됐다”는 문장은 의도적으로 사람들의 화를 돋우는 방식으로 쓰였다.
   2. 코딩을 전체 소프트웨어 개발 생명주기로 생각하는 사람에게는 VC 낙관론과 허세가 섞인 주장처럼 보이는 것이 자연스럽다.
   3. Boris가 자신의 코딩 정의를 명확히 하지 않았기 때문에 Matt의 해석은 충분히 합리적이다.

2. Boris의 해명

   1. Boris는 “TBH, this is a good debate to have”라고 답하며 좋은 논쟁이라고 인정했다.
   2. 그가 보는 가까운 과거와 미래는 세 단계다.
      1. 모델이 자신보다 코딩을 잘한다.
      2. 모델이 디버깅, 프로파일링, 최적화, 버그 수정, 시스템 설계, 추상화 설계, UI 설계, 아이디어 생성처럼 코딩에 인접한 엔지니어링 작업도 자신보다 잘한다.
      3. 모델이 컴퓨터로 할 수 있는 대부분의 일을 대부분의 사람보다 잘한다.

10.2. 단계별 현재 위치

1. Boris 자신의 작업

   1. Boris가 하는 코딩에 대해서 Claude는 1단계, 즉 손으로 코드를 쓰는 능력에서 이미 그를 넘어섰다.
   2. 디버깅·버그 수정·최적화·프로파일링·시스템 설계 같은 2단계는 일부만 달성했다.
   3. 컴퓨터에서 할 수 있는 대부분의 일을 사람보다 잘하는 3단계는 이제 초기 징후가 나타나는 정도다.

2. 전문가에 따른 분포

   1. 모든 사람에게 1단계가 도달한 것은 아니다.
   2. 컴파일러와 타입 시스템의 세계적 전문가인 Anders Hejlsberg라면 Claude가 아직 1단계에 도달하지 않았을 수도 있다.
   3. Boris는 그 수준에도 곧 도달할 것이라고 베팅하면서, 다른 사람들을 대상으로는 2단계와 3단계 쪽으로 계속 확장될 것이라고 본다.

3. 최상위 엔지니어의 병렬성

   1. Ryan Carniato는 Solid.js를 만든 프레임워크를 조금 수정하는 데 그치지 않고, Fable을 사용해 복잡한 아이디어를 말로 풀고 시간이 너무 오래 걸려 직접 시도하지 못했을 이론을 실험하고 있다.
   2. 최상위 엔지니어는 에이전트가 자신만큼 깊이 있지는 않아도 충분히 가까운 수준으로 코딩을 수행하게 하고, 여러 작업을 병렬로 돌려 과거에는 불가능했던 이론 검증을 실행한다.
   3. 모델 능력은 인간 능력의 분포를 포착한다고 볼 수 있으며, 평균 프로그래머라고 생각하는 Boris에게 Claude가 이미 자신을 넘어선 것은 이 분포의 한 지점이 먼저 자동화된 사례다.

10.3. 손코딩을 멈춘 뒤에도 코딩하는 사람

1. Boris의 실제 업무 방식

   1. Boris는 지난해 11월부터 손으로 코드를 작성하는 일을 완전히 멈췄다.
   2. 그렇다고 코딩을 멈춘 것은 아니며, 매일 에이전트를 사용해 코드를 작성한다.
   3. 자신과 주변 사람들에게는 이 상태를 “코딩이 해결됐다”고 부르는 것이 타당하게 느껴졌다.

2. 엔지니어링의 잔여 영역

   1. Claude가 작성하는 코드는 완벽하지 않고 버그와 비효율을 포함한다.
   2. Opus 4.8(자막 표기: Opus 48)은 Boris보다 나은 것처럼 느껴진 최초의 모델이었다.
   3. t3dotgg의 에이전트는 Boris가 직접 찾지 못했을 최적화와 디버깅 문제를 일상적으로 찾아낸다.
   4. 모델 세대가 바뀔 때마다 코드 품질과 비코딩 엔지니어링 능력은 개선되지만, 코딩 능력과 엔지니어링 전체 능력은 여전히 동일하지 않다.

11. 전술적 프로그래밍과 전략적 프로그래밍

11.1. John Ousterhout의 구분

1. 전술(tactical) 프로그래밍

   1. John Ousterhout가 말한 전술적 프로그래밍은 현장에서 매일 수행하는 구현, 즉 당장의 변경을 빠르게 코드로 만드는 일이다.
   2. Matt는 AI가 전술적 프로그래밍은 대부분 해결했다고 본다.

2. 전략(strategic) 프로그래밍

   1. 전략적 프로그래밍은 장기적인 코드베이스 건강, 아키텍처 설계, 올바른 의사결정처럼 미래를 고려하는 일이다.
   2. Matt는 AI가 전략적으로 사고한다는 증거를 아직 보지 못했다.
   3. Ousterhout가 말한 “전술적 토네이도(tactical tornado)”는 놀라운 양의 일을 처리하지만 미래를 위한 고려는 전혀 하지 않는 직원이다.
   4. 현재 에이전트가 보여주는 모습도 이런 전술적 토네이도에 가깝다.

11.2. 전략을 직접 설계하고 에이전트를 컨설턴트로 쓰기

1. 현재의 한계

   1. 에이전트가 장기적인 코드베이스 건강과 아키텍처를 선제적으로, 자율적으로 잘 관리할 것이라고 기대하기 어렵다.
   2. 에이전트가 전략적 판단을 스스로 지속해서 수행한다기보다, 인간이 전략을 설계하고 에이전트가 실행하도록 하는 편이 현실적이다.

2. 컨설턴트로서의 가치

   1. 에이전트에게 현재 아키텍처를 조사하고 피드백을 달라고 요청할 수 있다.
   2. 계획 중인 변경을 검토하게 하고, 특정 가설을 확인하기 위한 조사와 이론 검증을 시킬 수 있다.
   3. 사람이 전략을 세우는 과정에 에이전트를 컨설턴트로 참여시키면 상당한 가치가 생긴다.

3. 전략 이후의 폭발적인 실행력

   1. 사람이 전략을 모두 세우고 계획에 확신을 가진 뒤, 에이전트에게 필요한 검증 도구와 컨텍스트를 제공하면 에이전트는 상상을 초월하는 속도로 대담한 계획을 실행한다.
   2. 그 속도는 엔지니어링의 성공이 늘 시스템을 잘 설계하는 데 달려 있었다는 사실을 다시 보여준다.

12. 에이전트를 잘 작동시키는 조직·코드베이스 설계

12.1. 사람에게 좋은 시스템이 에이전트에게도 좋다

1. 일상 작업 흐름의 기반

   1. 회사의 누구나 다른 사람의 변경을 쉽게 내려받을 수 있어야 한다.
   2. 변경이 문제를 해결했는지 확인하기 쉬워야 한다.
   3. 필요한 코드가 어디에 있는지 찾기 쉬워야 한다.
   4. 변경을 PR로 올리고 승인받아 출시하기 쉬워야 한다.
   5. 문제가 생기면 롤백하기 쉬워야 한다.

2. 생산성의 일반 원칙

   1. 이런 설계는 인간 엔지니어를 더 효과적으로 만든다.
   2. 같은 설계는 에이전트도 더 효과적으로 만든다.
   3. 에이전트의 지능만 높이는 것보다 에이전트가 검증 가능한 작업을 반복할 수 있는 플랫폼을 만드는 일이 결과에 직접 영향을 준다.

12.2. 자동 유지보수의 초기 단계

1. 자동화되고 있는 전략 작업

   1. Anthropic에서는 앱을 자동으로 유지보수하기 시작했다.
   2. 최근에는 여러 고객도 비슷한 자동화 파이프라인을 구축하고 있다.
   3. T3 Code는 아직 사람들이 트윗을 스크린샷해 직접 올리는 방식을 쓰며, 트윗을 기반으로 에이전트가 자동 수정안을 제안하게 하지는 않는다.

2. 전략 파이프라인의 예시

   1. 버그 리포트 → 재현(repro) → 수정(fix)
   2. 기능 요청 → 프로토타입
   3. 크론(cron) → 코드베이스 아키텍처 RFC → 리팩터링(refactor)
   4. 이런 파이프라인을 관리하고 어떤 단계에서 인간의 판단을 넣을지는 여전히 전략적 관심사다.

12.3. 최종 결론과 열린 질문

1. 핵심 결론

   1. 에이전트는 명확한 계획을 코드로 옮기는 데 매우 강하다.
   2. 버그를 찾고 검증하는 일은 모델 지능과 코드베이스 설계가 함께 개선되어야 해결된다.
   3. 코딩을 좁게 정의하면 해결됐다고 말할 수 있지만, 소프트웨어 엔지니어링은 아직 해결되지 않았다.
   4. 버그가 해결됐다고 말하려면 에이전트가 계획-구현-실행-검증 루프를 스스로 완주하고 그 결과를 증명해야 한다.

2. 독자에게 남은 질문

   1. 엔지니어링이 아직 해결되지 않았고 코딩은 해결됐다는 구분이 과장인가?
   2. 코딩이 해결됐다고 말하는 것 자체가 너무 앞서 나간 주장인가?
   3. 엔지니어링이 여전히 대체로 인간의 일이라고 말하는 것은 충분히 강한 주장인가?
   4. 각자의 실제 업무에서 에이전트가 계획, 구현, 검증 중 어디까지 책임지고 있는가?

주요 발언 모음

“Coding is solved. Bugs are not yet solved.”

“코딩은 해결됐다. 버그는 아직 해결되지 않았다.”

“If you're writing your code by hand still, you are largely falling behind.”

“아직도 손으로 코드를 작성한다면 크게 뒤처지고 있는 셈이다.”

“This is a bug.”

“이건 버그다.”

“If it is too hard for you to spin up and test, it is way too hard for your agents to do the same.”

“당신이 실행하고 테스트하기 어렵다면 에이전트가 똑같이 하는 일은 훨씬 더 어렵다.”

“We need to check the results, not necessarily the code.”

“코드 자체가 아니라 결과를 확인해야 한다.”

“In order to make your agents act more strategic and act more like engineers, you have to do the engineering upfront yourself.”

“에이전트가 더 전략적으로, 더 엔지니어처럼 행동하게 하려면 먼저 사람이 엔지니어링을 직접 해 두어야 한다.”

핵심 데이터 & 수치

• PR 처리량: 회의가 많은 날에도 최소 8개 이상의 PR을 머지했다.
• CI Blacksmith 하드웨어: 기존 GitHub Actions보다 2배 빠르다.
• 캐시 다운로드: 4배 빠르다.
• Docker 빌드: 최대 40배 빠르다.
• Sticky Disks: 1분을 넘기던 캐시 다운로드를 약 3초로 줄였다.
• 좋은 계획·좋은 엔지니어: 결과 성공 범위는 대략 10점 만점에 8~10점이다.
• 나쁜 계획: 구현자가 뛰어나도 결과가 1~4점에 머물 수 있다.
• 명확한 명세 변경: 에이전트가 지시대로 수행할 확률을 약 99%로 제시했다.
• 오류 피드백 후 수정: 잘못된 결과를 알려주면 약 95% 확률로 고친다고 제시했다.
• T3 Code 검증 환경: Tailscale 개발 서버와 읽기 전용 데이터 스냅샷을 위해 수천 줄의 변경을 진행했다.
• 웹 검증 병렬성: 하나의 머신에서 에이전트가 개발 빌드 8개를 8개 탭으로 동시에 확인할 수 있다.

결론 및 시사점

1. 코딩을 키보드 입력과 명세-코드 변환으로 정의하면 AI가 이미 해결했다고 평가할 근거가 충분하다.
2. 소프트웨어 엔지니어링은 계획의 질, 아키텍처, 실행 환경, 사용자 경험, 검증, 출시·롤백까지 포함하므로 아직 인간이 책임져야 한다.
3. 에이전트가 코드를 작성했다는 사실은 PR이 실제로 작동한다는 증거가 아니다.
4. QA, 스테이징, 프리뷰, 점진적 출시, 자동화된 실행·영상 증거를 검증 계층으로 묶어야 한다.
5. 사람이 쉽게 실행할 수 없는 코드베이스에서 에이전트에게 자율적 품질을 기대할 수 없다.
6. 에이전트를 전략가로 만들려면 사람이 먼저 전략과 시스템을 설계하고, 에이전트에게 실행에 필요한 컨텍스트와 검증 도구를 제공해야 한다.
7. 미래의 에이전트는 스스로 테스트 기반을 만들고 저장소를 개선하는 PR을 작성할 수 있지만, 그 전까지는 사람이 기반을 마련하고 결과를 확인해야 한다.

핵심 요약 (20줄)

1. AI 에이전트는 명세가 분명한 코드를 빠르게 작성하는 능력에서 인간 개발자를 크게 앞서고 있다.
2. 코딩을 에디터에서 키보드로 소스 코드를 입력하는 행위로 정의하면 코딩은 사실상 해결됐다.
3. 코딩을 아이디어부터 사용자 경험까지의 전체 생명주기로 정의하면 아직 해결되지 않았다.
4. Claude Code Desktop의 업데이트 문구가 화면에서 잘린 사례는 코드 생성과 결과 검증의 차이를 보여준다.
5. 모델은 소스 코드만 읽고 실제 화면의 제한된 공간을 확인하지 않아 명백한 UI 버그를 만들었다.
6. 인간 개발자는 보통 변경된 화면을 직접 열어 보고 동료에게 PR을 보내기 전에 이런 문제를 고친다.
7. 에이전트가 올린 PR에는 원래 개발자가 실행과 테스트를 마쳤다는 기존의 암묵적 보장이 없다.
8. 좋은 계획과 뛰어난 구현자도 QA·스테이징·프리뷰 같은 검증 계층 없이는 나쁜 경험을 만들 수 있다.
9. 빈 계획은 결과를 1점에서 10점까지 무작위로 만들고, 나쁜 계획은 뛰어난 코더도 좋은 소프트웨어로 바꾸기 어렵다.
10. Claude와 Codex가 만드는 에이전트 스웜도 코드를 실행해 보지 않으면 결과가 작동하는지 알 수 없다.
11. 사람이 로컬에서 실행하기 어려운 코드베이스는 에이전트에게 더욱 검증하기 어려운 환경이다.
12. Electron 기반 Claude Code Desktop은 그래픽 VM과 운영체제 인스턴스가 필요해 웹 앱보다 테스트 루프를 만들기 어렵다.
13. 소프트웨어 엔지니어링에는 버그 수정, 아키텍처, 검증 루프, 출시와 롤백을 가능하게 하는 플랫폼 설계가 포함된다.
14. Boris는 명확한 변경을 99% 수행하고 오류를 알려주면 95% 수정하는 에이전트의 구현 능력을 코딩 해결의 근거로 본다.
15. 자율적으로 버그를 찾아 예방하는 능력은 모델 성능뿐 아니라 코드베이스와 도구의 검증 가능성에 달려 있다.
16. 상세한 버그 명세와 최소한의 검증 시스템이 있으면 프런티어급 에이전트는 이미 많은 버그를 해결할 수 있다.
17. T3 Code는 Tailscale 개발 서버와 읽기 전용 데이터 스냅샷을 구축해 사람과 에이전트가 결과를 확인하기 쉽게 만들었다.
18. 코드 리뷰는 구조와 아키텍처 문제를 찾는 데 유효하지만 화면에서만 드러나는 버그는 실제 사용으로 확인해야 한다.
19. Matt Pocock의 전술적 프로그래밍과 전략적 프로그래밍 구분은 에이전트가 전술에는 강하고 장기 판단에는 약하다는 점을 설명한다.
20. 에이전트가 엔지니어처럼 일하려면 사람이 먼저 전략과 검증 시스템을 설계하고 결과를 코드보다 우선해 확인해야 한다.