기술부채

기술부채라는 단어를 처음 들어본 것은 Blockchain 업계에 있을 때였다.

그 전까지는 기술부채라는 단어도, 레거시라는 단어도 알지 못한 채로 일을 하고 있었다. 스타트업에서 새로운 기술들을 개발하고 PoC를 하면서 기술부채를 갚겠다는 이야기를 하여서 알게 되었었다.

 

기술부채에 대한 설명은 다음과 같다

기술 부채(technical debt, design debt, code debt)는
 
현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점

이다.

 

개발 조직에 몸을 담고 있으면서 한정된 자원 (시간, 돈, 인력) 들로 인해 기술부채가 발생되지 않는다는 것은 말이 안되는 일일 것이다.

하지만, 부채라는 것은 결국 빚이기에 갚아나가야하는 노력도 필요하다.

 

그렇기에 수 많은 회사에서 기술부채를 갚기 위해서 리팩토링이며, 차세대며, 고도화라는 이름으로 소스를 유지보수를 해가면서 더 양질의 서비스를 제공하기 위해서 노력을 한다.

 

현재 몸 담고 있는 조직에서도, 작년까지 엄청난 레거시 코드들로 인해서 유지보수가 불가능한 상황에 처했었다.

수많은 로직들이 쿼리로 작성이 되어있었으며, If 문으로 처리가 되던 코드들은 80년대에 작성된 코드처럼 보일 정도였다.

이러한 부채를 갚기위해 회사에서는 거금을 들여 차세대 프로젝트를 진행을 하였다.

 

하지만, 차세대 프로젝트는 또 다른 기술부채를 발생을 시켰다.

넥사크로며, 중앙집권화된 Library 코드며, 아키텍처를 고려하지 않는 설계를 통하여 SOLID 원칙은 개나 줘버리라면서 하나의 Class에 모든 로직을 녹여두었다.

 

이러한 상황에서, 허망하게 소스코드를 바라보고 있었다.

 

이 와중에, 현 조직의 CTO의 타이틀을 가진 분과 개발 실장의 타이틀을 가진 분께서는 기술부채를 갚기보다는 현 상황에서 더 많은 Feature 들을 개발해서 넣기를 원하며, 일정 또한 본인들이 정하지 않은 채 비개발자들에게 그 키를 쥐어주었다.

 

그 결과, 10일의 소요시간이 필요한 것들은 5일만에 완료를 해달라고 하며, 코드 한줄 볼 줄 모르는 실장, CTO들은 그저 "그거 간단한거 아냐? 왜 이렇게 시간이 걸려, 어디 다른 개발자들은 금방한다던데?" 와 같은 비건설적인 대화를 논한다.

 

이렇게 개발에 무지한 사람들과 일을 하다보면, 기술부채는 불가피하게 급속도로 증가한다는 것을 깨달았다.

 

나는 오늘도 빚을 만들고 있으며, 아마 누군가는 이 빚을 갚아야겠지.

누군가 갚지 않는다면, 또 다시 거금을 들여 돈으로 갚아야겠지.