기술 부채를 숫자로 말하는 법

결론부터 말하겠습니다. "리팩터링 해야 합니다"가 통하지 않는 이유는 상대가 기술을 몰라서가 아니라, 그 문장이 의사결정에 필요한 정보를 하나도 담고 있지 않기 때문입니다. 무엇을 얼마나 쓰면, 무엇이 얼마나 좋아지고, 안 하면 무엇이 얼마나 나빠지는지가 없습니다. 예산을 배분하는 사람 입장에서 이건 제안이 아니라 감상입니다. 반대로 부채를 이자·원금·리스크 세 개의 숫자로 옮겨 놓으면, 그때부터는 기술 논쟁이 아니라 투자 판단이 됩니다. 그리고 투자 판단에는 "이번엔 하지 않는다"라는 정당한 답도 포함됩니다. 이 글은 그 환산 절차와 보고 형식, 그리고 갚지 않기로 결정하는 방법에 대한 것입니다.

한 가지 미리 못을 박겠습니다. 여기서 말하는 "숫자"는 정밀한 회계 수치가 아닙니다. 자릿수와 순위가 맞으면 충분합니다. 3인·일과 30인·일을 구분하는 것이 목적이지, 12인·일과 14인·일을 구분하는 것이 목적이 아닙니다. 소수점을 맞추려다 측정 자체를 착수하지 못하는 경우를 자주 봅니다. 목표는 정확한 값이 아니라 비교 가능한 값이고, 비교 가능하려면 항목마다 같은 방식으로 재야 합니다. 방식의 일관성이 값의 정밀도보다 훨씬 중요합니다.

왜 "리팩터링 해야 한다"는 반려되는가

같은 말이 반려되는 데에는 몇 가지 구조적인 이유가 있습니다. 화법의 문제가 아니라 정보 구조의 문제입니다.

1. 비용은 구체적이고 편익은 추상적이다

리팩터링을 제안하는 순간, 듣는 사람의 머릿속에는 "개발자 몇 명 × 몇 주"라는 아주 구체적인 비용이 즉시 계산됩니다. 반면 편익은 "코드가 깨끗해집니다", "유지보수가 쉬워집니다" 같은 형용사로 들어옵니다. 구체적인 비용과 추상적인 편익이 붙으면 결과는 언제나 같습니다. 미뤄집니다. 편익을 같은 단위(인·일)로 옮기지 않는 한 이 비대칭은 사라지지 않습니다.

2. 부채 은유가 절반만 쓰인다

기술 부채라는 은유의 핵심은 "빚을 졌다"가 아니라 "이자가 계속 나간다"입니다. 그런데 대부분의 제안은 원금(고치는 데 드는 비용)만 말하고 이자(안 고쳤을 때 매 분기 새어 나가는 비용)를 말하지 않습니다. 이자를 말하지 않으면 상대에게 이 안건은 "지금 돈 쓰고 나중에 좋아지는 것"으로 보입니다. 이자를 말해야 비로소 "지금 안 쓰면 계속 돈이 새는 것"이 됩니다. 은유를 절반만 쓰면 설득력도 절반만 남습니다.

덧붙이자면 이 은유가 처음 제안됐을 때의 초점은 흔히 알려진 것과 조금 다릅니다. "대충 짠 나쁜 코드"보다는 "그동안 알게 된 것을 코드에 아직 반영하지 못한 상태"에 가까웠습니다. 이 구분은 실무에서 꽤 유용합니다. 처음부터 잘못 짠 코드보다, 도메인 이해가 바뀌었는데 구조가 예전 이해에 머물러 있는 코드가 이자를 훨씬 많이 물기 때문입니다. 후자는 코드 품질 도구로는 거의 잡히지 않고, 변경 리드타임에서만 드러납니다.

3. 부채가 하나의 덩어리로 제시된다

"우리 시스템에 부채가 많습니다"는 항목이 아니라 감정입니다. 승인할 수 있는 단위가 아니라는 뜻입니다. 조직은 프로젝트를 승인하지 상태를 승인하지 않습니다. 부채는 반드시 개별 항목으로 쪼개져야 하고, 각 항목은 독립적으로 승인·보류·기각될 수 있어야 합니다. 쪼개는 기준은 코드 구조가 아니라 "이것만 따로 착수해서 따로 끝낼 수 있는가"입니다. 이 질문에 답할 수 없으면 아직 항목이 아니라 주제입니다.

