`기술 부채(빚)`라는 재치 있는 비유가 있다.
소프트웨어(SW) 개발 과정에서 최선의 방법이 아니라 짧은 시간에 쉽고 빠른 방법을 선택하고, 생략된 과정은 차후 해결할 숙제로 보류하는 것이다. 빈약한 문서, 테스트되지 않은 코드, 반복되는 수동 배포, 미뤄진 리팩토링과 같은 것들이 `기술 부채`의 흔한 사례다.
통상 빠듯한 일정, 급격한 요구 사항 변경, 팀의 숙련도 부족 등이 원인이다. 〃이 `기술 부채`라는 비유가 참 적절하다고 생각되는 것이 우리가 보통 알고 있는 부채와 유사한 점이 많다. 빚을 질 때는 마음이 불편하고 갚아 나갈 미래가 걱정된다.
하지만 곧 매달 이자를 내는 상황에 익숙해진다. 개발 과정에서도 초기에 테스트를 작성하지 않거나 개선할 수 있는 코드를 남겨 뒀을 때는 마음이 불편하다. 슬그머니 비효율 상황에 익숙해지고, 개선 의지는 사라진다.
돈을 빌릴 때 가장 두려운 것은 이자다. `기술 부채`도 마찬가지로 프로젝트가 진행됨에 따라 이자가 붙는다. 여기에서의 이자는 보통 개발팀 시간이다. 초기에 개발 과정을 정리하지 않을 경우 유지·보수 시 훨씬 큰 노력을 요구한다. 급격한 요구 사항 변경을 맞추기 위해 뒤틀린 설계를 제때 바로잡지 않으면 불어난 이자를 갚을 수 없어 일종의 부도 상태인 시스템 폐기로 연결되는 경우도 있다.
다시 말해서 더 이상 유지·보수가 불가능한 상태가 돼 프로젝트가 폐기되거나 아예 처음부터 다시 만들게 된다.
마지막으로 과도한 빚이 채무자를 힘들게 하는 것처럼 과도한 `기술 부채`는 팀의 업무 의욕을 떨어뜨려 해결해야 할 문제에 집중하지 못하게 한다.
〃`기술 부채`만의 특징도 있다. 부채는 빚을 지는 사람과 갚는 사람이 동일하지만 기술 부채는 개인이 지더라도 팀이 갚는다. 즉 내가 기술 부채를 쌓으면 다른 동료나 내 후임이 갚을 수도 있다. 또한 이자가 정량 계산되지 않는다.
돈을 빌리면 내가 어느 시점에 얼마를 갚아야 하는지를 정확히 알 수 있지만 기술 부채는 끝까지 해결하지 않아도 별다른 문제가 되지 않을 수도 있고, 폭탄으로 돌아와 프로젝트를 망칠 수도 있다.
〃그렇다면 항상 `기술 부채`를 쌓지 않고 프로젝트를 진행해야 하는가? 항상 그렇지는 않다.
보통 `부채`가 이자를 내고 돈을 쓰는 시점을 당기는 것처럼 `기술 부채`는 기술로 해결돼야 문제들은 잠시 보류하고 비즈니스 문제의 해결 시점을 앞당기는 것이다.
우리에게 돈을 빌려야 할 때가 있는 것처럼 기술 부채를 쌓으며 전진해야 할 때가 있다. 바로 제 시간 내에 결과물을 전달해야 하는 경우다. `기술 부채`를 해결하기 위해 추가로 사용하는 일주일에 사업 기회가 사라질 수도 있고, 시장 선점의 기회를 놓칠 수도 있다.
〃`기술 부채`를 쌓을 것인가, 갚을 것인가의 판단은 어떻게 해야 할까. `기술 부채`로 발생하게 되는 비효율과 지금 당면한 비즈니스 기회의 크기를 비교해야 한다. 두 가지 모두 정확한 측정이 어렵기 때문에 이 비교는 냉철한 분석이라기보다 경험에 의한 직관 영역에 속한다.
다만 그 직관이 좀 더 뚜렷해지기 위해서는 결정권자가 회사의 비즈니스 환경과 개발 조직의 상황에 대한 명확한 이해가 필요하다.
〃이 `기술 부채`라는 것은 `디자인 부채` `운영 부채` 등으로 다양하게 변형돼 사용되기도 한다.
좋은 서비스를 만들기 위해 노력하는 사람이라면 우리의 제품과 서비스가 지속 가능한 성장을 하고 있는가를 이 관점에서 생각해 보길 권한다.
완성도는 높지만 시장의 타이밍을 놓치는 `아름다운 쓰레기`와 언제 무너질지 모르는 `사상누각` 사이에서 최적의 결과를 도출하길 기원한다. 그 결과물은 화려하지 않더라도 튼튼한 벽돌집으로 완성될 것이다.
이호성 8퍼센트 최고기술책임자(CTO) hslee@8percent.kr