기술 부채 (Technical Debt)

Development / Thought / technical debt

어제 우아한형제들에 새 CTO로 취임하신 김범준님의 인터뷰를 보고 '기술 부채 (Technical Debt)'라는 단어를 처음 알게 되었다. 찾아보니 워드 커닝햄(Ward Cunningham)이라는 분이 처음 하신 말씀이라고 하는데, 현재 우리의 상황에 너무나도 걸맞는 이야기라서 굉장히 뇌리에 깊이 박히게 되었다.

개념은 아주 간단하다, 기술 자본이 많지 않은(기술 인력을 포함한 전반적인 리소스에 관해서겠지) 집단이 빠르게 기술력을 개발하기 위해 포기하는 많은 것들(주로 실질적인 Output과는 동떨어져보이는 프로세스들.. 가령 테스트, 코드 품질 관리, CI 등)이 결국에는 '부채(Debt)'로 차후에 돌아온다는 것이다. 테스트나 QA를 하지 않아 차후에 제품에서 이슈가 발생하면, 그것을 보정하기 위해 들어가는 추가 공수는 일종의 '이자(Interest)'가 되는 것이다. 그리고 최종적으로는 테스트나 QA 시스템을 개발하고 프로세스를 확정하는 등의 '원금 갚기'의 행위를 해야 이 부채를 모두 상환하게 되는 것이다. (Fxxking liabilities!)

하지만 빚을 지는 것이 무조껀 나쁜 것일까? 우리는 빚을 지지 않기 위해 무조건 처음부터 모든 QA 프로세스를 도입하고 탄탄한 땅 위에 공장을 지어야할까? 알려진 바에 의하면 모든 사업에는 투자가 필요하다. '남의 돈으로 장사하지 마라'라는 우리 엄마, 아빠의 격언(?)이 있음에도 불구하고, 현재 내가 가진 자본이 없는 상황에서 앞으로의 수익이 확실한 장사라면 과감히 은행에서 번호표를 뽑아야 할 것이다. 시간 전쟁과 같은 스타트업 시장에서는 빨리 고객에게 선보일 MVP를 만들어내고 시장을 맛보는 것이 훨씬 중요할 수 있다.

문제는 '얼마나 Risk taking을 할 것인가'이다. 나는 기왕 부채라는 경제 컨셉을 도입한 김에 총부채상환비율 (DTI, Dept to Income)의 개념으로 이 문제를 생각해보면 어떨까 싶었다. 결국 '돈'(자본, 부채..)이 '기술력'으로 대체된 개념이니까, 우리가 보유한 기술력 대비 감내할 수 있는 기술 부채 양을 정하는 것이다. 언제든지 빚을 갚을 능력이 되어 있는 팀원을 보유하고 있는 경우(정말 공수 시간에만 빚을 지고 있는 경우) 우리는 빚을 더 질 수 있다. 이러한 팀원이 많으면 많을수록, 우리가 무슨 빚을 지고 있는지, 어떻게 갚아야 하는지 잘 알면 알수록(여기서 파생되는 더 큰 문제가 바로 '내가 무슨 빚을 어떻게 지고 있는지도 모르는 경우'일 것이다.) 상환이 유리하다. 코드나 아키텍쳐의 비효율을 씹어 먹을 수 있을 정도의 인프라 증설에 돈을 투입할 수 있게 되는 경우에도 우리는 빚을 더 질 수 있다. 가령 우리의 경우 현재 바로 코앞에 예정되어 있는 릴리즈 일정 때문에 코드 리뷰와 테스트에 소홀한 상태인데, 코드 리뷰 같은 경우는 정말 시간에만 빚을 지고 있는 상황이라 의도적인 High risk taking이 가능하다. 하지만 테스트는 우리가 TDD에 대한 지식이 많이 부족한 관계로 더 이상 빚을 지지 말고 슬슬 테스트 관련 공부를 하고, 각자가 유닛 테스트 코드를 짜고, CI 등에 테스트 코드를 붙이는 작업을 진행해야 할 것이다.

더불어 빚을 지는데 있어서 가장 위험한건 '맞아, 난 나중에 성공해서 다 갚을 수 있어!'라고 미래의 나에게 짐을 모두 떠맡기는 행위일 것이다. 그 생각으로 사채까지 질 수도 있을 것이고. 이러한 부분을 항상 조심하면서, 우리, 그리고 우리 팀의 DTI를 객관적으로 평가해 앞으로의 기술 부채를 계산하는 노력을 해야겠다. 자! 이제 일하자!

Share on : Twitter, Facebook or Google+