부스트캠프 웹・모바일8기(boostcamp) 그룹 프로젝트 2주차 회고

초기 세팅

팀 프로젝트를 진행하며 적용할 계획 및 백로그, 팀 그라운드 룰을 작성했고 이제는 같은 분야 백엔드 캠퍼와 호흡을 맞춰야 했다.

우선은 TypeScript 언어를 사용하며 Nest.js 프레임워크를 사용할 계획이었기에 Prettier와 Eslint 설정을 맞췄다.

ex : Prettier 설정

함께 이야기를 나누며 어떤 규칙을 적용할 것인지 서로 편한 방식으로 합의하였다.

그리고 프로젝트 주제에 맞는 어떤 기술을 적용할 것인지에 대한 기술적 고민에 대해서 얘기했다.

기술적 고민 규칙

1. 단순히 하고싶은 것보다는 왜 하고싶은 지에 대해서 고민해보기.
2. 같은 기능을 하는 프레임워크 또는 라이브러리에 대해서 선택하는 이유를 생각하기.
3. 해당 기술을 사용하지 않는다면 직접 어떤 방식으로 구현해 볼 수 있을까 생각하기.

Ncloud 서버 구축

NCloud를 이용한 웹 어플리케이션 서버 및 데이터 베이스 서버를 구축해야 했다.

아래도 정리해 두었으나, 자세한 내용은 https://velog.io/@rmsgur/cloud-serviceserverless-application 를 참고하자

그 전에, 백엔드 인원들과, 안드로이드 인원들이 사용할 계정을 sub계정으로 각각 만들어 사용을 구분했다.

다음으로 , 백엔드 계정으로 NCloud의 어떤 서버를 이용할 것인지를 선택했다.

웹 어플리케이션 서버는 Ubuntu Public 서버로써, 공인 IP를 받아 사용할 계획이었으나, DB서버를 선택하는 것에 고민이 되었다.

Cloud DB for PostgreSQL과 같은 DB 기능지원을 하는 서버를 사용해보고 싶기도 하였으나, 비용적인 측면과 일반 VPC 서버를 DB서버로 만들어 관리해보는 것이 프로젝트를 운영하고 관리하는 경험에 도움이 더 될 것 같다는 판단을 했다.

VPC 서버를 이용하기로 했는데, Classic 서버로는 DB와 같은 서버를 private 서버로 만들기가 어렵기 때문이었다.

우리는 하나의 VPC를 생성하고, 내부에 Public, Private 서버로 분리하여 Public에는 WAS, Private에는 DB를 두어 VPC 내부의 Public에서만 Private서버와 통신이 가능하도록 구현하기로 했다.

VPC Management를 통해서 VPC를 생성했는데 CIDR 블록은 일반적인 10.0.0.0/16을 사용했다.

다음으로는 Subnet을 생성했다. Public, Private 각각의 subnet을 생성해주었다.

이후 ACG를 설정해 각 서브넷의 인바운드, 아웃바운드 허용 규칙을 정해주었다.

여기서 나중에 발견한 하나의 실수가 있었다.

바로 하나의 ACG를 두 서버에 모두 적용한 것이었는데, 이는 DB서버가 VPC 내 Private서버더라도 WAS 서버의 인바운드 규칙과 같은 규칙을 적용하는 것이 Private를 관리하는 측면에서 굳이 열어도 되지 않는 포트를 더 연다는 느낌이 들어 이를 각 서버의 ACG로 분리하였다.

Nest.js 시작

Ncloud 서버를 구축하고, Prettier와 Eslint 적용을 제외하고 본격적인 개발을 시작했다.
첫 Api endpoint 처리 함수 구현은 페어 프로그래밍으로 함께 개발하기로 했고 해당 부분은 '회원가입' 부분이었다.

우선 nest 에서 모듈 및 컨트롤러를 생성하고 컨트롤러에서 호출하는 서비스 함수를 작성했다.

이런 과정에서 Nest.js 서버가 DB와 통신을 해야했는데, 우리는 DB 서버를 VPC 내 private서버로 두어 로컬 개발환경에서 통신할 방법이 없었고 이를 로컬 환경 DB로 대체하기로 했다.

그러다 각 feature 개발이 완료되고 develop/be 브랜치 및 relesase 브랜치로 병합이 된다면 이를 public 서버로 옮겨 확인하기로 하였다.

기술적 도전

위에서 말한 것과 같이 이번 주 기술적 도전 사항들에 대해서 나열해보려 한다.

1. Object-Relational Mapping

