외주 잘 맡기는 방법 1부: 외주 계약 전에 꼭 보세요!

아웃소싱을 위해 관련 채용 플랫폼에 공고를 내더라도, 마치 시장에서 물건 고르듯이 쉽게 고를 수는 없습니다. 더욱이 IT 관련 프로젝트 경험이나 상식이 없는데, 서비스 앱이나 웹사이트를 만들어야 할 상황이라면 외주 업체 선정이 더 어려울 수밖에 없습니다. 이에 리스크 최소화를 위해, 아웃소싱 플랫폼은 효율적인 시스템과 가이드라인 제시가 필요하며, 아웃소싱 관련 지침이 필요하신 분들은 외주를 맡기기 전에 반드시 책을 읽거나 인터넷에서 아웃소싱 관련 콘텐츠를 검색해보신 후, 외주 업체 계약 진행을 추천합니다. 

무엇이 중헌디?

아웃소싱 전 체크리스트

1. 외주의 목적을 정의한다

무엇을 얻으려 하는가? 일을 맡기는 "목적"을 분명하게 하실 필요가 있습니다. 물론 사람 욕심에 따라, 또는 상황에 따라 요건 사항이 늘어날 수도 있습니다. 그러나 외주의 목적이 무엇인지를 명확하게 하고 상대에게 미리 밝히는 것을 추천합니다. 우유부단하여 중간에 계속 큰 줄기를 바꾸는 분도 있습니다. 일의 큰 줄기가 계속 바뀌는 것은 그 일의 성격을 잘 몰라서일 가능성이 큽니다. 아니면 관련 이해관계자가 많을 수도 있겠습니다. 하지만 어떤 능력자라고 하더라도 일의 큰 방향성을 자주 바꾼다면 퍼포먼스가 떨어지는 것은 당연한 일입니다.  

킥오프 시, 해당 프로젝트의 비즈니스 가치와 성격에 대한 설명뿐만 아니라 외주를 맡기는 목적성도 함께 제시해주십시오. 예를 들어, 인하우스 인력이 있지만, 단기간 내에 이 일이 깔끔히 마무리 짓는 것을 보고 싶어서 맡긴다. 혹은 내부 인력이 아닌 다른 제3자의 입장에서 많은 아이디어를 얻고 싶어 공고를 냈다 등 일반적인 외주 업체라면 언급한 부분에 대해 더 많은 고민을 하고 이를 산출물에 반영하려 할 것입니다. 

2. 누구에게 일을 맡기는가?

가능한 적합한 경력의 소유자들에게 일을 맡겨야 합니다. 해당 서비스 경력이 있는지? 해당 서비스를 사용한 적 있는지 등이 선택의 기준이 됩니다. 당연한 말이지만, 적합한 업체와 사람에게 일을 맡기는 것이 중요합니다. 그러나, 때때로 지인의 소개를 통해 알게 된 사람을 신뢰하여 기회를 주는 경우도 있습니다. 이런 경우, 턴키(turnkey)로 일을 맡기는 것은 리스크가 있습니다. 믿고 맡긴다는 개념은 경력과 경험이 많아, 업계에서 어느 정도 신용이 있는 업체에게만 해당되는 말이기 때문입니다. 

3. 실무적으로 확인이 필요한 부분

외주 기간 동안의 커뮤니케이션 툴과 기술적인 요소를 상의하고, 서비스의 특성을 정의합니다. 킥 오프 전에 미리 상의할 수도 있고, 다소 이른 감은 있으나 최초 면접 시에 논의를 해도 무방합니다.  

4. IT 업무는 개인 업무가 아닌 함께 하는 팀플이다

IT 프로젝트는 한 사람의 영웅이나 스타는 거의 없습니다. 현장에서는 평범한 사람들이 대다수라 개개인의 역량도 중요하지만 전체 팀워크도 생각할 부분입니다. 서로 대화를 1~2회 나누었다고 커뮤니케이션이 완료되었다고 생각하면 안 됩니다. 최종 산출물이 나올 때까지 상대가 이해했는지는 알 수 없습니다. 이는 의심과 다른, 우리의 원초적 뇌와 인지 심리학적인 측면에서 말하는 것입니다. 글을 읽어도 읽고 싶은 것만 인지하여 받아들이고, 상대의 말을 들어도 듣고 싶어 하는 내용만 듣는 우리의 "확증 편향"을 필드에서 종종 경험했습니다. 따라서 턴키 형태로 외주를 맡기더라도 100%가 아닌 중간중간 꼼꼼히 확인하면서 관리하는 단계가 필요합니다. 

