Vibe Coding 확산이 만드는
두 개의 그림자
Slop 현상과 토큰 과소비의 구조적 분석

개념 정의

1.1 Vibe Coding — "코드가 존재한다는 사실을 잊어버리는" 코딩

Vibe Coding은 2025년 2월 Andrej Karpathy(OpenAI 공동 창업자, 전 Tesla AI 리더)가 명명한 개발 방식으로, 개발자가 자연어 프롬프트로 LLM에게 의도를 전달하고 생성된 코드를 검토 없이 수용하면서 결과물 중심으로 반복하는 실천을 말한다.

Collins Dictionary는 2025년 올해의 단어로 Vibe Coding을 선정했고, Merriam-Webster는 2025년 3월 이를 "slang & trending" 용어로 등재했다. Y Combinator 2025년 겨울 배치의 25% 스타트업이 코드베이스의 95%를 AI로 생성했다.

1.2 Slop 현상 — 기술적으로 동작하나 구조적으로 열화된 코드

AI Slop은 "저품질 AI 생성 콘텐츠"를 가리키며, 소프트웨어에서는 컴파일되고 테스트를 통과하지만 장기 유지보수성·아키텍처 일관성·보안이 결여된 코드를 지칭한다.

Baltes et al. (2026, arXiv 2603.27249)의 정성 분석(Reddit/Hacker News 15개 스레드, 1,154개 포스트)은 Slop을 세 클러스터로 체계화했다:

Slop의 공통 증상

• 과도하게 장황한 구현, 중복 로직
• 비효율적 알고리즘과 자원 사용
• 일관성 없는 아키텍처 패턴
• 빈약하거나 없는 문서
• 숨겨진 보안 취약성
• "올바름의 착시(illusion of correctness)": 코드가 깔끔해 보이고 기본 테스트는 통과하지만 엣지 케이스·비즈니스 요구·실제 스케일에서 실패

1.3 토큰 과소비 · 비용 비효율화

토큰 과소비란 LLM 기반 코딩 도구 사용 시 생산적 출력 대비 소비되는 컨텍스트·프롬프트·히스토리 토큰의 양이 과도해지는 현상이다.

Anthropic의 공식 Context Engineering 문서는 근본 원인을 다음과 같이 설명한다:

원인 분석

2.1 Slop 발생의 구조적·인지적 원인

구조적 원인

인지적 원인

2.2 토큰 과소비의 기술적·행동적 원인

기술적 원인

1. 시스템 프롬프트·도구 정의 재전송: 대부분의 토큰은 프롬프트가 아닌 반복 전송되는 시스템 프롬프트, 도구 설명, 대화 히스토리, RAG 청크, 로그에서 발생 (Medium)
2. Context Rot로 인한 컨텍스트 불신: 컨텍스트가 길어지면 성능이 저하 → 자주 리셋 → 매번 배경 정보를 다시 로딩하는 악순환 (Anthropic)
3. MCP 도구의 토큰 폭탄: Playwright MCP 같은 도구는 단일 호출에서 많은 토큰을 소비하지만 비용이 투명하게 공개되지 않음

행동적 원인

1. Prompt-first 습관: 개발자들은 컨텍스트 설계보다 프롬프트 문구 수정에 집중하지만, 실제 비용은 컨텍스트 폭발(context explosion)에서 발생
2. 세션 리셋 회피: 구독자들은 "모니터링 필요 없음" 메시지를 신뢰하여 세션을 길게 유지 → 한 세션에서 더 많은 토큰 낭비

2.3 Cowork vs 개인 개발 환경 비교

Northeastern 대학 연구진의 "AI's Social Forcefield" 논문은 더 미묘한 메커니즘을 제시한다. AI는 단순한 도구가 아니라 팀의 언어·인지·사회적 조율을 재구성하는 사회적 역장(social forcefield)으로 작동하며, 같은 모델을 쓰는 구성원들은 동일 어휘·사고 구조로 수렴하여 인식론적 다양성(epistemic diversity)이 침식된다.

현상 유형화

3.1 Slop 유형 분류 — 코드 품질 저하 패턴

GitClear의 211M 라인 종단 분석(2020-2024):

6가지 Slop 유형

3.2 토큰 낭비 유형 분류

3.3 Cowork 환경 특유의 증폭 요인

영향 분석

4.1 단기 생산성 vs 장기 품질 — 실증 데이터

단기 생산성 개선 증거

장기 품질 저하 증거

4.2 조직·팀 차원의 영향

배치 크기 증가와 하류 병목

Faros: 평균 PR 크기 51.3% 증가, PR당 편집 파일 59.7% 증가. 전 DORA 리드 Laura Tacho: "AI가 리스크를 도입하는 것은 쓰레기 코드 때문이 아니다. 배치 크기가 커지기 때문이다." (InfoQ)

실제 장애 사례

오픈소스 생태계 영향

2026년 1월 "Vibe Coding Kills Open Source" 논문: LLM은 훈련 데이터에 많이 등장한 대형 확립된 라이브러리로 수렴 → 신생 OSS 도구의 유기적 발견 과정이 사라지고 동질화가 진행된다.

