이 글은 글쓴이의 소유인 백산의 기술 블로그에서 발췌했습니다.
먼저 토이 프로젝트를 시작하기 전에 생각해야 하는 것부터 보도록 하겠습니다.
- 이 프로젝트에 포함될 기능을 필요로 하는 될 시장/유저층이 존재하는가?
- 나는 이 프로젝트를 통해 무엇을 얻고자 하는가?
- 프로젝트의 개발기간은 어느 정도로 잡을 것인가?
이 프로젝트에 포함될 기능을 필요로 하는 될 시장/유저층이 존재하는가?
간단하지만 가장 많이 놓치는 것들 중 하나입니다. 프로젝트를 시작하기 전에 먼저 이 서비스를 누가 사용할지 고민해봐야 합니다. 자기 생각에는 좋은 아이디어라고 생각하더라도 그러한 기능을 필요로 하는 사용자가 없거나, 같은 기능을 가진 서비스가 이미 시장에 존재 혹은 독점하고 있을 경우 아이디어를 바꾸거나 포기해야 합니다.
물론 토이 프로젝트는 어디까지나 자신의 즐거움과 실력 향상을 위해 만드는 것이기 때문에 반드시 이 조건을 만족시켜야 할 필요는 없습니다. 그렇지만 우리가 만든 서비스는 웹사이트나 앱스토어에 배포될 것이라 생각하고 이를 필요로 하는 사람들이 있는지 확인하는 것은 자신의 만족뿐만 아니라 경험적으로도 중요한 요소입니다. 열심히 만든 사이트/앱인데 아무도 사용하지 않고 몇 안 되는 사용자마저 필요하지 않다는 코멘트를 남기면 아쉽지 않을까요?
서비스를 개발하는 것만으로 실력은 크게 향상되지만 이를 운영하고 홍보하며 고객의 요청에 대응하며 피드백을 해가는 과정이야말로 토이 프로젝트의 묘미라고 할 수 있습니다. 서비스 사용자들과 함께 기능을 추가해가며 규모를 점점 키워가는 것은 생각보다 큰 성취감을 주기 때문에 이를 위해서라도 시장과 유저층을 조사하는 것은 중요합니다.
나는 이 프로젝트를 통해 무엇을 얻고자 하는가?
토이 프로젝트는 공부와 병행해가며 시간을 들여 진행해야 하는 일이기 때문에 프로젝트에서 얻는 것이 없다면 계속해나가기 어렵습니다. 자신의 포지션으로 참가해 실력을 늘린다던지, 취업을 대비해 포트폴리오를 만든다던지, 이직 시 자신의 능력을 어필하기 위해서라던지 등의 프로젝트에 참여하는 이유를 스스로 가지고 있지 않다면 끝까지 해내기 어려울 것입니다. 자신이 가지고 있는 능력의 최대한을 사용해 프로젝트를 진행해 나가기 위해서는 자신의 포지션(프론트엔드, 백엔드, 인프라)에 걸맞은 프로젝트를 선택해야만 하죠.
예를 들어 자신이 프론트엔드 개발만 가능하다고 가정해보겠습니다. 만약 토이 프로젝트로 웹 서비스를 개발해보고 싶다면 세 가지 방식이 있습니다.
- 팀을 꾸려서 자신이 부족한 부분(기획, 디자인, 백엔드, 인프라)을 채워줄 수 있는 사람을 구해 팀으로 프로젝트를 진행한다.
- 웹 서비스 프로젝트의 욕심을 내려놓고 정적 호스팅 등의 서버 쪽 지식이 필요하지 않은 프로젝트를 진행한다.
- 혼자서 디자인, 백엔드, 인프라 등을 공부해가며 프로젝트를 진행한다.
일반적으로 토이 프로젝트를 팀을 꾸려서 하는 경우는 (1)을 많이 따라갑니다. 자신이 부족한 부분을 다른 팀원들이 메워줄 수도 있고, 협업 경험도 쌓을 수 있으니까요. 슬랙이나 잔디 등 현업에서 사용되는 프로그램을 사용하면서 미리 익숙해질 수도 있고, git 등의 형상관리 툴을 사용하며 경험을 쌓을 기회가 됩니다.
(2)의 경우 자기 혼자서 프로젝트를 진행하고자 하는 경우입니다. 이 경우 웹 서비스를 개발하기 위해서는 필수로 필요한 지식인 백엔드와 인프라 쪽이 결여되어 있기 때문에 서버 개발이 필요 없는 프론트엔드 프로젝트를 진행하게 됩니다.
가장 간단하게는 투두 리스트부터 실수령액 계산기, 포트폴리오 사이트, 회사 랜딩 페이지 클론같이 서버 개발이 필요 없는 프로젝트를 할 수 있으며 오로지 자기 포지션(프론트엔드)에만 집중하면 되기 때문에 다른 기술을 익히느라 시간을 소모할 필요가 없습니다. 그래서 프로젝트의 기간을 짧게 가져가고(1개월 ~ 2개월가량) 계속해서 완성도를 높이고 고도화시키는 방향으로 갈 수 있죠. 하나의 완성된 프로젝트를 충분히 완성할 수 있다는 점에서 (2)도 좋은 방식입니다.
그리고 제가 가장 비추천하는 방식인 (3)입니다. 이 방식은 혼자서 풀 스택을 처리하며 모든 개발을 1인으로 개발하는 방식으로 공부해야 할 양이 제곱으로 늘어나게 됩니다. 프론트엔드뿐만 아니라 백엔드와 인프라까지 개발해야 하기 때문에 해당 포지션에 대한 지식을 습득하고 스택에 익숙해져야 합니다.
백엔드라면 mvc패턴과 프레임워크를 사용할 줄 알아야 하고 서버 스크립트 언어는 기본적으로 할 줄 알아야 하죠. 게다가 프론트와 백이 나누어진 mvvm패턴이라면 rest api에 익숙해야 하고 이를 위한 프레임워크, 서버 설정을 맞추고 postman 등의 툴에 익숙해지는데도 시간이 소요됩니다. 인프라는 클라우드 컴퓨팅을 사용해야 할 테고 이 과정에서 간단한 웹서버만을 오픈하기 위해서도 많은 시행착오를 거쳐야 하죠. 말만 토이 프로젝트지 실제로 작업해야 하는 분량과 시간은 전혀 토이스럽지 않게 돼버립니다.
무엇보다 (3)을 비추천하는 가장 큰 이유는 프로젝트 완성이 매우 어렵기 때문입니다. 처음부터 프로젝트의 규모를 CRUD 이하로 잡고 진행했다면 어느 정도 기능을 타협해가며 예정했던 기간 내에 개발이 가능한 데에 비해 (3)은 아예 모르는 포지션에 뛰어들어 처음부터 모든 걸 배우고 시행착오를 거치며 진행해야 하기 때문에 기간이 오버하는 것은 물론이고 한 군데에서 막혀버리면 프로젝트 완성이 불가능해지는 상황도 올 수 있습니다.
프로젝트란 완성되어 결과물이 나와야만 비로소 가치를 가지게 되는데, 혼자서 개발하다가 막혀서 프로젝트가 중단되면 그동안 투자한 시간은 물론이고 어디 가서 제대로 어필할만한 결과물조차 제대로 나오지 않습니다. 게다가 혼자서 모르는 분야를 잔뜩 공부하다 보면 금세 모티베이션이 떨어지기 마련이죠. 이로 인해 저는 (3)을 가장 추천하지 않습니다.
제가 이렇게 확실하게 추천하지 않는 방식을 말해드릴 수 있는 이유는 저 또한 123 방식을 전부 거쳐서 프로젝트 개발을 진행해봤기 때문입니다. 저의 경우 가장 비추천하는 방식인 (3)으로 웹서비스를 개발했었고 그 과정에서 후회와 고통을 겪었기 때문에 여러분한테 추천하지 않는 방법이라고 자신 있게 말할 수 있는 것이죠. 자신의 수준이 입문자 정도라면 (2)를, 어느 정도 포지션에 대한 지식과 이해도가 있다면 비슷한 수준의 사람들을 모아 (1) 번 방법을 채택하는 것이 현명하다고 생각합니다.
프로젝트 기간은 어느 정도로 잡을 것인가?
프로젝트에서 중요한 요소중 하나는 바로 기간입니다. 언제까지 프로젝트를 완성할 것인가를 먼저 정하고 개발 과정을 요소별로 나누고 마감일을 정하는 것이 일정표입니다. 이러한 일정표에 맞추어 개발을 진행해야 시간을 효율적으로 사용할 수 있고 시각적으로 진행률이 확실하게 보이기 때문에 어느 파트가 부족하게 진행되었는지, 어떻게 일정 조율을 해야 마감에 맞출 수 있을 것인지 등을 계획할 수 있습니다. 아래는 제가 프로젝트를 진행하면서 사용했던 개발 일정표의 양식입니다.
월별, 주별로 분기를 나누어 개발이 진행된 만큼 해당 포지션의 색 블록을 채워나가는 방식입니다. 양식 파일은 제가 직접 만든 것이기 때문에 자유롭게 사용하셔도 됩니다. 저의 경우 프로젝트 규모에 따라 다르지만 3개월 ~ 5개월 정도로 기간을 잡고 프로젝트를 진행했습니다.
마치며
이처럼 토이 프로젝트를 시작하기 전부터도 생각해야 할 것들이 굉장히 많습니다. 사람에 따라 일련의 과정이 불필요하다고 생각할 수도 있을지 모르겠지만 저는 제대로 프로젝트를 개발하고 완성시키기 위해서는 반드시 필요한 과정이라고 생각합니다. 이렇게 철저하게 계획하고 프로젝트를 진행해본 경험이 있다면 실무에서도 빨리 적응하고 더욱 넓은 시야를 가질 수 있게 될 테니까요. 다음 글에서는 프로젝트 개발을 위한 기술 스택에 대해서 써보겠습니다.
