개발을 배워야 비로소 보이는 것들

기획을 시작한 지 어느덧 2년. 

원래 컴퓨터공학을 전공했지만 학부 공부 이외의 것을 경험하지 못해 얕은 개발 지식만 알고 있었다.

그러다 개발을 직접 경험해보고 싶다는 생각에 Node js와 Sequelize를 공부하여 실제 서버 개발자로 작은 프로젝트를 경험하게 되었다.

이러한 경험을 하며 과연 기획자는 개발 지식을 얼마나 쌓아야 할까에 대한 문제를 끄적인다.

간단한 요청은

간단한 요청이 아니다.

서비스 기획 단계에서 아무리 꼼꼼하고 자세히 문서를 만들고 설계를 해도 놓치는 부분이 존재한다. 심지어 핵심 기능의 로직이 변경되거나 기능 자체가 변경되는 경우도 생긴다. 이것의 원인에는 여러 가지가 있지만, 서비스는 생각보다 복잡하며 수많은 예외 처리가 이루어 지기 때문에 개발에 들어가면 이전에 보이지 않은 오류들이 보이기 때문이다. 그러나 이를 개발자 입장으로 생각해보면 반갑지 않은 소식들이다. 이러한 수정 요청들이 그동안 짜 놓은 코드를 뒤엎고 새로 짜야할 수도 있기 때문이다.

예를 들어 우리가 건물을 짓는다고 생각하자.

건축가가 건축물을 설계한 후(기획자) 이러한 설계를 바탕으로 사람들이 건물을 짓고 있을 때(개발자), 예상치 못한 결함이 있어 건축가가 다음의 요청을 한다. 

"지금 지어지고 있는 건물이 너무 좋은데, 죄송한데 건물 위치를 옆으로 3cm만 옮겨주세요ㅎㅎ. 

어려운 거 아니죠? 30cm도 아니고 3cm잖아요! ㅎㅎ"  

약간의 과장이 섞인 예시지만, 기획자가 요청하는 수정 사항 혹은 기능들이 때로는 서비스 전체의 로직이 바뀌는 치명적인 것이 되기도 한다. 나아가 그동안 개발자가 짜 놓은 코드 전체가 수정되는 일이 일어날 수도 있는데, 실제로 주변에서 가끔 이러한 문제들이 발생해 팀 내에 갈등이 생기는 등 원활한 협업이 이뤄지지 못하는 경우가 발생한다. 

따라서 기획자가 개발자로 일해보면 가질 수 있는 강점은,

기획을 하는 과정에서 개발을 고려한 서비스 설계가 이루어진다는 장점이 생긴다. 기획자는 좋은 고객 경험을 제공하기 위해, 여러 기능을 추가하거나 수정하는데 개발적인 요소를 고려 안 하는 경우가 많다. 그러나 개발 베이스의 기획자의 경우, 구현 가능성을 고려하며 현실적으로 기능 구현이 가능한지를 판단하여 설계할 수 있다.

정해진 일정에 따른

개발 범위 선정이 가능하다.

대부분의 프로젝트는 일정이 존재한다. 이러한 일정이 정해진 프로젝트들에 대해 기획자 혼자 기능 범위와 우선순위 설정하는 것은 어려운 일이다. 

정해진 기간 내에 개발자들이 어느 정도까지 끝낼 수 있을지에 대한 경험이 부족할 뿐만 아니라 범위를 선정했다고 해도 막상 개발에 들어가 보면 이를 다시 수정해야 하는 경우가 빈번하다. 

이러한 경우, 개발에 들어갔을 때 범위와 기능을 수정하는데 시간이 많이 들기 때문에 효율적인 프로젝트 일정 관리에 문제가 생긴다. 

그러나 개발 지식을 갖춘 기획자의 경우, 이러한 범위 선정에 강점을 갖는다.

물론 개발자별로 능력치가 다르기 때문에 범위를 정확히 정할 수는 없지만, 변경되는 일정과 우선순위 그리고 기능들을 최소화할 수 있다는 장점이 있다. 

이러한 요소들이 중요한 이유는, 

우리가 진행되는 대부분의 프로젝트는 정해진 마감 기한이 정해져 있으며 마일스톤을 향해 달려가기 때문이다. 따라서 개발을 경험해본 기획자라면 이러한 것들을 잡는데 큰 강점을 가질 수 있다.