4. 기술적 옳음을 근거로 쓴다

"이건 안티패턴입니다", "레이어가 잘못됐습니다"는 개발자들 사이에서는 강력한 근거지만, 회의실 밖으로 나가면 근거가 아닙니다. 옳음은 근거가 아니라 취향으로 번역되어 도착합니다. 옳기 때문에 고쳐야 한다는 주장은, 옳지 않은데도 몇 년째 잘 돌아가고 돈을 벌고 있는 시스템이 세상에 널려 있다는 반례 앞에서 무너집니다.

세 개의 숫자로 나눈다: 이자, 원금, 리스크

부채 항목 하나를 잡았으면 다음 세 가지를 각각 따로 추정합니다. 이 셋은 성격이 다르고, 섞으면 판단이 흐려집니다.

세 축을 나누는 이유는 각각이 다른 결정을 유도하기 때문입니다. 이자가 크면 지금 갚는 게 이득이고, 원금이 크면 쪼개서 갚아야 하고, 리스크가 크면 갚는 대신 막는 것(모니터링, 폴백 경로, 복구 절차 검증)이 더 나은 선택일 수 있습니다. 셋을 한 덩어리로 뭉치면 이 구분이 사라지고, 결국 "부채 점수"라는 아무 결정도 유도하지 못하는 값 하나만 남습니다.

회수 기간: 두 숫자를 붙이는 지점

이자와 원금이 나오면 곧바로 하나의 파생값을 계산할 수 있습니다. 회수 기간 = 원금 ÷ 분기당 이자입니다. 원금이 12인·일이고 분기 이자가 4인·일이면 세 분기면 본전입니다. 이 값 하나가 대화를 크게 단축합니다. 우선순위 논쟁 대부분은 "그래서 언제 본전이 되는가"에 대한 답이 없어서 길어지기 때문입니다.

단, 회수 기간에는 반드시 짝이 되는 질문이 붙습니다. 그 모듈이 회수 기간보다 오래 살아남는가. 회수에 여섯 분기가 걸리는데 그 시스템이 네 분기 뒤 폐기 예정이라면, 그 항목은 계산상 갚으면 손해입니다. 이 한 줄을 같이 적어 두면 "기술적으로는 맞지만 지금은 안 한다"는 결론이 감정 없이 나옵니다.

이자를 재는 법: 이미 있는 데이터부터

이자 추정에서 가장 흔한 실패는 새로운 측정 도구를 도입하려다 착수 자체가 늦어지는 것입니다. 대부분의 조직은 이미 이자를 계산할 원재료를 가지고 있습니다. 버전 관리 저장소, 이슈 트래커, 온콜·장애 기록입니다.

변경 비용의 편차

같은 크기의 기능이 어떤 모듈에서는 며칠, 어떤 모듈에서는 몇 주가 걸립니다. 이 편차 자체가 이자입니다. 이슈 트래커에서 최근 몇 개 분기의 작업을 모듈별로 묶고, 착수부터 배포까지의 리드타임 분포를 봅니다. 특정 모듈이 유독 긴 꼬리를 가지고 있다면 그 모듈이 이자를 물고 있는 것입니다. 평균만 보지 말고 상위 구간을 보십시오. 부채의 비용은 평균이 아니라 꼬리에서 발생합니다. 평균 리드타임은 멀쩡한데 분기마다 한두 건이 몇 배로 튀는 모듈이 가장 위험합니다. 그 튀는 건들이 일정 약속을 깨뜨리는 주범이기 때문입니다.

재작업과 되돌림

배포 후 되돌린 횟수, 핫픽스 비율, 리뷰에서 반려되어 다시 짠 횟수는 모두 이자입니다. DORA에서 말하는 변경 실패율과 같은 계열의 지표인데, 조직 전체가 아니라 모듈 단위로 쪼개서 봐야 부채 항목에 연결됩니다. 전사 평균은 보고서에는 예쁘지만 의사결정에는 쓸모가 없습니다. "우리 변경 실패율이 어떻다"로는 아무 항목도 승인되지 않습니다.

