앞으로 최종 프로젝트를 진행하면서 겪었던 일들을 기록하고자 한다
트랜잭션 관리 개선
적용 배경
기존의 트랜잭션 방식은 트랜잭션이 필요한 메서드마다 QueryRunner를 이용하여 하나의 데이터베이스의 연결을 생성하고 컨트롤하였다. 그러다보니, 트랜잭션이 필요한 메서드마다 QueryRunner를 이용해야만했고, 이러한 방식은 굉장히 복잡해보이고 가독성이 떨어졌다. 그래서 트랜잭션을 간편하게 적용할 수 있도록 수정하게 되었다.
적용 방법1: TransactionInterceptor 이용하기
interceptor를 이용하여 트랜잭션이 필요한 라우터 핸들러에 도달하면 QueryRunner를 생성하여 주입하는 방식으로 작성하였다.
이와 같은 방식은 라우터 핸들러를 통해서만 QueryRunner를 전달할 수 있지만, Nest.js가 Interceptor를 사용하는 방식을 권장하며 구현이 비교적 쉬워 손쉽게 적용할 수 있었다.
문제 발생
그러나 Interceptor를 이용하는 방식에서는 서비스 계층에서 트랜잭션을 적용하기 위해서는 라우터 핸들러를 거쳐야만 하는 문제가 발생했다.
특히 Google OAuth에서는 GoogleAuthGuard가 GoogleStrategy를 사용해 인증 절차를 처리한다. Nest.js의 LifeCycle를 보면, Interceptor보다 Guard가 먼저 동작하도록 설계되어 있다.
따라서 인증이 통과되면, Google에서 전달받은 사용자 정보를 바탕으로 유저를 생성하게 되는데, Interceptor보다 앞서서 동작하므로 트랜잭션을 적용할 수 없다는 문제가 발생하였다.
적용 방법2: TransactionMiddleware 이용하기
그래서 이러한 문제를 해결하기 위해 cls-hooked 라이브러리를 이용한 TransactionMiddleware를 적용하였다.
Node.js는 단일 스레드를 사용하기 때문에, 비동기 작업 간 상태를 전달하기 어렵다.(사용자 정보, 트랜잭션 등) cls-hooked는 이러한 비동기 작업 체인에서 context를 유지하고 상태들을 쉽게 공유할 수 있게 도와준다.
cls-hooked를 이용하여 TRANSACION이라는 namespace를 만들어서 EntityManager를 설정하고, @Transactional()이라는 데코레이터를 만들어서 서비스 계층에서 해당 메서드에 손쉽게 트랜잭션을 적용할 수 있었다.
Google OAuth
적용 배경
소셜 로그인은 신뢰할 수 있는 보안 시스템을 가지고 있다. 따라서 사용자가 이미 신뢰하고 있는 서비스를 통해 로그인을 함으로써, 애플리케이션에 대한 신뢰성을 높이고 싶었다.
또한 사용자가 회원가입 절차를 거치지 않고도 빠르게 서비스에 접근할 수 있어 사용자 경험을 향상시키고자 하였다.
적용 방법: Passport 라이브러리 사용하기
Passport라는 라이브러리를 사용하였는데, Google OAuth만 적용하는게 아니라 naver, kakao, github 등 여러가직 OAuth를 적용해야하기 때문에, 확장성이 뛰어난 Passport 라이브러리를 사용하기로 했다. Passport는 모듈화된 전략 패턴을 사용하여 각 OAuth 제공자별로 간편하게 설정할 수 있다.
이를 통해 사용자는 간편하게 Google 계정으로 로그인할 수 있게 되었다. 또한 추가적으로 Naver, Kakao, GitHub 등 다른 OAuth도 구현해볼 생각이다.
마무리
Google OAuth 구현은 생각보다 어려웠다. 처음에는 쉽게 생각했지만, Passport의 동작 방식을 이해하는 데 어려움을 격었고, 트랜잭션이라는 복병이 숨어있던 터라 구현하는데 시간이 많이 걸린 것 같다.
그래도 이러한 작업을 마무리하게 되어서 뿌듯하다. 하지만 아직도 해야할 일이 산더미같다. 기존의 CI/CD 방식이 맘에들지 않아 젠킨스를 활용한 방식으로 수정해볼 계획이고, ECS도 도입해볼 생각이다.
처음에는 해결할 수 있을까 고민했던 작업들을 하나씩 해결하면서 점점 성장하고 있는 것 같다. 조급해지지 말고, 지금처럼만 해보자!
