높아지는 개발자 연봉에 어떻게 대처해야 할까
“개발자 인건비에 대한 실제 비용에 대해 계산해보았습니다”
개발자의 연봉이 요즘 뜨거운 감자이죠. 이에 우리 회사의 개발자 연봉 정책은 어떠한지, 그리고 어떤 기준으로 고객사에 개발비를 청구하고 있는지 공유합니다. 저희 개발자분들의 인건비는 신입 기준 연봉 3천만 원부터 시작하여 6천만 원 중반까지 고르게 분포되어 있습니다. 분기별로 연봉이 자동으로 인상되기 때문에 2년 차에 6천 대까지 도달하게 되고 매출 증가분에 따른 인센티브, 스톡옵션 등을 추가 보상으로 지급합니다.
시간당 개발자 인건비는 얼마나 될까?
개발자의 연봉에 대한 실제 비용을 시간 단위로 변환해보겠습니다. 우선 연간 근무시간을 계산해야 합니다. 토/일/공휴일을 빼고 남은 연간 평일 수 평균은 250일입니다. 평일 모두 근무하는 것이 아니니 유급 휴가인 연월차와 경조사 휴가를 고려하면 연간 평균 20일 정도는 빠진다고 볼 수 있습니다.
거기에 3~4개월의 출산 휴가까지 고려하면 월 200만 원의 국가지원금을 고려하더라도 차액만큼은 회사 부담이기 때문에 연봉이 5천 수준이라면 2개월 정도의 인건비가 발생합니다. 여성 근로자가 절반이라고 가정, 5년에 한 번 출산을 한다고 가정하여 2개월에서 5년을 나누고 성별 비중인 2로 나누어 6일 적용해보겠습니다. (성비나 출산 빈도에 있어서 공격적인 가정인데, 높은 여성 근로자 비율과 높은 출산 빈도가 가능한 안전한 근무 환경을 만드는 것이 목표여서 입니다)
250일 중 35일을 빼면 215일입니다. 하루 8시간 근무하기 때문에 1792시간을 근무하는 것이죠. 5천만 원의 연봉을 1792시간으로 나누면 28,000원이 되고 이것이 근로자 입장에서의 실질 시급이 됩니다. 인센티브/스톡옵션 등은 고려하지 않은 상태입니다.
실질적인 시간당 고용 비용은 얼마나 될까?
기업 입장에서의 고용 비용은 여기서 더 추가되는데요, 크게 퇴직금, 4대 보험에 대한 기업부담금, 임대료, 식대, 간식/비품 등 기타 경비와 노트북/모니터/소프트웨어 등의 장비 구입비가 추가로 들어갑니다.
퇴직금은 매년 연봉의 1/12을 적립하게 되므로 연봉에 420만 원을 더하고, 4대 보험에 대한 기업부담금이 10% 정도이니 500만 원을 또 더하게 됩니다. 점심 식대를 만 원 지급한다면 215일을 먹어야 하니 215만 원이 더해지고 간식/비품을 식대의 1/4 정도로 잡으면 54만 원이 추가됩니다. 인당 모니터와 장비는 연간 60만 원 정도, 인당 소프트웨어 비용은 연간 60만 원 정도로 고려해보겠습니다.
임대료는 인당 월 30~60만 원 선입니다. 위치가 좋고 쾌적할수록, 단독 사무실보다 공유 오피스일수록 비용이 비싸집니다. 단독 사무실이라도 중개비, 인테리어, 관리비, 시설 관리비, 청소비 등을 고려해야 하니 45만 원 정도는 생각해야 합니다. 1년이면 인당 540만 원의 임대료가 발생합니다. 5천 만 원대의 연봉을 지급하면 실제 비용은 6,850만 원이 되었습니다. 이를 연간 근무시간으로 나누면 38,000원이 되니 인당 38,000원의 비용이 매시간 숨만 쉬어도 나간다고 보면 됩니다.
운영 비용과 리스크를 고려하면 얼마큼의 비용을 개발비로 청구해야 할까?
모든 임직원이 매출과 연관되는 것은 아닙니다. 매출과 연관된 임직원의 모든 업무 시간이 매출로 연결되는 것도 아닙니다. 규모가 커지게 된다면 CS, 제휴, 영업, 인사, 마케팅 등 직접적인 매출과 연결되지 않는 인력의 비중이 높아지게 될 것입니다.
저희 같은 개발사는 매출을 발생시키는 개발 직군이 매출을 발생시키지 않는 운영 직군의 비용까지 감당할 수 있어야 손익분기를 넘을 수 있습니다. 저희 회사는 제가 대부분의 운영/행정/회계/인사 업무를 담당하고 많은 업무를 최대한 자동화하는 등 굉장한 노력으로 운영 비용을 최소화하고 있어 대부분의 인력이 매출을 발생시키는 개발 직군입니다. 하지만 통상적인 개발사라면 매출을 만들어내는 직군이 50~70% 수준일 거라고 봅니다.
50% 수준이라고 가정하면 개발 시간당 비용 2배 이상을 청구해야 손해가 아니게 됩니다. 더불어 개발업은 큰 금액 단위의 계약을 중심으로 하기 때문에 계약 이행 여부나 치명적인 오류 등에 따른 손해 배상 리스크를 지고 있습니다. 저희는 다행히 소송을 당하거나 제기한 경험이 없지만 저에게 종종 개발 소송과 관련한 자문 요청이 오는데, 이익률이 낮은 개발사들의 경우 한두 건의 개발 실패나 손해 배상 소송으로 폐업을 하곤 합니다.
반품하면 그만인 5만 원짜리 물건을 파는 것이 아니라 고객의 사업에 필수적인 5천만 원짜리 플랫폼을 판매하는 것이기 때문에 결과물에 불만족한 고객이 손해를 주장할 법적인 리스크가 존재합니다. 이 때문에 3배 이상 청구해야 리스크를 반영한 손익분기점이 된다고 생각하고 그렇지 못하면 한두 번의 프로젝트 실패에 사업이 휘청하게 된다고 생각합니다.
그리고 고객사가 다양하게 분포되어 있지 않고 소수의 고객사에 매출 의존도가 높다면 리스크는 더 커집니다. 저희는 연간 40~50개 고객사 프로젝트를 진행하기 때문에 기본적으로 프로젝트 리스크가 분산되고 있으면서, 각각의 프로젝트를 여러 단계로 백업하고 있습니다. 또한 고객사에서 불편한 점을 느꼈다면 이를 해소하기 위해 적극적으로 대안을 제시하고, 기본적으로 담당 개발자분들이 최선을 다하기 때문에 리스크 분산과 리스크 최소화를 모두 추구하고 있습니다.
기술 투자와 개발자 교육까지 고려하면?
마지막으로 또 한 가지 고려해야 할 사항은 선행적인 기술 개발을 할 수 있는 비용 투자가 필요하고 신입 개발자 교육 투자가 필요하다는 점입니다. 개발 환경은 매우 빠르게 변화하고 좋은 기술들은 쏟아져 나오고 있고 이를 미리 전사적으로 학습하고 적용하지 않으면 시대에 맞지 않은 방법으로 개발을 하게 될 것입니다. 그리고 새로운 기술에 대한 도입과 학습 과정 자체가 좋은 개발자를 채용하고 장기근속을 시킬 수 있는 동기가 됩니다.
좋은 처우를 마련해주더라도 임직원은 더 좋은 기회 또는 새로운 도전을 위해 이직을 할 수 있기 때문에 회사는 지속해서 새로운 개발자를 채용하고 교육하며 원활한 인수인계를 준비해야 합니다. 이 과정 역시 매출이 발생하지 않고 비용을 투자하는 단계입니다. 이 때문에 4배 이상 청구할 수 있어야 교육과 기술 투자가 가능해져 개발업을 지속할 수 있다고 생각합니다.
투자와 리스크, 실질 고용 비용을 고려하면 장기적으로 지속할 수 있는 비즈니스는 개발자 인건비의 4~5배를 고객에게 청구할 수 있어야 하고 연봉이 5천만 원인 개발자라면 시간당 고용 비용인 38,000원의 4~5배 15만 원~19만 원 수준을 청구해야 합니다. 예전부터 직원 한 명이 본인 인건비의 5배 이상의 매출을 벌어야 한다는 이야기를 들었었는데, 계산해보면 그 이야기가 어느 정도 맞는다는 것을 알 수 있습니다.
장기적으로 개발업을 지속하려면 시간당 비용을 정상화해야 합니다
저희는 실제로는 이에 못 미치는 시간당 개발비를 청구하고 있습니다. 그런데 장기적으로 이 업을 지속하기 위해서는 시간당 청구 개발비를 점차 정상화해야 한다는 계획을 가지고 있습니다. 리스크 대비를 하지 않으면 한두 번의 실패로 회사가 휘청할 수 있고 기술 투자를 하지 않으면 오래된 기술 때문에 가라앉게 되며, 교육 투자를 하지 않으면 신입이 더 많은 시행착오를 겪게 되기 때문에 이 모든 것을 잘 관리해야 지속 가능한 비즈니스가 됩니다.
청구 비용을 높이면서 동시에 적정한 고객사의 예산 범위 내에서 출시 가능한 프로덕트를 만들어내기 위해서는 개발자들의 시간당 부가가치를 극대화해야 합니다. 개발 지식은 회사 차원으로 축적하여 모든 임직원의 효율성을 끌어올리고 소통의 비효율을 없애기 위해 애자일하고 린하게 개발해야 합니다. 개발자가 고객사와 직접 소통하게 만드는 것은, 높아지는 시간당 인건비를 감당하면서 고객사에서 얻는 결과물의 가치는 충분히 높이는 두 가지 목표를 달성하기 위해 저희가 찾아낸 방법입니다.
개발자의 인건비를 낮추면 되지 않나요?
저희 급여 수준은 스타트업 업계 기준으로 초임은 낮은 편이지만 급여 인상에 따른 1~3년 차 급여는 적정한 수준이라고 생각합니다. 그런데 외주 개발 업계 기준으로는 저희의 급여가 상당히 높은 편일 것입니다. 저는 스타트업 플랫폼을 개발하는 개발사라면 그것이 외주 개발 형태라 하더라도 외주 개발 시장의 기준이 아니라 스타트업 개발 시장의 기준으로 급여를 맞추어야 스타트업 플랫폼을 원활하게 개발하는 좋은 태도와 책임감과 지식과 동기를 가진 개발자를 채용할 수 있다고 생각합니다.
임직원이 최소한 처우에 불만은 갖지 않아야 회사와 안정적인 관계를 맺고 고객사의 어려운 프로젝트에도 적극적으로 문제 해결을 하게 됩니다. 초봉을 낮추면 당장 높은 급여 조건만 중요시하는 분들을 걸러낼 수 있고, 지속해서 급여를 인상하면 본인 실력의 성장과 함께 보상의 증가가 연동되어 장기적인 근속에 대한 동기부여가 된다고 생각하여 설계한 급여 정책입니다.
다양한 스타트업 프로젝트를 주도적으로 개발할 수 있으면서 다양한 기술 스택을 익힐 수 있고 기술과 지식에 대한 백업을 회사 차원에서 한다는 점은 개발자들에게도 충분히 매력적이어서 저희 회사를 좋게 보신 개발자분들은 급여를 낮추면서 지원을 하기도 합니다. 예전에 비해서는 채용이 원활해지긴 했죠. 그럼에도 신입 개발자들 중에 몇몇은 저희가 채용 제안을 했음에도 다른 곳에 입사했습니다. 이만큼 고민하고 처우를 제시해도 채용은 여전히 쉽지 않은 상황이라 인건비를 낮추는 것은 해결책도 아니고 바람직하지도 않은 것입니다.
개발사에 의뢰하는 대신 채용을 하는 것이 더 나을까요?
신입/경력할 것 없이 개발자의 연봉은 올랐는데, 연봉이 20% 인상되었을 때 실력이 20%가 자동으로 개선이 되지는 않았을 것입니다. 비용만 20% 증가한 상황입니다. 더불어 수요가 많아져 연봉이 오른 것이기 때문에 방금 창업한 스타트업에서 개발자를 채용하기는 더 어려워졌고요. 채용해도 장기적인 근속을 유지하는 것은 또 다른 이야기입니다.
채용에 성공했다 하더라도 5천만 원 수준의 연봉에 대한 실질적인 연간 비용은 7천만 원에 가깝습니다. 5천만 원 연봉의 개발자 1명을 채용해 7개월 동안 플랫폼을 개발했다면 4,000만 원의 비용을 사용한 것이 되고 출시에 성공했다면 4,000만 원을 그래도 합리적으로 잘 사용한 것이 됩니다.
그러나 초기 스타트업이 처음 채용한 개발자가 혼자서 6개월 안에 플랫폼을 개발하고 출시할 수 있는 확률은 절반이 안 될 것 같습니다. 그 개발자가 사용해보지 않은 기술, 구현해보지 않은 기능, 맞닥뜨려보지 않은 앱스토어나 결제 심사 거절 등으로 프로젝트가 실패했다면 7개월의 시간과 4000만 원의 비용은 제로로 돌아가게 됩니다. 일정 내에 구현이 가능한지 여부도 판단하기 어려워 1년을 허비하게 된다면 더 비관적입니다.
이제는 개발사에 의뢰하는 것이 확실히 낫습니다
저희가 의뢰받는 경우 4,000만 원의 비용에 적절한 구현 범위를 사전에 협의한 상태로 착수하여 4개월 전후의 기간에 개발 완료 및 출시가 대부분 됩니다. 기능 추가, 기획 변경이 필요하다면 적절한 시간과 비용만큼 추가될 수는 있지만 이에 대한 선택지도 고객사에 드리게 되고요. 심사 거절의 사유도 그래도 개발사 차원에서 노하우가 많이 쌓여있고 보완 후 재심사에 최선을 다합니다.
출시한 이후에 채용을 한다면 채용한 개발자가 플랫폼을 새로 구축하는 것이 아니라 출시한 서비스에 대한 유지보수를 하면 되기 때문에 구현 리스크 적어진다고 볼 수 있고 출시한 플랫폼을 가지고 공고를 내면 채용도 쉬워지며 개발자에게 저희가 적극적으로 코드 인수인계를 해드립니다. 플랫폼이 출시된 상태라면 개발자 채용 비용 마련을 위한 투자유치도 그전보다 수월해집니다. 개발자 채용 비용이 비싸진 이유 자체가 스타트업 투자 시장에 자금이 많이 풀렸기 때문이고 사람보다 돈을 구하기가 더 쉬워졌다고 볼 수 있습니다.
저희는 높은 인건비 수준을 맞추면서 시간당 개발 결과물을 늘려나가기 위해 효율적인 방식을 연구하고 기술과 지식이 축적되고 단계적인 기술 백업을 통해 개개인의 개발자가 헤매는 상황을 최소화합니다. 난이도와 리스크가 높은 기능은 고용 비용이 높은 개발자가 맡고, 난이도가 낮은데 시간이 많이 걸리는 화면 구성 등을 고용 비용이 아직 낮은 개발자가 맡게 하여 난이도에 따라 업무를 분산하여 개발 비용을 최적화할 수 있습니다. 첫 번째 버전의 서비스는 저희 같은 개발사에 의뢰를 하는 것이 무조건 낫다고 이제는 자신 있게 말할 수 있습니다.
해당 글은 인썸니아와 모비인사이드의 파트너쉽으로 제공되는 기사입니다.
