당신(나)의 외주개발이 망하는 이유

IT스타트업 창업자라면 반드시 알아야 하는 외주 개발의 기초

나는 이과계열도 아니고, 개발자 출신도 아닌 IT 분야 창업가이다.

그럼에도 IT 분야 창업을 희망했던 나는, 항상 개발이라는 영역이 내 앞길의 장애물이었다.

이를 해결하기 위해 10명이 넘는 팀원을 모두 IT 인력으로 채용하기도 했었고, 먹고살기 위해 우리가 외주를 받아서 개발해보기도 했었다. 그러다가 팀이 여러 번 바뀌면서, 결국 외주 개발을 맡겨보기도 했다. 이렇게 실패하는 과정에서 진행한 규모 있는 개발 프로젝트만 10개가 넘는다. 그리고 스스로 매우 웃긴 일이지만, 그 수많은 실패를 겪은 결과로써 나는 개발 비슷한 걸 배워 직접 외주 개발을 하며 생계를 이어나가고 있다.

그렇게 내게 외주개발을 맡기는 많은 분들을 보며 "아 너무도 나와 똑같은 실수를 계속하고 계시는구나"라는 생각이 들 때가 한두 번이 아니다. 사실 과장이 아니라 10명 중 9명의 고객사 대표님들이 해당된다. 볼 때마다 "이래서 내가 망한 건데!!!"라는 생각이 항상 들지만, 하나하나 다 내가 챙기고 다른 회사 대표자의 역할을 대신할 수는 없다. 그래서 나의 수많은 개발 실패와 그 이유, 그리고 지금 내 고객사 대표님들의 10명 중 9명이 하고 있는 똑같은 실수들에 대해서 적어보려 한다.

우선 나의 과거를 포함해 대부분 창업가들이 소프트웨어 개발이라는 분야를 장애물로 느끼고 있다면, 분명 그들은 개발에 대한 도메인 지식이 없거나 (혹은 아주 기초만 알고 있거나) 경험 자체가 없는 경우가 대부분이다. 그러나 정부지원사업 및 다양한 지원사업 덕분인지 개발에 투입할 비용을 마련하는 것은 비교적 쉬워졌고, 이제 비용을 투입해서 결과물을 만들어내면 된다!라는 무언가 설레는 마음에 사로잡히게 된다.

그렇다면 당신의 외주 개발은 왜 망하는가?

(가장 기초적이면서 기본적인 사례들을 뽑아보았다)

1. 당신의 아이디어는 개발을 실행할 수준 정도로 구체적이지 않다. (다시 말해서, 당신의 기획은 너무나도 추상적이다.)

아마 많은 대표님들이 외주개발을 맡기면서 개발사에게 들어봤을 법한 말이 있을 것이다. 그것은 바로 "이건 기획서가 아니에요" 혹은 "더 자세히 작성해 주세요"와 같은, 기획이 완전하지 않다는 말일 것이다.

말 그대로다. 개발사는 말 그대로 계산기라고 보면 된다. 당신이 입력한 그대로 입력해서 결과를 알려준다. 하지만 당신이 입력하는 것은 "5+5의 값을 계산해 줘"가 아닐 것이다. 당신은 개발사에게 "뭔가 유럽풍스러운 아름다움에서 조금 더 고풍스러운 걸 만들면 좋겠어"라고 말하고 있을 것이다. 조금 더 개발과 비슷한 예시로는 "딱 위치 정보 가지고 로그인해 가지고 딱 주변 결과가 나오는 그런 거 있잖아요"가 있을 것이다. 객관적으로 인간적인 면모를 없앤다면 딱 로그인해서 딱 결과가 나오는 그런 건 없다.

비용은 더 많이 들지만, 위와 같은 문제를 해결하기 위해 기획까지 맡기는 경우가 있다. 본인의 약점을 인지하고 보완하기 위해 추가 리소스를 투입하는 아주 현명한 선택이다. 하지만 이런 경우도 마찬가지로 결국 개발된 프로덕트는 버려지는 게 대부분인데, 당신이 생각한 "아름다움"의 추상적인 기준과 개발사가 생각한 "아름다움"의 추상적인 기준이 다르기 때문이다. 이 기준을 정하기 위해 기획서를 사전에 공유하지만, 애초에 개발 기획서를 볼 줄 모르는 당신은 소프트웨어 기획 공부를 하면서 차근차근 기획서를 보지 않는 이상, 뭐가 어떻게 결과물이 나올지 예상하기는 어렵다. 그렇다고 공부하면서 검토하는 시간을 들이는 것은 또 시간이 가니, 일단 진행시켜! 가 되어버리고, 그리고 나중에 분명 "왜 이런 걸 안 물어보고 했지?"라는 생각이 들것이다. 심할 경우, 무슨 마음대로 만들어놨어라는 수준까지도 가는 경우도 있다. 안타깝지만, 그걸 미리 물어보고 소통하고 조율하거나, 정해서 알려주거나 등 사전 조치를 취해야 하는 게 바로 발주사의 역할이다. 입력값이 정확하지 않은데 어떻게 당신이 원하는 정확한 결괏값이 나올 수 있을까. 이 역할이 비어있으니, 당연하게도 프로젝트는 점점 산으로 간다.

