[한영자막] 슬롭에는 슬롭으로 맞섭니다 — Vaibhav Gupta, Boundary

URL: https://www.youtube.com/watch?v=bKT2wOec_rg 날짜: 2026-08-08 채널: Tech Bridge 원본 발표: AI Engineer World's Fair 발표자: Vaibhav Gupta (Boundary / BAML 공동창업자) 영상 길이: 약 21분 자막 기준: 영어 자동 생성 자막 (한국어 자막은 영상 내장)

---

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

==AI가 쏟아내는 '슬롭(slop)' 코드와 맞서면서도 코드 리뷰 없이 안정적인 프로그래밍 언어를 출시할 수 있었던 이유는 무엇인가?==

• 인간의 통제 대신 기계가 검증하는 불변식(invariant)과 에이전트 중심 도구로 통제 지점을 옮겼다.
• 프로그래밍 언어처럼 슬롭을 용납할 수 없는 기초를 증명 삼아, 수천 시간의 인간 노동을 수백만 토큰으로 대체했다.
• TypeScript·JavaScript 같은 기존 기초가 에이전트 시대에 맞지 않으므로, Git·데이터베이스·프로그래밍 언어까지 새로 고민해야 한다.

Vaibhav Gupta는 Boundary에서 BAML이라는 프로그래밍 언어를 만드는 팀이 3년째 슬롭과 전쟁 중이라고 말한다. 그의 팀은 코드 리뷰를 하지 않고, 모든 엔지니어가 병렬로 작업하며, AI 도구 사용 방식도 표준화하지 않는다. 그럼에도 불구하고 약 8명의 인원으로 2년이 채 안 되어 안정적인 언어를 만들 수 있었던 비결은, 슬롭을 막기 위해 더 많은 슬롭 같은 내부 도구를 쌓되, 그 위에 기계 검증 가능한 불변식을 얹었기 때문이다.

---

1. 도발적인 오프닝: 코드 리뷰 없는 팀, 병렬 작업, AI 표준화 없음

Gupta는 청중에게 먼저 자신의 팀이 "줌머 YC 스타트업"처럼 들릴 것이라고 인정한 뒤, "나는 분명 밀레니얼"이라고 농담으로 반박한다. 그 뒤에 깔린 진지한 주장은, 전통적인 엔지니어링 통제가 에이전트 시대에는 더 이상 효과적이지 않다는 것이다.

1.1. Boundary의 비전통적 엔지니어링 관행

1. 코드 리뷰를 폐기한 이유

   1. 대체재: 인간의 리뷰 대신 architecture.md 불변식, 의존성 그래프 검증, 에이전트 기반 테스트 하니스(harness)를 운영한다.
   2. 결과: 인간이 한 줄씩 읽지 않아도 기계가 깨진 것을 잡아낸다.
   3. 전제: 언어 컴파일러처럼 동작이 결정적이고 되돌릴 수 없는 기초 시스템에서만 이 베팅이 성립한다.

2. 병렬 작업을 강제하는 이유

   1. 연속적 소유권 대신: 누가 먼저 설계를 맡느냐가 아니라, 설계 문서를 중심으로 모두가 동시에 진행한다.
   2. 동기화 도구: 설계 문서 알림 피드와 "반드시 읽어야 한다"는 제약이 병렬 충돌을 막는다.
   3. 효과: 늦은 밤에도 문서가 업데이트되면 여러 동료가 즉시 읽는 문화가 생겼다.

3. AI 도구 사용 표준화 폐기

   1. 팀의 자율: 누구는 Claude, 누구는 Codex, 누구는 Hacker News에서 찾은 최신 도구를 쓴다.
   2. 제약: AI 도구를 통일하지 않고, 오직 시간이 지나도 변하지 않는 사실만 architecture.md에 적는다.
   3. 핵심 인사이트: 훌륭한 엔지니어에게 무엇을 쓸지 지시할 수 없으므로, 지시할 수 있는 것만 지시한다.

