아직 해커톤의 결과는 나오지 않았지만 MVP 배포까지의 얘기를 해보려 한다.
이번 해커톤의 정식 개발 기간은 9월 23일부터 9월 25일까지였다. 9월 17일에 주제가 나온 후, 19일쯤 서비스 기획을 결정하고, 서비스 구체화 및 인프라 작업을 진행했다. 인프라 구축 단계는 너무나도 수월했다. 이전 프로젝트의 프론트엔드와 백엔드가 이번 해커톤에서도 같이 협업했기 때문에, 인프라 관련 의사결정에서 효율적으로 처리할 수 있었다.
인프라 구축 후 순수 개발 3일. 그동안 새로 배운 것과, 좋았던 점, 힘들었던 점에 대해 얘기를 할 것이다.
새로 배운 skills
개발 기간이 짧기 때문에 새로운 걸 도입하기보단 익숙함을 추구했다. 그래서 기술 측면에선 배움이 적었다.
-
kakao map API
지도 api를 제대로 사용한 건 이번 프로젝트가 처음이다. 그럼에도 짧은 기간 안에 MVP 요구사항을 모두 충족시킬 만큼의 기능이 나오면서 나의 default 러닝 커브가 꽤 줄어듦을 느꼈다. 작년 이맘때의 내가 이 API를 사용해 기능 개발하려면 3일로는 턱도 없다는 생각이 들었다. 아무튼 우리 서비스의 핵심은 핀이기 때문에 kakao map의 마커와 클러스터 기능을 적극 활용하여 서비스를 구현했다. -
svg 다루기
svg를 이번에 처음 다뤄봤는데, 그 파괴력은 정말 엄청났다. 세상에 이미지의 색깔을 js를 통해 결정할 수 있다니. 더욱이 벡터 이미지라 화질 부분에서도 압승이다. svg 없인 살 수 없는 몸이 되어버렸다.
-
서버리스 환경 배포하기
이전 프로젝트는 React로 진행했고, Nginx가 직접 웹서버의 역할을 맡았다. 하지만 이번엔 Next.js를 사용했는데, 넥제는 서버리스를 지원한다. 서버리스임에도 Nginx는 https 및 도메인 적용을 위해서 필요했다. 무중단 배포까지 처리하고 싶었지만 개발 기간 상 이것도 후 순위로 밀렸다..
좋았던 점
좋았던 점들을 언급하기에 앞서, 사실 이 해커톤을 참여함에 고민이 굉장히 컸다. 왜냐하면 카카오 코딩 테스트와 날짜가 겹쳤기 때문이다. 하지만 결국 해커톤으로 결정하였고, 좋은 경험을 하였기에 후회는 없다. 아직 4학년 막 학기도 아니기에 카카오 욕심을 버릴 수 있었다.
-
협업이 익숙한 멤버들과 대회 진행
이번 프로젝트는 총 4인(디자이너 1, 프론트엔드 1, 백엔드 2)으로 진행했다. 여기서의 프1, 백2는 이전 프로젝트를 2달간 해왔기 때문에 협업 부분에서 굉장히 순조로웠고, 마침 디자이너 분도 성격이 굉장히 좋고 협업을 경험해 보셔서 개발 과정이 순탄했다. -
디자이너와 함께 UX 의사결정하기
이번 프로젝트에서 처음 디자이너와의 협업을 경험했다. 결론적으로 매우 만족스러운 경험을 할 수 있었고, 다음부터 디자이너 없인 프로젝트 못 할 것 같다는 생각까지 들 정도로 너무 좋았다. 특히 프론트엔드 개발자이기에 더욱 느끼는 바가 큰데, UI 부분을 맡길 수 있고, png를 직접 찾아다닐 필요도 없고, UX 고민도 함께할 수 있어서 좋았다. -
넣을 거 넣고 뺄 건 확실하게 뺀 MVP
'내 정보', '설정 페이지' 등등 다 빼버렸다. 명확하게 서비스 주요 기능만을 포커싱 해서 높은 완성도를 이끌어냈다. 이게 심적으로도 크게 작용했는데, 남은 기간이 짧더라도 압박감을 덜 받을 수 있었고, 주요 기능들의 디테일까지도 챙길 수 있어서 굉장히 만족스러웠다.
힘들었던 점
-
디자이너와 백엔드 사이의 프론트엔드 1인
4명 중 프론트엔드를 혼자 담당했다. 웹서버 인프라 구축 담당까지 했으니 3일 동안 정말 치열하게 개발했다. 그러면서 특정 디자인이 완성되면 디자인 처리하다가 백엔드 측 API가 완성되면 API 연결하다가.. 그래도 디자인 구현과 API 연결을 번갈아가며 하니 정신적으로 버틸만했다. 3일 동안 하나만 하라 했으면 정신이 나갔을지도 모른다. -
짧은 개발 기간 속 요구되는 정확하고 빠른 기술적 의사결정
이게 가장 힘든 부분이었는데, 결론적으로 실수 없이 잘 해결해서 좋았다. 대표적으로 필요한 state에 대해 useState로 처리할지, recoil의 atom으로 처리할지에 대한 고민이 있었다. 한 컴포넌트 또는 자식 컴포넌트까지 사용하려면 useState로 처리함이 맞다. 전역적으로 사용하려면 atom이 맞다. 하지만 0과 1로 결정할 수 없는 애매한 문제들이 존재한다. 이걸 정하는 건 단순 기술 문제뿐 아니라 UX 결정도 포함이기 때문이다. 처음부터 완벽한 UX 설계를 할 순 없었기에 개발과정에서 들어오는 yes or no를 쳐내는 것에 대한 고민을 많이 했다. 아무튼 맡은 바를 해낼 수 있었던 것은 역시 이전 프로젝트들의 경험이 큰 역할을 한 것 같다. -
데스크탑 버전의 디자인을 먼저 만듦으로 인해 까다로운 반응형 고려
해커톤 대회 기간이 짧기에 PC와 모바일 버전의 완성된 디자인을 받고 시작하는 것이 아니었다. 따라서 우선 PC버전용 페이지를 하나하나씩 받았고, 이를 완벽히 구현하고 나니 개발 종료까지 4시간 정도 남았다. 디자이너 분이 구현해 준 모바일 버전용 웹을 100% 구현할 시간은 도저히 안 났고, 이를 디자이너 분도 이해해 주셨다. 따라서 여기서부턴 가지고 있는 PC버전 소스를 최대한 활용하여 스스로 모바일 처리를 할 수밖에 없었고, 어떻게 처리할지에 대해 정말 4시간 중 1시간은 쓴 것 같다. 메인 페이지와 글쓰기 페이지는 상대적으로 간단했고, 지도 페이지에서 고민이 많았는데, 결과적으로 가지고 있는 자원과 시간 대비 최대의 UI/UX 만족도를 끌어낼 수 있어서 상당히 만족했다.
마무리
짧은 대회 기간이었지만 실시간 협업, 디자이너와의 협업에서 개발 외적으로 많은 부분을 배울 수 있었다. 개발적으로도 짧은 시간 동안 a to z 개발은 처음이었는데, 어려웠지만 해낼 수 있어서 만족스럽고, 스스로 뿌듯함도 느꼈다. 혹시 서비스가 궁금한 사람들을 위하여 github와 서비스 링크를 남기며 글을 마무리하겠다.
수고했당