드라마 삼체로 살펴보는 앱과 웹 초기 기획이 잘못되면 개발이 어렵게 되는 이유

보통 초기에 투입되는 기획/설계자의 업무가 미진할 경우 중간에 교체를 합니다. 보통 3~5개월 이상 지난 뒤가 될 것입니다. 교체 기획자는 어느 정도 실력이 있어도 이 문제를 해결하지 못할 것입니다. 그리고 이후에는 아무리 실력 좋은 기획자가 들어와도 문제를 해결할 수 없게 될 것입니다. 여기에는 이유가 있습니다. 

 

 

 

기획은 시간의 흐름에 대한 문제 해결이기 때문

 

결론부터 이야기하자면 기획의 속성인 '시간에 따른 목표 달성의 문제 해결' 때문입니다. 이는 앞서 다른 글에서 '기획은 프로세스다', '과정이다.' 등으로 이야기한 것과 맥이 같습니다.

 

이를 시간에 흐름에 기반하여 드라마 삼체의 예를 들어 설명해 보겠습니다.

 

아마 삼체 드라마를 보신 분이 많으므로 이런 설명은 '기획은 프로세스다', '과정이다.' 등의 말이 이해에 도움이 될 것이라 생각합니다.

 

일단 먼저 우리는 엄마가 나간 후 아이들이 집을 어지르는 것을 보고 있다고 가정합니다. 이때 아이들이 집을 어지르는 단계는 시간의 흐름에 따라 심해집니다. 처음에는 놀이방에 장난감을 어지르는 것에서, 거실로 나와서 어지르고, 음식을 먹으며 어지르고 합니다. 점점 어떤 물건이 어디에 있었던 것인지도 알 수 없게 되고, 심지어 너무 어질러서 필요한 물건을 찾기도 어려운 상황에 다다르게 됩니다.

 

이를 시간의 흐름에 의한 어지러움이라 합니다. 이때 시간에 따라 어질러지고 물건이 이동하는 놀이방, 거실, 식당 등의 장소의 혼란의 파급을 각각 A, B, C라 하겠습니다. 1차 시간 타임에 장난감은 A에만 있습니다. 그리고 어지르는 게 B로 넘어가면서 장난감은 B에도 존재하게 됩니다.

 

이로 인해 장난감을 치우는 엄마는 A 뿐 아니라 B와 C도 찾아야 장난감을 정리할 수 있게 됩니다. 또한 거실 물건, 식당 물건과도 섞어 장난감을 찾는 것조차 어려운 상황이 됩니다.

 

자 이제 이 A, B, C 삼체의 예를 앱/웹 개발 프로젝트로 가져오겠습니다.

 

  

앱/웹 개발 프로젝트 기획 단계

 

일반적으로 앱이나 웹 개발이 시작되면 개발할 앱 또는 웹을 정의합니다. 이때 기능과 화면/UI에 대한 개발 앱/웹의 특정과 필요가 정리됩니다. 이 정리는 앱/웹 사업 방향 및 경쟁 전략 등에서 나오는 정책에 기반합니다.

 

결국 이 말은 개발될 앱과 웹에 대한 정책이 있어야 온전한 기능 정의, 화면 정의가 가능하다는 말이 됩니다.

 

그래서 우리는 앱/웹 개발 프로젝트를 먼저 필요한 정책 정리를 A 단계, 이후 개발 할 앱에 대한 기능 정의와 화면 정의를 B단계라 하겠습니다.

 

이 두 단계는 개발 프로젝트가 진행되는 시간의 흐름에 상호 연결성을 가지고 있습니다. 즉, A와 B 단계는 서로 연결되어 있다는 말입니다. 

 

그러기에 이를 드라마 삼체에서 두 항성이 서로 중력의 영향을 주고받는 것에 비슷하다고 할 수 있습니다. 물론 실제 복잡도가 그렇지는 않지만, 관계가 유사하다는 것입니다.

 

그런데 보통 앱/웹 개발 프로젝트에서 기획자가 작업하는 스토리보드/화면 설계 작업은 아직 언급하지 않았습니다.

 

앱/웹 스토리보드/화면 설계는 개발될 앱과 웹의 특성이 반영되어야 합니다. 또한 작동이 되어야 합니다. 그러므로 기능 정의와 화면 정의의 내용을 토대로 작업하는 것이 효율적이게 됩니다.

 