생기는 이슈들을

함께 고민할 수 있다.

개발에 들어가면 예상치 못한 이슈들이 많이 생긴다.

이러한 이슈들은 기능 자체를 바꿔야 하는 것일 수도 혹은 구현이 어려워 다른 대체 기능을 생각해야 하는 경우 등 다양한 것들이 있는데,  이러한 이슈들에 대해 개발자들과 함께 고민할 수 있다.

필자가 개발 지식이 없을 때 기획자로 진행한 프로젝트를 생각해보면, 

개발 이슈가 있어 우선순위를 미뤘던 기능이 있었는데 나중에 보니 이 기능에 대한 개발이 진행되지 않아 또 다른 영역에서 이슈가 생긴 경험이 있었다. 개발자들도 여러 기능들을 구현하다 보니, 디테일한 요소들을 놓치기 쉬운데 어느 정도 개발 경험이 있는 기획자의 경우 여기서 발생하는 리스크 파악에 용이하며 대체 기능에 대해 함께 고민해 나갈 수 있다. 

사실 기획자는 고객에게 좋은 경험을 주기 위해 이를 고민하고 서비스에 녹여내는 역할을 하는데, 이러한 개발 이슈들에 대해 고객 경험에서 가장 중요한 요소들을 뽑아내 결정을 내릴 수 있어야 하기 때문에 개발 지식이 중요한 역할을 할 경우가 생긴다.

더 자세하고 디테일한
문서 작성이 가능하다.

기획자가 만드는 산출물들이 있다. 

프로젝트의 특성마다 다르겠지만 IA, 와이어프레임, 스토리보드 등 서비스 설계에는 전반적으로 문서화 작업을 진행한다. 그런데 생각해보면, 이러한 문서들이 개발자의 손에 들어갔을 때 어떤 것들을 보고 개발을 하는지 모르는 경우가 많다. 그러나 기획자가 개발자로 직접 프로젝트를 경험하면 이러한 문서화 작업에서 어떤 부분들이 중요하며 기능에 대한 디테일한 설명이 가능해진다.

필자의 경우, 

IA 설계서를 작성할 때 각 화면의 네이밍 및 기능에 대한 설명, 우선순위를 선정하여 이를 문서로 옮겼는데 막상 이러한 문서에서 서버 개발자가 필요한 것은 각 페이지별 필요한 정보들이었다. 

이 화면에서는 사용자의 이름과 나이, 성별이 들어가고... 이러한 정보들이 있어야 데이터 베이스를 설계하는데 수월하며 n:m관계를 미리 파악할 수 있기 때문이다. 

특히 스토리보드의 경우, 개발을 경험했을 경우 더욱더 유용한데 각 기능에 대해 설명할 때 개발자 입장에서 필요한 내용들을 더 직관적이고 자세히 설명할 수 있으며 예외 처리들을 사전에 잡아줄 수 있기 때문에 매우 유용하다. 스토리보드는 개발자들이 가장 많이 보고 이를 토대로 개발하기 때문에 사소한 실수나 놓친 서술이 개발을 진행하는데 큰 영향을 주기 때문에 특히 중요하다.

개발을 하면 보이는 시야가 달라진다.

개발을 모르고 기획할 때와 알 때 그 차이는 명확하다. 

우선 위 내용들처럼 개발자와 커뮤니케이션하는데 있어 어느 정도 지식을 갖췄기 때문에 더 수월하며 어려운 지점들을 함께 고민해 나갈 수 있다. 또한 개발에 들어가서 생가는 기능적인 이슈들을 고민하고 해결해 줄 수 있다는 장점들이 있다. 개발을 모른다고 해서 기획을 못한다는 말은 아니다. 다만 개발에 대한 경험치가 있을 경우 기회의 시야가 달라지고 여러 커뮤니케이션의 이점이 있다.

개인적인 생각이지만, 

기획자가 서비스를 만들 때 우리 제품에는 어떤 기술 스택이 사용되었으며 기술적인 이점이 어떤 것인지 아는 것이 중요하다고 생각하다. 어렵겠지만 기획자가 개발을 경험해 보는 것을 추천한다.