생성은 저렴하지만 검토는 비쌉니다: 엉터리 AI 코드 배포를 멈추는 법

원문 제목: [한영자막] 생성은 저렴하지만 검토는 비쌉니다: 엉터리 AI 코드 배포를 멈추는 법
번역 제목: 생성은 저렴하지만 검토는 비쌉니다 — 엉터리 AI 코드 배포를 멈추는 법
URL: https://www.youtube.com/watch?v=utMfI1DXTOE
날짜: 2026-10-14 (원본 발행일)
수집일: 2026-10-15
채널: Tech Bridge
발표자: Gabriel Martinez (Gabo), G2i 엔지니어링 매니저이자 ‘슬롭 워든(slop warden)’

---

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

==AI가 코드를 만들어내는 속도가 인간의 판단·검토·책임지는 속도를 앞지를 때, 결과물은 완성품처럼 보이는 ‘슬롭(slop)’이 된다. 생성량을 늘리는 것이 아니라 사람이 이해하고 검토하고 소유할 수 있는 작업 단위와 시스템 구조를 설계해야 한다.==

• 슬롭은 AI가 만들었다는 사실이 아니라, 생성이 판단을 추월한 상태를 뜻한다.
• 코드 작성 비용은 빠르게 내려가지만, 코드의 의미와 트레이드오프를 이해하는 비용은 내려가지 않는다.
• 빠른 프로토타입은 요구사항 정리, 통합, 수동 테스트, UX 검증이라는 어려운 일이 끝났다는 증거가 아니다.
• 팀의 보상 체계가 PR 개수와 속도를 부추기면 엔지니어는 충분히 판단하기 전에 코드를 병합하게 된다.
• 에이전트 시대에는 관례, 경계, 다이어그램, 작은 리뷰 단위, 명확한 완료 정의가 인간의 인지 부하와 슬롭을 줄이는 장치가 된다.

문제의 핵심은 기계가 나쁜 선택을 했다는 데만 있지 않다. 더 위험한 일은 엔지니어가 선택이 필요한 상황 자체를 알아차리지 못하는 것이다. 모호함과 제약, 예외 상황, 제품의 트레이드오프가 생성 과정에서 매끈하게 덮이면 결과물은 그럴듯해지지만, 무엇을 결정했고 누가 책임지는지는 사라진다. 따라서 AI를 거부하는 대신 생성과 판단 사이의 인간 계층을 보존하고, 그 계층이 실제로 작동하도록 개발 프로세스를 바꿔야 한다.

1. 슬롭의 정체: 완성품처럼 보이는 미완성 사고

슬롭은 AI 산출물의 고정된 시각적 특징이 아니라, 생각이 끝나기 전에 작업물이 끝난 것처럼 보이는 상태다.

1.1. 생성이 판단을 앞지를 때

1. 슬롭의 정의

   1. 판단보다 빠른 생성: 슬롭은 ‘생성(generation)이 판단(judgment)을 앞지를 때’ 발생한다. AI가 만들었다는 사실만으로 모든 결과물을 슬롭이라고 부를 수는 없다.
   2. 미완성 사고의 완성품 외관: 작업물은 완료된 것처럼 보이지만, 그 안의 사고 과정은 아직 끝나지 않았다. 출력은 나왔지만 이해는 나오지 않은 상태다.

2. 모호함과 트레이드오프의 은폐

   1. 추측으로 모호함을 지움: 요구사항이나 도메인이 불명확한 부분을 확인 질문과 설계 판단으로 해결하지 않고, 가장 그럴듯해 보이는 추측으로 채운다.
   2. 우연에 맡긴 선택: 성능·복잡성·유지보수성·UX 같은 트레이드오프를 의식적으로 결정하지 않고 결과에 맡긴다.
   3. 소유권의 부재: 누가 어떤 선택을 했는지, 그 결과를 누가 장기간 책임질지 정해지지 않는다.

1.2. 소프트웨어는 선택의 기록이다

1. 보이지 않게 된 선택

   1. 기술적 선택: 코드 구조, 데이터 모델, 서비스 경계, 구현 패턴은 기술적 판단의 흔적이다.
   2. 제품·운영·사용자 선택: 어떤 기능을 만들지, 어떤 운영 부담을 감수할지, 사용자가 어떤 흐름을 경험할지도 코드에 기록된다.

2. 알아차리지 못한 미지의 문제

   1. 선택할 기회 자체를 놓침: 사람이 선택이 필요한 지점을 인식하지 못하면, 잘못된 선택을 한 것보다 더 심각한 문제가 생긴다. 선택이 있었다는 사실을 모르기 때문에 검토나 수정도 시작할 수 없다.
   2. 엣지 케이스가 발견되지 않음: 제약을 직접 부딪치고 예외를 찾아야 설계가 바뀌는데, 결과물이 미리 매끄럽게 정리되면 그 과정이 생략된다.
   3. unknown unknowns의 잔류: 무엇을 모르는지조차 드러나지 않은 채, 작업물에 포함된 ‘알 수 없었던 문제’가 계속 알 수 없는 상태로 남는다.

