Diary 프로젝트 일기 (1) - 동기

 한 때 새티스팩토리와  팩토리오라는 게임을 아주 열심히 했던 적이 있다. 둘 다 굉장히 복잡하고 광활한 공장을 짓는 게임인데, 친구하고 내 홈서버에 게임 서버를 올리고 같이 멀티플레이를 했던 즐거운 기억이 있다. 그렇게 복잡한 게임을 처음 시작하면 어디서부터 시작해야 할지 감이 오지 않는다. 저 돌을 먼저 캐야할까? 저 석탄을 먼저 캐야할까? 정찰을 먼저 해야할까? 

새티스팩토리 스크린샷

 어느 정도 완성된 게임 속 공장의 사진이다. 뭐가 뭔지 알아보기 힘들지 않은가? 마치 아랍어로 쓰인 글을 본 것 같은 이런 경험을 나는 '까만건 글씨요, 하얀건 종이로다' 상태라고 부르곤 한다. 

 림월드라는 게임을 만든 게임개발자 타이난 실베스터는 자신의 책 '게임 기획의 정석'에서 이러한 상태가 발생하는 이유가 정보의 과잉 때문이라고 했다. 너무 많은 정보가 물밀듯이 쏟아지니 양에 압도되어 세부사항을 무시할 수 밖에 없고 전체적인 특징만 눈에 들어온다는 것이다. 아랍어 글을 처음 본 내가 그 세부사항들을 알아차리지 못하고 단지 색깔이라는 특징만 인지할 수 있었던 것과 같다. 

 팩토리오와 같은 공장 게임을 처음 시작하면 굉장히 많은 정보가 유저를 압도한다. 지나친 정보의 문제는 많은 정보의 양이 정보의 질을 낮춘다는 것이다. 어떤 정보에 집중해야 할 지 모르는 사람은 모든 정보를 비슷한 수준으로 다룬다. 정보가 더욱 많아지면 정보의 질의 합은 사용 가능한 인지적 자원의 합과 같아질 것이다. 다시 말하면 이 때 정보 하나의 질은 단순히 1/n이 된다. 중요한 정보는 평가절하되고 무의미한 정보는 과대평가된다. 

 이런 게임을 시작하는 가장 좋은 방법은 일단 뭐든 해보고, 하다가 막히면 재시작하는 것이다. 석탄을 일단 캐보라. 전기를 생산하는데 들어간다는 것을 알아냈다. 전기를 생산하려면 석탄뿐만 아니라 물도 필요하다는 것을 알게되었다. 터빈을 돌려야 하기 때문이다. 물을 끌어오려면 파이프가 필요하고, 파이프를 만드려면 철이 필요하다는 것을 깨달았다. 석탄으로 전기를 생산하려 했지만 결국 철이 없어서 목표를 달성하지 못했다.

 이제 다시 시작해보자. 무엇보다 초기 목표가 전기 생산이라는 점을 알고 있다. 전기를 위해서는 석탄이 필요하지만 얻기 쉽고, 여기에 더해 철이 필요하다는 사실을 안다. 따라서 나는 석탄이 아니라 철을 먼저 캐기 시작한다. 파이프를 만들고 호수에 연결한다. 이제 석탄을 캐고 보일러에 넣는다. 증기는 터빈을 돌리고 전기가 만들어진다. 목표를 달성했다! 

 이러한 '맨 땅에 헤딩-배움-재시작-달성' 프로세스는 게임이 끝날 때까지 반복된다. 초반과 후반의 차이점이라면 후반으로 갈수록 재시작의 부담이 커지면서 동시에 인프라가 충분하기에 완전한 재시작의 필요성이 줄어든다는 점이 있다. 후반에는 전체 공장의 작은 부분만 지우고 다시 건설하면 그만이다. 나머지는 이미 잘 돌아가고 있을 것이기 때문이다. 이미 팩토리오를 몇 백시간 해본 입장에서 완전히 처음 시작하는 내 친구를 보며 이 '헤딩-배움-재시작-달성' 프로세스를 정립할 수 있었다. 

 이 프로세스가 의미있는 이유는 무엇일까? 이 프로세스는 지나치게 많은 정보의 양을 강제로 줄인다. 다시 말하자면 임의의 정보의 중요성을 강제로 끌어올리는 휴리스틱을 사용하는 것이다. 그 이후에는 그 정보를 따라 흘러갈 뿐이다. 그리고 유저는 어떤 목표를 달성하였고 할 수 있는지 끊임없이 평가한다. 석탄을 먼저 캔 성과는 석탄을 얻었다는 것이고, 석탄이 전기 생산에 쓰일 수 있다는 것을 알았다는 것이다. 

유저는 사실 관대한 최단거리 찾기 게임을 하고 있다.

 컴퓨터공학과에게 익숙한 단어들로 설명하면, 유저는 갈 수 있는 수 만개의 경로 중 하나를 임의로 선택한 것이다. 그 길은 대부분 만족스럽지 않아 처음으로 다시 돌아올 것이다. 석탄을 먼저 캔 것만으로는 전기를 생산하기 어려워 다시 시작한 유저처럼. 그러나 이번엔 알고 있는 것이 있다. '철을 먼저 캔다'가 적힌 바로 옆의 길은 아까 전의 길보다 훨씬 짧다는 것이다. 이제 새로 시작한 유저는 그 짧은 길로 가기 시작한다. 자기도 모르게 목표 달성을 위한 그리디 알고리즘을 사용하고 있다. 

 그리디가 최적해를 보장하지는 않지만 이 경우에는 유저 경험 내의 최적해를 보장한다. 더 나은 방법이 있다면 추후에 우연찮게 알게되거나 커뮤니티에서 알게되고는 한다. 친구가 전기를 생산한 후, 그걸 보다못한 내가 전기보다 컨베이어 벨트를 먼저 만들어야 한다고 훈수하는 것처럼 말이다. 그럼에도 불구하고 유저는 이제 새 게임을 시작했을 때 어떤 정보에 집중해야 하는지 알게되었다. 유저는 이제 시작과 동시에 거의 모든 정보를 무시할 것이다. 대신 철광석을 캐기위한 부지에 집중한다. 어디에 물이 있는지 찾는다. 어디에 보일러와 터빈을 설치해야 공간이 여유로울지 탐색한다. 그 옆에 있는 구리 광석과 우라늄 광석, 주변에 흩어진 나무들, 미니맵에 빨갛게 표시되는 적은 신경쓰지 않는다. 이 프로세스의 아름다움은 가장 빠르게 정보의 필터를 구축한다는 것에 있다. 

 