또한 일이 순조롭게 진행되지 않을 때, 사람을 교체하는 일을 종종 목격합니다. 서로의 의견과 방향성이 달라 갈등이 발생하고, 이를 모면하기 위해 사람을 교체하는 것으로 이어지는 것입니다. 그러나 마지막으로 종결을 앞둔 프로젝트의 경우 흐름과 대세를 거스르기는 매우 힘든 일입니다. 왜 그럴까요? 프리랜서와 아웃소싱이 타 업계보다 많더라도 사실상 IT 프로젝트는 팀플의 성격을 나타내며, 얼마 기간이 안 남은 프로젝트라면 일련의 호흡을 맞추어 눈에 보이지 않는 룰이 생기기 때문입니다.

*일반적으로 아웃소싱 플랫폼을 통해 “특정 업체를”선택하는 원칙

1. 정성스럽게 글을 작성하여 외주 의사를 밝혔는지? 그 회사의 서비스 혹은 프로덕트 맞춤형으로 작성한 글에서 업체의 열정과 성의가 느껴져 만나보고 싶게 만듭니다.    

2. 개인보다 법인 사업자가 신뢰가 간다고 합니다. 이는 조직의 파워일까요? 

3. 허술하지 않은 웹 페이지 링크를 주시면 좋습니다. 참고로 회사 홈페이지의 디자인과 기술이 현란하지 않아도 됩니다. 단, 미니멀리즘 성격의 디자인이어도 최소한의 성의는 느껴지도록 콘텐츠를 기획하여 완성도는 느껴져야 합니다. 

4. 우리 서비스와 관련된 경험이 있는지? 이 일을 잘 풀어나갈 역량을 가지고 있는지가 중요합니다. 어떤 채용 공고에서도 흔히 볼 수 있습니다. 우대사항. 관련 경험 유! 해당 서비스의 경쟁사나 관련 포트폴리오가 있는 업체나 개인에게 기회가 돌아갈 가능성은 매우 높습니다. 

어떤 사람이 맞나? 사람을 보는 안목 기르기

디자이너 유형을 대표적 페르소나에 따라 아래와 같이 나눠봤습니다.

1. 디자이너 유형 A. 

프로덕트 퀄리티를 매우 중요하게 여기는 디자이너들이 있습니다. 산출물의 퀄리티를 중요하게 여기기 때문에 그래픽 스킬은 상대적으로 높으나, 납기일이 다소 안 맞춰지는 경향이 발생할 수 있습니다. 프라이드가 강한 만큼 스타일과 생각이 강할 수 있어 마찰이 발생할 우려가 있습니다. 

2. 디자이너 유형 B. 

납기일을 준수하고 상업적인 레벨의 70~80% 완수하는 디자이너가 있습니다. 단, 자유자재로 그래픽을 표현하는 것은 어려울 수 있습니다. 평범하나 기본적인 일 처리가 가능한 사람이라고 명명하겠습니다. 

3. 디자이너 유형 C.

주니어급 디자이너가 아니라 팀장급 디자이너 정도의 경력이 있으면 서비스 기획자 경력이 없어도 사용자 경험적인 부분이나 정책을 잡는 능력도 함께 기대하는 경우가 있습니다. 이런 심리를 잘 알고 있어, 당사자도 이를 PR에 적극 활용합니다. 더불어 개발 커뮤니케이션이나 퍼블리싱 개념도 탑재하고 있음과 동시에 화면 그래픽 디자인뿐만 아니라 프로젝트 앞단의 비즈니스 개념도 잘 파악하여 디자인에 반영합니다. 

디자인 역량은 이렇게 나뉩니다.

1. 아마추어 레벨

학생이나 초보 레벨로 비 전문가가 언뜻 봐도 어설픈 부분이 느껴집니다. 

2. 상업적 초기 레벨

그래픽 기교는 없으나 상업적으로 내놓은 타 서비스 앱과 견주어 크게 떨어지지 않으며, UI가 평범하나 기본 UI의 구조나 그룹핑이 어색하지 않습니다. 

