개발팀이 느린 진짜 이유: 사람보다 코드베이스 드래그가 문제다

서론

개발팀 속도가 떨어지면 조직은 대개 사람부터 본다. 일정이 늘어지면 추정이 약하다고 말하고, 배포가 뜸하면 책임감이 느슨해졌다고 본다. 신규 입사자가 적응에 오래 걸리면 온보딩 자료 부족 정도로 끝내기 쉽다. 하지만 현장에서는 더 먼저 봐야 할 대상이 있다. 바로 그 팀이 매일 부딪히는 코드베이스가 얼마나 큰 마찰을 만들고 있는가다.

Ally Piechowski가 2026년 3월 31일 공개한 Why Your Engineering Team Is Slow (It's the Codebase, Not the People)는 이 질문을 정면으로 다룬다. 핵심은 단순하다. 보기 안 좋은 코드가 많다는 사실보다, 안전하게 변경하기 위해 팀이 추가로 지불하는 시간과 긴장 비용이 더 중요하다는 주장이다.

이번 글은 그 주장만 번역해 옮기지 않았다. DORA의 배포 성과 지표, Microsoft Research의 SPACE 프레임, Martin Fowler의 테스트 커버리지 글, METR의 개발자 생산성 연구를 함께 대조해 어느 부분이 검증 가능한 사실이고 어느 부분이 현장 경험에 가까운 해석인지 가려냈다. 읽는 기준도 분명하다. 이 글이 느린 팀을 다그치기 전에, 느린 경로를 먼저 보여 주는가다.

 

1. 먼저 검증: 어떤 자료를 대조했나

1. 원문 확인: Ally Piechowski, 2026년 3월 31일 게시, 다섯 신호 기반 Codebase Drag Audit 제시
2. DORA 확인: 배포 빈도, 변경 리드타임, 실패 복구 시간, 변경 실패율, 재작업 비율 제시
3. SPACE 확인: 생산성을 단일 수치로 재단하지 말고 만족도, 성과, 활동, 협업, 효율을 함께 보라는 틀 제시
4. Fowler 확인: 커버리지는 빈 구간 탐지 도구이지 테스트 품질 점수 그 자체가 아니라는 해석 제시
5. METR 확인: 2025년 연구에서 숙련 오픈소스 개발자가 AI 도구 사용 시 19% 더 오래 걸린 결과 제시

Piechowski의 글이 강한 이유는 현장 언어를 잘 붙잡기 때문이다. 다만 기사로 읽히려면 감각만으로는 부족하다. 그래서 이 글은 다섯 신호를 그대로 받아들이지 않고, 배포 성과를 보는 방법, 생산성을 측정하는 방식, 테스트 수치를 읽는 기준, 실제 개발 속도 연구를 차례로 대조했다.

대조 결과는 비교적 분명했다. DORA는 배포를 감정이 아니라 전달 성과로 보게 만들고, SPACE는 개발자 생산성을 한 수치로 재단하지 말라고 경고한다. Fowler는 높은 커버리지가 높은 신뢰를 보장하지 않는다는 점을 짚고, METR는 좋은 개발자도 복잡한 맥락 앞에서는 더 느려질 수 있음을 보여 준다. Piechowski의 글은 이 네 축을 실전 질문지로 압축한 셈이다.

2. 이 글의 핵심 주장: 기술부채보다 마찰 비용

1. 기술부채 관점: 코드 내부 결함과 낡은 구조 중심의 상태 진단
2. 마찰 비용 관점: 그 코드를 바꾸기 위해 팀이 추가로 내는 시간과 긴장 비용 중심의 운영 진단
3. 실무 차이: 리팩터링 목록보다 배포 지연, 우회 설계, 수동 검증, 온보딩 정체 같은 현상 관찰

Piechowski의 글이 던지는 핵심 차별점은 기술부채와 코드베이스 드래그를 구분한 대목이다. 기술부채라는 말은 넓고 익숙하지만, 투자 결정권자에게는 종종 추상적으로 들린다. 반면 코드베이스 드래그는 훨씬 구체적이다. 일정이 왜 길어졌는지, 왜 작은 수정에도 회의가 길어지는지, 왜 배포 전날이 늘 긴장 상태인지까지 비용 언어로 바꿔 준다.

이 차이는 현업에서 특히 중요하다. 보기 좋은 코드가 아니어도 팀이 빠르게 변경하고 안정적으로 배포하면 드래그는 낮을 수 있다. 반대로 파일 수가 적고 구조가 단정해 보여도 작은 수정 하나에 반나절 검증이 붙으면 드래그는 높다. 결국 판단 기준은 미관이 아니라 안전한 변경 비용이다.

3. 다른 생산성 프레임과 같이 보면 무엇이 보이나

1. DORA 공통점: 배포 공포를 처리량과 안정성 저하로 읽는 시선
2. SPACE 공통점: 사람 생산성을 단일 활동량으로 재단하지 않는 시선
3. Fowler 공통점: 커버리지 숫자를 신뢰도와 분리해 읽는 시선
4. METR 공통점: 입력 속도보다 맥락 이해와 검증 비용을 병목으로 보는 시선

Piechowski의 글을 혼자 읽으면 컨설턴트의 현장 노트처럼 느껴질 수 있다. 그런데 DORA, SPACE, Fowler, METR를 옆에 놓으면 글의 위치가 더 분명해진다. 이 글은 연구 보고서가 아니라, 이미 알려진 생산성 프레임을 팀 대화에 바로 쓸 수 있게 압축한 질문지에 가깝다.

1) DORA: 배포를 감정이 아니라 전달 성과로 읽는 기준

