Generation Is Cheap, Review Is Expensive: How to Stop Shipping AI Slop — Gabriel Martinez, G2i

한 줄 핵심

AI는 코드를 빠르게 생성하지만, 시스템을 이해하고 검토하며 책임지는 인간의 판단이 따라오지 않으면 더 큰 복잡성과 기술 부채만 빠르게 쌓인다는 점을 강조하는 영상이다.

시간별 요약

1. 0:00
   도입 AI 시대의 소프트웨어에서 가장 큰 문제는 생성 속도가 아니라 판단 속도와 책임이 따라가지 못하는 데 있다. 이 영상은 그런 현상을 'slop'으로 보고, 이를 경계해야 한다는 문제의식을 제시한다.
2. 0:37
   slop이란 무엇인가 slop은 생성이 판단보다 앞서며, 생각이 끝나기 전에 결과물이 완성된 것처럼 보이는 상태다. 모호함을 추측으로 덮고, 트레이드오프와 소유권을 남겨 둔 채 출력만 만들어낸 작업이 여기에 해당한다.
3. 1:12
   보이지 않은 선택이 만드는 위험 진짜 위험은 AI가 틀린 선택을 했다는 사실보다, 엔지니어가 선택의 존재 자체를 보지 못한 채 지나친다는 데 있다. 소프트웨어는 기술·제품·운영·사용자 관점의 선택 기록이므로, 그 선택을 보지 못하면 엔지니어링이 아니라 단순 수용에 그친다.
4. 1:52
   냉정해질 때 AI 자체를 부정하는 것이 아니라, 최근의 발전으로 생긴 과속 상태를 조정해야 한다는 문제의식을 담는다. 에이전트는 코드 작성과 화면 구성에는 능하지만, 판단과 절제는 대신할 수 없으므로 속도를 낮추고 기준을 회복해야 한다.
5. 2:27
   에이전트가 대신할 수 없는 것 에이전트는 무엇이 중요한지 결정하는 일, 모호함을 해석하는 일, 장기적으로 시스템을 책임지는 일, 그리고 무엇을 만들지 않는 것이 맞는지 판단하는 일을 대체하지 못한다. slop의 본질은 AI 도구의 문제가 아니라 판단 부재에 있다.
6. 2:51
   여기까지 오게 된 이유 무엇이든 가능한 환경에서는 무엇을 만들지 정하는 일이 더 중요해졌지만, 사람들은 오히려 복잡한 제품을 과도하게 키워 왔다. 그 결과 스파게티 같은 제품 구조와 불필요한 복잡성이 늘어났다.
7. 3:06
   코드는 부채다 작성되는 모든 코드는 자산이 아니라 부채이며, 최고의 코드는 아예 없는 코드라는 관점이 제시된다. AI는 코드를 쉽게 만들지만 이해 비용은 줄이지 못하므로, 핵심 흐름·경계·데이터 모델·제품 행태의 이해가 여전히 필요하다.
8. 4:01
   더 커진 진흙 덩어리 기존 구조가 이미 엉망이면 AI는 문제를 해결하지 못하고 더 큰 진흙 덩어리만 빠르게 만든다. 새 컴포넌트를 만들 수 있다는 사실이 곧 제품에 필요한 것이라는 뜻은 아니다.
9. 4:11
   생산된 줄이 아니라 쓴 줄 코드 줄 수는 생산량이 아니라 비용으로 봐야 한다는 관점이 중요하다. AI는 파일, 추상화, 복잡성에 더 쉽게 비용을 쓰게 만들고, 그 대가는 혼란과 취약한 흐름, 이해하기 어려운 제품으로 돌아온다.
10. 5:01
    책임성 팀은 자신이 만든 결과물에 대한 책임을 지고, 그 책임이 보상과 평가로 연결되어야 한다. 누군가 자신의 작업을 검토한다는 사실만으로도 더 세밀하고 신중한 작업이 유도된다.
11. 5:31
    프로토타입 착시 짧은 시간에 클릭 가능한 프로토타입을 만들 수 있게 되면서, 사람들은 소프트웨어 전체도 그렇게 빨리 완성된다고 착각하기 쉽다. 하지만 실제 난이도는 통합, 요구사항 정리, 수동 테스트, UX 검증 같은 인간의 마지막 단계에 있다.
12. 6:50
    "공짜가 아니다" PR을 올리는 행위는 공짜가 아니라, 유지보수·문서화·테스트·장기 책임을 다른 누군가에게 넘기는 행위일 수 있다. AI가 만든 결과물일수록 그 이후의 유지 책임이 누구에게 있는지를 분명히 해야 한다.