3. 고급 레벨

클라이언트가 어느 형태의 그래픽 스타일을 주문해도 어설픔 없이 만들어내며, UI의 구조감이 잘 맞습니다. 또한 서비스 기획자나 UX기획자가 제시할 만한 정책이나 개발 구조도 함께 알고 있어, 이에 대한 의견을 논리적으로 제시할 수 있습니다.

디자이너를 선택할 때는 포트폴리오를 반드시 요구하시고, 대면 및 구두 확인도 함께 해야 합니다.

단순하게 정리해보면, 평균 이상의 그래픽 표현 능력으로 산출물을 만들 수 있는 디자이너인데 전체 프로젝트의 비즈니스적 관점과 서비스 정책, 사용자 경험에 대한 이해가 있는 사람이면 레벨이 높은 분이라고 보시면 좋습니다. 그러나 그런 분들이 흔하지 않다는 것이 업계의 총평이며, 이는 곧 단순 디자인 스킬이 아니라 기획적 사고를 탑재한 디자이너가 환영을 받는다는 것을 보여줍니다.

기획자의 유형과 역량을 아래와 같이 나눠봤습니다.

1. 숙련공 타입

개발 구현의 검토를 바랄 경우 적합한 유형입니다. 프로젝트 경험이 많고, 한 가지 필드의 경험을 쌓은 경우가 많습니다. SI 구축/기획 역량을 가지고 있습니다. 

2. 컨설턴트 타입

선행 프로젝트나 비즈니스 기획을 중점으로 경험했으나 구축, 개발의 지식이나 경험은 부족할 수 있습니다. 트렌드나 산업 동향을 꿰뚫고 있어 클라이언트보다 한 발 앞선 무언가를 제시할 수 있는 분들이 컨설턴트 타입이라고 볼 수 있습니다. 외주를 받기 위한 면접을 볼 때, 서비스에 대한 질문을 많이 하는 경우가 있는데요. 이는 서비스에 대한 관심도로 해석할 수도 있겠지만, 사실 클라이언트 입장에서는 해답이나 아이디어를 좀 더 듣고 싶을 수도 있습니다. 어느 정도 리딩을 원하는 경우도 있기 때문입니다. 물론 인하우스 내부에서 이미 방향성이 잡혔거나, 사람에 따라 일의 답이 정해져 있는 경우도 있겠죠. 이렇듯 컨설팅과 새로운 아이디어 제시에 대한 갈증은 외주 업체의 아웃소싱으로 이어집니다. 

3. 아이디어맨 타입

경력의 유무를 떠나 톡톡 튀는 아이디어를 내고, 일에 매우 적극적인 태도의 사람을 말합니다. 어디서나 긍정적인 태도가 중요합니다. 여러 아이디어와 문제 해결의 소재를 제시하는 사람은 어디서나 환영받을 가능성이 큽니다. 경험이 어떻고, 트렌드나 흐름을 잘 파악하는지, 서비스의 사용성과 사용자 경험에 대한 인사이트가 어느 정도인지 확인합니다. 이밖에도 아이디어를 많이 낼 수 있는지도 확인하고, 해결력과 관련된 컨설팅력을 중점적으로 봐야 합니다. 기획자 중에는 영업력이 강한 사람이 있을 수 있고, 개발자와 커뮤니케이션이 능수능란한 사람도 있을 수 있습니다. 어느 쪽을 선택할지는 프로젝트 성격에 더 맞는 타입으로 선택하면 됩니다. 기획자는 자신의 산출물도 중요하지만, 지식 노하우를 파는 직업이기도 합니다. 따라서 꼭 대면으로 대화를 나눠볼 필요가 있습니다.

일을 하다 보면 개발자와의 커뮤니케이션이 중요합니다.

