쓰레기 코드를 없애는 법

URL: https://www.youtube.com/watch?v=3JCgiVYlLFo 날짜: 2026-10-06 채널: Nomad Coders

---

📌 핵심 질문 / 핵심 논점

==AI가 코드를 싸게 생성해도 읽기·이해하기·검증하기·유지보수하는 비용은 사라지지 않으므로, 생성량을 줄이고 판단을 외부화하며 실행 증거를 요구해야 한다.==

• Andrej Karpathy가 지적한 AI 코드의 문제는 과도한 추상화, 나쁜 코드 미학, 복사·붙여넣기, 잘못된 가정, 데드 코드, 필요 이상으로 긴 구현이다.
• Markdown 지침은 응답과 구현의 방향을 잡지만, Oxlint 같은 결정론적 도구와 컴파일러가 지침을 강제하는 안전장치가 된다.
• 린트와 타입 검사를 통과한 작고 아름다운 코드도 실제로 동작하지 않을 수 있으므로, done·fixed·passing이라는 주장은 새로 실행한 검증 명령과 전체 출력·종료 코드로 뒷받침해야 한다.

AI는 기본값으로 더 많은 코드, 단어, 파일, 추상화를 추가하는 ‘adding machine’이다. 좋은 AI 코딩은 무엇을 만들지뿐 아니라 무엇을 만들지 않을지 결정하고, 모델이 임의로 내린 판단의 수를 줄이며, 사람이 읽어야 할 코드의 양을 통제하는 작업이다.

1. AI가 만드는 슬롭과 검토 비용

AI가 생성한 코드의 가장 큰 위험은 고장보다 그럴듯한 과잉이다.

1.1. Karpathy가 지적한 AI 코드의 패턴

1. 과잉 생성의 원인

   1. Andrej Karpathy는 에이전트가 추상화(abstraction)를 부풀리고 코드 미학(code aesthetics)이 나쁘며 코드 블록을 곳곳에 복사·붙여넣어 엉망을 만든다고 지적했다.
   2. 모델은 사용자를 대신해 잘못된 가정을 세운 뒤 그 가정을 검토 없이 끝까지 밀고 나간다.
   3. 데드 코드(dead code)를 남기고 100줄이면 충분한 문제에 1,000줄을 작성한다.

2. 작은 요청이 공장으로 변하는 과정

   1. “작은 기능 하나를 추가해 달라”고 요청하면 필요하지도 않은 factory, interface, config file, 테스트 네 개가 생길 수 있다.
   2. 네 개의 테스트가 붙은 함수 자체가 존재할 필요가 없을 수도 있어, 결과물을 읽는 사람이 “이게 왜 필요한가?”를 다시 판단해야 한다.

1.2. 망가진 코드와 슬롭 코드의 차이

1. 슬롭(slop)의 정의

   1. Slop은 인터넷을 뒤덮은 저품질 AI 생성 글·이미지·코드를 가리키는 표현이다.
   2. 망가진 코드는 쉽게 발견하고 고칠 수 있지만, 슬롭 코드는 컴파일되고 테스트를 통과하며 요청을 대충 수행하는 것처럼 보인다.

2. 숨은 비용

   1. 슬롭 코드는 애초에 존재할 필요가 없거나 불필요하게 복잡할 수 있어 한 줄씩 읽어야 한다.
   2. 코드를 작성할 때는 타이핑하는 동안 머릿속에 정신 모델(mental model)이 만들어지지만, AI가 작성할 때는 그 형성 과정이 빠진다.
   3. 따라서 사람은 누구도 실제로 내리지 않은 결정을 역설계(reverse-engineer)해야 하며, 코드가 어떻게 동작하는지 확신하지 못한 채 배포하는 ‘vibe code anxiety’를 겪게 된다.
   4. AI는 코드를 9초 만에 작성할 수 있어도, 최종 책임자는 이름을 걸 수 있을 정도로 코드를 이해해야 한다. 작성보다 검토가 어려운 이유가 여기에 있다.

2. 응답의 양을 줄이는 Attention Span

첫 단계는 AI가 무엇을 말하는지 통제해 읽기 피로를 줄이는 것이다.

2.1. Markdown output style 설치

1. Attention Span의 역할

   1. Attention Span은 에이전트의 답변 방식을 지정하는 Markdown 파일 모음이다.
   2. Claude Code에서는 output style로 설치하고, Codex나 Open Code에서는 AGENTS.md에서 style file을 링크하면 된다.
   3. 설치 자체는 약 2분이면 끝난다.

