AI 슬롭 피하기: 바이브 코딩에서도 코드 품질 유지하기 (2026)

Jasmine, Claude Code를 매일 쓰고, 이 글을 쓸 수 있을 만큼 AI 슬롭을 출시하고(또 치워도) 온 개발자예요.

바이브 코딩은 말도 안 되는 속도를 안겨줘요. 하지만 AI에게 한 달만 코드를 맡겨본 사람이라면 누구나 같은 느낌에 부딪혀요. "아주 잘 돌아가는" PR을 머지했는데, 몇 주 뒤에 그게 엣지 케이스를 놓치고 있거나 아무도 요청하지 않은 추상화 계층을 세워두었다는 걸 발견하는 거죠. 그게 바로 AI 슬롭이에요. 이 글은 바이브 코딩에 반대하는 글이 아니에요. 이 용어가 처음이라면 먼저 바이브 코딩이 무엇인지부터 읽어보세요. 여기서 다루는 건, 바이브 코딩에 규율을 더해 품질을 지키는 방법이에요.

AI 슬롭이란? (그리고 소셜 미디어의 "AI 슬롭"과 어떻게 다른가)

AI 코드 슬롭은 AI가 생성한 코드로, 컴파일도 되고 테스트도 통과하지만 구조적으로 얕고, 프로젝트의 관례를 무시하며, 사람이 리뷰할 수 있는 속도보다 빠르게 기계적인 규모로 찍어내지기 때문에 그럼에도 코드베이스를 썩게 만드는 코드예요. "명백히 잘못된" 코드가 아니에요. 만약 대놓고 망가져 있다면 바로 알아챘을 거예요. 슬롭이 위험한 건 바로 맞아 보이기 때문이에요.

이 구분이 중요한 이유는, "AI 슬롭"이라는 표현이 두 방향으로 끌려가고 있기 때문이에요.

"AI 슬롭"의 두 가지 다른 의미:

1. AI 콘텐츠 슬롭 - 소셜 피드를 뒤덮는 대량 생산된 쓰레기 같은 영상, 이미지, 글이에요. Merriam-Webster는 바로 이 의미로 "slop"을 2025년 올해의 단어로 선정했어요(2025년 12월 15일 발표). "AI 슬롭"으로 찾게 되는 글의 대부분은 이 이야기예요.

2. AI 코드 슬롭 - AI가 만들어내는 저품질 코드로, 이 글의 주제예요. 이건 엔지니어링 관점이고, 솔직하게 다뤄지는 경우가 훨씬 적어요.

소셜 미디어 콘텐츠라는 의미를 찾아 오셨다면, 이 글은 맞지 않아요. AI가 쓴 코드가 맞아 보이는데 사실은 틀린 게 아닐까 걱정된다면, 계속 읽어보세요. 함께 보게 될 관련 용어: ai code slop, vibe slop, low-quality AI code.

AI 슬롭 코드의 6가지 신호 (분류)

모든 AI 코드가 슬롭인 건 아니에요. 하지만 슬롭에는 꽤 알아보기 쉬운 지문이 있어요. 제가 가장 자주 마주치는 저품질 AI 코드의 6가지 신호를, 빠르게 잡아낼 수 있도록 간단한 예시와 함께 정리했어요:

1. 맞아 보이는데, 가장자리에서 틀려요. 샘플 입력에서는 멀쩡한데 빈 문자열, 타임존, 음수, 페이지네이션의 마지막 페이지에서 깨져요. 예: 빈 배열을 전혀 처리하지 않아 0으로 나누는 평균 계산 함수.
2. 과도한 설계 / 불필요한 추상화. 5줄이면 될 일에 AI가 팩토리, 전략 패턴, 범용 계층까지 지어 올려요. 예: 날짜 문자열 하나를 포맷하려고 인터페이스 하나에 클래스 3개.
3. 레포 관례를 무시. 네이밍, 폴더 구조, 에러 처리가 코드베이스의 나머지 부분과 전혀 딴판이에요. 예: 프로젝트는 Result<T>를 쓰는데, AI는 여기저기서 예외를 던져요.
4. 존재하지 않는 API / 설정 / 패키지 환각. 없는 함수를 호출하거나, 잘못된 패키지 이름을 임포트하거나, 삭제된 설정 옵션을 써요. 예: import { parseDate } from 'date-fns' - 그런데 date-fns는 그런 이름을 내보낸 적이 없어요.
5. 구현을 그대로 따라 하는 테스트. 테스트가 기대되는 동작을 확인하는 게 아니라, 방금 생성된 바로 그 코드를 통과시키려고 작성돼요. 예: 반환값을 목(mock)해 놓고 그 같은 목에 대해 단언(assert)해요.
6. 하드코딩과 매직 값. 숫자, URL, 키가 설정이 아니라 로직 안에 그대로 박혀 있어요. 예: if (userId === 42), 또는 곳곳에 흩어진 3000 타임아웃.