핫스팟: 자주 바뀌는 곳 × 복잡한 곳

부채가 아픈 곳은 "나쁜 코드"가 아니라 "나쁜 코드 중에 자주 건드리는 곳"입니다. 아무도 건드리지 않는 모듈은 아무리 지저분해도 이자가 0에 가깝습니다. 변경 빈도는 저장소에서 바로 뽑을 수 있습니다.

# 최근 1년간 가장 자주 바뀐 파일 (변경 빈도 = 이자의 승수)
git log --since="12 months ago" --no-merges --name-only --pretty=format: \
  | grep -E '\.(java|kt|ts|vue)$' \
  | sort | uniq -c | sort -rn | head -30

이 결과를 그대로 믿기 전에 두 가지를 걸러야 합니다. 첫째, 대량 포매팅이나 의존성 일괄 수정 커밋이 순위를 통째로 흔듭니다. 그런 커밋이 있으면 기간을 조정하거나 해당 커밋을 제외하고 다시 뽑으십시오. 둘째, 파일을 옮기거나 이름을 바꾸면 그 이전 이력이 끊겨 실제보다 적게 잡힙니다. --follow는 경로를 하나만 지정했을 때만 동작하므로 이런 일괄 집계에는 쓸 수 없습니다. 최근 크게 이동한 디렉터리가 있다면 그 부분은 수동으로 보정해야 합니다.

여기에 파일 크기나 정적 분석 도구의 복잡도 점수를 곱하면 대략적인 핫스팟 순위가 나옵니다. 이 순위는 놀랍도록 자주 개발자들의 체감과 일치합니다. 일치한다는 게 중요합니다. 체감을 데이터로 확인해 주는 것이 이 작업의 목적이지, 새로운 진실을 발견하는 게 목적이 아닙니다. 만약 순위가 체감과 크게 어긋난다면 데이터가 왜곡됐거나(위의 두 함정) 체감이 특정 개인의 최근 경험에 치우쳐 있다는 뜻입니다. 어느 쪽인지부터 확인하고 넘어가야 합니다.

대기 시간

느린 빌드, 느린 테스트, 로컬에서 재현이 안 되는 환경은 매일 모든 개발자에게 부과되는 이자입니다. 계산이 가장 쉬운 항목이기도 합니다. 하루 빌드 횟수 × 대기 시간 × 인원으로 곧장 인·일이 나옵니다. 보여주기에도 가장 직관적입니다. 첫 보고에는 이렇게 계산 경로가 명확한 항목을 하나쯤 끼워 넣는 편이 좋습니다. 검산이 가능한 항목이 하나 있으면 나머지 추정치의 신뢰도까지 같이 올라갑니다.

다만 대기 시간 전부가 손실은 아니라는 점은 스스로 먼저 인정하고 들어가야 합니다. 빌드가 도는 동안 다른 일을 하기도 합니다. 그래서 이 항목은 할인율을 명시해서(예: 대기 시간의 절반만 손실로 계상) 쓰는 편이 안전합니다. 상대가 지적할 만한 허점을 먼저 깎아 놓는 것이, 나중에 통째로 반박당하는 것보다 훨씬 낫습니다.

추정이 안 되면 물어본다

정량화가 어려운 항목은 팀에 직접 묻습니다. "지난 분기에 이 부분 때문에 날린 시간이 대략 며칠인가"를 각자 따로 적게 하고 중앙값을 씁니다. 따로 적게 하는 게 중요합니다. 회의실에서 같이 추정하면 목소리 큰 사람의 숫자로 수렴합니다. 자기 보고는 편향이 있지만, 편향이 있는 숫자가 숫자 없음보다 낫습니다. 다만 보고서에는 출처가 자기 보고임을 명시해야 합니다. 출처를 숨긴 숫자는 한 번 반박당하면 그 뒤의 모든 숫자를 같이 잃습니다.

이자로 세면 안 되는 것