1. 핵심 초점: 배포 빈도, 변경 리드타임, 실패 복구 시간, 변경 실패율, 재작업 비율
2. Piechowski 접점: 배포 공포, 큰 묶음 릴리스, 롤백 부담, 배포 회피 습관
3. 기사 해석: 팀 문화처럼 보이는 긴장이 실제로는 전달 체계 문제일 가능성

DORA는 소프트웨어 전달 성과를 처리량과 불안정성으로 함께 본다. 이 틀을 적용하면 금요일 배포 농담은 단순한 유머가 아니라, 배포 빈도 하락과 복구 부담 확대라는 운영 신호로 바뀐다. Piechowski의 배포 공포 항목이 설득력을 얻는 이유도 여기에 있다. 감정처럼 보이는 현상이 사실은 측정 가능한 전달 체계 문제일 수 있기 때문이다.

처다.

2) SPACE: 느린 팀을 한 숫자나 한 사람 문제로 보지 말라는 기준

1. 핵심 초점: 만족도와 웰빙, 성과, 활동, 협업, 효율과 흐름의 다면 측정
2. Piechowski 접점: 느린 일정과 잦은 병목을 커밋 수나 티켓 처리량 하나로 설명하지 않는 시선
3. 기사 해석: 팀 속도를 사람 평가표 하나로 재단할수록 병목 위치를 놓칠 가능성

Microsoft Research가 소개한 SPACE 프레임은 개발자 생산성을 한 가지 수치로 재지 말라고 말한다. 활동량만 보면 늦어 보이지만, 실제로는 협업 비용이나 흐름 단절, 검증 부담이 더 큰 병목일 수 있다는 뜻이다. 이 지점은 Piechowski의 글과 정확히 닿는다. 사과가 붙는 견적이나 늦은 첫 PR은 활동량 부족보다 흐름 비용을 먼저 의심하게 만든다.

3) Fowler: 테스트 수치를 신뢰도와 구분하는 기준

1. 핵심 초점: 커버리지를 테스트가 비어 있는 구간 탐지 도구로 읽는 원칙
2. Piechowski 접점: 높은 커버리지와 낮은 회귀 방지 능력이 함께 나타나는 상태
3. 기사 해석: 숫자가 높아도 결제, 권한, 정산 경로가 비어 있으면 장식용 지표 가능성

Fowler의 글은 Piechowski가 말한 장식용 커버리지를 이해하는 데 가장 직접적인 기준을 준다. 테스트 커버리지는 도움이 되지만, 높은 수치만으로 안전망이 충분하다고 말할 수는 없다. 핵심 경로가 비어 있고 배포 전날 사람이 직접 확인해야 한다면, 커버리지는 품질 증거가 아니라 안심 효과에 가까워진다.

 

4) METR: 좋은 개발자도 나쁜 경로 앞에서는 느려질 수 있다는 기준

1. 핵심 초점: 숙련 개발자의 실제 작업 속도를 맥락 포함 조건에서 측정한 연구
2. Piechowski 접점: 좋은 엔지니어가 복잡한 저장소에서 더 느려 보이는 현상
3. 기사 해석: 키보드 속도보다 맥락 이해, 검토, 검증이 병목일 수 있다는 확인

METR 연구는 특히 흥미롭다. 익숙한 오픈소스 저장소에서 숙련 개발자가 AI 도구를 썼는데도 평균 시간이 줄지 않았고, 오히려 더 오래 걸렸다는 결과가 나왔다. 이 연구는 도구를 붙이면 무조건 빨라진다는 기대를 누그러뜨린다. Piechowski의 글도 같은 방향을 가리킨다. 느림의 원인은 종종 능력 부족이 아니라, 맥락과 검증 비용이 과도하게 높은 경로에 있다.

4. Piechowski의 다섯 신호를 기사형으로 다시 읽기

1) 사과가 먼저 붙는 견적

