[SMILEGATE] 2022 winterDevCamp 후기 -2

1편 보러가기 - https://smaivnn.tistory.com/5

3편 보러가기 - https://smaivnn.tistory.com/7

개인 프로젝트

이번 스마일게이트 winter dev camp는 12월부터 2월 24일, 약 3개월간 진행되었다.

그 중 12월은 스마일게이트 측에서 제시하는 주제에 해당하는 개인 프로젝트를, 그리고 1, 2월은 팀 프로젝트를 진행하였다.

 

개인프로젝트의 주제는 아래 3가지이다.

1. URL shortener

2. Blog

3. 인증시스템

 

나는 3번 인증 시스템을 선정하였다.

 

인증 시스템을 선정한 이유는 내가 백엔드 담당으로 지원했기 때문이다.

블로그의 경우 인증 기능은 이미 해결 했다고 가정하고 진행하는 프로젝트였으며 주로 클라이언트에게 권장되었다.

또 url shortener의 경우도 해보지 않아 흥미가 있었지만 그 보다 인증 시스템 부분에서 더 배우고 고려할게 많다고 느꼈다.

 

특히, 인증 시스템의 경우 이전 홈페이지 만들기 개인 프로젝트를 진행할 때 한 번 진행 해 보았는데, 그 때 당시 로그인 및 인증 시스템을 개발하며 아쉬운 부분이 존재하였기에 그 부분을 조금 더 중점적으로 개선 시켜서 구현하고자 하였다.

설계 시작

사실 설계의 중요성은 이전 프로젝트를 진행하면서 깊게 느꼈다.

특히 백엔드 담당으로 참여 한 만큼 이번에는 리액트의 디자인적인 요소보다 백엔드 입장에서의 역할 서버 구현에 조금 더 힘을 써보고자 하였다.

 

이번에 더 신경 쓸 부분은 아래 크게 아래 두 가지이다.

1. 시작하기 전 서버의 역할을 생각해보고 주먹구구식 개발 하지 않기 (코드 흐름)

2. passport를 사용하지 않는 로컬 로그인 전략 구현하기

 

사실 2번의 경우 이미 구현해 본 경험이 있어 1. 번의 논리 흐름과 그 과정을 문서화 하여 생각해보기가 가장 컷다.

 

그 이유는 추후 팀 프로젝틀를 진행할 경우 API명세서를 정의할 것이고, 당연한 말이지만 지금껏 하던 생각나면 그대로 해보는 구현 스타일을 고치기 위해서이다.

고려할 부분

사실 인증 기능의 구현은 어렵지 않다.

하지만 여러 고려할 부분이 있긴 하였는데, 

세션, JWT 어느 것을 사용할 것인데?

세션은 서버에 유저 정보를 담는다.

유저 확인시 유저의 세션 값이 서버에 저장된 세션 값과 같은지를 파악하는 과정이 필요한데,

따라서 매 요청마다 세션 데이터베이스를 살펴보게 된다.

이 세션 ID는 특별한 개인 정보를 담고 있지는 않다. 따라서 탈취 당한 후에도 해커의 활용에 있어서 명확한 한계가 존재한다. 지금 당장 고려 할 부분은 아닐 수 있지만 만약 사용자가 많아 질 경우 서버 부하가 생길 수 있다는 부분이다.

 

JWT의 경우 서버는 토큰을 발급하는 역할을 한다. 

이 때 두가지 토큰을 주로 활용 하는데, Access Token과 Refresh Token이다.

accesstoken의 경우 주로 클라이언트의 로컬 변수 혹은 스토리지에 저장하며

refreshtoken의 경우 주로 데이테베이스에 저장하여 accesstoken을 검증하는 역할을 한다. 이 토큰들의 역할과 구현에 대해서는 블로그의 다양한 글이 많으니 찾아보도록 하자.

 

이 토큰이라는 것이 로그인에서 많이 활용되기는 하지만 이는 로그인에서만 활용 되는 것이 아니다.

JWT방식의 토큰은 '정보'를 담을 수 있다는 장점이 있다. 따라서 유저 정보 등 다양한 정보를 토큰에 포함하여 전달할 수 있다. 물론 토큰이 탈취당할 경우 내용이 유출될 수 있다는 단점이 있다.

 

하지만 이 부분에 대해서는 보안만 잘 신경 쓴다면 걱정 할 필요가 없는데, 그 이유는 아래와 같다.