여기서 가장 흔한 과대 계상은 정상적인 개발 비용까지 이자에 넣는 것입니다. 기능을 추가하려면 원래 코드를 읽어야 하고, 테스트를 짜야 하고, 리뷰를 받아야 합니다. 이건 부채가 없어도 드는 비용입니다. 이자는 어디까지나 이 부채가 없었다면 들지 않았을 추가분입니다. 이 구분을 하지 않으면 이자 총합이 팀 전체 공수를 넘어서는 우스운 숫자가 나오고, 그 순간 보고서 전체가 폐기됩니다. 총합을 계산했으면 반드시 팀의 실제 분기 공수와 비교해서 자릿수가 말이 되는지 확인하십시오. 이 한 번의 검산이 대부분의 과대 추정을 걸러 냅니다.

원금과 리스크

원금은 단일 값이 아니라 범위로

상환 비용은 반드시 범위로 씁니다. 단일 값을 쓰면 그 값이 약속으로 굳어지고, 초과하는 순간 다음 부채 상환 제안의 신뢰가 사라집니다. 범위의 상한을 넉넉히 잡되, 상한이 하한의 몇 배로 벌어진다면 그건 추정이 아니라 무지의 표현입니다. 그럴 때는 숫자를 짜내지 말고 조사 작업을 별도 항목으로 먼저 올리십시오. "이 항목의 원금을 추정하기 위해 며칠을 쓰겠다"는 요청은 상환 요청보다 승인받기 훨씬 쉽습니다.

원금을 낮추는 방법도 같이 제시해야 합니다. 전면 교체가 아니라 경계를 먼저 긋고 뒤에서 조금씩 바꾸는 방식, 새 코드만 새 규칙을 따르게 하고 옛 코드는 건드릴 때만 고치는 방식은 원금을 여러 분기에 분산시킵니다. 큰 원금 하나보다 작은 원금 여럿이 승인될 확률이 훨씬 높습니다. 이때 함정도 같이 알고 있어야 합니다. 이런 점진 방식은 전환 기간 동안 두 구조가 공존하는 비용을 발생시킵니다. 이 공존 비용을 원금에 포함하지 않으면 나중에 초과로 잡힙니다. 그리고 점진 상환은 중간에 멈추면 상황이 시작 전보다 나빠질 수 있으니, 중단 시점과 조건을 미리 정해 두는 편이 안전합니다.

리스크는 가능성과 영향으로 쪼갠다

리스크 항목은 이자와 성격이 다릅니다. 평소에는 비용이 0이다가 터지면 크게 나갑니다. 지원이 끊긴 런타임, 아무도 이해하지 못하는 정산 로직, 복구 절차를 검증한 적 없는 백업, 한 사람만 아는 배포 과정 같은 것들입니다.

여기서는 정밀한 확률을 지어내지 말고 등급을 쓰십시오. 발생 가능성을 상·중·하로, 영향도 서비스 중단 범위와 지속 시간 기준으로 상·중·하로 나눕니다. 소수점 확률을 붙이는 순간 그 숫자의 근거를 대라는 질문이 나오고, 답할 수 없습니다. 더 중요한 건 영향의 서술 방식입니다. "장애가 납니다"가 아니라 "결제가 시간 단위로 멈추고 그동안의 주문은 수기로 처리해야 합니다"처럼, 기술 사고가 아니라 업무 중단으로 번역해서 써야 합니다. 이 번역을 하는 순간 듣는 사람이 스스로 금액을 계산합니다. 우리가 계산해 줄 필요도 없고, 계산해 주면 오히려 그 금액의 근거를 두고 싸우게 됩니다.

리스크 항목의 답이 항상 "상환"인 것은 아닙니다. 가능성을 낮추는 것(모니터링, 알림, 절차화)과 영향을 낮추는 것(격리, 폴백, 복구 연습)이 원금의 몇 분의 일로 가능한 경우가 많습니다. 이 대안을 같이 올리는 보고가 훨씬 신뢰를 받습니다. 대안 없이 "고쳐야 합니다"만 올리면, 상대는 우리가 다른 선택지를 검토하지 않았다고 판단합니다.