1.2. 왜 프로그래밍 언어가 증명 대상인가

1. 슬롭을 용납할 수 없는 기초

   1. 결정론적 동작: 언어는 매번 정확히 같은 방식으로 동작해야 한다.
   2. 설계의 되돌림 불가: 나쁜 설계 결정을 한 달 뒤 조용히 수정할 수 없다.
   3. 따라서: 이곳에서 통제 메커니즘이 살아남으면 다른 곳에서도 살아남을 수 있다.

2. BAML의 성과

   1. 인원: 약 8명.
   2. 시간: 2년이 채 안 되어 안정성에 도달.
   3. 비교: 에이전트 이전 세계에서는 수천, 수만 시간의 인간 노동이 들어가도 여전히 부서진 시스템이 출시되었을 것이다.

---

2. 슬롭이란 무엇이며, 슬롭으로 슬롭을 싸우다

Gupta는 슬롭에 대한 철학을 "Slop Sue"라는 스승에게 배운 공안으로 소개한다.

2.1. 슬롭의 정의와 mindset

1. 슬롭 = 읽지 않는 코드

   1. Gupta가 말하는 정의: "Slop is just any code you don't read."
   2. 이 정의는 AI가 생성한 코드뿐 아니라, 인간이 작성한 채 읽지 않는 코드도 포함한다.
   3. 현재 시점의 의미: "this is the least amount of slop that your code base will ever have. Cherish it." — 오늘이 앞으로 코드베이스에서 슬롭이 가장 적은 날이다.

2. 슬롭을 받아들이고 슬롭으로 맞서는 전략

   1. 공안: "To defeat the slop, we must become the slop."
   2. 실천: 내부에 일부러 "슬롭 같은" 도구를 많이 만들되, 그것들이 기계 검증 가능한 불변식을 지키게 한다.
   3. 결론: 슬롭을 없애려 하지 말고, 슬롭이 시스템을 망가뜨리지 못하게 가두라.

2.2. 버려진 통제와 그 대체 메커니즘

버려진 통제	대체 메커니즘
코드 리뷰	에이전트가 처음부터 빌드하고, 대화 기록을 분석해 트리아지하는 테스트 하니스
순차적 소유권	설계 문서 알림과 "반드시 읽기" 제약을 통한 병렬 동기화
표준화된 AI 스택	architecture.md 불변식 + "컴파일러 깊숙이 들어갈 때 한 사람과 이야기하기" 규칙
아키텍처 검토 위원회	의존성 그래프 시각화 + CI/CD가 강제하는 불변식

---

3. 첫 번째 불변식: 표준의 전투 — architecture.md

Gupta는 훌륭한 엔지니어를 고용하면 그들에게 무엇을 쓸지 말할 수 없다는 점을 첫 번째 전제로 삼는다.

3.1. 엔지니어의 자율과 최소한의 표준

1. AI 도구 통일의 포기

   1. 팀원들은 Claude, Codex, Hacker News의 최신 도구 등 제각각 사용한다.
   2. 통일하지 않는 이유: 도구는 매주 바뀌고, 엔지니어가 스스로 가장 생산적인 도구를 찾아야 하기 때문이다.
   3. 통제할 수 있는 것: 변하지 않을 설계 사실.

2. architecture.md의 역할

   1. 모델 비의존: CLAUDE.md 같은 특정 모델 이름을 쓰지 않는다. 모든 모델이 이해할 수 있는 이름을 사용한다.
   2. 극도로 작음: 수개월~수년 동안 변하지 않는 사실만 담는다.
   3. 내용 예시: 컴파일러의 계층 구조(layer structure).

3.2. 컴파일러 깊이에 따른 인간 중재 규칙