3. 엔지니어링과 출력 수용의 차이

   1. 이해와 소유: 선택을 보지 못하면 선택을 소유할 수 없다. 선택을 소유하지 않는다면 엔지니어링을 한 것이 아니라 출력물을 받아들인 것이다.
   2. 코드 머저로의 퇴행: 판단 없이 생성물을 병합 버튼으로 보내는 사람은 시스템을 설계하는 엔지니어라기보다 단순히 코드를 통과시키는 사람에 가까워진다.

1.3. AI를 반대하는 주장이 아니다

1. 에이전트의 실제 능력

   1. 구현 자동화: 에이전트는 코드를 작성하고, 화면을 뼈대부터 만들며, 적절히 조정하면 전체 기능이나 시스템을 구성할 수 있다.
   2. 마법처럼 보이는 속도: 인터넷의 과장된 서사처럼 에이전트가 마법을 부리는 것처럼 보일 수 있다. 12월 25일 이후의 급격한 발전으로 이런 기대가 생긴 것은 이해할 만하다.

2. 자동화할 수 없는 인간의 일

   1. 중요한 것 결정: 무엇이 중요한지, 무엇을 만들지, 무엇을 만들지 않을지 결정하는 일은 남는다.
   2. 모호함 해석: 불완전한 요구사항과 상충하는 목표를 해석하고 질문으로 구체화해야 한다.
   3. 장기 소유와 절제: 시스템을 오래 책임지고 아키텍처 수준에서 절제된 판단을 해야 한다.
   4. 미구축의 판단: 가장 중요한 판단 중 하나는 만들지 않을 것을 아는 일이다.

3. 속도를 늦춰야 하는 이유

   1. AI는 나쁜 도구가 아님: 문제는 AI 자체가 아니라 AI를 둘러싼 ‘취한 듯한(stupor)’ 사용 패턴과 판단의 부재다.
   2. 소버(sober)한 사용: 가능한 일을 모두 빠르게 만들기보다, 생성 속도를 사람의 이해와 검토 속도에 맞추고 과열된 기대를 가라앉혀야 한다.

2. 생성 비용은 내려가도 이해 비용은 내려가지 않는다

AI는 코드를 쉽게 만들지만, 그 코드가 시스템에 추가하는 책임과 복잡성까지 없애주지는 않는다.

2.1. 코드는 자산인 동시에 부채다

1. 무엇이든 만들 수 있는 시대의 우선순위

   1. 구축보다 선택: 만들 수 있는 것이 무한해질수록 무엇을 만들지 결정하는 일이 더 중요해진다.
   2. 스파게티 제품의 팽창: 가능하다는 이유로 거대한 제품과 뒤엉킨 기능을 계속 추가하면, 제품은 실제 문제를 해결하기보다 복잡한 산출물의 집합이 된다.

2. Dijkstra의 관점

   1. 코드 라인은 ‘생산’이 아니라 ‘지출’: 코드 줄 수를 셀 수 있다면 그것을 만들어낸 생산량이 아니라 사용해버린 비용으로 봐야 한다.
   2. AI가 쉽게 만드는 지출: AI는 파일, 추상화, 코드 라인을 더 쉽게 지출하게 만든다. 하지만 생성된 결과의 비용 청구서는 결국 팀이 떠안는다.

3. 이해 비용의 청구서

   1. 혼란: 어떤 코드가 어디에서 작동하는지 알기 어려워진다.
   2. 취약한 흐름: 충분히 이해하지 못한 기능은 작은 변경에도 쉽게 깨진다.
   3. 접근을 꺼리는 기능: 기능은 존재하지만 아무도 전체 동작을 이해하지 못해 수정하기를 두려워한다.
   4. 미로 같은 제품 표면: 기술적으로는 할 수 있는 일이 많아도 사용자는 화면과 경로를 미로처럼 느낀다.

2.2. 좋은 소프트웨어의 실용적 조화

1. 모든 줄을 외우라는 뜻이 아님

   1. 대규모 시스템의 현실: 어떤 한 사람도 거대한 시스템의 모든 세부사항을 머릿속에 담을 수 없다. 모든 줄을 개인적으로 읽고 축복하듯 승인해야 한다는 뜻은 아니다.
   2. 반드시 알아야 할 표면: 핵심 로직, 주요 흐름, 경계, 데이터 모델, 제품 행동은 팀이 이해해야 한다.

