기술 부채는 빠르게 기능을 구현해야 한다는 압박감, 의사 결정 변경, 데이터 구조 변경 그리고 시간이 흐름에 따라 자연스레 발생하기 때문에 기술 부채 없이 서비스 한다는 것은 사실상 불가능 하다고 생각해요.

기술 부채를 어떻게 다루고 해소해야 하는 지에 대해 많은 글들과 경험이 공개되어있는데, 이 또한 '기술 부채를 해소해야 한다' 라는 전제 하에 '해소를 위한 리소스 사용을 보장' 받거나, '기술 부채를 최대한 천천히 쌓아야 한다'라는 전제 하에 '개발 공수가 지연되는 것을 이해'받아야 가능한 내용들이 많았어요. 그렇다는 것은 팀 단위나 조직 단위, 혹은 의사결정권자에 대한 설득과 합의가 필요하다는 뜻이겠죠.

기술 부채가 누적되어간다면, 정작 중요할 때 가지 못하게 만들 수 있습니다. 신규 사업, 신규 플랫폼 출시, 신규 기능... 살아남고 커지기 위해 끊임없이 새로운 무언가를 발굴하는데, 정작 기술 부채로 발목이 잡혀 좋은 타이밍을 놓치게 된다면 회사의 성장 곡선도 수그러들 수 있습니다. 늘어가는 운영 이슈와 유지보수성 업무로 대부분의 개발 리소스가 사용된다면, 어떻게 새로운 것을 만들어 낼 수 있을까요?

개발자는 혁신과 개선, 자동화를 좋아하는데 기술 부채는 개발자의 사기를 저하시키기도합니다. 이는 특히 '내가 작성한 코드'나 '내가 만든 기능'과 '나'를 동일시 할수록 심해질 수 있습니다. 최근 동료 개발자 분과의 대화 중 '새로 구축하는 프로젝트는 개발자한테 복지다.'라는 이야기를 했는데, 그 복지를 경험해 본 사람으로써 공감이 되는 말입니다.

하나만 포기하면 되겠지, 라는 생각에 하나를 포기하면 다음에 또 하나를 포기하게 되고, 그렇게 포기할 것들만 늘어갑니다. 사방팔방에서 다양한 이유로 어려움이 생기겠지만, 마케팅이 숫자를 신경쓰고, 디자인이 UX를 신경쓰고, PM이 일정을 신경쓰는 것처럼 개발자라면 기술 부채에 대한 신경을 써야하지 않을까 생각해봐요.

기술 부채를 대하는 다양한 방식에 대해 이야기나누면 즐거울 것 같네요 ㅎㅎ

P.S. 개인적으로는 적당한 기술 부채는 레버리지 투자처럼 최대한의 효율로 성장할 수 있는 방법이기 때문에, 기술 부채가 무조건 나쁘다고 생각하지 않고 상황에 맞는 판단이 중요하다고 생각해요. 그렇기 때문에 더 어려운 것이지만, 그렇다고 빚이 많은 걸 좋아하는 사람은 없을 거라고 생각해요. :)