여기서 일컫는 ‘성장부채’란, 직원의 성장을 위해 회사가 선제적으로 부담한 비용·시간·복잡성이, 회사의 성장을 저해하거나 위험을 증가시키는 상황을 말한다. 직원의 성장이라는 ‘미래 가치’가 실현되지 않으면, 그 부담은 온전히 회사의 부채로 남게 된다.
2020년 초, 스타트업에 유동성이 넘치고 개발자 시장이 과열되던 시기, 많은 창업자들이 공통적으로 빠졌던 함정이 있었다. 바로 ‘개발자의 성장’이라는 명분이다.
많은 회사들이 우수한 개발자들을 채용하기 위해 높은 연봉과 스톡옵션은 물론, ‘성장할 수 있는 환경’을 제공하기 위해 과도한 투자를 해왔다. 조직과 구성원이 함께 성장한다면 이상적이지만, 실제로는 직원만 성장하고 회사는 성장하지 못한 채 비용만 떠안고 결국 무너진 사례가 적지 않았다.
단일 베어메탈 서버로도 충분한 서비스임에도 굳이 복잡한 클라우드 인프라와 쿠버네티스, 마이크로서비스, GraphQL 등을 도입하거나, 실무적으로 필요 없는 기술을 이력서 한 줄을 위해 적용하는 일이 흔했다. 이렇게 늘어난 인프라의 복잡성은 퇴사 후 유지보수 부담으로 이어져, 회사 입장에서는 투자 대비 효과가 미미할 수밖에 없었다.
회사는 자본을 투입해 이익을 창출하고 이를 주주에게 분배하기 위해 존재한다. 그러나 많은 조직은 ‘좋은 개발자’를 판단하는 기준 자체가 어긋나있었다. 다양한 언어와 프레임워크 경험, 미세한 성능 개선, 그리고 기술적 완성도만을 강조하기보다, 자신의 기여가 실제로 회사의 매출을 증대시키고 비용을 절감하는 데 어떤 영향을 미쳤는가를 중심에 두었어야 했다.
그동안 수많은 경영진이 직원 성장이라는 명분 아래 과도한 시간과 비용을 투입했으나, 그에 상응하는 성과는 돌아오지 않았다. 값비싼 교훈이었다. 지금은 다행히도 AI 코딩 어시스턴트의 발전으로 인력 효율은 개선되었지만, 오버엔지니어링을 비롯하여 인프라에 과잉 투자하는 비효율이 여전히 곳곳에 남아 있다.
반대로, 지금 새롭게 시작하는 조직들은 인력 구성과 인프라 모두 ‘제로 베이스’에서 설계할 수 있다는 점에서 매우 유리하다. 단순하고 최소한의 기술 스택으로 시작하여, 실제 유저가 원하는 가치를 더 빠르게 검증한 뒤에만 확장하면 된다. 가장 중요한 점은, MVP를 지나 사업이 본궤도에 오른 후에도 기술적 결정의 근거에는 ‘지금 정말 필요한지’를 기준삼아야 한다는 것이다.
돌이켜보면, 회사를 무너뜨리는 것은 기술부채보다 성장부채인 경우가 훨씬 많았다. 기술은 시간이 지나면 자연스럽게 낡고 부채가 쌓이지만, 그것만으로 회사가 쉽게 망하지는 않는다. 반면 성장부채는 비용을 증가시키고 속도를 느리게 만들며, 회사의 에너지에 돌이킬 수 없는 피해를 입힌다.