안녕하세요. 지난 글에 이어 지적 덕후생활 공동체(지덕체)개발기를 연재하고 있는 ryukim입니다.
지난 주에는 2주차 과제였던 파일 관리 운영 정책 설계, S3 파일 서버 구축, lambda함수로 배치 프로세싱, 로그 작성과 랜딩 페이지 페이지네이션에 대해서 글을 써봤습니다.
오늘은 3주차 과제를 해결하면 겪었던 시행착오와 배포과정에 대해 이야기 해보겠습니다.
알고리즘 문제가 아닌 서비스에 자료구조 적용하기
말만 어려워보였지 구현은 별거 없었다…!
저번 주 과제였던 신상품 페이지네이션에 숨은 깊은 뜻은 ‘실시간으로 추가되는 상품들을 새로고침 없이 적용할 수 있는가?’였는데요.
비전공자인데다 평소 알고리즘이나 자료구조는 취업을 위한 수단이라고 생각해 공부를 뒤로 미뤄왔던 저에게 스택이니 큐니 하는 것들은 이름만 들어도 어려운 존재들이었습니다.
하지만 이번 과제를 위해 오랫동안 사놓고 방치해뒀던 자료구조 책을 꺼내서 스택에 대해 공부했고 그렇게 크게 어려운 개념은 아니라는 것은 알게 되었습니다.
거기다 제 서비스에 적용하기 위해 DB에서 데이터를 불러올 때 스택구조를 적용하는 것은 더욱 쉬웠습니다. 지덕체에 사용되고 있는 mongoDB는 fast Paging이라는 기능이 있었고 이를 이용해 직전까지 가져왔던 데이터들의 시작과 끝 아이디를 기억해 실시간으로 추가되는 데이터들을 가져올 수 있었습니다.
이 작업에는 https://darrengwon.tistory.com/826 다음 블로그 글을 참고했으니 관심있으신 분들은 보시면 도움이 될 것 같습니다.
이렇게 새로고침 없이, 중복 없이 신상품을 페이지네이션하는 기능을 구현했습니다.
그렇게 어려울 것 같던 내용이 딱 이만큼의 코드로 완성되었습니다.
조금 더 커뮤니티답게!
아직도 헤어나오지 못한 덕밥의 늪
지덕체 프로젝트를 시작하기 전 카뎃들과 함께 덕질이 밥 먹여준다(덕밥)라는 프로젝트를 했다고 말씀드린 적이 있는데요.
지덕체의 궁극적인 목표인 비공식 굿즈의 합법적 펀딩 사이트를 처음부터 목표로 잡고 진행했던 덕밥 프로젝트는 저에게 많은 것을 남겼습니다.
물론 좋은 점들도 많았지만 가장 큰 것은 아직도 제가 상품, 판매와 같은 단어들을 지덕체 내에서 많이 사용하고 있다는 것이었습니다.
아이콘 하나 추가했을 뿐인데…
멘토님은 지금 만들고 있는 것이 무엇인지 기억하라며 늘 이 부분을 지적하셨고, 좋아요와 댓글 수 같은 아이콘을 추가하여 커뮤니티의 정체성을 확실히 하는 과제를 내어주셨습니다.
다행히 좋아요와 댓글 아이콘을 모듈화 해놓은 덕분에 과제를 내주신 그 자리에서 바로 추가할 수 있었습니다.
그렇게 아이콘만 추가했을 뿐인데 랜딩페이지부터 마이페이지까지 훨씬 커뮤니티처럼 변한 것을 볼 수 있었고, 작은 요소 하나하나가 참 많은 것을 좌우한다는 것을 느낄 수 있었습니다.
좋아요, 댓글 아이콘 추가 before(위) & after(아래)
혼자서도 뚝딱뚝딱
그 외에 추가로 커뮤니티의 필수 기능인 댓글에 등록 기능만 있고 수정과 삭제 기능이 없어 추가해야겠다고 생각하던 찰나 멘토님께서 조금 더 커뮤니티스럽게 만드는 과제를 내주셔서 이 기능을 추가했습니다.
기존의 답글 달기 기능을 조금 변형하여 수정하기 기능을 만들고 빠르게 API를 제작함으로서 수정기능을 완성했습니다.
삭제 기능의 경우 흔히 말하는 글삭튀(?)를 방지하기 위해 댓글이 삭제 되었는지 확인하는 필드를 DB에 boolean 형으로 추가하고 삭제되더라도 그 내용은 그대로 유지되도록 하는 운영 정책을 설계하여 이에 맞게 API를 제작했습니다.
기존에 만들어져있는 것들을 변형하는 연습을 많이 하다보니 점점 혼자서 찾아보지 않고 할 수 있는 것이 많아지고 있음을 느낄 수 있어 개인적으로 뿌듯한 기능 중 하나였습니다.
다음과 같이 댓글 수정과 삭제 기능을 구현하였습니다.
드디어 배포
생애 첫 도메인을 가지다
어느정도 MVP의 개발이 마무리되어 가고 있다고 멘토님께서 말씀해주셨고, 저도 이제 거의 마무리 단계라는 것을 느끼고 있었기에 배포를 해보기로 결정했습니다.
서버리스, 클라우드 서버 등 여러 선택지가 있었지만 가장 레퍼런스가 많고 이해하기 쉬웠던 클라우드 서버 EC2를 이용해 서버를 구축하기로 결정했습니다.
시작하기 전 미리 정보를 찾던 중 https 프로토콜을 이용하기 위한 SSL인증서 발급에 도메인이 반드시 필요하다는 것을 알게 되었고 어차피 서비스를 하기 위해서는 도메인 구입이 언젠가는 필요할 것이라고 생각하고 있었기에 구매하게 되었습니다.
역시 42의 가장 큰 장점은 커뮤니티에서 많은 정보를 얻을 수 있는 것 아니겠습니까? 어떤 사이트에서 도메인을 구입할지 고민하고 있다는 글을 올리자 정말 많은 분들이 답을 해주셨고, 가격 비교를 통해 최종적으로 hosting.kr에서 제 생애 첫 도메인을 구매하게 되었습니다.(광고아님)
얼마나 부족한지 다시 한 번 깨닫다
도메인을 구입한 후 route53을 이용해 라우팅하기 위한 몇가지 설정이 필요했는데요. 저는 다음 블로그 (https://velog.io/@nari120/Route53-DNS-구축.-AWS-도메인-연결하기) 글을 통해 이 작업을 쉽게 마칠 수 있었습니다.
이후 본격적으로 EC2에 nodejs 환경을 세팅하고 ssl을 적용했습니다. 이 과정에서는 다음 두 블로그
(https://velog.io/@neity16/EC2-https설정Nodejsletsencrypt,
https://openmymind.tistory.com/entry/nginx-reverse-proxy-설정-및-https-적용) 글이 정말 많이 도움이 되었습니다.
또한 42과제 중 ft_server와 ft_services를 해결한 경험이 ssl, 리버스 프록시 등을 적용하는데에 많은 도움이 되었습니다.
이까지는 잘 해결이 되었지만 여기서부터 nginx와 nodejs를 어떻게 활용할지에 대해 감이 오지 않았습니다. 웹서버, 앱서버에 대한 개념이 정확하게 잡혀있지 않았고, 개발할 때는 react와 nodejs가 각자 서버를 열어줬는데 그렇게 하면 되는 것인지, 그러면 서버가 2개 필요한 것인지 머리가 너무 복잡했습니다.
구글을 돌아다니며 여러 정보를 탐색한 후 웹 서버는 react에서 build 했을 때 생성되는 정적 파일들을 serve해주는 역할을 한다는 것, 이 외에 로드밸런싱 혹은 프록시의 용도로 사용할 수도 있다는 것, 웹서버는 바로 앱서버와 통신할 수 없어 WAS(Web Application Server)를 통한다는 것 등의 정보를 알 수 있었습니다. (https://toycrane.medium.com/web-was-서버에-대해-알아보자-34861e69ac4e 참고)
일단 하나로 만들어보자
저는 일단 가장 간단한 방법으로 웹서버인 nginx는 리버스 프록시를 위한 용도로만 앞에 두고 앱서버인 nodejs 서버를 통해 정적파일 전달과 API서버 역할을 동시에 하는 방식으로 서버를 구성했습니다.
이렇게 정상적으로 동작은 하도록 완성했지만 이렇게 구성할 경우 하나의 서버가 마비됐을 때 프론트와 백 모두 무너진다는 문제점이 있어 추후 SEO를 위한 SSR(Server Side Rendering) 적용 시 분리하기로 결정했습니다. (https://it-eldorado.tistory.com/85 참고)
이렇게 배포까지 마무리했습니다. 다음 글에서는 배포 전 마지막 멘토링이었던 4주차 과제와 그 해결과정에 대해 이야기해보겠습니다.
긴 글 읽어주셔서 정말 감사합니다!