생성은 싸고 검토는 비싸다: AI Slop을 막는 엔지니어링

URL: https://www.youtube.com/watch?v=6qkzlT962es 날짜: 2026-10-10 채널: aiDotEngineer

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

==AI가 코드를 빠르게 생성하는 시대에 엔지니어링의 핵심은 더 많은 코드를 내보내는 일이 아니라, 사람이 판단·이해·검토·소유할 수 있는 형태로 소프트웨어를 만드는 일이다.==

• 생성 속도가 판단 속도를 앞지르면 결과물은 완성된 것처럼 보이지만 요구사항의 모호성, 트레이드오프, 엣지 케이스가 해결되지 않은 채 남는다.
• AI가 만들어내는 코드·문서·파일의 양이 사람이 평가할 수 있는 양을 넘으면 생산성이 올라가는 것이 아니라 평가가 병목이 된다.
• 좋은 구조, 명확한 경계, 일관된 관례, 작은 검토 단위, 다이어그램, 책임 소재가 에이전트 시대에도 인간의 이해와 장기적 유지보수를 지탱한다.

AI는 나쁜 도구가 아니며 코드 작성·화면 스캐폴딩·기능 구현을 크게 가속할 수 있다. 그러나 무엇을 만들지, 모호한 요구사항을 어떻게 해석할지, 어떤 트레이드오프를 선택할지, 무엇을 만들지 않을지는 여전히 인간의 판단 영역이다. `Slop`은 AI가 생성했다는 사실 자체가 아니라 생성이 판단을 앞질러 이해와 소유권이 빠진 결과물이다.

1. Slop의 정의와 진짜 위험

Slop은 AI 산출물의 출처가 아니라 판단 부재로 규정해야 한다.

1.1. 완성된 모양과 끝나지 않은 사고

1. Slop의 본질

   1. 판단보다 빠른 생성: Slop은 generation이 judgment보다 앞설 때 생긴다. 단순히 AI가 생성한 코드 전체를 Slop이라고 부르는 객관적 판별 대상이 아니다.
   2. 미완성 사고의 완성된 외관: 결과물이 끝난 것처럼 보이지만, 그 안의 모호성은 추측으로 해소되고 트레이드오프는 우연에 맡겨지며 누가 책임질지도 정해지지 않는다.
   3. 이해 없는 산출: 출력물은 만들어졌지만 무엇을 만들었는지에 대한 이해가 따라오지 않는다.

2. 발견되지 않은 선택이 만드는 위험

   1. 선택의 존재 자체를 놓침: 기계가 나쁜 선택을 했다는 사실보다 엔지니어가 선택해야 할 지점이 있었다는 것조차 알아차리지 못하는 일이 더 위험하다.
   2. 미지의 미지(unknown unknowns): 모호성을 직접 부딪쳐 해결하지 않고 제약을 경험하지 않으며, 설계를 바꿀 엣지 케이스를 발견하지 않으면 결과물 표면이 매끄러워진 만큼 중요한 위험은 계속 감춰진다.
   3. 소프트웨어의 기록성: 소프트웨어는 기술적 선택, 제품 선택, 운영 선택, 사용자 대면 선택을 기록한다. 선택을 보지 못하면 그 선택을 소유할 수 없고, 소유하지 못하면 엔지니어링이 아니라 출력물을 받아들이는 일에 그친다.

1.2. AI를 거부하지 않는 이유와 인간의 고유 역할

1. AI에 대한 균형 잡힌 전제

   1. AI는 나쁜 도구가 아님: 2024년 12월 25일 이후의 발전을 고려하면 현재의 열광과 혼란에 이른 과정은 이해할 수 있다. 문제는 AI가 아니라 속도를 다시 조절하고 정신을 차리는 일이다.
   2. 에이전트의 실제 능력: 에이전트는 코드를 작성하고, 화면을 스캐폴딩하고, 적절히 조정하면 전체 기능이나 시스템까지 만들 수 있다.
   3. 과장된 마법의 인상: 에이전트가 마법처럼 보인다는 인터넷의 인상은 인간이 맡아야 할 판단과 책임을 없애지 않는다.

2. 대체할 수 없는 인간의 일

   1. 중요도 결정: 무엇이 중요한지와 무엇을 만들지 않을지를 결정해야 한다.
   2. 모호성 해석: 요구사항과 문제의 경계를 해석하고, 불완전한 조건 속에서 의도와 우선순위를 정해야 한다.
   3. 장기 소유: 시스템을 오랫동안 운영할 사람으로서 구조와 결과를 책임져야 한다.
   4. 절제와 아키텍처 판단: 시스템 아키텍처 수준에서 판단과 절제를 행사해야 하며, 가능한 모든 것을 만들지 않는 것이 특히 중요하다.

