앱 또는 웹 신규 개발과 개선을 위한 기획 중 난이도가 더 높은 것은?

일괄적으로 이렇다는 결론을 내리기는 어렵지만 상황에 따른 난이도 차이는 분명히 있을 것 같습니다. 잘 개발되고 설계 문서도 있는 경우 개선 프로젝트의 난이도는 확실히 낮아집니다. 그러나 문제가 있는 시스템, 설계 문서가 없는 경우 개선을 위한 개발의 난이도는 올라가게 됩니다. 

 

 

케이스 구분

 

앱/웹 신규 개발과 개선 개발 난이도를 고려해 보기 전 먼저 간단한 가정을 하여 구분해 보겠습니다.

 

이 가정을 통한 케이스 구분은 앞에서 언급했듯이 개선 개발에 대한 것입니다. 

 

• 케이스 1 - 현재 앱/웹에 문제가 없고 서비스가 잘 진행되고 있다. 앱/웹 개발 관련 기획서가 잘 되어 있고, 기획된 설계 문서와 작동되는 앱/웹의 설명 관계가 잘 이루어져 있는 상태이다. 그러므로 특정 앱/웹 부분을 파악하기 위해 코드를 까 보는 것이 아닌 기획 설계 문서만 보아도 충분히 내용을 파악할 수 있다.
• 케이스 2 - 현재 앱/웹에 분명한 문제가 발견되고 있다. 화면 설계 외에는 특별한 기획 문서가 없고 설계 문서도 부실한 상태이다. 앱/웹의 비즈니스 로직은 앱/웹 이용을 통해 파악할 수 있고, 특정 부분의 문제를 발견 시 코드를 까서 문제를 찾아야 한다.

 

일단 신규 개발은 똑같은 하나의 상황이라 가정하고, 개선을 위한 개발에서는 위 두 가지 케이스가 존재한다고 가정합니다.

 

 

현재 앱/웹 서비스가 잘 이루어지고 있고 기획서도 완비되어 있는 상황

 

이런 상황에서의 서비스 고도화/개선 개발의 난이도는 신규 또는 차세대 개발보다 난이도가 낮아질 것입니다. 기획에 있어서도 이는 똑같이 적용됩니다.

 

특히 기획서가 완비되어 있어는 사실은 고도화/개선 개발 기획의 난이도를 낮추면서도 확실히 기획 리스크를 감소시킵니다. 고도화/개선 관련 기획의 퀄리티의 상당 부분 과거 개발 시 기획 문서가 받쳐주게 됩니다.

 

잘 작성된 기획서가 완비되어 있다는 사실은 해당 앱/웹의 개발 설계 문서 및 개발의 목적, 기능, 화면 구성에 대한 전반적인 내용을 쉽게 파악할 수 있다는 것을 의미합니다. 그러므로 이 문서들을 기반으로 개선 개발을 위한 기획을 하면 됩니다. 

 

한 마디로 앱/웹 고도화/개선을 위한 내용을 기존 기획에 업데이트 하면 된다는 것입니다.

 

만약 기획서가 완비 되어 있는데도 업데이트가 아닌 완전히 새롭게 기획해야 하는 상황이라면, 이전 앱/웹과 연결성이 있는 완전히 이름만 같은 사용자 경험과 UI 등은 완전히 다른 차세대 앱/웹을 개발하는 것과 같습니다.

 

그러므로 이런 상황이 앱/웹 서비스 고도화/개선 개발 프로젝트라 할 수는 없을 것입니다.  

  

 

현재 앱/웹 서비스에 문제가 있고 기획서가 잘 구비되어 있지 않은 상황

 

현재 서비스 되고 있는 앱/웹에 문제가 있다는 사실은 이전 개발에 무언가 문제가 있다는 사실을 의미합니다. 그리고 기획서가 잘 구비되어 있지 않다는 것은 이 문제를 앱/웹 코드에서 찾아야 한다는 사실을 의미합니다.

 

기획자 입장에서 어디서 문제가 있는지는 알지만 어떻게 코딩되었는지 모르기 때문에 정확히 문제를 찾을 수 없고, 그러기에 해결할 수도 없습니다.

 

