STORIFY (0215) - session 적용

카카오톡 로그인 시 유저 정보를 클라이언트에 전달하기 위해서는 session을 사용해야 할 듯해서 적용한다. 

 

 

의문: session.module.ts를 추가하는 이유가 뭘까 그리고 추가해서 어떤 기능을 사용해야 할까. 현재 사용하고 있는 mongodb를 사용해 session을 저장하는 곳을 만드는 것일까?

 

`session.module.ts` 파일을 추가하는 이유는 세션 관리를 위해서이다. 웹 어플리케이션에서 세션은 사용자가 서버에 접속한 이후부터 브라우저를 닫거나 로그아웃하기 전까지 유지되는 상태를 말한다. 이 세션을 관리하기 위해서는 세션 데이터를 저장할 공간이 필요하며, 이러한 공간을 세션 스토어라고 부른다. `connect-mongo`는 이러한 세션 스토어를 MongoDB에 저장하기 위한 미들웨어이다. 따라서 `connect-mongo` 패키지를 사용하면 MongoDB를 세션 스토어로 사용할 수 있다. 현재 코드에서는 `connect-mongo`를 통해 MongoDB에 세션 데이터를 저장하도록 설정하고 있다. 이렇게 하면 사용자가 로그인한 후에 서버가 사용자의 세션 데이터를 MongoDB에 저장할 수 있다. 그리고 사용자가 다음번에 접속할 때는 이 세션 데이터를 통해 사용자를 인식할 수 있다. 따라서 `session.module.ts` 파일을 추가하고 `connect-mongo` 패키지를 사용하는 이유는 사용자의 세션 데이터를 MongoDB에 저장하고 관리하기 위해서이다.

 

 

 

의문: 카카오톡처럼 외부에서 유저 정보를 받아서 사용하려면 session을 사용하는 게 제일 효율적일까?

 

외부 서비스에서 사용자 인증을 받을 경우(예: 카카오 로그인, 구글 로그인 등), 사용자의 세션을 관리하는 것이 효율적이다.

1. 보안: 사용자의 로그인 정보를 서버에서 관리하면, 사용자의 중요 정보가 클라이언트 사이드에 노출되는 것을 방지할 수 있다.

 

2. 상태 유지: 사용자가 로그인한 상태를 유지할 수 있다. 예를 들어, 사용자가 사이트를 이용하다가 잠시 다른 사이트를 방문한 후에 다시 돌아와도 로그인 상태가 유지된다.

 

3. 사용자 경험 향상: 사용자가 로그인한 상태를 유지하면, 사용자는 매번 로그인할 필요 없이 서비스를 이용할 수 있다. 따라서 외부 서비스에서 사용자 인증을 받을 경우에도 세션을 사용하여 사용자의 로그인 상태를 관리하는 것이 효율적이다.

 

그러나 세션 관리도 서버 리소스를 사용하므로, 사용자 수가 많아질수록 서버 부하를 관리하는 데 주의해야 한다. 이를 위해 Redis와 같은 인메모리 데이터베이스를 사용하여 세션 데이터를 저장하는 방법도 많이 사용된다.

 

 

 

 

의문: 기존의 'nestjs-session'를 사용하지 않고 따로 SessionModule를 만드는 이유는 뭘까?

 

`nestjs-session`의 `SessionModule`은 세션을 설정하고 관리하는 기본적인 기능을 제공합니다. 그러나 이 모듈만으로는 세션 데이터를 MongoDB에 저장하는 것은 지원하지 않습니다. 따라서, `connect-mongo`를 사용하여 MongoDB를 세션 스토어로 사용하려면 별도의 모듈인 `SessionModule`을 만들어야 합니다. 이 `SessionModule`에서는 `nestjs-session`의 `SessionModule`을 import 하고, `connect-mongo`를 사용하여 세션 스토어를 MongoDB로 설정합니다. 이렇게 하면, `nestjs-session`의 `SessionModule`에서 제공하는 세션 관리 기능을 그대로 사용하면서, 세션 데이터를 MongoDB에 저장하는 기능을 추가할 수 있습니다. 즉, `SessionModule`을 별도로 만드는 이유는 세션 데이터를 MongoDB에 저장하는 기능을 추가하기 위해서입니다. 이를 통해 세션 데이터의 영속성을 확보하고, 서버가 재시작되거나 다운되어도 세션 데이터를 유지할 수 있습니다.

 

 