2. 코드 생성 비용 하락과 이해 비용의 고정

생성 가능한 것이 많아질수록 무엇을 만들지 결정하는 능력이 더 중요해진다.

2.1. 코드가 곧 부채이자 청구서라는 관점

1. 무한한 가능성이 만드는 과잉 제품

   1. 스파게티 제품: 무엇이든 만들 수 있다는 흥분이 거대한 `spaghetti product`와 무의미한 기능을 낳는다.
   2. 코드 한 줄의 책임: 작성한 모든 코드 줄은 liability이며, 가장 좋은 코드는 아예 존재하지 않는 코드다.
   3. 생성 비용과 이해 비용의 비대칭: AI로 코드 생성 비용은 떨어졌지만 소프트웨어를 이해하는 비용은 떨어지지 않았다.

2. 전체 코드를 한 사람이 읽어야 한다는 뜻은 아님

   1. 현실적인 이해 기준: 대규모 시스템의 모든 세부사항을 한 사람이 머릿속에 담을 수 없다는 사실은 예전부터 당연했다. 모든 줄을 따로 읽고 승인하고 이해해야 한다는 뜻은 아니다.
   2. 반드시 이해해야 하는 층: 핵심 로직, 주요 흐름, 경계, 데이터 모델, 제품 동작은 이해해야 한다.
   3. 도메인과 코드의 조화: 좋은 소프트웨어의 조화는 장식적 미학이 아니라 실용적 일관성이다. 코드는 도메인의 형태를 반영해야 하며, AI는 엉킨 시스템에 자동으로 일관성을 부여하지 않는다.

2.2. 구조가 있는 코드베이스와 진흙공

1. 에이전트가 잘 작동하는 조건

   1. 명확한 구조: 구조, 패턴, 분명한 경계, 설계 근거가 있는 코드베이스에서는 에이전트가 더 효과적으로 움직인다.
   2. 일관된 판단 공간: 에이전트가 따라갈 수 있는 구조가 있으면 생성된 구현이 기존 시스템과 연결될 가능성이 높아진다.

2. Big Ball of Mud의 확대

   1. 구조 부재의 증폭: 이미 `big ball of mud`인 시스템에서 에이전트는 진흙에서 구해주지 않는다. 같은 진흙공을 더 크고 빠르게 만든다.
   2. 컴포넌트 증식의 함정: 컴포넌트를 하나 더 생성할 수 있다는 사실은 제품에 컴포넌트가 하나 더 필요하다는 뜻이 아니다.
   3. 라인 수가 아니라 지출로 보기: Dijkstra가 말한 것처럼 코드 줄 수를 생산된 줄이 아니라 지출한 줄로 보면, 코드·파일·추상화·복잡성은 모두 건설 비용이다.
   4. 결국 팀이 청구서를 지불함: AI가 줄을 쉽게 지출하게 만들어도 혼란, 취약한 흐름, 아무도 손대기 싫은 기능, 미로 같은 제품 화면이라는 청구서는 팀이 떠안는다.

2.3. 복잡한 B2B 제품의 사례

1. 복잡성이 사용자 요구인지 확인하기

   1. 훈련이 필요한 모든 작업: 최악의 B2B 소프트웨어처럼 모든 작업에 교육이 필요할 정도로 복잡해질 수 있다.
   2. 탈출구가 열두 개인 화면: 모든 화면에 12개의 탈출구가 있고, 그 복잡성이 사용자의 필요 때문인지 팀이 계속 무언가를 추가했기 때문인지 아무도 설명하지 못하는 상태가 발생한다.

2. 책임성(Accountability)

   1. 산출물에 대한 소유: 팀은 자신이 만드는 작업과 제품을 책임져야 한다.
   2. 강화와 연결: 책임성을 긍정적·부정적 강화와 연결할 방법이 있어야 한다.
   3. 검토의 효과: 누군가 자신의 결과물을 검토한다는 사실만으로도 엔지니어는 세부사항에 조금 더 주의를 기울이고 꼼꼼해진다.
   4. 가시적인 지표: 작업 산출물의 각 단위에 대해 책임성 지표를 보이게 만들면 이러한 주의를 강화할 수 있다.

3. 한 시간짜리 프로토타입이 숨기는 마지막 1마일

