낙서장이자 오답 노트이자 컨닝 페이퍼

패스트캠퍼스 환급챌린지 35일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Mon, 5 May 2025 14:05:57 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

Database Seeding

개요: DB 시딩이란?

DB 시딩(Seeding): 개발 환경에서 테스트나 시연을 위해 샘플 데이터를 자동으로 삽입하는 작업
프로덕션에서는 잘 쓰지 않지만, 개발/테스트 환경에서는 필수

폴더 구조 및 시딩 준비

Postman에 시드 폴더 생성
Authorization → Bearer Token (환경 변수로 access_token 사용)
시딩 순서:
1. 로그인
2. 다이렉터 생성
3. 장르 생성
4. 무비 생성

랜덤 데이터 생성 (Pre/Post 스크립트 활용)

랜덤 다이렉터 생성

랜덤 풀네임, 랜덤 국가 → name, country 값 자동 생성
Postman Test 탭에서 응답 받은 id를 environment variable로 저장:

const body = pm.response.json();
let directors = pm.environment.get('director_ids') || '';
directors = directors ? `${directors},${body.id}` : `${body.id}`;
pm.environment.set('director_ids', directors);

랜덤 장르 생성
- 랜덤 명사, 형용사를 조합하여 장르 이름 생성
- 중복 방지 로직 추가:
  - 이미 존재하면 400 에러 반환
- 위와 같은 방식으로 장르 ID 저장

무비 시딩을 위한 관계 랜덤 연결

무비 생성 시 필요한 정보
- title: 랜덤 명사 + 형용사 + 숫자
- description: 랜덤 문장
- directorId: 시딩된 다이렉터 중 하나 랜덤 선택
- genreIds: 장르 중 3개 랜덤 중복 없이 선택

Pre-request Script 예시

const _ = require('lodash');

// 다이렉터 ID 랜덤 선택
const directorIds = pm.environment.get("director_ids").split(",");
const randomDirectorId = _.sample(directorIds);
pm.environment.set("director", randomDirectorId);

// 장르 ID들 중 3개 랜덤 중복 없이 선택
const genreIds = pm.environment.get("genre_ids").split(",");
let picked = [];
let failCount = 0;
while (picked.length < 3 && failCount < 20) {
  const g = _.sample(genreIds);
  if (!picked.includes(g)) {
    picked.push(g);
  } else {
    failCount++;
  }
}
pm.environment.set("genres", picked);

Postman Runner로 대량 생성

Postman Collection Runner 활용법
- Runner에서 시드 폴더 선택 → 실행 순서 지정
- 반복 횟수(iteration) 설정 (ex. 감독 10명, 장르 50개, 영화 200개)
- 중복 에러 발생 가능하지만 일부 실패는 무방

테이블 리셋 후 재시딩

DB 테이블 드랍 → 서버 재시작 → Postman으로 다시 시딩
유저 등록 → 롤 변경 (어드민) → 로그인 → 다시 시딩 가능

학습 후기

이번 강의를 통해 Postman을 활용한 Database Seeding 자동화 방법을 배우면서, 백엔드 개발에서 데이터 준비가 얼마나 중요한지 다시금 느꼈습니다. 실제 서비스에서는 프로덕션 데이터를 직접 다루지만, 개발과 테스트 환경에서는 시딩을 통해 일관된 테스트 환경을 유지하는 것이 매우 중요합니다. 단순히 데이터를 넣는 것에 그치는 게 아니라, 관계형 데이터를 유의미하게 구성하고, 이를 반복적으로 쉽게 재사용할 수 있도록 자동화하는 흐름을 체득할 수 있었습니다.

특히 인상 깊었던 점은 Postman 스크립트를 활용한 랜덤 데이터 생성과 변수 저장 방식이었습니다. Pre-request Script에서는 lodash와 같은 유틸을 활용해 랜덤한 감독 ID, 장르 ID 등을 추출하고, 이를 Postman 환경변수에 저장하는 구조가 굉장히 유연하고 강력했습니다. 단순한 API 테스트 도구로만 알고 있었던 Postman이 실제로는 데이터 생성용 워크플로우 자동화 도구로 활용될 수 있다는 점에서 눈이 열렸습니다. 테스트 탭에서 응답값을 파싱하고 환경변수에 저장해 다음 요청에 활용하는 방식은 서비스 개발 초기에 데이터를 대량으로 준비해야 할 때 큰 도움이 될 수 있습니다.

또한 Postman Runner를 활용해 반복 횟수를 조정하면서 대량 데이터를 생성하는 기능도 유용했습니다. 단순히 다이렉터, 장르, 무비를 순서대로 생성하는 것뿐만 아니라, 각 무비가 관계를 맺고 있는 다이렉터와 장르를 랜덤하게 연결하는 과정이 포함되어 있어서, 실무에서 자주 마주하게 될 관계형 데이터 시딩 시나리오를 미리 체험해 볼 수 있었습니다. 특히 반복 중 일부 실패는 무시해도 되는 전략 덕분에 오류에 유연하게 대응할 수 있었고, 이는 테스트 효율성을 높이는 데 중요한 요소라고 느꼈습니다.

마지막으로, 시딩 작업을 진행하며 데이터 초기화 및 재시딩 흐름까지 자연스럽게 익힐 수 있었습니다. NestJS 서버 재시작과 함께 데이터베이스를 초기화하고 다시 시딩하는 일련의 작업이 반복되면서, 백엔드 초기화 → 유저 등록 → 권한 설정 → 시딩 자동화라는 전반적인 백엔드 개발 워크플로우를 체득하게 되었습니다. 실무에서는 종종 staging 환경에서 테스트 데이터를 넣어야 하는 상황이 있는데, 이 방법을 숙지해두면 반복 작업 없이 빠르게 처리할 수 있을 것이라 확신합니다.

이번 학습을 통해 Postman은 단순한 API 테스트 도구가 아니라, 테스트 환경 구축과 데이터 워크플로우 자동화까지 지원하는 매우 유용한 도구임을 몸소 체감했습니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 34일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Sun, 4 May 2025 14:50:09 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

환경변수와 스크립트 작성

문제 상황: 매번 토큰 복사 → 붙여넣기 너무 번거로움

모든 API가 인증 필요 → 매번 로그인 → 토큰 복사 → Authorization 헤더에 붙여야 함
실무에서는 자동화/재사용이 필요함

해결 1: 환경변수 (Environment Variable) 활용

환경 만들기
- 좌측 하단 Environments → + 클릭 → 환경 이름 입력
  - 예: FastCampus NestJS
- 변수 추가:
  - Key: host, Initial: (비워둬도 됨), Current: http://localhost:3000
- 저장 후 우측 상단에서 해당 환경 활성화
변수 사용법
- URL 앞부분을 {{host}} 로 치환
- {{host}}/movies
- 마우스 올려 보면 적용된 값 확인 가능
- 추후 배포 시 환경만 바꾸면 되므로 매우 유용

해결 2: 로그인 시 토큰 자동 저장

스크립트 작성

로그인 API → Tests 탭에 아래 스크립트 입력

const body = pm.response.json();
pm.environment.set("access_token", body.accessToken);
pm.environment.set("refresh_token", body.refreshToken);

응답에서 토큰을 추출해 환경 변수로 저장

토큰 확인
- Environments → 해당 환경 → 변수 자동 생성됨
  - access_token
  - refresh_token

해결 3: Authorization 자동 주입

Authorization에 환경 변수 사용
- 헤더 > Authorization > Bearer {{access_token}}
반복 방지: Inherit auth from parent 설정
- 각각의 요청/폴더/컬렉션에서:
  - Authorization 설정 → Inherit auth from parent
- 최상위 컬렉션에서만 직접 설정
  - Bearer Token 방식 선택
  - Token 값: {{access_token}}
토큰 자동 갱신 흐름
1. 로그인 실행 → access_token 갱신됨
2. 모든 요청은 {{access_token}} 사용 → 자동 적용
3. 다시는 복붙 필요 없음

학습 후기

이번 강의를 통해 Postman을 활용한 API 테스트 자동화 및 인증 토큰 관리의 중요성과 구체적인 방법들을 배울 수 있었습니다. NestJS 기반의 백엔드 서버를 개발하면서 모든 API가 인증을 필요로 하다 보니, 로그인 → 토큰 복사 → 헤더에 붙여넣는 반복 작업이 점점 부담으로 다가왔습니다. 하지만 환경 변수와 스크립트를 적절히 활용하니, 이러한 번거로움이 한 번에 해결되었습니다.

