서비스개발을 위한 앱/웹 기획 잘하는 법

앱과 앱 개발을 위한 기획 방법이라고 이론적으로 정해진 것이 있는 것은 아닙니다. 이 글의 내용은 그동안 개발 프로젝트 경험을 통해 개인적으로 이렇게 기획하면 더 효과적이라 논리적으로 생각해 본 내용을 적은 것입니다.

 

간단하게 생각나는대로 그려 보았습니다.

 

가장 기본은 액션(요청)과 응답을 이해하는 것 입니다. 사용자가 원하는 액션을 할 경우 그것이 올바른 액션인지, 올바르다면 원하는 페이지나 처리를 한 결과를 보여주는 것이 가장 기본입니다.

 

이러한 기본을 가지고 화면설계를 하면서 작동이 될수 있는 화면설계를 위한 구성요소(서버, 데이터 조회/등록/수정/삭제)들이 움직이는 방식을 생각하여 추가 해 주는 것입니다.

 

이러한 기본사항으로부터 출발하면 서비스 개발 시 왜 기획을 하는가에 대한 정의는 세부적으로는 다를 수 있습니다.

사용자가 앱/웹을 이용하기 위해서는 작동을 해야 합니다. 편리한 UI나 세련된 디자인도 작동하지 않는다면 의미가 없습니다. 이 때문에 개발 기획은 작동을 전제로 편리한 기능, 구성, 트렌디 한 디자인 등을 해야 한다는 점은 그 전에 근본적으로 개발이 우선이라는 전제라 할 수 있습니다.

 

사용자와 직접적으로 만나는 앱/웹의 부분은 화면입니다. 그러나 사용자가 화면의 UI를 작동할 때 서버와 DB를 통해 요청한 데이터가 쿼리되어 디자인된 페이지에 포장되어 표현되는 작업이 이루어지지 않는다면 사용자는 그냥 스마트폰이나 PC 화면에 있는 그림을 터치하는 것과 다를 것이 없을 것입니다. 움직인다 해도 서버나 DB가 작동하지 않는다면 HTML로 만들어진 단순 링크 이동 정도로만 사용자는 느끼게 될 것입니다.

 

따라서 기획이 앱/웹을 사용자가 이용할 수 있게 하기 위한 것이라 가정한다면, 화면과 서버, DB에 대한 고려는 기획자가 해야할 기획업무에 모두 포함되어 있다는 전제를 가지고 기획을 해야 합니다.

 

많은 앱/웹 서비스 개발 현장을 보면 기획자는 화면을 설계하는 것이라고 합니다. 그리고 기획자의 작업물은 디자이너에 의해 앱/웹 화면으로 나옵니다. 그런데 이게 다가 아니라는 것입니다.

 

기획자들이 힘들어 하고 실수하는 문제는 앞서 앱/웹 개발을 위한 기획이 사용자가 앱/웹을 이용할 수 있는 작동하는 앱/웹을 개발하기 위한 것이어야 하는데 그렇지 못한 설계서가 많습니다. 애초부터 디자인을 위한 설계라던지, 기능 작동 흐름이 중간에 떠버리는 설계가 대표적이지요.

 

그럼 사용자가 이용하는 앱/웹 화면을 작동하는 기획은 누가 할까요? 물론 작동을 위한 프로그램 설계는 개발자가 해야 합니다. 그러나 그 프로그램 설계 및 코딩을 위한 서비스설계는 기획자가 제공을 해 줘야 합니다. 개발자는 단순히 코드와 코드 간 설계를 의미하지 사용자가 화면을 클릭했을 때 어떤 반응이 있어야 하는지에 대해 관점 포인트가 있기 때문입니다. 때로는 화면에 보이는 콘텐츠를 위해서 저장할 데이터와 노출 규칙이 필요할 수도 있습니다. 가령 년월일 표시방법이나 글자입력수 등.. 이는 앱/웹의 작동과 연결됩니다.

즉 기획자는 서비스의 목적을 가진 서비스관점의 화면설계를 하여야 하고 이 설계는 요청과 응답들이 모이는 서비스 시작과 끝을 상세화면설계에 포함 해야 합니다.

 

 

 

기획자 역량 형성

 

기획자마다 다를 수 있겠지만, 저는 다양한 기획 경험을 통해 반복과 추론의 상호작용을 통해 기획 역량이 형성된다 생각합니다. 반복은 경험이지요. 그리고 추론은 경험과 다른 호기심, 실험과 같은 것입니다.

경험은 기회자를 만드는 매우 중요한 요소 중 하나가 맞습니다. 하지만, 10년이상의 기획자나 20년이상의 기획자는 사실 큰 차이가 없습니다.

 

그러면 차이는 어디서 생길까요?

 

저는 이부분을 가정, 추론이라고 생각 합니다. 벤치마킹을 통해 더 나은 서비스를 할 수 있는 가정, 벤치마킹해도 없지만 요건을 채우기 위해 시스템화 요건을 구성하는 서비스플로우 추론. 이것이 역량의 차이를 발생시킨다고 생각 합니다.

 

결국 앞으로 기획자는 과거 경험, 학습을 통해 축적한 정보를 조합하고, 변형하여 새로운 개념과 논리를 만들어 낼 수 있는 가정해보고 추론해볼수 있는 능력이 있어야 인정받을 수 있을 것입니다.

 

그러면 왜 과거 경험을 중시하는가라는 질문을 하실수도 있지요. 현재까지도 기획자의 레벨은 경력의 기간에 준하여 평가되고 있습니다. 하지만 지금까지 앱/웹 서비스 개발은 벤치마킹하고 레퍼런스를 기반하여 베끼는 수준이었기 때문입니다.

 

개발을 예시로 들어볼까요? 몆년전 까지만 해도 자신 가지고 있는 코드가 많은 개발자가 레벨이 높았습니다. 이미 테스트라는 절차를 거친 가지고 있는 코드로 개발을 하면 빠르고 에러 가능성도 낮고 속도도 빠르도록 최적화 되었기 때문입니다. 하지만, 지금은 오히려 구글 검색이 더 유용합니다. 깃허브 등의 동일한 검증과 의견까지 조합된 오픈소스 코드들의 활용을 편하게 하는 플랫폼들이 점점 늘어가고 있기 때문입니다.

 

기획도 비슷한 흐름이 이루어질 것이라 생각합니다. 베끼기식 레퍼런스 기반 기획의 문제점은 앱/웹 서비스의 최적화가 아니기에 투입자원대비 매출 실현도가 매우 낮다는 것입니다. 그리고 비즈니스면에서 볼때 서비스 실패 가능성도 매우 높아지기 때문입니다.

 

결론

사용자의 앱/웹 서비스 경험을 위한 서비스 기획은 유자와 서버 및 데이터 영역이 조화를 이루어 작동이 되는 기획 이어야 합니다. 이러한 기능작동 서비스 기준이 아닌 단순 화면을 위한 레퍼런스 기획은 많은 위험요소를 가지고 있습니다.