---
title: "AI가 쓰레기 코드를 만든 게 아니라, 쓰레기 코드가 들어오는 속도를 키운 거다"
published: 2026-05-20T21:10:43.000Z
canonical: https://jeff.news/article/2972
---
# AI가 쓰레기 코드를 만든 게 아니라, 쓰레기 코드가 들어오는 속도를 키운 거다

이 글은 ‘AI slop’ 논쟁을 인간 개발자가 만든 낮은 품질의 코드와 같은 문제로 다시 본다. 핵심은 작성자가 사람인지 대규모 언어 모델(LLM)인지가 아니라, 형편없는 변경이 저장소에 들어오지 못하게 막는 품질 인프라가 있느냐는 점이다.

## AI slop 논쟁에서 빠진 질문

- 요즘 개발자 대화는 거의 무조건 AI 얘기로 흘러감. 특히 단골 메뉴는 “AI가 만든 쓰레기 코드”, 즉 AI slop임
  - AI가 멀쩡한 들여쓰기와 그럴듯한 변수명으로 말도 안 되는 코드를 뽑아내는 건 맞음
  - 다만 글쓴이는 여기서 한 번 비꼬듯 묻는다. “그럼 인간 개발자는 ChatGPT 나오기 전까지 전부 완벽한 코드만 썼나?”

- 글의 핵심은 AI가 나쁜 코드를 발명한 게 아니라, 나쁜 코드가 들어오는 속도와 양을 키웠다는 쪽에 가까움
  - 레거시 프로젝트, 테스트 없는 기능 수정, 수천 줄짜리 함수, 디버깅용 alert 난사 같은 건 AI 이전에도 흔했음
  - 그래서 문제를 “AI냐 인간이냐”로 보면 빗나감. 진짜 문제는 팀이 쓰레기 변경을 막을 장치를 갖고 있느냐임

> [!IMPORTANT]
> 이 글의 결론은 단순함. 저장소가 엉성한 변경을 받아들였다면, 작성자가 사람인지 AI인지는 2차 문제고 프로세스가 이미 실패한 거임.

## 품질이 개인 성향에 맡겨질 때 생기는 일

- 글쓴이는 인도 다국적 IT 기업에서 일했던 경험을 꺼내면서, 인간 slop의 현실을 꽤 노골적으로 설명함
  - 서구 기업이 비용 절감을 위해 외주를 주고, 낮은 유지보수성까지 같이 받아오는 구조를 비판함
  - 보상 구조도 뛰어난 엔지니어링보다 정치, 고객 대응, 해외 파견 같은 것에 더 기울어져 있었다고 함

- 실제 프로젝트 코드 품질은 꽤 처참했던 것으로 묘사됨
  - 한 함수나 메서드 안에 수천 줄이 들어가 있었고, 디버깅은 `alert('file.xyz line no=1234')` 같은 식으로 여기저기 박아 넣는 방식이었음
  - 유닛 테스트도 통합 테스트도 없고, “고치면 커밋”에 가까운 분위기였다고 함

- 결국 고객사 쪽 아키텍트가 정적 검사, 유닛 테스트, 커버리지 리포트 같은 도구를 요구하기 시작함
  - Simian, PMD 같은 도구가 도입됐고, 릴리스마다 품질 리포트를 요구받음
  - 이때 글쓴이가 깨달은 포인트가 중요함. 품질이 “좋은 마음가짐”이 아니라 “측정 가능한 인프라”가 됐다는 것

## 좋은 조직은 품질을 제출 경로에 박아둔다

- 글쓴이가 Google 같은 대형 엔지니어링 조직을 보며 느낀 대비는 명확함
  - 코드가 그냥 체크인되지 않고, 프로젝트 소유자의 리뷰를 포함한 승인이 필요함
  - 포매팅과 스타일 규칙이 회사 전체에서 일관되게 강제됨
  - 변경사항이 리뷰에 올라가기 전부터 여러 자동 검사들을 통과해야 함

- 의존성 통제도 품질과 보안의 일부로 다뤄짐
  - 아무 라이브러리나 가져다 쓰는 걸 허용하지 않고, 어떤 의존성을 쓸 수 있는지 관리함
  - 글에서는 패키지 생태계를 겨냥한 Shai-Hulud 2.0 같은 공급망 공격을 떠올리면 이 통제가 더 납득된다고 말함