가장 먼저 유용했던 점은 환경변수 설정입니다. {{host}}와 같은 변수로 API의 base URL을 추상화해두니, 추후 서버 환경이 변경되더라도 환경값만 바꾸면 전체 테스트 스크립트를 수정할 필요가 없어졌습니다. 실제로 로컬에서 테스트할 때는 localhost를 사용하고, 추후 배포 시에는 프로덕션 URL만 바꾸면 되니 협업이나 배포 자동화에도 유리할 것이라 생각했습니다.

또한 로그인 API의 응답에서 access_token과 refresh_token을 자동으로 저장하는 방식은 매우 강력했습니다. Postman의 Tests 탭에 간단한 JavaScript를 삽입함으로써 로그인 요청 이후의 모든 요청이 자동으로 최신 토큰을 반영하게 되었고, 헤더 설정 또한 Bearer {{access_token}}으로 통일할 수 있었습니다. 이런 자동화 덕분에 테스트 효율이 크게 향상되었고, 테스트 중에 토큰이 만료되더라도 단지 로그인 요청 하나만 재전송하면 전체 환경이 다시 유효해진다는 점이 실무에서도 매우 유용하게 쓰일 것이라 느꼈습니다.

특히 컬렉션 상속을 통한 Authorization 설정은 Postman을 깊이 있게 활용하는 첫 경험이었습니다. 각각의 요청에서 Authorization을 따로 설정할 필요 없이, 최상위 컬렉션에서 한 번만 설정하고 모든 하위 요청은 상속받게 하는 방식은 코드의 DRY(Don’t Repeat Yourself) 원칙과도 일맥상통한다고 느꼈습니다. 실수도 줄고, 협업자와의 공유 시에도 구조적으로 깔끔하게 유지할 수 있었습니다.

이번 실습은 단순한 토큰 처리 자동화 수준을 넘어, API 테스트 자체의 생산성과 안정성을 끌어올릴 수 있다는 인사이트를 주었습니다. 백엔드 개발자로서 단순히 API를 만드는 것에 그치지 않고, 테스트 자동화와 관리 효율성까지 고려하는 것이 진짜 실무 능력이라는 점을 절실히 느꼈습니다. 앞으로 다른 프로젝트에서도 이 방식을 그대로 적용할 생각입니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 33일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Sat, 3 May 2025 11:30:41 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

Role Based Access Control 이론

RBAC이란?

RBAC = Role-Based Access Control
번역: 역할 기반 인가 시스템
역할(Role)에 따라 리소스에 대한 **권한(Permission)**을 부여
특정 리소스의 CRUD(Create, Read, Update, Delete) 권한을 역할에 따라 제어

왜 필요한가?

사용자의 등급/역할에 따라 접근 가능한 기능을 나눌 수 있음
예:
- 어드민(Admin): 모든 기능 접근
- 유저(User): 본인 리소스만 접근 가능
- 게스트(Guest): 열람만 가능

구현 난이도

RBAC는 매우 복잡하게 설계할 수 있지만, 단순하게 시작하는 것이 좋음
복잡하게 설계할수록:
- 기능 설계 난이도 급증
- 기획자/개발자 간 커뮤니케이션 비용 증가
권한 설계는 유지보수가 매우 어려워지므로 작게 시작하고 점진적으로 확장할 것

기본 구현 아이디어

역할 분류 예시

enum Role {
  ADMIN = 'ADMIN',
  USER = 'USER',
  GUEST = 'GUEST',
}

커스텀 데코레이터로 역할 지정
- ```
@Roles(Role.ADMIN)
@Roles(Role.USER)
```
가드 내부에서 처리 로직
- @Roles() 데코레이터에서 역할 정보 추출
- 요청의 req.user.role 과 비교
- 권한 없으면 ForbiddenException 던짐
역할 지정이 없을 경우 처리
- ```
if (!roles) {
  return true; // 권한 검사하지 않음
}
```
- 프로젝트마다 디폴트 정책은 다르게 설정 가능

RBAC 구현하기

커스텀 데코레이터 생성

파일: auth/decorators/rbac.decorator.ts

export const Rbac = createParamDecorator<Role>((role) => role);

@Rbac(Role.ADMIN) 과 같이 사용될 예정
역할(Roles)을 데코레이터로 엔드포인트에 명시함

RbacGuard 생성

파일: auth/guards/rbac.guard.ts
CanActivate 가드 인터페이스 구현

핵심 로직

// 1. Reflector를 통해 @Rbac 데코레이터 메타데이터 추출
const requiredRole = this.reflector.get<Role>(RBAC_KEY, context.getHandler());

if (!requiredRole) return true; // 데코레이터 없으면 제한 없음

// 2. Request 객체에서 유저의 role 추출
const req = context.switchToHttp().getRequest();
const user = req.user;

if (!user) return false; // 로그인 안 되어 있으면 차단

// 3. 권한 체크 (숫자가 작을수록 높은 권한)
return user.role <= requiredRole;

역할 Enum 정의

예시:

export enum Role {
  ADMIN = 0,
  PAID_USER = 1,
  USER = 2,
}

숫자가 작을수록 높은 권한
- 0 = 최고 권한
- 2 = 일반 유저

app.module.ts에 가드 전역 등록

providers: [
  {
    provide: APP_GUARD,
    useClass: AuthGuard, // 인증 먼저
  },
  {
    provide: APP_GUARD,
    useClass: RbacGuard, // 인가(RBAC)는 두 번째
  },
];

가드 순서 중요: 인증(토큰 확인) → 인가(권한 확인)

엔드포인트에 권한 적용

예: 일반 유저는 영화 조회 가능, 관리자만 생성/수정/삭제 가능

@Get()
@Public()
getMovies() {}

@Post()
@Rbac(Role.ADMIN)
createMovie() {}

@Patch(':id')
@Rbac(Role.ADMIN)
updateMovie() {}

@Delete(':id')
@Rbac(Role.ADMIN)
deleteMovie() {}

학습 후기

이번 RBAC 강의를 통해 NestJS에서 역할 기반 인가를 실제로 어떻게 구현할 수 있는지 깊이 있게 이해할 수 있었습니다. 인증만으로는 보안이 완성되지 않으며, 인가가 더해져야 비로소 시스템 전반의 접근 제어가 가능해진다는 점을 실습을 통해 체감했습니다. 특히 JWT에 role 값을 포함하고, 이 값을 기준으로 엔드포인트별 접근 권한을 제한하는 방식은 NestJS의 데코레이터 및 가드 시스템과 매우 잘 어울리는 설계라고 느꼈습니다.

RBAC 구현 시 가장 인상 깊었던 부분은 @Rbac()이라는 커스텀 데코레이터를 만들어 각 라우트 핸들러에 요구되는 역할을 명시하고, 이를 Reflector로 추출하여 가드 내부에서 req.user.role과 비교하는 구조였습니다. NestJS의 메타프로그래밍 개념이 실무와 직결되는 순간이었고, 역할이 없을 경우 인가를 건너뛰는 예외 처리 로직까지 반영하면서 유연하고 확장 가능한 인가 시스템을 직접 설계할 수 있다는 자신감을 얻었습니다.

또한 권한을 숫자 기반으로 정의한 점도 현실적이고 실용적인 선택이라고 느꼈습니다. 단순한 조건문 비교로 충분한 유연성을 확보할 수 있었고, 나중에 기획 변경이나 새로운 역할 추가 시에도 비교적 손쉽게 대응할 수 있을 것이라 판단됩니다.

전역 가드 등록 순서 또한 중요한 학습 포인트였습니다. 인증이 먼저 실행되고, 그 다음에 인가가 실행되는 순서로 구성하여 인증이 먼저 통과된 사용자만이 인가 로직을 거칠 수 있게 함으로써, 책임과 관심사의 분리가 잘 이루어진 구조였습니다. 이로 인해 가드 코드가 더 명확해지고, 유지보수 또한 쉬워진다는 장점이 있었습니다.

