# 기술 부채란 무엇인가: 플랫폼 엔지니어의 솔직한 시각 URL: https://upstreamapi.com/ko/journal/gisul-buchae-ran Type: blog Locale: ko Published: 2026-09-26 Updated: 2026-09-26 --- > 플랫폼 엔지니어에게 기술 부채는 코드 품질 점수가 아닙니다. 배포 리스크이자 blast radius를 확대하고 DORA 메트릭을 잠식하는 운영상의 취약점입니다. ## 기술 부채란 무엇인가: 플랫폼 엔지니어의 솔직한 시각 새벽 3시였습니다. PagerDuty 알림이 울렸고, 배포 파이프라인의 롤아웃이 절반에서 멈췄습니다. 원인을 추적해보니 6개월 전 "당장은 이걸로 충분하다"는 코멘트와 함께 커밋된 임시 DNS 우회 코드였습니다. 그 한 줄이 프로덕션 blast radius를 세 배로 키웠습니다. 포스트모템에는 이렇게 적혔습니다: "기술 부채로 인한 예상치 못한 장애." 기술 부채(technical debt)란 무엇인가. 교과서적인 정의는 "단기적 편의를 위해 장기적으로 갚아야 할 설계상의 타협"입니다. 하지만 플랫폼 엔지니어의 시각에서 보면, 기술 부채는 코드 품질 지표가 아닙니다. 누적되는 배포 리스크이자, blast radius를 키우는 숨겨진 변수이며, 인시던트 포스트모템에서 반복적으로 등장하는 근본 원인입니다. ## 기술 부채는 코드 냄새가 아니라 운영 리스크다 많은 팀이 기술 부채를 SonarQube 점수나 코드 커버리지 수치로 측정합니다. 이 지표들은 유용하지만, 운영 리스크를 측정하지는 않습니다. 코드가 깔끔하더라도 아키텍처가 취약하면, 또는 의존성 그래프가 순환 참조로 얽혀 있으면, 배포 실패율은 올라갑니다. 플랫폼 엔지니어링 맥락에서 기술 부채의 실질적인 정의는 이것입니다: "다음 배포가 예상대로 작동할 확률을 낮추는 모든 시스템 내 마찰." 이 정의는 추상적이지 않습니다. 변경 실패율(change failure rate), 평균 복구 시간(MTTR), 배포 주기(deployment frequency) 같은 DORA 메트릭으로 측정할 수 있습니다. 기술 부채가 쌓일수록 이 세 지표는 나빠집니다. 그리고 그것이 인시던트 형태로 나타나기 전에, DORA 메트릭이 먼저 신호를 보냅니다. ![엔지니어링 팀이 기술 아키텍처를 검토하며 리팩토링 전략을 계획하는 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/4fe267-img-2.webp) ## 기술 부채가 누적되는 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개로 줄어듭니다. 나머지는 다음 분기에 판단합니다. ![개발자가 화면에 여러 오류 로그가 표시된 복잡한 레거시 코드를 검토하는 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/311630-img-3.webp) ## 프로덕션 알림처럼 기술 부채를 트리아지하라 기술 부채 관리의 실질적인 전환점은, 인시던트 트리아지와 동일한 프로세스를 적용하는 순간입니다. 인시던트 알림이 오면 팀은 즉시 이렇게 질문합니다: 누가 영향받고 있는가, blast radius는 어느 범위인가, 지금 롤백해야 하는가. 기술 부채에도 동일한 질문을 적용할 수 있습니다: - 이 부채가 터지면 어느 서비스가 다운되는가 - blast radius는 몇 개 팀, 몇 개 고객 세그먼트인가 - 지금 처리하지 않으면 다음 배포에서 실패 확률은 얼마인가 이 질문들에 답할 수 없다면, 그 부채의 심각도를 모르는 것입니다. 알 수 없는 리스크를 백로그에 넣어두는 것은 경보를 무시하는 것과 같습니다. ## 기술 부채 감소를 CTO에게 설득하는 방법 "기술 부채를 갚아야 합니다"라는 말은 "우리 코드가 나쁩니다"로 들립니다. 비즈니스 리더십에게는 설득력이 없습니다. 설득력 있는 프레이밍은 이것입니다: "이 부채는 지금 배포 주기를 주당 3일 늦추고 있습니다." 숫자로 말하십시오. MTTR이 이번 분기에 45% 증가했다면, 그것은 인시던트당 추가로 평균 2.3시간의 엔지니어링 시간을 소비하고 있다는 뜻입니다. 팀이 15명이고 인시던트가 월 8회 발생한다면, 기술 부채는 매달 약 276시간의 엔지니어링 용량을 소진합니다. 이 계산을 스프린트 계획 회의에 가져가십시오. 기술 부채 감소는 "좋은 일"이 아니라, 용량 복구입니다. ## 기술 부채를 측정하는 도구를 선택하는 기준 도구는 기술 부채를 해결하지 않습니다. 도구는 가시성을 높입니다. 가시성은 의사결정을 개선합니다. 도구 선택 기준은 단순합니다: 내 배포 파이프라인과 통합되는가, DORA 메트릭과 연결되는가, CI/CD 흐름을 방해하지 않는가. ## 기술 부채와 함께 사는 법 기술 부채 제로는 불가능합니다. 그리고 목표도 아닙니다. 목표는 부채가 운영 리스크를 실질적으로 높이기 전에 감지하고, 분류하고, 처리하는 프로세스를 가지는 것입니다. 새벽 3시에 전화를 받는 팀과 받지 않는 팀의 차이는 코드 품질 점수가 아닙니다. 기술 부채를 추적 가능한 운영 리스크로 다루는 실천의 차이입니다. 포스트모템이 이미 그 답을 알고 있습니다. 질문은, 그 답을 다음 스프린트 계획 전에 읽는가, 다음 인시던트 후에 읽는가입니다. ## FAQ ### 기술 부채란 무엇인가요? 기술 부채는 단기적 편의를 위해 내린 기술적 타협이 장기적으로 운영 리스크와 유지보수 비용으로 전환되는 현상입니다. 플랫폼 엔지니어링 맥락에서는 배포 실패율 상승, MTTR 증가, blast radius 확대로 나타납니다. ### 기술 부채가 DORA 메트릭에 미치는 영향은 무엇인가요? 기술 부채가 누적되면 변경 실패율(change failure rate)이 상승하고, 배포 주기(deployment frequency)가 감소하며, MTTR이 늘어납니다. 이 추세가 6주 이상 지속될 경우 임계점에 도달하고 있다는 신호입니다. ### 기술 부채를 어떻게 우선순위화해야 하나요? 운영 리스크 기준으로 분류하십시오. 배포 경로에 직접 관련된 부채, SLO 에러 버짓을 잠식하는 부채, 모니터링 사각지대에 있는 부채 순으로 처리합니다. 이 기준으로 분류하면 150개 티켓 중 실제 처리 대상은 7-12개로 줄어듭니다. ### 기술 부채를 완전히 없애는 것이 가능한가요? 불가능하며, 목표도 아닙니다. 현실적인 목표는 기술 부채를 추적 가능한 운영 리스크로 관리하는 프로세스를 구축하는 것입니다. 제로 부채보다 감지 가능하고 분류된 부채가 훨씬 안전합니다. ### Blast radius와 기술 부채는 어떤 관련이 있나요? 기술 부채는 장애 발생 시 영향 범위, 즉 blast radius를 키웁니다. 특히 배포 파이프라인, 피처 플래그, 공유 인프라에 걸쳐 있는 부채는 단일 장애가 다수 서비스에 전파되는 범위를 확대합니다. ### 기술 부채 감소를 경영진에게 어떻게 설득하나요? MTTR 증가분을 엔지니어링 시간으로 환산하십시오. 인시던트당 추가 소요 시간과 발생 빈도를 곱하면 월간 기술 부채의 비용을 용량 손실로 표현할 수 있습니다. 팀 15명, 월 8회 인시던트 기준으로 매달 276시간의 엔지니어링 용량이 소진될 수 있습니다. ### 기술 부채 관리에 도움이 되는 도구는 무엇인가요? Datadog은 DORA 메트릭과 배포 추적을, CodeScene은 코드 복잡도와 핫스팟 분석을, SonarQube는 정적 분석과 품질 게이트를 제공합니다. 중요한 것은 도구가 CI/CD 파이프라인에 통합되어 배포 결정에 직접 영향을 주는가입니다.