이런 문제는 코딩에서 발생할 수도 있지만 기획/설계의 부실에서 시작되었을 수도 있습니다.

 

크고 작은 개발 프로젝트를 해 보면 처음에는 기획/설계가 시간만 드는 아무것도 아닌 것처럼 보이기도 하지만 개발의 복잡도가 올라갈수록, 시간이 흘러 코딩된 내용이 많아질수록 그 중요성을 느끼게 됩니다.

 

보통 화면 설계를 기획/설계로 인식하는 경우도 있지만, 스토리보드를 통해 이루어지는 화면 설계는 기획/설계의 아주 작은 일부분이며, 오히려 난이도가 높지 않은 기획 작업이라는 것을 알게 됩니다.

 

때때로 세계적인 천재 기획자가 있어 모든 앱/웹 시스템의 구조와 알고리즘, 프로세스를 머리에 정리하고 한 번에 이를 반영하여 스토리보드로 화면 설계를 할 수는 있지만, 20년이 넘는 기간 동안 이런 기획자는 본 적이 없습니다. 오히려 이렇게 하는 기획자 치고 기획의 기본조차 안되어 있는 경우를 더 많이 보았습니다. 그러므로 현실 확률 상 이런 천재적 기획자를 가정하는 것은 논리적으로 불합리하므로, 충분한 기획 프로세스를 통해 화면 설계를 하는 것이 더 합리적인 기획적 선택이라 할 수 있습니다.     

 

 

화면 설계서로는 왜 문제를 해결할 수  없는가?

 

지금까지 프로젝트를 보면 문제가 이미 발생되어 있는 상태에서 기획자가 교체되거나 추가로 필요할 때 투입되는 경우도 상당히 많았습니다.

 

이때 프로젝트에 투입되면 먼저 기존 기획 자료를 수집해 파악하게 됩니다. 이때 상당 부분 문제의 시작은 기획 없이 화면 설계를 진행한 데에서 시작되었다는 것을 알 수 있습니다.

 

해당 계약의 개발 대상에 대한 기획이 없었으므로, 화면 설계는 말 그대로 앱/웹 시스템의 화면을 나타내는데 그칩니다.

 

그런데 문제는 화면의 모습이 아니라, 화면의 작동에서 발생하는 것입니다. 그러기에 기획 과정 없이 화면 설계가 이루어진 경우 이 작동과 관련한 내용을 스토리보드에서 찾을 수는 없게 됩니다.

 

때때로 개발과 화면 설계가 별도로 이루어지기도 합니다. 개발자는 화면 설계는 참고는 하겠지만, 실제 개발에는 활용하지 않을 때도 있습니다.

 

실제 제가 투입되었던 프로젝트에서는 개발과 스토리보드가 따로 진행되는 경우도 여러 번 있었습니다. 아예 기획 자체를 개발과 상관없이 화면을 그리라는 요구를 하는 프로젝트도 있었습니다.

 

이렇게 기획이 된 경우 기획서를 통해 문제의 파악 또는 개선을 할 수는 없습니다.

 

이 경우 앱/웹 고도화/개선 개발 기획의 난이도는 상당히 높아집니다. 차라리 새로 개발하는 것이 더 쉽지, 기존 앱/웹의 문제를 찾아 해결하면서 개발해 나가는 것은 쉽지 않습니다.

 

그래서 이런 프로젝트의 기획자는 때로는 그냥 요구를 반영하는 화면 설계만 하기도 합니다. 먼저의 개발 기획에서 했듯이 기획 과정 없이 화면 설계만 하는 것입니다.

 

이 경우 스토리보드는 앱/웹의 문제가 있던 없던 화면 설계를 하는 데는 아무 문제가 없습니다. 문제는 코드와 데이터, 알고리즘에 있는 것이지, 화면에는 없기 때문입니다.

 

이런 기획의 화면은 그냥 디자인입니다. UI는 사용자가 앱 이용 시 확인하고 작동하는 것을 표현하는 것일 뿐, 작동 로직을 설명하는 것은 아닙니다. 단지 앱/웹 이용 시 확인할 수 있는 정적 화면을 론칭 전 표현한 것일 뿐입니다.

 