마지막으로, 퍼블릭 라우트에 잘못된 토큰이 전달될 경우 에러가 발생하지 않도록 Bearer Token 미들웨어를 개선한 방식 역시 실무적인 고민이 반영된 내용이었습니다. 토큰이 없거나 잘못되어도 미들웨어는 조용히 넘어가고, 인가 여부는 가드에서 판단하는 구조는 시스템의 견고함을 높이는 설계라고 생각합니다.

이 강의를 통해 RBAC의 필요성과 구조, 그리고 NestJS에서의 구현 방법을 확실히 체득할 수 있었으며, 실제 프로젝트에 도입할 수 있을 만큼 구체적인 실습 경험을 얻을 수 있었습니다. 앞으로 역할 기반의 더 복잡한 권한 시스템(RBAC + ABAC 등)으로도 확장할 수 있다는 점에서 큰 가능성을 느꼈습니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 32일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Sat, 3 May 2025 10:07:30 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

Guard 이론

왜 가드를 배우는가?

기본기를 익힌 후 진도를 빠르게 나가기 위함.
파트1에서 많은 내용을 소화해야 하므로 깊이 있고 빠르게 커버할 필요 있음.

NestJS의 주요 기능 분류 및 비교

기능명	주 목적	실행 시점	사용 포인트
미들웨어	요청 전 비파괴적 작업	가장 먼저 실행	logging, 공통 처리 등
파이프	유효성 검사 및 변환	컨트롤러 진입 전	DTO, transform
가드	인가(authorization) 처리	컨트롤러 진입 직전	권한 체크
인터셉터	요청/응답 가로채기	컨트롤러 전/후	응답 변경, 로깅 등

기능은 유사한 일을 할 수 있지만, 각 기능의 문맥(Context)에 맞게 사용하는 것이 협업과 유지보수에 유리함.

가드(Guard)의 정의 및 역할

가드는 요청을 보호하는 역할을 한다.
요청을 라우트 핸들러에 넘기기 전, 요청자가 자격이 있는지(인가) 판단.
- 이를 Authorization이라고 함 (인증: Authentication과 구분)
요청을 통과시키거나 차단할 수 있음 (true/false 반환)

미들웨어 vs 가드

항목	미들웨어	가드
실행 위치	가장 앞단	핸들러 직전
사용 가능 정보	request, response만 있음	executionContext 제공 (컨텍스트 풍부)
적절한 용도	로깅, 인증 토큰 파싱 등	권한 검증, 접근 제어 등

가드 구현 방법

implements CanActivate 인터페이스 구현
canActivate(context: ExecutionContext): boolean 메서드 정의
반환 값
- true: 통과 → 요청 핸들러 실행
- false: 차단 → ForbiddenException (HTTP 403)

가드 적용 방식

로컬 적용

클래스 전체에 적용

@UseGuards(RolesGuard)
@Controller('cats')
export class CatsController {}

특정 메서드에만 적용

@UseGuards(RolesGuard)
@Get()
findAll() {}

글로벌 적용

간단한 글로벌 적용

const app = await NestFactory.create(AppModule);
app.useGlobalGuards(new RolesGuard());

DI(의존성 주입)가 필요한 경우

providers: [
  {
    provide: APP_GUARD,
    useClass: RolesGuard,
  },
]

Auth Guard 생성하기

목표

인증되지 않은 사용자가 특정 라우트(예: 영화 생성, 수정, 삭제 등)에 접근하지 못하도록 가드(Guard) 를 구현한다.

기본 설계 및 구조

src/us/guards/authentication.guard.ts 생성
인증용 가드를 간단하게 구현
이미 미들웨어에서 JWT 검증이 완료되었고, 그 결과가 request.user에 담겨 있음

Guard 구현 단계

클래스 정의 및 데코레이터 추가

@Injectable()
export class UsGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean { ... }
}

ExecutionContext로부터 Request 추출

const request = context.switchToHttp().getRequest();

검증 조건

if (!request.user || request.user.tokenType !== 'access') {
  return false; // → 403 Forbidden
}
return true; // → 라우트 통과

로컬 적용

특정 라우트(예: 영화 생성)에만 적용하고 싶은 경우:
- ```
@UseGuards(UsGuard)
@Post()
createMovie() {}
```
NestJS 내장 PassportGuard가 아닌, 직접 만든 Guard를 import 해야 함

기능 테스트 (Postman)

토큰 없이 POST 요청 시 → 403 Forbidden
올바른 Access Token 포함 시 → 정상적으로 요청 통과

글로벌 적용 방법

반복 적용 피하기 위해 AppModule에 글로벌 가드 등록

providers: [
  {
    provide: APP_GUARD,
    useClass: UsGuard,
  }
]

이렇게 하면 모든 라우트가 기본적으로 private route가 됨

글로벌 가드 적용 후 주의사항

로그인(auth/login), 회원가입(auth/register) 등 퍼블릭 라우트도 막히게 됨
의도치 않게 외부 공개되어야 할 API까지 막히는 문제가 발생할 수 있음

Public Custom Decorator 생성하기

문제 상황

AuthGuard를 전역(Global Guard) 으로 적용하면서, 로그인(auth/login)이나 회원가입(auth/register) 등 퍼블릭 라우트까지 차단되는 문제가 발생함.

목표

기본적으로 모든 라우트를 프라이빗(private) 으로 설정하고,
특정 라우트만 퍼블릭(public) 으로 제외 처리할 수 있도록 커스텀 데코레이터 + 가드 개선을 통해 해결.

커스텀 데코레이터 만들기

us/decorators/public.decorator.ts 생성
- ```
import { SetMetadata } from '@nestjs/common';

export const IS_PUBLIC_KEY = 'isPublic';
export const Public = () => SetMetadata(IS_PUBLIC_KEY, true);
```
- SetMetadata()를 통해 'isPublic'이라는 메타데이터를 true로 설정
- @Public() 데코레이터를 통해 퍼블릭 라우트를 마킹할 수 있게 됨

라우트에 데코레이터 적용

@Public()
@Post('login')
login() { ... }

@Public()
@Post('register')
register() { ... }

이 데코레이터를 붙이면, 가드 통과를 자동으로 허용할 예정

가드 수정 (us/guards/auth.guard.ts)

Reflector 주입

constructor(private reflector: Reflector) {}

퍼블릭 여부 확인 후 처리
- ```
const isPublic = this.reflector.get<boolean>(IS_PUBLIC_KEY, context.getHandler());
if (isPublic) {
  return true; // 퍼블릭이면 모든 로직 바이패스
}
```
- context.getHandler()를 통해 현재 라우트 핸들러의 메타데이터 접근
- isPublic === true이면 인증 검사를 하지 않고 곧바로 통과시킴

Bearer Token Middleware 토큰 검증 개선하기

문제 상황: 퍼블릭 라우트에서 "잘못된 토큰"이 들어올 경우

@Public() 데코레이터가 붙은 퍼블릭 라우트에 요청 시:
- 토큰이 아예 없는 경우 → 정상 동작
- 잘못된 토큰이 들어온 경우 → 403 Forbidden 에러 발생
왜 문제가 되나?
- 퍼블릭 라우트는 누구나 접근 가능해야 함
- "잘못된 토큰"이 있다고 해서 에러가 발생하면 안 됨
- 프론트엔드는 보통 모든 요청에 액세스 토큰을 자동으로 포함하므로,
- 퍼블릭 라우트에도 토큰이 포함되는 경우가 많음

원인 분석

이 에러는 미들웨어(BearerMiddleware)에서 토큰 검증 실패 시 에러를 던지기 때문
그런데 이미 가드(AuthGuard) 에서 인증 여부 판단을 하고 있음

해결 전략: 토큰 검증 실패 시 "조용히 무시"

기존 로직 (문제 있음)

try {
  const payload = verify(token, secret);
  req.user = payload;
} catch (e) {
  throw new UnauthorizedException();
}

→ 토큰이 잘못되면 에러 던짐 → 퍼블릭 라우트도 실패

변경 후 로직
- ```
try {
  const payload = verify(token, secret);
  req.user = payload;
} catch (e) {
  // 에러 무시하고 next() 호출
}
next();
```
- 검증에 실패해도 req.user = undefined인 채로 다음 단계로 넘어감
- 이후 인증 여부는 AuthGuard 내부에서 판단