1. "한 사람과 이야기하기" 규칙
   1. 에이전트가 컴파일러의 더 깊은 계층으로 들어갈수록, 적어도 한 사람과 이야기하도록 강제한다.
   2. 목적: 의도적인 감속. AI가 무분별하게 깊은 곳을 고치지 못하게 한다.
   3. 효과: 표준은 유지되면서도, 표면 도구의 사용 자율은 보존된다.

---

4. 두 번째 불변식: 설계의 전투 — 글은 슬롭이 될 수 없다

Gupta는 "코드는 슬롭이어도 된다"고 말하면서 "글은 슬롭이어선 안 된다"는 규칙을 제시한다.

4.1. 설계 문서 시스템의 구조

1. 기존 도구의 문제

   1. Notion과 GitHub는 설계 문서용으로 충분하지 않다고 판단했다.
   2. AI 에이전트가 직접 참여할 수 없는 구조가 문제였다.

2. 내부 설계 문서 도구

   1. 버전 관리 + 댓글: GitHub의 이슈/PR 기능과 유사한 설계 문서 워크플로우를 제공한다.
   2. 마크다운 기반: Markdown 파일과 간단한 CLI 스크립트로 구성되어 있어, 에이전트가 직접 읽고 쓸 수 있다.
   3. Notion·GitHub의 대체재: "GitHub처럼 다루되 GitHub 그 자체는 아니다."

3. Slack 알림의 힘

   1. 설계 문서가 업데이트될 때마다 Slack 채널에 알림이 간다.
   2. 결과: 그 채널이 회사에서 가장 인기 있는 채널이 됐다. 새벽 2시에 문서가 올라와도 동료 3명이 즉시 읽는다.
   3. 반직관적 발견: 가장 많이 읽히는 문서는 논쟁 중인 문서가 아니라, "변하지 않을 설계 문서"이다. 변하지 않을 것이기에 읽을 가치가 있다.

4.2. AI 정신병과 마지막 규칙

1. Gupta의 실패

   1. 설계 문서 도구를 만든 뒤 Gupta는 "AI 정신병(AI psychosis)"에 걸려 하루에 10개의 설계 문서를 만들어냈다.
   2. 결과: 팀이 Gupta의 슬롭과 싸워야 했다.

2. 마지막 규칙: 읽기를 강제한다

   1. 설계 문서를 배포하려면, 사람들이 실제로 읽어야만 한다는 제약을 추가했다.
   2. 방법: 배포 시 읽어야 할 독자를 지정하거나, 읽음 확인을 요구한다.
   3. 효과: 이 제약 하나로 문서 품질이 극적으로 높아졌다.

---

5. 세 번째 불변식: 아키텍처의 전투 — 기계가 통제하는 의존성

설계 문서가 인간을 통제한다면, 의존성 그래프 도구는 기계를 통제한다.

5.1. 의존성 그래프 시각화와 CLI 불변식

1. 그래프의 구성

   1. 내부 패키지와 주요 외부 의존성을 모두 시각화한다.
   2. 의미적 경계(semantic boundaries): 개별 패키지 주변에 경계를 그어 모듈 구조를 드러낸다.
   3. 실시간 관찰: 코드베이스가 어떻게 변하는지 실시간으로 지켜볼 수 있다.

2. CLI 기반 불변식 강제

   1. 클로드가 새 패키지를 만들거나 누수 의존성(leaky dependency)을 추가하면, CI/CD가 정확히 어느 곳이 깨졌는지 알려준다.
   2. Git 커밋 히스토리와 연결해 변화 궤적을 추적한다.
   3. 결과: 아키텍처 변경이 우발적 드리프트가 아닌 의도적인 행위가 된다.

5.2. 안정된 아키텍처의 증거

1. 3~4개월간 아키텍처 변경 없음
   1. Gupta가 발표 시점 기준으로 지난 3~4개월간 아키텍처가 바뀌지 않았다고 언급한다.
   2. 의미: 시스템을 얼리는 것이 아니라, 변화를 가시화하고 기계가 검증하게 만든 것이다.