제가 참여한 어떤 프로젝트에서는 이렇게 해서 이전 버전의 앱과 신규 버전의 앱의 개발이 완료된 경우가 있었습니다. 그런데 이전 버전의 앱 사용자와 신규 버전 앱 버전 사용자 데이터는 연결되지 않아 기존 앱 사용자가 신규 앱을 다운로드한 경우 새로 회원 가입을 해야 했습니다. 당연히 기능이나 데이터는 기존 앱과 신규 앱이 따로 이루어졌습니다. 앱 이름만 같을 뿐 완전 다른 앱으로 서비스되고 있었습니다.        

 

기존 앱이 있는 상황에서 신규 버전의 앱은 같은 겉으로는 같은 앱인데, 실제 서비스는 같은 앱이라기보다는 완전 다른 앱처럼 운영되었습니다. 결국 이전 버전 앱 서비스를 중단하면 전부 새로운 버전 앱의 회원이 아니라 모두 탈퇴 처리되어 이전 앱과 신규 앱 2개를 운영하였습니다.  

 

 

문제가 있는 수 만 줄의 코드를 확인하면 수정하는 것이 맞을까?

 

개발자와 개발 막바지에 갑자기 문제가 발견되어 개발이 지연되는 경우를 이야기할 때가 있습니다. 이 경우 문제 코드를 찾기 힘들 때도 있다고 합니다. 이런 경우는 문제 코드를 수정하는 것보다 차라리 다시 새로 코딩하는 것이 더 빠르게 문제를 해결하는 방법이 될 수 있다는 이야기를 하기도 했습니다.

 

기획에서도 마찬가지라 생각합니다. 그런데 이전 앱/웹 시스템을 개발한 고객 또는 담당자 입장에서 이에 대한 미련을 버리기는 어렵습니다. 이를 심적 비용에 비유할 수 있습니다.

 

그리고 기획의 특성상 고객 담당자와 협의를 많이 해야 하므로, 담당자의 이 심적 비용감은 협의 시 표출되게 됩니다.

 

이런 이유로 아예 신규 기획하듯이 기획한다 해도 실제 작업 과정은 그렇지 않게 됩니다. 계약 기간과 개발자에게 기획서를 넘기기까지 시간을 줄이기 위해 고객 담당자 설득과 신규 설계를 함께 해야 합니다.

 

그렇기에 문제가 있는 앱/웹의 개선 기획은 때로 아예 신규 앱/웹을 기획하는 것보다 더 어려울 수 있습니다.

 

프로젝트를 하다 보면 무관심한 고객보다 지나치게 열정적인 고객이 매우 난이도 높은 프로젝트를 만든 사실을 알게 됩니다. 열정 많은 이들이 앱/웹 서비스 개발에 대해 잘 모를 경우 시기에 맞지 않는 쓸데없는 일들을 열정 때문에 너무 하게 되고, 이 작업은 기획/개발 작업의 흐름에 걸림돌이 되기도 합니다.

 

흔히 잘 모르는 사람이 열정을 가지면 일이 힘들어진다는 말이 여기서 나오는 것이라는 생각이 들 정도로 힘들어집니다. 

 

그런데 필요 없는 일을 열심히 한 정도가 아니라 1년 넘게 많은 비용을 들여 개발한 앱/웹에 대한 것이라면, 이에 대한 활용 또는 이용에 대한 압박은 더 클 것입니다.

 

이는 오히려 문제 해결에 걸림돌이 되기도 합니다. 버려야 앞으로 나갈 수 있는 상황임에도, 개발 기간과 비용에 대한 생각이 이를 어렵게 합니다. 즉 심적 비용감이 문제를 잡고 있어 개선을 어렵게 하는 것입니다.

 

때로는 문제 부분은 버리는 것이 문제 해결 방법이지만 사람의 마음은 이를 쉽게 허용하지 않습니다. 그래서 다른 앱/웹 서비스의 기존 사용자를 우리 앱/웹 서비스로 끌어 오는 것이 어려운 것이기는 합니다. 

 

이는 신규 가입자를 많이 모으는 서비스가 앱/웹 시장을 지배하는 것이 아닌 기존 사용자를 잘 관리하는 서비스가 앱/웹 시장을 지배하는 이유기도 합니다.