스타트업의 개발자 채용, 그리고 스택 변경에 대한 단상

스타트업의 개발자 채용은 어려운가?


 많은 스타트업 경영인들과 유니콘 기업들의 리더들은 스타트업에게 중요한 핵심 덕목 중 하나로 빠른 시장 변화에 대응하기를 꼽곤 합니다. 기업에겐 빠른 시장 변화에 대응하는 것이 당연히 기업의 생존성을 높이고 시장 경쟁력을 확보할 수 있는 요소이니, 스타트업 뿐 아니라 대부분의 기업에게도 중요한 요소일 수 있겠습니다.

빠른 시장 변화에 대응한다는 것은 스타트업의 개발 조직에게는 조금 다른 느낌으로 전달 됩니다. 개발된 시스템은 방향 전환에 시간이 소요되고, 이러한 시간을 줄이게 되면 개발 부채라는 저장고가 차게됩니다. 이러한 문제를 최소화 하고자 소수의 개발조직으로 빠르게 생산성을 높일 수 있는 언어/시스템 프레임워크 등이 스타트업에게 고려됩니다. Ruby on Rails나 Django와 같은 프레임워크부터 node.js, Python 과 같은 개발 언어를 시스템 언어로 선정하는 등을 통해 소수의 개발 인력으로도 운영과 구축이 가능한 시스템을 만들도록 설계합니다.

스타트업의 확장면에서는 앞서 선택한 전략이 잘 맞아들어가는 시기가 존재합니다. 서비스가 확장하고 유저수가 늘어날수록 회사에 수익이 돌기 시작하고, 개발조직을 포함한 모든 조직이 성장합니다. 성장된 조직들은 다양한 시스템 니즈를 요구하고, 이러한 니즈들에 즉시 대응해 나가며, 기존의 시스템 언어/프레임워크를 선택한 결정에 대해 만족할 수 있을 것입니다. 그 과정에서 개발조직의 확장은 언제나 그렇듯 기존 시스템에 종속적이고, Java 위주의 국내 IT 시장에서는 적합한 개발자를 찾는데에 문제를 겪게 됩니다.

우리나라의 많은 기업들은 Java를 그 시스템의 코어 언어로 활용합니다. 대기업 뿐 아니라 중견기업을 포함하여 SI/SM 을 포함한 많은 기업들의 시스템이 Java로 구성됩니다. 스타트업이 Java로 초기부터 시스템을 구축하는 것은 불가능에 가깝습니다. 최초 자본금이 몇억씩 있는 경우가 아니라면, Java 기반의 웹서비스를 운영/제공하기 위해 필요로 하는 개발자의 최소 구성수를 감당할 수 없기 때문입니다. 서비스가 성공할지, 실패할지도 모르는 상황에서 혼자서 많은 것을 해결할 수 있는 개발자를 데려오기도 어려울 뿐더러 설사 방향성에 공감하는 개발자를 찾더라도 비용적인 문제를 감당하기 쉽지 않습니다.

지금 제가 속한 곳 역시 Python/Django를 최초 기술 스택으로 선정하였고, 지난 6년간 많은 성장을 거듭해오면서 수많은 기술 부채와 수백가지의 비즈니스 로직을 가진 수십가지의 도메인들이 개발 효율을 저하할만큼 쌓여있습니다. 이러한 상황속에서 개발자의 채용에 어려움을 겪기 시작하면서 Java로의 시스템 포팅이 화두에 올랐습니다.

무엇이 문제인가?

사실 대부분의 스타트업이 현재의 속도를 유지하거나 현재의 성장 만큼 앞으로도 진행하기만을 바란다면 이러한 문제를 겪지는 않을 것입니다. 기술 부채와 정량화되지 않은 비즈니스 로직은 개발 효율을 저하할 수는 있지만 주기적으로 관리가 가능합니다. 쉽게 생각하여, 2:1의 비율로 확장 목적의 시스템 개발과 부채 해결 및 안정화 목적의 리팩토링을 병행해 나갈 수 도 있습니다.

그러나 궤도에 오르기 시작하는 스타트업들은 더욱 빠르게 성장하고 더욱 기민하게 움직이고 싶어합니다. 흔히 말하는 j-curve의 시작점이 다가왔을 때 그 곡선의 높이를 더욱 크게 만들 수 있는 방안을 빠르게 찾고 빠르게 적용하고 싶어합니다. 더 빠르고 기민한 개발 조직을 만들기 위해서는 더 많은 개발자의 채용과 효율적인 조직 구성이 필요합니다. 문제는 이 과정에서 더 많은 개발자의 채용이 가능하게 할만큼 기업의 인지도, 채용에 투입될 자금력, 국내 개발자 Pool의 3박자가 딱 떨어지는 일이 없다는 것입니다.

우리나라의 IT 시장에서의 개발자 Pool은 100명의 Java 개발자를 채용하는 것이 30명의 Ruby 개발자를 채용하는 것보다 쉽고, 효율적인 조직이 구성될 수 있도록 할만큼의 적당한 경력과 업무 능력을 갖춘 개발자는 그 연봉이 적지 않습니다. 더군다나 기업의 인지도가 국내 업계에서 얼마나 알려져있느냐(물론 서비스가 B2B이냐 B2C냐는 큰 기준이 있지만) 역시 개발자의 이직에 영향을 주는 강한 요소 중 하나입니다. 물론 기업의 인지도에 있어 가장 큰 문제는 개발자들이 기업의 채용 공고를 관심갖고 볼만큼 기업을 잘 알지 못한다는 문제입니다.

