8월에 시작한 사이드 프로젝트가 있습니다. 보드게임 '스파이폴'을 온라인에서 즐길 수 있도록 만든 웹사이트인데요. 많은 사용자들을 기대하기보다는, 새로운 기술을 써보면서 스스로의 학습에 중점을 둔 프로젝트입니다. 배포와 테스트까지는 성공해서, 지인들 붙잡아다 열심히 사이트 즐겨보고 있는데요. 아직 고쳐나가야 할 부분이 많다는 걸 느끼지만... 그래도! 지인들과 즐겨볼 수 있는 수준까지 만들었으니, 기념 삼아 중간 회고를 해보고자 합니다.
1. 괜히 설계에 많은 시간을 쏟는 게 아니다.
스파이폴 프로젝트를 시작하기 전에, 다음과 같은 프로젝트들을 만들어보았습니다.
- 레지스탕스 아발론과 시크릿 히틀러 같은 디스코드 봇
- 보드게임 디크립토 웹사이트 (이 프로젝트만 유일하게 팀 프로젝트네요)
- this war of mine 보드게임 지원 툴 웹사이트
이 프로젝트들은 미리 설계를 1주일 ~ 한 달 정도 진행한 후 개발을 시작했습니다. 당연히 중간에 설계가 바뀌기도 하고, 기존 설계를 뒤엎는 과정도 있었기에, 꽤 시간이 오래 걸리는 과정이었죠.
그래서 이번에는 설계 없이 프로젝트를 진행해보기로 했습니다. 설계 없이 기능을 하나 만들 때마다 새로운 기능을 즉석으로 떠올리면서 개발을 이어나갔죠.
이렇게 개발하다보니 몇 가지 불편함이 있었습니다.
1. 기존 코드를 바꾸는 빈도가 너무 잦다.
처음 코드를 쓸 때는 빠르고 편하게 쓸 수 있었습니다. 즉흥적으로 코드를 작성하니 속도도 빠르고, 별로 어렵지도 않았습니다. 처음 이틀 동안만.
그렇게 즉흥적으로 썼던 코드는 기능이 늘어나면 늘어날 수록 훨씬 많이 교체되었습니다. 당시에는 간단하게 작성했던 코드가, 나중에는 훨씬 복잡하게 바뀌어야 했죠. 생각지도 못한 조건에 의해 오류가 발생하는 걸 보면서, 한번에 수정하는 코드의 범위가 엄청 넓어지게 되었습니다. 자꾸 파일을 왔다갔다하다보니 집중하기도 어렵고, 후회가 막심했던 것 같습니다.
2. 새로운 기능을 추가하기가 점점 어려워진다.
프로젝트를 진행하면 진행할수록 내가 원하는 기능이 점점 늘어갔습니다. 즉석에서 ‘오 이것도 넣어보고 싶은데? 저것도 넣어보고 싶은데?’같이 기능을 떠올렸죠. 역시 처음에는 쉽게 쉽게 기능을 추가했지만, 나중에는 기능을 추가하기 힘들어졌습니다.
왜냐면 새로운 기능을 추가할 때마다 고쳐야 할 코드가 넘쳐나서(…) 말이죠. 그러다보니 어느 순간 확장성은 포기하고, 그저 완성에만 신경썼던 것 같습니다.
3. 리팩토링에 시간이 훨씬 더 오래 걸린다.
제대로 된 설계가 없으면, 기술 부채가 엄~~청 늘어나더라고요. ‘돌아가기만 하면 됐지 뭐’라는 마인드로 임했다가 내가 쌓아둔 기술부채를 마주하면서 ‘하…’라는 생각이 떠올랐습니다. 그래도 리팩토링 시작은 어떻게 했지만…
‘이 코드는 왜 필요한 거야?’하고 지웠더니, 알고보니 임시방편으로 에러를 막은 코드였다던가. 코드 한 줄 바꾸려고 했더니 VS Code에서 빨간 줄이 우수수 뜬다던가… 내 코드에 대한 방향성이 존재하지 않기에, ‘리팩토링을 어떻게 할 것인가?’도 정의되지 않았고, 그래서 리팩토링이 훨씬 어려웠던 것 같습니다.
결론: 설계는 생각보다 중요하다.
설계를 처음 배웠을 때는 재미도 없고 오래 걸리는 귀찮은 작업이라고 생각했습니다만… 설계를 안 해보니 그제서야 필요성을 느끼게 되었습니다. 다음 프로젝트부터는 다시 설계부터 진행하고 시작하도록 하겠습니다. 처음에는 시간이 좀 걸리더라도, 장기적으로는 시간을 아끼는 일이더라고요.
2. 데이터베이스도 제대로 정해야 한다.
스파이폴 프로젝트에서는 Firebase를 데이터베이스로 쓰고 있는데요. 이전까지 Firestore Database를 쓰다가, 최근에 Realtime Database로 데이터베이스를 바꾸게 되었습니다.
가장 큰 이유는 유저가 사이트를 나갈 때 안정적인 이벤트 listener를 등록가능한지 아닌지의 여부였습니다. 기존에 있던 Firestore database를 유지하면서 Realtime Database를유지하는 방법도 있지만, 그건 유료 요금제로의 변경이 필요하고 저는 돈이 없기 때문에 Database 자체를 옮기기로 결정했죠.
근데 이거 전혀 쉬운 일이 아니더라고요(…) 데이터베이스와 통신하는 모든 코드를 다 수정해줘야 하고, 데이터베이스마다 통신하는 방법도 다 달라서(심지어 같은 Firebase 제품인데도!) 이관을 결정하기 전에 이관을 할까말까 정말 고민 많이 했습니다…
다행히 이 프로젝트는 배우는 것이 목적이고, 딱히 정해진 기한도 없기에 그나마 이런 결정을 내릴 수 있었지만, 실무에서 시간도 촉박한데 갑자기 데이터베이스 교체하라고 한다? 어후…
3. 직접 만들어봐야 한다는 게 이 의미구나.
꼭 이번 프로젝트만 해당하는 얘기는 아니고, 이전 프로젝트에 해당하는 얘기지만, 사이드 프로젝트에서 배울 수 있는 것들이 정말 많은 것 같아요. 책이나 동영상 보면서 따라친다거나, 알고리즘 테스트를 공부해본다거나, 클론코딩을 해보는 것 또한 많이 배울 수 있지만…
사이드 프로젝트를 하면서 배운 것은 ‘비즈니스 로직’을 생각해본다는 거에요. 굳이 돈을 벌지 않더라도, ‘스스로 문제를 정의하는 과정’이 정말 중요한 것 같아요. 알고리즘 문제나 클론 코딩은 이미 문제가 정의되어있는 상황에서 해결책을 찾는 거라면, 사이드 프로젝트는 문제를 스스로 정의해야 하고, 그 과정에서 해결책의 방향성을 결정한다는 차이가 있습니다. 해결책을 찾는다는 공통점이 있더라도, 한 쪽은 ’이미 결정된 정답‘을 찾는 과정이라면, 다른 한 쪽은 ‘아무도 모르는 정답‘을 스스로 정의하는 과정이 필요하죠.
나중에 회사를 창업하거나 프로젝트를 시작하면, 고객의 문제를 정의하는 과정이 필수적이라고 합니다. 책과 동영상을 보면서는 그런 과정을 체험해볼 수 없겠지만, 사이드 프로젝트를 통해서는 (비록 난이도는 훨씬 낮더라도) 그 과정을 체험해보고, 생각할 수 있는 기회를 가질 수 있다는 점에서 너무 추천드리고 싶네요.
4. 마무리
스파이폴 프로젝트는 아직 끝나지 않았고, 고쳐야할 문제도 많습니다. 회고록 작성 후 저는 다시 코딩하러 돌아가겠지만, 회고록을 적어보니 생각보다 배운 게 많군요! 그래도 제가 무의미한 시간을 보낸 것은 아닌가 봅니다 ㅎㅎ
사이드 프로젝트를 진행하는 모든 분들을 응원합니다! 우리 모두 화이팅하자고요!