2. 도메인을 반영하는 구조

   1. 실용적 조화: 좋은 소프트웨어의 조화는 순수한 미적 취향이 아니라, 코드 구조가 도메인의 형태를 반영하여 사람이 시스템을 예측할 수 있게 하는 실용적 특성이다.
   2. 구조가 있는 코드베이스: 명확한 패턴, 경계, 근거가 있는 코드베이스에서는 에이전트도 더 효과적으로 움직인다.
   3. 진흙 공의 가속: 이미 거대한 진흙 공(big ball of mud)이 된 시스템을 에이전트가 구해주지는 않는다. 오히려 같은 혼란을 더 빠르게 크게 만든다.

3. 컴포넌트 추가와 제품 가치의 분리

   1. 생성 가능성은 필요성의 증거가 아님: 컴포넌트를 하나 더 만들 수 있다는 사실이 제품에 컴포넌트 하나가 더 필요하다는 뜻은 아니다.
   2. 추가 전 질문: 기능을 만들기 전에 이 기능이 해결할 문제, 추가할 운영 부담, 기존 흐름과의 관계를 확인해야 한다.

2.3. B2B 소프트웨어가 미로가 되는 과정

1. 훈련이 필요한 제품

   1. 과도한 비대화: 최악의 B2B ERP처럼 모든 작업에 별도 교육이 필요해질 수 있다.
   2. 탈출구의 남발: 화면마다 12개의 빠져나갈 경로가 있고, 사용자가 무엇을 선택해야 하는지 설명하기 어렵다.

2. 복잡성의 출처를 잃음

   1. 사용자 필요인지 팀의 누적인지: 복잡성이 사용자가 요구한 결과인지, 여러 팀이 계속 기능을 더한 결과인지 아무도 설명하지 못하게 된다.
   2. 이해되지 않는 제품의 비용: 각 기능은 개별적으로 작동하더라도 전체 경험은 일관되지 않고, 교육과 지원 비용이 커진다.

3. 프로토타입이 감추는 마지막 1마일

한 시간 만에 클릭 가능한 애플리케이션이 만들어지는 일은 아이디어를 탐색하는 데 유용하지만, 이해와 검증이 끝났다는 뜻은 아니다.

3.1. ‘작동하는 화면’이 바꾼 기대

1. 프로토타입 생성의 변화

   1. 빠른 외관: 몇 개의 프롬프트가 화면으로 바뀌고, 터미널 세션이 실제처럼 보이는 결과물을 만든다.
   2. 실제 가치가 있을 때도 있음: 어떤 프로토타입은 아이디어를 탐색하는 좋은 방법이고, 때로는 충분히 유용한 수준으로 작동한다.

2. 이해관계자의 오해

   1. 어려운 일이 끝났다는 착각: 코드베이스에서 생활하지 않는 이해관계자는 화면이 나타난 것을 보고 어려운 부분이 끝났다고 생각하기 쉽다.
   2. 속도의 일반화: 소프트웨어가 그렇게 빨리 나타나는 장면을 보면, 실제 소프트웨어도 그 속도로 완성될 수 있다고 기대하게 된다.

3.2. 숙련된 엔지니어의 마지막 1마일

1. 행복한 경로 바깥의 통합

   1. 기능 세트의 결합: 새 기능을 기존 시스템에 응집력 있게 통합하는 작업은 화면을 만드는 것과 다르다.
   2. 요구사항 명확화: 가볍게 적힌 요청을 실제 행동·경계·예외가 있는 명세로 다듬어야 한다.

2. 사람처럼 작동하는지 검증

   1. 수동 테스트: 기능 세트가 실제 사용자가 기대하는 방식으로 동작하는지 직접 확인해야 한다.
   2. UX 품질: 화면이 존재하는 것과 UX가 괜찮은 것은 다르다. 경로가 어색하거나 사용자에게 쓰레기 같은 경험을 주지 않는지 확인해야 한다.

3. 판단이 사는 구간

   1. 코드 읽기: 실제 동작뿐 아니라 구현의 의도와 트레이드오프를 읽어야 한다.
   2. 행동 소유: 테스트 결과를 받아들이고, 누락된 요구사항을 발견하며, 이 기능이 시스템의 일부가 될 자격이 있는지 결정해야 한다.
   3. 마지막 1마일: 가장 시간이 많이 드는 인간의 작업은 생성 이후에 있다. 바로 그 지점에서 판단이 작동한다.

3.3. ‘무료 PR’은 무료가 아니다

1. SQLite 제작자의 PR 비유

   1. 유지보수의 이전: “무료라고 말하지만, 실제로는 나에게 당신을 위해 유지보수하고, 문서화하고, 테스트하고, 앞으로 25년 동안 유지해달라고 요구하는 것이다.”
   2. 장기 책임의 가격: 지금 올리는 PR의 작성 비용이 0원이어도, 누군가는 동작을 이해하고 고치고 설명해야 한다. 그 비용은 사라지는 것이 아니라 다른 사람에게 넘어간다.