개발자를 제외한 조직 구성원이 20~40명 내외인 스타트업 정도의 규모라면 개발조직도 그에 상응할 만큼 확보가 되어 있어야 겠지만, 위 3가지 요소 중 하나라도 어긋난 다면 채용은 쉽지 않습니다. 그중에서도 기업이 컨트롤 하기 어려운 유일한 영역이 개발자의 Pool입니다. 이는 기업이 기존 시스템의 언어를 변경하는 것에 대해 고민하게 되는 가장 기본적인 이유입니다.

문제를 더 뜯어보았는가?

해결이 가능한지에 대한 부분은 무엇이 문제인지에 대해 조금 더 바라보아야 합니다. 기업의 인지도와 채용에 투입될 자금력은 당연하게도 기업이 해결에 나서야 할 부분입니다. 이 두가지가 부족하다면 기업 스스로 해결방안을 모색해야 합니다. 돈이 많다면 채용 공고에 압도적으로 많은 비용을 쏟음으로써 인지도를 조금이나마 높이고, 돈이 부족하다면 투자나 비용 최적화 등을 통해 개발자에게 더 사용하는 방향으로 조율이 가능하겠습니다. 또는 개발자에게 기존의 직책/직급보다 더 높은 것을 제공함으로써 얻어낼 수도 있습니다.

개발자의 Pool 문제에 있어서는 기업이 해결하기 조금 어려운 문제입니다. 위에서의 언급처럼 기업이 사용하는 시스템 언어를 보편적인 것으로 변경하는 옵션이 그렇기 때문에 고려되는 것으로 보입니다. 저 역시 이점을 고민하면서 당연스럽게 떠올린 옵션이었던 것 같습니다. 유일한 대안이자 가장 문제 해결에 가까운 것으로 생각했습니다.

그러나 이 생각에 간과한 것이 있었습니다. 최초의 문제로 돌아가 왜 이 언어/프레임워크를 스타트업의 언어/프레임워크로 정했는가? 입니다. 시장 변화에 더 빠르게 대응할 수 있도록 시스템 구축 비용이 저렴하고 소수의 개발자로 기능 개선/구축 및 운영이 가능하도록 하는 것 입니다. 이러한 특성은 지금까지 팀 내부에게 자연스러운 모습이었지만, 시스템 언어의 변경은 이러한 특성을 없애버릴 수 있는 리스크가 존재합니다. 기능 하나를 구성하기 위해 필요로하는 Django 개발자 한명의 생산성은 같은 경험을 가진 java 개발자의 생산성보다 효율적입니다.

또, 현재의 IT 개발자 시장은 위에서 언급한 바대로 대기업과 중견기업에 의해 구축되고 안정화된 Java 시장이 주류입니다. SI 시장에 존재하는 많은 Java개발자를 포함하여 구축된 시스템의 운영을 위해 필요로 하는 Java개발자까지 원인과 과정 모두에 있어서 대기업이 얽혀있습니다.

두가지 생각으로 정리될 수 있었습니다.

  1. Java와 같은 주류 언어로 변경할 경우 지금과 같은 생산 퍼포먼스를 유지하기 위해 필요로하는 인력은 어느정도인가?
  2. 대기업이 타겟으로하는 Java 개발자 시장에 우리 정도의 인지도와 자금력으로 채용이 가능한가?

생각의 결론

채용 문제를 해결하기 위해 시스템 언어를 변경하는 것이 좋은 솔루션인가에 대해서는 위 두가지 이슈에 대해 x배, 네라고 대답할 수 있어야겠습니다. 2번째 생각에 대해 기업문화나 사무실의 위치, 팀원들과의 관계 등을 통해 ‘네’라고 대답이 가능하더라도 x의 숫자 크기가 어느정도인지가 중요한 듯 합니다. 아직 Java에 대해 많은 공부가 이루어지지 않았고, 어느정도의 생산성 차이를 갖길래 많은 개발자들이 Python, Ruby와 Java의 생산성 차이에 대해서도 크다고 이야기 하는지 명확하지 않습니다.

1, 2번의 생각들에 내린 결론이 ‘시스템 언어 변경은 좋지 않아’ 라면 몇가지 방법이 더 있는 것 같습니다. 물론 검증이 필요하고 생각보다 오랜 시간이 걸릴 수도 있겠지만 크게 2가지 방안이 보입니다. 두가지 중 한가지만 해서는 문제 해결이 불가능할 것이고, 두가지 모두 오랜 시간이 소요되는 방법입니다.

  • 주니어 개발자를 채용하여 원하는 능력 수준만큼 성장시키는 방안
  • 개발 조직의 효율성을 개선하는 방안 이 두가지를 모두 수행하는 것이 새 시스템 언어를 선정하여 채용하고, 차세대 시스템을 구축하는 과정에 들어가는 비용보다 적은 것이 명확해야만 시도해볼 방법이겠습니다.

결국 시스템 전환에 얼마만큼의 비용이 들어가는 가를 알아야 비교가 가능하다는 생각으로 이어집니다. 다가오는 다음 주말에는 Java의 생산성에 대한 검토와 Spring MVC를 좀더 해본 뒤에 생각을 정리해보아야 겠습니다.

More from TooLate
All posts