커뮤니케이션을 원활하게 할 수 있는지 확인할 필요가 있습니다. 해당 개발 툴에 대한 이해가 있는지, 성심껏 일을 해낼지도 중요하지만 말입니다. 단순 개발 스킬 능력을 넘어, 커뮤니케이션이 원활한 개발자의 몸값이 더 높습니다. 그만큼 산출물에 대해 잘 설명할 수 있고, 상대가 개발 내용을 이해하기 쉽게 풀어내는 것도 큰 능력이라고 봅니다. 개발자 품귀 현상으로 최근에는 외국(인도, 중국) 개발자들에게 소싱을 주는 경우도 생겨납니다. 이들을 채용할 때 가장 신경 쓰이는 부분이 바로 커뮤니케이션입니다. 글이든 구두로든 소통을 안 할 수는 없습니다. 개발자와의 커뮤니케이션은 기획자나 PM, 혹은 타 업계 종사자와는 다를 수밖에 없습니다. 일을 하다 보면 개발자가 알아듣기 쉬운 대화, 즉 개발식 언어, 개발체가 있다고 생각합니다. 만약 그들이 알아듣기 쉬운 개발식 언어가 불가능하다면, 되도록 명확하고 정확하게 요구사항을 전달할 필요가 있습니다.

비 개발자인 경우, 다른 개발자의 이야기를 보조로 들으세요. 그다음 자문을 받고 정확하게 요구사항을 지시합니다. 단, 그 말에 너무 휘둘리지는 마시고요. 마지막으로 추후 전달받을 부분도 함께 꼼꼼히 체크하시길 바랍니다. 비 개발자의 경우, 인하우스 개발자 등 개발을 아는 지인을 곁에 두고 일하는 것을 추천합니다. 단, 아는 개발자 한 명의 업무 스타일과 견해만을 무조건 신뢰해선 안 되고, 시소의 균형을 맞추듯 한쪽으로 편향되지 않아야 합니다. 더불어 소싱 후, 관련 업무를 인수받을 땐 리스트업을 해두고 꼼꼼히 요구할 필요가 있습니다. 이를 반드시 계약사항에 포함해야 합니다. 더불어, 컨택 포인트는 PM이나 PL이 하는 것이 맞으나, 보통 개발자끼리 더 소통이 잘 되기 때문에 원활한 프로젝트를 위해 컨택 포인터라는 부분을 너무 고집할 필요는 없습니다.

또한 개발자 중에서는 기획을 스스로 해서 이미 만들어 놓은 경우도 있습니다. 그리고 최종 클라이언트가 아니면 다른 이의 의견을 잘 수긍하지 않거나, 심지어 상대가 클라이언트여도 기본 요구사항을 들어주지 않는 경우도 있습니다. 단순히 일을 줄이는 일이 개발자로서 혹은 개발 PL로서 역할을 잘 해내는 것이라고 생각하기 때문입니다. 만약 이런 개발자들을 만나면 우리는 어떻게 해야 할까요? 답은 간단합니다. 다음에 함께 일을 하지 않으면 됩니다. 우리는 다양한 성격의 스킬과 시스템을 다루기 때문에 프로젝트 성격에 따라 본인의 능력이 십분 발휘될 수도 아닐 수도 있습니다. 따라서 사람을 평가하는데 최소 3개의 프로젝트는 함께 해봐야 그 사람의 능력을 알 수 있다는 입장을 가지고 있습니다. 그러나 초반부터 태도가 불통인 경우에는 어떤 프로젝트를 하더라도 함께 만들어가는 산출물이 아닐 것이며, 어떤 기대도 할 수 없기 때문입니다.

마무리하며

일의 대다수는 "성공"보다 "실패"할 가능성이 더 높습니다. 이 일은 특별히 한 가지 요소로만 이루어지는 것이 아니라 어떤 부분에서 펑크가 발생할지는 아무도 모릅니다. 진행 중에 예기치 않은 변동도 많이 일어납니다. 따라서 "크게 하자가 없는" 정도의 산출물이 나온다면, 사실상 프로젝트가 성공한 것임을 한 번 더 알려드립니다. 인류는 절대 집단으로서 진화해온 것이고, 이런 원리가 잘 반영된 곳이 IT 현장이라고 생각합니다. 프로그램 활용 스킬과 프로젝트 경험 이런 것만이 아닌, 맥락적인 흐름에서 잘 판단하여 프로젝트와 서비스 성격에 맞는 외주 계약을 체결하시길 바랍니다. 이어지는 편에서는 외주 실패 경험 사례를 알아보고, 외주 업체와 프로젝트 진행 중에 관리해야 할 부분에 대해 면밀히 알아보겠습니다.