NestJS 도입기

1. 도입 이유

현재 Firebase Functions API는 정상적으로 동작하고 있다. NestJS를 도입하는 목적은 기존 Functions를 교체하거나 현재 장애를 해결하기 위함이 아니다. HTTP API가 늘어날 때 현재 구조에서 발생할 수 있는 설정 누락과 변경 영향 확대를 미리 방지하기 위함이다.

1. 인증 정책 설정 누락 방지

현재 router.ts는 각 route의 requiresAuth를 true 또는 false로 직접 지정한다. 새 route를 추가할 때 인증 여부를 잘못 지정하면 인증이 필요한 endpoint가 보호되지 않을 수 있다.

NestJS API에서 FirebaseAuthGuard를 인증이 필요한 Controller 전체에 적용하면 해당 Controller에 추가되는 endpoint는 개별 boolean 설정 없이 동일한 인증 절차를 거친다. 이로써 route를 추가할 때마다 requiresAuth 값을 반복해 지정하는 구조적 누락을 방지한다.

2. 변경의 배포 영향 확대 방지

현재 Todo, WebPage, Push Notification, Apple, Google, GitHub HTTP API는 모두 하나의 Firebase Function인 api에 포함된다. 이 중 하나의 기능만 변경해도 배포 단위는 api 전체가 된다.

선택한 업무 API를 독립적인 NestJS + Cloud Run service로 분리하면 해당 service의 변경은 기존 Functions api를 재배포하지 않는다. 이로써 업무 API 변경이 OAuth와 다른 기존 endpoint의 배포·rollback 범위까지 확대되는 것을 방지한다.

3. 불필요한 OAuth Secret 접근 방지

현재 api는 Apple, Google, GitHub 인증에 필요한 Secret을 하나의 Function에 모두 연결한다. 따라서 Todo처럼 OAuth Secret을 사용하지 않는 요청도 같은 실행 단위에서 처리된다.

Todo 전용 NestJS + Cloud Run service에는 OAuth Secret을 주입하지 않고 Firebase Auth 검증과 Firestore 접근에 필요한 권한만 부여한다. 이로써 Todo API 실행 단위가 사용하지 않는 provider Secret에 접근할 수 있는 구조를 방지한다.

4. 전역 모듈 대체에 의한 시험 결합 방지

현재 rest-api.test.js는 Firebase Admin, Firestore, onRequest, logger와 인증 모듈을 require.cache에서 교체한 뒤 api를 불러온다. 대체 모듈이 늘어나면 시험이 모듈 로드 순서와 전역 cache 상태에 더 크게 의존하게 된다.

NestJS의 의존성 주입으로 Service, Repository, Firebase Auth provider를 모듈 단위에서 교체하면 require.cache를 변경하지 않고도 시험 경계를 구성할 수 있다. 이로써 시험 간 전역 모듈 상태가 서로 영향을 주는 구조를 방지한다.