화면 설계만으로는 왜 앱/웹을 개발하기 어려울까

개인적인 경험으로 문제가 생긴 앱/웹 개발 프로젝트를 보면 기획에서 화면 설계만 있는 경우가 많습니다. 물론 모든 문제를 화면 설계 때문으로 돌릴 수는 없습니다. 화면 설계에 추가되는 설계가 없었기 때문입니다. 이를 기획자 책임이라 할 수는 없지만, 부족한 설계를 관리하는 부분에서의 문제는 기획의 부실이라 할 수는 있습니다.

 

 

앱/웹 설계 그리고 화면 설계

 

앱/웹을 개발하기 위한 설계는 크게 화면 부분과 서버 부분으로 구분하여 볼 수 있습니다. 그리고 이 두 설계가 연동될 수 있어야 비로소 작동되는 앱/웹을 개발할 수 있게 됩니다.

 

이점에서 화면 설계는 화면 부분에 대한 설계라 할 수 있습니다.

 

앱/웹의 개발에 대해 잘 모르는 고객 입장에서 확인할 수 있는 모습이 있는 화면만 있으면 앱/웹이 개발되었다 생각할 수도 있습니다. 그러나 이런 앱/웹의 작동을 기대하기는 어렵다는 것은 개발자면 알고 있습니다.

 

앱/웹 개발 분야를 세분화하여 보면 화면 설계는 코딩보다는 디자인 작업 지향 설계라 볼 수도 있습니다. 때문에 화면 설계를 기반으로 디자인 작업량을 파악하기는 쉬워도, 코딩 작업량을 파악하기 어려운 경우도 있습니다.

 

그리고 프로그램 지식이 부족한 고객 입장에서 알 수 없는 문자만 있는 코딩보다, 이미지로 되어 있는 디자인은 이해되기 쉽습니다. 그리고 내부 보고에도 유용합니다.

 

그러나 앱/웹 화면은 서버의 작동을 통해 피드백을 받았을 때만 사용자의 앱/웹에 대한 요구를 해결할 수 있습니다. 

 

이점에서 앱/웹 설계가 개발 관점에서 의미가 있기 위해서는 화면 설계와 서버에서의 작동 설계가 함께 유기적으로 이루어져야 하는 것입니다.

 

 

기획자의 한계

 

전통적인 앱/웹 개발 프로젝트는 프로그래머, 디자이너, 기획자 외에도 PM, PL, PMO가 존재합니다.

 

그리고 실질적인 기획 업무는 주로 PM, PL이 담당합니다. 앱/웹 개발 프로젝트 전체의 기획과 관리는 PM, 각 파트별 기획 및 관리는 각 파트 PL이 담당합니다.     

 

이러한 역할 구성에서 기획자는 기획에서의 한계를 가지게 됩니다.

 

그리고 앱/웹 개발 프로젝트 팀의 구성에 따라 부여된 형식적인 업무를 부여받게 됩니다. 이는 기획 본질에 대한 업무라기보다는 개발 프로젝트에 투입된 기획자로 명명된 인력이 해야 하는 업무로 주어진 일에 대한 처리를 의미합니다.

 

이러한 현상은 일종의 친구 관계와 회사 그리고 집에서 각 개인에게 주어지는 역할 행동의 차이와 비슷한 것입니다.

 

인위적으로 구성된 팀에서 네이밍 되고 구분되는 각각의 역할이 존재합니다. 인위적으로 구성된 팀에 참가하는 인력은 그 프로젝트를 위해 조직된 R&R(역할과 책임)에 따라 작업을 해야 합니다.

 

이러한 앱/웹 개발이라는 목표를 달성하기 위한 조직 설계 또한 기획 영역이기에, 프로젝트에 참여하는 기획자는 큰 기획의 설계 안의 일정 부분을 담당하는 기획자라 볼 수도 있는 것입니다.

 

이는 앱/웹 개발 프로젝트에 기획자라는 인력은 분명 존재하지만, 실질적으로는 전체 프로젝트 설계에 의해 실질적인 기획 업무에서는 제한을 받게 되는 것입니다.

 

 

그럼 기획자는 왜 화면 설계를 하는가

 

이는 앱/웹 개발을 위한 기획 관점이 아니라, 해당 개발 프로젝트가 운영되기 위한 팀 구성 인력으로의 담당 역할의 의미로 접근해야 합니다.

 

앱/웹 개발 프로젝트 팀은 지정된 기간과 예산하에서 특정 앱/웹 개발이라는 분명한 목표를 위해 일시적으로 구성된 팀입니다. 이 개발 팀은 앱/웹 개발이 끝나면 해체됩니다.

 

그리고 앱/웹 개발이 끝나야 해당 앱/웹 개발에 배정된 모든 비용을 받을 수 있게 됩니다. 이러한 개발 계약은 또 다른 기획자에 의해 설계됩니다. 그리고 온전한 앱/웹 개발의 진행을 위해 단계별 확인과 이에 따른 비용 지불이 이루어지기도 합니다.

 

개발 과정이 제대로 되고 있는지에 대한 평가는 중도금 지급에 핵심입니다. 그런데 앞서 언급했듯이 고객은 코딩 내용을 잘 알지 못합니다. 코딩 내용을 예산 지급 품의에 넣는다면 아마 욕을 먹을 것입니다. 무언가 분명하고, 개발을 잘 알지 못하더라도 개발 결과를 직관적으로 파악할 수 있는 문서가 필요합니다.

 

냉정히 보았을 때 화면 설계의 가장 큰 역할을 바로 여기에 있다고 해도 틀리지 않습니다.

 

기획 경력이 오래되었고, 다양한 프로젝트에서 기획을 했으므로 종종 진행되고 있는 개발의 기획 내용을 검토해 달라는 요구를 받고는 합니다. 앱/웹 개발 영역에 있어서도 사업 기획부터, 서비스 기획, 자체 개발 기획, 외주 개발 기획 등 다양한 역할을 했기에 이러한 요구를 받을 때가 있습니다.

 

그래서 프로젝트 설계를 분석해 보면 화면 설계 외에 설계가 없는 경우가 대부분입니다. 그러다 보니 앱/웹이 껍질만 있고 뼈와 근육, 장기, 혈관 등이 없는 박제의 모습인 상황입니다. 

 

이러한 앱/웹 설계로 시작할 경우 프로젝트 초기에는 문제가 없지만, 개발 기간이 진행될수록 문제가 생기기 시작합니다. 그리고 시간이 지나면 지날수록 문제는 커지게 됩니다.

 

더 큰 프로젝트 문제는 시간이 지나야 문제가 크다는 것을 인식하게 되지만, 또 시간은 프로젝트 예산을 소비하다면 것입니다. 그래서 앱/웹 개발 프로젝트 팀은 문제를 인식했을 때 역량 높은 기획/설계자를 투입해 문제를 풀어야 하지만 이미 예산은 사용했고, 개발 완료 기간은 얼마 남지 않은 상태가 되어 그럴 수 없게 됩니다. 

     

이 문제를 화면 설계 때문이라 할 수는 없습니다. 본질적인 문제는 앱/웹 프로젝트 기획 자체가 부족했기 때문입니다. 화면 설계는 단지 이러한 부실한 프로젝트 설계에서 업무를 지정받은 죄 밖에 없습니다.