---

6. 네 번째 불변식: 에이전트를 테스트 장치로 활용하기

Gupta가 가장 중요하게 여기는 코드 리뷰 대체재는 에이전트 기반 테스트 하니스다.

6.1. 에이전트 기반 테스트 루프

1. 지속적 생성과 빌드

   1. 에이전트가 계속해서 BAML 프로그램을 생성한다.
   2. 각 프로그램에 대해 "처음부터(spin up from scratch)" 빌드를 시도한다.

2. Claude 대화 기록 전체 수집

   1. 모든 도구 호출(tool call), 결과, 중간 상태를 포착한다.
   2. 인간과 에이전트가 함께 이 기록을 검토한다.

3. 버그와 비효율 분류

   1. 버그: 언어의 잘못된 동작.
   2. 비효율: "3번의 도구 호출로 해결할 것을 1번에 할 수 있었는가?"
   3. 트리아지: 인간이 실제 문제인지, 환각인지, "취향이 없는(no taste)" 제안인지 판별한다.

4. 자동 수정 및 배포

   1. 에이전트가 수정안을 제안하고, 검증 후 직접 배포한다.

6.2. 언어 기능의 A/B 테스트

1. 데이터 기반 설계

   1. 어떤 언어 기능이 에이전트에게 더 나은지 추측하지 않는다.
   2. 두 버전을 비교해 도구 호출 수, 오류율, 최종 결과 정확도를 측정한다.
   3. 결과: "deterministically know what's going on" — 결정론적으로 무슨 일이 일어나는지 안다.

2. 토큰 경제학

   1. 과거 컴파일러급 시스템은 수만 인간 시간을 들여도 부서져 출시됐다.
   2. Boundary는 수백만 토큰을 소비해 동일한 수준의 안정성을 얻었다.
   3. Gupta는 이제 코드 한 줄 쓰지 않고도 데이터 기반 인사이트를 얻을 수 있다고 말한다.

---

7. 기초층의 슬롭: TypeScript와 JavaScript의 한계

Gupta는 개별 전투에서 이길 수 있어도 전쟁에서 질 수 있다고 말하며, 그 이유를 기존 기초 시스템에서 찾는다.

7.1. TypeScript의 설계 목표 재해석

1. 정확성과 생산성의 균형

   1. TypeScript의 공식 설계 목표는 "정확성(correctness)과 생산성(productivity)의 균형"이다.
   2. Gupta는 여기에 별표(*)를 달고 싶다고 말한다: 인간의 생산성을 의미한다.

2. 에이전트 시대에 맞지 않는 결정

   1. 만약 인간이 코드 한 줄을 쓰지 않는 세상을 위해 언어를 설계한다면, 근본적 선택이 달라질 것이다.
   2. JS의 기본 sort는 원소를 문자열로 강제 변환한 뒤 비교한다. Gupta는 이를 "Why do we turn things to strings when we sort them?"이라고 지적하며 언어에 박힌 슬롭이라고 부른다.
   3. TypeScript의 일부 기능은 Gupta가 "I love this part of TypeScript"라고 비꼬면서, "my agent loves"라고 말한다 — 에이전트가 쉽게 악용하는 escape hatch이다.

7.2. 깨진 기초 위에 계속 쌓는 산업

1. 레이어의 누적

   1. JavaScript 위에 CoffeeScript, 그 위에 TypeScript, 그 위에 AI 도구가 계속 쌓인다.
   2. 핵심 비판: "the thing underneath is already broken" — 가장 밑바닥이 이미 부서져 있다.

2. 패치 대신 재설계

   1. 계속해서 위에 레이어를 쌓는 대신, 첫 원칙부터 새로 설계해야 한다.
   2. Gupta는 이것이 결국 "made-up language" 즉 BAML 같은 새 언어로 이어진다고 말한다.

---

