온라인 인테리어 서비스 개발 케이스로 살펴보는 명백한 온라인 비즈니스 실패 상황

과거 진행했던 프로젝트 몇 개를 통해 어떻게 앱 개발을 진행해야 하는지에 대하여 생각해 보고자 합니다. 개인적으로 어떻게 하면 성공한다는 방법론은 없습니다. 그러나 다양한 프로젝트 경험을 통해 이렇게 하면 앱 서비스를 실패한다는 것은 알게 되었습니다. 이 위험 요소만 피해도 성공 가능성을 높일 수 있을 것입니다.

 

 

검토를 시작하면서

앱이나 웹 같은 온라인 프로젝트를 참여하게 되면 문제가 있는 프로젝트에는 공통점이 있다는 사실을 알게 됩니다. 참여 프로젝트가 많지 않을 때는 공통점을 찾아내기 어렵지만, 많아지면 통계적인 공통점을 어렵지 않게 알게 됩니다. 그냥 문제가 있는 프로젝트에 반복적으로 나타나므로 알아채는 것은 어렵지 않습니다. 

 

재밌는 사실은 프로젝트를 책임지거나 관리하는 인력들은 공통적으로 실패의 환경에서 성공의 결과를 얻으려 한다는 것입니다. 상식적으로 실패의 확률이 높은 환경은 만들지 않는 것이 성공의 가능성을 높이는 것이라는 것을 알고 있지만 문제가 있는 프로젝트는 공통적으로 이를 무시합니다.

 

같이 프로젝트를 하면서 협업을 하다 보면 스스로를 과신하는 우리는 다르다는 생각을 하고 있는 것으로 보일 때도 있습니다. 때로는 너무나 분명한 실패의 길이 성공이라 믿고 있는 경우도 있습니다. 아예 앱 비즈니스나 개발에 대해 모르는 담당자도 있습니다.

 

이러한 실패하는 프로젝트의 공통점은 몇 가지 유형으로 정리될 수 있습니다. 우리는 앞으로 몇 개의 글에서 제가 경험한 이 유형을 검토하면서 최소한 너무나 분명한 실패의 방식은 하지 않는 온라인 서비스 프로젝트를 진행할 수 있게 될 것이라 믿습니다.

 

• 지나친 자기 과신
• 잘못된 비즈니스 및 개발 신념
• 잘 모르는 담당자

 

 

케이스 설명

기획자로 투입된 온라인 개발 프로젝트는 종료 약 2개월을 남겨 둔 상황이었습니다. 개발 종료를 앞둔 시점 기획자로 제가 투입된 이유로 설명을 들은 것은 현재 개발된 내용과 스토리보드가 맞지 않기 때문이라는 것이었습니다. 그래서 제 업무는 스토리보드 현행화로 투입되는 것이었습니다.

 

본 프로젝트 케이스 인테리어 대기업인 고객사가 스타트업 '오늘의 집'의 성공을 보고 이와 비슷하게 앱과 웹 온라인 서비스를 업그레이드할 목적으로 진행하는 것이었습니다. 자회사인 SI 기업이 1차 업체였으나, 실제로는 이 1차 업체에서 업체에서 턴키로 프로젝트를 받은 독립 SI 업체가 주도하여 작업을 하고 있었습니다. 그러나 이 업체도 실제 개발은 타 업체에 넘긴 것으로 보였습니다. 2차 업체도 소수 관리 인력만 상주하고 있었고 개발자나 기획자는 다른 업체가 관리하고 있었습니다.

 

저는 종료 시점 3차 또는 4차 업체 밑에 있던 인력 용역업체의 연락을 받아 인터뷰 후 투입되었습니다. 기획자는 저 혼자였지만 같지 투입되었던 개발자는 4~5명 정도 되었던 것으로 기억납니다.

 

일단 투입되어 확인된 프로젝트 주요 상황은 이러했습니다.

 

 

PM이 프로젝트 내용과 상황에 대해 전혀 알고 있지 않았습니다.

고객 기업의 건물의 회의실을 프로젝트 실로 사용하고 있었는데, 이곳에는 서로 다른 여러 기업 소속 인력들이 있었습니다. 그리고 옆 회의실에는 저와 함께 투입되었던 개발자들이 있었습니다. 그리고 다른 쪽에는 1차 업체인 고객 기업이 속한 그룹의 SI 기업 인력이 자리하고 있었습니다.

그런데 신규 투입 인력을 제외한 이전부터 있던 다수 사람들로부터 PM이 프로젝트 내용을 모르고 있다는 말을 들었습니다. 주간회의가 끝나면 여기저기서 불만이 터져 나왔습니다. 

 

 