한 가지 더. 리스크 항목 중 "한 사람만 안다" 유형은 다른 항목과 다르게 다뤄야 합니다. 이건 코드를 고쳐서 없어지지 않습니다. 문서화와 인수인계, 두 번째 담당자 지정으로 줄이는 항목이고, 상환 단위도 인·일이 아니라 "몇 주에 걸친 병행 작업"입니다. 코드 상환 항목과 같은 표에 섞어 놓으면 둘 다 판단이 흐려집니다. 별도 구획으로 빼십시오.

도구가 뱉는 숫자를 그대로 옮기지 마라

정적 분석 도구 중에는 코드베이스의 "기술 부채"를 시간 단위로 환산해 주는 것들이 있습니다. 룰 위반 하나하나에 미리 정해 둔 수선 시간을 붙여 합산하는 방식입니다. 이 숫자는 유용한 참고값이지만, 그대로 보고서에 옮기면 두 가지가 틀립니다.

첫째, 그건 원금의 거친 추정치이지 이자가 아닙니다. 룰 위반의 합계는 그 코드를 얼마나 자주 건드리는지, 그래서 실제로 얼마나 아픈지와 아무 관계가 없습니다. 아무도 열지 않는 파일의 위반 수천 건이 총합의 대부분을 차지하는 일이 흔합니다. 앞서 말한 변경 빈도와 곱해서 보지 않으면 순위가 통째로 틀립니다.

둘째, "전사 부채 비율 몇 퍼센트" 같은 단일 지표는 아무 결정도 유도하지 못합니다. 이 숫자가 올라가면 질책의 근거가 되고, 내려가면 룰 설정을 바꿔서 내린 것 아니냐는 의심을 받습니다. 어느 쪽이든 항목 승인에는 도움이 되지 않습니다. 도구는 후보 항목을 찾는 데 쓰고, 숫자는 위에서 만든 세 축으로 다시 세우십시오. 도구 점수는 근거란에 보조 자료로 적으면 충분합니다.

부채 등록부: 관리의 단위

부채 항목은 위키 문서가 아니라 목록으로 관리해야 합니다. 형식은 이슈 트래커의 라벨이든 저장소 안의 텍스트 파일이든 상관없지만, 코드 옆에 두면 갱신될 확률이 조금 더 높습니다. 다음은 항목 하나를 어떤 필드로 적는지 보여주는 형식 예시입니다. 안의 값은 자리 표시자이니 그대로 옮기지 마십시오.

- id: DEBT-014
  title: 주문 상태 전이 로직이 3개 서비스에 중복
  이자: 분기당 N인·일 (상태 추가 시마다 3곳 동시 수정 + 누락으로 인한 재작업)
  원금: N~M인·일 (상태 머신 추출 후 단계적 치환)
  회수: 원금 / 분기 이자 = 약 K분기
  리스크: 가능성 중 / 영향 중 — 누락 시 일부 주문이 잘못된 상태로 고착, 수기 정정 필요
  근거: 이슈 트래커 라벨 order-state 재작업 건수(집계), 팀 자기보고(중앙값)
  수명: 이 모듈은 향후 로드맵에 유지로 잡혀 있음
  상태: 제안 | 승인 | 진행 | 완료 | 수용
  재검토일: YYYY-MM-DD

여기서 가장 자주 빠지는 항목은 근거와 재검토일입니다. 근거가 없으면 숫자가 반박당했을 때 방어할 수 없고, 재검토일이 없으면 "수용"으로 분류한 항목이 영원히 잊힙니다. 수명 필드도 빠지기 쉬운데, 이게 없으면 회수 기간을 계산해 놓고도 그 계산이 의미가 있는지 판단할 수 없습니다.

등록부 자체에도 관리 비용이 듭니다. 항목이 수십 개로 늘어나면 아무도 갱신하지 않게 됩니다. 상한을 두십시오. 살아 있는 항목 열 개 안팎이 적당하고, 그보다 늘어난다면 아래쪽은 수용으로 내리거나 통합해야 합니다. 등록부의 가치는 완전성이 아니라 갱신되고 있다는 사실에서 나옵니다.

