# 당신의 엔지니어링 팀이 느린 진짜 이유는 사람이 아니라 코드베이스다

> Clean Markdown view of GeekNews topic #28186. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28186](https://news.hada.io/topic?id=28186)
- GeekNews Markdown: [https://news.hada.io/topic/28186.md](https://news.hada.io/topic/28186.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-04T10:19:01+09:00
- Updated: 2026-04-04T10:19:01+09:00
- Original source: [piechowski.io](https://piechowski.io/post/codebase-drag-audit/)
- Points: 40
- Comments: 5

## Summary

팀이 느린 이유를 사람 탓으로 돌리기 전에, **코드베이스부터 점검하라**는 글입니다. 예측치 부풀리기, 배포 공포, "이 파일은 건드리지 마" 같은 **5가지 신호**를 0~2점으로 정량화한 진단 루브릭을 제시하는데요. 3일이면 될 기능에 2주 견적을 내는 건 개발자가 게을러서가 아니라, billing 모듈을 고치면 notification까지 깨지는 **모듈 결합 문제** 때문이라는 분석이 날카롭습니다. 숙련된 엔지니어일수록 위험을 잘 알아서 **오히려 더 느려 보이는 역설**도 인상적이고요. 4점 이상이면 코드베이스에 직접 투자가 필요하고, 7점 이상이면 즉각 개입이 필요한 수준이라고 합니다. 팀 리드나 매니저라면 한번 자가 진단해보시길 추천합니다.

## Topic Body

- **코드베이스 Drag** 는 모든 작업이 필요 이상으로 오래 걸리게 만드는 코드베이스 상태로, 대시보드나 스프린트 리포트에 드러나지 않아 리더십이 이를 '사람 문제'로 오해하는 악순환을 반복시킴  
- 수년간의 코드베이스 Audit 결과, 동일한 **5가지 신호**가 반복적으로 나타났으며 이를 0~2점으로 정량화한 진단 루브릭인 '코드베이스 드래그 감사'가 제시됨  
- 예측치 부풀리기, 배포 공포, 손대지 말라는 파일, 커버리지 거짓말, 첫 커밋까지의 시간 등 **5개 신호는 모두 코드베이스 품질 문제**에서 비롯되며 사람의 역량 부족과는 구별됨  
- 숙련된 엔지니어일수록 코드베이스의 위험을 더 잘 인지해 더 신중하게 움직이기 때문에 **오히려 더 느려 보이는 역설**이 발생하며, 이를 인재 문제로 오인하면 프로세스만 추가되는 역효과가 생김  
- 4점 이상이면 코드베이스에 직접 투자가 필요하며, 7점 이상은 **즉각적인 구조적 개입**이 요구되는 수준임  
  
---  
  
### 코드베이스 드래그란 무엇인가  
  
- **Codebase Drag**는 코드베이스가 모든 작업을 필요 이상으로 오래 걸리게 만드는 현상으로, 스프린트 리포트나 대시보드에 나타나지 않음  
  - 예시: 클라이언트 팀이 어드민 패널에 CSV 내보내기 기능을 추가하는 데 2명의 엔지니어가 1주일을 소비 — 실제 작업은 하루 분량이었으나, 기존 코드를 안전하게 수정하기 위한 이해에 나머지 시간 소요  
- 팀 속도 저하가 반복될 때 리더십은 **인재 문제**로 판단하고 조직 개편, 프로세스 추가, 인력 교체로 대응하지만, 다음 팀도 동일한 벽에 부딪힘  
- 문제의 근원은 버그도, 누락된 기능도, 일반적으로 말하는 기술 부채도 아닌 **코드베이스 그 자체**  
  
### 5가지 코드베이스 드래그 신호  
  
#### 1. 사과식 예측(Apology Estimate)  
  
- 실제로 3일 걸릴 기능에 엔지니어가 2주 견적을 내놓는 상황으로, 리더십은 이를 **일정 부풀리기**로 오해함  
- 실제 이유는 billing 모듈 수정이 notification 시스템까지 건드리는 **모듈 간 결합**과 변경 시 어디까지 영향이 미칠지 알 수 없는 구조 때문  
  - hidden default scope나 깊이 중첩된 콜백으로 인해 **변경 영향 범위(blast radius)** 를 코드 절반을 읽지 않으면 예측 불가  
- 견적이 일관되게 예상 대비 2~3배 걸린다면 견적 산정 문제가 아니라 **코드베이스 비용 문제**  
  
#### 2. 배포 공포(Deploy Fear)  
  
- 팀이 금요일 배포를 기피하거나, 배포를 묶어서 큰 단위로 드물게 릴리즈하는 패턴이 나타남  
- 한 클라이언트 팀은 수요일 이후 배포 금지 비공식 규칙을 운용 — 3번의 목요일 배포가 주말 장애로 이어진 후 생긴 관행  
  - **롤백 전략 부재**, 신뢰할 수 없는 테스트, 45분짜리 배포 파이프라인이 원인  
- **DORA** 기준 엘리트 팀은 변경 실패율 5% 미만으로 필요 시 즉시 배포하지만, 이 팀은 주 1회 배포에 조마조마하게 기다리는 상태  
  
#### 3. '손대지 마' 파일(Don't Touch That File)  
  
- 거의 모든 현장에서 "그 파일은 건드리지 마"라는 말이 첫 2일 안에 등장함  
  - 30개의 `before_action`이 달린 billing 컨트롤러, `git log` 상단에 올라 있지만 구조적으로는 수년간 손대지 않은 모델 등  
- `git log --oneline --since="2 years ago"` 실행 시 가장 많이 수정된 파일이 항상 경고받은 그 파일 — 소규모 패치만 반복되고 **구조적 작업이 없다면** 증상만 치료하고 병은 방치하는 상태  
- 진짜 비용은 해당 모듈에 있어야 할 기능이 **다른 곳에 구현**되는 것이며, 신규 입사자들은 첫 주 안에 해당 파일을 피하는 법을 터득함 — 코드베이스가 죽은 구역을 중심으로 기형적으로 자라남  
  
#### 4. 커버리지 거짓말(Coverage Lie)  
  
- **테스트 커버리지 80%** 라는 수치가 건강해 보이지만, 실제로는 거의 깨지지 않는 serializer·helper·유틸리티 테스트가 수치를 떠받치고 있으며 돈을 다루는 핵심 모델 3개는 테스트가 전무한 경우  
- 테스트 스위트가 회귀를 잡는 대신 **지표를 좋아 보이게 하기 위해** 존재하는 상태 — 테스트가 통과해도 프로덕션이 깨짐  
- CI 시간이 40분이라 개발자들이 로컬 테스트 실행을 중단 → 커버리지 수치가 두 가지 면에서 거짓말: 중요한 부분을 커버하지 못하고, 존재하는 테스트조차 실행되지 않음  
- 진짜 질문은 커버리지 숫자가 아니라 **"마지막으로 테스트가 프로덕션 전에 버그를 잡은 게 언제인가"**  
  
#### 5. 첫 커밋까지의 시간(Time to First Commit)  
  
- 신규 엔지니어에게 노트북을 주고 **실제 버그 수정이나 소규모 기능을 담은 PR**을 열기까지 걸리는 시간  
  - 건강한 코드베이스: 1~2일  
  - 드래그 중인 코드베이스: 2주 이상  
- 한 클라이언트는 개발 환경 세팅에 수 주가 걸렸으나, 수정 후 신규 개발자가 15~20분 만에 환경 구성 완료  
- 핵심 원인은 **setup rot(설정 부패)** — `bin/setup` 스크립트가 마지막 환경 변경 이후 업데이트되지 않음, 더 이상 존재하지 않는 테이블·컬럼을 참조하는 시드 데이터, 앱 구동 시 충돌해야 알 수 있는 문서화되지 않은 환경변수 3개  
- 기존 엔지니어들은 문서화되지 않은 절차를 이미 내재화했기 때문에 **신규 입사자만이 코드베이스가 요구하는 암묵적 지식의 규모를 정확히 드러냄**  
  
### 나쁜 코드베이스에서 좋은 엔지니어가 느려 보이는 이유  
  
- 5가지 신호는 **복합적으로 작용**하며, 모든 작업에 standup에서 지목할 수 없는 오버헤드를 더함  
  - 전 직장에서 이틀이면 기능을 구현하던 엔지니어가 이 코드베이스에서는 1주일이 걸리며, 그 이유를 설명하려 해도 변명처럼 들림  
- **2025년 METR 연구** 결과 숙련된 개발자들이 AI 도구를 쓸 때 19% 더 느렸음 — 타이핑이 병목이 아니었다는 증거  
- 최고의 엔지니어일수록 위험을 더 잘 인식해 더 신중히 움직이고, **견적을 넉넉히 잡음** — 덜 숙련된 엔지니어가 위험을 보지 못해 더 빠르게 배포했다가 프로덕션 장애를 일으켜 팀 전체가 더 조심해지는 악순환  
- 한 클라이언트는 10년간 6팀을 교체(2번의 완전 인수 포함) — 리더십의 기능 요구 → 부채 처리 건너뜀 → 코드 회복 불가 상태 → 리라이트 또는 마이크로서비스 분리 제안 → 시스템이 둘로 늘어나면서 더 악화의 패턴이 반복됨  
- 리더십이 속도 저하를 인재 문제로 읽으면 **이미 마찰에 시달리는 팀에 프로세스만 추가**하여 악화 — 실제로 도움이 되는 유일한 개입은 경로(path) 자체를 수정하는 것  
  
### 코드베이스 드래그 감사: 진단 방법  
  
- 5개 신호 각각을 0~2점으로 채점:  
  - **0점**: 문제 없음  
  - **1점**: 부분적 문제  
  - **2점**: 심각한 문제  
- **4점 이상**이면 다른 어떤 조치보다 코드베이스에 직접 투자가 선행되어야 함  
  
### 기술 부채가 팀을 잡아끌 때의 대응 방법  
  
- **가장 높은 점수의 신호 하나부터 시작** — 모든 것을 동시에 고치려 하지 말 것  
  - 배포 공포 2점: CI 속도, 롤백 자동화, 소규모 배포 단위 개선 우선  
  - 사과식 예측 1위: 가장 넓은 blast radius를 가진 모듈 디커플링 우선  
  - 첫 커밋 시간 2점: `bin/setup` 수정 및 환경 문서화에 하루 투자하면 이후 모든 신규 채용에서 회수 가능  
- Rails 버전이 여러 버전 뒤처진 경우 **버전 업그레이드**가 투자를 정당화하는 강제 함수(forcing function)가 될 수 있음  
- 2주 단위로 측정: 최고 점수 신호 선택 → 집중 스프린트 → 구체적 수치 측정 (배포 빈도, 견적 정확도, 첫 PR 시간 등)  
- 투자 승인을 받기 어려운 이유는 **하지 않았을 때의 비용이 보이지 않기 때문** — "기술 부채가 있다"보다 "이 세 모듈의 결합으로 모든 기능이 약 두 배 걸린다"가 훨씬 설득력 있는 대화  
- **7점 이상**은 일반적으로 1주 코드베이스 감사부터 시작하는 수준

## Comments



### Comment 54650

- Author: mbh023
- Created: 2026-04-05T00:24:25+09:00
- Points: 3

ㄹㅇ 레거시 프로젝트 암적존재  
차라리 처음부터 다시만드니만 못한것들이 있어요

### Comment 54654

- Author: hanje3765
- Created: 2026-04-05T02:39:47+09:00
- Points: 2

내 얘기니 ..?

### Comment 54643

- Author: maedk10
- Created: 2026-04-04T19:12:09+09:00
- Points: 2

유지보수 비용 절감에 정말 중요한 글로 보입니다

### Comment 54760

- Author: cronex
- Created: 2026-04-06T15:56:30+09:00
- Points: 1

이래서 새로 짜는게 더 빠른 경우가 생기기도 하죠.

### Comment 54699

- Author: kallare
- Created: 2026-04-05T21:49:48+09:00
- Points: 1

코드베이스를 정리하는게 장기적으로는 속도를 올리는 길이라는걸 모두가 알고는 있지만,  
잘 먹고, 운동하고, 잠 잘자면 건강해진다는 것과 같은 수준의 이야기죠