아날로그 기술 부채 온실: 실제 식물 관리 시스템으로 레거시 코드를 키우고 가지치기하기

기술 부채(Technical Debt)는 악명 높게 추상적입니다. 다이어그램, 대시보드, Sonar 같은 리포트가 도움이 되긴 하지만, 사람들이 레거시 코드에 대해 어떻게 느끼는지까지 바꾸지는 못합니다. 뭔가가 고장 나기 전까지는 보이지 않고, 그때는 이미 비용이 큽니다.

그 기술 부채가 팀룸 한가운데, 선반 위 화분 속 흙과 잎과 실제 뿌리를 가진 채로 살고 있다면 어떨까요?

여기에 **아날로그 기술 부채 온실(Analog Tech Debt Greenhouse)**이 있습니다. 레거시 코드의 건강 상태를 눈으로 보고, 손으로 만지고, 직접 돌볼 수 있는 실제 식물 관리 시스템으로 바꾸는 실험입니다.

이 글에서는 다음을 다룹니다.

코드 컴포넌트를 실제 식물에 매핑하는 방법
식물 관리를 통해 기술 부채를 시각화하고 우선순위를 정하는 방법
칸반 스타일의 보드로 부채 작업을 일상 흐름에 통합하는 법
의도적인 가지치기를 통해 깨지기 쉬운 거대 시스템을 피하는 법
‘식물 건강’과 실제 엔지니어링·비즈니스 목표를 연결하는 법

왜 기술 부채를 물리적으로 만들어야 할까?

기술 부채는 보이지 않는 곳에서 쉽게 자랍니다.

아프기 전까지는 눈에 잘 보이지 않습니다.
정치적으로 말하기가 까다롭습니다. ("이걸 또 왜 다시 만드는 거죠?")
기능 개발에 밀려 미루기 쉽습니다.

여기서 물리적 은유, 즉 실제 공간 속의 진짜 식물이 역할을 바꿉니다.

구체적·가시적: 매일 실제로 그 부채 옆을 지나갑니다.
공유 언어: “이 식물이 시들어가고 있어요”는 “이 모듈은 유지보수가 불가능한 수준입니다”보다 말하기 쉽습니다.
중립적 프레이밍: 누가 잘못했느냐가 아니라, 어떻게 돌보고 키울 것인가의 문제입니다.
시각적 긴급성: 선반 위에서 눈에 띄게 죽어가는 식물은, 조용히 쌓이는 코드 스멜 리포트보다 무시하기 훨씬 어렵습니다.

디지털 영역에서 한 발 벗어나면, 팀은 레거시 코드에 대해 더 솔직하고 방어적이지 않은 대화를 시작할 수 있습니다.

코드 컴포넌트를 식물에 매핑하기

핵심 아이디어는 단순합니다. 각 식물 하나가 하나의 코드 컴포넌트나 도메인 영역을 대표합니다.

예를 들면:

거대한 양치식물 → 모놀리식(monolithic) 서비스
작은 다육이(석화 식물) → 개별 마이크로서비스
길게 뻗어나가는 넝쿨 → 프론트엔드 코드베이스
분재(본사이) → 제약이 많고 까다로운 레거시 연동 시스템

어떻게 시작할까

매핑 범위를 정한다
‘식물 하나’가 무엇을 의미할지 결정합니다.
- 하나의 서비스
- 하나의 바운디드 컨텍스트 / 도메인
- 핵심 라이브러리나 공유 컴포넌트
각 식물에 정체성을 부여한다
- 이름 태그: 시스템 이름, 담당 팀, 담당 비즈니스 기능
- 핵심 정보: 연식, 언어/프레임워크, 주요 의존성
사람들이 일하는 공간에 온실을 둔다
- 팀룸 안, 혹은 주요 협업 공간 근처
- 하이브리드/원격 환경에서는, 사무실에 작은 실제 온실을 두고 원격 인원을 위해 사진을 공유하는 디지털 보드를 함께 운영할 수 있습니다.

누군가 “저 초라해 보이는 식물은 뭐예요?”라고 물으면, 그 시스템이 무슨 일을 하는지, 왜 지금 곤란한 상태인지 설명할 기회를 얻습니다.

