항해 99 11주차를 끝내며

   항해 99 11주차를 끝마쳤다. 이번 주차는 프론트 엔드 서버와 본격적으로 합치는 과정이었다. 그 과정 중에 NestJS에서 지원하는 스웨거 문서 제작 툴?을 이용해 API 문서를 기초적이나마 만들었다. NestJS에서는 Data Transfer Object의 준말인 DTO를 만들어 이를 활용해 프론트엔드 서버에서 송신한 데이터를 검증할 수 있고, 이는 validationPipe를 통해 이루어진다. 이외에도 parseIntPipe, parseUUIDPipe 등등 다양한 pipe들이 존재하여 controller단에서 데이터를 안정적으로 받아올 수 있으며, 이것은 자동적으로 스웨거 문서에서 보여진다. 현재는 컨트롤러를 기준으로 하여 API들을 분류해두고, 기초적인 input에 대한 instruction만이 존재하는 상황이지만, NestJS에서 제공하는 다양한 데코레이터로 이를 훨씬 더 자세하고, 예시도 넣어서 더 가독성 좋게 작성할 수도 있으며, 그 스웨거 문서 안에서 해당 예시를 통해 실제로 서버에 API를 요청해볼 수도 있다. 

    또한, 유저가 닉네임을 설정할 때에 있어 현재 우리 조가 설정한 원칙은 중복을 허용하지 않으며, 특수문자를 허용하지 않으며 독립적인 자음 혹은 모음을 허용하지 않는다. 즉, 영어 알파벳과 자음과 모음이 결합된 형태의 한글과 숫자만을 지원한다. 또한, 그 길이는 2글자에서 6글자까지로 제한되어 있다. 이런 복잡한 조건을 단번에 만족시키기에 가장 좋은 것이 정규표현식인데, 정규표현식은 지금까지 한번도 제대로 사용해본 경험이 없어서 꽤나 방대한 양의 정보를 받아들이기가 쉽지 않았다. 인터넷에 업로드된 정규표현식을 보고 공부하였으며, 결과적으로 위의 조건을 만족시키는 방법 중에서 길이에 대한 부분은 ValidationPipe에서 길이에 대한 정보를 주어 처리하도록 하였으며, 다른 부분에 대해서는 정규표현식을 작성할 수 있었고, 그것은 다음과 같다.

const regex = /^[가-힣|a-z|A-Z|0-9]+$/

    정규 표현식은 위의 경우처럼 2개의 슬래쉬로 감싸진 형태로 선언할 수 있다. 단순히 그 사이에 정확히 원하는 문자열을 입력하는 것을 넘어서 여러가지 특수문자 등을 활용하여 넓은 범위의 조건을 걸 수 있으며, 또한 이를 간단하게 표현하는 방법도 존재한다는 큰 장점이 있다. 위의 내가 사용한 예시에서 / 뒤에 가장 먼저 나오는 ^는 문자열의 시작점에서부터 이 조건이 만족되어야 함을 의미하며, +는 내가 적어준 조건들이 최소 1번 이상 만족되어야 한다는 것을 의미한다. []은 해당 대괄호 안에 존재하는 기준들에 대해서 만족하는 것이 있는가를 판별해주는 역할을 하며, |는 or 연산자로 해당 조건들 중 하나를 만족하는 지에 대해서 검사할 수 있도록 하는 역할을 한다. 마지막으로 $ 기호는 ^와는 반대로 끝 문자열부터 매칭되는 경우를 찾아주는 역할을 한다. 즉, ^와 함께 쓰면 전체가 위 조건을 만족해야 하는 것이다. 

 

    우리 조의 프로젝트의 사진 업로드 로직은 우선 프론트엔드 서버에서 백엔드 서버로 이미지를 송신하면, 이를 백엔드 서버에서 아마존 S3 서버로 사진을 업로드하고 해당 URL을 프론트 엔드 서버로 송신하여 이용하는 방식이다. 이렇게 한 이유는 사진이 업로드되자마자 프론트엔드 서버에서 바로 URL을 받아서 이용할 수 있도록 하기 위함이며, 이를 마크다운 형식으로 하여 이미지 태크를 바로 삽입할 수 있도록 URL을 바로 내려주기로 하였다. 다만, 이렇게 하는 경우에 걱정되는 부분은 이미지를 업로드하고 나서 사용자가 해당 이미지를 사용하지 않을 경우에 이 이미지가 S3 저장소에 사용되지 않은 체로 남는다는 것이 있다. 이에 대한 해결책으로는 2가지 정도를 생각했다. 첫번째 방식은 DB에 모든 업로드되는 이미지들에 대해서 그것이 실제로 사용되는 지, 그리고 해당 파일의 S3 저장소 상의 디렉토리를 함께 저장하는 Table을 만들고, 주기적으로 해당 Table을 검사하여 이미지가 정상적으로 사용되지 않았다고 판단되는 정도의 시간이 흘렀을 때 해당 이미지가 사용되지 않고 있다는 것이 확인되면 이를 삭제하는 것이다. 두번째 방식은 아무것도 처리하지 않는 것이다. 사진을 메인으로하는 서비스가 아닌 경우에는, 사진이 업로드되는 양은 그렇게 많지 않으며, S3 저장소의 이용 요금 자체가 몹시 저렴하기 때문에 이는 비용적으로 큰 차이를 나타내지 않기 때문이다. 

 

    저번부터 꾸준히 작성하고 있는 OAUTH에 대해서 몇가지를 추가적으로 적자면, 구글 OAUTH의 경우 개발단계에서만 http를 지원하고 production 단계에서는 https를 사용하여야 https를 구현하여야 한다. 이를 위해서 https를 구현하기 위한 방법을 알아보고 있고, nginx를 통한 https 구현을 생각 중에 있다. 다만, 이렇게 하는 경우 걱정되는 점이 하나 있다. 내가 소셜 로그인을 구현함에 있어 해당 소셜 로그인 서비스 제공 업체의 API를 접근해야 하는데, 구글의 경우 문제가 생겼던 것이 accessToken을 요청하는 host와 authentication code를 요청하는 host가 서로 다를 경우 accessToken을 정상적으로 발급받을 수 없었다. 이를 고려하면, 일종의 프록시 서버인 nginx가 authentication code를 요청하게 되고, localhost로 동작될 api 서버가 accessToken을 요청하게 되는 셈이니, 구글 서버가 이를 어떻게 인식할 지 모르겠다. 물론, 둘은 같은 ec2 인스턴스에서 실행될 것이고, 따라서 ip주소는 동일하겠지만 말이다. 이 부분에 대해서는 실제로 구현해보거나, 더 공부해서 알아보아야 할 것 같다.