1. 판단 기준: 사흘짜리 일에 미리 2주를 붙이는 추정 습관
2. 숨은 비용: 폭발 반경 선반영, 연쇄 영향 조사, 수동 검증 부담
3. 우선 처방: 결합도가 높은 경로 분리, 영향 범위 문서화, 변경 단위 축소

이 신호는 일정 추정이 보수적이라는 뜻에 그치지 않는다. 개발자가 기능 크기보다 주변 위험을 먼저 가격표에 넣고 있다는 뜻에 가깝다. 알림, 결제, 권한, 배치 작업이 한 경로에 엮여 있으면, 빨리 끝날 일도 늦게 부를 수밖에 없다. 문제는 사람의 의욕이 아니라 폭발 반경이다.

2) 배포를 미루게 되는 팀

1. 판단 기준: 금요일 배포 금기, 수요일 이후 배포 회피, 대형 묶음 릴리스
2. 숨은 비용: 배포 빈도 하락, 복구 난도 상승, 변경 실패 부담 확대
3. 우선 처방: CI 시간 단축, 롤백 절차 정비, 작은 단위 배포 복원

배포가 무서워지면 팀은 변경을 묶는다. 묶인 변경은 다시 더 큰 위험을 만들고, 그 위험은 다음 배포를 더 미루게 한다. 이때 사람을 더 조이는 승인 절차는 해법이 되기 어렵다. 전달 경로를 짧게 만들고 복구를 쉽게 만드는 편이 먼저다.

3) 손대지 못하는 핵심 파일

1. 판단 기준: 모두가 피하는 파일, 작은 패치만 누적되는 영역, 우회 구현 상시화
2. 숨은 비용: 구조 왜곡, 신규 인력 학습 지연, 기능 분산 심화
3. 우선 처방: 금기 파일 설명서 정리, 주변 우회 경로 지도화, 작은 분리 작업 착수

오래된 서비스에는 거의 항상 금기 파일이 있다. 문제는 그 파일이 복잡하다는 사실보다, 아무도 제대로 손보지 못해 주변에 우회 구조가 계속 덧붙는다는 점이다. 시간이 지나면 핵심부는 죽은 구역이 되고, 기능은 가장자리에서 삐뚤어진 형태로 자란다. 이 신호가 보이면 복잡도 점수보다 팀 인터뷰가 더 빠르게 진실에 닿는다.

4) 숫자만 높은 테스트 커버리지

1. 판단 기준: 높은 수치와 낮은 실제 신뢰 동시 존재, 핵심 경로 수동 검증 상시화
2. 숨은 비용: 잘못된 안도감, 배포 전날 점검 확대, 회귀 장애 반복
3. 우선 처방: 결제·권한·정산 경로 재선별, 핵심 테스트 보강, 장식용 테스트 축소

대시보드에 80%가 찍혀 있어도 중요한 경로가 비어 있으면 그 숫자는 품질 지표가 아니라 장식일 수 있다. Piechowski가 이 항목을 강하게 집은 이유도 바로 여기에 있다. 테스트 수치와 실제 신뢰를 분리하지 못하면, 팀은 매번 숫자를 믿었다가 마지막 순간 사람 손으로 다시 검증하게 된다.

5) 늦어지는 첫 PR

1. 판단 기준: 새 개발자가 의미 있는 첫 변경을 올리기까지 과도한 시간 소요
2. 숨은 비용: 낡은 bin/setup, 깨진 시드 데이터, 문서 밖 환경 변수, 재현 불가 로컬 환경
3. 우선 처방: 환경 세팅 재검증, 필수 변수 정리, 첫 PR 경로 단축, 온보딩 기록 최신화

이 항목은 기존 인력이 익숙해서 보지 못하는 마찰을 가장 잘 드러낸다. 오래 일한 사람은 숨은 절차를 몸으로 외우고 있지만, 새 사람은 그 비용을 처음부터 맞는다. 그래서 첫 PR까지 걸리는 시간은 의외로 강력한 진단 지표다. README가 아니라 실제 기능 수정까지 걸리는 시간을 봐야 하는 이유도 여기에 있다.

5. 어디까지 사실이고 어디부터 해석인가

이 글에서 날짜와 지표, 연구 결과는 확인 가능한 사실이다. 반면 Piechowski가 제시한 점수 해석과 시간 기준은 현장 휴리스틱에 가깝다. 따라서 조직에 바로 적용할 때는 최근 분기 장애 이력, 배포 빈도, 리드타임, 최근 입사자 경험을 함께 붙여 보정하는 편이 안전하다.

검증 작업이 중요한 이유도 여기에 있다. 느린 팀을 다루는 글은 자칫 사람 평가나 문화 비난으로 흐르기 쉽다. 그런데 사실과 해석을 분리해 놓으면 질문 방향이 달라진다. “누가 느린가”보다 “어느 경로가 느린가”를 먼저 묻게 된다.

