빚이란 "미래의 나"의 등골에 빨대를 꽂아 "현재의 나"의 문제를 해결하는 방식이라는 점에서 일맥상통하는 부분이 있다.
한번 스타트업이 자주 겪을 만한 상황에 빗대어 보자.
당신은 스타트업의 CEO다. 올해 초에 정부지원사업으로 돈을 억 단위로 타서 썼다. 그래서 성과보고를 위해 올해 안에 앱을 론칭하기는 해야 하는 상황인데 아직 제품의 성능이 좋지 않다. 향후 장기간 고장 나지 않고, 좋은 성능을 보여주려면 반년 가량 밑 작업이 필요하지만, 당장 2주 안에 앱을 론칭해야 한다.
이런 상황에서 많은 CEO들은 성능이 많이 떨어지거나 불안정하더라도 일단 '작동은 되는' 앱을 그럴싸하게 만들어서 론칭을 해야 한다고 판단한다. 안 그러면 억 단위의 정부지원금을 환수당할 수도 있기 때문이다. 그 돈은 일 년간 대부분 직원 인건비로 지급하고 없을 가능성이 크기 때문에 더욱 선택의 여지는 좁아진다.
향후에 유지보수나 수많은 패치, 심할 경우 처음부터 다시 만들어야 하는 등 다양한 유,무형의 비용을 지불해야겠지만 "그건 미래의 우리 회사가 책임질 문제고, 당장 현재의 우리 회사의 문제를 해결해야겠다."라고 판단했다면 이를 일종의 빚이라고 볼 수 있는 것이다. 이러한 빚을 '기술 부채'라고 부른다. 스타트업을 예시로 들었지만 사실 대부분의 조직에서 온갖 형태의 기술 부채를 지고 있다.
코더가 아닌 프로그래머에게 무한한 시간과 자원, 그리고 인터넷이 연결된 pc를 제공해 주면 언젠가는 완벽한 서비스를 만들 수 있을 것이다. 하지만 이는 현실에서는 일어날 수 없는 일이다. 결국 일정 부분은 "향후에 개선하거나 해결하는 방향으로 갑시다."라고 미룰 수 밖에 없다. 기술부채가 전혀 없는 프로젝트가 존재할 수 있는지 여부는 잘 모르겠으나 "적어도 우리 팀에는 반드시 기술부채가 있다."고 생각하는 것이 마음이 편할 것이다.
기술 부채도 빚이다. 어떻게 하면 빚을 덜 질 수 있고, 빚을 빨리 청산할 수 있을까?
개발에 투입할 수 있는 시간과 자원이 유한함을 인정하는 것이 유능한 프로젝트 매니저가 되기 위한 첫걸음이다. PM은 개발인력들이 프로젝트 기간 내에 리소스를 어떤 방향으로 활용하면 어느 지점까지 도달할 수 있을지, 거의 모든 경우의 수를 고려하며 견적을 낼 수 있어야 한다.
어떻게 하면 기술 부채를 최소화하며 기간 안에 프로젝트를 성공시킬 수 있을까? 기간을 준수하는 것과 기술 부채를 낮추기 위해 시간과 자원을 더 투자하는 것 중 어느 것이 회사의 입장에서 더 중요한 것인가? 이러한 고민을 하는 과정에서 비즈니스 플랜을 부득이하게 수정할 경우도 생길 수 있으므로 PM에게는 강력한 권한과 책임이 필요하다.
그래서 데브옵스를 해야 하는 것이고, 그래서 스타트업이 강점을 가질 수 있는 것이다. C레벨 임원이 팀에 합류해버리면 걱정할 부분이 많이 사라지니까.
