시작하며
이번 프로젝트에서 배포 관련한 작업을 모두 도맡아 진행했다.
아무래도 FE팀원분은 경력직이라 해당 경험이 있었지만, 나에게 부족한 지점 중 하나가 이 지점이라 생각했기 때문이다.
직접 마주하며 시행착오를 겪어봐야 알 수 있는 부분이라 생각하여 담당하게 되었고, 덕분에 느낀점이 좀 있었다.
진행 과정에서 있던 일을 많이 적을 순 없으나, 잊어버리기 아쉬운 기억이라 기록한다.
회고
Netlify - 스테이징
기존에는 Upstream 레포지토리를 두고, 개별로 fork해서 개발 후 Upstream/main에 바로 배포해버리는 방식을 사용하고 있었다.
배포 단계에 가까워지기 전에는 불필요한 작업을 최소화하자는 의견에 의해서였다.
데모 데이가 다가오자, Upstream/dev를 생성했는데 막상 AWS를 사용하기는 아까웠다.
BE 팀에서는 무료 도메인을 얻어 무료에 가깝게 사용하고 있다는 것을 듣고, 무료 배포 방식을 찾아봤다.
물론 Vercel을 사용하는 것이 제일 간편했으나, 안해봤던 서비스를 사용하고 싶었고 Netlify를 사용해보게 되었다.
Vercel과 Netlify모두 Serverless 방식이었기 때문에, 불편한점이 많지는 않았다.
다만 Vercel에 비해 처리할 작업이 존재했는데, netlify.toml를 통해 플러그인을 적용해야 했다.
Vercel과 마찬가지로 Edge Functions를 통해 서버 액션 등을 처리하고, 단순 정적 파일들을 호스팅하는 것이 아니라 SSR에도 대응할 수 있다는 것을 알게 되어 신선했다.
시연하면서 느꼈던 단점은, 아무래도 Cold-Start로 인해 성능이 좋지 않았다는 것이다.
우리 서비스처럼 동적 라우팅이 많고 사용자 수가 적으며, BE 서버도 좋지 않은 상황에선 크게 느껴지게 되었다.
이에 Production 단계에선 EC2를 사용하기로 했다.
EC2 + Docker + Nginx - Production
성능을 조금이라도 끌어올리기 위해 EC2를 사용하게 되었다.
Netlify에서는 도메인 네임을 설정하 수 있었기 때문에 편리했으나, EC2를 사용하기 위해선 무료 도메인을 구해야 했다.
또한, 다른 팀들에서 Docker를 사용하는 것을 보고 도입해보자는 생각을 했다.
Docker를 제대로 사용해보는 것은 처음이었기 때문에 좋은 기회라 생각했다.
EC2 배포 자체는 경험이 있었기 때문에, 설정 과정은 어렵지 않았으나 Docker를 같이 사용함으로 인해 얻는 이점이 커보였다.
우선 EC2 Free Tier를 사용했기 때문에 컴퓨팅 성능이 매우 제한적이었는데, 때문에 CD 과정에서 종종 에러가 발생하곤 했다.
직접 레포지토리를 사용해 빌드 및 배포를 하는 과정에서 인스턴스가 메모리 이슈로 중단되어버리는 것이다.
그러나 Docker를 통해 빌드한 이미지를 Docker Hub에 업로드하고, EC2 인스턴스에서 이를 다운 받아 실행하는 것으로 메모리 이슈 없이 배포를 해결할 수 있었다.
이러한 CD 과정을 github actions를 통해 자동화 했다.
Nginx는 TLS인증이 간단하고, 리버스 프록시가 더 깔끔하기 때문에 사용하게 되었다.
certbot만 따로 운영하여 처리하기엔 비용이 너무 컸다.
이 역시 처음 사용해보았는데, 과정을 따로 외운다기 보다는 그 때 그 때 찾아보는 것이 좋아보였다.
역시 설정 파일을 잘 처리해야 했던 것이다.
추후, 고도화 작업에서 HTTPS/2로 변경하였는데, 과정이 매우 간단했다는 점은 인상 깊었다.
마치며
배포 관련해서 있었던 일과 느낀점을 간략하게 적어보았다.
이 부분에 있어서 크게 할 말은 없기 때문에, Motimo를 제작하며 그리고 Prography를 수료하며 있던 것들 중 남은 것들을 정리하겠다.
사실 주요한 기술적 이슈 및 해결은 포트폴리오에 적었기 때문에 기술적으론 할 말이 많지는 않다.
정말 버리기 아까운, 내 노력이 많이 들어갔던 것들에 대해 작성하고자 이번 시리즈를 시작하게 되었던 것이다.
그 외에, 진행하면서 느꼈던 점들이 몇 가지 있다.
우선, 어떤 것을 하든 본인이 하는 것에 따라 얻어갈 수 있는 것들이 다르다는 점이다.
예를 들어, 다른 팀들이 어느정도로 했는지는 정확히 모르지만, 디자인 시스템을 도입하는데 꽤 많이 공을 들였고, 이는 포트폴리오에 쓸 좋은 경험이 되었다.
면접에서도 도움이 될 경험들이 많이 쏟아져 나왔고, 덕분에 채용 자소서를 작성하고 면접을 준비하는데 큰 도움이 되었다.
어떤 것이든 얼만큼 고민하고, 시도하고, 노력하느냐에 따라 가치가 바뀌는 것 같다.
또한, 인간관계를 비롯한 소프트 스킬의 중요성도 느꼈다.
우리 팀은 서로 서먹한 쪽에 속했다. 서로 어느정도 농담도 하고 만나면 잘 이야기 했지만, 그 외에는 딱히 더 만나는 등의 활동이 없었다.
다른 팀의 경우 다같이 MT도 참가하고 정규 날짜 이외에 따로 프로젝트 회의 등을 위해 모이는 등의 추가적인 노력으로 끈끈함이 보이는 듯 했지만, 우리는 그정도는 아닌 듯 했다.
프로젝트를 유지하고 수익화를 위해 나아가겠다는 몇몇 팀들과는 분위기가 달랐던 것이다.
물론, 마지막 시간에 보니 우리보다 상황이 좋지 않았던 팀도 있어보이긴 했지만, 이들과 비교하는게 무슨 소용이 있겠는가.
조금 더 잘 소통하는 것이 팀적으로 프로젝트를 진행하는데 있어서 얼마나 중요한지 깨닫게 되었다.
마지막으로, 이러한 IT 커뮤니티의 한계를 느끼기도 했다.
솔직하게 처음에 지원할 때는 다른 경력자 분들께 엄청나게 배울게 많다고 생각했으나, 그렇지는 않았다.
다들 프로젝트를 진행하느라 바쁘기도 했고, 여러 프로젝트를 동시에 진행하고 계시는 분들도 많았기 때문에 시간적 여유가 부족했다.
또한, 소위 '네카라'와 같은 고수로부터 사사받는 상황은 망상에 가까웠다. 대부분 IT 커뮤니티를 이용하는 사람들은 빠르게 사이드 프로젝트를 제작하고자 하는 사람인데, 이는 이직을 위함이 대부분이기 때문이다.
고수들이 과연 이직을 위한 포트폴리오를 IT 커뮤니티를 통해 얻을지는 의문이다. 상황상 본인의 프로젝트에선 이직하고자 하는 영역의 경험을 얻기 어려울 경우도 있겠지만, 이러한 사이드프로젝트를 통해 충분한 경험을 쌓기는 어려워보였다.
이러한 구조적 한계로 인해 고수로부터 사사받는 기대는 접는 것이 낫다. 차라리 인맥을 얻는다고 생각하는 편이 마음이 편할 것이다.
시스템을 보려고 노력한다면 보이는 것들이 있는 듯 했다.
이상으로 느꼈던 점들을 최대한 정리해보았다.
밤샘 코딩도 해보고, 스트레스도 받고, 이슈들도 해결하면서 결과적으로 좋은 경험과 결과물을 얻었다.
어떤 활동을 하든 스스로 높은 결과물을 얻고 가치를 창출하기 위해 고민하고 나아가야 할 것임을 명심하며 이만 시리즈를 마치겠다.
