brunch

라이킷 8 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 시선 Jan 15. 2021

#11. 자체 개발이 좋은 이유

여러 상황에 능동적인 대처가 가능해진다.

기획자마다, PM마다 성향이나 성격, 업무 스타일 등이 다르기 때문에 무엇이 옳고 그르다를 논하기는 어렵다. 하지만 분명하게 말할 수 있는 건 대부분의 개발인력들은 "자체 개발"을 더 선호하고 있다는 것이다.

실제 많은 CEO분들을 뵙고 이야기를 하다 보면 자체 개발에 대해 부정적인 분들이 꽤 많다는 사실에 놀라곤 하는데 어느 정도는 이해도 되지만 대부분 이해가 어렵다는 것이 내 생각이다.

자체 개발 vs 외주 개발.

아주 간단한 프로젝트, 일거리라면 외주가 더 나을 수도 있다. 개발 인력을 충원해 점심값, 각종 장비 비용을 생각하면 자체개발보단 비용이 더 들지만 개발하고 끝낼 수 있는 외주 개발이 더 매력적으로 느껴지기도 하다.

실제로 홈페이지나 간단한 앱, 페이지 등이 그것일 것이다.

또한 많은 회사들이 그런 부수적인 부분은 외주에 맡기고 주력 사업에 매진하는 경우가 대부분인 경우도 바로 그러한 이유에서이다. 개발인력을 분산하는데 따른 위험부담보다는 외주로 부수적인 걸 처리하는 편이 시간적으로, 비용적으로 더 좋기 때문일 것이다.

이것은 부수적인 부분에 해당되는 이야기이고 중요한 것은 메인. 바로 주력 프로젝트에 대한 것이다.

#10 글에서도 설명했듯 주력 프로젝트를 추진하는 과정에서 "기획은 우리가 하고 디자인, 개발은 외주로 맡기면 되지."라고 생각하는 분들이 많다는 건 다들 아실 것이다. 하지만 이 과정에서 오는, 따라생기는 파생적인 문제에 대해서는 간과를 하는 게 현실인 것도 설명했다.

쉽게 말하면 외주를 맡길 것이라면 아예 통째로 맡기는 게 가장 좋다. 그리고 분기, 일정 이슈마다 체크를 하는 게 가장 현명하고 자체적인 위험 부담을 줄이는 길이다. 물론 개발이 외주이기 때문에 불안한 요소는 존재하지만 잘못 된 책임을 확실히 한다는 점에서는 외주에 다 맡기는 것이 낫다.

그것이 아니고 기획을 할 것이라면 아예 개발도 자체적으로 하는 게 낫다.

왜? 그래야 능동적이고 위기의 순간에도 발빠른 대책이 나올 수 있기 때문이다. 또한 시간적인 면에서도 이익이 많다. 기획자들도 더 능률적인 시간 배분을 할 수 있다.

협업의 진짜 의미

이해하기 쉽게 말을 해주겠다. 물론 외주라고 해서 100% 그러는 건 아니지만 말이다.

시간이 부족한 상황에서 개발을 추진해야 하다 보면 기획서를 작성 할 시간이 상대적으로 부족한 경우가 발생한다. 이때 외주사에 "다른 건 기본적으로 알아서 해주세요."라고 해도 될 수 있긴 하다.

통상적이고 통념적인 기존 방식을 적용해달라는 말로도 가능한 범주는 존재하기 때문이다. 문제는 그 상황에서 조금의 추가적 개념이 들어가는 경우에는 꼼짝없이 "기획서를 제출"해야 한다.

기획서는 작업을 위한 메뉴얼이기도 하지만 이 경우에는 "책임을 논하기 위한 증거 자료"로 활용된다.

또한 조금(?)의 융통성도 없는 외주사라면 아주 기본적인 내용들도 기획서로 작성해서 줘야 하는 일들이 발생한다. ( 물론 기획서를 주는게 당연한 일이지만 )

기획서를 한 장 작성하는 것도 써 본 사람은 잘 알겠지만 시간이 필요하다. 아무리 간단한 내용이라도 말이 되게, 개발이 되게 작성하려면 시간이 들 수 밖에 없다. 하루 종일 기획서를 작성해도 많은 양을 단번에 작성할 수는 없다. 진짜 개발에 대해 1도 모르는 분들은 2~3일이면 다 나오는 줄 아는 경우가 많다.

