인하우스 개발, 몇 명이나 필요하고 얼마나 들까?

SI 산업 가이드북 ⑬

이번 편은 “인하우스 전략”입니다. 내부 개발팀 구축을 고려하는 전통 산업 리더들이 청중입니다.

요즘 자동차는 자율 주행이 필요해졌고, 금융은 AI가 필요해졌고, 의료계는 원격 진료가 필요해졌습니다.

대기업들은 “OO 시스템즈” 같은 IT 계열사를 통해 문제를 해결하고 있지만, 내부 개발팀을 만드는 것도 고민하고 있습니다. 어떤 차이가 있을지 정리를 해봅니다.

인하우스란 당근의 주요 변화

2023년 말, 당근이 흑자전환을 했습니다. 창업한 지 8년 만이었죠. 회사는 직원 수 3명으로 시작했습니다. 지금은 400명이 조금 넘죠. 긴 세월 동안 SI 등으로 사업 전환을 하지는 않았습니다. 그리고 대부분 아웃소싱 없이 직접 개발했죠. 인건비가 많이 필요했습니다. 이를 위해 2,000억 원이 넘는 돈을 투자받았죠.

현재 당근 전체 인력의 70%가 개발 인력입니다. 지금도 무언가를 계속 만들고 있는 거죠.

이렇게 제품 개발을 모두 내부 개발자가 하는 걸 “인하우스 개발”이라고 합니다. 프리랜서를 고용하기도 하지만, 정말 일부 역할에 한해 한시적으로 쓰죠.

인하우스 개발의 장단점 Wishdesk >

인하우스 개발에는 단점이 있습니다.

먼저 고정비가 높습니다. 비싼 직원을 여러 명 데리고 있어야 하니까요. 그리고 계속 데리고 있어야 합니다. 회사의 개발 노하우가 직원에게 쌓이니까요.

부대 비용도 높아집니다. 채용과 교육 훈련, 관리 비용까지 생각해야 하죠. 시간 비용도 많이 들어갑니다. 업무 역량을 끌어내기까지 기다려야 하죠.

즉, 한 번 개발하고 말 거라면 인하우스 개발이 불리합니다. 아웃소싱을 하는 게 낫죠.

그렇다면 왜 인하우스 개발이 필요할까요?

첫째, 소프트웨어가 제품인 경우입니다. “직방” 같은 인터넷 서비스도 해당됩니다. 소프트웨어가 기업이 돈을 벌어들이게 해주는 직접 재화인 거죠. 100%가 아니라 50%만 해당하여도 됩니다. “테슬라”에서 자율주행은 빼놓을 수 없는 기능이죠. 제품을 만드는 강력한 구성 요소입니다. 인하우스 개발팀이 꼭 있어야 하는 이유죠.

둘째, 시장 변화에 맞춰 제품을 빠르게 바꿔야 하기 때문입니다. 빠르게 움직이려면 “우리 직원”이라는 운명 공동체 의식이 필요하죠. 느리게 대응해도 좋다면 아웃소싱으로도 충분합니다.

셋째, 노하우가 중요한 경우입니다. 노하우는 제품을 개량하기 위한 강력한 수단이죠. 시행착오를 통해서만 축적됩니다. 그리고 그 분량만큼 후발주자와의 거리도 멀어지죠.

아웃소싱을 하면 노하우는 외부 업체에 축적됩니다. 우리가 우리 제품을 더 좋게 만들기 어렵죠.

넷째, 보안 때문입니다. 아웃소싱을 하면 어쨌든 정보는 유출됩니다. 100%가 아니라 일부라고 해도요. 자투리를 모아 전체를 유추할 수 있습니다. 정보 유출이 사업에 큰 영향을 미친다면 인하우스 개발이 필수입니다.

돈이 얼마나 들까? 당신은 스타트업 창업자입니다. 인스타그램 같은 작은 앱을 만들려고 합니다.

몇 명이 필요하고, 얼마나 많은 돈이 필요할까요?