- 유닛 테스트와 코드 커버리지도 “있으면 좋은 것”이 아니라 실제 기준으로 취급됨
  - 한쪽 환경에서는 품질이 그날 누가 신경 쓰느냐에 달려 있었음
  - 다른 쪽에서는 코드를 제출하는 경로 자체에 품질 기준이 들어가 있었음

## 코드 리뷰만으로는 부족함

- 코드 리뷰는 중요하지만 만능은 아님
  - 좋은 리뷰어는 설계 오류, 이상한 추상화, 빠진 테스트, 보안 문제, 이상한 변수명까지 잡아낼 수 있음
  - 하지만 사람은 피곤해지고, 큰 변경은 흐릿해지고, 기준이 리뷰어 머릿속에만 있으면 매번 다르게 적용됨

- 그래서 필요한 게 가드레일임
  - 포매터, 린터, 테스트, 코드 소유권 규칙, 의존성 검사, CI 게이트 같은 것들이 저장소 주변의 방어선 역할을 함
  - 핵심은 도구 이름이 아니라 “허용 가능한 변경”의 기준을 정하고 실제로 강제하는 것임

- 위키에 적힌 코딩 표준이나 PR 체크리스트는 쉽게 무시될 수 있음
  - 반면 병합을 막는 자동 검사는 진짜 표준으로 작동함
  - 이 차이가 쌓이면 기술 부채가 느리게 쌓이는 조직과 빠르게 무너지는 조직이 갈림

## AI slop의 해법도 결국 같은 곳으로 돌아옴

- AI가 만든 코드가 문제라면, 인간이 만든 나쁜 코드에도 같은 질문을 던져야 함
  - “왜 이런 코드가 생성됐나”보다 “왜 이런 코드가 들어왔나”가 더 운영적인 질문임
  - 저장소가 낮은 품질의 변경을 받아들이는 구조라면 AI가 없어도 언젠가 같은 문제가 생김

- 글쓴이가 말하는 처방은 향수병이 아니라 표준, 가드레일, 강제임
  - 예전 인간 개발 시대가 깨끗했다는 식의 회고는 별 도움이 안 됨
  - AI 코딩 도구가 보편화될수록, 품질 기준을 자동화하고 병합 경로에 넣는 팀이 훨씬 유리해짐

---

## 기술 맥락

- 이 글에서 말하는 핵심 선택은 “리뷰어가 알아서 잘 보겠지”가 아니라, 품질 기준을 CI와 저장소 정책에 넣는 거예요. 왜냐하면 AI든 사람이든 반복적으로 생기는 실수는 사람의 기억력에 맡기면 언젠가 빠지거든요.

- 정적 분석, 포매터, 테스트 커버리지, 의존성 정책은 각각 다른 문제를 막아요. 포매터는 스타일 논쟁을 없애고, 린터와 정적 분석은 명백한 결함을 먼저 걸러내고, 의존성 검사는 공급망 리스크를 줄이는 식이에요.

- 코드 리뷰가 사라지는 건 아니에요. 오히려 자동화가 사소하고 반복적인 검사를 대신해주면, 리뷰어는 설계 판단이나 장기 유지보수성처럼 사람이 봐야 하는 문제에 시간을 쓸 수 있어요.

- AI 코딩 도구가 들어오면 이 구조가 더 중요해져요. 생성 속도가 빨라질수록 낮은 품질의 변경도 더 빨리 들어올 수 있어서, 병합 전에 막는 장치가 없으면 팀의 기술 부채가 눈에 띄게 빨리 불어나요.

## 핵심 포인트

- AI는 엉터리 코드를 그럴듯하게 만들 수 있지만, 나쁜 코드는 AI 이전에도 늘 있었다
- 코드 리뷰만으로는 품질을 일관되게 지키기 어렵고, 포매터·린터·테스트·소유권 규칙·CI 게이트 같은 가드레일이 필요하다
- 품질 기준이 위키나 체크리스트에만 있으면 권고사항에 가깝고, 병합을 막는 자동화가 있어야 실제 표준이 된다

## 인사이트

AI 코딩 도구 논쟁에서 자주 빠지는 지점은 ‘누가 썼나’보다 ‘어떻게 들어오게 놔뒀나’다. 팀의 품질 시스템이 약하면 AI는 원인이 아니라 증폭기 역할을 할 뿐이다.