부채를 보이게 만들기: 식물로 건강 상태 표현하기

코드를 식물에 매핑했다면, 이제 기술 부채를 식물의 상태에 인코딩할 수 있습니다.

다음과 같은 비유를 고려해보세요.

잘 자라는 식물 → 건강한 코드: 테스트 커버리지 양호, 명확한 오너십, 안정적인 변경 이력, 팀이 잘 이해하고 있음.
성장이 멈춘 식물 → 오래 방치된 코드: 아무도 손대지 않고, 지식이 사라지고 있으며, 신규 개발자 온보딩이 어렵습니다.
시들어가는 식물 → 부채가 많은 코드: 깨지기 쉽고 버그가 잦으며, 리팩터링이 어렵고, 자주 장애의 근원이 됩니다.
과하게 무성한 식물 → 누적된 복잡도: 역할이 너무 많고, 의존성이 얽혀 있으며, 경계가 불분명합니다.

표현을 표준화할 수도 있습니다.

흙 상태 = 아키텍처·의존성의 품질
잎의 색·생기 = 유지보수성·가독성
물 주는 빈도 = 실제 사용도와 관리 빈도
화분 크기 vs. 뿌리 크기 = 확장성 및 적합성(Fit-for-purpose)

어떤 식물이 방치된 것처럼 보인다면, 의도적으로 이렇게 물어봅니다.
“이 식물이 말해주는 underlying 시스템의 현실은 뭘까?”

기술 부채 분류하기: 가지치기, 분갈이, 교체

모든 기술 부채가 동일하지는 않습니다. Kenny Rubin이 제안하는 접근처럼 (유형, 심각도, 비즈니스 영향으로 분류) 일관된 식물 관리 액션을 설계할 수 있습니다.

예시 분류 체계

유형(Type)
- 설계 부채: 아키텍처, 결합도, 경계 문제
- 코드 부채: 스타일, 복잡도, 테스트 커버리지
- 인프라 부채: 구식 런타임, 수동 운영, 자동화 부재
- 지식 부채: 소수만 이해하는 영역, 문서 부족
심각도(Severity)
- 미관 수준: 거슬리긴 하지만 위험은 크지 않음
- 중간: 딜리버리를 느리게 하고 혼란을 유발
- 심각: 잦은 장애, 로드맵 차단, 감사·규제 리스크
비즈니스 영향
- 매출·트랜잭션 핵심
- 규제·보안상 핵심
- 내부 생산성 관련
- 영향이 낮은 주변 시스템

분류를 식물 행동으로 매핑하기

가지치기(Prune) – 작고 타깃이 명확한 리팩터링
- 무성한 가지를 정리 → 함수·클래스 분리, 죽은 코드 제거, 조건문 단순화, 네이밍 개선.
분갈이(Repot) – 구조 재편성 혹은 리플랫폼
- 더 큰 화분으로 옮기기 → 더 적절한 인프라로 이전, 도메인 경계 재구성, 명확한 인터페이스 도입.
교체(Replace) – 폐기 후 재식재
- 병든 식물 새로 심기 → 레거시 시스템 폐기, 현대적 설계로 신규 서비스 구축, 데이터 마이그레이션.

각 식물에 색깔 태그나 작은 깃발을 꽂아 이 카테고리와 결정을 표현할 수 있습니다. 예를 들면:

빨간 태그: 심각/고영향 부채
노란 태그: 중간 수준 부채
초록 태그: 건강함, 우선순위 낮음
가위 아이콘: 예정된 가지치기 작업
화분 아이콘: 예정된 분갈이/마이그레이션

온실 칸반: 부채를 일상 흐름에 녹여 넣기

기술 부채가 자주 실패하는 이유는, 이를 별도의 프로젝트로 다루기 때문입니다. ("이번 릴리즈만 끝나면 대청소하자" 같은 식이죠.) 그 ‘언젠가’는 거의 오지 않습니다.

대신, 온실을 3D 칸반 보드처럼 다뤄보세요.

식물/코드 관리를 위한 칸반 컬럼

온실 옆에 간단한 보드를 하나 둡니다.

Assess (평가) – 건강 상태 파악, 부채 식별, 영향 정리
Refactor (개선) – 가지치기·분갈이 액션 실행
Validate (검증) – 지표 확인, 테스트 실행, 개선 효과 검증
Done (완료) – 부채 감소 작업 완료·기록

