brunch

You can make anything
by writing

C.S.Lewis

by 맨오브피스 May 16. 2021

아웃소싱 개발이 필요한 상황은?

아웃소싱(outsourcing)은 내부 자원을 핵심 역량에 집중하기 위한 사업 전략으로 80~90년대부터 널리 퍼지기 시작했다. 처음에는 제품의 생산을 외부에 맡기는 것으로 시작해 현재는 회계, 마케팅, 프로젝트 관리까지 영역이 무한히 확장되고 있다.

IT분야에서도 마찬가지다. 회사의 IT 인프라를 아웃소싱하는 것에서 뻗어나가 개발이나 서비스 운영도 외부 업체나 개인에게 맡길 수 있는 환경이 마련되었다. ‘소프트웨어는 한 번 만들어 팔고 끝!’이라는 개념이 사라진 시대에 아웃소싱하기 좋은 프로젝트란 과연 어떤 것들인지 살펴보자(뉘앙스 차이가 있지만, 외주를 맡기는 것과 거의 비슷하다고 봐도 무방하다).

1. 핵심 제품이 아닌 일

현재 몸 담고 있는 회사에서도 개발 아웃소싱을 맡기고 있는 부분이 있어 이를 예시로 들어보겠다. 우리 회사는 앱 내에서 광고를 노출해 수익을 얻을 수 있는 SDK와 API를 솔루션으로 제공한다. 그리고 솔루션 설정이나 수익 보고서를 확인할 수 있는 UI도 제공한다.

여기서 핵심 제품인 SDK와 API는 아웃소싱으로 돌리지 않는다. 회사 전략에 맞춰 광고 알고리즘을 수시로 조정해야 하고 데이터가 늘어남에 따라 사용하는 기술도 바꿔 줘야 하기 때문이다. 외부에 맡겨버리면 그 복잡성을 다 소화해내기 힘들뿐더러 세부 내용을 일일이 컨펌해야 해 속도가 느려질 수 있다. 또한 고객들의 정보를 보호함에 있어 외부 업체가 개입되면 법적인 동의도 중복으로 받아야 해서 귀찮아진다.

반대로 UI는 중요도가 상대적으로 낮다. 알고리즘 최적화로 수익을 높여주는 것이 핵심이라 UI는 수익 확인용 그 이상 그 이하도 아니다. 수익률이 높으면 UI가 못생긴 들 어떠하리. 따라서 핵심 제품을 보조해주는 UI 부분만 아웃소싱하고 있다.

2. 어떻게 만들어야 할지 모를 때

1번과 상반된 내용이긴 하지만, 핵심 제품을 아웃소싱해야 할 때가 있다. 어떤 제품은 타이밍이 생명이다. 이때 내가 어떤 개발자를 뽑아야 할지, 실력 테스트는 어떻게 해야 할지 모른다면 매우 난감하다.

대략 7~8년 전, 인플루언서 마케팅 시장이 한창 성장하던 때였다. 당시 일하던 회사에서 “인플루언서 마케팅 플랫폼을 만들자!”는 이야기가 나왔다. 과연 성공할 수 있을 것인가 반신반의하는 마음으로 기획에 들어갔다. 내부 개발자들은 모두 다른 프로젝트에 몰두하느라 바빴기 때문에 최소 기능 제품(MVP)을 아웃소싱할 수밖에 없었다. 핵심 제품의 개발을 외부에 맡기다니 리스크가 컸지만 시장에 빨리 진입하려면 어쩔 수 없는 상황이었다.

결론부터 이야기하자면 우리가 만들었던 플랫폼을 성공하지 못했다. 그럭저럭 기능하는 제품이 나오기는 했는데, 내부적으로 운영 노하우가 너무 빈약했다. 물론 돈을 날린 셈이었지만, 제품을 실제로 만들어 테스트해봤다는 점에서는 긍정적이었다고 생각한다.

상황에 따라서는 핵심 제품의 개발을 아웃소싱하는 것도 나쁘지 않다. 다만 장기적으로는 내부에서 만들어나갈 수 있게끔 개발자를 구해(단 한 명이라도!) 기술적 내용과 노하우를 최대한 가져오는 것이 중요하다.

3. 개발 내용이 명확한 일

무엇을 어떻게 만들어야 하는지는 명확한데 코드를 작성할 사람이 없을 때가 있다. 한마디로 ‘일손이 부족할 때’. 예를 들어 사용자들의 이용 데이터가 차곡차곡 쌓여가는데, 이를 시각화해줄 비즈니스 인텔리전스(BI) 시스템을 구축할 시간이 없을 때. 이럴 때 아웃소싱 개발이 큰 도움이 된다.

명확하면 명확할수록 커뮤니케이션 비용을 낮출 수 있다. 개발 아웃소싱을 할 때 단순 인건비나 개발 시간으로 비용을 계산할 때가 많은데, 커뮤니케이션 비용이 은근 많이 든다. 외부 개발자에겐 우리 회사 고객들이나 장기 전략, 내부 비용에 대한 맥락 정보가 없다. 맥락이 잘려나간 상태에서 무언가를 만들려면 정보 교환과 확인을 수십수백 번 거쳐야 하니, 되도록 맥락 정보가 별로 없어도 되는 프로젝트를 맡기는 것이 좋다. ‘고객의 관심사를 분석해주는 시스템’은 어떻게 만들어야할지 모호하지만, ‘근태관리 시스템’은 비교적 명확하다.

다만 아무리 개발하기 명확한 제품이라도 개발의 상세 내용은 꼭 문서로 남겨놓자(또는 남겨달라고 하자). 나중에 다른 개발자들이 이어받았을 때 코드 구조나 로직이 명확하지 않으면 또 다른 비용으로 이어진다.

4. 직원들이 하기 싫어하는 일

개발 난이도가 너무 높으면 머리가 지끈거리지만, 반대로 너무 쉬우면 하품이 나온다. 위에서 UI 업무를 외부에 맡겼다는 이야기를 했는데, 내부 개발자들이 UI 업무를 재미없어했다는 점이 가장 큰 이유였다.

만약 기능이 다양한 UI 제품이었다면 몰라도, 단순히 수익 금액을 확인하기 위한 UI라면 데이터 항목을 늘리는 것이 전부다. 정확한 금액이 표시되고 페이지가 다운되지만 않으면 나머지는 부가적인 기능이다. 개발자 입장에서는 재미없을 수밖에 없다. 재미로라도 새로운 기술을 이것저것 실험해볼 수 있다면 그나마 괜찮은데 안정성이 중요한 제품에는 그러기도 쉽지 않다. 결국 재미없다면 아무리 급여가 좋더라도 개발자가 회사를 떠나는 사태가 발생할 수 있다.

‘누군가는 해야 하지만 재미없는 개발’은 아웃소싱으로 돌리고, 내부적으로는 새롭고 흥미로운 프로젝트에 집중할 수 있도록 하는 것이 좋다.