8. 에이전트 우선 언어 설계: BAML의 구체적 기능

Gupta는 BAML이 "새 언어가 모든 문제를 해결해준다"는 식의 환상을 피하면서도, 에이전트 우선 설계가 실제로 무엇을 바꾸는지 보여준다.

8.1. 코드 읽기를 선택 사항으로 만드는 시각화

1. 확대 가능한 코드 지도

   1. 코드를 클릭하면 정확한 연결된 줄로 이동한다.
   2. 더 넓은 시맨틱을 보고 싶을 때는 확장하여 구조를 파악한다.
   3. 의도적 무시: "Nope, that's too much slop. Let's let that be slop." — 너무 많은 세부 사항은 슬롭으로 남겨두고 넘어간다.

2. 실행 추적(execution trace)을 중심으로 이해하기

   1. Gupta는 "코드를 모두 읽지 않는 세상에서 코드를 이해하는 유일한 방법은 실행 추적이다"라고 말한다.
   2. BAML은 첫 원칙부터 설계되어 실행 추적이 사실상 성능 비용이 거의 없다.
   3. 모든 파일에 Claude가 탐색할 수 있는 추적 시스템이 내장되어 있어, 에이전트가 버그·오류·비효율을 스스로 찾고 최적화한다.

8.2. 에이전트 우선 탐색 도구

1. grep/ripgrep을 대체하는 단일 호출

   1. Gupta는 "grep should not be used anywhere"라고 말한다.
   2. 예전에는 rg calculate로 여러 파일을 훑어야 했다.
   3. BAML에서는 "Can you describe calculate for me?"라고 한 번 물으면, docstring, 실제 소스 코드, 모든 사용처를 한 번에 반환한다.

2. 라이브러리 학습의 변화

   1. 외부 라이브러리를 이해할 때 웹 검색 대신, 해당 라이브러리 코드 자체를 질의한다.
   2. Gupta는 "docs may lie, readme will definitely lie, but the code cannot lie"라고 강조한다.
   3. 결과: 여러 도구 호출이 하나의 도구 호출로 축소된다.

8.3. 모든 함수가 즉시 CLI가 되는 실행 모델

1. 함수 = 프로그램

   1. add 함수를 실행하면 add라는 CLI 명령어가 되어 A, B 매개변수를 받는다.
   2. multiply도 독립형 바이너리 CLI가 된다.
   3. 코드를 직접 실행하지 않아도 동작을 확인할 수 있다.

2. 타입 안전성과 이식성

   1. 모든 것이 타입 안전하고 결정론적이다.
   2. Windows, Mac, Linux, WASM을 포함한 아키텍처를 모두 타겟팅할 수 있다.
   3. 배포 걱정 없이 에이전트가 즉시 도구로 사용할 수 있다.

---

9. 오류 처리와 타입 시스템: 신뢰의 기초

Gupta는 신뢰가 핵심이라며, 현재 에이전트의 오류 처리를 강하게 비판한다.

9.1. 에이전트의 전형적 오류 처리 패턴

1. 중첩된 try/catch와 console.log
   1. 에이전트는 try/catch를 계속 중첩하다가 결국 console.log some error happened로 끝낸다.
   2. Gupta는 이를 아름다운 오류 처리가 아니라고 지적하며, Rust를 제외하고는 거의 본 적이 없다고 말한다.

9.2. BAML의 첫 원칙적 오류 처리

1. 오류 타입 추론

   1. divide 함수는 0으로 나누기 오류를 던진다는 사실을 주석 없이도 추론한다.
   2. divide를 호출하는 calculate 함수도 자동으로 동일한 오류 타입을 전파받는다.
   3. 이점: 개발자가 직접 주석을 달거나 문서를 추적하지 않아도 된다.

2. 전체 처리 증명

   1. 컴파일러는 모든 오류가 처리되었는지 증명하거나, 그렇지 않으면 코드를 거부한다.
   2. Gupta는 "No more guessing. There's no unknowns. It's guaranteed to be proven"이라고 말한다.