우선순위 매트릭스

항목이 열 개를 넘으면 표만으로는 판단이 안 됩니다. 두 축으로 나눠 사분면을 만듭니다. 가로축은 원금(상환 비용), 세로축은 이자 + 기대 손실(방치 비용)입니다.

이 매트릭스의 진짜 효용은 우선순위 결정이 아니라 대화의 범위를 좁히는 것입니다. 논의해야 할 칸은 오른쪽 위 하나뿐입니다. 나머지 셋은 기술 조직이 알아서 처리하거나 알아서 포기하면 되는 영역입니다. 회의에 올리는 항목 수를 줄이는 것만으로도 승인율이 올라갑니다.

세 번째 축으로 전략적 정렬을 반드시 겹쳐 봐야 합니다. 이자가 크더라도 그 모듈이 몇 분기 뒤 폐기될 예정이라면 상환 가치는 급락합니다. 반대로 이자가 중간이어도 다음 분기 주력 제품이 그 위에 올라간다면 우선순위는 올라갑니다. 로드맵을 모르는 상태에서 매긴 부채 순위는 대체로 틀립니다. 순위를 확정하기 전에 제품 쪽과 한 번 맞춰 보는 30분이, 잘못된 순위로 한 분기를 쓰는 것보다 쌉니다.

보고 형식: 한 장

보고는 한 장으로 끝나야 합니다. 슬라이드 열 장짜리 기술 부채 보고서는 읽히지 않습니다. 순서는 다음과 같습니다.

1. 지금 새고 있는 총량 한 줄. 개발 역량의 어느 정도가 반복 작업에 쓰이고 있는지를 범위로 씁니다. 정확한 비율을 모르면 모른다고 쓰고 범위를 넓게 잡습니다.
2. 상위 3~5개 항목의 표. 항목명 / 방치 비용 / 상환 비용 / 회수 기간 / 리스크 등급 / 권고. 그 이상은 부록으로 뺍니다.
3. 이번 분기 요청. 항목 두세 개, 필요한 인원과 기간, 그리고 그 기간에 대신 밀리는 것이 무엇인지. 이걸 우리가 먼저 말해야 합니다. 상대가 먼저 묻게 하면 주도권을 잃습니다.
4. 기대 효과의 관찰 방법. "무엇이 어떻게 달라지면 성공으로 보겠는가"를 미리 적습니다. 리드타임 분포의 꼬리가 짧아진다, 특정 유형의 장애 알림이 사라진다처럼 관찰 가능한 형태여야 하고, 언제 확인할지도 같이 적습니다.
5. 이번엔 하지 않기로 한 것. 뒤에서 다시 다룹니다. 이 항목이 보고서의 신뢰도를 좌우합니다.

문장 수준의 원칙도 하나 있습니다. 기술 용어를 쓰되 결과로 이어 붙이십시오. "순환 참조가 있습니다"가 아니라 "순환 참조 때문에 이 영역을 건드리는 작업은 예측이 안 되고, 그래서 일정 약속을 못 합니다"입니다. 앞부분은 원인이고 뒷부분이 안건입니다. 앞부분만 말하고 뒷부분은 상대가 알아서 이해할 거라고 기대하는 것이 가장 흔한 실패입니다.

보고 주기는 분기 1회면 충분합니다. 매달 부채를 들고 가면 "저 조직은 늘 불평한다"가 되고, 1년에 한 번 들고 가면 항상 늦습니다. 그리고 형식은 고정하십시오. 지난 분기 항목이 이번 분기에 어떻게 됐는지가 같은 자리에 보이는 것이, 매번 새로운 분석을 들고 가는 것보다 훨씬 강한 신뢰를 만듭니다.

갚지 않기로 결정하는 것도 결정이다

이 글에서 가장 중요한 부분입니다. 부채 목록에 올라간 모든 항목을 갚아야 한다고 생각하는 순간, 목록은 죄책감의 저장소가 되고 아무도 보지 않게 됩니다.

수용은 실패가 아니라 유효한 결정입니다. 다만 조건이 있습니다.