이 스토리보드/화면 설계를 C라 하겠습니다. 그러면 C는 B와 연결됩니다. 여기서 또 C는 B를 통해 A와도 연결되게 됩니다. 그러므로 기능 정의나 화면 정의 내용의 해석이 모호한 경우 정책을 통해 스토리보드/화면 설계를 완성할 수 있게 되는 것입니다.

 

 

 

잘못된 기획의 시작의 개발 난이도를 올리는 이유

 

앱/웹 개발 초기 투입되는 기획자는 정책을 개발에 맞게 정리합니다. 이를 요구 사항 분석/상세화라 부를 수 있습니다. 또한 이를 바탕으로 기본적인 앱/웹 시스템에 대한 전반적 설계를 합니다. 이는 일종의 앱과 웹의 사업 방향 및 경쟁 전략이 반영된 앱과 웹에 적용된 비즈니스 구조(BA)로 할 수 있습니다.   

 

이런 이유로 A(정책 정리)는 요구 사항 상세화 및 시스템 설계의 내용으로 앱/웹 개발 프로젝트에 영향을 미치게 됩니다. 이는 마치 삼체 드라마의 가장 먼저 형성된 항성과 비슷합니다. 

 

요구 사항 명세서와 시스템 구성에 따라 더욱 앱과 웹을 개발할 수 있게 상세화 한 기능 정의와 화면 정의가 작성됩니다. 이를 A 항성에 영향을 받는 새로 형성된 B 항성에 비유할 수 있습니다.

 

B 항성이 A 항성의 영향하에 형성된 것이라 해도, 일단 형성된 이후에는 B 항성도  A 항성에 영향을 주게 됩니다. 그래서 이 두 항성은 서로 영향을 주고받는 관계게 됩니다. 

 

이로서 단지 하나가 더 발생한 것만으로도 복잡도는 더 올라가게 됩니다. 

 

앱/웹 개발에서도 일단 기획된 기능 정의와 화면 정의 내용은 요구 사항(정책)에 영향을 주고받습니다.

 

만약 어떤 기획자가 요구 사항을 잘못 이해하여 기능 정의와 화면 정의를 했는데, 이것을 바꾸면 개발 기간과 난이도, 범위에 현저히 영향을 주는 상황이 되었다고 가정합니다. 그러면 어떻게든 요구 사항 해석을 조금 다르게 해서라도 그대로 기능 및 화면을 개발하는 방향을 가려고 노력할 수 있습니다.

 

아니면 현재 트렌드가 어떻고, 개발 비용이 어떻고 해서 요구 사항을 변경하려 고 노력할 수도 있습니다.

 

그러나 독립적인 개발 항목이 아니고 종속적인 항목의 경우 이런 변경은 또 다른 문제를 야기할 수 있습니다. 

 

일단은 어떻게 해서 그렇게 넘어갔다고 가정합니다.

 

이제 화면 설계를 진행합니다. 흔히 IA나 화면 목록을 보고 화면 설계/스토리보드를 작성합니다. 그러나 이는 앞서 B에서의 화면 정의 내용을 말하는 것입니다. 다른 말로 화면 정의 없이 작성된 IA나 화면 목록은 단순한 상상 또는 개발되어야 할 해당 앱/웹과 다른 기획자 자신의 개인적 생각이라는 점입니다.

 

이유는 간단합니다. 기업이 앱과 웹을 개발하려는 의도는 사업 방향 및 경쟁 전략에 바탕하기 때문입니다. 바로 앱과 웹에서 발생하는 수익 때문에 앱 또는 웹을 개발하려는 것이지, 그냥 앱과 웹을 가지고 싶어서 수 십억 원, 수 백억 원을 들여서 개발하는 기업은 존재하지 않습니다.  

 

이렇게 작업된 기획 내용인 스토리보드/화면 설계를 C라 합니다. 이 C는 앞의 내용처럼 B와 연결됩니다. 그리고 B를 매개로 A와 연결됩니다. 

 

또한 B가 A에 영향을 주듯이 C 또한 B와 A에 영향을 줍니다.

 

이로써 항성 단위는 아니지만 개발 프로젝트 안에서 기획 삼체가 완성되었습니다. 

 