6. 이번 주에 돌려볼 코드베이스 드래그 점검표

1. 사과가 붙는 추정: 비슷한 규모 작업이 반복해서 두세 배로 불어나는지 확인
2. 배포 회피 습관: 배포 날짜를 의도적으로 늦추거나 특정 담당자에게만 맡기는지 확인
3. 금기 파일 존재: 손대지 않는 핵심 파일과 우회 구현 누적 구간이 있는지 확인
4. 장식용 테스트: 테스트 통과 뒤에도 핵심 경로를 사람이 매번 직접 밟는지 확인
5. 늦은 첫 PR: 신규 인력이 도움 없이 환경을 세우고 첫 기능 PR을 올릴 수 있는지 확인

Piechowski는 각 항목을 0점부터 2점까지 채점하라고 제안한다. 0점은 건강 구간, 1점은 경고 구간, 2점은 병목 구간이다. 이 방식은 거창한 설문 도구가 없어도 바로 쓸 수 있다. 엔지니어링 매니저, 테크 리드, 최근 입사자 한 명만 인터뷰해도 30분 안에 윤곽이 나온다.

점수 해석도 복잡하지 않다. 0점에서 3점은 정상 마찰 구간이지만, 특정 항목이 2점이면 그 항목은 별도 추적이 필요하다. 4점에서 6점은 팀이 이미 느림을 체감하는 단계다. 7점에서 10점은 코드베이스 자체가 병목인 상태라, 승인 강화나 채용 확대만으로는 풀기 어렵다. 이 구간에서는 경로를 직접 고치는 투자가 빠질 수 없다.

 

7. 무엇부터 고쳐야 하나

1. 최고 점수 1개 항목 선정: 가장 아픈 신호 1개 항목 우선 선택
2. 2주 복구 스프린트: 전면 재작성보다 좁은 개선 묶음 우선 편성
3. 측정 항목 2개 이상 설정: 배포 빈도, 추정 정확도, 첫 PR 시간 같은 체감 지표 연결
4. 문서화 병행: 복구 절차, 위험 파일 설명, 환경 변수 목록 정리
5. 다음 신호 이동: 첫 개선 효과 확인 뒤 차점 항목으로 이동

이 글이 실무적으로 유용한 이유는 처방도 과장하지 않기 때문이다. 배포 공포가 가장 심하면 CI 시간과 롤백 절차부터 손보고, 장식용 커버리지가 심하면 핵심 경로 테스트부터 다시 세우는 식이다. 늦은 첫 PR이 문제라면 가장 값싼 개선은 보통 환경 세팅 정비와 문서 최신화다.

중요한 점은 한 번에 다 고치려 하지 않는 태도다. 여러 신호가 동시에 보인다고 해서 전면 개편부터 선언하면 다시 큰 프로젝트가 된다. Piechowski의 제안처럼 최고 점수 신호 하나에 먼저 집중하고, 그 뒤 배포 빈도나 추정 정확도 같은 보이는 수치를 확인하는 편이 훨씬 현실적이다.

결론

Piechowski의 글을 DORA, SPACE, Fowler, METR와 함께 읽으면 메시지는 더 선명해진다. 느린 개발팀의 문제를 사람 성과표 하나로 설명하면 병목 위치를 놓치기 쉽다. 반대로 코드베이스 마찰 비용이라는 관점으로 보면, 일정이 늘어지는 이유와 배포가 늦어지는 이유, 신규 입사자가 막히는 이유가 같은 지도 위에 놓인다.

사과가 붙는 견적, 배포 공포, 금기 파일, 장식용 커버리지, 늦은 첫 PR은 모두 같은 방향을 가리킨다. 팀은 일을 안 하는 것이 아니라, 안전하게 바꾸기 위해 계속 우회 비용을 내고 있다. 그래서 해법도 사람을 더 압박하는 방식보다 변경 경로 복구, 테스트 신뢰 회복, 환경 정비 같은 직접 투자에 가까워진다. 느린 팀을 빠르게 만드는 첫걸음은 사람을 탓하는 일이 아니라, 잡아끄는 경로를 먼저 찾아 이름 붙이는 일이다.

참고 자료

• Why Your Engineering Team Is Slow (It's the Codebase, Not the People) - Ally Piechowski, 2026년 3월 31일
• DORA’s software delivery performance metrics - DORA, 2026년 1월 5일 기준 문서 확인
• The SPACE of Developer Productivity: There’s more to it than you think - Microsoft Research, 2021년 2월
• Test Coverage - Martin Fowler, 2012년 4월 17일
• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR, 2025년 7월 10일