2. 세 가지 응답 스타일

   1. Spartan: 정말 날것에 가까운(raw) 답변을 원할 때 사용한다.
   2. Rundown: 체크리스트가 포함된 상태 업데이트(status update)에 사용한다.
   3. Attention Kind: 먼저 결론을 답하고(answer first), 짧아서 훑어볼 수 있는 포인트를 뒤에 붙인다. 실사용 스타일은 Attention Kind다.

2.2. 응답 압축이 계획 품질을 높이는 이유

1. PostgreSQL과 MongoDB 비교 사례

   1. “새 소셜 앱에 PostgreSQL과 MongoDB 중 어떤 데이터베이스를 쓸까?”라는 질문에 일반 답변은 수백 단어를 늘어놓는다.
   2. Attention Kind를 적용하면 같은 정보를 400단어 이상에서 94단어로 줄여 몇 초 안에 읽을 수 있다.

2. 계획 단계의 방어선

   1. 계획(planning session)을 짧게 읽을 수 있으면 구현 계획이 끝날 때까지 지치지 않는다.
   2. 코드가 되기 전에 계획을 검토하면 슬롭이 실제 구현으로 굳어지는 것을 먼저 잡을 수 있다.
   3. Attention Span은 코드 자체가 아니라 AI가 말하는 방식을 고친다.

3. 적게 만들도록 지시하는 Andrej Karpathy Skills

응답을 짧게 만든 다음, 구현에 들어가기 전 모델의 판단 습관을 제한해야 한다.

3.1. 네 가지 행동 규칙

1. Think before coding

   1. 코딩 전에 먼저 생각하고, 모르는 내용을 가정하지 않는다.
   2. 요청이 모호하면 임의로 하나를 고르지 말고 가능한 선택지를 드러낸다.

2. Simplicity first

   1. 문제를 고치는 데 필요한 단순한 해법을 우선한다.
   2. 필요 없는 추상화·파일·계층을 추가하지 않는다.

3. Surgical changes

   1. 문제를 고치는 줄만 바꾼다.
   2. 기존 스타일을 따르고 나머지 코드는 그대로 둔다.

4. Goal-driven execution

   1. “무엇을 해라”라고 막연히 명령하기보다 성공 기준(success criteria)을 준다.
   2. “로그인 버그를 고쳐라” 대신 버그를 재현하는 테스트를 작성하고 통과시키며 아무것도 깨지지 않았는지 확인하라고 요청한다.
   3. 모델은 목표에 도달할 때까지 반복하는 데 특히 강하므로, 실제로 검사할 수 있는 목표를 제시해야 한다.

3.2. 파일 하나로 널리 퍼진 이유

1. 작은 설치 단위

   1. Andrej Karpathy Skills는 한 개의 Markdown 파일인 CLAUDE.md로 배포할 수 있다.
   2. 플러그인으로 설치하거나 파일을 내려받아 프로젝트에 넣으면 된다.
   3. GitHub에서 200,000개가 넘는 별(stars)을 받은 배경에는 AI 코딩을 사용하는 사람이 같은 문제를 겪는다는 공감대가 있다.

2. 지침의 한계

   1. Markdown은 모델이 읽는 글일 뿐이므로 모델이 고의가 아니더라도 무시할 수 있다.
   2. 컨텍스트가 커지고 세션이 복잡해질수록 모델은 지침을 덜 잘 따른다.
   3. 따라서 지침은 방향을 제시하지만 통과·실패를 결정하는 강제 장치는 아니다.

4. Anti-Slop과 언어 선택으로 판단을 없애기

모델에게 더 깨끗한 코드를 부탁하는 대신, 반복적으로 확인할 수 있는 규칙과 언어 기능으로 선택지를 줄여야 한다.

4.1. Oxlint 기반 Anti-Slop 규칙

1. 결정론적 린트(deterministic lint)

   1. Anti-Slop은 JavaScript와 TypeScript용 린터(linter)인 Oxlint에 적용하는 규칙 모음이다.
   2. 린터는 AI 없이 코드를 읽고, 정해 둔 규칙을 어긴 모든 줄을 표시한다.
   3. 같은 코드는 항상 같은 지적을 받으므로 “더 깨끗하게 써 달라”는 주관적 부탁보다 재현성이 높다.

2. 실행 루프

   1. 에이전트가 lint 명령을 실행하게 한다.
   2. 문제가 있으면 고치고 다시 lint를 실행한다.
   3. 이 과정을 오류가 하나도 남지 않을 때까지 반복한다.
   4. Markdown 문장의 지시는 무시할 수 있지만, 실패한 lint 명령은 통과할 때까지 무시할 수 없다.

