¶ 17권 — 소프트웨어 수명주기와 기술부채 관리하기
초기 단계에서는 빠르게 만들고 빠르게 배우는 것이 합리적 선택이지만, 서비스가 실제로 성장하기 시작하면 그때 쌓인 부담이 발목을 잡는다. 기술부채 관리의 목표는 부채를 무조건 없애야 할 죄악으로 보거나 반대로 방치하는 양극단이 아니라, "어떤 부채는 감수하고 어떤 부채는 반드시 갚아야 하는가"를 판단하는 기준을 세우는 것이다.
¶ 기술부채란 무엇인가
"기술부채"라는 용어는 1992년 Ward Cunningham이 처음 사용했다. 원래 의도는 지저분한 코드가 아니라, 팀이 도메인을 이해한 정도와 실제 시스템이 그 이해를 반영하는 정도 사이의 간극을 가리키는 것이었다.
이를 실무에서 다루기 쉽게 확장한 것이 Martin Fowler의 기술부채 사분면이다. 다음 두 축을 교차하면 네 유형이 나온다.
- 의도적(Deliberate) vs 무의도적(Inadvertent)
- 신중함(Prudent) vs 무모함(Reckless)
"의도적이고 신중한" 부채는 정당한 비즈니스적 선택일 수 있고, "무의도적이고 신중한" 부채는 최고 수준의 팀이라도 겪는 불가피한 현상이다.
¶ 기술부채 식별·기록 방법
정성적 식별은 도구만으로 찾을 수 없는 조직적 신호를 포착하는 것이다.
- 같은 유형의 버그가 반복된다
- 기능 추가 시간이 점점 길어진다
- "아무도 못 건드리는 코드"라는 말이 나온다
정량적 측정은 SonarQube 계열 도구의 기술부채 비율을 활용하며, 절대 수치보다 스프린트마다의 추세를 보는 것이 유용하다.
식별한 부채는 다음 네 요소를 갖춰 이미 쓰는 이슈 트래커에 기록하는 것이 실행력을 높인다.
- 위치
- 유형
- 영향
- 상환 조건(트리거)
¶ 레거시 이관 전략 — 스트랭글러 무화과 패턴
특정 시스템 전체를 다시 만들어야 할 때 가장 위험한 선택이 빅뱅 재작성이다. 대안은 Martin Fowler가 제안한 스트랭글러 무화과 패턴으로, 기존 애플리케이션을 기능 영역별로 나눠 한 번에 하나씩 새 구현으로 교체한다. 다음 세 단계로 반복된다.
- 변환(Transform)
- 공존(Coexist)
- 제거(Eliminate)
¶ 부채 상환을 로드맵에 반영하기
식별·기록만으로는 상환이 저절로 일어나지 않는다. 부채 상환을 "언젠가 할 일"이 아니라 로드맵의 정규 항목으로 편입해 매 주기 신규 기능과 나란히 우선순위를 매겨야 한다. 우선순위는 영향과 시급성 두 축으로 판단한다.
¶ EOL 정책과 의존성 최신화 자동화 (옵션)
기술부채의 상당 부분은 의존 소프트웨어의 지원 종료(EOL)에서 비롯된다. endoflife.date 같은 자료로 핵심 의존성의 EOL 일정을 정기 확인한다. 이를 자동화하는 대표 도구가 GitHub Dependabot과 오픈소스 Renovate다. 자동 생성 PR은 CI 테스트를 반드시 통과시켜야 하고, 메이저 버전 업그레이드는 자동 병합 대상에서 제외하는 것이 안전한 절충안이다.
¶ 정리 — 기술부채 관리의 순환 고리
다음 다섯 요소는 한 번으로 끝나는 프로젝트가 아니라 지속 반복되는 순환 고리다.
- 개념 이해
- 꾸준한 식별·기록
- 점진적 레거시 이관
- 로드맵 반영
- EOL·의존성 자동화
목표는 부채를 0으로 만드는 것이 아니라, 생기는 것을 두려워하지 않되 인지하고 통제된 속도로 갚아나가는 체계를 갖추는 것이다.
¶ 참고할 만한 사례
- 토스페이먼츠: 20년 된 레거시 결제 시스템을 Two Track 전략으로 5년에 걸쳐 점진 전환했다.
- 트위터: Ruby on Rails에서 JVM/Scala로 여러 해에 걸쳐 단계적으로 이전했다.
- 넷스케이프: 전면 재작성을 택했다가 약 3년의 공백 동안 시장점유율을 잃은 반면교사 사례로 꼽힌다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.