클릭 가능한 프로토타입은 탐색에는 유용하지만 제품 완성의 증거로 오해되기 쉽다.

3.1. 기대치가 바뀌는 과정

1. 즉시 만들어지는 애플리케이션

   1. 한 시간의 구매 가능한 코드: 오늘날 누구나 한 시간 안에 코드를 구매해 애플리케이션을 만들고 작동하는 클릭형 프로토타입을 얻을 수 있다.
   2. 프롬프트와 터미널의 인상: 몇 개의 프롬프트가 화면으로 바뀌고 터미널 세션이 실제처럼 보이는 결과를 만들어내면 소프트웨어 전체가 그렇게 빨리 만들어진다고 믿기 쉬워진다.
   3. 탐색 도구로서의 가치: 때로는 프로토타입이 아이디어를 탐색하기에 훌륭하고 실제로 쓸 만큼 유용하다.

2. 이해관계자의 오해

   1. 완료 착시: 코드베이스에 살지 않는 이해관계자는 프로토타입을 보고 어려운 일이 끝났다는 증거로 받아들인다.
   2. 행복한 경로 밖의 작업 누락: 실제로 뛰어난 엔지니어가 가치를 만드는 지점은 happy path 바깥에 있다.

3.2. 인간 판단이 필요한 마지막 단계

1. 통합과 요구사항

   1. 기능 집합의 응집적 통합: 새로운 기능 묶음을 기존 시스템에 일관되게 통합해야 한다.
   2. 요구사항 명확화: 모호한 요구사항을 분해하고 무엇이 필요한지 확인해야 한다.

2. 검증과 제품 판단

   1. 수동 테스트: 실제 사람이 기대하는 방식으로 기능이 작동하는지 직접 테스트해야 한다.
   2. UX 품질 확인: 사용자 경험이 완전히 망가져 있지 않은지 확인해야 한다.
   3. 마지막 1마일의 판단: 코드를 읽고 동작을 테스트하며 트레이드오프와 빠진 요구사항을 확인하고 이 기능이 시스템의 일부가 될 자격이 있는지 결정해야 한다.

3.3. 무료 PR이라는 착각

1. SQLite 창시자의 지적

   1. 무료가 아닌 이유: 풀 리퀘스트를 공짜라고 부르면 안 된다. 누군가 그 코드를 대신 유지보수하고 문서화하고 테스트하며 앞으로 25년 동안 관리해야 하기 때문이다.
   2. 장기 책임의 이전: PR을 빠르게 던지는 사람과 그 결과를 장기적으로 소유해야 하는 사람은 다를 수 있다.

2. PR을 던지는 속도와 책임의 간극

   1. 쉬운 생성: PR을 `yeet`하는 일은 쉽지만 그 코드가 시스템에 들어온 뒤의 책임자는 따로 필요하다.
   2. 파급효과의 소유: 코드가 만들어내는 장기적 결과와 부작용을 누가 책임질지 결정하지 않으면 생성 속도는 곧 부채가 된다.

4. 인센티브가 만들어내는 성능 불안과 Slop

빠르게 많이 병합하는 행동을 보상하면 판단보다 병합이 앞서게 된다.

4.1. 외부 압력과 경쟁 압력

1. 속도 경쟁의 구조

   1. 이해관계자 압력: 이해관계자의 외부 압력과 Slop을 만드는 경쟁자와의 경쟁이 결합하면 Slop이 대량으로 생긴다.
   2. 나쁜 엔지니어가 더 빨라 보이는 현상: 세부사항을 검토하지 않고 명세를 다듬지 않으며 디테일에 주의를 기울이지 않는 사람이 더 많이, 더 빠르게 생산하는 것처럼 보인다.
   3. 좋은 엔지니어의 역설: 세부사항을 살피고 기대 이상으로 일하는 사람은 상대적으로 덜 하고 느리게 움직이는 것처럼 보인다.

2. 팀 내 전파

   1. 성과 불안(performance anxiety): 동료들이 놀라운 속도로 PR을 병합하면 자신이 충분히 빨리 움직이지 못한다는 불안이 생긴다.
   2. 판단보다 빠른 병합: 이 불안은 엔지니어가 충분히 이해하거나 평소 수준으로 검토하기 전에 코드를 병합하게 만든다.
   3. 인간적 취약성: 발표자도 주변 엔지니어들이 빠르게 병합하는 모습을 보고 자신이 뒤처진다는 불안을 느꼈고, 그 결과 평소보다 낮은 수준의 세부 검토로 코드를 병합한 경험이 있다.