2. 생성물의 책임자

   1. 병합보다 중요한 질문: PR을 쉽게 만들어내는 것보다 그 결과를 누가 소유하고, 그 의미와 파급효과에 누가 책임지는지가 중요하다.
   2. 외부 압력의 결합: 이해관계자의 빠른 결과 요구와 ‘슬롭을 대량 생산하는 사람’과 경쟁해야 한다는 압력이 결합하면 슬롭이 훨씬 많이 나온다.

4. 속도 경쟁이 만드는 성과 불안과 잘못된 보상

세부사항을 검토하고 명세를 다듬는 사람은 느려 보이고, 검토 없이 많이 병합하는 사람은 생산적으로 보이는 환경이 판단을 파괴한다.

4.1. 많이 빨리 만드는 사람이 유능해 보이는 구조

1. 나쁜 성과 신호

   1. 검토하지 않는 엔지니어의 외형적 우위: 세부사항을 보지 않고 명세를 정제하지 않으며 디테일에 집중하지 않는 사람은 더 많은 결과물을 더 빨리 낸 것처럼 보인다.
   2. 꼼꼼한 사람의 불리함: 세부사항을 확인하고 한 단계 더 나아가는 사람은 실제로 더 많은 책임을 지지만, 겉으로는 적게 하고 느리게 움직이는 것처럼 보인다.

2. 성과 불안의 전파

   1. PR 속도 압박: 팀 분위기가 엔지니어에게 판단할 수 있는 속도보다 더 빠르게 PR을 병합하라고 압박한다.
   2. 단기 승리: 완전히 이해하지 못한 코드도 일단 PR을 넣는 것이 장기적인 코드 건강성보다 우선된다.

4.2. 개인의 경험이 보여주는 취약성

1. 주변 속도와 비교

   1. 지속적인 불안: 주변 엔지니어가 놀라운 속도로 코드를 병합하면, 자신이 충분히 빨리 움직이지 않는다는 불안이 생긴다.
   2. 검토 수준의 하락: 그 불안 때문에 평소라면 했을 세밀한 검토를 하지 않은 채 코드를 병합할 수 있다.

2. 사람의 한계

   1. 이해하지 못한 코드의 병합: 실제로 완전히 이해하지 못했거나 직접 테스트하지 않은 코드를 병합하는 사례가 발생한다.
   2. 인센티브의 힘: 사람은 보상에 반응한다. PR을 많이, 빨리 내는 것이 보상받는다면 선의와 전문성만으로 그 압력을 계속 거스르기 어렵다.

4.3. 보상 체계를 바꾸는 기준

1. 가치를 중심에 두기

   1. 우아하고 잘 분해된 설계: 보상은 생성된 코드의 양이 아니라 가치, 우아하게 분해된 구조, 실용적인 시스템 설계에 연결되어야 한다.
   2. 테스트·평가 하니스의 명료성: 무엇을 어떻게 검증했는지 분명한 테스트와 평가 하니스를 만드는 일도 성과로 인정해야 한다.

2. 대규모 PR을 경계하기

   1. 수천 줄의 PR 문제: 수천 줄에 달하는 변경에서 사람이 모든 중요한 부분을 완전히 이해할 방법은 사실상 없다.
   2. 검토 가능한 최소 단위: 엔지니어의 역할은 요구사항을 가장 단순한 단위로 분해하여 이해 가능한 코드 표면과 통제 가능한 코드베이스를 만드는 것이다.

5. 생성량이 아니라 평가 가능성을 최적화하기

AI는 더 많은 문자를 더 빠르게 만들 수 있지만, 사람이 평가할 수 있는 양보다 많이 만들면 팀을 가속하는 대신 평가 병목을 만든다.

5.1. ‘더 많이, 더 빠르게’라는 압박의 실체

1. 토큰 생산 속도와 인간의 시간

   1. 일자리 대체 서사: AI가 일자리를 없애고 엔지니어가 토큰이 생성되는 속도로 움직여야 한다는 압력이 커졌다.
   2. 문자의 증가: 실제로 늘어나는 것은 반드시 가치가 아니라 사람의 시간을 먹는 문자와 결과물의 양일 수 있다.

2. 10개 불릿이 20쪽 문서가 되는 사례

   1. 입력: 가볍게 유지하려고 한 10개의 범위 불릿과 몇 개의 사용자 여정을 건넨다.
   2. 출력: AI가 화려한 문장으로 작성된 20쪽짜리 문서를 돌려준다.
   3. 검토 부담: 문서가 매끈해 보일수록 그 안에 실제 사고가 들어 있는지 판단하는 데 몇 시간이 걸린다.