13. 7:25
    더 빨리 합치라는 압박 세부를 검토하고 명세를 다듬는 사람보다, 빠르게 결과를 내는 사람이 더 유능해 보이는 환경이 만들어진다. 이런 구조에서는 조심스럽고 꼼꼼한 작업이 오히려 느리게 보이는 역전 현상이 생긴다.
14. 7:45
    성과 불안 팀 내에서 병합 속도가 과도하게 강조되면, 충분히 판단하지 않은 채 PR을 합치게 되는 압박이 생긴다. 단기 성과가 장기 코드 건강을 이기면, 이해하지 못한 코드가 쌓이고 사람들은 속도 경쟁에 휩쓸린다.
15. 8:45
    천 줄짜리 PR 수천 줄짜리 PR은 사람이 중요한 변경점을 온전히 이해하기 어렵게 만든다. AI가 생산성을 높이는 것처럼 보여도, 실제로는 인간이 검토해야 할 문자와 복잡성만 더 많이 만들어 낸다.
16. 9:30
    20페이지 문서 문제 간단한 범위를 줬는데도 AI가 긴 문서나 거대한 산출물로 되돌려주면, 문제는 명확해지지 않고 오히려 확장된다. 작은 기능이 거대한 파일 묶음이 되면, 실제 사고는 작성자가 아니라 검토자에게 떠넘겨진다.
17. 10:14
    생성은 싸고, 검토는 비싸다 AI가 인간이 평가할 수 있는 양보다 더 많이 만들어내면 팀의 속도는 올라가는 것이 아니라 검토 병목이 생긴다. 생산의 병목은 생성이 아니라 평가와 판단 쪽에 있다.
18. 10:29
    Twitter 과장과 Ralph 루프 새로운 개념인 것처럼 포장되는 과장된 담론이 많지만, 실제로는 익숙한 원칙을 이름만 바꿔 반복하는 경우가 많다. 토큰을 많이 쓰는 사람이 더 생산적이라는 식의 착각 대신, 작고 검토 가능한 단위로 쪼개는 기본 원칙을 잊지 말아야 한다.
19. 11:39
    코드의 형태가 여전히 중요한 이유 에이전트가 코드를 써 주더라도, 코드의 구조와 형태가 왜 중요한지는 여전히 사라지지 않는다. 추상화 수준이 올라가더라도 시스템이 어떻게 결합되고 작동하는지는 사람이 이해해야 한다.
20. 12:34
    검토 표면으로서의 다이어그램 다이어그램은 장식이 아니라 시스템을 읽을 수 있게 만드는 압축된 검토 표면이다. 서비스 경계, 데이터 흐름, 상태 전이, 실패 지점을 한눈에 보이게 해야 인간이 검토 가능한 범위로 시스템을 다룰 수 있다.
21. 13:18
    인지적 오버헤드 엔지니어가 작업을 시작하기 전에 어디에 코드를 넣고 어떤 패턴을 따라야 하는지 파악하는 비용이 바로 인지적 오버헤드다. AI가 이를 줄이기는커녕 여러 스타일을 섞어 제시하면 오히려 부담이 커지므로, 규칙·표준·명확한 소유권이 필요하다.
22. 14:13
    Rails에서 배운 교훈 Rails는 선택지를 줄이고 관습을 강하게 만들 때 인지적 부담이 얼마나 낮아지는지 보여 준다. 같은 패턴이 오래 유지되기 때문에, 코드베이스에 다시 들어와도 의도를 빠르게 이해하고 적은 학습 비용으로 움직일 수 있다.
23. 15:43
    ORC를 만든 이유 AI가 코드를 만들 수 있어도 기획, 검토, 반대 검증, 컨텍스트 관리 같은 인간의 규율은 여전히 필요하다는 반복적 경험이 ORC를 만들게 했다. 목표는 더 많은 생성물이 아니라, 판단을 유지한 채 소프트웨어를 일관되고 테스트 가능하며 관리 가능한 상태로 배포하는 것이다.

실무 인사이트

• AI 개발에서는 생성량보다 검토 가능성을 먼저 설계해야 하며, PR 크기·문서 길이·아키텍처 경계를 작게 유지하는 기준이 팀 생산성을 좌우한다.
• 프로토타입 속도에 속지 말고, 통합·테스트·운영 책임이 시작되는 지점을 명확히 정의해야 AI 산출물이 실제 제품으로 전환된다.
• 컨벤션과 다이어그램, 정의된 완료 조건은 사람의 인지 비용을 줄이는 핵심 장치이므로 에이전트 도입과 함께 반드시 강화해야 한다.