기획이 없이 개발이 진행되었습니다.

 스토리보드 현행화를 위해 투입되었는데, 완성된 스토리보드가 없다는 사실을 알게 되었습니다. 현재도 스토리보드를 작성 중에 있었으며, 디자인 파일을 보고 스토리보드를 만들라는 요구를 받았습니다. 일단 현행화할 스토리보드 자체가 없는 것은 물론, 스토리보드 작성을 위해 사전 작업하는 여타 기획 문서 또한 작성된 것이 없었습니다. 

시간이 지난 후에 알게 된 사실로 고객과 협의 완료한 요구사항 명세서조차 없었다는 것입니다. 개발 종료를 1달가량 앞둔 시점 갑자기 고객 그룹사 자회사인 1차 SI 업체 기획자라는 분이 새롭게 와서 갑자기 요구 사항이라고 문서를 주면서 스토리보드를 새로 그리라고 요구했습니다. 그런데 이 요구 사항이 고객의 요구가 아닌 1차 업체의 요구 사항이라는 사실을 알게 되었습니다. 

 

 

알 수 없는 개발 상황

기획 관련 내용은 없고 스토리보드도 완성된 것이 없이도 개발은 진행되고 있었습니다. 새로운 개발 작업 내용이 업데이트되어 함께 투입된 개발자들에게 내용을 물어보았습니다. 그런데 개발자들은 누가 개발 업데이트 하는지 모른다고 말하였습니다. 현재 자신들은 개발 오더를 받지 않고 있어 개발을 하고 있지 않고, 인수인계받은 파일을 검토하고 있다는 것입니다.

즉 앱과 웹에서 개발되고 있는 것들이 현재 프로젝트에 투입된 인력들이 아닌 다른 인력이 진행하고 있는데, 제가 물어본 사람들은 아무도 누가 개발을 하고 있는지 모르고 있다는 사실이었습니다.

 

 

개발 대상과 맞지 않는 설루션

인터뷰 때 설명 듣기로는 고객은 인테리어 잡지와 같은 앱/웹 콘텐츠를 통해 사용자에게 서비스되고, 여기서 인테리어 욕구가 커진 사용자를 기존 영업망과 연결하는 것을 온라인 목적으로 한다고 들었습니다.

 

그러나 투입되어 본 설루션은 이를 개발 구현하는 것이 불가능한 것이었습니다. 해당 고객 기업이 작업 중인 인테리어 소재나 작업의 등록조차 어려운 일반 웹 설루션이었습니다. 이런 설루션으로 웹뷰 형태의 개발을 지행하고 있었던 것입니다. 그러니 처음 고객이 기대했던 앱과 웹의 모습 어디에서도 찾을 수 없고 개발이 진행할수록 불만스러운 모습만 나타나고 있었던 것입니다. 이에 대한 고객의 불만은 이미 커질 대로 커져있는 상태였습니다.

 

 

잦은 인력 교체

시작 프로젝트 구성부터 문제가 있었으므로 진행의 문제는 아주 초기부터 있었다고 프로젝트 초기부터 있었던 분에게 전해 들었습니다. 고객을 제외하면 본 케이스 프로젝트 초기부터 있었던 인력은 1명뿐이었습니다. 1차와 2차 업체 인력들도 문제가 커지자 투입된 인력이라 들었습니다.

 

프로젝트에 문제가 생기면 기획팀 전체를 날리고 다시 새로운 기획팀을 구성했다고 합니다. 다음에 문제가 생기면 이번에는 투입된 개발팀 전체를 날리고 다시 구성했다고 합니다. 그래서 제가 받은 스토리보드 버전 그렇게 많았던 것입니다. 투입 기획팀마다 따로 스토리보드를 만든 것이 버전이라는 형태로 남아 있었던 것입니다. 제 기억으로는 5개 버전이 있었고, 제가 하는 작업은 또 새로운 버전인 것입니다.

 

1년이 안 되는 개발 기간 동안 최소 기획팀이 4번 이상 교체된 것입니다. 그래서 스토리보드나 개발 내용을 아는 기획자는 초기부터 남아있던 1명만 존재하는 것입니다. 개발자는 초기부터 있었던 인력은 1명도 없다고 들었습니다.

        

그런데 초기부터 남아 있었던 기획자 1명이 사실은 프로젝트 시작 시 PM이었다고 후에 알게 되었습니다. 후에 제가 소속된 SI 업체와 이야기해 본 결과 문제의 중심이 이분이라고 하는 것입니다. 그런데 프로젝트 히스토리를 아는 사람도 없고 현 PM도 내용을 모르고 있기에 주간보고를 위해서라도 이 기획자 1명만 남겨두고 있다고 합니다.

 

