[정글]열네째주. 서버개발자로서의 첫 고민
나만의 무기 프로젝트 팀에 합류하다
정글 커리큘럼의 끝에는 서비스 개발 프로젝트가 있다. 팀원들과 함께 소프트웨어 서비스를 만들어서 배포하고, 사용자를 모아 테스트하며 지속적으로 개선하고, 최정적으로 완성물을 발표하는 과정이다.
정글에 온 가장 큰 이유는 CS 지식을 공부하는 것이었고, 두번째 이유는 바로 이 프로젝트였다. 이전에 두번정도 직접 팀원들을 모아서 사이드프로젝트를 운영해봤었지만 원하는 만큼의 완성도가 나오지 않아서 많이 아쉬웠었는데, 이번에는 꼭 완성도 높은 결과물을 만들고 싶었다.
결론적으로, 메타버스 서비스를 만드는 팀의 일원이 되었고 포지션은 서버개발자를 맡게 되었다. 이번 글에서는 그 과정에서 고민한 것들을 적어보고자 한다.
1. 팀장인가 팀원인가
팀 형성 전에, 팀장이 되고 싶은 사람들이 직접 지원할 수 있는 시간이 있었다. 스스로를 리더보다 팔로워에 더 적합하다고 판단하고 있었기 때문에 팀장에 지원하지 않았다. 리더에게 필요한 넓은 시야가 나에게는 부족했다. 팀장이라면 자신의 일에 완전히 빠져들기보다는 주변을 두루 살필 줄 알아야 한다. 하지만 경험상 나는 일에 완전히 몰입해서 주변상황이 어떻게 흘러가는지 몰랐던 적이 몇 번이나 있고, 만약 리더가 되고자 한다면 반드시 개선해야 할 부분이라고 생각하고 있다. 물론 주변을 살피는 능력은 팀원에게도 어느 정도 필요하기에, 이틀에 한번씩은 팀 노션을 전체적으로 살펴본다거나, 서로에게 방해가 되지 않는 선에서 중간중간 간단한 회의시간을 갖자고 제안하는 등의 노력을 하고 있다.
2. 프론트인가 서버인가
팀과 아이템이 정해지고, 포지션을 논의하는 시간이 왔다. 프론트엔드 개발을 1년 정도 해본 입장에서 이번에는 새로운 도전을 해보고 싶어서 서버 개발을 하겠다고 자원했다.
자바스크립트 언어를 주력으로 사용해왔기에 기술스택은 nodejs 프레임워크 중에서 하나를 선택하기로 했고, 팀원들과 함께 nestjs와 비교해본 끝에 적은 코드 양으로 서버를 구축할 수 있는 express 를 채택했다.
또한 프레임워크를 반드시 사용해야 하는가에 대해서도 살펴보았는데, 미들웨어 처리의 간편함만으로도 express를 사용하는 것은 당연해보였다.
3. 배포는 어디서 할지
aws, heroku
서버개발을 시작해보니 프론트엔드 개발자와는 고민의 방향이 달랐다. 프론트엔드개발은 맨 앞에서부터 고민을 시작했다면, 서버개발은 맨 뒤에서부터 앞으로 고민을 하는 느낌이었다.
일주일 후에 있을 시연은 어떤 url로 사람들에게 보여질 것인가?
여러 명이 동시에 소켓통신하는 서비스를 개발하는 데 있어서, 효율적인 테스트 환경을 어떻게 구축할 것인가?
API 를 통해 얻은 데이터는 어디에 저장할 것인가?
일련의 고민을 하면서, 배포와 DB 구축을 가장 먼저 해두는 것이 좋다고 판단했다. 논의 끝에, DB 에 정보를 저장하고 빼오는 기능은 추후로 미룰 수 있다고 결정이 나서 일단 프론트서버와 백엔드서버 배포부터 진행했다.
배포는 처음이었기에 서칭을 많이 해봤고, 많은 사람들이 사용하는 조합으로 배포했다. 대안으로는 s3버킷에 직접 빌드폴더를 올려주는 방식도 있었는데, 배포할 때마다 직접 빌드해서 일일이 build 폴더를 올려주어야한다면 너무 번거로울 것 같았다. 그밖에 netlify라는 서비스도 있었다.
react 서버 배포는 aws의 amplify라는 클라우드 컴퓨팅 서비스를 이용했고, nodejs는 heroku 클라우드 컴퓨팅 서비스를 이용했다. 같은 플랫폼에서 둘다 배포할 수도 있었지만 다양한 서비스를 사용해보고 싶었다. 가격플랜은 amplify의 경우 무료, heroku는 매달 7달러로, 한달정도 사용하기에는 둘다 괜찮았다. 또한 두 서비스 모두 github 브랜치에 연결해두면 새로운 커밋이 올라올 때마다 자동으로 배포해준다는 점이 매력적이었다. ( 사실 heroku 에 올린 앱은 결국 aws로 호스팅된다고 한다. 그래서 요금이 aws보다 저렴할 수 없다 )
https://kinsta.com/blog/google-cloud-vs-aws/로컬호스트로 테스트할 때는 직접 https 인증서(ssl)를 발급해서 테스트해보고 있었는데, 배포버전에서는 두 서비스를 이용하면서 자연스럽게 https 연결이 해결되었다. 헤로쿠의 경우 유료플랜(basic이상)을 이용하면 Automated Certificate Management (ACM) 이라는 서비스를 적용해서 자동으로 보안연결을 지원해주고, aws amplify 역시 https 연결을 지원하며 사용자가 구매한 커스텀 도메인에 대해서도 적용해준다.
4. 도메인을 살 것인가 말 것인가
백엔드서버뿐 아니라 클라이언트 서버를 heroku로 배포했다면 도메인을 굳이 사지 않더라도 heroku.com이라는 예쁜 도메인으로 호스팅해주어서 좋았을 것 같다는 생각이 뒤늦게 든다. amplify에서 호스팅해주는 url은 알아보기 힘들었고, 가비아에서 도메인을 사서 amplify에 붙였다. 앞서 언급했듯, 커스텀 도메인을 연결해도 https 연결이 지원된다.
5.현재 하고 있는 고민들
어떤 데이터베이스를 사용하는 게 좋은가
이건 지금 하고 있는 고민이다. 관계형 DB mysql을 사용하면 단점이 있을까? 다들 너무 당연하게 nodejs + mongodb를 붙여서 사용하고 있는데 여러가지 DB 를 사용하고 비교해보지 않아서 장단점이 명확하게 와닿지 않는다.
CORS 문제가 발생하지 않도록 해야 한다
이전에 토이프로젝트로 프론트엔드 개발을 하면서 API 통신을 할 때 CORS 문제가 숱하게 발생했고 해결에 어려움을 겪었었다. 웹 브라우저는 현재 url과 API를 통해 받아온 리소스의 출처 url(백엔드서버)가 다르기 때문에 Same Origin Policy 위반이라고 판단하고 리소스를 사용하는 것을 허용하지 않음으로서 브라우저의 안전을 보장한다. 다른 Origin의 데이터를 읽고 싶으면 브라우저와 서버 간 통신시 헤더에 CORS 설정을 추가해서 출처가 다른 리소스임을 명시하고 허용하도록 해주어야 한다.
이번에는 이전 경험을 바탕으로 fetch 함수 사용시 mode에 cors를 명시하도록 했다. 그리고 서버 쪽 처리방법을 찾아보니 express의 cors 미들웨어를 통해 cors 처리를 할 수 있었다.
Photo by Adrien Ledoux on Unsplash
참고자료
https://ko.javascript.info/fetch-crossorigin#ref-197
https://fetch.spec.whatwg.org/#http-cors-protocol