각 식물에는 대응하는 카드를 하나씩 둡니다.

식물 이름(= 시스템/서비스 이름)
현재 건강 요약
식별된 부채(유형, 심각도, 영향)
계획된 액션(가지치기, 분갈이, 교체)
담당자와 타임박스

카드를 보드 위에서 이동시키면서, 식물도 함께 업데이트합니다.

평가 세션 후, 심각도에 따라 빨간 태그를 추가할 수 있습니다.
리팩터링이 끝나면, 빨간 태그를 떼고 설명을 갱신합니다.

이렇게 하면 기술 부채 작업이 기능·버그와 같은 흐름 안에서 가시화되고, 모호한 “언젠가 정리하자” 리스트로 밀려나지 않습니다.

오직 작은 변경만 하는 위험

온실 비유는 또 하나의 중요한 리스크를 드러냅니다. 바로 작고 반응적인 변경만 계속하는 습관입니다.

현실의 정원 가꾸기를 떠올려보세요. 만약 여러분이:

물만 주고 가지치기는 전혀 하지 않거나
뿌리가 꽉 찼는데도 분갈이를 하지 않거나
서서히 죽어가는 식물을 계속 방치한다면

결국 취약하고, 일관성이 없고, 관리하기 힘든 정원이 됩니다.

소프트웨어 시스템도 마찬가지입니다.

빠른 핫픽스가 층층이 쌓입니다.
일관성 없는 패턴이 퍼져 나갑니다.
변경 비용이 기하급수적으로 늘어납니다.

온실은 이 문제를 눈에 보이게 해줍니다.

멀리서 보기엔 멀쩡해 보이는 식물이, 실제로는 뿌리가 화분을 꽉 채운 상태일 수 있습니다.
과하게 자란 식물이 옆 식물을 가려 빛을 막을 수 있습니다. (의존성이 서로를 질식시키는 상황)

이 가시성을 활용해서, 의도적이고 정기적인 가지치기·분갈이, 즉 계획된 리팩터링과 마이그레이션을 진행하세요. 장애가 터진 뒤에야 손대는 방식에서 벗어나는 것이 핵심입니다.

리팩터링을 ‘청소’가 아닌 ‘가드닝’으로 보기

“청소”에서 지속적인 가드닝으로 마인드셋을 바꾸는 것은 온실이 주는 가장 큰 이점 중 하나입니다.

청소는 ‘진짜 일’이 끝난 뒤에나 할 수 있는 선택 과제처럼 들립니다.
가드닝은 무언가를 살아 있고 생산적으로 유지하기 위한 필수 활동입니다.

이 마인드셋을 강화하는 실용적인 방법들:

정기적인 케어 의식 만들기
- 매주 짧은 “온실 산책”을 하며 팀이 함께 식물과 카드를 확인합니다.
- 짧게 이야기합니다. “어디가 시들고 있지?”, “이번 스프린트에 가볍게 가지칠 곳은?”
작고 지속적인 변화
- 이미 존재하는 ‘보이스카우트 규칙’과 정렬시킵니다. “캠프장(코드)을 떠날 때는 올 때보다 깨끗하게.”
- 어떤 컴포넌트를 기능 개발 때문에 건드릴 때, 그 안에서 가지치기에 쓸 시간을 조금이라도 확보합니다.
공유된 오너십
- 팀 누구나 물을 주고, 가지치고, 태그를 업데이트할 수 있게 합니다. 특정 “부채 영웅” 한 명에게만 맡기지 않습니다.
- 심리적 메시지: 시스템을 건강하게 유지하는 일은 모두의 책임입니다.

시간이 지나면, 팀 내에 **건강과 진화 가능성(Evolvability)**을 첫 번째 시민으로 대하는 엔지니어링 문화가 자리 잡게 됩니다. 덤처럼 취급하지 않게 됩니다.

중요한 것을 측정하기: 식물 건강에서 비즈니스 성과까지

온실은 단지 기분 좋은 비유에 그쳐서는 안 됩니다. 보여주기식 활동이 되지 않으려면, 식물의 건강을 실제 지표와 연결해야 합니다.

