프로젝트 개요
프로젝트 기간: 2024.05.22 ~ 2024.07.09
프로젝트 목표:
- 외부 라이브러리 사용해보기
- 개발부터 배포까지의 풀 스택 개발 경험해보기
- 사용자 경험 개선을 위한 성능 향상 고민
프로젝트 배경 및 목적
내가 가장 많이 사용하는 서비스가 뭔지를 고민해봤습니다. 이번 프로젝트의 목표가 단순한 기능 구현이 아닌 사용자 경험 개선까지 고려하여 프로젝트의 완성도를 높이는 것에 있기 때문에 더더욱 제가 자주 사용하던 서비스여야 했습니다.
그렇게해서 최종적으로 2가지의 주제로 추려졌습니다.
- 치지직 api를 활용한 서비스
- kakao map sdk를 활용한 서비스
이 중에서도 첫번째 요소에 관심도가 더 높았었지만 최종적으로는 두번째 요소인 지도 검색으로 최종 결정 하게 됐습니다. 그 이유로는
- 치지직은 아직 공식 api가 없다.
- 유저가 커스텀한 api가 있긴 하지만 불안정 하기도 하고 데이터 자체가 크롤링 수준이었기 때문에 적합하지 않다고 판단.
이러한 이유로 안정적이고 관련 글도 많은 kakao map sdk를 활용하기로 결정했습니다.
프로젝트 계획 및 준비
주제를 정했으니 다음은 기술 스택을 선정해야 했습니다. 가장 큰 고민의 지점은 next와 react + express 중 어떤 것을 선택하느냐 였습니다. 결론적으론 후자를 선택했는데 그 이유는
- next.js의 강점은 강력한 서버 사이드 렌더링의 지원입니다. 서버 사이드 렌더링의 강점은 seo 즉 검색엔진 최적화에 있는데 이번 지도 검색 서비스에 적용하기엔 고려할 사항이 적다는 생각을 가졌습니다.
- next.js는 파일 시스템 기반 라우팅을 제공하는데 좀 더 낮은 레벨에서의 라우팅을 경험해보고 넘어가고 싶다는 생각이 들어 손 가는 곳이 더 많은 express를 선택했습니다.
기술 스택:
Languages: TypeScript
Front-End: React, Redux Toolkit, Tanstack Query, TailwindCSS
Back-End: Express
Databases: MongoDB
Tools: Git, Docker, AWS EC2, AWS S3, CloudFront, VSCode
프로젝트 진행 과정
커밋 내용과 개발 일지를 복기해보며 시간순으로 작성해보겠습니다.
- 각 기술 스택별 학습을 위해 repository 를 하나 만들고 예제를 통해 빠르게 학습하려고 했습니다.
- axios를 이용한 비동기 처리 방식으로 kakao map sdk의 기능을 활용했습니다.
- 즐겨찾기 등록, 삭제 버튼을 구현하면서 Virtual DOM 기반의 spa 의 강점을 실감했습니다.
- 로그인 기능을 구현하고 jwt 토큰 방식을 인증 방식으로 채택했습니다. session과의 비교를 통해 사용자의 로컬 공간을 적절히 활용하는 것이 서비스 최적화에 큰 영향을 준다는 것을 배웠습니다.
- 검색 결과를 클릭했을때 나오는 상세페이지를 개발하면서 이미지 렌더링을 경험했습니다. 그리고 이 이미지를 어떻게 최적화 하느냐가 렌더링 최적화의 핵심이 되겠다라는 생각을 했습니다.
- 5번 과정을 겪은 이후 막연했던 서비스 성능 최적화라는 개념이 구체화 됐고 여러 렌더링 최적화 기법을 고려하다 지도 검색 서비스의 특성을 고려해 데이터 캐싱 기능을 도입하기로 했습니다. 그리고 데이터 캐싱관련 제일 대표적인 기술인 react-query를 적용하여 캐싱을 활용했고 부하 테스트를 통해 성능 비교까지 진행했습니다.
- 서비스를 배포했던 경험이 없어서 이전 next와 express를 고민했던 지점과 비슷하게 사용하기 편한 기능을 가져다 쓰기 보단 직접 서버를 구축해보기로 결정했습니다.
- 백엔드는 ec2에 직접 서버를 구축하여 배포하고 클라이언트는 s3 cloudfront를 이용해 정적 배포했습니다. 이 과정속에서 배운 것들이 참 많은데
탄력적 ip: ec2는 실행할때마다 ip가 변하는데 이 변하는 ip를 탄력적 ip라는 정적 ip를 결제해서 적용시킬 수 있었습니다.
DNS의 개념: 우리가 흔히 사용하는 url 명이 해당 서버의 ip 주소를 도메인 네임이라는 가독성이 좋은 이름으로 덮어씌운 것이라는 것을 알았습니다.
프록시의 개념: 제 탄력적 ip에 제가 구매한 도메인을 적용하면서 프록시라는 개념을 마주했습니다. 프록시라는 용어 자체는 알고 있었지만 구체적으로 어떤 것인지는 알지 못했었는데 앞서 기술했던 것들을 구현해보며 개념을 확립했습니다.
이 외에도 certbot을 활용한 https 인증서, 리눅스 명령어 등을 익힐 수 있었습니다. 직접 서버를 구축하는게 너무 생소한 개념도 많고 힘들었는데 힘들었던 만큼 얻은 것들이 많아서 만족스러웠습니다.
- Git Action을 이용해서 CI/CD 파이프 라인을 구축해봤습니다. 배포의 과정이 정말 복잡하다고 생각했는데 그 문제를 해결 할 수 있었습니다.
- Docker를 사용해봤습니다. 이번 프로젝트에서 처음 다뤄본 기술들이 굉장히 많은데 그 중에서 체감이 제일 좋았던 기술입니다. 휴대용 집을 소지하고 다니는 느낌 ? Docker를 이용해 ec2에 재배포를 했고 명령어에 좀 친숙해지기 위해 CI/CD 파이프라인은 잠시 해제해뒀습니다.
- 다양한 성능 테스트를 진행해봤습니다. 앞서 말씀드린 react-query를 이용한 캐싱 데이터를 강제 부하를 통해 성능 측정을 해봤고, DB 로직을 수정해서 연산 과정을 간략하게 수정했습니다.
어려움 및 해결 방안
매 순간이 어려움의 연속이었습니다.
안그래도 어려웠는데 혼자 진행하다보니 물어볼 곳도 마땅치 않아 구글 검색과 gpt를 적극적으로 활용했습니다. 그러다 보니 프로젝트 초반부는 gpt의 비중이 높았던 것이 사실입니다. 근데 프로젝트가 점점 고도화되고 복잡해지면서 더 이상 gpt의 코드에만 의존할 수 없다는 생각이 들었습니다. 그 때부터 gpt에는 간단한 개념 검색, 툴 사용법, 코드 리뷰등만을 부탁하고 모든 코드들을 직접 설계하기 시작했습니다.
코드를 직접 설계하고 작성하다보니 기획의 중요성을 깨달았습니다. 이번 프로젝트는 학습과 구현을 병행하면서 진행해 미처 기획을 상세하게 하지 못한채로 시작했는데 다음 프로젝트는 컴포넌트 구성, DB 구성 등 기획을 확실하게 하고 코드 작성을 시작해야겠다는 생각을 했습니다.
느낀 점
이전의 웹 개발 경험은 html, css, javscript 를 활용한 정적 웹 사이트 제작 정도 였습니다. 그래서 이번 프로젝트를 풀 사이클로 계획하면서 내가 할 수 있을까 ? 라는 생각이 들었던 것도 사실입니다. 그래서 완벽하진 않지만 해냈다는 사실이 굉장히 만족스러웠던 프로젝트였다고 생각합니다.
수학에 변곡점이라는 개념이 있습니다. 함수의 그래프가 오목에서 볼록으로 바뀌는 지점을 말하는데요. 이번에 개발자라는 직업에 다시 도전하면서 제일 걱정했던 부분이 개발에 대한 흥미를 어떻게 유발시킬까 였습니다. 제가 어떤 일이든 100% 열심히 할 수 있는 사람이었다면 좋겠지만 저는 재미를 못느끼면 100%를 쏟아 붓지 못한다고 생각해서 걱정이 컸는데 이번 프로젝트는 그 고민을 어느정도 해결해줬다고 생각합니다. 프로젝트 기간동안 하루에 10-12시간 정도를 투자했는데 그동안의 저 라는 사람을 돌아봤을때 재미를 느끼지 못했다면 절대 할 수 없던 일들이었습니다. 그래서인지 이번 프로젝트 회고를 하며 떠오른 키워드가 변곡점 이라는 키워드입니다. 이번 변곡점을 통해 어떤 그래프를 그리며 어떤 도착지에 도착할지 너무 기대가 됩니다.
Ghost