물론 이것이 가능한 회사도 있다. 하나의 프로젝트만 지속적으로 개발하는 회사는 짧은 시간에도 기획서가 나오긴 하다. 그것은 오랜기간 노하우와 협업, 그리고 관련 소스들이 많을 때 가능한 이야기이다.

대부분의 개발사는 처음부터 만들기 때문에 사소한 부분까지도 모두 기록, 작성되어야 한다.

자체 개발하는 경우라면 이런 간단하거나 말로 끝낼 부분에 대해서는 기획서가 필요없다.

담당 개발자와 협의만 끝내고 간단한 내용의 타이핑이나 그림만 그려줘도 개발이 가능해진다. 이렇게 줄인 시간은 보다 많은 시간과 구상이 필요한 기능이나 기획에 활용할 수 있게 된다.

협업은 서로 이야기를 하고 만드는 것만이 협업이 아니라, 이런 경우를 '협업'이라 부르는 것이다.

국내에서는 협업을 소통을 통한 업무 추진으로 생각하는데 그것은 그냥 업무일 뿐이다. "기획서줘야 일을 하죠."와 다를 게 없다. 안주면 일을 안하겠다는 의미이고 내가 놀고 있는 이유에 대한 근거일 뿐인 셈이다.

그걸 협업이라 부르지 않는다.

같이 밤새고 고민하고 해결하다 보면 생기는 동료애, 개발사에서 가장 필요한 덕목

외주사의 직원이라 해서 동료애가 생기지 않는 건 아니지만 상대적으로 다른 회사 소속이다 보면 결국 소속에서 오는 거리감은 분명 있다. 이런 경우가 종종 있기는 한데 만약 이 글을 읽는 분께서 개발사에 입사를 했는데 개발자들이나 다른 동료들이 까칠하게 대하는 경우를 종종 느낀 적이 있을 것이다.

일종의 텃새일수도 있고 개인적 성격일 수도 있지만 대개는 "동료애를 갖기 전의 행위"가 대부분이다.

IT업종은 직원의 이탈이 잦은 편이다. 정이 들만하면 이직하거나 말없이 관두는 경우도 많다.

그러다 보니 직원들간 유대감이 적은 경우도 있고 회사에서는 친하게 지내지만 의외로 사적으로는 연락 한번 안하는 경우도 많다.

하나의 프로젝트를 끝내고 보면 평소 까칠하던 동료들이 어느 순간 친근하게 다가오는 경우가 많다.

바로 동료로 인정하는 것인데 같이 밤새고 고민하고 일을 추진하면서 상대의 성격, 업무 스타일 등을 파악하고 이해하게 되는 것이다. 군대에서도 동기나 전우조로 함께 지낸 전우들이 더 기억에 남고 생각나는 것도 바로 이런 맥락일 것이다.

외주를 맡겼다가 외주의 장난질 덕분에 1개월 보름 정도를 개발자들과 함께 야근을 하며 일을 마친 적이 있었다. 원래도 좀 친했지만 함께 테스트를 하고 수정해가면서 24시간을 붙어지내다 보니 서로 이해하는 계기와 상대 파트의 어려움을 알게되는 시간이기도 했다. 작은 부분 하나까지도 원칙을 내세우던 사이에서 "아...그건 너 바쁘니까 내가 그냥 처리할께. 걱정마." 또는 "아...그러면 생각 정리해서 문서로 줄께."같은 대화들이 오고간다. 주말을 할애해서라도 동료가 조금 더 편하게 일처리를 할 수 있게 배려하기 시작하는 것이다.

대개 이런 과정을 거친 회사들이 쉽게 무너지지 않기도 하지만 이직율도 적다.

이미 호흡이 맞기 때문에 다른 회사에서 또 같은 고생을 하고 싶지 않게 되는 것이다. 이는 회사로써도 굉장한 이득이며 개발사라면 당연히 갖춰져야 할 분위기라고 할 수 있다.

keyword