학습 후기

이번 강의를 통해 NestJS에서 가드가 어떤 위치에서 어떤 역할을 수행하는지 명확히 이해할 수 있었습니다. 처음에는 미들웨어와 가드가 유사하게 느껴졌지만, 미들웨어는 요청을 변형하거나 로그를 출력하는 등 비파괴적인 전처리에 가깝고, 가드는 컨트롤러 직전에서 접근을 허용할지 말지를 결정하는 보안 필터라는 점에서 확실히 역할이 구분된다는 점이 흥미로웠습니다.

직접 AuthGuard를 구현하면서, ExecutionContext에서 request 객체를 가져와 req.user를 기반으로 인증 여부를 판단하는 구조는 NestJS의 IoC 철학에 잘 부합한다고 느꼈습니다. 특히 기존에 Bearer Token을 미들웨어에서 파싱하여 req.user에 주입하는 구조와 연결되어, 미들웨어와 가드가 각자 역할을 나누고 있지만 유기적으로 협력하는 구조가 인상 깊었습니다. 인증은 가드가 담당하고, 미들웨어는 정보를 제공하는 조력자로만 남겨두는 구조가 가장 깔끔하고 확장 가능한 아키텍처라고 느꼈습니다.

또한 글로벌 가드 설정을 통해 모든 라우트를 기본적으로 보호하면서, @Public() 데코레이터를 통해 퍼블릭 라우트를 명시적으로 열어두는 방식은 실무에서 자주 겪는 인증/인가 요구사항을 매우 우아하게 해결해준다고 생각합니다. 특히 Reflector를 이용해 메타데이터 기반으로 가드의 동작을 제어하는 방식은, 이후 역할 기반 권한 시스템이나 세분화된 인증 정책으로 확장할 때에도 매우 유용하게 작동할 것이라 판단됩니다.

실제 실습 중 가장 인상 깊었던 부분은, 퍼블릭 라우트에 잘못된 토큰이 포함된 경우에도 요청이 거부되는 문제를 해결한 방식이었습니다. 처음엔 이 현상이 이상하다고 느껴졌지만, 문제는 가드가 아닌 Bearer 토큰 미들웨어에서 에러를 던진 것이 원인이었습니다. 이 부분을 try-catch로 조용히 무시하고 넘어가며, 인증 여부의 최종 판단은 가드에서 하도록 설계한 점은 책임의 분리를 잘 보여주는 사례였습니다.

결론적으로 이번 강의를 통해 단순히 Guard의 사용법만 익힌 것이 아니라, NestJS 아키텍처의 철학과 역할 분리에 대한 깊은 이해를 얻게 되었습니다. 인증, 인가, 역할 권한 등의 보안 관련 요구사항을 구조적으로 어떻게 풀어야 할지에 대한 감을 잡을 수 있었고, 실제 팀 프로젝트나 실무에서도 매우 유용하게 활용할 수 있을 것이라 확신하게 되었습니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 31일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Thu, 1 May 2025 22:41:34 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

Middleware 이론

NestJS 요청 처리 순서

미들웨어 → 가드 → 인터셉터 → 파이프 → 컨트롤러(핸들러) → 응답 → 인터셉터 → 예외 필터

미들웨어란?

라우트 핸들러 실행 전에 동작
Request, Response, Next 객체에 접근 및 조작 가능
NestJS 공식 문서에도 다음과 같은 역할로 정의됨:

미들웨어의 주요 역할기능 설명

자유로운 로직 실행	로그 출력, 요청 전처리 등
req/res 객체 변경	예: req.user 값 추가
요청-응답 사이클 중단	인증 실패 시 직접 응답 종료
다음 단계로 전달	next() 호출 시 다음 미들웨어 혹은 컨트롤러로 진행

미들웨어 만들기

@Injectable()
export class LoggerMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    console.log(`${req.method} ${req.url}`);
    next();
  }
}

NestMiddleware를 구현하고 use() 메서드 필수 정의
next() 호출 전까지 원하는 로직 실행 가능

미들웨어 적용 방법

모듈 단위 적용

AppModule 또는 특정 모듈에서 적용

export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer
      .apply(LoggerMiddleware)
      .forRoutes('*'); // 전체 라우트 적용
  }
}

apply() 안에 여러 미들웨어 넣을 수도 있음

forRoutes()에는 다음과 같은 방식 사용 가능:

.forRoutes('cats')                      // 특정 경로 전체
.forRoutes({ path: 'cats', method: RequestMethod.GET })  // 특정 메서드만
.forRoutes('*')                         // 전체 라우트

제외 라우트 설정
- ```
consumer
  .apply(LoggerMiddleware)
  .exclude({ path: 'cats', method: RequestMethod.POST }) // 제외 조건
  .forRoutes('*');
```
  - exclude()를 먼저 선언하고 forRoutes()로 나머지 적용
  - 너무 복잡하게 exclude 로직을 설계하지 않도록 주의
글로벌 미들웨어로 등록
- main.ts에서 전체 앱에 전역 적용
```
app.use(LoggerMiddleware);
```

미들웨어 다중 적용

consumer
  .apply(LoggerMiddleware, AuthMiddleware, CacheMiddleware)
  .forRoutes('*');

미들웨어는 등록 순서대로 실행
순서 중요할 경우 주의 필요

Bearer Token Middleware 구현하기

목표

매번 컨트롤러/가드에서 Bearer 토큰을 파싱하지 않고, 전역 미들웨어로 처리하여 중복 제거 및 편의성 향상
Request 객체에 payload를 삽입해 이후 로직에서 req.user로 간편하게 접근

문제 인식

parseBearerToken()을 매번 불러서 토큰을 파싱하는 게 번거로움
해결 방안: 미들웨어를 통해 자동으로 처리되도록 만들자

미들웨어 구조 설계 및 생성

middleware/bearer-token.middleware.ts 생성
NestMiddleware 인터페이스 구현 및 use() 함수 정의

export class BearerTokenMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    // ...
  }
}

토큰 파싱 및 예외 처리 로직

토큰 유무 확인
- Authorization 헤더가 없으면 → 인증 의도 없음 → next()로 패스
Bearer 토큰 형식 확인 및 파싱
- 형식이 "Bearer "인지 확인
- 아니면 BadRequestException 던짐
- 올바르면 토큰 문자열만 추출
디코드 후 타입 확인 (access / refresh)
- jwtService.decode()로 타입 확인
- 타입이 access나 refresh가 아니면 → UnauthorizedException
Secret 결정
- 토큰 타입에 따라 accessTokenSecret 또는 refreshTokenSecret을 선택

검증 및 payload 삽입

jwtService.verify()로 실제 검증 수행
검증된 payload를 req.user에 삽입

의존성 주입

JwtService, ConfigService를 생성자에서 주입
ConfigModule은 글로벌 등록되어 따로 exports 불필요

AppModule에 미들웨어 등록

configure()에서 consumer.apply().forRoutes()를 통해 전역 등록
단, 로그인/회원가입은 Basic Auth 사용 → exclude()로 예외 처리

consumer
  .apply(BearerTokenMiddleware)
  .exclude(
    { path: 'auth/login', method: RequestMethod.POST },
    { path: 'auth/register', method: RequestMethod.POST }
  )
  .forRoutes('*');

미들웨어 적용 후 검증

컨트롤러에서 @Req() req: Request를 통해 req.user에 접근
토큰이 포함되지 않으면 undefined
Bearer 토큰 포함 → payload 정보가 정상 출력됨

학습 후기

이번 강의를 통해 NestJS의 미들웨어 구조와 실질적인 활용 방식에 대해 명확하게 이해할 수 있었습니다. 이전까지는 미들웨어를 단순히 로깅이나 요청 전처리 용도로만 생각했으나, 이번에 Bearer Token을 파싱하고 검증하는 과정을 미들웨어로 추출함으로써 인증 흐름 전반을 효율화할 수 있다는 사실을 직접 체감할 수 있었습니다.

