기술 부채가 엔지니어링 팀의 속도를 끌어내리고 있는지 점수로 확인하는 2분짜리 인터랙티브 점검. 사람 문제와 코드 문제를 가르는 다섯 가지 신호를 소개합니다.
기술 부채가 엔지니어링 팀의 발목을 잡고 있는지 점수로 확인하는 2분짜리 인터랙티브 점검. 사람 문제와 코드 문제를 가르는 다섯 가지 신호를 소개합니다.
Ally Piechowski · 2026년 3월 31일 · 10분 읽기
한 고객사의 팀은 관리자 패널에 CSV 내보내기 기능을 추가하는 데 꼬박 일주일을 썼습니다. 엔지니어 두 명, 요구사항도 명확했고, 실제 작업만 놓고 보면 하루면 될 일이었습니다. 나머지 시간은 기존 코드를 안전하게 변경할 수 있을 만큼 이해하는 데 들어갔습니다. 저는 이것을 코드베이스 드래그라고 부릅니다. 코드베이스 때문에 모든 작업이 원래보다 더 오래 걸리는 상태를 말합니다. 이건 어떤 대시보드나 스프린트 보고서에도 드러나지 않습니다.
팀의 속도는 느려집니다. 그리고 리더십은 매번 이것을 사람 문제라고 판단합니다. 시니어들이 안일해졌을 수도 있고, 새로 들어온 사람들이 더 많은 지원이 필요할 수도 있다고 생각합니다. 그래서 조직을 재편하고, 프로세스를 추가하고, 때로는 사람을 내보내기도 합니다. 그런데 다음 팀도 똑같은 벽에 부딪힙니다.
애초에 사람 문제가 아니었기 때문입니다. 문제는 코드베이스였습니다.
버그도 아니고, 빠진 기능도 아닙니다. 심지어 대부분의 팀이 “기술 부채”라고 말할 때 떠올리는 그것만도 아닙니다. 기술 부채는 코드 자체에 무엇이 잘못되었는가에 관한 이야기입니다. 코드베이스 드래그는 그런 코드에서 어쨌든 일을 해내기 위해 팀이 치르는 비용입니다.
수년간 코드베이스 감사를 하면서 같은 다섯 가지 신호가 계속 반복해서 나타났습니다. 그래서 결국 이를 점수표로 정리했습니다. 코드베이스 드래그 점검입니다. 다섯 가지 신호를 각각 0점부터 2점까지 매깁니다. 총점이 4점 이상이라면, 다른 어떤 조치보다 먼저 코드에 직접 투자해야 합니다. (점검으로 바로 이동)
“이 코드베이스를 생각하면, 아마 2주쯤 걸릴 겁니다.” 저는 거의 모든 프로젝트에서 이런 말을 변형한 표현을 듣습니다. 기능 자체는 3일이면 될 일입니다. 그런데 엔지니어는 2주라고 말합니다. 리더십은 버퍼를 넣는다고 생각합니다. 아니면 그냥 느리다고 봅니다.
그들은 드래그 비용을 반영하고 있는 겁니다.
그들은 청구 모듈을 바꾸려면 알림 시스템도 건드려야 한다는 것을 압니다. 어느 시점엔가 아무도 기억하지 못하는 공유 서비스 객체를 통해 두 시스템이 결합되어 버렸기 때문입니다. 그 모듈을 마지막으로 수정한 사람이 결제 흐름을 3시간 동안 망가뜨렸다는 것도 압니다. default scopes 같은 숨겨진 패턴이나 깊게 중첩된 콜백 때문에, 코드베이스 절반을 읽어보지 않고서는 변경의 파급 범위를 예측할 수 없습니다. 그 추정치는 부풀린 것이 아닙니다. 솔직한 겁니다. 단지 이 코드베이스에서 일하는 비용이 그만큼 큰 것입니다.
추정치가 일의 “원래” 소요 시간보다 지속적으로 2-3배씩 길게 나온다면, 그건 추정 문제는 아닙니다. 당신의 엔지니어들은 이 코드베이스의 비용을 알고 있습니다. 다만 이제는 그걸 설명하려는 시도를 포기했을 뿐입니다.
당신의 팀이 마지막으로 금요일에 배포한 게 언제인가요? 이 질문에 웃음이 터진다면, 배포 공포가 있는 겁니다.
배포 공포는 묶음 배포로 나타납니다. 진행되는 대로 출시하는 대신, 팀은 릴리스를 크고 드문 배포로 묶습니다.
한 고객사의 팀에는 비공식 규칙이 있었습니다. 수요일 이후에는 배포하지 않는다는 규칙이었습니다. 아무도 문서로 적어두진 않았습니다. 다만 목요일 배포 세 번 연속으로 주말 장애를 일으킨 뒤 자연스럽게 규칙이 되었습니다. 롤백 전략도 없고, 신뢰할 수 없는 테스트, 45분이나 걸리는 배포 파이프라인까지 있었습니다. 당연히 목요일에는 배포를 멈추게 됩니다. 다른 선택이 있겠습니까? DORA는 변경 실패율 5% 미만으로 필요할 때마다 배포할 수 있는 팀을 최고 수준으로 정의합니다. 그런데 이 팀은 주 1회 배포를 하면서 숨을 죽이고 있었습니다.
“그 파일은 건드리지 마세요.” 저는 거의 모든 프로젝트에서 이 말을 듣습니다. 대개 첫 이틀 안에, 항상 아주 자연스럽게요. 마치 원래 다 이렇게 돌아가는 것처럼 말입니다.
before_action이 30개 달린 청구 컨트롤러. git log를 돌릴 때마다 항상 맨 위에 뜨지만 몇 년째 구조적으로는 아무도 손대지 않은 모델. 저는 models 디렉터리에서 어떤 파일이 반복적으로 수정되었는지 보려고 git log --oneline --since="2 years ago"를 실행합니다. 맨 위에 나오는 파일은 거의 항상 사람들이 경고했던 바로 그 파일입니다. 그리고 그 기록이 구조 개선 없이 작은 패치들로만 채워져 있다면, 그것이 모든 걸 말해줍니다. 사람들은 증상만 다루고 병 자체는 그대로 두고 있는 것입니다.
진짜 비용은 그 파일 자체가 아닙니다. 원래 그 모듈에 있어야 할 기능들이 대신 다른 곳에 구현된다는 데 있습니다. 새 엔지니어들도 첫 주 안에 그 파일을 피해야 한다는 사실을 알아차립니다. 시간이 지나면 코드베이스는 마치 나무가 울타리 기둥을 감싸며 자라듯, 그 죽은 구역을 피해 주변으로 자라납니다.
당신의 테크 리드들에게 어떤 파일을 리팩터링하라고 하면 가장 불안할지 물어보세요. 어떤 메트릭 대시보드보다 그 대화에서 더 많은 것을 알게 될 겁니다.
테스트 커버리지 80%. 대시보드는 건강해 보입니다. 하지만 돈을 다루는 세 개의 모델에는 테스트가 하나도 없고, 전체 커버리지 수치는 거의 깨지지 않는 serializer, helper, utility method에 대한 수백 개의 테스트가 떠받치고 있습니다.
저는 이것을 커버리지의 거짓말이라고 부르기 시작했습니다. 테스트 스위트가 실제 회귀를 잡기 위해서가 아니라 좋아 보이는 지표를 만들기 위해 존재하는 상태입니다. 테스트는 통과하는데도 운영 환경은 계속 깨집니다. 엔지니어들은 테스트 스위트를 신뢰하지 않게 되고, 배포 전에 핵심 경로를 수동 테스트하기 시작합니다. 그러면 배포 공포는 더 심해집니다.
CI는 40분이 걸리니, 개발자들은 로컬에서 테스트를 돌리지 않게 됩니다. 이제 커버리지 숫자는 두 번 거짓말을 하고 있습니다. 중요한 부분은 커버하지 못하고, 그나마 있는 테스트조차 실제로는 돌리지 않기 때문입니다. 버그는 더 늦게 드러납니다. 누군가 그것을 알아차릴 때쯤이면, 그 코드를 작성한 엔지니어는 이미 다른 작업 세 개쯤 깊이 들어가 있습니다.
커버리지 숫자는 잊으세요. 진짜 질문은 이것입니다. 마지막으로 테스트가 운영 배포 전에 실제 버그를 잡아낸 게 언제였나요? 팀이 그 답을 곰곰이 떠올려야 한다면, 그 테스트 스위트는 제 일을 하지 못하고 있는 겁니다.
새 엔지니어에게 노트북을 줬다고 해봅시다. 그 사람이 실제 변경이 담긴 pull request를 올리기까지 얼마나 걸리나요? README 수정 말고요. 실제 버그 수정이나 작은 기능 추가 말입니다.
건강한 코드베이스에서는 하루 이틀이면 됩니다. README에는 실제로 동작하는 설정 지침이 있고, 테스트 스위트도 로컬에서 실행됩니다. 드래그가 심한 코드베이스에서는 이게 2주 이상 걸리는 경우도 봤습니다. 한 고객사의 개발 환경 설정은 제가 개입하기 전까지 몇 주나 걸렸습니다. 제가 고친 뒤에는 새 개발자가 15분에서 20분 만에 작업을 시작할 수 있었습니다.
더 중요했던 건 이것입니다. 개발자들이 언제든 깨끗한 상태로 되돌릴 수 있게 되었다는 점입니다. 이전에는 개발 환경이 망가지면 모든 것을 처음부터 수동으로 다시 빌드하고 재설치해야 했습니다. 그래서 사람들은 실험하기를 두려워했습니다. 코드 앞에서 조심스럽게 움직이듯, 자기 개발 환경 앞에서도 살금살금 다녔습니다.
범인은 보통 설정의 부패입니다. bin/setup 스크립트는 마지막 개발 환경 변경 이후 한 번도 업데이트되지 않았습니다. 시드 데이터는 더 이상 존재하지 않는 테이블이나 컬럼을 참조합니다. 문서화되지 않은 환경 변수가 세 개쯤 있고, 앱이 부팅 중에 죽고 나서야 그런 게 있다는 사실을 알게 됩니다. 설정 부패를 막는 일은 비용이 적게 들지만, 아무도 책임지지 않기 때문에 조용히 썩어갑니다.
첫 커밋까지의 시간이 중요한 이유는, 이것만큼은 우회할 수 없는 신호이기 때문입니다. 기존 엔지니어들은 이미 문서화되지 않은 모든 단계를 몸으로 익혔습니다. 새로 들어온 사람은 생산적으로 일하기 전에 이 코드베이스가 얼마나 많은 축적된 지식을 요구하는지 정확히 드러내 줍니다.
이 다섯 가지 신호는 서로를 증폭시킵니다. 모든 작업에는 스탠드업에서 누구도 정확히 가리킬 수 없는 오버헤드가 붙습니다. 이전 직장에서는 이틀 만에 기능을 출시하던 엔지니어가 여기서는 일주일이 걸립니다. 왜 그런지 설명하려고 하면, 심지어 본인 귀에도 변명처럼 들립니다.
2025년 METR 연구에 따르면 숙련된 개발자들은 AI 도구를 사용할 때 오히려 19% 더 느렸습니다. 애초에 타이핑은 병목이 아니었습니다.
가장 뛰어난 엔지니어일수록 더 많이 느려집니다. 그들은 위험을 보기 때문입니다. 이 파일을 바꾸면 저 흐름이 깨질 수도 있다는 것을 압니다. 그래서 조심스럽게 움직이고, 방어적인 코드를 쓰고, 추정치에 여유를 둡니다. 경험이 덜한 엔지니어는 위험을 보지 못한 덕분에 더 빨리 배포할 수도 있지만, 그 결과 운영 장애를 일으켜 다음 스프린트에서 모두를 더 조심스럽게 만들 수 있습니다.
한 고객사는 10년 동안 여섯 개의 엔지니어링 팀을 거쳤고, 그 안에는 두 번의 전체 인수도 포함되어 있었습니다. 패턴은 매번 반복됐습니다. 리더십은 기능 개발을 밀어붙이고, 부채 정리는 건너뛰고, 코드는 점점 회복 불가능해 보이기 시작합니다. 누군가는 재작성이나 마이크로서비스 분리를 제안합니다. 그러면 상황은 더 나빠집니다. 이제 시스템이 하나가 아니라 둘이 되고, 원래 시스템은 여전히 남아 있기 때문입니다. 다음 팀은 그 모든 것을 그대로 물려받습니다.
리더십이 느림을 사람 문제로 읽을 때, 상황은 더 악화됩니다. 팀이 이미 고군분투하고 있는 마찰 위에 또 다른 프로세스를 덧씌우기 때문입니다. 실제로 도움이 되는 유일한 개입은 그 경로를 고치는 것입니다.
각 신호에 0점에서 2점까지 점수를 주세요. 각 행에서 당신의 팀을 가장 잘 설명하는 셀을 클릭하세요.
코드베이스 드래그 점검 점수표. 각 행에서 셀을 클릭해 점수를 매기세요.| Signal | 0 | 1 | 2 | | --- | --- | --- | --- | | Apology Estimate | 0 추정치는 대체로 정확하다 | 1 일부 작업은 지속적으로 예상을 초과한다 | 2 엔지니어들이 “이 코드베이스” 때문에 모든 추정치에 여유를 둔다 | | Deploy Fear | 0 팀은 스트레스 없이 매일 배포한다 | 1 배포는 가능하지만 추가 조율이나 주의가 필요하다 | 2 배포는 묶어서 하거나, 피하거나, “배포 담당자”가 필요하다 | | “Don’t Touch That” File | 0 코드베이스 대부분에 쉽게 접근할 수 있다 | 1 몇몇 파일은 피하지만 이해는 하고 있다 | 2 코드베이스 일부가 고치기보다 우회해서 개발하는 죽은 구역이 되었다 | | Coverage Lie | 0 테스트가 실제 회귀를 정기적으로 잡아낸다 | 1 테스트는 있지만 엔지니어들은 배포 전 핵심 경로를 여전히 수동 확인한다 | 2 테스트는 통과하지만 운영 환경은 여전히 자주 깨진다 | | Time to First Commit | 0 신규 입사자는 며칠 안에 의미 있는 코드를 커밋한다 | 1 설정에 일주일이 걸리고 옆에서 도와줘야 한다 | 2 신규 입사자는 기여하기까지 2주 이상이 필요하다 |
점수: 0 / 10
위에서 점수를 선택하세요.
이 점검은 개발자 생산성 문제에 이름과 숫자를 붙여줍니다. 로드맵을 통제하는 이해관계자 앞에 내밀 수 있는 형태가 됩니다.
가장 점수가 높은 신호부터 시작하세요. 모든 것을 한꺼번에 고치려 하지 마세요. 배포 공포가 2점이라면, 첫 투자는 CI 속도, 롤백 자동화, 더 작은 배포 단위에 가야 합니다. 사과하는 추정치 점수가 가장 높다면, 파급 범위가 가장 넓은 모듈들의 결합을 끊는 일부터 시작하세요. 코드베이스가 동시에 여러 Rails 버전 뒤처져 있다면, 버전 업그레이드가 그 투자를 정당화하는 강제 계기가 되는 경우가 많습니다. 첫 커밋까지의 시간이 2점이라면, 하루만 투자해 bin/setup을 고치고 환경을 문서화하는 일은 앞으로 채용할 때마다 충분히 보상받게 됩니다.
2주를 주세요. 가장 높은 신호 하나를 고르고, 집중 스프린트를 돌리고, 구체적인 무언가를 측정하세요. 배포 빈도가 가장 추적하기 쉽지만, 어떤 신호를 겨냥하느냐에 따라 추정 정확도나 첫 PR까지 걸리는 시간도 좋습니다. 재작성은 아닙니다. 팀이 체감할 수 있는 하나의 정밀한 투자입니다.
가장 어려운 부분은 그 투자를 승인받는 일입니다. 하지 않았을 때의 비용은 보이지 않기 때문입니다. 바로 여기서 이 점검이 제 값을 합니다. “이 세 모듈의 결합 때문에 모든 기능이 대략 두 배의 시간이 걸립니다”라는 말은 “기술 부채가 있습니다”와는 전혀 다른 대화가 됩니다.
7점 이상이 나왔다면, 그 구간이 바로 제 고객 프로젝트 대부분이 시작되는 지점입니다. 저는 보통 1주일짜리 코드베이스 감사로 시작해서 거기서부터 진행합니다. 기꺼이 함께 이야기해 보겠습니다.
이메일 메시지
