모든 팀은 기술 부채를 진다. 빠르게 출시하기 위해 임시방편을 쓰고, “나중에 정리하자”고 약속한다. 문제는 그 나중이 거의 오지 않는다는 것이다. 이 글은 우리 팀이 2년간 미뤄둔 데이터 파이프라인 부채가 결국 한 분기 전체를 삼킨 과정을 솔직하게 복기한 회고다.
이 이야기를 공유하는 이유는 변명을 하기 위해서가 아니다. 부채가 쌓이는 메커니즘은 놀랄 만큼 보편적이어서, 우리의 실패가 다른 팀에게는 조기 경보가 될 수 있다고 믿기 때문이다.
처음엔 합리적인 타협이었다
시작은 정당했다. 제품 출시 마감이 코앞이었고, 우리는 검증 로직 없이 데이터 파이프라인을 빠르게 띄웠다. 당시 데이터는 하루 수천 건이었고, 문제가 생기면 손으로 고칠 수 있었다. 그때의 결정은 옳았다. 부채 자체가 죄는 아니다.
이자는 복리로 붙는다
죄는 부채를 관리하지 않은 데 있었다. 데이터가 하루 수백만 건으로 불어나는 동안 검증 로직은 여전히 없었다. 새 기능들이 그 위태로운 파이프라인 위에 하나씩 쌓였다. 임시방편 위에 또 임시방편이 올라가며, 부채의 이자는 단리가 아니라 복리로 불어났다.
기술 부채의 가장 잔인한 점은, 갚지 않은 동안에도 이자가 매일 조용히 청구되고 있다는 것이다.
붕괴의 날
붕괴는 예고 없이 왔다. 한 상류 시스템이 데이터 형식을 미묘하게 바꿨고, 검증이 없던 우리 파이프라인은 잘못된 데이터를 조용히 흘려보냈다. 3주 뒤 경영진이 본 매출 지표가 실제와 크게 어긋났다는 사실이 드러났다. 그 사이 그 잘못된 숫자로 내려진 결정들을 되돌려야 했다.
복구가 아니라 재건이었다
우리는 한 분기 전체를 갈아 넣었다. 새 기능 개발을 전면 중단하고 파이프라인을 재설계했다. 만약 부채가 작았을 때, 즉 데이터가 적었을 때 검증을 넣었다면 며칠이면 끝났을 일이었다. 부채를 키운 대가는 그 일을 80배쯤 비싸게 만들었다.
- 부채를 진 즉시 “상환 기한”을 백로그에 명시적으로 기록한다
- 데이터 규모가 N배 커질 때 부채 비용도 N배 커진다고 가정한다
- 검증과 모니터링은 기능이 아니라 보험이다, 작을 때 든다
균형 잡힌 교훈
그렇다고 모든 부채를 즉시 갚아야 한다는 결론은 위험하다. 그것은 또 다른 과잉이다. 폐기될지도 모르는 실험적 기능을 완벽하게 만드는 것은 낭비다. 핵심은 부채를 지지 않는 것이 아니라, 어떤 부채인지 의식하고 의도적으로 관리하는 것이다.
지금 우리 팀은 분기마다 “부채 가시화” 시간을 갖는다. 미뤄둔 타협들을 목록으로 펼치고, 각각의 이자율을 추정하고, 상환할지 의도적으로 더 끌고 갈지 결정한다. 부채는 적이 아니다. 보이지 않는 부채가 적이다. 이 회고가 누군가의 파이프라인이 조용히 무너지기 전에 닿기를 바란다.