가장 인상 깊었던 부분은 req.user에 payload를 삽입하는 방식이었습니다. 일반적으로는 가드나 컨트롤러 내부에서 JWT 검증 로직을 넣고 결과를 기반으로 인증 여부를 판단했지만, 이번 방식은 인증과 관련된 공통 로직을 미들웨어로 분리하여 코드 중복을 제거하고 유지보수성을 높이는 데 효과적이었습니다. 특히 parseBearerToken 같은 유틸성 함수가 여기저기서 반복적으로 호출되는 상황에서, 해당 로직을 미들웨어로 대체한 구조는 실무적인 관점에서 매우 유용한 패턴이라고 느꼈습니다.

또한 NestJS의 요청 처리 순서를 다시 확인하고, 미들웨어가 가드보다 앞서 실행된다는 점을 이해함으로써 인증 흐름 전체를 설계하는 데에 훨씬 더 명확한 기준을 갖게 되었습니다. 예외 처리와 next() 호출 타이밍, 그리고 Authorization 헤더가 없는 경우에도 유연하게 넘어가는 구조는 사용자 경험 측면에서도 중요하다고 생각합니다.

특정 라우트를 exclude() 처리하여 미들웨어 적용 대상에서 제외하는 방법 역시 유연한 라우팅 구성을 가능하게 해주었고, 미들웨어의 실행 순서가 등록 순서에 따라 결정된다는 점은 로그, 캐시, 인증 등을 조합할 때 고려해야 할 중요한 포인트임을 실감했습니다.

결론적으로, 이번 강의를 통해 NestJS에서 미들웨어가 단순한 기능적 보조 수단을 넘어서 인증, 보안, 요청 흐름 제어 등 핵심 기능까지도 담당할 수 있는 유연한 구조임을 체감했습니다. 앞으로 프로젝트를 설계할 때는 이러한 구조적 이점을 적극 활용해, 깔끔하고 유지보수 가능한 인증 흐름을 설계하고자 합니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 30일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Wed, 30 Apr 2025 22:50:27 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

Access Token 재발급하기

목적

Access Token은 유효기간이 짧음 (보안 목적)
Refresh Token을 통해 Access Token 재발급 가능
→ 로그인 없이 세션 유지

엔드포인트 구성

@Post('token/access')
rotateAccessToken(@Headers('Authorization') token: string) {
  const payload = await this.authService.parseBearerToken(token, true);
  return {
    accessToken: await this.authService.issueToken(payload, false),
  };
}

Authorization: Bearer <refresh_token> 형식으로 요청
refresh_token 유효성 검증 후, 새로운 access_token 발급

토큰 파싱 함수 분리

parseBearerToken()

async parseBearerToken(rawToken: string, isRefresh: boolean): Promise<{ id: number; role: Role; }> {
  const [type, token] = rawToken.split(' ');
  if (type.toLowerCase() !== 'bearer') throw new BadRequestException('포맷이 잘못됐습니다.');

  const payload = await this.jwtService.verifyAsync(token, {
    secret: this.configService.get(isRefresh ? 'REFRESH_TOKEN_SECRET' : 'ACCESS_TOKEN_SECRET'),
  });

  // 토큰 타입 체크
  if (isRefresh && payload.type !== 'refresh') {
    throw new BadRequestException('Refresh Token을 입력해주세요.');
  }
  if (!isRefresh && payload.type !== 'access') {
    throw new BadRequestException('Access Token을 입력해주세요.');
  }

  return { id: payload.sub, role: payload.role };
}

Bearer 포맷 확인
verifyAsync()로 서명/만료 검증
payload의 type이 'refresh'인지 확인 필수

토큰 발급 함수 개선

issueToken() 수정

async issueToken(payload: { id: number; role: Role }, isRefresh: boolean): Promise<string> {
  return this.jwtService.signAsync(
    {
      sub: payload.id,
      role: payload.role,
      type: isRefresh ? 'refresh' : 'access',
    },
    {
      secret: this.configService.get(
        isRefresh ? 'REFRESH_TOKEN_SECRET' : 'ACCESS_TOKEN_SECRET',
      ),
      expiresIn: isRefresh ? '24h' : 300,
    },
  );
}

payload.sub, payload.role, type 명시
expiresIn은 refresh → 24h, access → 5분(300초)

환경변수 정비

왜 환경 변수를 상수로 분리해야 하는가?

.env의 키들을 하드코딩된 문자열로 직접 반복 사용하고 있었음
이는 오타 발생 시 런타임 에러로 이어질 수 있음
변수화해 관리하면 오타를 줄이고 유지보수가 쉬움

공통 상수 관리 폴더 및 파일 생성

구조:
- src/common/const/env.const.ts

코드:

export const EnvVariableKeys = {
  DB_TYPE: 'DB_TYPE',
  DB_HOST: 'DB_HOST',
  DB_PORT: 'DB_PORT',
  DB_USERNAME: 'DB_USERNAME',
  DB_PASSWORD: 'DB_PASSWORD',
  DB_DATABASE: 'DB_DATABASE',
  HASH_ROUNDS: 'HASH_ROUNDS',
  ACCESS_TOKEN_SECRET: 'ACCESS_TOKEN_SECRET',
  REFRESH_TOKEN_SECRET: 'REFRESH_TOKEN_SECRET',
};

사용처 리팩토링

app.module.ts

ConfigModule.forRoot({
  validationSchema: Joi.object({
    [EnvVariableKeys.DB_TYPE]: Joi.string().required(),
    [EnvVariableKeys.DB_HOST]: Joi.string().required(),
    ...
  })
})

auth.service.ts

this.configService.get(EnvVariableKeys.ACCESS_TOKEN_SECRET)
this.configService.get(EnvVariableKeys.REFRESH_TOKEN_SECRET)
this.configService.get(EnvVariableKeys.HASH_ROUNDS)

정상 작동 여부 테스트

기존 API (/auth/login, /auth/token/access) 테스트 → 정상 작동
실수로 access token을 refresh token 엔드포인트에 넣으면 → 에러 응답

refresh token 만료 시 에러 처리 개선

기존 문제:
- 만료된 refresh token 입력 시, 내부 에러만 발생 → 사용자에게 불명확한 응답

개선 방법:

try {
  const payload = await this.parseBearerToken(token, true);
  ...
} catch (err) {
  throw new UnauthorizedException('토큰이 만료됐습니다.');
}

try-catch로 감싸고, 명시적인 메시지를 가진 예외를 던짐

학습 후기

이번 강의를 통해 Access Token과 Refresh Token을 함께 사용하는 인증 구조의 실용성을 체감할 수 있었습니다. 기존에는 토큰이 만료되면 무조건 로그인을 다시 해야 한다고 막연히 생각했지만, Refresh Token을 통해 Access Token만 교체해 주는 구조는 실제 서비스에서 매우 합리적인 방식이라는 점을 알게 되었습니다. 사용자 경험을 해치지 않으면서도 보안을 유지할 수 있다는 점이 특히 인상 깊었습니다.

특히 parseBearerToken 메서드로 Access와 Refresh 토큰을 구분하고, issueToken 메서드로 두 토큰을 모두 발급할 수 있게 설계한 구조는 단순하면서도 확장성이 뛰어나다고 느꼈습니다. 이 과정에서 토큰 타입을 payload.type으로 구분하는 아이디어는 향후 로그아웃이나 토큰 블랙리스트 기능을 구현할 때도 유용할 것 같습니다.

추가로 .env 환경 변수 키를 상수화하여 관리하는 방식은 실무에서 반드시 필요한 설계 패턴이라는 인사이트를 얻었습니다. 문자열을 반복해서 사용하는 대신 상수 객체로 관리하니 오타를 방지할 수 있었고, ConfigService를 사용하는 모든 부분에서 일관된 접근 방식이 가능해졌습니다. 이는 코드의 안정성과 유지보수성을 크게 높여주는 작업이었습니다.

또한, Refresh Token이 만료되었을 때 내부 에러 메시지로 끝나는 것이 아닌, UnauthorizedException을 통해 명확한 응답 메시지를 클라이언트에 전달하는 처리 방식은 사용자 친화적인 API 설계의 좋은 예시라고 느꼈습니다. 단순히 작동하는 코드보다, 클라이언트와의 소통을 고려한 예외 메시지 설계가 얼마나 중요한지를 다시금 느낄 수 있었습니다.