그리고 프로젝트 철수 후 남아 있던 분에게 전해 들은 이야기로는 투입 인력의 경력 뻥튀기를 넘어, 투입되지 않은 인력이 투입된 것으로 등록하여 개발비를 빼돌리는 게 걸렸다고 합니다. 너무 다양한 업체가 투입되어 있어 어느 업체인 것까지는 저는 모릅니다. 프로젝트 실에 있었던 인력들의 소속사도 다 외우기 어려웠기 때문입니다. 

 

 

대표적 외주 개발 문제의 복합 케이스

이 케이스는 다른 분석 요소는 이야기할 필요 없이 그냥 대기업 SI 자회사를 통한 프로젝트가 가질 수 있는 문제를 복합적으로 모두 가지고 있다 생각합니다.

굳이 위에서 예시를 든 3가지 유형 중 선택하지면 앱/웹에 대해 잘 모르는 담당자의 잘못된 비즈니스와 개발 신념이 결합된 케이스라 할 수 있을 것입니다.

 

일단 고객 그룹사 자회사는 국내 대표 SI 기업 중 하나입니다. 그런데 이곳에서 문제를 해결하기 위해 투입된 인력이 앱/웹 개발에 대해 전혀 모른다는 것입니다. 문제 해결을 위해 투입된 기획자가 요구 사항의 개념, 기획 프로세스와 필요한 기획 문서가 무엇인지 전혀 모르고 있었습니다. 그래서 개발 종료를 2달도 안 남긴 시점에서 그냥 개발과 상관없이 스토리보드 문서만 예쁘게 여러 장 만들라는 요구만 해 왔습니다.

 

물론 문제의 시장은 하청과 재하청 구조에 있기는 합니다. 1차 업체는 2차 업체에 넘기고, 2차 업체는 3차 업체에 넘겼습니다. 3차 업체는 프로젝트를 찢어서 여러 업체에 넘기고 관리 인력만 상주시킨 것으로 보였습니다. 그러나 문제가 생기자 2차 업체와 1차 업체도 순차적으로 직원을 상주시킨 것을 보입니다.

제가 투입되었을 때는 1, 2차 직원들이 다 있었습니다. 그런데 이들 투입되어 문제 해결 대상은 개발이 아닌 소송으로 보일 정도였습니다.

 

축구를 하는데 농구 선수로 팀을 구성하고 전략/전술을 만들면 결코 이길 수 없다는 사실을 누구나 알 것입니다. 이 케이스가 바로 이 모습이었습니다.

 

만약 축구와 농구를 모르는 사람이라면 이 사람이 축구 선수인지, 농구 선수인지 알지 못할 것입니다. 체격 조건만 보고 농구 선수도 축구를 잘할 것이라 생각할 수도 있습니다. 이 케이스가 딱 이 모습이었습니다. 

 

게다가 원 개발 비용에서 차지하는 업체 수수료가 너무 커서 실제 개발 업무를 할 인력을 충원하기도 어려운 상황이었습니다. 그리고 개발자들을 문제의 희생양으로 삼다 보니 개발 상황을 아는 인력도 없었던 것입니다.

이 상황을 기업 정치가 비즈니스를 삼켰다고 합니다. 앱 개발이나 비즈니스를 잘 아는 인력이 아닌 정치를 잘하는 인력만 남아 있게 된 것입니다.  

 

이런 상황은 어느 정도 경험만 있다면 쉽게 알아챌 수 있습니다. 그러므로 본 케이스 마지막까지 남아 있던 인력들도 알았을 것입니다. 그래서 스토리보드 현행화로 투입된 저에게 R&R에 맞지 않는 신규 스토리보드 작성을 요구한 것입니다. 개발 종료 1달을 앞둔 시점에 콘텐츠 입력 모듈을 설계하라는 요구 또한 한 것도 개발이 목적이 아니라 면피가 목적이었던 것입니다. 누구도 모르게 개발이 진행되었던 것도 바로 면피 때문이었다 추측해 봅니다.

 

이 정도 상황이 개발 종료 시점 있다면 이미 개발 조직 구성 및 정의 때부터 문제가 나왔을 것입니다. 그럼에도 그냥 넘어간 것은 다른 이유가 있었기 때문이라는 것은 쉽게 알 수 있습니다.

 

이런 류의 앱 비즈니스는 전형적인 실패 케이스라 할 수 있습니다. 그냥 시작부터 온라인 서비스 실패가 아니라 개발을 할 수 없다는 사실은 경험자이거나 앱/웹 비즈니스 역량이 조금만 있어도 아는 상황인 것입니다.

 

개인적으로 프로젝트 철수 시점 일부러 개발 실패를 만들기 위해 일부러 이렇게 구도를 설계한 것은 아닌가 하는 생각이 들 정도였습니다.