[TIL/Nest] 2025/05/08

NestJS + Google OAuth + Session 중간 정리 🤮

이 글은 부적절한 정보를 제공할 가능성이 매우 높습니다. 오늘은 정말 자신이 없습니다. 절대로 믿지 마십시오.

0. Overview ✍️

아,,, 고민이 정말 많았던 주제고 여전히 완벽하게 해결되지는 않았습니다만, 완벽이라는 건 없죠. 계속 발전해 나가는 것이지요. 세션 방식을 구현하는 과정에서 제가 겪고 있는 문제들을 공유하고자 합니다.

우선은 구체적인 논의에 앞서 정리본을 공유하고자 합니다. 아래 제시된 목차는 이미지의 순서와 동일합니다.

클라이언트를 나 자신이라고 생각하면 좋습니다. 서버는 서랍이고, 회원 DB는 암기 노트이며, 세션 DB는 컨닝 페이퍼죠. 그게 뭔데.

내 머리는 stateless 합니다. 외운 것을 계속 까먹죠. 그래서 서랍에서 암기 노트를 꺼내서 보고 싶습니다. 하지만 시험 중입니다. 미리 만들어놓은 포스트잇 컨닝 페이퍼에는 시험에 나올 것으로 예상한 개념이 적혀있는 페이지 번호가 적혀 있습니다.

다행히 감독관이 좀 널널합니다. 포스트잇에 보니 39페이지에 예상 문제에 대한 개념이 있다고 하네요. 그 페이지를 통해 암기 노트를 읽어 기억을 복원하고 문제를 풀어냅니다.

반칙을 썼으니 나쁜 놈이지만 지금 도덕 얘기를 하고 있는 것은 아니죠. 위 비유가 완벽히 적절하지도 않습니다만, 이 정도 발악이 없으면 이어질 내용을 이해하기 참 어렵습니다.

1. Click Google Button ✍️

문득 로그인이 하고 싶어졌습니다. 하필이면 구글로 하고 싶어졌습니다. 회원가입은 되어 있는 상태입니다.

회원가입 때와 동일한 프로세스(구글 프로세스)를 진행합니다. 구글로 로그인을 하겠다는 말은, 구글 서비스를 한 번은 거쳐야 한다는 말과 같기 때문입니다.

회원가입 프로세스에서는 유저 정보가 없었기에, /phone 경로로 이동한 뒤 verification 절차를 거쳐야 했습니다. 현재는 이미 회원가입이 완료된 유저임을 전제하기 때문에, Database에서 해당 유저를 찾는 로직이 필요합니다.

2. Find user in the user database ✍️

아 여기서부터 탈모가 진행되는데요, 저의 최종적인 목표는 구글 유저 정보를 가져오는 것이 아니었습니다. 엄밀히 따지면 '구글을 통해 가입한 우리 유저'에 대한 정보가 필요했습니다.

구글에서 제공하는 고유한 accountId를, 최종 유저 테이블의 외래키로 사용하는 것이 정석에 가까우나, 개떡같은 데이터 구조 때문에 어려움이 있었고, 여기서 많은 시간을 지체할 수는 없었습니다. 다행히 두 테이블이 공통적으로 email 값을 갖고 있었기에 email로 접근해서 최종 유저 정보를 꺼내왔습니다. 그 정보가 코드 상의 viaGoogleUser에 해당합니다.

좋은 기획은 변경사항이 적은 기획이라는 점을 다시금 생각해 보며, 이어서 내용을 공유하겠습니다.

3. Create session ✍️

세션을 생성하기 위해서는, 기초적인 설정 작업이 필요합니다. 간단하게만 설명하겠습니다.

app.use()에는 기본적으로, 서버로의 요청과 응답에 대한 처리를 진행하는 미들웨어가 들어가게 됩니다. 그렇다면 cookie와 session, 그리고 passport를 사용하겠다고 명시한 것으로 위 코드를 해석할 수 있습니다.

4. Serialize session ID ✍️

serializeUser() 함수가 전달받는 user는 viaGoogleUser입니다. 세션에 최종 유저의 id를 저장하겠다는 뜻입니다.

이후 컨트롤러에서 req.login()을 실행하면 session ID가 생성됩니다.

5. Response + session ID ✍️

간단하게만 생각해 보죠. 지금 우리의 목적은, 원하는 데이터의 id를 세션에 저장한 뒤, 세션 id를 클라이언트로 '쿠키에 담아' 전달하는 것입니다. 일단 클라이언트에 쿠키가 있는지 확인해 봅시다.

아 아주 탈취하고 싶게 잘 도착했습니다. 기회가 되면 해킹을 공부해 보고 싶다는 생각이 듭니다.

6. Request protected data ✍️

overview에서 제시한 6번에 대한 흐름을 확인해 보죠.

세션 id가 쿠키에 담긴 상태로 클라이언트에 왔으니, protected data에 대해 요청을 보내면, 서버로 쿠키가 전송되어야 합니다.

그리고 쿠키에 대한 validation을 거친 뒤 세션 id를 확인하고, 세션 id에 맞는 세션 유저 정보를 복원해서 다시 클라이언트에 전달해 줘야 합니다. 우선 클라이언트에서는 다음과 같이 처리했습니다.

위 로직은 앱바에 작성되어 있습니다. 앱바가 모든 페이지에 걸쳐 있으니, 어떤 페이지를 가든 지속적으로 세션 정보를 가져오는 요청을 수행할 것입니다.

로그인을 이미 했는데 지속적으로 사용자 세션 정보를 요청한다? 이거야말로 protected data에 대한 요청이라고 할 수 있겠죠.

7. Validate Cookie ✍️

7번 파트에서는 설명이 아니라 석고대죄를 하려 합니다.

사실 NestJS에서 세션 방식을 구현하려면 Guard와 Strategy라는 개념을 적용해야 합니다. 하지만 처음부터 너무 많은 것을 고려하게 되면, 한 발짝도 못 움직이게 됩니다.

즉, 현재로서는 validate 로직이 없습니다. 바로 역직렬화로 가시죠.

8. Deserialize session ID ✍️

세션 id를 통해 세션에서 실제 저장된 유저의 id를 가져오고, 그 값을 통해 유저 정보를 복원해서 전달합니다.

9. Response ✍️

데이터가 잘 도착했음을 확인할 수 있네요.

Foreign key로 database를 mapping 해야 하는데 일단 email로 viaGoogleUser를 파싱 했다는 점, Guard와 Strategy를 적용하지 않았다는 점, 세션 ID를 제외하고 프론트엔드에 내려야 할 최소 data에 대한 정리가 끝나지 않았다는 점, 쿠키값(세션 ID)를 통한 UI/UX 처리가 진행되지 않았다는 점 등의 한계가 남아있습니다.

10. Conclusion ✍️

아 쉽지 않은데요. 수학 실력은, 쎈수학 C 레벨 문제를 혼자 끙끙대면서 풀 때 느는 법이지요. 오늘 뭔가 잘 풀리지 않았다면, 축하합니다 성장하셨습니다. 잠깐 안 풀리는 걸로 주눅 들지 마십시오. 잘 해낼 겁니다. (블로그를 우연히 보게 된 누군가에게)