진행한 내용

백엔드 및 프론트엔드 배포 + 테스트

갑자기 배포?

지난 포스팅 마무리에 말하긴 했지만 한 번 더 말해보려 합니다. 배포를 하고 다시 잡을 할지, 작업을 다 하고 배포를 할지 고민을 해 보다가 배포를 하고 피드백을 받으며 작업을 계속 진행하자!! 라고 생각되었습니다. 우선 배포 전에는 40% 정도 프로젝트가 진행되었다고 생각하고 배포 작업을 진행했습니다.

프론트엔드 배포

프론트엔드 배포는 Vercel 을 이용하였습니다. Next.js 공식문서의 Deployment 쪽을 보면 아래와 같은 문구가 나옵니다.

Managed Next.js with Vercel

Vercel is the fastest way to deploy your Next.js application with zero configuration.

아직 제 애플리케이션 자체가 크지도 않고 찾아보니 배포 방법도 상당히 간단해 보여서 "그래 공식 문서에서 언급까지 됐는데 Vercel에 하자!!" 이러고 작업을 진행했습니다.

그리고 직접 해 보니 배포 작업은 매우 간단했습니다. 회원가입 이후 Add New > Project 를 눌러 하라는 대로만 진행했습니다. Github을 연결하면 아래와 같은 화면이 나옵니다.

Project Name 은 그대로 두시고 Framework Preset은 Next.js로 작업했으니 Next.js 를 선택해 주었습니다. 다음은 Root Directory인데 처음엔 ./ 로 초기 설정이 되어 있습니다. 하지만 제 프로젝트는 back/front 폴더로 나뉘고 front 폴더가 클라이언트 측의 root 폴더 이기 때문에 front를 선택해 주었습니다.

아래를 보면 Environment Variables가 보이는데 앱을 개발할 때 .env에 넣었던 데이터를 넣어줘야 합니다. 기본적으로 Vercel은 Github 연동이고, 보통 개발자들은 .env 파일을 github에 올리지 않기 때문에 Vercel에서 환경 변수 설정을 해 주어야 합니다.

이 상태로 아래 Deploy 버튼을 눌러 배포만 해주면 끝입니다. 빌딩 과정에서 몇 번의 에러가 있었는데 딱히 임팩트가 남던 에러들이 아니었는지 기억도 안나고 금방금방 고쳤던 것 같네요...

그렇게 Deploy 가 성공하니 백엔드 연동은 안되는 제 페이지가 화면에 나타나게 되었습니다!!

백엔드 배포

백엔드 배포는 Heroku 를 사용했습니다. 사실 백엔드 배포는 AWS EC2 를 사용하려 했습니다. 실제로 시도도 했고요. EC2 인스턴스 생성 후, 일련의 과정을 거쳐 배포를 했으나... 어떤 에러 때문인지 통신이 되지 않았고 결국 에러를 고치지 못해 다른 방법을 찾아보았습니다. 그러다 Heroku 에 배포하게 되었는데 확실히 과정 자체는 AWS보다 쉬웠습니다. Heroku CLI 설치 후 과정대로만 하니 바로 배포가 되었습니다. 이 내용은 인터넷에 정말 쉽게 잘 나와있어서 그냥 넘어가겠습니다. Heroku 또한 Github과 연동해 배포하는 방식으로 배포했기에 더 쉬웠던 것 같습니다. 하지만... AWS에서 나타난 문제가 그대로 생겼습니다. Heroku에서 배포한 이후에도 그 말인 즉, AWS 에 대한 무지 때문에 에러가 났던게 아니었다는 건데... 라면서 여기저기 보다보니...

ㅋ... api 주소를 제가 잘못 입력하고 통신을 계속 시도하고 있었더라고요... 등ㅅ....

저는 예를 들어 폴더 구조가 /routes/api/user.js 이렇게 되어 있을 때 저는 이를 /api/user 로 줄여서 사용할 수 있도록 예전에 세팅을 해 두었습니다. 그런데 그냥 그대로 /routes/api/user 이렇게 주소를 두고 했었고, 이것만 고쳤더니 통신이 잘 되었습니다. AWS에 그대로 두었어도 잘 됐겠더라고요..

배포 이후