시작

 소프트웨어 마에스트로를 마치고 다시 취업준비의 길로 들어섰다. 물론 바쁘고 힘든 날들이지만 코딩을 손에서 놓고 싶지는 않았다. 책을 보고, 글을 쓰고, 코딩하는 일상을 잃고 싶지 않았던 것이다. 그래서 나만의 게시판을 하나 만들어보기로 마음 먹었다. 

 서비스의 한 생애주기를 경험했다는 사실이 나름 자신감을 심어주었는지도 모르겠다. 기획서도 내 손으로 썼고, 와이어프레임도 내 컴퓨터에서 그렸다. 백엔드 서버 개발은 물론이고 AWS 클라우드 인프라 구성도 내가 했다. 심지어 구글 애즈로 홍보하는 것까지 내 손으로 끝을 보았다. 서비스 기획부터 개발, 출시, 홍보까지 기본적인 흐름은 모두 경험한 셈이다. 

 게임으로 따지면 작은 공장을 끝까지 만들었고 게임의 엔딩을 본 셈이다. 물론 여타 공장게임들이 그렇듯 엔딩은 끝이 아니고 또 다른 시작이겠지만. 어찌되었든 마치 팩토리오 엔딩을 보고 나서 새 게임을 시작하면 해야할 일들의 순서와 중요도가 머릿속에 떠오르듯이, 새 프로젝트를 시작하려니 어디서부터 시작해야하고, 어떤 준비들이 필요하고, 어디에 마일스톤을 놓아야하며, 어떤 방식으로 일해야 하는지 보이기 시작했다. 수 없이 많은 방법론과 프레임워크, 라이브러리, 갖가지 스킬들과 인프라 아키텍처들이 있지만 그 중에서 내가 뭘 눈여겨봐야할지 명확해졌다. 

 소프트웨어 마에스트로를 겪고 얻은 필터와 반면교사를 갖고, 이번에 취준하면서 제대로된 프로젝트를 다시 한 번 시작해보려 한다. 

 

기획

 서비스의 성공에 기획은 정말 큰 부분을 차지한다. 내가 느끼기에 소프트웨어 마에스트로 프로젝트에서 본 프로젝트들은 잘못된 기획 때문에 실패했다기보다 현실적인 문제와 타협하는 등의 이유로 원래의 기획이 변경되어서 기대했던 성과를 거두지 못한 경우가 더욱 많았다. 우리 팀의 프로젝트도 그런 예시가 아니었을까. 

 그럼에도 이번 프로젝트는 작은 부분에서부터 시작하려 한다. 생각해보니 컴퓨터공학을 전공했음에도 내 개인 웹사이트 하나 만들어본 적이 없었다. 그래서 주로 내가, 가능하다면 다른 사람들도 글을 써 올릴 수 있는 게시판을 구상하였다. 간단한 댓글과 좋아요 기능들을 모두 손수 구현해 일종의 게시판 형 SNS를 말이다. 고객을 위한 기획은 아니지만 내가 꼭 한 번은 만들어보고 싶었던 서비스라 이번 기회에 시간도 있겠다 한 번 만들어 볼 것이다. 

기능

• 구글 로그인 지원
• 모든 유저는 글을 써서 올릴 수 있다. 
  • 글은 작성자, 제목과 내용으로 구성된다. 
  • 글은 텍스트와 이미지, 링크 등을 포함할 수 있다. 
  • 모든 글은 좋아요와 댓글을 가지고 있다. 
  • 작성자 또는 관리자가 글을 수정, 삭제, 비공개 할 수 있다. 
• 홈페이지에서는 모든 글을 날짜 역순으로 보여준다. 
  • 홈페이지에서 글을 클릭하면 해당 글의 상세 페이지로 이동한다.

기본적인 포스트 기반 SNS와 다를 바 없다. 여기에 짧은 글을 블로그처럼 써서 올릴 수 있도록 기능을 구성했다. 

기술 스택

 백엔드 기술 스택은 NestJS를, 프론트엔드는 NextJS를 사용기로 했다. 지금까지 SpringBoot만 사용해와서 조금 다른, 그러나 많이 익숙한 구조의 프레임워크를 쓰고 싶었고, Javascript/Typescript를  온전히 써본 적이 없었기 때문에 그 둘을 만족하는 NestJS를 선택했다. 프론트엔드는 React를 쓰고 싶었고 그 중 가장 핫한 프레임워크인 NextJS를 쓰기로 했다. 

 

마치며

 글을 쓰고 있는 시점에는 어느 정도 개발 진전과 기획 변경이 있었지만 일단 이번 글은 여기서 끊고 가려한다. 어쩌다 프로젝트를 시작하게 되었는지 위주로 설명하고 싶었다. 다음 글에서는 어디까지 개발했고, 어떤 변화가 있었으며, 어떤 어려움이 있었는지 소개하겠다.