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

한 줄 핵심

AI가 코드를 더 빨리 만들수록 검토·이해·주인의식의 비용이 더 커지므로, 생성 속도보다 제약과 리뷰 가능한 구조를 설계해야 엉터리 코드 배포를 막을 수 있다.

시간별 요약

1. 0:00
   도입: 가브리엘 마르티네스 소개 발표자는 G2i의 엔지니어링 매니저이자 AI slop을 감시하는 역할로서, slop이 오래된 문제이지만 이제는 훨씬 더 빠른 속도로 번지고 있다고 문제를 제기한다.
2. 0:25
   AI 슬롭의 진짜 정의 slop은 AI가 코드를 생성했다는 사실이 아니라, 판단이 끝나기 전에 산출물이 완성된 듯 보이는 상태를 뜻한다. 모호함이 추측으로 덮이고 트레이드오프와 책임이 사라진 결과, 출력은 생겼지만 이해는 남지 않는다.
3. 1:00
   진짜 위험: 아무도 인지하지 못한 선택들 진짜 위험은 잘못된 선택 그 자체보다, 선택이 필요했다는 사실조차 알아차리지 못하는 데 있다. 소프트웨어는 선택의 기록이므로, 그 선택을 보지 못하면 소유할 수도 없고 엔지니어링이라고 부르기도 어렵다.
4. 1:40
   취기에서 깨어날 시간 AI 자체를 부정하는 것이 아니라, 과도한 흥분 속에서 속도를 늦추고 판단을 되찾아야 한다는 메시지다. 에이전트는 코드와 화면을 빠르게 만들 수 있지만, 그 능력이 곧바로 좋은 시스템을 의미하지는 않는다.
5. 2:15
   에이전트가 대체할 수 없는 인간의 역할 에이전트는 무엇이 중요한지 결정하고, 모호함을 해석하고, 장기적으로 시스템을 책임지고, 무엇을 만들지 말아야 할지도 판단하는 인간의 역할을 대신할 수 없다. slop의 핵심은 AI 도구가 아니라 판단의 부재다.
6. 2:39
   우리가 여기에 이르게 된 과정 무엇이든 가능한 시대에는 무엇을 만들지 정하는 일이 더욱 중요해졌다. 그러나 많은 팀이 그 판단보다 거대한 스파게티식 제품을 만드는 데 과열되어 있다.
7. 2:54
   코드는 자산이 아니라 부채다 코드 한 줄은 자산이 아니라 부담이며, 가장 좋은 코드는 애초에 없는 코드다. 생성 비용은 내려가도 이해 비용은 내려가지 않으므로, 구조·경계·데이터 모델·핵심 흐름에 대한 이해가 반드시 필요하다.
8. 3:49
   더 거대해지는 진흙탕 코드베이스 이미 진흙탕인 코드베이스에서는 에이전트가 구조를 정리해 주지 못하고 오히려 더 큰 진흙덩이를 더 빨리 만들 뿐이다. 새 컴포넌트를 만들 수 있다는 사실만으로 제품이 정말 필요한 것은 아니다.
9. 3:59
   생산된 라인이 아니라 소비된 라인 코드 라인은 생산된 것이 아니라 지출된 것으로 봐야 하며, AI는 이 지출을 더 쉽게 만든다. 그 비용은 혼란, 취약한 흐름, 이해하지 못한 채 건드리기 싫은 기능, 그리고 미로 같은 제품 형태로 돌아온다.
10. 4:49
    책임감과 주인의식 누군가 내 작업을 검토한다는 사실만으로도 더 세밀하게 보게 되며, 가시적인 책임 지표가 있으면 세부 품질이 더 좋아진다. 좋은 결과를 보상하고, 생산한 작업에 대한 책임을 분명히 해야 한다.
11. 5:19
    프로토타입의 환상 짧은 시간에 클릭 가능한 프로토타입이 나오면, 이해관계자들은 실제 개발도 그만큼 빨리 끝난다고 착각하기 쉽다. 그러나 진짜 어려움은 통합, 요구사항 정리, 수동 테스트, 엣지 케이스 검증, 그리고 시스템에 넣을 가치가 있는지 판단하는 마지막 단계에 있다.
12. 6:38
    공짜는 없습니다: 유지보수의 대가 PR은 쉽게 만들 수 있지만, 그 뒤의 문서화·테스트·유지보수·장기 책임은 공짜가 아니다. 외부의 압박과 경쟁 심리가 겹치면 slop은 더 많이, 더 빨리 늘어난다.