인스타그램 같은 앱을 만들려면 앱 개발 1명, 웹 개발 1명, 서버 및 DB 개발 1명, 이렇게 최소 3명의 개발자가 필요합니다. 기획자 1명, 디자인 1명까지 붙이면, 최소 5명이 되죠.

돈은 얼마나 들까요?

연봉, 퇴직금, 사무실비 등등을 다 더하면, 어느 정도 경력 있는 개발자라 했을 때, 1인당 평균 1억 원 정도 추산합니다. 개발팀 구성에 연간 5억 원 정도의 고정 비용이 필요한 거죠. 기타 비용을 생각하면 창업 비용으로 연간 7~8억 원을 준비해야 합니다.

이것도 1년 만에 제품이 나와서 그다음 해에 매출을 만드는 경우입니다. 아니라면 2년 차에 또 그만큼 돈을 구해야 하죠. 보통 첫해에 제품을 만들고, 둘째 해에 고객을 만들고, 셋째 해에 매출을 만듭니다. 그다음에 손익분기점(BEP)을 넘기도록 계획을 잡죠. 창업자는 이 기간을 버틸 수 있도록 돈을 구해와야 합니다. 단순 계산으로도 3년에 20억 원 정도 조달해야 하죠. 빌리거나 투자를 받아야 합니다.

사업마다 상황은 많이 다르겠습니다만, 어쨌든 창업할 때는 이런 식으로 꼼꼼히 따져봐야 합니다.

좋은 개발자를 만나고 기업 문화를 만들고 하는 건 그다음 이야기입니다. 인하우스 개발도 아웃소싱 못지 않게 어렵습니다.

개발팀의 변화 인하우스 개발팀은 아웃소싱 팀처럼 변하려는 경향이 있습니다. 분업화, 프로세스화 될수록 말이죠.

수익화 방식이 정해지고 사업 환경이 안정되면, 기술 환경도 안정됩니다. 그러면 기업은 낭비를 줄여 이윤을 높이려는 시도를 하죠. 이른바 효율화입니다.

가장 좋은 효율화 방식은 “분업, 프로세스, 반복”입니다.

“분업”은 업무 간 결합도를 낮춰 책임이 넘어가는 걸 막아줍니다. 남의 일은 생각할 필요가 없는 거죠.

“프로세스”는 생산 과정을 안정화 시킵니다. 프로세스가 시킨 대로만 해도 결과물이 나오는 거죠.

“반복”은 숙달을 통해 생산성을 높여줍니다. 좀 더 짧은 시간에 완성도가 올라가게 되죠.

이 모습은 어느 정도 “SI”와 닮아 있습니다. SI가 제조업의 효율화 방식을 벤치마킹했으니까요.

인하우스 개발팀은 아웃소싱에 필요한 업무 난이도를 낮추고, 비효율을 제거하는 “R&D” 역할을 하게 됩니다. 이 과정에서 인하우스 개발팀은 자연스럽게 프로세스 중심의 경직된 일 문화를 갖죠.

외부 환경의 변화가 적다면 좋은 선택이 될 수도 있습니다. 그게 아니라면 바람직하지 않죠.

개발팀의 경직성이 사업을 방해하게 됩니다. 개발자 문제라기보다 이렇게 만든 조직의 문제입니다.

우아한 말로는 “기술 변화에 대한 적응 실패”라고 하죠. 구글보다 컸던 Yahoo! 가 몰락하게 된 이유입니다.

※ 참고 글: What happen to yahoo?

개발팀과 운영팀 오류를 줄일 땐 프로세스화가 좋습니다.

옆에서 누가 체크해 주는 게 훨씬 더 가볍고 빠르니까요. 프로세스는 “불신”을 바탕으로 설계합니다. 이전에 체크하지 않은 것은 다 오류일 수 있다고 보는 거죠. 대신 느립니다. 점검하지 않은 건 모른다고 가정하니까요.

“운영팀”은 이렇게 프로세스 기반으로 구성합니다. 안정성, 항상성, 지속성이 중요하거든요. 그런데 이렇게 하다 보면 자꾸 중복이 생깁니다. 낭비죠. 관리자가 개입해서 자꾸 없애줘야 합니다. 낭비 제거, 다른 말로 효율화라고 하죠. 운영할 땐 이런 걸 중요하게 봅니다.

