[들어가는 말] 프로젝트 회고..? 뭘 적으면 좋을까
제가 이번에 도전한 프로젝트의 주제는 명언 웹 이었습니다. 사실 아직도 완성이라고 하기에는 현실적인 제약에 부딪혀 미완성 상태이지만, 그래도 어느 정도 돌아가고는 있으니 회고라는 핑계로 분풀이를 해볼까 합니다. 다른 회고 글을 보면 기능 명세서도 작성하고, ERD도 기술적으로 정리하는 등 엄청 잘 작성된 글들이 많이 보였는데요. 그걸 따라하기에는 A 부터 Z 까지라는 체계적인 순서를 지키며 개발한 것은 아니다 보니, 나름대로 목차와 흐름을 정해서 회고를 시작해볼까 합니다.
[본문] 프로젝트 소개(+ 디자인 변경점)
우선 제가 어떤 프로젝트를 했는지 소개를 해야겠죠? 명언 웹 사이트는 말그대로 명언 목록을 조회하고, 검색하고, 마음에 드는 명언은 픽 해서 SNS에 공유도 가능하고, 또.. 사용자가 자신만의 명언 카드를 만들어서 소장할 수 있는 그런 단순한 웹 사이트 입니다. 웹 사이트이지만 모바일에서도 실제 앱과 같이 사용할 수 있도록 나름 디자인에 신경을 써보았습니다.
아래는 현재 사이트의 루트 페이지인데, 디자인 색감 소개 겸, 현재 이루어진 변경 사항에 대한 부분도 언급하고자 합니다.
[2024.4.10 이전 리뉴얼 전] 전체적으로 외곽선이 진하고 눈에 피로감을 주고 있습니다.
[2024.4.10 기준 현재는 UI 디자인이 다음과 같이 수정되었습니다]
사용한 기술 스택
일단, 해당 프로젝트에서 사용된 기술스택은 NextJS(14버전 이상), Typescript, Tailwindcss, Zustand, PostgreSQL, SWR 이 주요 스택이구요. 이 외에도 회원가입 및 로그인 기능으로 JWT와 Next-Auth 등의 라이브러리를 포함해서 다양한 라이브러리와 프레임워크를 사용하여 개발되었습니다.
인프라 및 배포
배포는 AWS EC2 를 사용했습니다. 현재는 t2.micro 라는 아주 작은 CPU 를 사용한 똥컴에서 돌리고 있습니다. 그래서 유저가 만약에, 수십명에서 백명 사이의 동접자가 발생한다면, 위험하지 않을까 싶네요. 무엇보다 인스턴스가 하나라서 더 걱정인 상황입니다. 찾아보니까 오토 스케일링 이라는 기능이 있어서 자동으로 인스턴스나 서버 자원을 축소 및 확장하는 기능도 있던데, 더 알아봐야 겠어요.
또한 Nginx 를 사용하여 리버스 프록시를 적용하여 https 통신을 통해 패킷 암호화는 시도했지만, 트래픽을 분산처리하는 로드밸런서를 비용 문제로 셋팅만 해두고, 사용하지 않았기 때문에, 조금의 과부하에도 펑 터질 위험성이 다분한 상태입니다. 사실 막 공부해서 이론상 약간 이해해서 아쉬웠던 로드밸런서를 적용해보면서 깊게 공부하고 싶었는데, 생각보다 VPC 비용이 며칠 사이가 크게 늘어나는 것을 보고 경각심을 느껴서 배제했습니다.
현재는 배포까지 했다는 것 만으로도 만족하고 있지만, 개인적 욕심에서 해당 사이트를 키워보고 싶다는 마음이 강합니다. 그래서 언제가 되었든 스케일 업을 하거나 스케일 아웃을 통해서 좀 원활한 인프라를 구축할 수 있도록 노력해봐야 다고 생각 중입니다.
UI 설계 및 디자인
한 번은 갈아 엎은 디자인
사실 설계나 디자인을 구체적으로 논리적으로 따져가며 만든게 아니라 그 때 그 때 감으로 괜찮다 싶은 것을 구현해서 만들었습니다. 거의 즉흥적으로 개발이 되어서 한 번은 싹다 엎어서 새롭게 디자인 하였는데 그게 앞서 첨부한 웹 사이트의 다자인 입니다.
| 참고로 변경이 되면서 원래 추가하고자 했던 기능도보류가 되었습니다. 하고 싶은 것은 많았는데, 데이터가 많이 부족해서 보완해 나가는 중입니다 |
갈아 엎기 전에는 디자인이 전체적으로 위와 같이 주황색과 하얀색 기반의 대시보드 느낌이었습니다. 제가 레이아웃 설계를 잘못해서 모바일 환경에서 반응형이 제대로 동작하지 않았습니다. 이 경험을 통해서 처음 부터 잘 만들어진 UI나 디자인 설계가 얼마나 중요한지 많이 느꼈죠.
두 번째로 바뀐 디자인
본론으로 와서 사이트 디자인을 나름 고려했을 때, 현재 사이트의 색감은 차분한 느낌이 든다면 사용자 입장에서 보기 더 편하지 않을까 에 대한 생각의 뿌리에서 하나하나 가지를 뻗어 나갔습니다.
그러면, 이런 차가우면서도 고급진 진청색이면 차분한 느낌을 주지 않을까? 로 이어졌고, 이러한 마인드맵을 기반으로 나름대로 사용성을 고려하여 레이아웃을 정하고, CSS 작업 까지 이어 나갔습니다.
물론 지금와서 생각해보면, 명언 카드 위에 있는 카드를 컨트롤하기 위한 아이콘 친구들이 너무 작아서 눈에 안 띄는게 오히려 사용하기 불편하지 않을까 생각은 들었지만, 최대한 사용자가 카드의 내용에 집중할 수 있도록 나름 디테일을 생각해서 디자인을 해보았습니다.
아래는 이번에 변경한 디자인 인데요. 두 번째 버전의 경우에는 하얀색 테두리가 너무 시선을 분산시켜서 제가 추구하는 명언에 집중하도록 하는 것과는 크게 벗어난다고 생각하여 바꾼 케이스 입니다. 현재는 이미지라 보이지 않지만, 은은한 빛의 퍼짐을 표현하기 위해 마우스 호버 애니메이션을 추가로 달아주었습니다.
다양한 기능 구현(프론트엔드와 백엔드)
현재 구현된 기능을 간략하게 언급하면, 무한 스크롤, 페이지네이션, 음성 TTS, 북마크 기능, 좋아요(평가) 기능, 댓글 및 대댓글 기능, 명언 카드 확대 기능, 명언 카드 꾸미기 기능, sitemap 동적 생성 기능(NextJS 에서 제공해주죠) 등등이 있습니다 .당연히 풀스텍 프레임워크라서 이 외 에도 서버 작업 포함해서 몇 개 더 있습니다. 크게 보면 몇 개 안 되는 기능이지만, 막상 구현해보니 신경쓸게 많아서 시간이 많이 소요 되었습니다.
사실 기능 자체만 본다면 정말 단순하다고 해도 뭐라 할 말은 없지만, 개인적으로는 고려할 게 참으로 많았던 것 같습니다. 에러 없는 기능 구현은 전설적인 존재가 아닐까 싶을 정도로 생각지도 못한 부분에서 문제가 생기니 왜 테스트를 작성해 나가며 개발을 해야하는 지 절실히 공감하는 순간이기도 했습니다.
데이터베이스 스키마 설계 및 작성
사실 관계형 데이터베이스에 대해서 잘 모르는 상태에서 진행되었습니다. 데이터베이스에 대해서 이론상 공부는 했지만 막상 프로젝트에 적용하려고 하니 쉬운 일이 아니었습니다.
그래서 우선은 제가 구현하고자 하는 기능을 리스트화 시켜서 정리하고, 이를 토대로 테이블을 만들어본다면 어떤 형태가 될지 표로 만들어보면서 구조를 잡아갔습니다
그 후에는 Postman 를 사용해서 프론트엔드에서 요청을 보내는 경우 데이터베이스에서 어떻게 조회가 되어 응답을 보내는지 네트워크 패킷을 확인해보면서 조금씩 구조화 시켜 나갔습니다.
배포
AWE EC2 를 사용해서 배포를 진행했습니다. 사실 배포에 크게 의미를 두지 않았던 프로젝트 초창기에는 단순한 무료 클라우드 서비스를 이용해서 배포를 할 계획이었습니다.
그런데, 계속 개발을 해나가면서 프로젝트가 어느 정도 구색이 갖춰지고, 실제 운영도 해보고 싶다는 욕구? 호기심? 같은게 생겼습니다. 무엇보다 웹 개발자를 꿈꾸면서 웹 인프라에 대한 전반적인 지식도 없이 편안한 도구를 이용한다는 것이 역설적이게 느껴졌습니다.
그래서 실제 배포를 진행하기로 했습니다. 고민은 길어서 좋을게 없으니 속전속결로 가자는 마인드 였습니다.
AWS EC2 Vs AWS Amplify Vs S3/Cloud Front ... 그것도 아니면?
사실 운영을 염두에 두었을 때, AWS EC2 가 처음부터 최선은 아니었습니다. 여러 블로그나 AWS 공식 사이트의 문서들을 찾아보면서 AWS Amplify 를 사용하면 보다 적은 비용으로 웹 호스팅이 가능하다는 결론까지 이르렀고, 이를 토대로 배포를 진행하려고 했었죠..
그런데, 문제는 AWS Amplify 는 서버리스 방식인 것을 떠나서 별도의 CLI 설정을 통해서 NextJS 의 백엔드 구조 자체를 변경할 필요가 생겼다는 점입니다. 그래서 이런저런 시도와 고민 끝에 이 방식은 보류하기로 결정했습니다. 저에게 필요한 것은 제가 만든 프로젝트의 환경 그대로 실행시켜줄 도구였으니까요.
그 다음에 고민했던 것은 S3 와 클라우드 프론트 기반의 정적 파일 배포, 백엔드를 별도의 클라우드에서 처리하는 방식이었습니다. 그런데, 이 방식은 제가 판단하기로는 NextJS 자체가 서버리스인데 굳이 서버 배포를 2차적으로 분리하여 하는 것은 비효율적이라 판단했습니다. 무엇보다 NextJS 자체적으로 엣지환경에서 성능최적화를 위한 다양한 기능을 지원해주는데 정적 빌드와 서버 배포를 분리해버리면 이에 대한 이점을 누리지 못한다는 치명적 단점이 보여서 이 방법 또한 보류 했습니다.
결국은 AWS EC2 를 선택했습니다.
이런 저런 고민 끝에 실제 컴퓨터 환경을 가상화 하여 제공해주는 AWS EC2 를 사용하기로 했습니다. 앞서 배포 방법보다 더 복잡하고, 더 많은 것을 알아야 하고, 더 고려해야 할 것이 많은 깊게 파고들면 끝도 없이 알아야 할게 많은 방식이었지만
그럼에도 이 방식을 선택한 이유는 제가 만든 프로젝트를 온전한 상태로 올려서 빌드 후 실행시켜줄 친구였기 때문이죠. 무엇보다 1년 간 거의 무료로 똥컴이라도 사용할 수 있게 해주는데, 피할 이유도 없었구요.
다른 핑계를 대자면, 이 도전을 통해서 배울 수 있는 것이 정말 많을 것이라는 기대감 때문이었습니다. 암튼 현재는 EC2 를 기반으로 사이트가 돌아가고 있다는 것으로 이 파트를 마무리 해봐야 겠네요
도전과제 였던 것?? 혹은 직면한 어려움들
남들이 보면 저의 어려움이 어떻게 보일지는 모르겠습니다. 사실 개인 프로젝트에서 그게 중요한 것은 아니죠. 제가 경험했고, 어려움이라 생각했으며, 결국에는 이겨내 나갔다는 것, 그것이 제일 중요하니까요.
아무튼, 이 프로젝트의 배포까지 정말 정말 많은 일들이 있었습니다. 차라리 팀 프로젝트라면 주위의 실력 있는 분에게 물어보면서 하나하나 공부하고, 극복하면서 하기 수월했을 것 같은데, 저는 개인적으로 취업을 위한 시간이 촉박하여 팀프로젝트 보다는 개인의 성장에 집중할 수 있는 개인 프로젝트에 초점을 맞추기로 했습니다.
그러다 보니 대략적으로 다음과 같은 문제들을 직면하면서, 이러지도 저러지도 못할 상황에 직면할 뻔 했죠. 개인적으로는 멘탈이 와장창 깨지는 상황들이 많았습니다.
| - accessToken 으로 구현한 로그인 기능이 취약하다는 사실을 알고 refreshToken 기반으로 업데이트하면서 로직을 싹다 갈아 엎은 문제 - JWT 재발급 기능 자동화 구현 시 계산된 시간 보다 200ms 빠르게 토큰을 발급하는 문제 - 빌드 시 동적이 아닌 정적 빌드가 되어 새로운 데이터가 갱신되지 않는 문제 - 현재 제일 고민인 크로스 브라우징 문제로 인한 무쓸모가 되버린 TTS 기능 - 실시간 명언 목록 페이지인데, 명언 목록이 실시간으로 갱신되지 않는 문제 - 배포하면서 만난 데이터베이스 연결문제 - 사용자 2명이 좋아요를 눌러서 2가 된 상태에서 또 다른 사용자가 좋아요를 누르면 0으로 초기화되는 문제 이 외에도 메모리 누수로 인한 화면 버벅임 문제, 로컬에서는 되던 것들이 EC2 에서는 안 되는 문제.. 등등이 있었습니다. |
특히 구글링해도 안 나오는 문제들도 많았는데요. 에러 코드를 구글에 검색해도 검색 결과 없음이 뜨고, 결국에는 최대한 배제하려고 했던 GPT 한테 물어봤지만 이상한 소리만 하고해서 차라리 직접 뜯어보자는 마음으로 에러 코드의 호출스택을 따라서 하나하나 디버깅하면서 찾아갔습니다.
이렇게 해서도 해결된 문제도 있지만, 해결이 안 되어서 갈아 엎은 문제도 있지만요.. 지금 생각해도 정말 무섭고 두려운 순간이었지만, 이 문제들을 꼭 해결해 내고 말겠다는 호승심도 생기더라구요. 힘들고 고통스러웠지만 그 과정 자체를 한 마디로 정리하면 즐거웠다 라고 요약할 수 있을 것 같습니다.
[나가는 말] 회고 마무리
음.. 이렇게 회고하는게 맞을까 싶지만, 아무튼 제가 생각하는 회고의 틀에 맞춰서 포스트를 작성해보았습니다. 다양한 회고 게시글을 찾아봤는데, 많은 분들이 팀프로젝트를 기준으로 엄청 꽉차면서도 명료하게 포스트를 작성했더라구요. 그런 점에서 저의 첫 회고글은 기술적으로나 형식적으로나 많이 부족하다는 느낌을 지울 수 없는 것 같습니다. 다음에는 더 기술적으로 완성된 프로젝트를 시도해서 명료하면서도 꽉찬 글을 작성해봐야 겠다는 생각이 드네요.
'회고와 이슈 > 회고' 카테고리의 다른 글
| [푸드피커] 프로젝트 발자취 (1) | 2024.06.16 |
|---|
