IT 기획자가 바라보는 기술 부채
우리 회사에 기술 부채는 조삼모사인가, 투자인가?
이건 기술 부채로 인해 작업시간이 예상보다 길어질 것 같아요.
일정 산정 시 고려해주세요.
기획자라면 개발자로부터 이런 말을 들을 때가 있을 거라고 생각한다. 기술에도 부채가 있다니?
현재로서는 살 수 없는 무언가를 사기 위해 돈을 끌어다 쓰는 것을 보통 부채라고 한다.
기술도 마찬가지로, 회사가 성장하기 전 프로젝트가 커서 너무 시간이 많이 소요된다거나, 자금적으로 부족해서 최선의 솔루션이나 개발방식 대신 차선책으로 시간이나 돈이 덜 드는 솔루션을 채택함으로써 현재 시점에 미래에 부담해야 하는 시간적, 금전적 의무가 생기는 것이다. 쉽게 말해서 조삼모사(朝三暮四)다.
기술 부채는 시간이 지날수록 어딘가 찜찜한 기분이 들게 한다. 그러나 현업이 바빠서 그 문제를 직면하기가 두려워 수면 위로 떠오를 때까지 묵혀두곤 한다. 오랜 시간 묵혀둔 이 기술 부채는 실제로 현업에서 다양한 문제를 발생시킨다.
- 스프린트로 업무를 해야 하는 상황에서 개발 시간을 늦춘다
- 업무가 몰릴 경우 병목현상이 생긴다
- 빌리는 사람과 갚는 사람이 따로 있어서 개발자의 의욕이 하락할 수 있다
- 레거시를 모르는 기획자, 개발자, 디자이너가 정책을 파악하는 데 시간이 들어간다
- 같은 DB인데 어드민을 다르게 만들어야 한다
- 기획자가 CS건에 대해 운영 업무 하듯이 일일이 예외처리를 해야 한다
이렇게 보면 사실 미래의 돈을 끌어다 써서 더 큰 부가가치를 만드는 좋은 부채라기보다는, 차선책을 써서 나중에 개고생을 해야 하는 환율이 낮아진 외화 같은 존재랄까... 위와 같은 문제는 차라리 양호한 편에 속하고, 더욱 심각한 상황을 야기하기도 한다.
1. 기술 부채를 충당하기 위한 운영인력을 많이 채용해야 하는 상황
인건비가 IT회사의 거의 전부인데, 생각보다 운영인력의 타격은 크다.
내가 다녔던 IT 스타트업의 경우 인건비가 거의 70,80%에 육박할 정도로 큰 비중을 차지했다.
일례로 특정한 타깃에게 특정 이벤트를 진행해야 하는 경우, 기존에 이벤트 대상 조건을 설정하는 로직이나 DB가 구축되어있지 않다면 개발자는 하드코딩을 해야 한다. 이벤트성이 아니라 지속적으로 운영이 필요한 경우 그 문제는 더 심각해진다. 운영인력은 일일이 사람의 손을 타고 정기적으로 해야 하는 업무이기 때문에 중간에 사람이 비어서도 안 되기 때문에 이를 고려해서 유휴인력을 운영해야 한다. 또 1초에 몇만 건씩 잡으로 돌리는 시스템을 건건이 수작업으로 대체해야 하는 운영일 경우 생각보다 많은 인력이 필요하다.
2. 레거시 시스템을 전부 마이그레이션 하는 상황
스타트업에서 있었던 일이다. 기존의 DB가 비즈니스 확장을 전혀 고려하지 않고 설계되다 보니 next step으로 나아갈 수가 없는 상황이 발생했다. 불행 중 다행인 건 연혁이 오래되지 않았고 거래 데이터 또한 많지 않았다는 거다. 초반부터 DB설계에 힘을 빼는 대신 시장 검증을 위해 린하게 작업할 수 있는 작은 규모를 선택했던 것 같다. 그 여파로 결국에는 연봉 2억이나 되는 비싼 개발자를 몇 명씩 데려와서 작업을 해야 했으며, 추후 비즈니스 확장까지 고려해서 DB설계를 해야 했기 때문에 오랜 시간을 들여 DB를 전부 다시 설계하고 마이그레이션을 진행했다. 마이그레이션은 말 그대로 기존의 데이터를 왼쪽 주머니에서 오른쪽 주머니로 옮기는 행위이다. 1+1이 1이 되는 작업에 여러 사람의 시간을 쏟아야 한다. 여기에는 개발자와 QA, 기획자 모두 달라붙어서 마이그레이션으로 밤을 지새우곤 한다.
그러나 수백만 건의 거래 데이터가 왔다 갔다 하는 서비스일수록, 연혁이 오래될수록 마이그레이션은 불가능에 가까워진다. 이런 곳은 보통 DB가 진화에 진화를 거듭하여 결국에는 형체를 알아볼 수 없을 정도로 덕지덕지 붙게 된다. 이런 경우는 비즈니스 상황과 중요도 순위에 따라 순차적으로 마이그레이션을 하기도 한다. 마이그레이션은 귀찮고 숙원사업이기 때문에 팀원들이 움직여줄 수 있도록 하는 것이 중요하다. 그러기 위해서는 "정말 필요한 작업인가?" "꼭 지금 해야 하는 이유가 있는가?"에 대한 생각을 먼저 정리하는 것이 중요한 것 같다.
이렇게 결국은 기획자가 전체 프로젝트를 고려해서 원금을 조금씩 갚아나가는 수밖에 없다. 기술 부채가 환율이 떨어진 외화 같은 존재가 아니라, 현재 효율적이고 빠른 기술 구현으로 인해 비즈니스를 확장하는 데에 기여하는 '투자'의 개념으로써 부채가 되도록 고민해야겠다.