4.3 개인 개발자 차원의 영향

대응 전략

5.1 기술적 전략 — 토큰 최적화·컨텍스트 관리

컨텍스트 엔지니어링 원칙 (Anthropic)

1. 컨텍스트를 유한 자원으로 대우: "어떤 구성의 컨텍스트가 원하는 행동을 일관되게 유도하는가"를 설계 문제로 취급
2. 정보 통화 관리: 시스템 프롬프트, 도구 정의, MCP, 외부 데이터, 메시지 히스토리의 큐레이션
3. 점진적 공개(Progressive Disclosure): 필요한 시점에 필요한 정보만 로드

Claude Code 공식 권장 패턴

토큰 절감 실무 기법

5.2 조직·프로세스적 전략

DORA AI Capabilities Model — 7가지 필수 요소

팀 단위 Cowork 거버넌스

• 버전 관리되는 규칙 파일: CLAUDE.md, .cursorrules, AGENTS.md를 저장소에 커밋하여 전 팀원의 AI가 동일 규칙을 따르도록 강제 (Cursor)
• PR 크기 제한: 더 엄격한 통제, 개발 환경에서의 조기 품질 게이트
• AI 사용 공시 의무: PR 설명에 AI 사용 여부·이유 기록
• 'Trust but verify' 문화: DORA 2025는 30%가 AI 코드 신뢰도가 낮다고 보고하는 것을 "성숙한 도입의 신호"로 해석

리뷰 프로세스 재설계

• AI 사전 스캔 + 인간 논리·아키텍처 리뷰: AI가 스타일·포맷·기본 버그를 사전 필터링, 인간 리뷰어는 논리·아키텍처·보안에 집중
• 정적 분석 도구 통합: CodeQL, SonarQube 등으로 CI에 AI 생성 코드 검증 내재화
• 보안 정책: AI에 자격 증명 공유 금지; 민감 파일에 대한 AI 접근 제한

5.3 개인 개발자 전략 — AI 의존도 관리·역량 유지

시사점 (Implications)

6.1 기업·조직 관점

1. "AI 도입률"은 잘못된 KPI: 단순 채택률보다 AI 정책·내부 플랫폼·데이터 생태계의 성숙도가 결정적
2. 단기 ROI의 함정: 단기 속도 메트릭으로 ROI를 평가하면 Slop이 감추어지고 장기 부채만 쌓인다
3. 거버넌스 설계: 병목이 리뷰에서 하류 배포 파이프라인으로 이동 → CI/CD 용량 증설, 품질 게이트 재설계 필요
4. 측정의 방법론적 주의: 텔레메트리 기반 측정과 자기 보고 서베이를 병용 필수

6.2 팀 관점

6.3 개인 개발자 관점

두 가지 Vibe Coding이 있다 (Simon Willison):

결론 — 왜 이런 현상이 발생하는가

인과 사슬

프롬프트 비용 감소 → 생산 볼륨 증가 → 리뷰·검증 용량 초과 → 게이트 통과(31.3% 무리뷰 증가) → 낮은 품질 코드 병합 → 기술 부채 누적(중복 4배·처닝 2배) → 장기 속도 저하(METR 19% 감속) → 인시던트 증가(Faros 인시던트-PR 3배)

Cowork 증폭

• 외부화 가능한 비용 — 개인이 만든 Slop을 팀이 부담
• 공유 컨텍스트의 부재 — 각 세션이 고립
• 리뷰 병목의 급성장 — 선형적 리뷰 용량이 지수적 생산을 따라가지 못함
• AI 사회적 역장 — 인식 다양성 침식

토큰 낭비와 Slop의 동전 양면

컨텍스트 폭발 → 토큰 낭비 → Context Rot → 결과 품질 저하(Slop 촉진). 반대로 Slop 제거를 위한 재작성은 추가 토큰 소비. 두 현상은 단일 현상의 두 얼굴이다.

한계 (Limitations)

• METR 연구의 일반화 한계: n=16 숙련 OSS 개발자, 단일 모델 세대(2025년 2-6월 Sonnet 3.5/3.7). 더 나은 모델·더 높은 AI 경험 수준에서는 결과가 바뀔 수 있다.
• Faros·Lightrun 데이터의 자기 선택 편향: 벤더 고객은 "AI 도입 문제를 측정하려는" 집단일 수 있다.
• Cowork 증폭 명제의 증거 구조: 단일 RCT가 아니라 여러 독립 증거의 수렴으로 지지된다. 방향은 강건하되 정량적 효과 크기는 추정 범위가 넓다.
• 한국 컨텍스트 데이터 부족: 주로 영미권 연구·사례 기반. 한국 분산 협업 환경의 고유 특성에 따른 차이는 별도 연구가 필요하다.
• 모델·도구의 급변: 보고서 기준일(2026-04-24) 이후의 모델 세대 변화로 일부 수치는 빠르게 노후화될 수 있다.

출처 (Sources)