이번 학습을 통해 인증 구조를 보다 체계적이고 견고하게 구성하는 방법을 익혔으며, 무엇보다도 실무 환경에서 반복적으로 마주치게 될 인증 문제들을 사전에 대비할 수 있는 탄탄한 설계 철학을 배울 수 있었습니다. Access Token 재발급 기능은 단순한 기능 이상으로 사용자 경험, 보안, 유지보수 측면에서 모두 중요한 역할을 한다는 점에서 앞으로도 적극적으로 활용하고 싶은 기술 중 하나가 되었습니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 29일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Tue, 29 Apr 2025 22:43:04 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

Jwt Strategy 적용하기

JWT 발급 로직 분리

issueToken() 함수 생성
- 기존 로그인 로직에서 토큰 발급 코드 분리
- 함수 시그니처:
  - ```
  async issueToken(user: User, isRefreshToken: boolean): Promise<string>
```
- 내부 로직:
  - type: access 또는 refresh
  - secret: .env에서 설정한 값
  - expiresIn: access → 5분(300초), refresh → 24시간

로그인 컨트롤러 정리

@Post('login-passport')
@UseGuards(LocalAuthGuard)
async loginPassport(@Request() req) {
  return {
    accessToken: await this.authService.issueToken(req.user, false),
    refreshToken: await this.authService.issueToken(req.user, true),
  };
}

LocalAuthGuard로 사용자 검증
검증 성공 시 request.user에서 사용자 정보 추출
JWT 2종 발급 후 반환

JWT Strategy 생성

jwt.strategy.ts

@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor(private configService: ConfigService) {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      ignoreExpiration: false,
      secretOrKey: configService.get('ACCESS_TOKEN_SECRET'),
    });
  }

  async validate(payload: any) {
    return payload; // request.user로 들어감
  }
}

ExtractJwt.fromAuthHeaderAsBearerToken() 사용
secretOrKey: access 토큰 시크릿 사용
validate()의 반환값이 request.user에 들어감

JWT Auth Guard 생성

export class JwtAuthGuard extends AuthGuard('jwt') {}

이름 기반 guard 사용 방지 → 안전한 타입 기반 코드 작성 가능

보호된 라우트 생성 및 토큰 검증

@Get('private')
@UseGuards(JwtAuthGuard)
getPrivateData(@Request() req) {
  console.log('run'); // guard 통과 시 실행
  return req.user;
}

JWT 토큰 필요
- Authorization: Bearer <token>
실패 시 → Unauthorized 에러 응답
성공 시 → validate의 반환값이 request.user에 담김

학습 후기

NestJS에서 JWT 기반 인증을 구축하면서 가장 인상 깊었던 점은 인증 흐름이 전략 단위로 완전히 분리된다는 점이었습니다. 기존에는 로그인 시 JWT를 직접 발급하고 검증하는 로직을 한곳에 몰아넣기 쉬웠는데, JwtStrategy를 사용하면 토큰 발급과 검증을 명확히 역할별로 나눌 수 있었습니다.

특히 Passport의 구조 덕분에 JWT 전략을 별도 파일로 작성하고, validate() 메서드 내부에서 토큰의 payload만 넘겨주면 request.user에 자동으로 주입된다는 점이 매우 편리했습니다. 덕분에 라우트에서는 인증된 사용자 객체를 별도 로직 없이 사용할 수 있었고, 이는 전반적인 코드의 가독성과 유지보수성을 높여주었습니다.

또한 access 토큰과 refresh 토큰의 발급 로직을 issueToken() 함수로 분리하여 설계하니, 토큰 발급 정책을 일관되게 관리할 수 있었습니다. 이 방식은 추후 Redis나 블랙리스트 기반의 리프레시 토큰 관리 전략으로 확장할 때도 유리하다는 생각이 들었습니다.

Guard를 통해 인증이 필요한 라우트를 보호하는 구조 역시 직관적이었습니다. @UseGuards(JwtAuthGuard) 한 줄로 해당 라우트를 보호할 수 있고, 토큰이 없거나 잘못된 경우에는 Unauthorized 에러가 자동으로 처리된다는 점에서 불필요한 예외 처리 코드를 줄일 수 있었습니다.

하지만 처음에는 PassportStrategy의 추상화 구조가 조금 낯설게 느껴졌습니다. 특히 jwtFromRequest, secretOrKey 등의 설정이 어떻게 작동하는지 이해하는 데 시간이 걸렸습니다. 그럼에도 불구하고 흐름을 파악한 뒤에는 NestJS의 DI 시스템과 함께 잘 어우러져 있다는 점에서 큰 만족감을 느꼈습니다.

결국 이번 학습을 통해 느낀 가장 큰 인사이트는, 인증 로직을 전략화함으로써 인증 시스템의 확장성과 유연성을 확보할 수 있다는 점이었습니다. 추후 OAuth2, SNS 로그인, 2차 인증 등의 기능도 각기 다른 Strategy로 관리하면, 시스템 전반의 복잡도를 최소화하면서 기능은 점차 확장해나갈 수 있을 것입니다. NestJS에서 Passport와 JWT를 활용한 인증 설계는, 단순한 구현을 넘어 인증 아키텍처의 핵심적 설계 방식임을 깨닫게 되었습니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 28일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Mon, 28 Apr 2025 18:56:02 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

passport 이론

Passport란 무엇인가?

모듈화된 인증 시스템
- 다양한 인증 방식을 유연하게 연결
- ex) 이메일/비밀번호, 구글 로그인 등
코드량을 줄일 수 있는 장점
- 복잡한 인증 로직을 전략으로 추상화해 둔 덕분
미들웨어 기반
- 기존 코드에 비파괴적으로 통합 가능
코어는 가볍고 일반화된 구조
- 다양한 전략을 끼워 넣을 수 있게 설계됨
세션 방식과 토큰 방식 모두 지원
- 전략마다 방식이 다를 뿐, Passport 자체는 모두 지원
풍부한 생태계
- 수많은 전략 패키지 존재 (ex. passport-local, passport-jwt, passport-google 등)

패스포트 사용 시 주의점

장점	단점
인증 코드 작성이 간편	추상화로 인해 유연성 부족
다양한 전략 즉시 활용 가능	내부 동작을 정확히 파악하지 않으면 디버깅 어려움
미들웨어 형태로 쉽게 통합	특정 프로젝트와 맞지 않을 수 있음

Passport 사용 방식 요약

전략(Strategy) 구현
- 예: LocalStrategy, JwtStrategy
- validate() 메서드를 필수로 구현해야 함
- 이 안에서 인증 로직 작성 (ex. 유저 검증, 비밀번호 비교 등)
전략 주입
- @Injectable()로 NestJS에서 DI로 사용
- PassportStrategy()를 확장하여 사용
Guard로 적용
- AuthGuard('local') → 해당 전략(LocalStrategy) 적용
- 전략 이름은 커스터마이징 가능
- JWT 전략으로 바꾸려면 'jwt'만 지정해주면 됨
```
@UseGuards(AuthGuard('local'))
```

패스포트를 쓰는 이유 vs 쓰지 않는 이유

Passport 사용 장점
- 인증에 필요한 로직을 거의 직접 작성하지 않아도 됨
- 전략 교체가 간편 (JWT ↔︎ Local 등)
Passport 사용 단점
- 추상화가 많아 직접 제어가 어려움
- 자유도가 낮아 세세한 커스터마이징이 어렵고
- 프로젝트 요구사항에 따라 과한 복잡성을 유발할 수 있음

Local Strategy 적용하기

Passport 관련 패키지 설치

pnpm i @nestjs/passport passport passport-local
pnpm i -D @types/passport-local

@nestjs/passport: NestJS에서 Passport 전략을 쉽게 쓰도록 도와주는 모듈
passport: 기본 Passport.js
passport-local: Local 전략용
@types/passport-local: 타입 지원

전략 디렉토리 및 Local Strategy 생성

/auth/strategy/local.strategy.ts 생성

전략 클래스 기본 구성:

@Injectable()
export class LocalStrategy extends PassportStrategy(Strategy) {
  constructor(private authService: AuthService) {
    super({ usernameField: 'email' }); // 기본값은 username
  }

  async validate(email: string, password: string): Promise<User> {
    return this.authService.authenticate(email, password);
  }
}

usernameField 변경: 기본은 username, email로 지정 가능
validate는 자동 호출되는 콜백 → 여기서 유저 검증 수행

AuthService에 검증 로직 분리