4.2. 단기 승리와 장기 각성

1. 위험한 병합 습관

   1. 이해하지 않은 코드: 완전히 이해하지 못했거나 직접 테스트하지 않은 코드를 병합하는 사례가 실제로 있다.
   2. 인센티브의 지배: 모든 사람은 인센티브에 이끌리므로 PR 개수를 늘리는 행동에 보상하면 심각한 반작용을 맞게 된다.
   3. 단기 목표의 우위: PR을 일단 넣는 단기적 성과가 장기적 코드 건강성보다 중요하게 취급된다.

2. 바람직한 보상 기준

   1. 가치 중심: 보상은 단순한 산출량이 아니라 실제 가치 생산을 중심으로 설계해야 한다.
   2. 우아하고 실용적인 설계: 우아하고 잘 분해된 실용적 시스템 설계를 보상해야 한다.
   3. 명확한 테스트와 평가 장치: 테스트와 평가 하니스가 얼마나 명확한지도 보상 대상이 되어야 한다.

4.3. 거대한 PR을 분해해야 하는 이유

1. 수천 줄 PR의 한계

   1. 인간 검토의 불가능성: 수천 줄짜리 PR의 중요한 부분을 사람이 완전히 이해하는 것은 현실적으로 불가능하다.
   2. 검토 단위의 문제: PR 크기가 커질수록 핵심 변경, 부수적 변경, 누락된 요구사항을 구분하기 어려워진다.

2. 새로운 세계의 엔지니어링

   1. 요구의 단순 분해: 엔지니어는 요구사항을 가장 단순한 조각으로 분해해 이해 가능성을 높여야 한다.
   2. 작은 코드 표면: 더 단순한 코드 표면과 통제 가능한 코드베이스를 만들어야 한다.
   3. 토큰 생산량과 가치의 분리: AI가 일자리를 없애고 엔지니어가 토큰 생성 속도로 움직여야 한다는 압력은 생산량을 가치로 착각하게 만든다.

5. 생성은 싸고 평가는 비싸다

AI가 만드는 양이 사람이 평가할 수 있는 양보다 많아지면 가속이 아니라 병목이 된다.

5.1. 문서와 코드에서 반복되는 패턴

1. 문서가 문제를 확장하는 경우

   1. 가벼운 입력: 10개의 범위 bullet과 몇 개의 사용자 여정처럼 의도적으로 가벼운 요구를 준다.
   2. 20페이지의 출력: AI는 그 요구를 20페이지짜리 문서로 돌려줄 수 있으며, 화려한 문장으로 매우 정교해 보일 수 있다.
   3. 검토자에게 돌아온 모호성: 이제 검토자는 그 안에 실제 사고가 있는지 확인하는 데 몇 시간을 써야 한다. 문제는 명확해지지 않고 더 커졌다.

2. 코드에서의 동일한 확장

   1. 모호한 작업에서 거대한 PR로: vague task가 큰 PR로 바뀐다.
   2. 작은 기능에서 파일 더미로: small feature가 수많은 파일의 묶음으로 변한다.
   3. 완료의 모양만 전달: 결과물은 완료된 것처럼 보이지만 실제 작업은 reviewer에게 이동했을 뿐이다.

5.2. 평가 병목의 공식

1. 생성보다 평가가 비싼 이유

   1. 생성 비용: AI는 코드, 문서, 화면, 테스트 후보를 매우 싸고 빠르게 만든다.
   2. 평가 비용: 인간은 의도, 적합성, 일관성, 보안, 엣지 케이스, 운영 결과를 확인해야 한다.
   3. 처리량 역전: AI가 인간이 평가할 수 있는 양보다 많은 결과를 내놓으면 팀 속도는 증가하지 않고 평가 대기열이 쌓인다.

2. 생산성 지표의 오류

   1. 라인 수의 폐기된 가치: 코드 줄 수는 오래전부터 생산성의 나쁜 지표였는데, 토큰을 가장 많이 태우는 엔지니어가 가장 생산적이라는 식으로 같은 오류를 반복하고 있다.
   2. Ralph loop의 사례: 소셜미디어에서 `Ralph loop`를 새로운 agentic breakthrough처럼 포장하지만, 본질적으로는 while loop에 가깝다.
   3. 과거의 원칙 망각: 작고 원자적인 단위로 기능을 쪼개고 머릿속에 담을 수 있는 크기로 검토하던 원칙을 두 문장의 프롬프트와 한 번의 거대한 생성으로 대체했다.

