"웹 개발부터 배포, 운영까지 (5/8) — OAuth와 SSO는 왜 느리게 느껴질까: 로그인 뒤에 숨은 지연 흐름"

-

로그인은 한 화면의 문제가 아니라, 여러 시스템이 짧은 시간 안에 신뢰를 교환하는 과정이다.

핵심 요약

  • OAuth는 권한 위임 규약이고, SSO는 한 번의 인증으로 여러 서비스에 접근하게 만드는 사용자 경험이다.
  • 로그인 지연은 화면 렌더링보다 리다이렉트 -> 인증 확인 -> 토큰 교환 -> 세션 생성 -> 사용자 정보 반영 구간에서 자주 생긴다.
  • 개인용 로그인보다 조직용 SSO는 정책 검사, IdP 연동, 속성 매핑이 추가되어 더 느리게 느껴질 수 있다.
  • 배포 이후 인증 문제는 코드 버그만이 아니라 도메인, redirect URI, 쿠키, 환경 변수 분리 문제로도 나타난다.

1. OAuth와 SSO는 같은 것이 아니다

둘은 같이 등장해서 자주 섞여 보이지만 역할이 다르다.

OAuth는 "내 비밀번호를 직접 넘기지 않고도 다른 앱에 제한된 권한을 위임하는 방식"에 가깝다. 예를 들어 어떤 서비스가 Google 계정으로 로그인 버튼을 제공할 때, 실제 비밀번호 검증은 Google 쪽에서 하고 애플리케이션은 결과 토큰만 받는다.

SSO는 "한 번 인증한 사용자가 여러 서비스에서 다시 로그인하지 않게 하는 구조"다. 회사 환경에서는 SAML이나 OIDC 기반 SSO가 자주 쓰이고, 개인 서비스보다 조직 정책이 더 많이 개입한다.

즉, OAuth는 권한 위임 프레임이고, SSO는 로그인 경험과 조직 접근 제어를 포함한 상위 흐름으로 이해하는 편이 정확하다.

2. 로그인 버튼을 누른 뒤 실제로 무슨 일이 일어날까

사용자는 버튼 하나만 보지만 내부 흐름은 꽤 길다.

  1. 애플리케이션이 사용자를 인증 제공자 로그인 페이지로 리다이렉트한다.
  2. 인증 제공자가 사용자를 확인하고 동의 또는 조직 정책 검사를 수행한다.
  3. 브라우저가 애플리케이션의 redirect URI로 다시 돌아온다.
  4. 애플리케이션이 authorization code를 받아 서버 쪽에서 토큰으로 교환한다.
  5. 받은 토큰으로 사용자 프로필, 조직, 권한 범위를 확인한다.
  6. 애플리케이션 세션이나 쿠키를 만들고 최종 화면을 다시 그린다.

RFC 6749의 authorization code 흐름은 이 구조의 기본 골격이다. 여기서 중요한 점은 로그인 완료가 프론트엔드 한 번의 클릭으로 끝나지 않고, 브라우저와 인증 서버와 애플리케이션 서버가 순차적으로 왕복한다는 점이다.

3. 왜 OAuth와 SSO는 체감상 느리게 보일까

지연은 한 군데가 아니라 여러 짧은 구간이 합쳐져 체감된다.

리다이렉트 왕복

로그인 페이지로 이동하고 다시 애플리케이션으로 돌아오는 과정은 최소 두 번 이상의 네트워크 왕복을 만든다. 모바일 네트워크나 기업망에서는 이 구간이 더 길어진다.

토큰 교환과 세션 생성

authorization code를 access token으로 바꾸는 과정은 보통 서버 사이드에서 일어난다. 이어서 세션 저장, 쿠키 설정, 사용자 정보 조회가 붙으면 로그인 직후 첫 화면이 늦게 뜰 수 있다.

추가 사용자 정보 동기화