AI 슬롭이 일반적인 기술 부채보다 나쁜 이유

사람이 만든 기술 부채는 보통 눈에 보여요. 당신(또는 동료)이 일부러 그 부분을 대충 처리했으니, 지저분한 코드가 어디 있는지 알죠. AI 슬롭은 세 가지 면에서 더 나빠요.

첫째, 완성된 것처럼 보여요. 코드는 깔끔하게 포맷돼 있고, docstring도 있고, 테스트도 있어요 - "좋은 코드"의 표면적 신호가 전부 갖춰져 있어서 뇌가 경계를 풀어버려요. 둘째, 기계적인 규모로 균일하게 퍼져요. 사람은 한 군데에서 대충 하지만, AI는 하루 오후 만에 40개 파일에 걸쳐 똑같은 방식으로 대충 해요. 셋째, 팀이 신뢰하는 모든 검사를 통과해요. Lint 초록불, 타입 초록불, 테스트 초록불 - 그 테스트마저 같은 코드를 따라 하도록 AI가 썼기 때문이에요.

걱정스러운 숫자 하나: CSET(Center for Security and Emerging Technology, "Cybersecurity Risks of AI-Generated Code", 2024)의 연구에 따르면, AI가 생성한 코드 스니펫의 거의 절반에 버그 또는 악용 가능한 보안 취약점이 들어 있었어요. 다시 말해, "돌아간다"는 건 "출시해도 안전하다"와 같은 말이 아니에요.

익숙한 시나리오: 당신이 작은 기능 하나를 추가해 달라고 하면, AI가 "친절하게도" 그럴듯해 보이는 패턴을 따라 관련된 파일 세 개를 리팩터링해요. PR은 초록불이고, 리뷰는 "그냥 리팩터링이니까" 하며 슥 훑고 지나가 머지돼요. 3주 뒤, 전혀 관련 없어 보이는 모듈에서 이상한 버그가 나타나요 - 그 패턴이 공유되는 함수의 동작을 몰래 바꿔놨기 때문이죠. 반나절을 들여 원인을 되짚어 보니, 근본 원인은 한참 전에 끼어든 무해해 보이는 슬롭 덩어리였던 거예요.

결과적으로, AI 슬롭은 전통적인 기술 부채보다 빠르게 쌓이면서도 더 잘 숨어요 - 드러날 즈음이면 이미 여러 계층에 스며들어 있어요. 게다가 패턴으로 퍼지기 때문에, 한 군데를 고치는 걸로는 거의 부족해요. AI가 흩뿌려 놓은 사본을 하나도 빠짐없이 찾아내야 해요.

바이브 코딩에서 AI 슬롭을 피하는 체크리스트

이게 핵심이에요. 막연히 "더 빡세게 리뷰하기" 대신, 바이브 코딩 루프의 4단계로 나눠서 봐요. 원한다면 출력해서 모니터 옆에 붙여두세요.

프롬프트를 쓰기 전에

• 프롬프트를 입력하기 전에 명확한 스펙 / 인수 기준을 적으세요. AI는 당신의 마음을 읽지 못해요. 빈칸을 추측으로 채우죠 - 그리고 추측이야말로 슬롭이 태어나는 곳이에요.
• 작고, 범위가 좁은 작업을 맡기세요. 한 번에 함수 하나, 엔드포인트 하나 - 리뷰하기 쉽고, 실수도 잡아내기 쉬워요.
• 컨텍스트를 불러오세요: 코딩 표준, 아키텍처, 기존 패턴, 그리고 당신의 CLAUDE.md 파일. 얇은 컨텍스트야말로 슬롭의 가장 큰 원인이에요.

코드를 생성하는 동안

• AI에게 레포의 관례를 따르라고(네이밍, 에러 처리, 구조) 지시하세요 - 프롬프트에서 분명하게 말하고, 알아서 추측하리라 기대하지 마세요.
• 환각과 싸우기 위해, 모든 API / 패키지 / 설정을 최신 문서에 대조해 검증하세요. AI가 한 번도 본 적 없는 함수를 호출한다면, 반증되기 전까지는 지어낸 것이라고 가정하세요.

머지하기 전에