6. AI 이후에도 유효한 60년의 소프트웨어 지혜

AI가 구현 세부사항을 추상화해도 시스템이 함께 작동하는 방식을 이해해야 한다.

6.1. 변하지 않는 소프트웨어의 근거

1. 기존 원칙의 지속성

   1. Composable code: 조합 가능한 코드는 AI 시대에도 필요하다.
   2. 좋은 패턴: 반복 가능한 좋은 설계 패턴과 견고한 실천법은 폐기되지 않았다.
   3. 60년의 지혜: AI가 등장했다고 60년 동안 축적한 소프트웨어 지혜가 무효가 되지 않는다.

2. 가드레일을 설계하는 이유

   1. 친구의 반론: 에이전트가 코드를 쓴다면 코드가 어떻게 생겼는지, coding convention·아키텍처 스타일·제약을 왜 신경 써야 하느냐는 질문이 나온다.
   2. 추상화의 역사: 소프트웨어는 기계어에서 어셈블리, C, Java, Ruby로 올라왔고, Ruby는 프로그래머의 행복을 주요 설계 목표로 삼았다.
   3. 구현 세부사항의 추상화: 언어가 garbage collection과 수동 포인터를 추상화한 것처럼 AI는 명령형 구현의 세부사항을 추상화할 수 있다.
   4. 통합 이해의 불가피성: 구현이 숨겨져도 시스템이 어떻게 함께 구성되는지는 여전히 이해해야 한다.

6.2. 다이어그램을 압축된 검토 표면으로 사용하기

1. 다이어그램의 역할

   1. 사후 장식이 아님: 다이어그램은 코드를 만든 뒤 붙이는 장식적 문서가 아니라 시스템을 읽기 쉽게 만드는 수단이다.
   2. 수천 줄의 압축: 에이전트가 수천 줄의 구현 세부사항을 만들수록 인간에게는 압축된 review surface가 필요하다.

2. 다이어그램에 담을 구조

   1. 서비스 경계: 어디서 하나의 책임이 끝나고 다른 책임이 시작되는지 보여준다.
   2. 데이터 흐름: 데이터가 어떤 경로로 이동하고 변환되는지 보여준다.
   3. 상태 전이: 시스템의 상태가 어떤 이벤트와 조건으로 바뀌는지 보여준다.
   4. 실패 모드: 정상 경로뿐 아니라 실패했을 때의 동작과 복구 경로를 드러낸다.

3. 검토 가능한 본류와 잎

   1. 주요 프로세스 보존: 핵심 프로세스나 워크플로를 사람이 검토할 수 있는 표면으로 남긴다.
   2. 구현 세부사항의 말단화: 세부 구현은 잎(leaves)으로 밀어 넣어 본류의 이해를 방해하지 않게 한다.
   3. 선언적 코드와 아키텍처: 사람이 추론할 수 있는 층을 만드는 선언적 코드와 아키텍처 패턴을 지향한다.
   4. 목표의 재정의: 목표는 코드 생성 자체가 아니라 인간의 지식, 이해, 검토를 보존하는 것이다.

7. 인지 오버헤드와 관례의 가치

에이전트가 코드를 생성할수록 인간이 의도를 복원하는 비용을 낮추는 구조가 중요해진다.

7.1. Cognitive overhead라는 숨은 세금

1. 변경 전 지불해야 하는 비용

   1. 위치 찾기: 코드를 어디에 두어야 하는지 알아내는 시간이 든다.
   2. 패턴 선택: 어떤 설계 패턴을 따라야 하는지 결정해야 한다.
   3. 올바른 구현 파악: 현재 시스템에서 적절한 구현이 무엇인지 먼저 이해해야 의미 있는 변경을 할 수 있다.

2. AI가 만드는 추가 부담

   1. 다섯 가지 그럴듯한 패턴: 에이전트는 서로 다른 다섯 가지 스타일로 모두 그럴듯한 패턴을 생성할 수 있다.
   2. 의도 역공학: reviewer는 코드 자체뿐 아니라 왜 그렇게 만들어졌는지의 의도까지 역공학해야 한다.
   3. 생성의 무제한성: AI를 통제하지 않으면 인지 오버헤드를 없애기는커녕 증폭한다.

7.2. Slop이 숨을 공간을 줄이는 조건