서비스가 처음 로그인한 사용자를 내부 DB에 생성하거나 역할을 붙이는 경우, 인증 성공 뒤에도 후처리가 남는다. 그래서 "로그인은 됐는데 홈 화면이 바로 안 뜨는" 경험이 생긴다.

조직형 SSO의 정책 검사

기업용 SSO는 허용된 도메인인지, 어떤 조직에 속하는지, 어떤 그룹 속성값을 갖는지까지 확인하는 경우가 많다. Supabase 문서도 개인 Auth 흐름과 별도로 Project SSO, Organization SSO 흐름을 분리해 설명한다. 이 차이가 체감 지연의 원인이 되기도 한다.

4. 개발 단계에서는 되는데 배포 후 깨지는 이유

인증은 로컬에서 가장 쉽게 "되는 것처럼" 보이지만, 배포 후 가장 자주 깨지는 영역이기도 하다.

첫째, redirect URI가 환경마다 다르다. 로컬에서는 http://localhost:3000/callback이 맞지만, 운영에서는 실제 도메인 경로를 정확히 등록해야 한다. 하나라도 다르면 인증 서버가 코드를 돌려주지 않거나 오류를 반환한다.

둘째, 쿠키와 세션 정책이 달라진다. 로컬에서는 느슨하게 허용되던 설정이 실제 HTTPS 도메인 환경에서는 SameSite, Secure, 서브도메인 범위 문제로 드러난다.

셋째, 프론트엔드와 백엔드가 서로 다른 도메인에 있으면 CORS, 쿠키 전달, 프록시 설정 문제가 얽힌다. 이때 사용자는 단순히 "로그인이 느리다" 혹은 "한 번 더 로그인하라고 한다"로 체감한다.

5. 운영 관점에서 꼭 확인해야 할 체크포인트

로그인 기능을 붙였다는 사실보다, 운영 가능한 인증 구조인지가 더 중요하다.

redirect URI와 callback 경로

개발, 스테이징, 운영 도메인을 분리해서 모두 명시적으로 관리해야 한다.

토큰 수명과 재발급

access token은 짧고 refresh token은 더 길게 운영되는 경우가 많다. 세션 만료 정책을 모르면 "가끔 자동 로그아웃된다"는 현상만 보게 된다.

최소 권한 요청

OAuth는 필요한 범위만 요청하는 것이 기본 원칙이다. 권한을 넓게 잡을수록 보안과 사용자 신뢰 문제가 커진다.

에러 로깅

사용자는 "로그인이 안 된다"고 말하지만, 실제 원인은 invalid redirect URI, state mismatch, 쿠키 누락, 토큰 교환 실패처럼 다양하다. 인증 실패 지점을 단계별로 로그에 남겨야 운영이 가능하다.

6. 입문자가 가져가면 좋은 구조적 이해

인증을 붙일 때 중요한 질문은 "어느 라이브러리를 쓰지?"보다 "어디서 지연과 실패가 생기는가?"다.

OAuth와 SSO를 붙인 뒤에는 아래 구간을 별도로 생각하는 습관이 좋다.

  • 브라우저 이동 구간
  • 인증 제공자 확인 구간
  • 서버 측 토큰 교환 구간
  • 내부 사용자 생성 및 권한 반영 구간
  • 최종 세션 반영 구간

이렇게 분해해서 보면, 로그인은 더 이상 마법이 아니라 관찰 가능한 운영 흐름이 된다.

참고 자료

  • IETF, RFC 6749: The OAuth 2.0 Authorization Framework — https://www.ietf.org/rfc/rfc6749.txt.pdf
  • IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security — https://www.ietf.org/rfc/rfc9700.pdf
  • Supabase Docs, Auth — https://supabase.com/docs/guides/auth/
  • Supabase Docs, Project SSO (SAML) — https://supabase.com/docs/guides/auth/enterprise-sso/auth-sso-saml
  • Supabase Docs, Organization SSO — https://supabase.com/docs/guides/platform/sso

이 글은 웹 개발부터 배포, 운영까지 시리즈의 5/8편이다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »