서비스 기획자가 되기 위한 개발 지식?
서비스를 기획하는 사람이 서비스 자체가 어떻게 만들어지는 모른다면
서비스 기획자가 되기 위해서 개발을 얼마나 알아야 할까? 아마 서비스 기획자를 직업으로 생각한다면 한 번쯤 하게 되는 질문이다. 오늘은 이 질문에 대해 스스로 답해보고자 한다.
내가 취업 시장에 뛰어들고 처음 하고 싶었던 직무는 서비스 기획자였다. 하지만, 개발을 모르는데 어떻게 기획을 하나라는 스스로의 물음에 답하지 못하고 그저 저버렸다. 하지만 시간이 지나고 우연찮게 개발을 배우고 기획자가 되었다는 건 참 아니러니 하고 알 수 없는 인생이라는 생각이 든다. 앞으로 내용은 메인 기획자로 처음 프로젝트를 마치고 느낀 점처럼 써 내려가는 글로 위 질문을 중점으로 주관적인 답을 내려보고자 한다. 사실 기획자는 정말 어디에 포커스를 두느냐에 따라서 정말 다른 일을 할 수 있기 때문에 기획자마다 그 답은 달라질 수 있다고 생각한다. 그러니 혹 이 글을 읽는 사람은 이 내용은 여러 가지 답들 중 하나의 답임을 이해하고 글로 들어가길 바란다.
그럼 원초적인 질문부터 시작해 보자. 서비스 기획자는 개발 지식이 필요할까? 그 답은 너무나 당연하게도 '그렇다'이다. 웹 서비스를 만드는 일은 건물을 짓는 일에 비유되곤 한다. 과연 건물의 설계를 맡은 사람이 건물이 어떤 구조로 이루어지고 어떤 재료로 만들어지는 모른다면 제대로 된 건물을 설계할 수 있을까? 아마 부실 공사 혹은 공사 이 전에 누군가에게 이렇게는 못 짓는다고 이야기를 들을 가능성이 농후하다(개발자: 이렇게 개발 못해요!). 웹 서비스도 그렇다. 인터넷 세상이 어떻게 되어있지 모르는 채, 종전의 건설 비유처럼 이 땅이 건물을 지을 수 있는 땅인지 모르는 채 건물을 짓는 것은 어불성설이다.
그럼 이제야 본래의 질문을 던질 수 있다. 그럼 얼마큼 알아야 할까? 나는 본인이 웹서비스를 만들 만큼 알아야 한다고 생각한다. 이 말의 궁극적인 의미는 서비스의 복잡도를 떠나서 개발에서 서비스를 만드는 프로세스를 겪어보라는 의미이다. 그 과정 속에서 개발할 때 고려하는 요소들을 학습하고 고민들을 직접 겪어보면 자연스럽게 서비스 기획에 한 걸음 다가설 수 있다. 시중에 개발 기본 강의 하나를 완파하는 것을 추천한다. 나 같은 경우 노마드 코더에서 유튜브 클론코딩을 들었고 이 정도의 수준의 강의를 권한다. 이 정도라 함은 백엔드로 비즈니스 코드를 짜고 프런트엔드로 UI를 그리고 간단한 인터렉션을 구현하며 DB를 붙여 통신까지 하는 것이다.
물론 이에 반론을 낼 수 있다. 서비스를 직접 만들 거면 본인이 직접 개발하면 되지 않나요? 그런 지식은 개발자가 알아서 해야 하는 것 아닌가요?라고 말이다. 거기에 대한 나의 답은 내가 말한 것들은 개발의 기본의 기본이며 실제 개발자들은 더 깊은 고민을 하는 일을 하고 있음을 알려주고 싶다. 예를 들어, 언어 자체의 특징에 대해서 공부하고 수많은 이미지들을 어떻게 빠르게 노출할지 혹은 수많은 데이터들을 어떻게 효율적으로 찾고 로드할지 말이다.
이 과정을 겪어야 하는 근본적인 이유는 HTTP을 이해하기 위해서이다. 우리가 웹서비스를 이해하기 위해서는 큰 밑그림을 그려야 하는데 이 그림 속에서 중요한 것이 데이터인데 이 데이터를 주고받는 클라이언트와 서버의 관계를 알기 위해서이다. 그럼 HTTP는 무엇일까?
아래는 f-lab에서 제공하는 정의이다.
HTTP(HyperText Transfer Protocol)는 웹에서 정보를 주고받을 수 있는 프로토콜입니다. 왜냐하면 웹 페이지를 요청하고 전송받기 위한 기본적인 방법을 제공하기 때문입니다.
HTTP는 클라이언트와 서버 간의 통신을 가능하게 합니다. 사용자가 웹 브라우저를 통해 웹 페이지를 요청하면, 브라우저(클라이언트)는 해당 요청을 서버에 전송하고, 서버는 요청받은 웹 페이지를 클라이언트에게 전송합니다.
물론 정확하게 HTTP가 무엇인지 알면 좋겠지만 프로토콜을 검색하면서 수많은 개발 용어들이 마주하면 일찍이 포기하고 싶을 것이다. 이 글에서는 대략적인 그림을 그리도록 돕기 위해 비유를 통해서 설명하고자 한다.
우리는 하나의 모니터 화면에서 여러 페이지를 이동하며 별생각 없이 인터넷 세상 속을 누빈다. 로그인을 하면 어떤 또 다른 세상으로 이동한다고 생각할지도 모르겠다. 사실 이 생각은 내가 개발을 배우기 전에 실제 했던 생각이다. 실상은 우리는 기획자가 기획해 놓은 화면을 보고 있을 뿐이다. 처음에 들어오면 이 화면이 뜨고 로그인을 하면 이 화면, 이 버튼을 누르면 이 화면, 각각 설정해 놓은 화면을 우리는 보고 있는 것이다. 그리고 그 화면은 사실 수많은 네모 박스들로 구성되어 있으며 그 안에 채워진 데이터(글 혹은 이미지)가 노출되어 우리가 보고 있는 화면이 완성된다. 물론 데이터들과 네모 박스는 잘 디자인되어 보기 좋은 형태로 나타내어진다.
내가 주목하고 싶은 것은 데이터(글, 이미지)이다. 이 데이터는 도대체 어디서 오는 것일까? 이 것을 이해하기 위해서 HTTP을 알아야 한다. 우리는 웹 서비스를 이용하는 입장으로 클라이언트라고 부른다. 말 그대로 손님입장이다. 브런치를 예로 든다면 클라이언트는 브런치에 방문한 손님이다. 그럼 자연스럽게 브런치는 호스트, 즉 주인장이다. 개발에서는 이를 서버라고 부른다. 클라이언트와 서버는 통신을 통해서 데이터를 주고받는데 이러한 방식 혹은 규칙을 HTTP라고 부른다.
더 구체적인 예로 우리가 브런치에서 쓴 글이 어떻게 저장하고 불러오는 과정을 살펴보자. 우리는 클라이언트로서 글을 쓰고 저장 버튼을 눌러 글을 저장한다. 저장을 누르는 순간 우리의 글은 데이터로서 서버에게 전송된다. 서버는 클라이언트가 보낸 데이터를 데이터 베이스에 저장한다. 데이터 베이스는 거대한 엑셀 파일이라고 생각하면 이해하기 쉽다. 엑셀에서 우리가 첫 줄에 이름을 넣고 그 아래 데이터를 넣는데 서버가 하는 일이 미리 지정된 이름에 클라이언트가 전송한 데이터를 넣는 것이다. 이 경우에는 제목, 글이라는 이름이 있고 그 아래 클라이언트가 보낸 제목과 글을 저장하는 것이다. 그리고 유저는 글을 수정하기위해 작가의 서랍장에서 글을 다시 클릭하여 다시 쓰고자 한다면 서버는 저장된 데이터를 다시 클라이언트에게 보내주어 우리가 글을 수정하는 곳에 이전에 저장한 글과 제목 데이터가 노출된다. 모든 웹서비스는 이 과정이 동일하게 이루어진다. 정리하자면 클라이언트는 화면을 이동하면서 데이터를 요청(버튼을 누르거나 페이지를 이동하는 행위)하고 이에 따라서 서버는 그에 맞는 데이터를 보내준다.
정말 간단하게 HTTP에 대해서 알아보았다. 이 것을 안다고 서비스 기획을 잘하거나 그렇지는 않다. 기획은 이 내용 이 외에도 정말 다양한 분야의 지식이 접목된 일이라고 생각하기 때문이다. 하지만, 적어도 내가 만드는 서비스가 어떻게 돌아가는지 그림을 그려볼 수 있고 개발자와의 커뮤니케이션을 하기 위한 단계에 한 걸음 다가섰다고 할 수 있다. 내가 프로젝트를 진행하면서 가장 크게 느낀 것은 개발 지식이 아예 없었다면 어땠을까였기에 더더욱 이 내용을 강조하고 싶었다. 이 내용을 필두로 앞으로 기획에서 필요했던 것들을 정리가자라는 마음을 먹으며 이 글을 마무리하고자한다.
