호미로 막을 것을 가래로 막게 될 수 있는 이야기
안녕하세요? Kay입니다.
오늘은 기술부채 이야기를 해볼까 합니다.
기술부채? 그게 뭘까요? 검색창에 기술부채를 검색하면 윗줄에 다음과 같은 내용이 검색이 됩니다.(출처:위키백과)
기술 부채(technical debt, design debt, code debt)는 현시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발생되는 추가적인 재작업의 비용을 반영하는 소프트웨어 개발의 한 관점이다. 기술 부채는 금전적인 채무와 비유될 수 있다.
아직까지도 감이 잘 안 옵니다. 물론 저도 100% 이해를 한다고는 자신할 수 없습니다만, 저의 이해범위안에서 설명해 보겠습니다.
예를 들어 어떠한 앱을 만들어서 서비스를 제공한다고 해 보겠습니다. 그런데, A범주의 항목과 B범주의 항목은 서로 간 특정 로직에 의해서 매칭이 됩니다. 그런데, 한 두건씩 에러가 생깁니다. 그러면, 로직에 뭔가 버그가 있지 않나 살펴보고 수정을 해야 하겠지요. 하지만, 이 바쁜 시기에 로직을 찬찬히 다시 보고 수정할 여유가 없습니다. 결국 문제가 되는 항목에 대해서 A범주와 B범주를 수동으로 매칭해 버리고 문제를 종결해 버립니다. 당장은 빠르고 편한 해결책이지요. (마치 엑셀에서 데이터를 함수처리 하지 않고 그냥 수동으로 입력하는 것과 비슷하지요.)
그런데, 말입니다...
사업이 잘되어 앱의 고객이 많아졌습니다. 엄청난 데이터를 처리하게 되었는데, 예전에 버그를 잡지 않은 것이 지금 문제가 되어 버렸습니다. 대부분의 데이터는 잘 처리되지만, 여전히 치명적인 오류가 존재하는 것이죠. 문제가 생겼던 초기에 버그를 잡았으면 적은 비용과 노력으로 해결이 되었을 텐데, 지금 이 시점에서는 엄청나게 많은 투입이 필요하게 돼버렸습니다. 이러한 추가투입을 '기술부채'라고 말씀드릴 수 있겠습니다.
HR도 비슷합니다.
조직의 설립단계나 초기 성장단계에는 HR에 신경을 쓸 여유가 없습니다. 당연합니다. 굳이 업무절차나 제도를 만들거나 준용할 필요가 없습니다. 인원수가 얼마 되지 않기 때문에 다들 불문율로 혹은 '융통성'으로 처리합니다. 하지만, 조직이 커지고 구성원들의 수가 많아지게 되면 절차와 제도가 필요하게 됩니다. 그렇지 않으면 담당자 간, 팀 간, 조직 간에 트러블이 발생할 수밖에 없게 됩니다. 초기 멤버들은 괜찮을 수 있지만, 나중에 들어온 구성원들은 그동안 불문율로 이루어져 왔던 일하는 방식에 대해서 매우 혼란을 느낄 수밖에 없습니다.
저는, 이러한 현상을 'HR부채'라고 명명하고 싶습니다. 조직의 성장 초기 단계 혹은 인원수가 얼마 되지 않을 때부터 조금씩 HR에 대한 관심을 갖고 준비를 해야 합니다. 관심을 갖지 않아도 당장은 큰 문제없이 편할 수도 있겠지만, 언젠가 조직이 폭발적으로 성장을 하게 되었을 때 불필요한 조직의 추가 투입이 발생하게 될 것입니다.
오래된 기업들의 HR은 어느 한순간 갑자기 만들어진 것이 아닙니다. 많은 스타트업도 언젠가 조직이 커지면 그때 가서 해도 되겠지 라는 생각을 가져서는 안 될 것입니다. HR은 당장에 조직의 생산성에 별 도움을 주지 못하는 것처럼 보일 수도 있지만, 사내 자원의 불필요한 낭비를 최소화할 수 있도록 언제나 노력합니다.
감사합니다.