2. 개발자는 마법사가 아니다. (개발에서 간단한 건 없다.)

나도 같은 실수를 하기도 했고, 내가 개발하는 외주 용역사인 지금도 많은 대표님들이 이런 요청을 하신다. "이거 이렇게 가능하죠? 간단한 건데..." 혹은 "이렇게만 바꾸면 되는 거 같은데" 등등...

개발에 가능하냐 불가능하냐 를 물어보는 건 큰 의미가 없다. 왜냐면 대부분의 답변은 당연히 "가능하다" 일 것이니까. 그러나 중요한것은 결국 가능하기 위해서 필요한 공수 산정을 어떻게, 얼마큼 조율할 것인가 이다.

이 글을 읽는다면, 대부분 글을 읽는 것에 익숙하실 테니, 쉽게 예시를 들자면 아래와 같다.

남자가 주인공인 소설책이 있다. 무려 500페이지나 되는 장편 소설이다. 원고를 읽어본 경영진이 갑자기 "주인공을 여성으로 바꾸면 어때"라는 생각을 하게 되고 작가에게 지령이 떨어진다. "주인공을 그냥 남성에서 여성으로만 바꾸자. 성별만 바꾸는 거야"

원래 주인공은 남성으로 하기로 했지만, 원고 작성이 완성되고 나니 이제야 주인공을 여성으로 바꾸자는 것이다. 이렇게 바꾸는 게 가능한가? 당연히 가능하다. 그렇다면 이게 간단한 작업일까? 성별만 바꾸는 건데?

일단 500페이지 분량에서 주인공을 '그'라고 했다면 '그녀'로 바꾸어야 한다. 500페이지 중 단 한 문장에서라도 '그'로 표기되어 있으면 책 출판을 못하기 때문에 한 문장, 한 단어 하나하나 모두 검토하며 수정한다.

그런데 이런 젠장, 주인공에게 아내가 있었다. 근데 아내를 그럼 남편으로 바꿔야 하는가? 에 대한 지령은 없었다. 작가는 경영진에게 물어본다.

"그럼 아내도 남편으로 바꿔야겠죠...?"

"당연하죠"

"근데 이 부부가 하필 자녀가 있네요 딸인데.... 주인공을 '아빠'라고 부르는 부분도 다 고쳐야겠군요"

"당연하죠"

"근데 이게 가족이나 친척이 많이 나오는 소설인데.... 그럼 가족 호칭이 모두 바뀌어야 하네요 주인공을 삼촌으로 부르는 부분은 이모로, 고모부 라고 하는 곳은 고모로... 그리고 반대로 주인공의 아내 (이제 남편)의 호칭등.... 500페이지 전체 다 수정하려면...."

작가는 힘이 쭉 빠진다. 적어도 몇 주는 검토하고 수정하고 검토하고 수정하고를 반복해야 할 텐데, 늘어난 업무에 대해서 아무런 얘기가 없다. 일정도 이제 최대한 빨리라고밖에 말을 안 한다.

물론 위 사례는 이제 AI로 많이 대체되어 어떻게 보면 간단할 수도 있지만, 역시나 마법처럼 RDB(관계형 데이터베이스, 위 소설에서 주인공이 남성 -> 여성으로 바뀜에 따라 발생되는 '그' -> '그녀', '삼촌' -> '이모', '고모부' -> '고모' 변경 사항 등 주인공의 성별에 따라 연관되어 있는, 그리고 파생되어 있는 다른 호칭들) 전체를 한 번에 뿅 하고 수정할 수는 없다. 단순하게 '간단한 수정'이라고 하는 순간, 소통에서 벌써 좁혀지지 않을 간격이 훤히 보인다.

그리고 이 문제는 아래 3번과 이어진다.

3. 개발 프로젝트를 진행하고 관리하는 사람이 없다. (즉, 어떻게 관리해야 하는지 아예 모르는 상태로 외주를 맡겨버린다.)

PM이라는 말을 업계에서 많이 들어보았을 것이다. Project Manager라는 이 직책은 다양한 회사에서 다양한 역할로서 업무를 담당하고 있고, 이는 회사마다 조금씩 차이가 있다. 하지만 근본적으로 말 그대로 이 직종은 바로 프로젝트를 관리하는 직종이다.