• 모든 줄을 읽고 이해하세요. 절대 어길 수 없는 규칙: 이해하지 못한 코드는 절대 출시하지 않기. 어떤 줄이 왜 있는지 설명할 수 없다면, 아직 준비된 게 아니에요.
• "돌아가는가?"만이 아니라 로직 + 계약 + 아키텍처를 리뷰하세요. AI 코드를 리뷰하는 건 사람 코드를 리뷰하는 것과는 다른 일이에요 - 자세한 내용은 AI 코드를 제대로 리뷰하는 방법을 보세요.
• 테스트가 따라 하는 구현이 아니라 기대되는 동작을 확인하는지 점검하세요.
• Lint / 타입 / 커버리지를 CI 게이트로 유지하세요 - 다만, 초록불 CI가 슬롭이 없다는 증거는 아니라는 걸 기억하세요.
• AI가 방금 추가한 의존성과 라이선스를 확인하세요.

유지보수 단계

• "슬롭 카탈로그"를 만드세요: AI가 당신의 레포에서 자주 만드는 안티패턴을 기록하고, 그것을 프롬프트 템플릿과 CI 규칙에 다시 반영하세요. 코드베이스가 AI에게 더 많이 "가르칠수록", 슬롭은 줄어들어요.

이 섹션의 관련 용어: AI code checklist, context engineering. 어떤 체크리스트도 슬롭을 100% 없애지는 못해요 - 확률과 쌓이는 속도를 낮출 뿐이에요.

실제 예시: 슬롭 한 덩어리와 그 수정

할인 계산 함수로 구체적으로 살펴봐요 - 전형적인 "맞아 보이는데 틀린" 경우예요. AI의 첫 결과물은 이래요:

// BEFORE - AI slop: looks right, wrong on several edge cases
function applyDiscount(price, discountPercent) {
 const finalPrice = price - (price * discountPercent / 100);
 return finalPrice.toFixed(2);
}

// applyDiscount(100, 20) -> "80.00" ✓ seems fine

샘플 테스트는 통과하니, 쉽게 머지돼 버려요. 하지만: (1) 숫자가 아니라 문자열을 반환해서 다른 곳의 계산을 깨뜨려요. (2) 음수나 > 100 할인을 막지 않아요. (3) 금액 계산에서 부동소수점 반올림 오류에 부딪혀요. (4) 잘못된 입력을 처리하지 않아요. 수정한 버전은 이래요:

// AFTER - slop fixed: explicit contract, guarded edge cases
function applyDiscount(priceCents, discountPercent) {
 if (!Number.isInteger(priceCents) || priceCents < 0) {
 throw new Error('priceCents must be a non-negative integer (unit: cents)');
 }
 if (discountPercent < 0 || discountPercent > 100) {
 throw new Error('discountPercent must be within 0..100');
 }
 // Compute in cents (integers) to avoid floating-point rounding errors
 const discount = Math.round(priceCents * discountPercent / 100);
 return priceCents - discount; // returns a number (cents), not a string
}

핵심은 "수정된 코드가 더 길다"가 아니에요. 슬롭 버전이 말끔한 겉모습 뒤에 네 가지 잘못된 가정을 숨기고 있었다는 거예요. 계약을 이해하려고 읽을 때에야 - 반환 타입, 유효한 값의 범위, 금액을 다루는 방식 - 비로소 슬롭이 정체를 드러내요. 그래서 "돌아간다"만으로는 결코 충분하지 않아요.

컨텍스트 엔지니어링 - 슬롭을 줄이는 근본

머지 후에 슬롭을 고치는 건 비싸요. 컨텍스트 엔지니어링으로 처음부터 막는 게 훨씬 저렴해요: AI가 추측할 필요가 없도록 올바른 재료를 건네주는 거예요. 구체적으로는 코딩 표준, 아키텍처 지도, 레포의 기존 패턴, 그리고 프로젝트 관례를 적어둔 탄탄한 CLAUDE.md 파일. 작동 원리를 더 깊이 파고들고 싶다면, 컨텍스트 엔지니어링을 그 자체로 하나의 스킬로 다뤄보세요.

좋은 컨텍스트는 AI를 "회사 첫 출근한 뛰어난 개발자"에서 "이미 코드베이스를 아는 개발자"로 바꿔줘요. 같은 모델인데도 결과물의 품질은 완전히 달라져요 - 순전히 컨텍스트 하나 차이로요.

팀 규모에서는 여러 사람 사이에서 컨텍스트와 프로세스 기준을 일관되게 유지하기가 어려워요. 한 가지 방법은 Claude Code용 스킬, 서브에이전트, 표준 워크플로를 모아둔 기성 키트예요 - 예를 들어 Claude Code용 AgentKit 키트는 리뷰 관례, 구조, 패턴을 팀 전체가 공유할 수 있게 패키징해서, 컨텍스트와 기준이 사람마다 흔들리지 않게 해줘요. 직접 보고 싶다면 AgentKit 가격을 확인할 수 있어요(링크로 20% 할인). 어떤 도구도 당신 자신의 판단을 대신하지는 못해요 - 하지만 컨텍스트를 표준화하는 건 슬롭을 근본부터 줄이는 확실한 지렛대예요.