그러나, 새로운 걸 개발하려면 자유로운 게 좋습니다. 잘 모르면 일단 만들어봐야죠. 프로젝트팀 내에서 상의하고 결정하게 합니다. “스케치해 보고 개발”, 이 과정을 반복하는 거죠. 관리 문서가 아니라 결과물과 개발 코드를 보면서 진도를 뺍니다.

이렇게 일하는 방식을 오래된 관습, “문화”라고 하죠. 참고로 문화는 효율을 위해 움직이지 않습니다. “효과”라는 결과를 향해 움직이죠. “개발팀”은 이렇게 구성합니다. 목표, 결과, 성과, 이런 것들이 중요하니까요.

한편 “은행권 차세대 프로젝트” 같은 대형 프로젝트는 좀 다릅니다. 핵심은 창의적 연구 개발이라기보다, 알려진 기술로 비즈니스 시스템을 조립하는 겁니다. 시스템이 크고, 복잡성을 통제해야 하니, 설계도, 조립도 같은 게 중요합니다. 그래서 관리팀을 섬세하게 구성하죠.

즉, IT 운영팀, 개발팀, SI 프로젝트의 개발팀은 같아 보이지만 모두 다른 조직입니다. 조직 목적이 다르기 때문에 조직도 달라지는 거죠.

개발 문화 “개발 문화”라고 하니까 기획자, 디자이너가 이런 말들을 많이 합니다.

“개발자 편의만 너무 봐주는 거 아니냐?”

“개발 문화”를 “개발자 문화”로 오해하는 겁니다.

“개발 문화”가 화제가 된 건 2004년의 구글 때문입니다. “20% 프로젝트” * 로 지메일과 구글 나우가 나왔거든요. 이 문화가 Google Developer Day, Google I/O 등으로 이어집니다. 이때까지만 해도 “개발 문화”는 개발자들만의 그 무엇이었죠.

*20% 프로젝트: 모든 직원이 자신이 원하는 창의적인 프로젝트에 업무 시간의 20%를 사용하도록 한 구글의 문화

일반인에게 널리 알려지게 된 건 2012년 페이스북 때문이었습니다. IPO를 하면서 투자자 공개서한에 “해커 문화”를 강력하게 내세웠거든요. 주식 투자자들에게 그걸 믿고 우리 회사에 투자하라 한 겁니다. 사람들은 궁금해지기 시작합니다. “도대체 그게 뭔데?”

구글과 페이스북으로 대표되는 이런 일 문화가 “개발 문화”라고 불리게 된 건, 회사 제품이 “인터넷 서비스”였기 때문입니다. 제품의 제작, 생산, 심지어 판매까지 모두 소프트웨어로 만드니까요. 즉, 개발 문화가 없으면 기업이 존립할 수 없는 겁니다. 제조업이었다면, R&D 문화, 생산 프로세스 등이 해당하겠죠.

즉, IT 회사에서 “개발”이란 제품을 만드는 전체 과정을 일컫는 말입니다. 코딩 스타일만 말하지는 않죠. 굳이 일반화시켜 보자면 “기업문화” 정도가 될 겁니다.

어쨌든 이때가 되어서야 사람들은, “인터넷 서비스나 패키지 소프트웨어를 잘 만들려면, 프로세스뿐 아니라 개발 문화가 있어야 하는 구나”라는 걸 알게 됩니다.

개발 문화 만들기 그런데 개발 문화는 어떻게 만들까요?

자연스러운 게 제일 좋겠지만, 누구나 사업 현장을 그렇게 만들 수는 없습니다. 마냥 기다릴 수도 없으니까요.

“문화”를 만드는 인위적인 수단은 “제도”와 “분위기”입니다. 회사니까 이 정도로도 충분합니다.