의문: `ConfigService`를 통해 환경변수를 불러오는 방식과 process.env로 불러오는 방식과 뭐가 다를까?

 

`process.env`로 직접 환경변수를 불러오는 방식과 `ConfigService`를 통해 환경변수를 불러오는 방식은 몇 가지 차이점이 있다.

 

1. 타입 검증: `ConfigService`는 환경변수를 추출할 때 해당 변수의 타입을 검증한다. `configService.get <string>('DB_URL')`와 같이 사용하면, `DB_URL` 환경변수가 문자열인지 확인한다. 이는 타입스크립트의 타입 검증 기능을 활용하여, 코드의 안정성을 높이는 데 도움이 된다.

 

2. 환경변수 유효성 검사: `ConfigService`는 `joi`나 `class-validator`와 같은 라이브러리를 사용하여 환경변수의 유효성을 검사하는 기능을 제공한다. 예를 들어, DB 연결 문자열이 올바른 형식인지, 필수 환경변수가 모두 설정되어 있는지 등을 검사할 수 있다.

 

3. 환경변수 기본값 설정: `ConfigService`를 사용하면, 환경변수가 설정되지 않은 경우에 사용할 기본값을 설정할 수 있다. 이 기능은 개발 환경에서 테스트를 수행하거나, 환경변수 설정이 누락된 경우에 유용한다.

 

4. 환경변수 파일 로딩: `ConfigService`는 `. env` 파일을 로딩하는 기능을 제공한다. 이를 통해, 환경에 따라 다른 `. env` 파일을 로딩하거나, 여러 `. env` 파일을 합치는 등의 작업을 수행할 수 있다. 따라서, `ConfigService`를 사용하면 환경변수 관리를 좀 더 안전하고 편리하게 수행할 수 있다.

 

그렇다면.... process.env를 사용할 필요 없는 거 아닐까??

 

`process.env`를 사용하는 것과 `ConfigService`를 사용하는 것은 각각의 장단점이 있다.

 

`process.env`를 사용하는 경우, 코드가 간단해지고 직접적으로 환경 변수에 접근할 수 있다는 장점이 있습니다. 이는 코드를 더 간결하게 만들어 주고, 별도의 설정 없이도 환경 변수를 불러올 수 있다. 그러나 `process.env`를 사용하면, 환경 변수의 유효성 검사나 기본값 설정, 파일 로딩 등의 기능을 사용할 수 없다. 또한, `process.env`는 모든 환경 변수를 문자열로 취급하기 때문에, 숫자나 불리언값을 사용할 경우에는 직접 형변환을 해줘야 한다.

 

반면에, `ConfigService`는 환경 변수의 유효성 검사, 기본값 설정, 파일 로딩 등의 기능을 제공한다. 또한, `ConfigService.get <string>('DB_URL')`와 같이 사용하면, 환경 변수의 타입을 검증할 수 있다. 그러나 `ConfigService`를 사용하려면, 먼저 `ConfigModule`을 설정해야 한다. 이는 코드가 약간 복잡해지는 단점이 있지만, 대신 환경 변수 관리를 더 안전하고 효율적으로 수행할 수 있다. 따라서, `process.env`를 사용할지 `ConfigService`를 사용할지는 프로젝트의 요구 사항과 개발자의 선호에 따라 달라진다.

 

간단한 프로젝트에서는 `process.env`를 사용하고, 환경 변수 관리가 중요한 프로젝트에서는 `ConfigService`를 사용하는 것이 좋을 수 있다.