3. 문제 해결이 아니라 문제 확장

   1. 모호함의 재이전: 작업을 수행하는 사람이 해결했어야 할 모호함이 해소되지 않은 채 더 큰 산출물로 바뀌어 다른 이해관계자에게 넘어간다.
   2. 코드에서의 동일한 패턴: 모호한 작업은 거대한 PR이 되고, 작은 기능은 파일 더미가 된다.
   3. 완료의 외형: 출력물은 완료된 형태를 갖지만 실제 작업은 검토자에게 막 이동했을 뿐이다.

5.2. 생성은 저렴하고 평가는 비싸다

1. 평가 비용의 비대칭

   1. 값싼 생성: AI는 몇 문장만으로 코드, 문서, 화면을 대량으로 생성할 수 있다.
   2. 비싼 평가: 사람은 그 결과가 요구사항을 충족하는지, 예외를 처리하는지, 기존 설계와 맞는지, 유지할 가치가 있는지를 확인해야 한다.

2. 병목의 판별

   1. 가속의 조건: 생성된 양이 사람이 평가할 수 있는 양 안에 있고, 결과가 이해 가능한 단위로 나뉘어 있어야 팀이 빨라진다.
   2. 병목의 조건: AI가 사람이 가능한 평가량보다 많이 만들면 팀은 가속된 것이 아니라 평가 병목을 만든 것이다.

5.3. 과장된 새로움과 잊힌 기본기

1. Ralph loop의 사례

   1. 새로운 에이전트 돌파구라는 포장: 온라인에서 Ralph loop가 새로운 에이전트 혁신처럼 소개되지만, 본질은 while 루프에 가깝다.
   2. 기본기의 재포장: 이미 알려진 단순한 패턴을 새로운 천재적 아이디어처럼 소비하면, 기존의 소프트웨어 지혜가 잊힌다.

2. 라인 수와 토큰 수는 쓰레기 지표

   1. 기존의 교훈: 코드 라인 수가 생산성 지표로 부적절하다는 사실은 오래전부터 알려져 있었다.
   2. 토큰으로의 치환: 엔지니어가 태운 토큰 수가 많을수록 더 생산적이라는 식으로 같은 오류를 반복해서는 안 된다.

3. 작은 원자적 단위의 회복

   1. 이전의 좋은 방식: 기능을 머릿속에 담고 실제로 리뷰할 수 있을 만큼 작은 원자적 조각으로 나누었다.
   2. 현재의 위험: 이제는 두 문장만 입력하고 충분히 생각하지 않은 기능 세트 전체를 한 번에 돌려받으려 한다.
   3. 핵심 질문: 무엇을 요구하는지, 어떤 판단을 AI에 넘기는지, 받은 결과를 어떤 단위로 이해할지 먼저 알아야 한다.

6. 에이전트 시대의 구조: 인간이 검토할 수 있는 표면 만들기

AI가 구현 세부사항을 추상화할수록, 사람은 코드의 모든 줄보다 시스템의 모양과 경계를 더 선명하게 볼 수 있어야 한다.

6.1. 60년의 소프트웨어 지혜는 유효하다

1. 변하지 않는 원칙

   1. 구성 가능한 코드: 작은 부분을 조합해 전체를 이해할 수 있는 구조는 여전히 필요하다.
   2. 좋은 패턴과 실천: 명확한 설계 패턴, 테스트, 경계, 유지보수 관행은 AI 때문에 폐기되지 않는다.

2. 에이전트가 코드를 쓰는데도 모양이 중요한 이유

   1. 구현 추상화의 방향: 소프트웨어는 기계어에서 어셈블리, C, Java, Ruby로 올라오며 구현 세부사항을 점점 추상화해왔다.
   2. 인간 행복을 위한 추상화: Ruby처럼 프로그래머의 행복을 주요 설계 목표로 삼은 언어도 있다. AI는 명령형 구현의 일부를 더 추상화할 수 있다.
   3. 응집력은 자동 생성되지 않음: 구현을 사람이 직접 쓰지 않는다고 해서 시스템이 어떻게 하나로 결합되는지 이해할 필요가 사라지는 것은 아니다.

6.2. 다이어그램은 장식이 아니라 압축된 검토 표면이다

1. 사람이 보아야 할 구조

   1. 서비스 경계: 어떤 책임이 어느 서비스에 속하는지 보여준다.
   2. 데이터 흐름: 정보가 어디에서 와서 어떤 변환을 거쳐 어디로 가는지 보여준다.
   3. 상태 전이: 시스템이 어떤 조건에서 상태를 바꾸는지 드러낸다.
   4. 실패 모드: 정상 경로가 아닌 경우 무엇이 실패하고 어떻게 복구하는지 나타낸다.