예시 측정 프레임워크

각 식물(= 코드 컴포넌트)에 대해 기술 지표와 비즈니스 지표를 함께 추적하고, 이를 단순하고 눈에 잘 띄는 신호로 표현합니다.

기술 지표 예:

변경 빈도와 리드 타임
결함/장애 발생률
테스트 커버리지와 플레이키(flaky) 테스트 비율
순환 복잡도(Cyclomatic Complexity)나 유지보수성 지수
배포 난이도(롤백 빈도, 수동 작업 단계 수)

비즈니스 지표 예:

해당 컴포넌트를 지나는 매출·트랜잭션 규모
규제·컴플라이언스 중요도
그 컴포넌트로 인해 발생한 온콜(on-call) 방해 시간
지원·장애 대응 vs. 신규 기능 개발에 쓰인 개발자 시간 비율

이를 식물 상태와 연결해 표현합니다.

장애가 잦을수록 → 더 눈에 띄는 경고 태그 부착
리팩터링 이후 리드 타임이 줄어들면 → 건강 상태 태그를 상향 조정
지원 시간 감소 → 카드에 “지원 시간 X% 감소”처럼 효과 기록

이렇게 하면 다음과 같은 추적 가능한 연결 고리가 생깁니다.

“이 식물을 가지쳤어요(이 서비스를 리팩터링했습니다). 그 결과 변경 리드 타임이 30% 줄었고, 장애 발생률이 절반으로 감소했죠. 그래서 기능 X 개발이 더 빨라졌고, 고객 Y에게 더 안정적인 서비스를 제공하게 됐습니다.”

이제 “온실에 들이는 시간”을 더 달라고 말할 때, 감(直感)이 아니라 데이터로 이야기할 수 있습니다.

나만의 기술 부채 온실 시작하기

큰 예산이나 거창한 디자인은 필요 없습니다. 작게 시작하세요.

가장 중요한 컴포넌트 3–5개를 고르고, 각각에 식물을 하나씩 배정합니다.
시스템 이름과 현재 건강 상태를 1–3문장으로 적은 간단한 식물 태그를 만듭니다.
색깔별 심각도 태그와 기본 칸반 보드(Assess → Refactor → Validate → Done)를 준비합니다.
4주 동안, 매주 30분짜리 온실 산책을 한 번씩 진행합니다.
식물마다 1–2개의 지표를 정해 추적하고, 리팩터링을 실행한 전·후를 간단히 기록합니다.

그리고 회고합니다.

이 비유가 대화에 실제로 도움이 되는가?
리팩터링 의사결정이 더 명확해지고 설명하기 쉬워졌는가?
거대한, 고통스러운 일회성 리라이트 대신, 작지만 지속적인 개선이 눈에 보이는가?

그렇다면 범위를 넓히고, 아니라면 매핑 방식이나 의식(ritual), 시각적 표현을 팀에 맞게 조정해보세요.

결론: 레거시의 건강을 무시할 수 없게 만들기

레거시 코드는 사라지지 않습니다. 하지만 관리되지 않는 기술 부채가 여러분의 기본 시나리오일 필요는 없습니다.

아날로그 기술 부채 온실은 팀에 다음을 제공합니다.

시스템 건강을 논의하기 위한, 공격적이지 않은 공통 언어
가장 중요한 코드들을 계속 돌보라고 상기시켜 주는 물리적 장치
가지치기, 분갈이, 교체의 우선순위를 정하는 단순한 틀
부채를 감당 가능한 수준으로 유지하게 해주는 ‘지속적인 가드닝’ 마인드셋
리팩터링 활동과 비즈니스 성과를 잇는 측정 브리지

보이지 않는 코드 품질을 살아 있는 식물로 바꾸면, 비즈니스를 떠받치고 있는 시스템을 외면하기가 훨씬 어려워지고, 무너지기 전에 돌보기가 훨씬 쉬워집니다.

여러분의 코드베이스는 이미 어떤 의미에서는 하나의 정원입니다. 다만 그렇게 대하고 있지 않을 뿐입니다. 질문은 이것입니다.
당신은 온실을 의도적으로 설계할 건가요, 아니면 식물들이 집 전체를 장악할 때까지 기다릴 건가요?