1. 필요한 구조

   1. 관례와 표준: 반복되는 판단을 관례와 표준으로 고정한다.
   2. 문서화된 흐름: 핵심 작업 흐름과 책임 경계를 문서로 명확히 한다.
   3. 작고 검토 가능한 표면: 한 번에 이해하고 검토할 수 있는 작은 변경 단위를 유지한다.
   4. 명확한 소유권: 각 시스템·기능·결과의 책임자를 분명히 한다.
   5. Definition of Done: 무엇이 완료인지 테스트·문서·검증을 포함해 정의한다.

2. 명확한 경로의 효과

   1. 결정 공간 축소: 가능한 경로가 분명할수록 에이전트와 인간이 선택할 수 있는 불필요한 변형이 줄어든다.
   2. 의도 추적: 코드가 관례를 따르면 reviewer가 결과물 뒤의 의도를 빠르게 복원할 수 있다.
   3. Slop 은닉 공간 축소: 경로가 명확할수록 모호한 추측과 책임 회피가 숨을 자리가 줄어든다.

8. Rails와 관례 중심 설계

Rails는 결정 표면을 줄여 인간과 에이전트가 같은 구조를 반복해서 이해하게 만드는 사례다.

8.1. Convention over configuration

1. Rails가 주는 일관성

   1. 하나의 구조: 같은 개념을 구조화하는 방법이 열 가지가 아니라 하나로 수렴한다.
   2. 완벽함보다 이해 가능성: 모든 사람의 주관적 취향에 완벽하지 않아도 구조가 이해되고 실제로 작동한다.
   3. 프레임워크의 결정 표면 축소: 관례가 반복적인 결정을 없애 인지 오버헤드를 낮춘다.

2. 개인 경험으로 확인한 이점

   1. 4년의 공백: Rails를 처음 사용한 뒤 두 번째로 Rails를 사용하기까지 4년의 간격이 있었다.
   2. 즉시 의도 파악: 4년 뒤 돌아와도 사실상의 표준 라이브러리와 패턴이 그대로여서 아키텍처를 처음부터 해석하지 않고 코드베이스에 다시 들어갈 수 있었다.
   3. 프로젝트 간 이동성: 관례가 일정하면 엔지니어가 프로젝트 사이를 이동할 때 ramp-up 비용이 작다.

8.2. 에이전트 개발과 생태계 일관성

1. JavaScript 생태계와의 대비

   1. 경쟁하는 방식의 문제: 여러 접근법이 공존하는 생태계에서는 에이전트가 어떤 방식을 따라야 할지 혼란스러워한다.
   2. 하나의 정답에 가까운 환경: 일을 하는 방식이 하나로 수렴한 환경이 agentic development에 더 유리하다.

2. Rails Doctrine과 인지 비용

   1. 프로그래머의 행복: Rails Doctrine은 `optimize for programmer happiness`를 핵심 기둥으로 삼는다.
   2. 설정보다 관례: `convention over configuration`은 핵심 개념을 구조화하는 반복 결정을 줄인다.
   3. 시작 장벽 하락: 관례는 처음 시작하는 장벽을 낮추고 인지 오버헤드를 줄인다.

9. ORC: 생성 이후의 인간 규율을 워크플로에 넣기

ORC의 목표는 더 많은 에이전트를 추가하는 것이 아니라 판단이 살아 있는 상태로 에이전트의 작업량을 늘리는 것이다.

9.1. ORC를 만들게 된 반복 실패

1. AI 주변에서 빠진 것

   1. 계획: 코드 생성만으로는 실제 요구를 작은 작업으로 분해하고 우선순위를 정하는 계획이 해결되지 않는다.
   2. 검토: 결과가 기존 시스템과 맞는지, 빠진 요구사항이 없는지 확인하는 검토가 별도로 필요하다.
   3. 적대적 검사: 정상 경로만 통과시키지 않고 실패·오용·엣지 케이스를 공격적으로 확인해야 한다.
   4. 컨텍스트 관리: 에이전트가 어떤 정보와 범위 안에서 일하는지 관리해야 한다.

2. 반복해 온 인간 프로세스

   1. 작업 분해: 큰 요구를 작은 단위로 쪼갠다.
   2. 컨텍스트 관리: 필요한 정보만 제공하고 과도한 맥락과 누락된 맥락을 통제한다.
   3. 선택지 평가: 여러 옵션의 장단점과 트레이드오프를 저울질한다.
   4. 추론 가능한 코드베이스에 편입: 결과물이 팀이 계속 이해할 수 있는 방식으로 코드베이스에 들어가는지 확인한다.

9.2. ORC의 지향점과 지양점