• 선택 이유

  • ORM을 사용하면 복잡한 SQL 쿼리를 작성하는 대신 객체 지향적 방식으로 데이터베이스 작업을 수행할 수 있기에, 코드를 더 읽기 쉽고 유지 보수하기 쉽게 만들었다.
    
    
  • 기존 멤버십 과정의 Vanillat JS 에서 MySQL을 이용해 직접 쿼리문을 작성하여 실행해본 경험과 이번 ORM을 통해 두 방법의 비교를 해보고 싶었다.

• typeorm 과 prisma 중 왜 typeorm을 선택했는가?

  1. 우리 백엔드 분야 캠퍼 2명은 ORM을 사용해 본 적이 거의 없다시피 했기에 학습할 자료가 많이 필요하다고 판단하였고, 이에 더 오래 존재했던 TypeORM이 관련 문서가 더 많을 것이라 생각해 선택했다.
     
     
  2. Prisma는 Prisma 스키마 파일을 사용하여 모델을 정의하고, TypeORM은 TypeScript 클래스와 데코레이터를 사용한다. typeScript를 이번 멤버십 과정을 통해 처음 사용하기 시작한 만큼 조금이라도 더 적용해보고 싶었기에 TypeORM을 선택했다.

2. Response Interceptor

• 선택 이유

  • 개발을 하며 협업이라는 부분에서 서버가 주는 응답을 프론트 개발자가 좀 더 쉽게 접근 할 수 있으면 좋겠다는 생각을 했고, 에러와 성공응답의 데이터포맷이 일치하는 방법을 적용하면 좋겠다는 생각을 가지다 이 방법을 찾게 되었다.
    
    
  • 모든 응답을 특정 JSON 구조로 래핑하거나 추가 메타데이터를 포함시키는 경우, Response Interceptor를 사용하여 이를 효율적으로 관리할 수 있었다.
    
    
  • 2번째 멤버십 프로젝트에서 모든 서버 구조를 net 모듈로 구현하면서 응답 구조를 직접 구현해야 했는데 그 때의 response make를 담당하는 클래스를 통해 통일된 구조의 응답을 생성하는 부분이 이 response Interceptor과 비슷하게 느껴지기도 하여 사용해보고 싶다고 생각되었다.

3. Guard

• 선택 이유

  • 서버에서 발급한 jwt를 포함한 요청을 클라이언트가 보냈을 때에, 모든 엔드포인트에서 이러한 jwt의 유효성 검증을 하는 것은 비효율적이라고 판단되었고, 이를 모든 요청이 먼저 거치는 미들웨어에서 하는 것이 효율적이라고 생각되었다.
    
    
  • 그러나, jwt토큰을 검증하지 않아도 되는 요청 ( ex : 회원가입, 로그인 ) 을 기존 프로젝트에서는 whitelist 를 만들어, 해당 리스트에 포함되는 url에서는 토큰 검증을 하지 않도록 했었는데 이러한 개념을 nest에서 적용한 것이 Guard 데코레이터인 것으로 이해되어 사용하는 것이 좋다고 판단했다.

4. PostgreSQL

• 선택 이유

  • PostgreSQL은 대규모 트랜잭션과 복잡한 쿼리 처리에 더 강점을 가지고 있다. 이는 사용자와 데이터가 많은 음식점 공유 플랫폼에서 중요한 요소가 될 수 있다 판단하여 선택하게 되었다
    
    
  • PostgreSQL의 extension 인 PostGIS가 제공하는 상세한 공간 쿼리 처리 ( ex : 거리 계산 ) 및 추후 확장성 ( ex : 특정 지역 내 음식점의 밀도 )를 생각했을 때 기본적인 공간 쿼리와 데이터 처리를 지원하는 MySQL보다 더 나은 이점이 있다고 판단되었다.

정리 및 후기

이번 주는 개발 환경을 세팅하는 시간이 더 많았던 것 같다. 직접적인 api 구현은 회원가입 과 마이페이지, 로그인 이었는데 6주라는 시간에 모든 기능을 구현할 수 있도록 부지런히 움직여야겠다는 생각이 든다.

페어 프로그래밍을 통해서 늦어졌던 부분이 있지만, 이것이 결코 끝까지 가는 속도라고는 생각하지 않는다. 오히려 지금 많은 부분을 서로 맞춰놓았기에 더 빠르게 치고 나갈 수 있지 않을까 라는 생각이 든다.

부스트캠프 챌린지 때 잤던 시간과 비슷해지는 것 같은데, 그만큼 더 자기관리에도 신경을 써야겠다!