프로젝트는 항상 1. 시간 / 2. 업무량 / 3. 비용 (리소스) 이 3가지의 밸런스를 맞춰서 최종 결정된다. 이 중 하나라도 변경이 있거나, 변경될 가능성이 있다면 이를 사전에 소통하고 논의하고 수많은 이해관계자들과의 합의를 통해 프로젝트 진행에 문제가 없도록 하는 게 바로 PM이다. 구글 프로젝트 매니지먼트 수업에서는, PM이 소통해야 하는 이해관계자에 팀원 및 내부 직원뿐만 아니라 고객, 경영진, 주주 까지도 모두 포함한다고 명시하고 있다.

위 2번 소설책 예시를 다시 활용해 보자.

원고를 90일간 (시간) 500페이지를 (업무량) 작성하기로 하고 비용을 1,000만 원 (비용)으로 측정했다.

하지만 80일째가 되던 날, 주인공이 남성에서 여성으로 바뀌었다.

제대로 된 PM이 없는 당신은, 작가에게 주인공이 남성에서 여성으로 바뀌었다는 점을 공유한다. "일단 10일 남아서 시간이 없는데 조금 더 걸리더라도 중요한 거니까 바꿔주세요"

작가는 외주 개발사, 즉 실제 작업을 실행하는 사람이다. 주어진 업무를 실행하는 작가는 이 책을 출판하는 프로젝트 전체를 총괄하지 않는다.

PM은 주인공이 남성에서 여성으로 바뀌는 수정사항으로 인해 파생되는 수많은 것들을 모두 조율하고, 소통하고, 합의해야 한다. 일정이 10일 남은 상황에서 주인공 성별이 바뀐다면, 예상 소요 일정은 얼마 큼이 될 것이고, 수정 후 1차, 2차 검토까지, 그리고 혹시나 일정이 지연될 가능성이 있으니 조금 더 여유로운 일정까지 (버퍼기간이라고 한다) 모두 고려해서 경영진, 작가, 책이 배송될 서점 등 이해관계자들과 미리 조율해야 한다. 게다가 변경 시에 500페이지가 맞는지, 500페이지에서 증가한다면 인쇄소에 예정보다 얼마나 페이지 수가 늘어나는지, 이에 따른 추가 비용은 얼마인지, 표지 디자인에 주인공이 있는데 디자인 변경은 어떻게, 얼마를 들여서 언제까지 수정하고 표지를 생산하는지, 이에 따른 비용은 또 얼마나 변동이 되는지 등 연관되어 있는, 그리고 파생되는 수많은 변동 사항들을 경영진 등 이해관계자들과 우선 내부적으로 소통하고 합의하여, 디자인회사, 출판회사, 프리랜서 작가, 등 외부 이해관계자들에게 전달하고, 다시 소통하고 합의를 거쳐야 한다.

그래서 미국의 PM 연봉은 매우 높은 편에 속한다. 실무를 하나도 안 하는 메신저 역할 같지만, 사전에 잘 대비하며 소통을 잘 이끌어내는 PM은 최고연봉을 줘도 부족할 만큼 중요하다.

물론 진짜 PM처럼 하지 못하는 현실도 나 역시 너무나도 잘 알고 있다.

그러나 이것만은 명심해야 한다. 시간, 업무량, 비용 중 업무에 수정사항이 생겨 업무량의 변화가 생겼다면, 반드시 다른 2개 (시간과 비용) 역시 변동이 있을 수밖에 없고, 이를 먼저 소통하고 조율해야 한다는 것이다. 이 3가지의 밸런스에 조금이라도 금이 가는 순간, 프로젝트는 점점 망하게 된다.

p.s 물론 이 모든 걸 다 해결할 수 있는 것은, '돈'이다. 위 3가지 모두 외주사가 다 할 수 있을 만큼의 비용을 지불할 수 있다면, 그리고 그 외주사가 정말 일을 잘하는 외주 사라면 프로젝트는 성공적일 것이다.

-Note-
5억 원을 날린 스타트업 대표의 '실패하는 법' 매거진 글입니다.
지금도 실패 중인 실패한 스타트업 대표의 아무 생각이나 막 적는 매거진이니 참고 바라며, 개인적인 경험과 생각, 의견 등을 바탕으로 작성된 글이니 일반화의 오류에 빠지지 않기를 바랍니다. 또한, 아직도 실패 중인 사람의 생각이니, 반대로 생각하면 성공할 가능성이 조금 더 올라갑니다.
나의 실패를 통해 누군가 배울 수 있었다면, 감사합니다.