솔직히 말하겠습니다. 오늘 아침 스크럼 회의에서 "레거시 코드가 너무 낡아서 개발 속도가 안 나옵니다"라고 불평하셨나요? 팀장님은 고개를 끄덕이며 "다음 스프린트에 고려해 보자"라고 했겠죠. 그리고 그 '다음'은 영원히 오지 않을 겁니다.
그건 당신의 설명이 부족해서가 아닙니다. 구조적인 문제입니다. 저는 이것을 최근 빙햄턴 대학교(Binghamton University)에서 발표한 '임대 주택 에너지 효율 연구'를 보며 뼈저리게 다시 느꼈습니다.
이 연구는 흥미로운 개념 하나를 던집니다. 바로 '분할된 인센티브(Split Incentive)'입니다.
미국 세입자의 90%는 전기/가스 요금을 직접 냅니다. 겨울에 난방비 폭탄을 맞는 건 세입자입니다. 하지만 단열 공사를 하거나 고효율 보일러를 설치할 권한(그리고 비용 부담)은 집주인에게 있습니다. 집주인은 난방비를 내지 않으니 단열에 투자할 유인이 '0'에 수렴합니다. 결국 세입자는 창문에 비닐(뽁뽁이)이나 붙이며 겨울을 납니다.
이 상황, 어디서 많이 보지 않았습니까?
집주인은 비즈니스 조직(Stakeholder)이고, 세입자는 개발팀(Developer)입니다.
조지 홈지(George Homsy) 교수의 말은 우리 개발 조직의 현실을 적나라하게 보여줍니다.
"집주인이 전구 하나 가는 데 5달러를 청구한다면, 최신형 히트펌프를 설치해 줄 리가 없습니다."
비즈니스 조직은 기능 출시(Feature)를 원합니다. 그 기능이 돌아가는 서버 비용(AWS Bill)이나 유지보수의 고통(On-call)은 개발팀의 몫입니다. 비즈니스 임팩트라는 명분 아래, 우리는 근본적인 아키텍처 개선(단열 공사) 대신 if-else 예외 처리(비닐 붙이기)로 코드를 땜질합니다.
연구 결과는 더 참담합니다. 정부가 '에너지 효율 개선 보조금' 같은 정책을 내놓아도 세입자들은 쓰지 못했습니다. 집주인의 허락을 받아야 하거나, 혹시라도 긁어 부스럼을 만들어 쫓겨날까 봐 두려워했기 때문입니다.
개발팀의 주니어들이 딱 이렇습니다. 리팩토링이 필요하다는 걸 알지만, 일정 지연을 유발했다가 평가가 깎일까 봐 입을 닫습니다. 그리고는 야근으로 그 기술적 부채를 몸으로 때웁니다.
그렇다면 해결책은 무엇일까요?
크리스티나 마티(Kristina Marty) 교수는 '자율'이나 '선의'에 기대는 건 실패했다고 단언합니다. 유일하게 효과가 있었던 것은 '규제(Regulation)'와 '데이터'였습니다.
연구에서 성공한 케이스는 임대 허가를 내줄 때 에너지 효율 등급을 강제한 지역뿐이었습니다. 다만, *어떻게* 달성할지는 집주인에게 맡겼습니다(유연성 부여).
이것을 우리 조직에 대입하면 다음과 같습니다.
- 감성팔이는 그만두십시오: "코드가 지저분해요"는 비즈니스 언어가 아닙니다. "이 레거시 때문에 기능 추가 시마다 3MD(Man-Day)가 낭비되고 있으며, 연간 1억 원의 리소스가 누수됩니다"라고 숫자를 들이미십시오.
- 강제성을 띤 정책(Governance)이 필요합니다: 배포 전 코드 커버리지 80% 미만은 파이프라인에서 차단하는 식의 강제적 규약(Policy)을 만들어야 합니다. 비즈니스 조직과 협의하여 '기술 부채 상환 스프린트'를 분기별로 할당받는 것을 계약처럼 박제해야 합니다.
- 작은 승리를 증명하십시오: 집주인에게 "집값이 올라간다"는 확신을 줘야 합니다. 리팩토링 후 트래픽 처리량이 늘어나거나, 고객 이탈률이 줄었다는 데이터를 보여주십시오.
제가 현대카드에서 앱카드를 설계할 때나 토스에서 대출 서비스를 만들 때, 성공한 리팩토링은 모두 '개발자의 편의'가 아니라 '비용 절감'과 '속도 향상'이라는 비즈니스 가치로 포장된 것들이었습니다.
추운 방에서 덜덜 떨며 "주인이 나빠"라고 욕해봤자 온도는 1도도 오르지 않습니다.
보일러를 바꾸고 싶다면, 그 보일러가 집주인의 지갑을 얼마나 두둑하게 해 줄지 계산기를 두드려 보여주십시오. 그게 프로입니다.
당신의 코드는 지금 얼마나 춥습니까?
