기술 부채

친구들이 집에 놀러 오기 10분 전을 떠올려 보세요. 방바닥에 널브러진 물건을 제자리에 차곡차곡 정리할 시간이 없으면, 일단 옷장 문을 열고 마구 쑤셔 넣은 뒤 닫아버리기 마련이에요. 겉으로 보기에는 방이 순식간에 깨끗해 보이지만 옷장 안은 엉망진창이 되죠.

소프트웨어를 만들 때도 이와 똑같은 상황이 자주 일어나요. 서비스 출시 날짜가 코앞으로 다가오면 개발자들은 코드를 탄탄하게 설계할 여유를 잃어버려요. 그래서 깊이 고민하지 않고 임시방편으로 빠르게 동작하는 코드를 먼저 작성하곤 해요.

이렇게 만든 프로그램도 당장 사용자 눈에는 아무 문제 없이 매끄럽게 돌아가요. 하지만 급하게 문제를 덮어둔 대가는 저절로 사라지지 않아요. 언젠가 치러야 할 빚이 되어 시스템 내부 깊숙한 곳에 고스란히 남게 돼요.

옷장에 짐을 계속 쑤셔 넣다 보면 결국 어떤 일이 벌어질까요? 나중에 작은 양말 하나를 꺼내려 해도 옷장 문을 여는 순간 온갖 물건이 와르르 쏟아져 내려요. 결국 방 전체를 다 뒤엎고 대청소를 해야만 하죠.

임시방편 코드가 겹겹이 쌓인 프로그램도 정확히 똑같은 비극을 겪어요. 시간이 흐른 뒤 새로운 기능을 하나 덧붙이려 할 때마다 엉켜 있는 코드들 때문에 엉뚱한 곳에서 오류가 연달아 터져 나와요.

은행 대출에 매달 이자가 붙듯이, 코드를 제때 정리하지 않고 미룰수록 새로운 기능을 개발하는 시간이 몇 배로 불어나요. 원래 10분이면 고칠 수 있던 사소한 버그 하나를 잡느라 며칠 밤을 새워야 하는 상황이 바로 기술 부채의 이자예요.

조금 더 정확히 말하면 기술 부채가 언제나 피해야 할 절대적인 악인 것은 아니에요. 치열한 비즈니스 세계에서는 경쟁자보다 먼저 서비스를 출시해 시장과 고객의 반응을 빠르게 확인하는 일이 무엇보다 중요할 때가 많아요.

사업가가 회사를 빠르게 성장시키기 위해 은행 대출을 전략적으로 활용하듯, 개발팀도 출시 속도를 앞당기기 위해 일부러 빚을 질 수 있어요. 중요한 것은 빌린 돈을 언제 어떻게 갚을지 미리 계획해 두었느냐예요.

빌린 빚은 겉모습은 그대로 두면서 내부 설계를 깨끗하게 다듬는 리팩터링(Refactoring)을 통해 제때 갚아나가야 해요. 빚을 갚지 않고 오래 방치하면 시스템 전체가 손을 대기 힘들 만큼 굳어 버릴 수 있어요. 또 기술 부채는 일부러 지는 것만 있는 게 아니에요. 처음엔 합리적이던 설계도 요구 사항이 바뀌거나 쓰던 기술이 낡으면서 나중에 부채가 되기도 해요.