3. "절대 던지지 않는다"는 제약 검증

   1. API가 "never throws"를 보장한다고 주장하면, 컴파일러는 실제로 처리되지 않은 오류가 있는지 검사한다.
   2. 오류를 catch하여 sentinel 값을 반환하면, 해당 오류가 더 이상 던져지지 않는다는 보장이 복원된다.
   3. 의미: 타입 시스템이 거짓말을 하지 않는다.

9.3. 신뢰와 경직성

1. 코드는 신뢰의 문제
   1. Gupta: "Code is a matter of trust."
   2. 우리가 ML이 생성한 코드를 맹신하지 않는 이유는, 그 아래 시스템이 충분히 경직성(rigidity)을 갖추지 않았기 때문이다.
   3. BAML의 컴파일러 증명이 그 경직성을 제공한다.

---

10. 재작성 없는 상호운용: 타입 시스템을 진실의 중심으로

Gupta는 아무도 기존 코드를 새 언어로 다시 쓰지 않을 것이라며, BAML이 기존 언어와 어떻게 연결되는지 보여준다.

10.1. 다양한 언어에서 호출 가능한 BAML

1. 지원 언어 범위

   1. Python, TypeScript, Rust, Go, Ruby, Java, 그리고 미래의 언어까지.
   2. BAML 함수를 호출하면 완전히 타입 안전하게 사용할 수 있다.

2. async와 sync의 통합

   1. BAML 자체에는 function coloring(색칠된 함수)이 없다.
   2. 하지만 Python 측에서 calculate와 calculate_async를 모두 생성해 제공한다.
   3. 이는 기존 언어의 비동기 패턴을 존중하면서도 BAML 내부의 단순성을 유지한다.

3. 언어 경계를 넘는 람다와 클로저

   1. Python의 람다, 제네릭, 클로저를 BAML로 넘겨 실행할 수 있다.
   2. 예시: with timeout 함수는 특정 밀리초 안에 작업을 완료하도록 보장한다. 작업이 오래 걸려도 콜백을 안전하게 제어한다.

10.2. 타입 시스템을 불변식의 방패로

1. 타입 시스템은 거짓말하지 않는다
   1. Gupta: "the type system never lies. The type system becomes the absolute center of truth that prevents invariants from entering your codebase."
   2. 언어 경계를 넘을 때도 타입 정보가 그대로 유지되므로, 에이전트가 실수로 불변식을 깨뜨리는 것을 막는다.

---

11. 종합: 전투는 이길 수 있지만 전쟁은 여전히 불확실

Gupta는 마지막으로 자신의 주장을 종합하고, 청중에게 실천을 촉구한다.

11.1. 슬롭과의 전투에서의 승리와 전쟁의 패배

1. 전투는 이길 수 있다

   1. architecture.md, 설계 문서 피드, 의존성 그래프, 에이전트 테스트 하니스를 통해 슬롭을 가두고 빠르게 출시할 수 있다.
   2. BAML은 그 증거다.

2. 전쟁은 여전히 질 수 있다

   1. Gupta: "I think we're still going to lose the war."
   2. 이유: Git, 데이터베이스, 프로그래밍 언어 등 우리가 쓰는 기초 시스템 자체가 부서져 있기 때문이다.

11.2. CI/CD 도입과의 비유

1. 단기적 감속, 장기적 가속
   1. Gupta는 CI/CD가 없는 회사를 예로 든다: 처음 3개월은 느려 보이지만, 그 뒤로 훨씬 빨라진다.
   2. 마찬가지로 에이전트 시대의 프로세스 변화도 단기적 비용을 감수해야 한다.
   3. Gupta: "Our processes have to evolve if we're going to ship at agent speed."

11.3. 최종 메시지: 새로운 기초를 상상하라