4.2. Anti-Slop이 잡는 구체적인 냄새

1. 조건부 object spread

   1. AI는 timeout 값이 있을 때만 추가하려고 conditional object spread를 자주 작성한다.
   2. 규칙을 켜면 에이전트가 같은 의미를 더 명시적이고 검토하기 쉬운 형태로 다시 작성해야 한다.

2. 모호한 파라미터

   1. save 함수가 정체를 알 수 없는 object 하나를 받으면 호출부를 모두 읽어야 어떤 데이터를 저장하는지 알 수 있다.
   2. save(user)처럼 저장 대상의 타입을 명시하면 TypeScript가 기대 타입을 검사하고 사람도 함수 계약(contract)을 즉시 파악할 수 있다.

3. 팀 취향과 이진 게이트

   1. Anti-Slop 규칙은 보편적 표준이 아니라 작성자가 선호하는 코드 스타일을 반영한 출발점이다.
   2. 팀의 취향에 맞게 규칙을 수정해야 한다.
   3. “더 깔끔하게 써 달라”는 판단을 줄이고, lint가 통과하거나 실패하는 binary gate로 바꾼다.

4.3. 언어가 제거하는 판단의 수

1. AI가 직접 구현하는 reduce와 Kotlin 표준 라이브러리

   1. AI가 데이터를 묶기 위해 손으로 쓴 reduce를 만들면 accumulator, key, mutator, 복사 여부, 반환 여부를 모두 결정해야 한다.
   2. 각각은 미묘하게 틀릴 수 있어 사람이 모든 선택을 검토해야 한다.
   3. Kotlin에서는 표준 라이브러리에 같은 기능을 나타내는 이름이 있으므로 associateBy가 맞는 함수인지 확인하는 것으로 검토가 끝난다.

2. 컴파일러가 만드는 보일러플레이트

   1. Kotlin에서 data를 한 줄로 정의하면 컴파일러가 equality, copy, hash code, toString을 일관되게 생성한다.
   2. TypeScript에서 AI가 이 helper들을 손으로 작성하면 equality에 어떤 필드를 포함할지, copy를 deep로 할지 shallow로 할지 다시 결정해야 한다.
   3. Kotlin 컴파일러는 세션·코드베이스·에이전트가 달라도 같은 방식으로 생성하므로, 어제의 에이전트와 오늘의 에이전트가 서로 다른 결정을 내리는 문제를 줄인다.

3. 언어 선택의 한계와 효과

   1. Kotlin을 사용해도 과도하게 설계된 코드는 컴파일되고 그대로 남을 수 있으므로 Attention Span, Karpathy 규칙, Anti-Slop을 함께 사용해야 한다.
   2. 언어가 AI에게서 빼앗는 판단 하나하나가 사람이 읽지 않아도 되는 한 줄이 되며, 매일 반복되는 검토량에서 큰 차이를 만든다.

4.4. Kotlin 생태계와 학습 기회

1. 모바일을 넘어서는 적용 범위

   1. Kotlin은 15주년을 맞았고, JetBrains는 프로젝트 기반 유료 Kotlin 강좌를 2026년 10월 9일까지 무료로 공개했다.
   2. 완전 초보자부터 숙련 개발자까지 각 수준에 맞는 강좌가 있다.
   3. Google은 Android 개발의 선호 언어로 Kotlin을 채택했다.

2. 멀티플랫폼과 서버

   1. Kotlin Multiplatform은 하나의 코드베이스로 Android와 iOS를 만들고, Kotlin/Native로 네이티브 컴파일한다.
   2. 웹에서는 Kotlin/JS로 컴파일할 수 있다.
   3. 백엔드에서는 기존 Java·Spring 프로젝트에 자연스럽게 들어간다.
   4. JetBrains의 Ktor를 사용하면 Spring 없이 Kotlin으로 서버를 처음부터 만들 수 있다.

3. 생산성 근거와 사용 기업

   1. Kotlin을 쓰는 팀은 Java보다 코드가 최대 40% 적고 개발 속도가 30~50% 빠르다고 보고된다.
   2. Google, Amazon, Meta, Uber가 Kotlin을 대규모 프로덕션에서 사용한다.
   3. 적게 유지보수할 코드와 AI가 내려야 할 적은 판단을 동시에 얻는 것이 언어 선택의 목적이다.

5. 검증 전 완료를 금지하기

린트·타입 검사·작은 구현은 품질 신호일 뿐 실제 동작의 증거가 아니다.

