로그인 / 인증 / 인가 & OAuth 2.0 정리

로그인 / 인증 / 인가 차이

구분	의미	예시
로그인(Login)	서비스 접속 시도 행위	로그인 버튼 클릭
인증(Authentication)	사용자가 누구인지 증명	구글/카카오가 신원 확인
인가(Authorization)	무엇을 할 수 있는지 권한 부여	글쓰기, 관리자 기능

순서:
로그인 → 인증 → 인가

소셜 로그인 핵심 개념

카카오 로그인 = 카카오가 인증해 준 것일 뿐, 우리 서비스 계정은 따로 관리해야 함

• 카카오/구글은 신원 보증자 역할
• 실제 서비스 계정은 우리 DB에 따로 생성

OAuth 2.0이 필요한 이유

기존 로그인 방식 문제
서비스마다 ID / PW 생성 필요
비밀번호 유출 위험
보안 관리 비용 증가

해결 방법
❝ 비밀번호 대신 토큰을 사용하자 ❞

• 서비스가 비밀번호를 직접 저장하지 않음
• 인증 책임을 대형 플랫폼에 위임

OAuth 2.0 구성 요소

역할	의미	예시
Resource Owner	사용자	앱 사용자
Client	우리 앱	Flutter 앱
Authorization Server	인증 서버	카카오/구글
Resource Server	API 서버	프로필 API
Access Token	API 권한	정보 조회 토큰
ID Token	사용자 정보	JWT 형태

토큰 종류

Access Token

목적: API 호출
용도: 사용자 정보 조회

ID Token (JWT)

목적: 사용자 식별
포함 정보: id, email, provider 등

소셜 토큰 vs 서비스 JWT 차이

소셜 로그인 토큰

발급자: 구글/카카오
용도: 인증 + 프로필 조회
범위: 해당 플랫폼 전용

서비스 JWT

발급자: 우리 서버
용도: 서비스 로그인 유지
범위: 우리 서비스 전용

👉 구조:
카카오 토큰 → 서버 검증 → 우리 JWT 발급 → 서비스 이용

실무 이슈

이메일 기반 계정 설계 문제

❌ 잘못된 방식
userId = kakaoEmail

발생 문제
1. 이메일 미제공 → 로그인 불가
2. 이메일 변경 → 계정 분리
3. 탈퇴 후 재가입 → 새 계정 인식

→ 계정 관리 붕괴 😇

해결 방법

Provider 고유 ID 사용

✅ 올바른 방식
kakao_123456789
google_987654321

구조 예시
provider + "_" + providerUserId

장점
이메일 없어도 OK
이메일 변경 영향 없음
재가입 시 동일 계정 유지
계정 충돌 방지

전체 로그인 흐름 정리

1. 앱 → 카카오 로그인 요청
2. 카카오 → 인증 완료
3. 토큰 발급
4. 앱 → 서버로 토큰 전달
5. 서버 → 카카오 서버 검증
6. provider_id 획득
7. 우리 DB 계정 생성/조회
8. 우리 JWT 발급
9. 서비스 이용

---

RAG

RAG (Retrieval-Augmented Generation)

개념

RAG = 검색 + 생성 결합 구조
LLM이 답변을 만들기 전에
-> 외부 데이터베이스에서 관련 정보를 먼저 검색하고
-> 그 결과를 기반으로 답변을 생성하는 방식

“모델 기억에만 의존”
“검색 → 참고 → 답변 생성”

흐름

질문 입력
↓
문서 검색(Vector DB 등)
↓
관련 문서 추출
↓
LLM에게 전달
↓
답변 생성

장점

항목	설명
최신 정보 반영	학습 안 된 데이터도 사용 가능
정확도 향상	근거 기반 답변
할루시네이션 감소	거짓 정보 감소