1. 실용적 행동

   1. 집에 가서 슬롭 같은 내부 도구를 만들고, 시스템과 프로세스를 더 튼튼하게 만들라.

2. 용기 있는 행동

   1. 가장 용감한 사람들은 기초 시스템을 다시 생각해 보라.
   2. Gupta: "I think we do need a new Git. I think we do need a new database, and yes, I think we need a new programming language."

3. 마지막 한 줄

   1. Gupta: "this is the least amount of slop your codebase will ever have to this day. So just embrace it and start fighting it back."

---

주요 발언 모음

"Fighting slop with slop."

"Slop is just any code you don't read. And whether any of you admit it or not, this is the least amount of slop that your code base will ever have. Cherish it."

"To defeat the slop, we must become the slop."

"The hard part about hiring great engineers is you sadly can't tell them what to do. Some of them want to use Claude, some of them want to use Codex, some of them want to use the latest thing that they just found on Hacker News."

"Code can be slop, writing cannot."

"What took three tool calls when it should have only taken one."

"Why do we turn things to strings when we sort them? This is just slop baked into the language."

"In a world where we don't read all the code, the only way to understand the code is actually by the execution trace."

"docs may lie, the readme will definitely lie, but the code cannot lie."

"No more guessing. There's no unknowns. It's guaranteed to be proven."

"Code is a matter of trust. The reason that we don't use LM code blindly is because we don't trust it yet because the systems underneath them don't have enough rigidity."

"Our processes have to evolve if we're going to ship at agent speed."

"I think we do need a new Git. I think we do need a new database, and yes, I think we need a new programming language."

"this is the least amount of slop your codebase will ever have to this day. So just embrace it and start fighting it back."

---

핵심 데이터 & 수치

• 팀 규모: 약 8명
• BAML 안정성 도달 시간: 2년 미만
• 아키텍처 변경 정체기: 발표 시점 기준 지난 3~4개월간 변경 없음
• 비용 단위 변화: 과거 수천~수만 인간 시간 → 수백만 토큰
• 최근 사례: 발표 하루 전, 엔지니어가 BAML 내부에서 부분적 C 컴파일러를 구현

---

결론 및 시사점

1. 슬롭을 없애려 하지 말고 가두어라: AI가 생성한 코드를 막을 수 없으므로, 그것이 시스템을 망가뜨리지 못하도록 불변식과 도구로 가둔다.
2. 통제 지점을 인간에서 기계로 옮겨라: 코드 리뷰 대신 의존성 그래프, 설계 문서 알림, 에이전트 테스트 하니스가 인간의 판단을 보완한다.
3. 최소한의 불변식만 남겨라: architecture.md처럼 시간이 지나도 변하지 않는 사실만 기록하고, 그 외에는 팀의 자율을 최대화한다.
4. 글의 품질을 강제하라: 코드는 슬롭이 되어도 설계 문서는 그래서는 안 되며, "읽어야만 배포된다"는 제약이 품질을 만든다.
5. 에이전트를 데이터 수집 장치로 써라: Claude의 대화 기록을 마이닝해 버그와 비효율을 측정하고, 언어 기능을 A/B 테스트한다.
6. 기초 시스템의 재설계를 두려워하지 마라: TypeScript·JavaScript의 인간 중심 설계 결정은 에이전트 시대에 맞지 않으며, Git·데이터베이스·언어 자체를 새로 고민해야 한다.
7. 단기적 감속은 장기적 가속을 위한 투자다: CI/CD 도입이 처음에는 느려 보여도 나중에는 훨씬 빨라지듯, 에이전트 워크플로도 마찬가지다.
8. 타입 시스템과 컴파일러 증명이 신뢰의 기초가 된다: ML 생성 코드를 맹신하지 않는 이유는 아래 시스템의 경직성 부족 때문이며, BAML처럼 증명 가능한 언어가 그 격차를 메운다.