앱/웹 프로젝트를 하다 보면 고객 기획자와 개발사 PM/PL들 간 동상이몽 대화를 자주 듣게 됩니다. 매우 재밌는 사실은 서로 대화가 잘 마무리되었다 생각하고 서로 다른 일을 하고 나중에 회의 때 서로 짜증을 내는 경우도 있다는 점입니다. 자체 서비스를 하다 외주 개발 기획을 하니 이러한 모습이 보이는 것일 수도 있습니다.
동상이몽의 이유
기획자 간 동상이몽이 발생하는 이유는 서로의 분야에 대한 전문성이 없이 때문입니다. 그러므로 상대의 말의 진의를 적절히 알아들을 수 없고, 또 자신의 계획을 상대가 잘 소화했는지 파악할 수 없습니다. 결과나 나온 후에야 파악이 되므로 문제가 되는 것입니다. 시간과 작업이 다르게 진행되었기 때문입니다.
제가 경험한 프로젝트들에서는 개발로 투입된 기획자는 사업 기획과 서비스 기획에 대해 이해를 잘 못하는 케이스가 더 많았습니다. 반대로 고객의 경우 개발에 대해 모르는 경우가 많았습니다.
그러다 보니 긴 시간 회의를 해서 서로 다른 결론을 가지고 개발을 진행하고 있는 모습도 종종 보았습니다. 저의 경우 프리랜서를 투입된 경우 PM/PL에 이를 이야기해도 이해를 못 했습니다. 오히려 국내 SI/웹에이전시 현실 상 PM/PL과 프리랜서도 정직원과 단기 고용직이라는 갑을 비슷한 관계라서 더 이상 합리적 이야기가 되지 않을 때도 있습니다.
결국 동상이몽은 연계 프로세스가 되지 않기 때문입니다. 마치 인터페이스 되지 않는 두 시스템이 연결될 되어 하나의 작업을 처리해야 하는 상황인 것입니다.
이는 그래도 좋은 의미의 동상이몽입니다. 상당한 프로젝트 비용이 걸려 있고 여러 기업이 참여하는 개발 프로젝트의 특성상 이보다 더 많은 안 좋은 의미의 동상이몽이 작동합니다.
동상이몽의 사례
제 경험에서 동상이몽 사례를 예시하겠습니다.
고객이 원하는 내용과 다른 개발사의 내용이 다른 경우
인테리어 사업을 하는 고객은 '오늘의 집' 앱에서 영감을 받아 기존의 단순 온라인에서 쇼핑몰 같은 서비스에서 인테리잡지 같은 인테리어 콘텐츠를 제공한 후 계약을 형성하는 앱/웹 서비스를 개발하여는 의도를 가지고 있었습니다.
저는 개발 막바지 투입된 여러 개발사 중 한 곳의 요청으로 기획서 현행화를 위해 투입되었습니다. 개발사 말로는 개발 내용과 기획서 내용이 맞지 않는다는 것을 해결해 달라는 것이었습니다.
그러나 프로젝트에 투입되어 기획서와 개발 내용을 본 결과 문제는 다른 곳에 있다는 것을 알게 되었습니다.
일단 기획도, 개발도 완료된 것이 없었습니다. 이제 개발 종료 시점이 2달밖에 남지 않은 시점에서 완료된 것이 없었습니다. 저는 투입된 업무인 기획서 현행화를 못하는 것은 물론 저와 같이 들어간 개발자들도 작업을 못하고 있었습니다. 그런데 개발 내용이 업데이트되고 있어 물어보니 기획팀에서는 어디서 개발이 되는지 조차 알지 못했습니다.
그리고 일단 고객이 요구하는 앱/웹 서비스가 되기 위한 기본적은 개발 방식과 솔루션이 채택되어 있지도 않았습니다. 그저 과거 방식의 웹뷰 및 플래시 기반 콘텐츠가 제공되는 온라인 서비스가 개발되고 있었습니다. 이 또한 개발 완료까지는 많이 남아 보였습니다.
아무튼 개발 종료를 위해 기획서 현행화로 투입되었는데, 기획서를 만들어야 한다는 오더를 받고 있었습니다. 그리고 이 기획서는 개발과 상관없이 작성하라고 압박하는 상황이었습니다. 고객은 당연히 개발 완료를 요구하고 있는 상황이었습니다.
이런 상황이 앱/웹 개발 프로젝트에서 발생할 가능성은 높습니다. 일단 국내 개발 환경 상 하청, 재하청 등의 다단계로 이루어집니다. 그리고 대부분 하청, 재하청으로 갈수로 실제 개발자는 아래 하청에서 진행하고 위의 하청은 관리 인력이 투입됩니다. 이러한 관리 인력의 경우 개발 내용을 잘 모를 가능성이 높습니다. 단지 인건비 따먹기와 감시 목적의 투입이기 때문입니다. 그러기에 개발보다는 책임 회피에 더 신경 쓰게 됩니다. 이것이 현실적으로 개발이 어려운 이유가 됩니다. 그리고 소모품인 프리랜서들이 실제 개발은 다 하므로, 프로젝트에 문제가 있을 시 프리랜서를 교체하여 면피하려 합니다. 해당 프로젝트로 10개월 동안 최소 2번 이상의 개발팀, 기획팀 전체가 교체되었다고 PM에게 들었습니다. 개발팀, 기획팀 각각 2번 이상입니다.
프리랜서들이 진행 사항을 보고 도망간 것인지, 실력이 없어 프리랜서들을 교체한 것인지, 아니면 책임을 프리랜서에게 씌운 것인지는 알 수 없습니다. 그러나 투입과 철수 의사 결정은 프리랜서가 하지는 않습니다. 또한 어떤 상황이었던 실질적 피해는 프로젝트가 받는 것입니다.
서로 내면의 의도가 다른 경우
외주 개발 프로젝트에 대해 고객은 적은 비용으로 많이 개발해 주기를 바랍니다. 그러나 개발사는 적게 개발하고 많이 받기를 원합니다. 이 차이로 인해 계약과 요구 사항은 모호 질 수 있습니다. 그리고 이는 개발의 범위에 영향을 주게 됩니다.
다른 프로젝트 사례로 웹전표 시스템의 화면 부분 개선 프로젝트 기획을 프리랜서 투입된 케이스였습니다.
그런데 투입되어 확인해 보니 해당 웹 전표는 말이 웹 전표지 기존 ERP 내에서 전표를 처리하는 시스템이었습니다. 직원들이 보안 시스템을 통해 익스플로러 브라우저로 이용하고 있어서 웹전표이지 그냥 ERP 시스템이었습니다. 또한 웹전표 처리 내용은 바로 SAP와 연동되어 회계 처리되고 있었습니다.
그런데 프로젝트는 이 웹전표 시스템을 기존 ERP에서 분리해서 크라우드 시스템으로 옮기는 것이었습니다. 이때 DB도 변경한다고 합니다. 여기에 기존 이용 브라우저인 익스플로러가 MS에서 사용 중단함에 따라 이용 브라우저도 변경해야 했습니다.
기존 화면 변경과는 프로젝트 범위가 완전히 달라지고 있는 것이었습니다.
여기에 고객사에서 진행하고 있었던 다른 ERP 프로젝트에 비해 개발 비용이 현저히 작았습니다. 고객은 기존 ERP에 하라로 묶여 카테고리로 되어 있던 기능을 나누어 새로 개발하고 있었습니다. 들리는 말에 의하면 나누어 개발되는 한 부분이 웹전표 시스템은 다른 여러 개발 프로젝트에 비해 1/10 정도의 개발비로 진행되고 있다고 합니다. 아마 화면만 작업해서 그런 것은 아닌가 생각됩니다.
그래서 저는 현재 서버 환경과 똑같이 가상화하여 크라우드 서버에 올리고 화면만 수정/보완하는 것이라 생각했는데 PM과 PL 말로는 그게 아니었던 것이었습니다.
여기에 웹전표가 처리되는 비즈니스 프로세스에 대한 것도 정리된 것이 없었습니다. 운영 매뉴얼조차 없어 현대 운영 중인 SM 기업은 문제 발생 시 하드 코딩하여 처리하고 있었습니다. 그래서 간단한 처리도 시간이 오래 걸리고 있었고, 이러한 처리 시간이 오래 걸리는 문제를 해결해 달라고 요청이 나오고 있었습니다.
개발자와 코드를 확인해 본 결과 어떤 작업이든 코드는 모든 프로세스를 체크하는 방식으로 되어 있고, 이를 위해 프리임 키가 하드코딩되어 있었습니다.
그래서 고객과 운영 기업의 담당자와 회의를 요청하였습니다. 이 자리에서 충격적 사실을 알게 되었습니다. 현재 고객은 여러 개의 해외 법인과 국내 법인의 전표 처리를 작업할 웹전표 시스템에서 처리하고 있는데 개발이 너무 오래되어 처리 비즈니스 로직을 아무도 모르는 상황이라는 것이었습니다. 운영 기업도 설계서나 기획서가 없어 문제 시 코드를 까 보고 처리하고 있고 대부분 하드코딩으로 해결하고 있다는 것입니다.
그런데 PM과 PL은 이 말의 의미를 이해하지 못하고 있었습니다. 그냥 화면만 개발하면 된다고 생각하고 있었습니다. 고객은 이번에 1/10 단가로 웹전표 BPR, 시스템 설계, DB, 크라우드 서버, 프런트 개발과 크롬 대응 등의 기존에 못했던 것을 모두 해결하려 하고 있었습니다. 운영 기업 담담자는 운영 매뉴얼이나 기획서만 만들어주어도 감사하다고 생각하고 있는 상태였습니다.
시작부터 고객이 생각하는 개발의 범위와 개발사가 생각하는 범위가 달랐던 것입니다.
투입 전 내용과 투입 후 내용이 너무 달라 기획자로 저는 계약서와 요구 사항을 보게 해달라고 요구했습니다. 일단 계약서의 개발의 범위가 매우 모호하게 되어 있었습니다. 그리고 정리된 요구 사항은 없었습니다. 요구 사항을 투입 후 제가 화면 관련 웹전표 이용 중인 여러 팀들을 인터뷰 한 내용이 요구 사항이라고 PM은 이야기했습니다. 결국 관점에 따라 비즈니스 프로세스와 웹전표 모든 개발이 범위가 될 수 있는 것입니다. 화면을 이용하려면 필요하기 때문입니다.
동상이몽 결과
고객 기획자, 개발 기획자의 동상이몽은 해당 앱/웹으로 진행하려는 비즈니스 전략 및 수익화 등을 진행할 수 없게 만듭니다. 의도한 온라인 서비스 사업이 아닌 다른 사업을 해야 하는 경우가 될 것입니다.
심한 경우 앱/웹의 개발 자체를 실패할 수도 있습니다. 위와 같이 극단적 케이스의 경우 개발에 참여한 서로 다른 목적 때문에 최소 한쪽의 기획자는 해당 프로젝트의 개발이 완료될 것이라 기대를 하고 있지 않고 있었을 것입니다. 물론 이는 극단적 동상이몽이기는 하지만 종종 발생합니다. 개발이 중간을 넘는 순간 이런 생각을 하는 개발 관련자가 나타나기 시작할 것입니다.
이런 상황에서 개발은 성공하기 어렵습니다.
개발된 앱/웹을 가지고 사업을 하는 입장에서 이러한 상황은 개발이 되었어도 실패한 것입니다. 오토바이를 개발해 달라고 했더니 자전거를 개발하고 바퀴 두 개와 운전대가 있으니 똑같은 것이라 말을 한다면, 준비 중인 오토바이 사업을 진행할 수 없게 됩니다. 그러면 자전거를 개발한 해당 프로젝트는 실패인 것입니다.
개발사는 자전거가 개발된 거니 성공이라 할 것입니다. 고객이 자전거는 수동이고 오토바이는 자동으로 움직인다 말하면, 자전거에 모터를 달아주고 개발 완료라 할 수도 있습니다.
분명 움직이는 자전거, 움직이는 모터 자전거는 개발이 된 것입니다. 그러데 온라인 서비스를 위한 개발에 맞게 된 것인가요?
대형 컴퓨터 모니터를 주문했는데 더 가격이 저렴한 TV를 보내주고 모니터라 하는 판매자에게 어떤 생각이 들까요? 반대로 TV를 주문하고는 그 크기의 4K 모니터를 달라고 하는 구매자에게 어떤 생각이 드시나요?
목적을 달성하지 못하는 앱/웹의 개발은, 개발 자체가 어떻든 간에 결과는 실패가 더 어울립니다.
댓글