이 글은 "데이터 저장 방식 구현 과제"를 수행하기 전, 인증 시스템을 설계하기 위해 반드시 이해해야 할 주요 개념들을 정리한 글입니다. 프론트엔드부터 백엔드, 그리고 보안 요소까지 아우르는 인증 흐름의 기초를 다집니다.
✨과제 배경
이 과제는 다음과 같은 환경과 조건 속에서 로그인 기능을 구현하는 것이 핵심입니다!
과제를 구현하기에 앞서 관련 개념들을 정리해보았으며, 각 개념에 대한 구체적인 내용은 별도 포스팅으로 이어갈 예정입니다.
1. 사용자 인증 방식의 이해
세션 기반 인증이란?
- 사용자가 로그인하면 서버에서 세션을 생성하고, 이를 식별할 수 있는 session ID를 쿠키를 통해 클라이언트에게 전달합니다.
- 이후 사용자는 모든 요청에 해당 쿠키를 자동 포함시키며 서버는 이를 통해 사용자를 식별합니다.
✅ 결론 : 서버가 주도한다.
서버는 클라이언트가 로그인하면,
- 내부에 세션 정보를 저장하고
- Set-Cookie로 session ID를 쿠키에 담아 브라우저에 보낸다.
- 이때 쿠키의 이름, 값, 보안 옵션(HttpOnly, Secure, Max-Age 등)을 함께 전달한다. → 클라이언트는 쿠키 설정에 관여할 필요가 없다.
- 클라이언트는 이 쿠키를 자동으로 저장한다.
클라이언트 역할은?
- 이후 모든 요청마다 해당 도메인에 대해 쿠키를 자동으로 포함시켜 전송한다.
- 이 쿠키에는 sessionId가 포함되어 있으며, 서버는 이를 통해 사용자를 식별한다.
🍪 쿠키 속성 정리
HttpOnly
쿠키에 HttpOnly 속성을 설정하여 JavaScript에서 해당 쿠키에 접근을 제한한다.
- 장점
- XSS(크로스 사이트 스크립팅) 공격으로부터 쿠키 탈취를 방지할 수 있다.
- 주로 세션 토큰, 로그인 정보 등 민감한 쿠키에 적용한다.
Secure
Secure 속성이 설정된 쿠키는 HTTPS 프로토콜에서만 브라우저가 전송한다.
- 장점
- 평문 HTTP 전송 중 쿠키 탈취를 방지한다.
SameSite
SameSite는 쿠키의 크로스 사이트 전송 여부를 제어하는 속성이다. 다른 도메인에서 요청이 발생했을 때 쿠키를 함께 보낼지 결정한다.
- 종류
- Strict: 같은 사이트에서만 쿠키 전송을 허용한다(가장 높은 보안성).
- Lax: 기본값으로, GET 요청에 한해 외부 사이트에서도 전송을 허용한다.
- None: 크로스 사이트 요청에도 쿠키 전송을 허용한다.
보안을 강화하기 위해서 로그인 쿠키에는 위 속성들을 반드시 설정하는 것이 권장됩니다!
2. 비밀번호 저장과 암호화
🔐 단방향 암호화 (해시 함수)
- 입력값을 고정된 길이의 해시값으로 변환
- 복호화 불가 (완전한 단방향)
- 비밀번호 저장에 최적(SHA256, bcrypt)
🙋♀️ 해시값으로 공격자는 비밀번호를 유추할 수 있지 않나요?
맞다,
- 대표적인 공격 방식들
- 무차별 대입 공격
- 사전 공격 (Dictionary Attack) : 자주 쓰이는 비밀번호를 미리 해시해서 비교
- 레인보우 테이블 공격(Rainbow Table Attack)
- 대규모 해시 결과를 저장한 테이블믄 만들어 놓고 비교.
- SHA256 같이 빠른 알고리즘은 이 공격에 특히 취약
- 필요한 대책 (해시값에 추가처리)
- Salt : 해시 전에 무작위 문자열을 비밀번호에 추가 → 해시값 다양화
- 느린 해시 알고리즘 : bcrypt, argon2, scrypt 등 고의로 느리게 만들어 공격 속도 저하
- Paper : 서버 내부 비밀 문자열을 추가
3. 대칭키 / 비대칭키 이해
🔁 대칭키 암호화
- 하나의 키로 암호화와 복호화를 모두 수행.
- 속도는 빠르지만 키 공유가 어려움.
🔐 비대칭키(RSA) 암호화
- 공개키로 암호화, 개인키로 복호화.
- 클라이언트는 서버의 공개키를 사용해 데이터를 암호화하고, 서버는 개인키로만 복호화 가능.
실무에서는 보통 대칭키 + 비대칭키 조합(예: HTTPS 내부 구조)을 사용한다고 합니다.
양방향 암호화와 비대칭키 암호화는 다다음 포스팅에서 자세히 다루도록 하겠습니다. (추가 과제)
4. PostgreSQL의 활용
PostgreSQL은 오픈소스 관계형 데이터베이스 시스템(RDBMS)중 하나로, 강력한 기능과 안정성을 갖춘 기업용 데이터베이스로 널리 사용되고있다.
🌟 장점
- 트랜잭션 안정성 : 오랜 개발 역사와 철저한 트랜잭션 처리로 매우 안정적
- JSON + SQL 병행 처리 : 관계형과 문서형 데이터 구조를 동시에 다룰 수 있음
- 오픈소스 : 라이선스 비용이 없고 커스터마이징 가능
- 다양한 인덱싱 방식 : B-Tree, Hash, GIN, GiST 등 다양한 인덱스 제공
⚠️ 단점
- 학습 곡선 : 고급 기능이 많아 처음 접하는 사람에겐 다소 복자할 수 있다.
- 대규모 수평 확장 : MySQL에 비해 샤딩(수평 분산) 관련 기능이 부족하고 복잡하다.
- GUI 도구 부족 : MySQL Workbench처럼 공식 GUI는 없고, pgAdmin은 다소 무겁고 제한적이다.
- 쓰기 성능 : TPS 기준으로는 일부 환경에서 MySQL보다 느릴 수 있다.
5. 클라이언트 스토리지 이해 SessionStorage vs LocalStorage
항목 | SessionStorage | LocalStorage |
범위 | 탭 단위 | 브라우저 전체 |
만료 | 탭 닫을 시 삭제 | 수동으로 삭제 전까지 유지 |
보안 | 민감 정보 저장 ❌ | 민감 정보 저장 ❌ |
민감한 인증 정보는 절대 저장하지 않도록 주의해야 하며,
이 과제에서도 브라우저 스토리지에 비밀번호 저장은 금지되어 있습니다.
지금까지 과제 수행 전 숙지해야할 개념들을 정리해보았습니다. 2편에서는 이러한 개념들을 바탕으로 실제로 Next.js + PostreSQL 기반 로그인 시스템을 구현해보겠습니다.
'📂 BE' 카테고리의 다른 글
[데이터 저장 방식 2편] SHA256로 암호화된 로그인 시스템 만들기: Next.js부터 PostgreSQL, Docker 패키징까지 구현기 (3) | 2025.05.23 |
---|---|
[Docker] Docker 기초 개념 및 핵심 정리 (0) | 2025.05.19 |