2. 코드를 압축하는 방식

   1. 가독성 있는 모양: 수천 줄의 구현 세부사항은 시스템의 전체 형태를 가릴 수 있지만, 좋은 다이어그램은 그 형태를 한눈에 보여준다.
   2. 잎으로 밀어낸 세부사항: 주요 프로세스와 워크플로를 검토 가능한 중심 표면으로 남기고, 구현 세부사항은 말단으로 밀어낸다.
   3. 선언적 코드와 구조 패턴: 사람이 추론할 수 있는 계층을 만드는 선언적 코드와 아키텍처 패턴을 선호해야 한다.

3. 최적화 대상

   1. 코드 생성 자체가 아님: 목표는 더 많은 생성 코드가 아니다.
   2. 인간의 지식과 이해: 시스템에 관한 인간의 지식, 이해, 검토 가능성을 중심으로 최적화해야 한다.

6.3. 인지 부하를 줄이는 관례와 표준

1. 인지 부하의 정의

   1. 변경 전 지불하는 세금: 엔지니어가 의미 있는 변경을 하기 전에 코드가 어디에 있는지, 어떤 패턴을 따라야 하는지, 올바른 구현이 무엇인지 알아내는 데 쓰는 시간이 인지 부하다.
   2. AI가 자동으로 없애지 못하는 비용: 에이전트가 이 비용을 제거하지는 않는다. 통제하지 않으면 오히려 더 키운다.

2. 스타일의 폭발

   1. 다섯 개의 그럴듯한 패턴: 에이전트는 서로 다른 스타일의 그럴듯한 구현 다섯 가지를 만들 수 있다.
   2. 의도 역추론: 검토자는 코드뿐 아니라 그 코드가 왜 그렇게 만들어졌는지까지 역으로 추론해야 한다.

3. 슬롭을 숨길 공간 줄이기

   1. 관례와 표준: 반복되는 선택을 줄이고, 모든 사람이 예상할 수 있는 기본 경로를 만든다.
   2. 문서화된 흐름과 작은 표면: 시스템 흐름을 문서화하고, 리뷰 단위를 작게 유지한다.
   3. 소유권 경계와 완료 정의: 누가 책임지는지, 완료가 무엇을 의미하는지 명확히 한다.
   4. 명확한 경로: 올바른 경로가 분명할수록 에이전트와 사람의 임의 추측이 줄고 슬롭이 숨을 공간도 줄어든다.

6.4. Rails가 보여주는 ‘결정 표면’의 축소

1. Rails의 가치

   1. 관례로 오버헤드 축소: 같은 개념을 구조화하는 방법이 열 가지가 아니라 하나로 수렴한다.
   2. 완벽함보다 이해 가능성: 모든 사람의 주관적 취향에 완벽하지 않아도, 일관되고 이해되며 실제로 작동한다.

2. 4년 뒤에도 남아 있던 패턴

   1. 복귀 경험: Rails를 처음 사용한 시기와 두 번째로 접한 시기 사이에 4년의 공백이 있었다.
   2. 즉시 의도 파악: 돌아왔을 때 패턴과 사실상의 라이브러리가 그대로여서, 별도로 아키텍처를 해석하지 않고도 코드베이스에 바로 들어갈 수 있었다.
   3. 프로젝트 간 이동: 관례가 안정적이면 엔지니어가 프로젝트를 옮길 때 램프업 비용이 작다.

3. 에이전트 개발과의 연결

   1. JavaScript 생태계와의 대비: 여러 방법이 경쟁하는 환경보다, 한 가지 올바른 방식이 분명한 환경이 에이전트 개발에 유리하다. 에이전트가 선택지의 폭에 혼란을 겪지 않기 때문이다.
   2. Rails Doctrine: Rails의 핵심 기둥인 ‘프로그래머의 행복을 위해 최적화(Optimized for programmer happiness)’와 ‘설정보다 관례(Convention over configuration)’는 반복 결정을 없애고 시작 장벽을 낮춘다.
   3. 인지 부하의 제거: 관례는 매번 새로운 선택을 하는 대신 이미 합의된 경로를 따르게 하여 사람과 에이전트의 인지 부하를 줄인다.

7. Ork: 더 많은 에이전트가 아니라 판단을 보존하는 오케스트레이션

반복되는 슬롭 방지 작업을 개발 흐름에 내장하기 위해 Ork가 만들어졌다.

7.1. Ork를 만든 문제의식

