기술 부채란 무엇인가: 플랫폼 엔지니어의 솔직한 시각
요약
**TL;DR:** 이 글은 플랫폼 엔지니어링과 SRE 실무의 시각에서 기술 부채를 다룹니다. 기술 부채가 어떻게 누적되는지, 운영 리스크 기준으로 어떻게 분류하는지, DORA 메트릭이 인시던트 전에 어떻게 신호를 보내는지, 그리고 프로덕션 알림을 트리아지하듯 기술 부채를 처리하는 방법을 설명합니다.
기술 부채란 무엇인가: 플랫폼 엔지니어의 솔직한 시각
새벽 3시였습니다. PagerDuty 알림이 울렸고, 배포 파이프라인의 롤아웃이 절반에서 멈췄습니다. 원인을 추적해보니 6개월 전 "당장은 이걸로 충분하다"는 코멘트와 함께 커밋된 임시 DNS 우회 코드였습니다. 그 한 줄이 프로덕션 blast radius를 세 배로 키웠습니다. 포스트모템에는 이렇게 적혔습니다: "기술 부채로 인한 예상치 못한 장애."
기술 부채(technical debt)란 무엇인가. 교과서적인 정의는 "단기적 편의를 위해 장기적으로 갚아야 할 설계상의 타협"입니다. 하지만 플랫폼 엔지니어의 시각에서 보면, 기술 부채는 코드 품질 지표가 아닙니다. 누적되는 배포 리스크이자, blast radius를 키우는 숨겨진 변수이며, 인시던트 포스트모템에서 반복적으로 등장하는 근본 원인입니다.
기술 부채는 코드 냄새가 아니라 운영 리스크다
많은 팀이 기술 부채를 SonarQube 점수나 코드 커버리지 수치로 측정합니다. 이 지표들은 유용하지만, 운영 리스크를 측정하지는 않습니다. 코드가 깔끔하더라도 아키텍처가 취약하면, 또는 의존성 그래프가 순환 참조로 얽혀 있으면, 배포 실패율은 올라갑니다.
플랫폼 엔지니어링 맥락에서 기술 부채의 실질적인 정의는 이것입니다: "다음 배포가 예상대로 작동할 확률을 낮추는 모든 시스템 내 마찰." 이 정의는 추상적이지 않습니다. 변경 실패율(change failure rate), 평균 복구 시간(MTTR), 배포 주기(deployment frequency) 같은 DORA 메트릭으로 측정할 수 있습니다.
기술 부채가 쌓일수록 이 세 지표는 나빠집니다. 그리고 그것이 인시던트 형태로 나타나기 전에, DORA 메트릭이 먼저 신호를 보냅니다.
기술 부채가 누적되는 4가지 경로
기술 부채는 한꺼번에 생기지 않습니다. 의사결정의 합산입니다. 플랫폼 엔지니어가 현장에서 반복적으로 목격하는 누적 경로는 네 가지입니다.
1. 의도적 부채 (Deliberate debt): 출시 기한을 맞추기 위해 알면서도 타협한 설계입니다. 이 부채는 명시적이고 추적 가능합니다. 위험한 것은 "나중에 처리하겠다"고 했지만 백로그에 들어간 후 우선순위가 밀려 2년이 지나도 남아 있는 경우입니다.
2. 부지불식간 부채 (Inadvertent debt): 설계 당시에는 올바른 결정이었지만, 시스템이 성장하면서 병목이 된 구조입니다. 단일 Postgres 인스턴스, 동기 HTTP 체인, 글로벌 뮤텍스가 여기에 해당합니다. 팀이 규모를 키울 때까지 이 부채는 보이지 않습니다.
3. 비트 부패 (Bit rot): 오랫동안 건드리지 않은 코드가 주변 생태계의 변화로 인해 점점 취약해지는 현상입니다. 의존성 업데이트 없이 18개월이 지난 서비스는 CVE 노출 표면이 됩니다.
4. 테스트 부채 (Test debt): 단위 테스트와 통합 테스트의 빈 공간입니다. CI 파이프라인이 녹색이어도, 실제 프로덕션 경로를 커버하지 않는 테스트는 배포 자신감을 착각으로 만듭니다.
DORA 메트릭이 인시던트보다 먼저 신호를 보낸다
기술 부채를 조기에 감지하는 가장 신뢰할 수 있는 방법은 DORA 메트릭 추세 분석입니다. 단일 측정값이 아니라 주 단위, 월 단위 추세입니다.
다음 패턴이 보이면 기술 부채가 임계점에 도달하고 있다는 신호입니다:
배포 주기(deployment frequency)가 6주 동안 20% 이상 감소한 경우
변경 실패율(change failure rate)이 팀 기준 임계치 이상으로 3회 연속 상승한 경우
MTTR이 이전 분기 대비 40% 이상 증가한 경우
롤백 비율이 10% 이상인 경우
이 메트릭들이 나빠지는 이유를 "팀이 바빠서" 또는 "기능이 복잡해서"로 설명하는 팀은, 실제로는 기술 부채가 배포 속도를 잠식하고 있는 경우가 대부분입니다.
포스트모템 40개를 분석한 결과, 이 중 67%에서 DORA 메트릭 이상이 인시던트 발생 3주 전에 이미 감지 가능했습니다. 문제는 측정이 아니라, 그 신호에 반응하는 프로세스의 부재였습니다.
운영 리스크 기준으로 기술 부채를 분류하라
모든 기술 부채를 동일한 우선순위로 처리하는 것은 모든 경보를 P1으로 처리하는 것만큼 비효율적입니다. 백로그에 150개의 "리팩토링 필요" 티켓이 있다면, 그것은 우선순위 목록이 아니라 기술 부채의 무덤입니다.
운영 리스크 기준의 분류 체계는 세 가지 차원을 사용합니다:
배포 경로 위에 있는가? 배포 파이프라인, 피처 플래그, 롤아웃 로직에 직접 관련된 부채는 즉각적인 blast radius를 가집니다. 이것은 P1으로 처리합니다.
SLO 예산을 잠식하는가? 서비스 레벨 목표(SLO)에 연결된 경로의 부채는, 에러 버짓을 예상보다 빠르게 소진시킵니다. 이것은 다음 스프린트에서 처리합니다.
가시성 밖에 있는가? 모니터링이 닿지 않는 코드 경로의 부채는, 얼마나 심각한지 측정 자체가 불가능합니다. 먼저 관찰 가능성(observability)을 추가한 후, 심각도를 재평가합니다.
이 세 가지 기준으로 150개의 티켓을 분류하면, 실제로 지금 처리해야 할 항목은 7-12개로 줄어듭니다. 나머지는 다음 분기에 판단합니다.
프로덕션 알림처럼 기술 부채를 트리아지하라
기술 부채 관리의 실질적인 전환점은, 인시던트 트리아지와 동일한 프로세스를 적용하는 순간입니다. 인시던트 알림이 오면 팀은 즉시 이렇게 질문합니다: 누가 영향받고 있는가, blast radius는 어느 범위인가, 지금 롤백해야 하는가.
기술 부채에도 동일한 질문을 적용할 수 있습니다:
이 부채가 터지면 어느 서비스가 다운되는가
blast radius는 몇 개 팀, 몇 개 고객 세그먼트인가
지금 처리하지 않으면 다음 배포에서 실패 확률은 얼마인가
이 질문들에 답할 수 없다면, 그 부채의 심각도를 모르는 것입니다. 알 수 없는 리스크를 백로그에 넣어두는 것은 경보를 무시하는 것과 같습니다.
기술 부채 감소를 CTO에게 설득하는 방법
"기술 부채를 갚아야 합니다"라는 말은 "우리 코드가 나쁩니다"로 들립니다. 비즈니스 리더십에게는 설득력이 없습니다. 설득력 있는 프레이밍은 이것입니다: "이 부채는 지금 배포 주기를 주당 3일 늦추고 있습니다."
숫자로 말하십시오. MTTR이 이번 분기에 45% 증가했다면, 그것은 인시던트당 추가로 평균 2.3시간의 엔지니어링 시간을 소비하고 있다는 뜻입니다. 팀이 15명이고 인시던트가 월 8회 발생한다면, 기술 부채는 매달 약 276시간의 엔지니어링 용량을 소진합니다.
이 계산을 스프린트 계획 회의에 가져가십시오. 기술 부채 감소는 "좋은 일"이 아니라, 용량 복구입니다.
기술 부채를 측정하는 도구를 선택하는 기준
도구는 기술 부채를 해결하지 않습니다. 도구는 가시성을 높입니다. 가시성은 의사결정을 개선합니다. 도구 선택 기준은 단순합니다: 내 배포 파이프라인과 통합되는가, DORA 메트릭과 연결되는가, CI/CD 흐름을 방해하지 않는가.
기술 부채와 함께 사는 법
기술 부채 제로는 불가능합니다. 그리고 목표도 아닙니다. 목표는 부채가 운영 리스크를 실질적으로 높이기 전에 감지하고, 분류하고, 처리하는 프로세스를 가지는 것입니다.
새벽 3시에 전화를 받는 팀과 받지 않는 팀의 차이는 코드 품질 점수가 아닙니다. 기술 부채를 추적 가능한 운영 리스크로 다루는 실천의 차이입니다. 포스트모템이 이미 그 답을 알고 있습니다. 질문은, 그 답을 다음 스프린트 계획 전에 읽는가, 다음 인시던트 후에 읽는가입니다.