• 명시적이어야 합니다. 방치와 수용은 다릅니다. 방치는 아무도 결정하지 않은 상태이고, 수용은 누군가 판단하고 기록한 상태입니다. 결과는 같아 보여도 다음 사고가 났을 때 조직이 배우는 것이 완전히 다릅니다.
• 만료일이 있어야 합니다. 영구 수용은 없습니다. 재검토일을 박아 두고, 그날이 오면 이자가 커졌는지 다시 봅니다. 부채의 이자는 대체로 시간이 갈수록 오릅니다. 그 위에 코드가 더 쌓이고, 사정을 아는 사람이 떠나기 때문입니다.
• 수용의 대가를 적어야 합니다. "이 항목은 갚지 않는 대신, 이 영역의 신규 기능은 기존 일정 대비 여유를 두고 잡습니다" 같은 식으로 운영 규칙에 반영합니다. 대가 없는 수용은 다음 분기에 일정 압박으로 되돌아옵니다.
• 누가 언제 어떤 근거로 수용했는지가 남아야 합니다. 기록의 목적은 책임 추궁이 아니라 그때의 판단 근거가 지금도 유효한지 확인하는 것입니다. 근거가 없으면 그 결정은 나중에 "아무도 몰랐다"로 기록됩니다.

수용해야 할 전형적인 경우들입니다. 폐기가 예정된 시스템, 사용자 수가 줄고 있는 기능, 외부 계약 때문에 어차피 바꿀 수 없는 인터페이스, 변경 빈도가 사실상 0인 영역, 그리고 고쳤을 때 아무도 그 차이를 느끼지 못할 영역. 마지막 항목은 특히 개발자가 놓치기 쉽습니다. 코드가 아름다워지는 것과 조직이 빨라지는 것은 다른 일입니다.

언제는 하지 말아야 하는가

이 방법론 자체를 도입하지 말아야 할 때도 분명히 있습니다.

1. 팀이 작고 제품 방향이 아직 흔들릴 때

초기 제품에서 코드는 자산이 아니라 가설의 부산물입니다. 다음 분기에 통째로 버릴 코드에 부채 등록부를 만드는 건 순수한 낭비입니다. 이 단계에서는 부채를 관리하지 말고 버릴 준비를 하십시오. 대신 딱 하나, 데이터 스키마와 마이그레이션 이력만 관리하십시오. 코드는 버릴 수 있어도 이미 쌓인 데이터는 버릴 수 없습니다. 초기 조직이 결국 지불하게 되는 진짜 원금은 대부분 거기서 나옵니다.

2. 부채가 문제가 아니라 요구사항 관리가 문제일 때

일정이 늘 깨지는 원인이 코드가 아니라 요구사항이 계속 바뀌기 때문인 경우가 꽤 많습니다. 이때 부채 보고서를 올리면 진짜 원인을 가려 주는 알리바이가 됩니다. 리드타임을 구간별로 뜯어봤을 때 지연의 큰 부분이 개발이 아니라 대기와 재정의에 있다면, 그건 부채 문제가 아닙니다. 다른 안건으로 가져가야 합니다. 이 확인은 항목을 만들기 전에 해야 합니다. 순서를 바꾸면 몇 주를 쓰고도 아무것도 개선되지 않습니다.

3. 측정이 개발자 평가로 흘러갈 위험이 있을 때

변경 실패율이나 핫스팟 데이터가 개인 평가에 쓰이기 시작하면 그 순간부터 모든 지표가 오염됩니다. 커밋을 잘게 쪼개고, 위험한 파일은 아무도 건드리지 않고, 재작업은 새 기능으로 위장됩니다. 조직 문화상 이 통제가 불가능하다면 측정을 시작하지 않는 편이 낫습니다. 오염된 지표로 내리는 결정은 지표 없이 내리는 결정보다 나쁩니다. 지표가 없으면 최소한 사람들이 자기 판단을 씁니다.

4. 이미 상환이 승인된 상태일 때

결정권자가 이미 "그거 고치세요"라고 말했는데 정교한 환산 보고서를 만드는 것은 착수를 늦추는 행위일 뿐입니다. 설득이 끝났으면 설득 자료 만들기를 멈추십시오. 이 경우에 필요한 건 환산이 아니라 착수 순서와 중단 조건입니다.