기존 로그인 로직에서 유저 검증 부분만 함수로 분리:

async authenticate(email: string, password: string): Promise<User> {
  const user = await this.userRepository.findOne({ where: { email } });
  if (!user) throw new BadRequestException('잘못된 로그인 정보입니다.');

  const passOk = await bcrypt.compare(password, user.password);
  if (!passOk) throw new BadRequestException('잘못된 로그인 정보입니다.');

  return user;
}

Guard로 적용하기

기본 방식 (문자열 사용):

@UseGuards(AuthGuard('local'))
@Post('login-passport')
loginPassport(@Request() req) {
  return req.user; // validate에서 반환된 유저
}

전용 Guard로 추출 (오타 방지):

export class LocalAuthGuard extends AuthGuard('local') {}

@UseGuards(LocalAuthGuard)
@Post('login-passport')
loginPassport(@Request() req) {
  return req.user;
}

학습 후기

NestJS에서 인증 시스템을 구축하면서 Passport를 적용해보니, 단순히 "전략을 등록해서 Guard로 감싼다"는 문법 이상의 통찰이 생겼습니다. Passport는 단순한 인증 라이브러리가 아니라, 인증 방식을 추상화하고 전략적으로 분리할 수 있도록 도와주는 플러그인 시스템에 가까운 구조입니다.

Local Strategy를 적용하면서 느낀 가장 큰 장점은 인증 흐름이 명확해진다는 점입니다. 기존에는 로그인 요청에서 이메일, 비밀번호를 직접 검증하고 응답하는 코드가 라우터에 함께 존재했다면, 전략으로 분리한 후에는 validate() 메서드에 인증 책임을 위임할 수 있었습니다. 이 덕분에 인증 로직과 라우팅 로직의 관심사가 명확히 분리되었고, 테스트하기도 쉬워졌습니다.

또한 AuthGuard('local')과 같이 전략을 문자열로 지정하여 사용할 수 있고, 이를 별도의 Guard 클래스로 추출해 관리하면 전략 이름 오타를 방지할 수 있으며 재사용성도 높아졌습니다. 특히, usernameField를 email로 변경해 Postman 테스트에서도 혼란 없이 진행할 수 있었고, 실제 전략 간 전환(JWT ↔ Local)도 매우 간편했습니다.

물론 단점도 있었습니다. Passport는 전략 내부 동작이 추상화되어 있어, 처음에는 흐름을 따라가기 어렵고 디버깅이 복잡하게 느껴졌습니다. 특히 NestJS에서 Guard가 validate() 결과를 자동으로 req.user에 실어주는 구조는 문서를 보지 않으면 파악하기 어려운 부분이었습니다. 하지만 내부 흐름을 이해한 후에는 오히려 일관된 인증 구조를 구성할 수 있다는 장점으로 다가왔습니다.

이번 학습을 통해 느낀 가장 중요한 점은, 인증은 단순히 로그인 여부를 판단하는 절차가 아니라, 애플리케이션의 전반적인 보안 흐름을 설계하는 것이라는 사실입니다. Passport를 도입함으로써 인증 전략을 별도로 설계하고, 확장성과 테스트 가능성을 확보할 수 있었던 점이 매우 인상 깊었습니다. 앞으로 JWT 전략까지 결합하면 더 강력한 인증 시스템을 구축할 수 있을 것으로 기대됩니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 종료 시간

공부 시작 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 27일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Sun, 27 Apr 2025 23:11:41 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

const accessTokenSecret = this.configService.get<string>(
  'ACCESS_TOKEN_SECRET',
);
const refreshTokenSecret = this.configService.get<string>(
  'REFRESH_TOKEN_SECRET',
);

return {
  refreshToken: await this.jwtService.signAsync(
    {
      sub: user.id,
      role: user.role,
      type: 'refresh',
    },
    {
      secret: refreshTokenSecret,
      expiresIn: '24h',
    },
  ),
  accessToken: await this.jwtService.signAsync(
    {
      sub: user.id,
      role: user.role,
      type: 'access',
    },
    { secret: accessTokenSecret, expiresIn: 300 },
  ),
};

Access Token
- 유효기간: 5분 (300s)
- 용도: 프라이빗 API 접근
Refresh Token
- 유효기간: 24시간
- 용도: Access Token 재발급
JWT Payload 구성
- Access/Refresh 공통 페이로드:
- ```
{
  sub: user.id,
  role: user.role,
  type: 'access' | 'refresh'
}
```
- signAsync() 호출 시 옵션 별도 적용

학습 후기

이번 강의를 통해 로그인 로직을 직접 구현하며 인증 시스템의 신뢰성과 보안성을 어떻게 확보하는지 구체적으로 이해할 수 있었습니다. Basic Auth를 이용한 로그인 요청 수신부터 JWT 토큰 발급까지의 흐름을 손으로 따라가면서, 인증이 "단순히 동작하는 것"과 "보안적으로 안전한 것"은 완전히 다르다는 사실을 체감했습니다.

Basic 토큰을 디코딩하고 이메일과 비밀번호를 분리하는 과정은 간단해 보였지만, 입력 포맷 오류에 대한 철저한 검증이 중요하다는 점을 깨달았습니다. 입력값 하나조차 방어적으로 다루지 않으면 보안 취약점으로 이어질 수 있다는 교훈이 인상 깊었습니다.

bcrypt를 이용한 비밀번호 비교에서는, 저장된 해시값과 입력값을 안전하게 비교하는 것이 얼마나 중요한지 느꼈습니다. 또한 로그인 실패 시 항상 동일한 에러 메시지를 반환해 해커에게 단서를 주지 않는 세심한 설계가 필요하다는 것도 알게 되었습니다.

JWT 발급 과정에서는 access token과 refresh token을 분리하고, 각각 다른 secret과 만료 시간을 설정해 보안과 UX를 모두 고려하는 방법을 배웠습니다. 특히 jwt.io를 통해 직접 디코딩해보면서, Header, Payload, Signature 구조와 변조 검증 방식까지 확실히 이해할 수 있었습니다.

이번 과정을 통해 인증 시스템을 구축할 때 단순 구현이 아닌 보안을 항상 우선순위에 두어야 함을 다시 느꼈습니다. 앞으로도 인증 로직을 구현할 때 이번 경험을 바탕으로 더욱 신중하고 견고하게 설계하겠다는 다짐을 하게 되었습니다.

학습 인증샷

수강 인증 사진

학습 인증샷

공부 시작 시간

공부 종료 시간

https://abit.ly/lisbva

패스트캠퍼스 환급챌린지 26일차 : 코드팩토리의 백엔드 아카데미 : 한 번에 끝내는 NestJS 패키지 - 기초부터 MSA까지 강의 후기

NangIn — Sat, 26 Apr 2025 20:33:51 +0900

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

강의 내용 정리

User Module 작업하기

인증 구현의 시작: 회원가입 준비

인증 기능은 복잡하므로 모듈을 분리하여 개발
- User 모듈 → 사용자 정보 관리
- Auth 모듈 → 인증 전담 (재사용성 고려)

Nest CLI로 모듈 및 리소스 생성

Auth 모듈 생성
- ```
nest g resource auth
```
- REST API 선택, CRUD 엔드포인트는 생성 안 함
User 모듈 생성
- ```
nest g resource user
```
- REST API 선택, CRUD 엔드포인트는 생성함

User Entity 구성

BaseTable 상속 (공통 컬럼 포함)

주요 컬럼 정의:

export enum Role {
  ADMIN = 'admin',
  PAID_USER = 'paid_user',
  USER = 'user',
}

@Entity('users')
export class User extends BaseEntity {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ unique: true })
  email: string;

  @Column()
  password: string;

  @Column({ enum: Role, default: Role.USER })
  role: Role;
}

User 서비스 및 CRUD 구현

UserModule에 import

// user.module.ts
@Module({
  imports: [TypeOrmModule.forFeature([User])],
  controllers: [UserController],
  providers: [UserService],
})

// app.module.ts
entities: [Movie, MovieDetail, Director, Genre, User],

UserService에 Repository 주입:

constructor(
  @InjectRepository(User)
  private readonly userRepository: Repository<User>
) {}

CRUD 기능 순서대로 구현:

전체 조회:

findAll() {
  return this.userRepository.find();
}

단일 조회:

async findOne(id: number) {
  const user = await this.userRepository.findOne({ where: { id } });
  if (!user) throw new NotFoundException('존재하지 않는 사용자입니다.');
  return user;
}

생성:

create(createUserDto: CreateUserDto) {
  return this.userRepository.save(createUserDto);
}

수정:

async update(id: number, updateUserDto: UpdateUserDto) {
    const user = await this.userRepository.findOne({ where: { id } });
    if (!user) throw new NotFoundException('존재하지 않는 사용자입니다.');
    await this.userRepository.update({ id }, updateUserDto);
    return await this.userRepository.findOne({ where: { id } });
}

삭제:

remove(id: number) {
  return this.userRepository.delete(id);
}

Controller 설정 및 Pipe 적용

@Param('id', ParseIntPipe)로 라우트 파라미터 타입 검증 적용
기본적인 RESTful 라우트 생성 완료

Auth Module 회원가입 작업하기

인증 시작 및 구조 설계

목표: 인증 시스템 구축의 첫걸음으로 회원가입 기능부터 구현
구성 모듈
- User 모듈: 사용자 관리 담당 (CRUD)
- Auth 모듈: 인증 담당 (회원가입, 로그인 등)

User 엔티티 정의

기본 필드

@Entity('users')
export class User extends BaseEntity {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ unique: true })
  email: string;

  @Column()
  @Exclude({ toPlainOnly: true })
  password: string;

  @Column({ enum: Role, default: Role.USER })
  role: Role;
}

id: 기본 PK
email: @Column({ unique: true })
password: @Exclude({ toPlainOnly: true }) → 응답 시 숨김
role: enum 기반 권한 관리 (Admin, PaidUser, User)
- 기본값: User

직렬화 설정
- @Exclude() 데코레이터 → 비밀번호, createdAt, updatedAt, version 숨김
- 컨트롤러에 @UseInterceptors(ClassSerializerInterceptor) 설정 필요

AuthController - 회원가입 API 구현

라우팅
- POST /auth/register: 회원가입 요청을 처리
요청 형식
- 헤더: Authorization: Basic <base64-encoded-email:password>

모듈 등록

@Module({
  imports: [TypeOrmModule.forFeature([User])],
  controllers: [AuthController],
  providers: [AuthService],
})

컨트롤러 구조

@Post('register')
registerUser(@Headers('authorization') token: string) {
  return this.authService.register(token);
}

서비스 등록

  constructor(
    @InjectRepository(User)
    private readonly userRepository: Repository<User>,
  ) {}

AuthService - 회원가입 로직 구현

Basic 토큰 파싱

  parseBasicToken(rawToken: string) {
    // 1) 토큰을 ' ' 기준으로 스플릿한 후 토큰 값만 추출하기
    // ['Basic', 'token']
    const basicSplit = rawToken.split(' ');

    if (basicSplit.length !== 2) {
      throw new BadRequestException('토큰 포맷이 잘못됐습니다!');
    }

    // eslint-disable-next-line @typescript-eslint/no-unused-vars
    const [_, token] = basicSplit;

    // 2) 추출한 토큰을 base64 디코딩해서 이메일과 비밀번호로 나눈다.
    const decoded = Buffer.from(token, 'base64').toString('utf-8');

    // "email:password"
    const tokenSplit = decoded.split(':');

    if (tokenSplit.length !== 2) {
      throw new BadRequestException('토큰 포맷이 잘못됐습니다!');
    }

    const [email, password] = tokenSplit;

    return { email, password };
  }

이메일 중복 검사

const user = await this.userRepository.findOne({ where: { email } });
if (user) throw new BadRequestException('이미 존재하는 이메일입니다.');

비밀번호 해싱 처리

bcrypt 설치
- ```
pnpm i bcrypt 
pnpm i -D @types/bcrypt
```

bcrypt 사용: hash(password, saltRounds)

const hash = await bcrypt.hash(
  password,
  this.configService.get('HASH_ROUNDS') as number,
);

await this.userRepository.save({ email, password: hash });

return this.userRepository.findOne({ where: { email } });

해싱된 비밀번호로 저장

saltRounds는 .env 또는 config 모듈에서 관리 (기본값 10)

```
HASH_ROUNDS=10
```

// app.module.ts
validationSchema: Joi.object({
  // ...
  HASH_ROUNDS: Joi.number().required(),
}),

// auth.service.ts
constructor(
  // ...
  private readonly configService: ConfigService,
) {}

사용자 등록 및 반환
- 해싱된 비밀번호로 DB 저장
- 저장된 사용자 조회 후 반환 (단, password는 직렬화에서 제외됨)

회원가입 테스트 (Postman)

Base64 수동 인코딩: email:password → Authorization: Basic xxxxxxx
Postman 내장 기능 사용: Authorization 탭 → Basic Auth 선택 → 자동 인코딩
요청 성공 시 사용자 정보 반환 (비밀번호 등은 노출되지 않음)

학습 후기

이번 학습을 통해 인증 시스템을 처음부터 직접 구축하는 과정이 왜 이렇게 세밀하게 설계되어야 하는지를 뼈저리게 느꼈습니다. 특히 사용자 모듈과 인증 모듈을 분리하여 개발하는 설계 방식을 통해, 모듈화된 구조가 얼마나 프로젝트 유지보수성과 확장성에 중요한 역할을 하는지 체감할 수 있었습니다. 앞으로 다양한 인증 방식이 추가될 수 있다는 점을 고려하여 처음부터 인증 기능을 분리하는 것이 현명한 판단임을 깨달았습니다.

User 엔티티를 설계할 때 단순히 email과 password만 저장하는 것이 아니라, Role을 명시적으로 구분하여 관리하는 방식이 굉장히 인상 깊었습니다. 이 작은 설계가 나중에 사용자 권한을 다루거나, 관리자와 일반 사용자를 구분하는 복잡한 로직에서 큰 역할을 하게 된다는 사실을 배웠습니다. 또한 패스워드에 @Exclude 데코레이터를 적용하고 직렬화 처리를 통해 응답 데이터에서 민감 정보를 안전하게 숨기는 과정을 보면서, 보안은 단순히 데이터베이스 저장뿐만 아니라 응답 레이어에서도 고려해야 한다는 점을 알게 되었습니다.

Auth 모듈을 통해 회원가입 로직을 구현하면서 Basic Auth 방식을 사용하는 것이 꽤나 깔끔한 패턴이라는 것을 알게 되었습니다. Base64 인코딩된 이메일과 비밀번호를 받아 서버에서 디코딩하고 검증하는 흐름은 직접 구현해보니 단순하지만 강력한 방식이라는 느낌을 받았습니다. 다만 Base64 인코딩은 암호화가 아니라 단순 인코딩일 뿐이므로 반드시 HTTPS로 통신해야 실제 보안이 확보된다는 점도 함께 인지하게 되었습니다.

비밀번호를 bcrypt를 사용해 해싱하는 부분도 매우 중요한 학습이었습니다. 해싱 과정을 직접 적용해보니, 단순한 저장이 아니라 보안성을 높이는 핵심 프로세스임을 실감할 수 있었습니다. 특히 saltRounds를 통해 해싱 속도를 조절하고, 이 값을 환경변수로 관리하는 패턴을 통해 실무에서는 모든 하드코딩을 피하고 설정 가능하게 만들어야 한다는 좋은 습관도 함께 배웠습니다.

전체적인 작업 흐름을 따라가면서 느낀 점은, 하나의 회원가입 기능을 완성하기 위해 수많은 작은 고려사항들이 존재한다는 것이었습니다. 그동안 당연하게 생각했던 로그인/회원가입 기능들이 사실은 보안, 설계, 확장성 등 다양한 측면을 모두 고려한 결과물이라는 사실을 새삼 깨닫게 되었습니다. 이번 과정을 통해 단순히 코드만 따라치는 것이 아니라, 왜 이렇게 설계하는지까지 이해하는 것이 얼마나 중요한지 깊이 체감했습니다. 앞으로도 비슷한 기능을 구현할 때 이번에 배운 설계 원칙과 보안 개념을 반드시 적용하겠다는 다짐을 하게 되었습니다.

학습 인증샷

수강 인증 사진

학습 인증 샷

공부 시작 시간

공부 종료 시간