1. 워크플로에 규율을 굽는 방식

   1. 자동화된 책임 보존: ORC는 반복되는 인간의 규율을 워크플로에 넣어 에이전트의 작업량이 늘어도 책임이 사라지지 않게 한다.
   2. 마법 상자가 아님: 정답을 보장해 인간의 책임을 없애는 마법 상자가 아니다.
   3. 인간 책임의 보존: 에이전트가 더 많은 일을 하더라도 판단과 검토라는 책임을 인간이 계속 보유하도록 돕는다.

2. 최종 목표

   1. 생성 코드의 양이 아님: 목표는 더 많은 생성 코드를 배포하는 것이 아니다.
   2. 배포 후의 품질: 생성이 끝난 뒤에도 소프트웨어가 응집력 있고(coherent), 테스트되며, 유지보수 가능하고, 누가 책임지는지 분명해야 한다.
   3. 판단을 갖춘 오케스트레이션: 미래는 더 빠르고 더 나은 vibe coding이 아니라 judgment가 포함된 orchestration이다.

주요 발언 모음

“Slop은 판단이 생성보다 앞설 때 생긴다.”

“Slop은 AI가 생성한 코드가 아니다. 사고가 끝나기 전에 결과물이 끝난 것처럼 보이는 작업물이다.”

“소프트웨어는 선택의 기록이다. 그 선택을 보지 못하면 소유할 수 없고, 소유하지 못하면 진짜 엔지니어링을 하는 것이 아니다.”

“AI는 코드를 생성할 수 있지만, 엉킨 시스템에 일관성을 마법처럼 부여할 수는 없다.”

“생성은 싸지만 평가는 비싸다.”

“AI가 사람이 평가할 수 있는 양보다 더 많이 만들면 팀을 가속한 것이 아니라 병목을 만든 것이다.”

“60년의 소프트웨어 지혜는 AI 때문에 무효가 되지 않았다.”

“목표는 단지 코드 생성이 아니다. 목표는 인간의 지식, 인간의 이해, 인간의 검토다.”

“가장 분명한 경로를 만들수록 Slop이 숨을 공간은 줄어든다.”

“미래는 더 빠르고 더 나은 vibe coding이 아니다. 미래는 판단을 갖춘 오케스트레이션이다.”

“공짜라고 말하지만, 실제로는 앞으로 25년 동안 그것을 유지보수하고 문서화하고 테스트해 달라고 요청하는 것이다. 그것은 공짜가 아니다.”

핵심 데이터 & 수치

• 2024년 12월 25일 이후의 발전: AI 발전 속도가 현재의 과도한 기대와 Slop 확산을 만든 배경으로 언급된다.
• 한 시간: 누구나 코드와 애플리케이션을 한 시간 만에 만들어 클릭 가능한 작동 프로토타입을 얻을 수 있는 수준에 도달했다.
• 12개의 탈출구: 복잡한 B2B 화면이 사용자 요구인지 팀의 누적인지 설명하기 어려운 예로 화면마다 12개의 escape hatch가 제시된다.
• 25년: 무료 PR처럼 보이는 코드도 문서화·테스트·유지보수를 향후 25년 동안 누군가 떠안을 수 있다는 SQLite 창시자의 표현이다.
• 수천 줄: 사람이 중요한 내용을 완전히 이해하기 어려운 대형 PR의 사례다.
• 10개 bullet과 몇 개 사용자 여정: 가볍게 제시한 범위가 AI에 의해 과도하게 확장되는 입력 사례다.
• 20페이지 문서: 가벼운 요구가 실제 사고를 담았는지 검토하는 데 오히려 몇 시간이 드는 산출물로 커지는 예다.
• 다섯 가지 패턴: 에이전트가 다섯 가지 스타일의 그럴듯한 구현을 만들어 인간이 코드뿐 아니라 의도까지 역공학하게 만드는 예다.
• 4년: Rails 사용 사이의 공백 뒤에도 같은 관례와 라이브러리 패턴 덕분에 코드베이스의 의도를 즉시 파악한 경험이다.
• 60년: AI 이전에 축적된 소프트웨어 공학의 원칙과 지혜가 여전히 유효하다는 시간 규모다.

결론 및 시사점