5.1. “Done”이라는 단어의 문제

1. 근거 없는 완료 선언

   1. 에이전트는 “Done. Everything should work now.”라고 말하지만 실제로 아무것도 테스트하지 않았을 수 있다.
   2. “Done”은 검증 결과가 아니라 다음에 나올 가능성이 가장 큰 단어일 뿐이다.

2. 마지막 질문

   1. lint가 깨끗하고 타입이 맞으며 구현이 작고 아름다워도 기능은 여전히 망가질 수 있다.
   2. 가장 중요한 질문은 “코드가 실제로 동작하는가?”다.

5.2. Verification Before Completion 규칙

1. Superpowers의 단일 원칙

   1. Verification Before Completion은 GitHub에서 널리 쓰이는 에이전트 스킬 모음인 Superpowers에 포함된 스킬이다.
   2. 핵심 규칙은 “항상 주장보다 증거를 먼저 둔다(Evidence before claims always)”다.
   3. 에이전트가 done, fixed, passing이라고 말하기 전에 검증을 끝내야 한다.

2. 세 단계 검증 순서

   1. 먼저 해당 주장을 증명할 명령이 무엇인지 말한다.
   2. 기억에 의존하지 않고 그 명령을 새로 실행한다.
   3. 전체 출력과 exit code를 읽은 뒤에만 증거를 붙여 주장을 만든다.
   4. 출력이 주장을 확인하지 못하면 성공을 꾸미지 말고 실제 상태를 말한다.

3. 금지해야 할 마법의 표현

   1. “should work”, “probably passes”, “seems correct”는 모두 검증하지 않았다는 뜻이다.
   2. “테스트 스위트를 실행했고 34개 중 34개가 통과했다”처럼 명령과 실제 결과를 함께 제시해야 한다.
   3. 성공 기준을 먼저 정한 뒤 그 기준을 실행하지 않고는 성공을 선언하지 않게 해야 한다.

주요 발언 모음

“Slop code compiles. It passes the tests and it sort of does what you ask.”

“Reviewing code is always harder than writing it.”

“Every decision the AI doesn't make is a decision you don't review.”

“The lint passes or it fails. That's it.”

“Evidence before claims always.”

“Generating code is free now. Reading it is not free.”

“Not typing code. Deciding what deserves to exist.”

“Someone still has to look at 500 generated lines and say we need 30 of these.”

핵심 데이터 & 수치

• AI가 작은 요청 하나에 factory, interface, config file, 불필요한 함수의 테스트 네 개를 추가할 수 있다.
• AI는 코드를 약 9초 만에 작성할 수 있지만 사람은 이해와 유지보수 책임을 진다.
• Attention Kind는 400단어 이상 답변을 같은 정보의 94단어로 줄인다.
• Andrej Karpathy Skills는 GitHub에서 200,000개가 넘는 별을 받았다.
• Kotlin은 Java 대비 최대 40% 적은 코드와 30~50% 빠른 개발 속도를 제시한다.
• Kotlin은 15주년을 맞았고 관련 무료 강좌는 2026년 10월 9일까지 제공된다.
• Google, Amazon, Meta, Uber가 Kotlin을 대규모 프로덕션에서 사용한다.
• 검증 사례는 테스트 34개 중 34개 통과다.
• AI가 만든 500줄을 사람이 30줄만 남기기로 결정하는 일이 새로운 개발 책임이다.
• 유지보수 비용은 향후 4년 동안 계속 발생하며 생성 비용이 사라져도 없어지지 않는다.

결론 및 시사점

1. Attention Span으로 답변을 먼저 압축해 계획을 읽을 수 있게 만들어라.
2. Karpathy의 네 규칙으로 가정·복잡성·광범위한 변경을 줄이고 성공 기준을 명시하라.
3. Anti-Slop 규칙을 Oxlint에 연결해 주관적인 코드 취향을 반복 가능한 통과·실패 판정으로 바꿔라.
4. Kotlin처럼 표준 라이브러리와 컴파일러가 반복 판단을 대신하는 언어를 선택해 검토해야 할 줄 수를 줄여라.
5. 린트·타입 검사·코드 미학만으로 완료를 선언하지 말고, 검증 명령·전체 출력·exit code를 남겨라.
6. AI 시대의 핵심 업무는 코드를 많이 타이핑하는 일이 아니라 무엇이 존재할 가치가 있는지 결정하는 일이다.
7. 500줄을 그대로 받아들이지 말고 필요한 30줄을 골라내는 편집자이자 검증자로 일하라.