-
코드베이스 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주 코드베이스 감사부터 시작하는 수준