1. 생성량을 생산성으로 착각하지 말아야 한다: 토큰, 코드 줄, 파일 수, PR 개수는 가치와 이해를 보장하지 않는다.
2. 평가 용량을 먼저 설계해야 한다: AI가 만드는 양을 인간이 검토할 수 있는 양 안에 두고, 그 이상이면 생성 범위를 줄이거나 검토 자동화·분해·컨텍스트 관리를 적용해야 한다.
3. 작은 단위로 쪼개야 한다: 요구사항·기능·PR을 사람이 이해하고 테스트할 수 있는 원자적 단위로 분해해야 한다.
4. 핵심 흐름을 보이게 해야 한다: 다이어그램과 선언적 구조로 서비스 경계, 데이터 흐름, 상태 전이, 실패 모드를 압축해 보여줘야 한다.
5. 관례와 Definition of Done을 명문화해야 한다: 선택지를 줄이고 구현 의도를 추적할 수 있게 하며, 완료를 테스트·문서·검증까지 포함하는 상태로 정의해야 한다.
6. 인센티브를 장기 가치에 연결해야 한다: 빠른 병합보다 우아하고 실용적인 설계, 명확한 평가 하니스, 유지보수 가능성, 실제 사용자 가치를 보상해야 한다.
7. 소유권을 끝까지 유지해야 한다: AI가 구현을 도와도 무엇을 만들지 결정하고 그 결과를 장기 운영할 책임은 인간과 팀에 있다.
8. AI의 역할을 오케스트레이션 안에 배치해야 한다: 계획·분해·검토·적대적 검사·컨텍스트 관리가 포함된 워크플로 안에서 에이전트가 일하도록 해야 한다.
9. 최종 기준은 생성 후의 소프트웨어다: 배포된 시스템이 응집력 있고 테스트되며 유지보수 가능하고 책임자가 분명한지가 AI 활용의 성공 기준이다.

핵심 요약 (20줄)

Slop은 AI가 만든 코드 자체가 아니라 판단보다 생성이 앞서 이해와 소유권이 빠진 결과물이다. 완성된 외관은 요구사항의 모호성, 트레이드오프, 엣지 케이스가 해결됐다는 뜻이 아니다. 소프트웨어는 기술·제품·운영·사용자 경험에 관한 선택을 기록하므로 엔지니어는 그 선택을 보고 소유해야 한다. 에이전트는 코드와 화면과 기능을 만들 수 있지만 무엇을 만들지와 무엇을 만들지 않을지는 결정하지 못한다. AI로 코드 생성 비용은 떨어졌지만 시스템의 핵심 흐름과 경계와 데이터 모델을 이해하는 비용은 줄지 않았다. 구조가 있는 코드베이스에서 에이전트는 잘 작동하지만 이미 엉킨 진흙공은 더 크고 빠르게 만든다. 코드 한 줄과 파일과 추상화는 모두 팀이 나중에 지불해야 하는 건설 비용이다. 한 시간짜리 클릭형 프로토타입은 아이디어 탐색에는 유용하지만 제품 완성의 증거로 오해되기 쉽다. 기능 통합, 요구사항 명확화, 수동 테스트, UX 검증은 생성 뒤에 남는 인간의 마지막 1마일이다. 무료로 보이는 PR도 누군가는 앞으로 25년 동안 유지보수하고 문서화하고 테스트해야 하므로 공짜가 아니다. PR 병합 속도만 보상하면 엔지니어는 판단과 검토보다 단기 성과를 앞세우게 된다. 수천 줄의 PR은 한 사람이 중요한 변경을 완전히 이해하기 어렵게 하므로 작고 원자적인 단위로 분해해야 한다. 생성은 싸지만 평가는 비싸며 AI 출력이 인간의 평가 용량을 넘으면 팀의 병목이 된다. 코드 줄 수와 소모한 토큰 수는 가치의 지표가 아니며 Ralph loop도 본질적으로 while loop일 뿐이다. AI 시대에도 조합 가능한 코드, 좋은 패턴, 견고한 실천법이라는 60년의 소프트웨어 지혜는 유효하다. 다이어그램은 서비스 경계, 데이터 흐름, 상태 전이, 실패 모드를 압축해 인간의 검토 표면을 만든다. 관례, 표준, 문서화된 흐름, 작은 변경, 명확한 소유권, Definition of Done은 Slop이 숨을 공간을 줄인다. Rails는 convention over configuration으로 반복 결정을 없애고 프로젝트 간 인지 오버헤드를 낮춘다. ORC는 계획, 검토, 적대적 검사, 컨텍스트 관리라는 인간의 규율을 에이전트 워크플로에 넣는다. AI 시대의 목표는 더 많은 생성 코드를 배포하는 것이 아니라 판단을 갖춘 오케스트레이션으로 응집력 있고 테스트되며 소유된 소프트웨어를 만드는 것이다.