가장 많이 하는 착각 중에 스토리보드나 화면 설계 단계를 독립 기획 단계로 보는 것입니다. 이 경우 요구 사항 상세화 및 시스템 설계, 기능/화면 정의를 해 본 적이 없는 기획자의 경우 흔히 합니다.

 

기획 리더가 이런 착각을 하는 경우 때로는 화면 설계 기간이 끝나갈 무렵 요구 사항을 정리하는 해프닝도 행기대 됩니다. 심한 경우 화면 설계 기획자들이 참고해야 할 가이드를 화면 설계 막바지까지 작성하기도 합니다.

 

이는 일의 상호 연결성을 모르기 때문입니다. 다른 말로 유기적 사고 훈련이 안되어 있기 때문입니다. 이 경우 심하게 문서 한 장 한 장 그 자체에 집착하게 됩니다. 그래서 앱/웹으로 진행하려는 사업 방향과 경쟁 전략과 맞지 않는 문서적으로만 그럴듯한 화면 설계가 완성되게 됩니다. 물론 이 화면 설계 문서에는 상호 연결성이 없기에 개발과 디자인으로 이어질 수는 없습니다.    

 

분명 여러 협업 부서에서 불만이 나올 것입니다. 앱/웹 개발은 혼자 하는 게 아니게 때문입니다. 이러한 여러 개발자와 디자이너와 협업은 기획자의 작업의 복잡도를 올립니다. 그런데 이 복잡도는 C 시점의 복잡도일 뿐입니다.

 

만약 C 시점 기획자의 역량 부족으로 문제가 있었다면 그래도 문제 해결 가능성이 올라갈 것입니다. C 시점의 복잡도만 해결하면 되기 때문입니다. 이는 앞의 예에서 놀이방과 거실은 깨끗한데, 부엌만 어지러운 상황과 비슷합니다.

 

그런데 우리의 가정의 '앱과 웹 초기 기획이 잘못되면'입니다.

 

즉 B 단계의 기획자가 뛰어난 기능/화면 정의를 완벽히 했더라도 이는 이미 잘못된 사업 방향과 경쟁 전략의 바탕으로 작업된 결과물입니다. 그러므로 아무리 잘했어도 잘못된 것을 바탕으로 완성되었기에 잘못된 것이 됩니다.

 

이는 마치 오염된(상한) 재료로 만든 최고의 음식이 잘못된 것과 같습니다.

 

또 이 기능/화면 정의를  바탕으로 스토리보드/화면 설계가 되었다면 이 또한 잘못된 기획이 됩니다.

 

문제는 앞서 언급했듯이 기획은 시간의 흐름에 종속된다는 것입니다. 총 15개월 프로젝트에 이렇게 6개월이 흘렀다면 이제 9개월만 프로젝트 완성까지 남은 것입니다. 남은 9개월 동안 기획을 새로 하고 개발까지 끝내야 합니다. 

 

그런데 모두 혼란한 가운데 고객은 빨리 화면을 보자 하고, 심지어 작동되는 모습을 프로토타입으로 보자고 하기도 합니다. 

 

이렇게 된 상황은 총 6개월이 며칠로 압축된 것과 같습니다.

 

이는 마치 지구와 목성, 토성이 서로 달 정도 위치에 있는 것과 같습니다. 지금 태양 옆에 태양 하나가 더 생긴 상황에서 목성과 토성이 지구 옆으로 온 상황인 것입니다.

 

이 경우 삼체 드라마에 나오듯이 지구보다 더 고도의 문명을 가졌음에도 해결을 못했던 것과 같은 앱/웹 개발 프로젝트 상황에 빠지게 되는 것입니다.

 

더 문제인 것은 삼체 외계인은 지구보다 더 고도의 문명임에도 해결하지 못했습니다. 그런데 이 경우 앱/웹 프로젝트는 이미 비용을 썼기에 낮은 인건비로 문제를 해결한다는 점입니다. 마치 중세인으로 삼체 외계인의 문제를 해결하려는 것과 같은 것입니다.   

 

앱/웹 개발 기획 상황의 복잡도, 시간, 비용 등이 또 다른 삼체문제를 야기하는 것입니다.

 

이러한 이유로 거의 모든 이 상태의 개발 프로젝트는 실패하거나, 정치적으로 문제를 덮거나 하는 형태로 종료되게 됩니다.