1. 빠진 것은 에이전트가 아니었다

   1. 반복된 실패 패턴: AI가 코드를 생성하는 능력은 빠르게 좋아졌지만, 그 주변의 규율은 계속 빠져 있었다.
   2. 인간 프로세스의 반복: 계획, 리뷰, 적대적 검증, 컨텍스트 관리 같은 인간의 프로세스를 슬롭과 싸우기 위해 매번 반복해야 했다.

2. 만들지 않은 것

   1. 에이전트 수의 증대가 목표가 아님: Ork는 단순히 더 많은 에이전트를 투입하기 위해 만들어진 것이 아니다.
   2. 판단 자동화가 아님: 엔지니어링 판단을 자동화해 인간의 책임을 없애려는 마법 상자도 아니다.

7.2. 규율을 워크플로에 넣기

1. 반복할 인간 프로세스

   1. 작업 분해: 요구를 이해 가능한 조각으로 나눈다.
   2. 컨텍스트 관리: 에이전트가 필요한 정보와 범위를 통제한다.
   3. 선택지 비교: 가능한 방법의 트레이드오프를 따져본다.
   4. 진입 방식 검증: 결과물이 팀이 여전히 추론할 수 있는 방식으로 코드베이스에 들어가는지 확인한다.

2. 생성 이후의 책임

   1. 사람이 책임을 유지함: Ork는 에이전트가 더 많은 일을 하게 하면서도 정확성에 대한 인간의 책임을 보존하는 시스템이다.
   2. 결과물의 기준: 생성된 코드의 양이 아니라, 생성 이후에도 응집력 있고 테스트되며 유지보수 가능하고 누군가 소유하는 소프트웨어를 목표로 한다.

7.3. 미래의 개발 방식

1. 거부할 미래상

   1. 더 빠른 바이브 코딩: 미래가 단순히 바이브 코딩을 더 빠르고 잘하는 것은 아니다.
   2. 양의 경쟁: 토큰, 파일, PR, 코드 라인을 늘리는 경쟁은 생성과 평가의 불균형만 키운다.

2. 지향할 미래상

   1. 판단이 있는 오케스트레이션: 에이전트의 실행력과 인간의 판단을 워크플로 수준에서 결합해야 한다.
   2. 소유 가능한 시스템: 구현 세부사항이 자동화되어도 시스템의 모양, 경계, 실패, 제품적 의미를 사람이 이해하고 책임져야 한다.
   3. 마지막 경고: “엉성해지지 말라(Don’t get sloppy)”는 말은 생성 속도가 판단을 앞지르지 않도록 하라는 결론이다.

주요 발언 모음

“슬롭은 AI가 생성한 코드가 아니다. 슬롭은 생각이 끝나기 전에 완성된 것처럼 보이는 출력이다.”

“모호함은 추측으로 지워졌고, 트레이드오프는 우연에 맡겨졌으며, 소유권은 가져가지 않은 작업물이다.”

“생성은 저렴하지만 평가는 비싸다. AI가 사람이 평가할 수 있는 양보다 더 많이 만들어낸다면, 팀을 가속한 것이 아니라 병목을 만든 것이다.”

“코드 라인은 생산된 줄이 아니라 지출된 줄로 보아야 한다.”

“에이전트가 코드를 쓴다고 해서 코드의 모양이 중요하지 않게 되는 것은 아니다.”

“목표는 생성된 코드를 더 많이 배포하는 것이 아니다. 생성 이후에도 응집력 있고, 테스트되고, 유지보수 가능하며, 누군가 소유하는 소프트웨어를 배포하는 것이다.”

“미래는 바이브 코딩을 더 잘하고 더 빠르게 하는 것이 아니다. 미래는 판단이 있는 오케스트레이션이다.”

핵심 데이터 & 수치

• 4년: Rails를 처음 사용한 시기와 두 번째로 사용한 시기 사이의 공백. 4년 뒤에도 패턴과 사실상의 라이브러리가 유지되어 즉시 의도를 파악할 수 있었다.
• 12개: 복잡한 B2B 소프트웨어의 한 화면에 존재할 수 있는 탈출구 수를 설명하는 비유. 기능은 많지만 사용자가 무엇을 해야 하는지 아무도 설명하지 못하는 상태를 상징한다.
• 25년: ‘무료 PR’이 실제로 떠넘기는 유지보수·문서화·테스트 책임의 기간을 보여주는 SQLite 제작자의 비유.
• 10개 불릿 → 20쪽 문서: 가볍게 적은 범위와 사용자 여정이 AI에 의해 화려한 장문 산출물로 부풀어 검토자의 시간을 소모하는 사례.
• 수천 줄 PR: 한 사람이 모든 중요한 변경 사항을 완전히 이해하기 어렵기 때문에 검토 단위를 더 작게 나눠야 하는 경고의 기준.
• 60년의 소프트웨어 지혜: AI가 등장해도 구성 가능한 코드, 좋은 패턴, 견고한 실천이 무효화되지 않았다는 주장.
• 12월 25일 이후: 급격한 AI 발전으로 에이전트가 마법처럼 보이게 된 시점을 설명하는 언급.