캠프 진행 중 토큰의 탈취에 대한 질의에 대한 답변

사실 이 답변과 같이 1. 토큰이 탈취 당한다는 사태 자체가 문제이며. 2. 어차피 accesstoken의 유효 주기는 짧다.

 

아무튼 이러한 여러가지 부분을 고려하여 나는 JWT방식을 이용한 인증 서버를 구현하기로 마음 먹었다.

인증과 인가는 어떻게 진행할거야?

인증(Authentication)과 인가(Authorization)을 어떻게 구현할 것인가를 생각해보아야 했다.

인증과 인가는 로그인과 접근 권한이라고 할 수있다.

즉, 로그인(인증)을 어떻게 하고 이후 접근 권한(인가)을 어떻게 부여할 것인가 이다.

 

인증의 경우 우선, passport를 이용한 로컬 로그인 전략과 그냥 구현하는 로컬 로그인 전략 두 가지를 생각했다.

추후 OAuth를 구현 할 때 passport를 활용 할 수도 있지만 나는 사실 docs를 보고 그냥 api를 활용하는 것을 조금 더 좋아한다.

따라서 임의의 로컬 로그인 전략과 추후 docs를 보고 OAuth를 구현하는 방법, 즉 passport 라이브러리는 사용하지 않는 방법으로 진행하고자 하였다.

 

인가의 경우 역할 기반의 인가(role-based)를 진행하기로 하였다.

사실 가장 무난하고 정석적인 방법이다.

시나리오를 한번 써보자

1. 유저가  로그인을 하면 토큰을 발급받는다. 이 토큰에는 본인의 역할 정보가 담겨있다.

2. 여러가지 기능을 이용하고자 한다. 이때 내부적으로 라우팅을 진행하기 전에 검증 미들웨어를 거친다.

3. 이 검증 미들웨어는 유저의 토큰을 decode하여 유저 역할 정보를 확인한다. 만약 적절한 역할을 가졌을 경우 기능 이용을 허용한다.

 

이렇게 코드를 구현하기로 하였고 이를 토대로 클라이언트와 서버의 흐름을 정리한다.

클라이언트, 서버의 로그인 흐름

구현 이후

구현된 코드와 작업물은 아래 주소에서 볼 수 있다.

https://github.com/smaivnn/-smilegate-winter-dev-personal

GitHub - smaivnn/-smilegate-winter-dev-personal

주로 사용된 것은 client사이드의 axios interceptor와 server 사이드의 역할 검증 미들웨어이다.

사실 조금 더 깔끔하게 코드를 짤 수있었을 것 같은데 아쉬움이 남는다.

 

프로젝트를 진행하며 발생한 문제점, 그리고 아쉬운 부분은 주로 클라이언트 파트에서 나왔다.

처음 사용해보는 라이브러리 등에 대한 문제점이 있었다. 하지만 이 부분은 서버와 관련된 사항은 아니기에 기재하지 않으려 한다.

 

이번 개인 프로젝트는 문서화 하고 프로젝트를 좀 체계적으로 관리한다는 것이 주요 목표였기에 그 부분은 만족스럽게 진행 되었다고 느껴진다.

 

문서화에는 Notion을 이용하였다.

gitbook이라는 옵션도 있었지만 혼자 사용하여 notion이 더욱 익숙했기에 notion을 통해 천천히 api명세를 작성하여 보았다.

 

하지만 그것보다 더욱 좋은 것은 git을 통한 체계적인 관리였다.

 

현업에서 git을 통한 버젼관리, 프로젝트에서 git을 통한 관리 등을 어떻게 진행하는지 참 궁금하였는데

이번 기술 멘토님께서 본인이 사용하는 예시를 보여주셨다.

 

Branch

내가 아마 앞으로도 진행 할 토이 프로젝트(프로젝트)를 가정한다면, 브랜치는 단계를 나타낸다.

예를들어

1. 로그인/회원가입

2. 역할 검증 미들웨어

3. CRUD의 구현

4. 소켓서버 구현

5. 세션서버 추가

등과 같이 목표를 나누어 브랜치를 구성한다.

이후 

 

해당 부분의 이슈에 대해서는 Issues탭을 활용한다.

 

사실 github 활용에 익숙하지 않은 나였기에 이처럼 현직 멘토님들이 현업에서 어떻게 일을 하고 툴을 사용하는지 보고 배우는것 만으로도 큰 도움이 되었다.