기술 부채
아름다운 쓰레기와 사상누각 사이 어딘가
얼마 전 개발자 면접을 볼 때 면접자 분이 물었다.
XX: Python으로 개발을 하신다고 들었어요. 회사 내에서 어떤 코딩 컨벤션을 사용하시나요?
호성: 아.. 그게 이제 맞추려고 하고 있어요.
부끄럽다. 하지만 아직도 못 맞췄다. 그리고 새롭게 회사에 들어오신 개발자 분이 내게 물었다.
XX: 웹서비스에서 오래 걸리는 부분들은 모두 비동기로 처리되고 있나요?
호성: 아.. 그게 되는 부분도 있고 아닌 부분도 있어요. 리팩터링이 필요해요.
역시나 부끄럽다. 개선해야 한다는 것을 알고 있지만 할 일 목록 어딘가에서 잠자고 있다.
이런 것들을 통칭해 "기술 부채"라 부른다. 일반적인 "부채"가 이자를 내고 돈을 쓰는 시점을 당기는 것처럼 기술 부채는 기술적으로 해결되어야 할 문제들을 뒤로 미루고, 비즈니스 문제를 해결하는 시점을 당기는 것이다.
어디까지 네모난 바퀴로 갈까? (출처: https://christierney.com/2015/12/04/technical-debt-in-an-image/)예를 들면 다음과 같은 것들이 기술 부채가 된다.
- 설계된 것을 문서로 남기지 않는다.
- 유닛 테스트를 작성하지 않는다.
- 더 이상 사용되지 않는 DB의 항목을 지우지 않는다.
- 반복되는 일(배포/빌드 등)을 자동화하지 않는다.
- 긴급하게 스펙을 변경한다.
안타깝지만 오늘도 일어난 일이다.
"부채"라는 이름이 참 적절하다고 생각되는 것이 돈을 빌리는 것과 유사한 점들이 많다.
- 빚을 지고 있으면 마음이 불편하다. 특히 빚을 질 때 제일 불편하다. 하지만 그 상황이 지속되면 빚을 지고 있는 상황에 익숙해진다.
- 빌리는 것은 상대적으로 쉽지만 갚는 것은 어렵다. 게다가 한 번에 갚는 것은 불가능에 가깝다. 지금 당장 문서를 쓰지 않고, 테스트를 작성하지 않는 것은 쉽지만 나중에 그것을 회복하기는 어렵다.
- 이자가 붙는다. 지금 배포 자동화를 해두지 않으면 배포를 할 때마다 시간을 쓰게 된다. 그 시간이 이자다.
- 부도가 나는 경우도 있다. 더 이상 복구 불가능한 상태가 되어 프로젝트가 폐기되거나 아예 처음부터 다시 만들게 된다.
돈을 빌리는 것과는 다른 기술 부채만의 특징도 있다.
- 빚을 지는 사람과 갚아야 할 사람이 다를 수도 있다. 어떤 사람이 코드를 리팩터링 하지 않은 상태로 두면 그 부채는 다른 팀원이 갚을 수도 있고, 나의 후임이 갚아야 할 수도 있다.
- 갚아야 할 양이 정확히 예측되지 않는다. 돈을 빌리면 내가 어느 시점에 얼마를 갚아야 하는지 정확히 알 수 있지만 기술 부채는 끝까지 해결하지 않아도 별다른 문제가 되지 않을 수도 있고, 폭탄이 되어 프로젝트를 망칠 수도 있다.
이런 "기술 부채"가 꼭 나쁜 것만은 아니다. 우리에게 돈을 빌려야 하는 이유가 있는 것처럼 기술 부채를 쌓으며 전진을 해야 하는 경우가 있다. 제 시간 내에 결과물을 전달해야 하는 경우이다. 그리고 데드라인은 스타트업에서 훨씬 더 중요하다. 기술 부채를 해결하기 위해 추가로 사용하는 일주일에 사업 기회가 사라져 버릴 수도 있고, 경쟁자가 같은 시도를 먼저 할 지도 모른다.
그렇다면 "지금 기술 부채를 해결할 것인가?"에 대한 의사결정을 어떻게 해야 하는가? 다음 사항에 대한 고민이 필요하다.
- 기술 부채를 해결하는데 얼마나 노력이 드는가?
- 기술 부채의 해결로 얻어지는 가치는 무엇인가?
- 기술 부채를 쌓고, 비즈니스 문제를 풀었을 때 얻어지는 가치는 무엇인가?
(보통 이 질문으로 바꾸는 것이 더 쉽다. 비즈니스 문제의 해결을 미뤘을 때 어떤 문제가 생기는가?)
첫 번째 질문은 상대적으로 쉽다. 하지만 그다음 두 가지 질문이 어렵다. 두 가지 모두 변수가 많은 상황을 정량화해야 한다. 따라서 이 비교는 냉철한 분석의 영역이라기보다는 경험에 의한 직관의 영역이라고 생각한다. 다만 그 직관이 보다 정확해 지기 위해서는 회사의 비즈니스 상황과 개발 조직에 대한 명확한 이해가 필요하다.
8퍼센트의 경우 내가 입사 후 지금까지 기술 부채를 쌓는 대신 비즈니스 문제를 빠르게 해결하는 것에 더 높은 우선순위를 두어 왔다. 처음 입사시에는 지금 시기면 비즈니스 문제들이 많이 해결되어 있어서, 아름다운 개발팀을 만들기 위한 일들에 보다 시간을 쓸 수 있을 거라 생각했다. 하지만 성장하는 스타트업에게는 더 많은 비즈니스 기회들이 찾아오고 그 기회들에 대한 실험을 해야 한다는 사실을 잊고 있었다. 하지만 동시에 개발팀의 규모도 커지고 레가시 시스템이 커지고 있다. 즉 기술 부채의 복리효과가 나타나고 있는 상황이다.
오늘도 어떤 쪽으로 추를 옮겨야 할지 고민한다. 개발팀원들이 스스로 만들어내는 제품에 자부심을 잃지 않는 동시에 회사의 사업 또한 속도를 잃지 않기를 바란다. 부디 "아름다운 쓰레기"와 "사상누각" 사이의 고민이 아름답진 않더라도 튼튼한 벽돌집으로 결론 나길 바란다.
글을 쓰고 보니 비단 "기술"에만 해당되는 내용은 아니다. 단기적인 성과를 얻는 것과 장기적인 투자를 하는 것 사이의 줄다리기는 누구에게나 해당된다.
글을 쓰면서 다음 링크들을 참고했다.