결론 및 시사점

1. AI가 생성한 코드인지 판별하는 데만 매달리지 말고, 생성 과정에서 모호함·제약·트레이드오프·소유권이 실제로 다뤄졌는지 확인해야 한다.
2. 기능을 만들 수 있다는 사실과 제품에 그 기능이 필요한지는 분리해서 판단해야 한다.
3. 핵심 흐름·경계·데이터 모델·제품 행동은 사람이 이해할 수 있는 검토 표면으로 남겨야 한다.
4. 빠른 프로토타입을 완성품으로 오해하지 않도록 통합, 요구사항 명확화, 수동 테스트, UX 검증을 별도의 작업으로 계획해야 한다.
5. PR 개수와 코드·토큰·문자 수를 생산성 지표로 삼으면 생성량만 늘고 평가 병목이 커진다.
6. 작고 원자적인 작업 단위, 명확한 관례, 다이어그램, 테스트·평가 하니스, 명확한 완료 정의가 에이전트 시대의 안전장치다.
7. 보상은 속도보다 가치, 우아하고 실용적인 설계, 명료한 검증, 장기적인 코드 건강성에 연결해야 한다.
8. AI의 미래는 인간의 판단을 제거하는 자동화가 아니라, 인간이 판단과 소유권을 유지하면서 에이전트의 실행력을 활용하는 오케스트레이션이다.

핵심 요약 (20줄)

1. 슬롭은 AI가 만든 코드가 아니라 생성이 인간의 판단을 앞질러 완성품처럼 보이는 미완성 작업물이다.
2. 슬롭에서는 모호함이 질문이 아니라 추측으로 지워지고 트레이드오프가 우연에 맡겨진다.
3. 소프트웨어는 기술·제품·운영·사용자 선택의 기록이므로 선택을 보지 못하면 책임질 수도 없다.
4. 가장 위험한 상황은 잘못된 선택보다 엔지니어가 선택 자체가 필요했다는 사실을 알아차리지 못하는 경우다.
5. 에이전트는 코드와 화면을 만들 수 있지만 무엇을 만들지와 무엇을 만들지 않을지는 대신 결정할 수 없다.
6. 코드 작성 비용이 내려가도 핵심 로직과 경계와 데이터 모델을 이해하는 비용은 내려가지 않는다.
7. 이미 진흙 공이 된 시스템에 에이전트를 투입하면 혼란을 제거하기보다 더 크고 빠른 진흙 공을 만든다.
8. 코드 라인은 생산량이 아니라 팀이 지출하고 장기적으로 책임져야 하는 비용으로 보아야 한다.
9. 한 시간짜리 프로토타입은 아이디어 탐색에는 유용하지만 통합과 요구사항과 테스트가 끝났다는 증거는 아니다.
10. 이해관계자는 화면이 나타난 것을 보고 실제로 어려운 마지막 1마일까지 끝났다고 오해하기 쉽다.
11. 수천 줄의 PR은 사람이 핵심 변경을 모두 이해하기 어렵게 하므로 작업을 검토 가능한 크기로 나눠야 한다.
12. 속도만 보상하는 팀에서는 꼼꼼한 엔지니어가 느려 보이고 검토하지 않는 엔지니어가 생산적으로 보인다.
13. 생성량이 사람이 평가할 수 있는 양을 넘으면 AI는 팀을 가속하는 대신 평가 병목을 만든다.
14. 열 개의 범위 불릿이 화려한 스무 쪽 문서가 되는 일은 문제 해결이 아니라 검토 부담의 확장이다.
15. 코드 라인 수나 소모 토큰 수는 오래전부터 부적절했던 생산성 지표를 새 이름으로 반복하는 것에 불과하다.
16. 구성 가능한 코드와 좋은 패턴과 견고한 실천이라는 수십 년의 소프트웨어 지혜는 AI 시대에도 유효하다.
17. 다이어그램은 서비스 경계와 데이터 흐름과 상태 전이와 실패 모드를 압축해 인간이 검토할 표면을 만든다.
18. 관례와 표준과 작은 리뷰 단위와 소유권 경계와 완료 정의는 슬롭이 숨을 공간을 줄인다.
19. Rails는 결정 표면을 줄여 사람이 프로젝트 사이를 이동하고 에이전트가 일관된 경로를 따르기 쉽게 만든다.
20. AI 시대의 목표는 생성 코드를 더 많이 배포하는 것이 아니라 판단과 함께 오케스트레이션하여 응집력 있고 검증되고 소유 가능한 소프트웨어를 만드는 것이다.