어찌됐든 이렇게 웹사이트 전체가 배포 완료 됐고, 이전까지 작업했던 내용들 또한 문제 없이 돌아가는 것을 확인했습니다. 하지만 역시.. 배포 완료 이후 웹에는 문제가 참 많았습니다. 여러 군데서 에러 처리가 안 된 부분들이 많았고, 하다못해 데이터가 없을 경우 띄울 화면도 만들지 않은 곳도 많았습니다. 배포 이후 당연히 통신하는데 시간이 걸렸기에 Loading에 관련된 부분도 다시 한 번 체크가 필요했습니다. 그렇게 여러 군데 테스트를 하다 보니 "이제 40% 정도 진행한 것 같은데?" 라고 생각했던게 "...20%도 안된 것 같은데?" 로 바뀌게 되었습니다.

애초에 웹사이트 하나에만 6개월을 잡고 시작한 프로젝트입니다만... 아무래도 회사를 다니기도 하고 제가 취미생활이 좀 많은지라(보컬도 다니고.. 테니스도 치고... 게임도 해야되고....) 많이 뒤쳐졌습니다. 물론 개발은 계속 진행되어 가고 있고 중간에 포기할 생각은 이제 아예 들지도 않습니다. 배포를 하고 나니 더 불타오르게 되는 효과도 있고요.

하지만 문제는 수익성은 둘째치고 사용자도 없을 개인 프로젝트를 1년 넘게 잡고 있는게 맞는가 였습니다. 심지어 앞으로 더 바빠질 예정이기 때문에 이 프로젝트를 이렇게 오래 잡고 있는건 아니라는 생각이 들었고, 고민 끝에 프로젝트 범위를 줄이기로 결정했습니다.

현재 프로젝트는 Feed, Notice, Event, Album, Playlist로 구성되어 있습니다. 그 중, Feed, Notice 부분에 대한 CRUD 및 대부분의 작업 및 배포가 완료 된 상태입니다. 하지만 구성을 잘 생각해보면 Event는 Notice에 포함될 수 있을 것 같습니다. 그렇기에 Event는 없애려고 합니다. 또한 Playlist도 없애고 Album 까지만 작업 이후 자잘자잘한 엄청나게 많은 것들을 수정하려 합니다.

그럼 이제 남은 부분은 Album 에 대한 작업입니다. 아직 기획도 되어 있지 않기에 아마 기획하고 또 맞는 디자인 찾고 하다보면 시간이 좀 걸리지 않을까 생각은 하지만 그래도 어차피 CRUD이기에 그렇게 오래 걸리진 않을 거라고 생각됩니다.

친구들 반응

배포 이후 회사 동기 1명, 고등학교 친구 1명, 이 프로젝트 대상인 중학교 친구 2명에게 한 번 봐주라 라고 얘기했습니다. 회사 동기분은 확실히 개발자여서 그런지 여러 피드백 및 수정했으면 좋겠는 부분에 대해 말해주셨습니다. 고등학교 친구는 발견하지 못했던 에러를 발견해 줬으며, 프로젝트 대상인 중학교 친구 2명은 쓰레기네^^ 라는 답변을 내놓았습니다.(미친놈들이) 물론 중학교 친구들한테는 까먹고 웹으로 들어가란 소리를 못해서 둘 다 모바일로 들어가보았다고 합니다. 웹 화면을 그대로 모바일로 보고 있으니 쓰레기란 소리가 절로 나올 수 밖에 없습니다. 그래도 이런 피드백을 받는 과정이 그저 재밌기만 합니다. 회사 프로젝트에서 피드백을 받을 때는 참... 그랬는데 제 프로젝트라 그런지 피드백을 받고 생각하고 맞게 수정하고 수정됐다고 하니 또 가서 보시고 리액션하는 일련의 과정들이 너무나 재밌더라고요. 그래서 더 노력해서 쓰레기가 아닌 웹앱을 만드려고 합니다

마치며

회사 프로젝트 배포 과정은 지켜봤지만 제가 직접 배포를 진행한 것은 처음입니다. 이 전에 개인 프로젝트나 팀 프로젝트도 어지간히 많이 했지만 항상 다 만들고 배포는 못했었는데 최근에 Velog에서 제발 프론트엔드 개발자면 배포 좀 해서 링크좀 올려달라는 글을 보고 '당연한건데 왜 난 이때까지 안그랬지...?' 란 생각을 하게 되었습니다. 결국 프론트엔드 개발자는 화면을 보여주는 역할이기에 화면을 포트폴리오에 기입하는게 당연한 건데 이제까지 그러지 않았던 제가 너무나 쪽팔렸습니다.

어찌됐건 저찌됐건... 앞으로의 나야 화이팅이다^^