AI가 쓰레기 코드를 만든 게 아니라, 쓰레기 코드가 들어오는 속도를 키운 거다

AI slop 논쟁에서 빠진 질문

• 요즘 개발자 대화는 거의 무조건 AI 얘기로 흘러감. 특히 단골 메뉴는 “AI가 만든 쓰레기 코드”, 즉 AI slop임

  • AI가 멀쩡한 들여쓰기와 그럴듯한 변수명으로 말도 안 되는 코드를 뽑아내는 건 맞음
  • 다만 글쓴이는 여기서 한 번 비꼬듯 묻는다. “그럼 인간 개발자는 ChatGPT 나오기 전까지 전부 완벽한 코드만 썼나?”

• 글의 핵심은 AI가 나쁜 코드를 발명한 게 아니라, 나쁜 코드가 들어오는 속도와 양을 키웠다는 쪽에 가까움

  • 레거시 프로젝트, 테스트 없는 기능 수정, 수천 줄짜리 함수, 디버깅용 alert 난사 같은 건 AI 이전에도 흔했음
  • 그래서 문제를 “AI냐 인간이냐”로 보면 빗나감. 진짜 문제는 팀이 쓰레기 변경을 막을 장치를 갖고 있느냐임

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

• 글쓴이는 인도 다국적 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 코딩 도구가 들어오면 이 구조가 더 중요해져요. 생성 속도가 빨라질수록 낮은 품질의 변경도 더 빨리 들어올 수 있어서, 병합 전에 막는 장치가 없으면 팀의 기술 부채가 눈에 띄게 빨리 불어나요.