“구글의 20% 프로젝트”, 이건 “제도”입니다. 그런데 처음 해보면 100% 헤매게 되죠. 보고 따라 하는 게 가장 빠릅니다. “따라 해 봤더니 목표한 결과에 쉽게 이르게 되더라.” 이런 성공 경험이 “습관”을 만들어 냅니다. 이게 오래되고 여러 사람이 함께하면 “관습”이 되죠. 그다음에야 문화가 됩니다.

즉, 문화는 제도 → 분위기 → 습관 → 관습을 거쳐 만들어집니다. 시간이 꽤 걸릴 것 같지만, 생각보다 빠르게 바뀝니다. 보고 따라 하는 게 “행동”, “생각”을 변화시키는 가장 빠른 방법이니까요.

다만, 코드의 양, 일의 범위, 기존 프로세스와 충돌 등이 변화의 속도를 느리게 만듭니다.

대기업은 개발 문화 만들기가 생각보다 어렵습니다. 이미 형성된 다른 문화가 있으니까요. 점진적이면서 느린 변화를 선택할 수밖에 없죠. 스타트업은 자유롭습니다. “새 문화의 축적”에만 신경 쓰면 되니까요.

그래서 큰 기업들은 CIC(Company In Company) 형태로 작은 스타트업을 만들거나 작은 스타트업을 인수하기도 합니다. 개발 문화를 바꾸기 위한 불씨로 쓰죠.

사람이 중요해요 일을 하다 보면 반드시 사고가 일어납니다.

분업화, 프로세스화는 사람의 책임을 덜어줍니다. 매뉴얼, 표준화를 통해 문제를 해결하니까요.

시킨 대로 한 사람은 잘못이 없습니다. 단계가 길고 복잡한 업무를 반복해야 할 경우 좋은 선택이죠.

어떤 일이 벌어질까요?

기업은 평이한 개발자를 뽑습니다. 설계는 비싸게 합니다. 복잡한 문제는 구조를 통해 해결하고, 업무 완성도는 반복 숙달을 통해 높입니다.

단점으로는 프로세스가 계속 늘어납니다. 사람도 계속 늘어납니다. 프로세스가 길어지면 시장 변화에 쉽게 대응하기 힘듭니다.

반면 개발 문화로 일할 땐 만든 사람이 책임을 지게 합니다. 개인 역량을 통해 문제 해결을 합니다. 일이 구분되지 않고 복잡하게 섞여 있는 경우 할만한 선택이죠. 대신 한 사람이 짊어져야 할 책임이 큽니다. 스트레스 수치가 높은 환경이죠.

고수 개발자를 뽑아야 합니다. 이것저것 다 해본 사람이니 일하기 편리하고, 결과 빨리 나오고, 소통도 잘 됩니다. 교육 훈련도 필요 없죠. 다만 연봉이 비쌉니다.

단점은 대량으로 반복하기 힘든 겁니다. 오래 지속하기도 어렵죠. 사람 구하기 매우 어렵습니다.

두 가지 사례는 극단적인 비교입니다. 대부분의 회사는 중간 어디쯤 있죠.

결국 둘 다 사람이 중요합니다. 요즘엔 사람 구하기 너무 힘들거든요.

2000년대 초엔 개발자 뽑기가 쉬웠습니다. 베이비붐 세대가 IT 현장에 들어와 있었거든요. 요즘은 아닙니다. 개발자 구하기 정말 어렵습니다. 훈련된 개발자는 더더욱 어렵죠.

기업 교육의 중요성이 점점 높아지고 있습니다. 새로 구하기보다 기존 직원을 훈련해서 쓰고 싶은 거죠.

좋은 채용 전략 어떤 사람을 뽑아야 할까요? 어떻게 뽑고, 어떻게 관리해야 할까요?

어렵습니다. 모든 IT 회사의 숙제죠.

인사가 만사라고 개발팀 채용, 관리도 사실 전통적인 HR의 연장선상에 있습니다. 다만 IT라는 산업 특성이 더 강할 뿐입니다.

상황은 조직마다 회사마다 다릅니다. 그래서 콕 찝어서 이야기할 만한 정답은 없죠.

