어쩌면 개발을 안 한 것이 더 좋은 것일지도 모른다

온라인 서비스 프로젝트를 하다 보면 가끔씩 지금 개발 포기하는 것이 더 비용을 아끼는 것일 것 같은데 하는 생각이 들 때가 있습니다. 실제 제가 직접 하는 프로젝트는 개발을 중단하고 처음부터 기획을 다시 한 적도 있습니다. 그러나 회사 지원 또는 외주 기획 시는 이런 결단이 어려울 수도 있습니다.

 

 

개발 포기 이익과 손실

 

개발 포기가 이익이 되는 상황은 매출 기대가 없는 상황과 개발이 진행될수록 문제가 생기고 커질 것이 분명한 상황을 의미합니다.

 

• 매출 기대가 없는 경우
• 개발 문제 발생 가능성이 분명한 경우

 

사람은 이러한 상황 정보를 확보해도 때로는 이를 애써 무시하기도 하고, 심지어 의도적으로 정보를 다르게 해석하기도 합니다. 그리고는 이를 강화하는 새로운 정보를 찾아 헤매기도 합니다.

 

일단은 이 자체가 비효율적이고, 비합리적인 것이지만 사람의 심리는 이를 통해 만족과 안정을 느끼고는 합니다.

 

그러나 스스로 이것을 알기는 합니다. 아니면 시간이 지나면서 이것은 아닌데 하는 생각이 들기는 할 것입니다. 이때 책임이라는 측면에서 문제의 인식과 다른 방식의 해결 방안을 선택하게 됩니다.

 

즉, 개발 이익이 아니라 개발 실패 원인 이전, 해당 개발 프로젝트에서 탈출 등의 선택을 통해 리스크를 헷징 하려는 시도를 하려 합니다. 그렇다 해도 개발 실패를 피할 수는 없지만 책임을 지는 일은 없을 수 있습니다. 책임을 지지 않으면 기업은 손실이 있을 수 있지만 개인은 손실이 없을 수 있습니다. 

 

 

 

 

매출 기대가 없는 경우

 

너무나 당연한 말이지만 실제 경영, 거래 현장에서는 다양한 이익 문제로 실제 진행되는 경우가 많습니다.

 

때로는 개발로 인한 손해가 크지 않은 경우 개인적 이득 또는 관계사의 이들을 위해 이러한 개발은 진행됩니다. 아니면 지나친 자신감과 확신 때문에, 대표의 욕망 때문에 매출 기대가 없는 개발은 진행될 수 있습니다.

 

기업에 대한 과도한 충성도가 이유 없는 확신을 형성하기도 합니다. 다른 직원들의 성과를 조직 관점에서 내면화하면서 자신의 실력으로 변경되기도 합니다. 또는 더닝 크로거 이팩트로 인해 누가 보아도 없는 매출 기대가 발생할 수도 있습니다. 

 

이런 프로젝트는 누구나 매출 기대가 0에 수렴함을 인지하고 있습니다. 단지 그 개발의 의사 결정자 또는 담당자만 그렇게 생각하고 있지 않을 뿐입니다.

 

매출 기대가 없는 개발의 진행은 심리적 요소와 함께 부족한 전문성과 객관화 실패로 이루어지는 경우도 많습니다. 이때 다른 기업의 성과가 너무 쉽게 보입니다. 앱의 경우 그냥 앱을 이용해 보니 너무 개발이 쉬워 보이는 것 같은 것입니다.

 

원칙적으로 매출 기대가 없는 개발은 중간에라도 중단하는 것이 이익입니다.

 

총개발비가 100이라고 했을 때 중간인 개발 50 상황에서 중단한다면 50만 비용이 든 것이지만, 다 개발하면 100만큼 비용이 들어간 것입니다. 2배가 비용이 들어간 것입니다.

 

어차피 둘 다 매출은 0이기에 비용이 적게 들어간 것이 회사로는 이익인 것입니다.

 

 

 

개발 문제 가능성이 분명한 경우

 

이는 개발 관련 작업을 하고 있으면 누구나 느끼게 됩니다. 처음에는 모를 수 있지만 개발 작업을 하다 보면 그냥 알게 됩니다. 이를 경험에 따른 직감이라고 할 수도 있고, 실무 능력이라고도 할 수 있습니다. 그냥 여러 번 개발 프로젝트를 하다 보면 알게 되는 자연스러운 현상입니다.

 

기획자의 경우 앱 아니 웹 개발 기획을 여러 번 하다 보면 설계 문서만 보면 대충 개발 진행을 알게 됩니다 그래서 종종 스토리보드로 만으로 개발이 어떻게 진행되었고, 어떤 문제가 있는지 대량적으로 잡아낼 수 있게 됩니다. 스토리보드로 개발자와 같이 작업을 하다 보니 알게 되는 것입니다.

 

좀 더 경험을 하다 보면 개발자 반응을 보고도 대충 문제에 대한 감을 잡을 수 있게 됩니다. 이는 코딩을 할 수 있느냐, 디자인 툴을 사용할 수 있느냐와 전혀 별개의 감입니다.

 

개발 프로젝트가 스토리보드를 바탕으로 진행되는 것이라면 상호 작용을 통해 느낄 수 있는 것입니다. 일반적인 앱 개발 구성 프로세스는 어느 정도 구조화 되어 있기 때문입니다.   

 

개발 문제 가능성이 분명하다는 것은 초기에는 별 문제없어 보일 수는 있을 수도 있지만, 진행이 되면 될수록 어려움이 생기고 종국에는 개발 완료를 하기 어려워진다는 것을 의미합니다.

 

문서나 디자인 상으로는 아무 문제가 없어 보이기에 이러한 개발 프로젝트는 계속 진행이 됩니다. 그러나 개발을 하고 있는 작업자는 이를 점점 구체적으로 느끼게 됩니다.

 

그래서 개발 실무와 지속적인 커뮤니케이션이 필요한 것입니다. 국내의 일반적인 상하, 갑을 관계하의 커뮤니케이션은 아무리 많아도 이 상황을 잡아내기 어려울 수 있다는 점을 기억해야 합니다.

 

개발 문제 가능성이 분명하다는 것의 한 사례로는 앱으로 치면 버그 많은 앱이 개발되고 있음이 있습니다. 이런 버그 가능성이 많은 앱으로 매출을 올리기는 쉽지 않을 것입니다.

 

그래서 이는 다른 의미의 매출 가능성이 없는 앱을 개발하고 있는 것이 됩니다.

 

여기에 더해 문제 가능성은 개발 비용을 상승시킵니다. 시간적으로나 질적/양적으로 문제 해결 비용은 상승할 수밖에 없습니다.

 

결국 이 상황은 매출은 낮아지고 비용은 상승하는 상황이 되는 것입니다.