"테이스트" - AI가 대체할 수 없는 엔지니어링 판단력

결국 슬롭 예방을 100% 자동화할 수는 없어요. 실무자들이 테이스트라고 부르는 게 필요해요: AI가 방금 내놓은 것을, 설령 "돌아가더라도" 출시하지 말아야 할 때를 아는 감각이에요. 테이스트란 코드 한 덩어리를 보고 그게 6개월 뒤 어디서 아플지 내다보는 능력이에요.

코드를 쓰는 건 AI지만, 커밋된 모든 줄에 책임을 지는 건 사람이에요. 프로덕션에서 버그가 터졌을 때, "근데 AI가 그렇게 썼는데요"는 아무도 받아주지 않아요. 테이스트는 살 수도 없고, 프롬프트로 만들어낼 수도 없어요 - 실제로 읽고, 실제로 이해하고, 자신이 머지하는 것을 실제로 자기 것으로 책임질 때에만 생겨나요. 그게 바이브 코딩과 바이브 슬롭을 가르는 선이에요.

자주 묻는 질문 (FAQ)

코드의 AI 슬롭은 소셜 미디어 AI 슬롭과 어떻게 다른가요?

소셜 미디어 AI 슬롭은 AI가 대량 생산하는 콘텐츠(영상, 이미지, 글)예요 - Merriam-Webster가 "slop"을 2025년 올해의 단어로 뽑게 만든 흔한 의미죠. AI 코드 슬롭은 저품질 AI 코드예요: 컴파일도 되고 테스트도 통과하지만 구조적으로 얕고 코드베이스를 썩게 해요. 이 글은 두 번째 의미에 관한 거예요.

바이브 코딩은 항상 슬롭을 만드나요?

아니요. 바이브 코딩이 슬롭을 만드는 건 규율이 없을 때뿐이에요: 모호한 프롬프트, 불러오지 않은 컨텍스트, 그리고 읽고 이해하지 않은 코드를 머지하기. 규율 있는 바이브 코딩 - 명확한 스펙, 좋은 컨텍스트, 꼼꼼한 리뷰 - 이라면 품질을 지키면서 AI의 속도를 누릴 수 있어요.

제 AI 코드에 슬롭이 있는지 어떻게 알 수 있나요?

6가지 신호를 확인하세요: 맞아 보이는데 가장자리에서 틀림, 과도한 설계, 레포 관례 무시, 존재하지 않는 API/패키지 환각, 구현을 따라 하는 테스트, 그리고 하드코딩된 매직 값. 어떤 줄이 왜 있는지 설명할 수 없다면, 아마 슬롭이에요.

테스트와 Lint만으로 슬롭을 막을 수 있나요?

아니요. Lint와 테스트는 표면적인 오류를 잡지만, 슬롭은 자주 빠져나가요 - AI가 쓴 테스트는 같은 코드를 그대로 따라 할 수 있으니까요. 그래도 여전히 로직을 읽고 이해하며, 계약과 아키텍처를 사람의 눈으로 확인해야 해요.

슬롭을 줄이는 데 도움이 되는 도구나 키트가 있나요?

근본적인 해결책은 컨텍스트 엔지니어링이에요: CLAUDE.md 같은 파일을 통해 코딩 표준, 아키텍처, 패턴을 불러오는 거죠. 팀 규모에서는 Claude Code용 스킬/서브에이전트/표준 워크플로 기성 키트가 컨텍스트와 기준을 일관되게 유지하는 데 도움이 돼요. 하지만 도구는 어디까지나 보조일 뿐 - 최종 결정은 여전히 당신의 판단이에요.

아직 이해하지 못한 AI 코드를 출시해도 되나요?

아니요, 절대 안 돼요. 이건 슬롭을 피하기 위한 절대 어길 수 없는 규칙이에요: 코드가 왜 작동하는지 이해하지 못하면 유지보수도, 디버깅도 할 수 없고, 망가졌을 때 책임질 수도 없어요. 이해될 때까지 읽고, 그다음에 머지하세요.

결론: 규율 있는 바이브 코딩

AI 슬롭은 AI를 피할 이유가 아니라 - AI를 규율 있게 쓸 이유예요. 공식은 간단해요: AI의 속도 + 사람의 리뷰 규율 = 깨끗하고 빠른 코드. 뒤쪽 절반을 버리면, 순식간에 슬롭이 돼요. 계속 나아가려면 바이브 코딩이 무엇인지에서 기본기를 다시 짚고, AI 코드를 제대로 리뷰하는 방법에서 품질 관리를 벼려보세요. 코드를 쓰는 건 AI지만 - 테이스트와 책임은 여전히 당신의 몫이에요.