개요
**코드베이스 드래그(Codebase Drag)**는 코드베이스가 모든 작업을 필요 이상으로 오래 걸리게 만드는 현상. 스프린트 리포트·대시보드에 나타나지 않아 리더십이 “사람 문제”로 오인하는 악순환을 반복시킴. 수년간의 코드베이스 감사(Audit) 결과 동일한 5가지 신호가 반복적으로 나타남. 0~10점 진단 루브릭 제공.
- 출처: piechowski.io (2026-04)
- 핵심 메시지: “팀이 느린 진짜 이유는 사람이 아니라 코드베이스다”
코드베이스 드래그란?
실제 사례:
어드민 패널에 CSV 내보내기 추가
→ 실제 작업: 하루
→ 실제 소요: 2명 × 1주일
→ 나머지 시간: 기존 코드를 안전하게 수정하기 위한 '이해'
리더십 반응:
속도 저하 발견 → "인재 문제" 판단
→ 조직 개편, 프로세스 추가, 인력 교체
→ 다음 팀도 동일한 벽에 부딪힘 (반복)
진짜 원인:
버그 ❌
누락 기능 ❌
일반적 기술 부채 ❌
→ 코드베이스 그 자체 ✅
5가지 드래그 신호
1. 사과식 예측 (Apology Estimate)
3일 걸릴 기능에 2주 견적을 내놓는 상황
리더십: "일정 부풀리기"로 오해
실제 이유:
- billing 모듈 수정 → notification까지 영향
- hidden default scope
- 깊이 중첩된 콜백
- 코드 절반을 읽지 않으면 변경 영향 범위 예측 불가
판별:
견적이 일관되게 예상 대비 2~3배
→ 견적 산정 문제 ❌
→ 코드베이스 비용 문제 ✅
2. 배포 공포 (Deploy Fear)
증상:
- 금요일 배포 기피
- 큰 단위로 묶어 드물게 릴리즈
- "수요일 이후 배포 금지" 비공식 규칙
원인:
- 롤백 전략 부재
- 신뢰할 수 없는 테스트
- 45분짜리 배포 파이프라인
DORA 엘리트 기준:
변경 실패율 <5%, 필요 시 즉시 배포
현실: 주 1회 배포에 조마조마
3. “손대지 마” 파일 (Don’t Touch That File)
증상:
"그 파일은 건드리지 마" — 첫 2일 안에 등장
예시:
- 30개의 before_action이 달린 billing 컨트롤러
- git log 상단에 올라오지만 구조적 작업은 수년간 없음
진짜 비용:
해당 모듈에 있어야 할 기능이 다른 곳에 구현
→ 코드베이스가 죽은 구역을 중심으로 기형적으로 자라남
확인:
git log --oneline --since="2 years ago" -- <file>
→ 소규모 패치만 반복? = 증상만 치료, 병은 방치
4. 커버리지 거짓말 (Coverage Lie)
수치: 테스트 커버리지 80%
실제:
- serializer·helper·유틸리티 테스트가 수치를 떠받침
- 돈을 다루는 핵심 모델 3개는 테스트 전무
- 테스트 통과 → 프로덕션 깨짐
이중 거짓말:
1. 중요한 부분을 커버 ❌
2. CI 40분 → 개발자가 로컬 테스트 미실행 → 존재해도 실행 안 됨
진짜 질문:
"마지막으로 테스트가 프로덕션 전에 버그를 잡은 게 언제인가?"
5. 첫 커밋까지의 시간 (Time to First Commit)
측정:
신규 엔지니어에게 노트북 → 실제 버그 수정 PR까지 시간
건강한 코드베이스: 1~2일
드래그 코드베이스: 2주 이상 ⚠️
원인 (Setup Rot):
- bin/setup이 마지막 환경 변경 이후 업데이트 안 됨
- 더 이상 없는 테이블·컬럼을 참조하는 시드 데이터
- 앱 구동 시 충돌해야 알 수 있는 문서화 안 된 환경변수 3개
핵심 인사이트:
기존 엔지니어: 암묵적 지식 이미 내재화
신규 입사자만이: 코드베이스가 요구하는 암묵적 지식의 규모를 정확히 드러냄
코드베이스 드래그 감사 (진단 루브릭)
채점
| 신호 | 0점 (문제 없음) | 1점 (부분적) | 2점 (심각) |
|---|---|---|---|
| 사과식 예측 | 견적 정확 | 가끔 2배 | 일관되게 2~3배 |
| 배포 공포 | 언제든 배포 | 금요일 기피 | 배포 자체가 이벤트 |
| 손대지 마 파일 | 없음 | 1~2개 | 핵심 영역 전체 |
| 커버리지 거짓말 | 핵심 커버 | 수치만 높음 | 테스트 무의미 |
| 첫 커밋 시간 | 1~2일 | 3~5일 | 2주 이상 |
해석
| 총점 | 상태 | 대응 |
|---|---|---|
| 0~3 | 건강 | 유지 관리 |
| 4~6 | 드래그 발생 | 코드베이스에 직접 투자 선행 |
| 7~10 | 심각 | 즉각적 구조적 개입 (1주 감사 시작) |
좋은 엔지니어가 느려 보이는 역설
숙련 엔지니어:
✓ 위험을 더 잘 인식
✓ 더 신중히 움직임
✓ 견적을 넉넉히 잡음
→ 리더십 눈에는 "느린 사람"
덜 숙련 엔지니어:
✗ 위험을 보지 못함
✗ 더 빠르게 배포
✗ 프로덕션 장애 발생
→ 팀 전체가 더 조심하는 악순환
관련 연구: 2025 METR — 숙련 개발자가 AI 도구 쓸 때 19% 더 느렸음 → “타이핑이 병목이 아니었다”
→ 관련: 코딩 에이전트 하니스 & Hashline (“모델보다 인프라가 병목”)
악순환 패턴
[10년간 한 클라이언트]
리더십의 기능 요구
↓
부채 처리 건너뜀
↓
코드 회복 불가 상태
↓
리라이트 또는 마이크로서비스 분리 제안
↓
시스템이 둘로 늘어나면서 더 악화
↓
6팀 교체 (완전 인수 2번 포함)
↓
... 반복
핵심: 리더십이 속도 저하를 인재 문제로 읽으면 → 이미 마찰에 시달리는 팀에 프로세스만 추가 → 악화
대응 방법
원칙: 한 번에 하나, 가장 심한 것부터
✗ 모든 것을 동시에 고치려 하지 말 것
✓ 가장 높은 점수의 신호 하나부터 시작
신호별 대응
| 신호 | 첫 번째 행동 |
|---|---|
| 배포 공포 2점 | CI 속도 개선 + 롤백 자동화 + 소규모 배포 |
| 사과식 예측 1위 | 가장 넓은 blast radius 모듈 디커플링 |
| 첫 커밋 2점 | bin/setup + 환경 문서화에 하루 투자 → 모든 신규 채용에서 회수 |
| 커버리지 거짓말 | 핵심 모델 3개에 테스트 집중 |
| 손대지 마 파일 | 구조적 리팩터링 스프린트 |
측정 주기
2주 단위:
1. 최고 점수 신호 선택
2. 집중 스프린트
3. 구체적 수치 측정:
- 배포 빈도
- 견적 정확도
- 첫 PR까지 시간
투자 승인 받는 법
❌ "기술 부채가 있습니다"
→ 추상적, 반응 없음
✅ "이 세 모듈의 결합으로 모든 기능이 약 두 배 걸립니다"
→ 구체적 비용, 설득력
핵심:
하지 않았을 때의 비용이 보이지 않기 때문에
승인받기 어려운 것
→ 비용을 보이게 만들어야 함
Rob Pike 5가지 규칙과의 연결
| Pike 규칙 | 코드베이스 드래그 |
|---|---|
| 규칙 2: 측정이 먼저 | 감사 루브릭으로 측정 → 행동 |
| 규칙 4: 단순한 구조 | ”손대지 마 파일” = 복잡성의 결과 |
| 규칙 5: 데이터 우선 | 올바른 구조 = 명확한 변경 경로 |
→ 관련: Rob Pike 프로그래밍 5가지 규칙
다른 노트와의 연결
| 노트 | 연결점 |
|---|---|
| Rob Pike 프로그래밍 5가지 규칙 | 측정·단순함·데이터 우선 |
| 코딩 에이전트 하니스 & Hashline | ”인프라가 병목” |
| Open SWE (사내 코딩 에이전트) | 에이전트도 코드베이스 품질에 영향 받음 |
| Codex 플랫폼 (SDLC 가이드) | agents.md로 컨벤션 명시 |
| 아키텍처 엔지니어 | 시스템 구조 책임 |
| AI 시대 실행 비용 붕괴 | 실행 쉬워져도 코드베이스 품질은 여전히 핵심 |
| FOMO 무기화와 기술 조기 채택 | ”기술보다 본질이 중요” |
| FreeBSD | ”진화 vs 혁명” — 점진적 개선 |
메타 메시지
오늘까지 vault의 일관된 흐름:
"표면이 아니라 근본이 중요하다"
Rob Pike: "데이터 > 알고리듬"
Hashline: "하니스 > 모델"
스크린샷 루프: "피드백 루프 > 프롬프트"
OmniCoder: "학습 데이터 > 모델 크기"
실행 비용 붕괴: "마케팅 > 개발 속도"
코드베이스 드래그: "코드베이스 > 사람"
→ 모두 "보이지 않는 근본이 보이는 표면보다 결정적"