13. 7:13
    더 빨리 머지해야 한다는 압박 세부를 살피고 명세를 다듬는 사람은 느려 보이고, 대충 넘기는 사람은 더 많이 만든 것처럼 보인다. 이런 환경은 빠른 머지 압박을 강화해, 충분히 판단되지 않은 코드가 들어가게 만든다.
14. 7:33
    개발자의 성과 불안과 인센티브 팀이 속도를 과하게 보상하면 개발자는 뒤처질까 불안해지고, 평소라면 더 검토했을 코드를 성급하게 머지하게 된다. 보상은 PR 개수가 아니라 가치 있는 결과, 잘 구조화된 설계, 명확한 테스트와 평가 체계를 중심으로 맞춰야 한다.
15. 8:33
    1,000줄짜리 PR의 악몽 수천 줄짜리 PR은 인간이 중요한 변경점을 온전히 이해하기 어렵게 만든다. 복잡도를 큰 덩어리로 밀어 넣기보다, 더 작은 단위로 쪼개서 이해 가능성을 유지하는 것이 엔지니어의 역할이다.
16. 9:18
    20페이지 AI 문서 문제: 검토자에게 전가된 생각 짧은 범위를 주었는데 장황한 문서가 돌아오면, 오히려 검토자가 그 안에 실제 사고가 있는지 다시 판별해야 한다. AI가 만든 결과물이 문제를 명확히 하기보다 모호함을 더 큰 산출물로 되돌려 주는 경우가 가장 나쁘다.
17. 10:02
    생성은 저렴하지만 검토는 비쌉니다 생성 비용이 낮아질수록 평가는 더 비싸진다. AI가 인간이 평가할 수 있는 양보다 더 많이 만들어내면, 속도가 아니라 검토 병목을 만든다.
18. 10:17
    트위터의 과장 광고와 Ralph 루프 트위터식 과장으로 기존의 단순한 개념을 새 발명처럼 포장하는 경향을 경계해야 한다. 코드 라인 수나 토큰 소비량은 생산성 지표가 아니며, 여전히 작은 단위로 분해해 이해하고 리뷰할 수 있어야 한다.
19. 11:27
    코드의 형태와 설계가 여전히 중요한 이유 에이전트가 코드를 대신 쓴다 해도 코드가 어떤 형태와 설계를 가져야 하는지는 여전히 중요하다. AI는 구현 세부를 추상화하지만, 시스템이 어떻게 일관되게 조립되는지는 여전히 인간이 이해해야 한다.
20. 12:22
    검토의 접점으로서의 다이어그램 다이어그램은 장식용 문서가 아니라, 거대한 구현 세부를 압축해 리뷰 가능한 형태로 바꾸는 도구다. 서비스 경계, 데이터 흐름, 상태 전이, 실패 모드를 한눈에 보이게 해야 인간이 시스템의 형태를 이해할 수 있다.
21. 13:06
    인지적 과부하: 변경 전 치러야 할 세금 코드를 어디에 두고 어떤 패턴을 따를지 파악하는 데 드는 인지적 비용은 모든 변경 전에 치러야 하는 세금이다. 관례, 표준, 작은 리뷰 단위, 명확한 소유 경계가 있어야 slop이 숨어들 틈이 줄어든다.
22. 14:01
    Rails가 주는 교훈: 규약의 힘 Rails는 결정해야 할 수를 줄이는 강한 규약이 얼마나 강력한지 보여준다. 같은 방식이 반복되면 사람도 에이전트도 빠르게 맥락을 이해할 수 있고, 온보딩과 프로젝트 이동도 쉬워진다.
23. 15:31
    우리가 ORC를 만든 이유: 제약과 검토 Ork는 에이전트를 더 많이 쓰자는 이유가 아니라, 계획·리뷰·반대 검증·컨텍스트 관리가 빠진 상태에서 반복되던 실패 패턴을 해결하려고 만들어졌다. 목표는 생성량을 늘리는 것이 아니라, 생성 이후에도 이해 가능하고 테스트 가능하며 책임질 수 있는 소프트웨어를 남기는 것이다.

실무 인사이트

• AI 코드 도입의 핵심 지표를 생성 속도나 출력량이 아니라 리뷰 가능성, 이해 가능성, 책임 추적 가능성으로 바꿔야 한다.
• PR 크기와 문서 분량을 줄이고, 다이어그램·규약·명확한 경계를 통해 인간이 판단할 수 있는 표면적을 작게 유지해야 한다.
• 팀 보상 체계를 속도 중심에서 품질·검증·장기 유지보수 중심으로 바꾸지 않으면, AI는 생산성 도구가 아니라 검토 부채 증폭기가 된다.