다만 IT 분야에 새로 진입하는 채용 담당자들이 꼭 알고 있어야 할 내용이 있습니다. Rober Half Technology라는 큰 회사의 분석 리포트입니다. 2020년 미국 상황을 정리한 내용인데, 국내 사정도 비슷합니다. 핵심만 요약해 봅니다.

우리 고객의 67%가 IT 팀을 확장할 계획을 갖고 있다. 그러나, 90%의 회사가 적임자를 못 찾고 있다. 개발자의 86%는 현재 취업 상태로 이직 의사가 별로 없다. 개발자 채용에는 최소 며칠 ~ 최대 4개월이 걸린다. 채용 담당자의 75%는 입사 제안을 거절당해 본 적이 있다. 거절한 개발자의 53%는 다른 곳에서 더 좋은 제안을 받았다고 한다.

한국도 흐름은 비슷합니다. 기존 산업과 IT 기술의 융합도가 높아지며, 인하우스 개발팀의 필요성도 따라 높아지는데, 개발자를 구할 수는 없으니까요.

좋은 개발자는 어떻게 구할까요?

검색해 보면 여러 가지 팁들이 많지만, 그중에서 중요하다고 생각하는 세 가지만 추려 보겠습니다.

첫째, 좋은 개발자는 찾아다녀야 합니다.

어떤 분야든 마찬가지겠지만, 우리 회사에 맞는 개발자를 우연히 만날 가능성은 거의 없습니다. 그 사람을 채용하게 될 확률도 거의 없고요.

비슷한 사람을 꾸준히 수소문해서 찾아다녀야 하고, 만나더라도 오랜 시간 이야기를 나눠야 비로소 공감할 수 있습니다. 뜻이 맞아야 시너지가 나는 거죠.

둘째, 채용 공고는 긴 호흡으로 냅니다.

기업은 채용 공고를 한 달 정도 기한으로 냅니다. 급하니까요. 그런데 한 달이라는 시간은, 우리가 찾는 사람이 있을 확률 x 그가 우리 채용 공고를 볼 확률 x 입사를 결심할 확률 x 원서를 잘 낼 확률이 꼭 맞아떨어져야 적당한 시간입니다. 너무도 낮은 확률이죠.

게다가 대부분은 우리 회사가 통제할 수 없는 항목들입니다. 오직 하나, 우리 채용 공고를 볼 확률을 높일 수 있죠. 그래서 채용 공고는 최소 2~3달이어야 합니다. 길수록 좋죠.

신입사원 채용은 대부분 신규 채용입니다. 졸업 시기에 맞춰 공고를 내면 지원서를 많이 받을 수 있죠.

반면 경력사원 채용은 대부분 이직입니다. 현재 업무가 바빠서 못 볼 수도 있죠. 그래서 경력 채용 공고일수록 여러 곳에 길게 냅니다. 또는 찾고 있는 개발자가 많이 오는 곳을 선택합니다. 돈이 좀 들어가죠.

셋째, 우리가 하는 일을 잘 알려야 합니다.

아무렇게나 공고를 낸다? 아무런 공고여도 괜찮은 사람이 옵니다. 정성 들여 공고를 낸다? 가물에 콩 나듯이 괜찮은 사람이 옵니다만, 그래도 정성 들여 공고를 내야 합니다. 우리가 무슨 일을 하는지 알아야 그에 맞는 사람이 찾아오니까요.

이를 도울 방법도 있습니다. 개발자 세계는 넓습니다. 별거 아닌 것처럼 보여도 우리 일을 좋아하는 사람이 있습니다. 기술 블로그나 SNS 등 우리가 하고 있는 일을 널리 알립니다. 돈이 되진 않습니다. 그래도 많이 알릴수록 핏이 맞는 사람을 만나게 될 확률이 큽니다.

즉, 좋은 채용 전략은 좋은 인력풀과 오랫동안 스킨십을 맺는 겁니다.

좋은 인재는 절대 한 번에 들어오지 않습니다. 한 명씩 한 명씩 채워 좋은 개발팀이 되는 겁니다.

다음에는 해외 기업들은 어떻게 아웃소싱을 하고 있는지 알아보겠습니다.