첫번째 사이드 프로젝트 개발 회고
결실을 맺지는 못했지만 최선을 다했고, 노력의 흔적을 남긴다.
📅 프로젝트 기간
- 1차 21.10.01 ~ 22.02.16
- 공백기
- 2차 22.08.24 ~ 22.12.25
여행을 즐기다, 나만의 특별한 장소 유목민
🍃 유목민 프로젝트?
- 양질의 특별한 여행 장소 공유
- 본인만의 여행 일지(기록) 작성
- 커뮤니티 기능을 모두 가진 블로그형 소통 플랫폼
😎 기획 목적/배경
- '좋았던 곳'을 타인에게 공유 or 소통하는 트렌트.
- 다양한 기록 앱 또는 타 커뮤니티에서 본인만의 여행 장소를 기록하는 사람들이 많음.
- 현재 여행 커뮤니티라고 할 수 있는 대표적인 여행 플랫폼이 없다. (SNS 제외)
🤔 주요 타겟
- 여행을 즐기는 나이불문 다양한 연령층
개발자 직군으로의 첫 직장에서 만난 마음맞는 친구 혁이를 만나 빌드업을 위해서 퇴사를 한후 그 기간동안 뭐라도 도전해보자 하고 막연하게 시작한 사이드 프로젝트.
한 프로젝트의 사이클을 이해하기엔 아직 어려운 지식들을 가지고 감히(?) 덤벼들어 보았다.
그리고 둘이서 시작한만큼 업무분담에서 나는 전반적인 프로젝트 전체를, 혁이는 디자인과 퍼블리싱을 맡았다.
초기 기획
- 소개
- 유저 플로우
- 와이어 프레임
- 전체 페이지 및 기능
- 디자인, 로고
- 아키텍쳐
지금 보면 상당히 부끄러울수 있는 허술한 기획 자료들을 그때는 정말 재미있게 준비해 나갔다.
위 초기 기획에서는 반응형 웹 하나였다.
이때 알았어야 했다.. 우리가 생각한 사이드 프로젝트의 정확한 의도를 무시한채 나의 욕심으로 나중엔 껍데기만 거창한 프로젝트가 되어 가고 있음을 인지하지 못했다.
그것을 알기전으로 돌아가서.. 드디어 코드를 짜보는 시간이 왔다.
실무에서 배운 기술들로 웹을 채워가면서 이때 미약하게나마 부족했던 지식(라이브러리, 자료구조, 알고리즘)들이 쌓였던거 같다.
도움없이 스스로 트러블슈팅을 해가면서 배우라는게 해보고나니 어느정도 이해가 되었었다.
그래도 비교적 수월하게 작업들이 진행되어서 뿌듯함이 있었던거 같다.
‘앱을 해야한다’라고 결론을 내기전까지 ..
돌아보면 여기서 내가 억지아닌 억지를 부렸다고 생각이 든다.
우리가 생각한 사이드 프로젝트는 개인의 성장 또는 프로젝트의 가치에 기반을 두고 최소 기능 제품(MVP)를 목표로 해당 목표 달성 후에 버전을 올려가면서 순차적 진행을 했어야 하지만‘대부분의 이용자들은 웹보다는 앱을많이 사용할거야’와 같은 추가적인 고민들로 기획 방향을 자꾸만 바꾸면서 혁이가 상당한 고충을 겪었을것 같아서 미안한 생각이 든다.
그렇게 기획 의도와 다르게 움직여 갈때 즈음 원하는 스타트업에 재취업에 성공했다.
🌧 재취업후 공백기
재취업을 하고 약 6개월간은 정말 정신없는 시간을 보냈다.
물론 당연한 얘기겠지만 사내에서 보고 배우는 것들이 내가 알고 있던것과는 정말 세발의 피에 불과 했다는것을..
전체적인 아키텍쳐부터 CI/CD, 클린 코드, AWS의 더욱 다양한 서비스들.
새로움은 언제나 설레고 재밌지만 아직도 배울것이 끝이 없이 남았다는 생각에 숨이 막히기도 했다.
🔥 재도전, 그리고 포기
하지만 최소한의 끝맺음은 필요하다는 마음가짐을 가지고 재도전을 시작했다.
여기서 혁이는 더욱 소중한 본인의 다른 꿈을 펼치기 위해 자리를 비웠던 시점이다.
이때부터는 혼자만의 외로운 싸움을 했던것 같다.
기존의 기획은 크게 변동없이 가되, 아키텍쳐와 기술 스택의 변화가 있었다.
기존 아키텍쳐
lagacy architecture
부끄럽지만 내가 생각한 구조이고, 심플함 그 자체였다.
사실상 아는게 여기까지다보니 이런 구조로 진행을 했었다.
웹과 앱을 구분하고 앱으로는 플러터를 추후에 진행하기로 했다.
추가 수정된 아키텍쳐
왜 이런 구조를 택하게 되었을까?
일단, 웹과 앱을 구분지어서 작업 하기엔 이미 너무나 많은 작업들이 밀려있었고,
플러터를 따로 배워서 배포까지 마쳐야 한다는 생각은 애초에 사실 고려도 하지 않았던 것 같다.
그럴싸해 보이는 아키텍쳐를 보여주고 싶었던 마음이기도 했다.
그러다 웹뷰라는 방법을 알게되었고 앱이면서 내부적으로는 웹뷰가 동작하는 하이브리드 앱을 보고 웹과 앱을 동시에 크로스 플랫폼 앱을 만들수 있다는 점에 ”내가 원하는게 이거였어.”라며 바로 선택했다.
물론 여기서도 내가 생각한 구조와 웹뷰의 단점들을 딥하게 고려하지 않았던 점도 지금으로써는 아쉬운 부분이기도 하다.
CI/CD로는 github action을 사용해서 EC2에 docker, docker-compose를 이용해서 자동화된 CI/CD를 구축을 할수 있게 했다.
확실히 자동화는 많은 시간을 아껴줄 수 있어서 개인적으로 아주 만족하는 자동화 배포 시스템이다.
덧붙여서 다양한 기술 스택들이 추가되었다.
- react → nextjs 마이그레이션
- react-native 하이브리드 앱을 위한 껍데기
- api docs 추가
- CI/CD github-action을 활용한 자동 배포
ECR register, ECS 자동 배포약 2주간의 고통으로 이 배포 방식은 포기해야만 했다.
포기하다
시작은 창대하나 그 끝은 미약하리라
그 유명한 명언이 나에겐 이렇게 반대로 작용했던것 같다.
자책하는 소리를 해보자면 일부의 스파게티 코드와 의미없는 리팩토링, 부족한 지식으로 따라하기식 기술 스택들로 떡칠된 겉만 번지르르한 프로젝트라고 볼 수 있다.
혼자서는 감당할수 없이 비대해져 가는 프로젝트를 보고 한동안 자괴감을 맛보게 되었고,
AWS EC2, ELB 등의 고정 지출 비용, 기약없는 배포일과 유저 유입을 기대하는것 또한 장기적으로 부담이라는 판단하에 최종적으로 프로젝트를 종료하게 되었다.
정말 많은 고민들과 배움, 아쉬움, 후회.
하지만 이를 돌아보았을때 결국은 무엇이든 배웠다고 생각이 든다.
🌊 경험, 트러블 슈팅
크게 기억나는 몇개의 웹뷰 이슈가 나를 지속적으로 괴롭혔었다.
웹뷰와 앱의 간극
🌱 마무리
주도적인 부분에서 게으르거나 고집적인 부분들 또는 가끔은 흥미를 잃고 일처럼 느끼는 스스로를 보면서 내가 어떤 단점들을 가지고 있었는지 다시 한번 더 알수 있게 되었고,
혼자서 모든걸 해결하는 것도 좋지만 스스로 그런 부분이 부족하다 느낀다면 시너지가 좋은 팀원을 만나서 서로의 부족함들을 채워준다면 더 큰 힘을 낼수 있음을 느끼기도 했다.
배움에는 끝이 없다. 이 또한 즐겨가며 주니어 개발자의 마인드셋을 갖추고 앞으로 있을 더 재미있는 프로젝트와 기본기를 갖춘 개발자가 되어 가고 싶다.