5. 항목 하나의 원금이 상시 예산 안에서 처리 가능할 때

며칠이면 끝나는 항목을 안건으로 올리는 것은 그 자체로 손해입니다. 승인 절차의 비용이 상환 비용보다 큽니다. 조직에 "이 규모 이하는 묻지 않고 고친다"는 기준선을 하나 만들어 두는 것이, 그 기준선 아래 항목들을 하나하나 보고하는 것보다 훨씬 가치가 큽니다.

6. 상환 결과를 검증할 수단이 아예 없을 때

회귀를 잡아 줄 테스트도, 재현 가능한 배포 절차도, 문제를 감지할 모니터링도 없는 상태에서 큰 상환에 착수하는 것은 부채를 사고로 바꾸는 일입니다. 이 경우 첫 번째 항목은 리팩터링이 아니라 안전망이어야 합니다. 바꿀 영역의 현재 동작을 고정하는 테스트를 먼저 두르고, 그 다음에 구조를 건드립니다. 순서를 반대로 하면, 상환 직후 발생한 장애가 "리팩터링 때문에 터졌다"로 기록되고 조직은 그 뒤로 오랫동안 상환 요청을 승인하지 않습니다. 이 실패는 회복이 대단히 어렵습니다.

실행 순서 체크리스트

1. 부채 항목을 개별 단위로 쪼갠다. "레거시 정리" 같은 이름은 항목이 아니다. 따로 착수해 따로 끝낼 수 있는가로 판정한다.
2. 지연의 원인이 정말 코드인지 먼저 확인한다. 대기와 재정의가 원인이면 여기서 멈춘다.
3. 각 항목에 대해 이자 / 원금 / 리스크를 각각 추정한다. 계산 경로가 명확한 항목(빌드 대기 등)을 최소 하나 확보한다.
4. 이자 총합을 팀의 실제 분기 공수와 비교해 자릿수를 검산한다.
5. 추정의 근거와 출처를 항목마다 적는다. 자기 보고면 자기 보고라고 쓴다.
6. 원금을 분기 이자로 나눠 회수 기간을 뽑고, 그 모듈의 남은 수명과 비교한다.
7. 로드맵을 확인하고, 곧 폐기될 영역의 순위를 낮춘다.
8. 매트릭스로 사분면을 나눈다. 올릴 것은 오른쪽 위 칸뿐이다.
9. 오른쪽 아래 칸은 수용으로 명시 기록하고 재검토일과 대가를 박는다.
10. 한 장 보고서를 만든다. 요청과 함께 대신 밀리는 것을 먼저 밝힌다.
11. 기대 효과의 관찰 방법과 확인 시점을 착수 전에 적어 둔다.
12. 분기마다 같은 형식으로 갱신한다. 형식을 바꾸지 않는 것이 신뢰를 만든다.

마지막으로 하나만 덧붙이겠습니다. 이 작업을 처음 하면 대체로 첫 보고는 반려됩니다. 그래도 손해가 아닙니다. 반려된 항목은 기록으로 남고, 그 항목이 실제로 사고를 냈을 때 조직은 "그때 판단이 이랬다"를 되짚을 수 있습니다. 기술 부채를 숫자로 옮기는 진짜 목적은 예산을 따내는 것이 아니라, 조직이 같은 실수를 두 번 하지 않도록 판단의 궤적을 남기는 것입니다. 승인은 그 부산물입니다.

같은 주제의 다른 글

• CTO 대행이 첫 2주에 실제로 하는 일
• 외주 개발 계약에서 반드시 정해 두어야 할 것들

맘소프트는 19년 넘게 금융 · 엔터프라이즈 · 모바일 시스템을 만들어 왔습니다. 여기 적는 글은 그 과정에서 실제로 부딪히고 해결한 것들입니다.

• 기술 블로그 전체 목록
• 이전 글 — CTO 대행이 첫 2주에 실제로 하는 일
• 다음 글 — 외주 개발 계약에서 반드시 정해 두어야 할 것들