본문 바로가기

전체 글55

JWT와 JWKS — Token을 서명하고 검증하는 방법 앞선 글에서는 Public Key와 Private Key가 하나의 Key Pair로 사용되고, Digital Signature에서는 Private Key로 Signature를 생성하고 Public Key로 이를 검증하는 원리를 살펴봤다.→ 공개키와 개인키 — 암호화와 디지털 서명의 원리 그보다 앞에서는 Token이 Client가 Server에 제시하는 Credential이고, Token의 검증 구조에 따라 Opaque Token과 Self-contained Token으로 나눠볼 수 있다는 점을 살펴봤다.→ Token 기반 인증 이해하기 — Bearer, Access·Refresh Token 이제 이 두 개념을 연결해보자.Opaque Token은 Token 자체만으로 의미를 알기 어렵기 때문에 Server.. 2026. 9. 27.

공개키와 개인키 — 암호화와 디지털 서명의 원리 인터넷에서는 데이터를 다른 사람이 읽지 못하도록 보호해야 할 때도 있고, 전달받은 데이터가 중간에 변경되지 않았는지 확인해야 할 때도 있다. 이런 문제를 해결하기 위해 Cryptography에서는 여러 종류의 Key와 Algorithm을 사용한다.그중 비대칭키 방식에서는 서로 수학적으로 연결된 Public Key와 Private Key를 하나의 Key Pair로 사용한다.두 Key 중 Private Key는 소유자만 비밀로 유지하고, Public Key는 다른 사람에게 공개할 수 있다. 이 Key Pair는 단순히 데이터를 암호화하는 데만 사용되는 것은 아니다.대표적으로 다음 두 가지 문제를 해결하는 데 사용할 수 있다.Encryption — 허가되지 않은 사람이 데이터의 내용을 읽지 못하게 한다.Dig.. 2026. 9. 27.

Token 기반 인증 이해하기 — Bearer, Access·Refresh Token 앞선 글에서는 Session 기반 인증에서 서버가 로그인 상태를 Session Store에 저장하고, 브라우저는 해당 Session을 찾기 위한 Session ID를 전달하는 구조를 살펴봤다. Token 기반 구조에서는 Client가 서버가 검증할 수 있는 Credential을 요청과 함께 전달한다.Client → Token 전달 → Server가 Token 검증 → Resource 접근 여부 결정 하지만 Token이라고 해서 모두 같은 형태나 같은 역할을 가지는 것은 아니다.실제 API 요청에 사용하는 Access Token이 있고,새로운 Access Token을 발급받는 데 사용하는 Refresh Token이 있다.또 Token 자체도 서버 측 상태를 조회해야 의미를 알 수 있는 Opaque Toke.. 2026. 9. 26.

Session의 동작 원리 — Session ID와 서버 측 상태 관리 앞선 글에서는 Cookie가 브라우저에 값을 저장하고, 조건에 맞는 HTTP 요청에 자동으로 포함하는 메커니즘이라는 점을 살펴봤다. 웹 인증에서는 Cookie에 다음과 같은 값을 저장하는 경우가 많다.Cookie: session_id=abc123 하지만 abc123이라는 값 자체에 사용자의 로그인 상태가 모두 들어 있는 것은 아니다.실제 인증 상태는 서버에 저장하고, 브라우저에는 그 상태를 찾기 위한 Session ID만 전달할 수 있다.Browser → Session ID → Server → Session Store → 사용자 상태이 구조가 일반적인 Session 기반 인증이다. 이번 글에서는Session이 어떻게 생성되고 요청마다 사용되는지Session ID를 왜 안전하게 관리해야 하는지만료와 로그아.. 2026. 9. 26.

Cookie의 동작 원리 — Scope와 보안 속성 앞선 글에서는 Cookie, Session, Token의 역할을 구분했다.그중 Cookie는 브라우저가 값을 저장하고, 조건에 맞는 HTTP 요청에 자동으로 포함할 수 있는 메커니즘이다. 하지만 브라우저에는 Cookie만 저장되는 것은 아니다.대표적으로 Cookie Store, localStorage, sessionStorage, IndexedDB, Cache Storage 같은 저장 공간이 있다.이 가운데 Cookie가 다른 저장소와 구분되는 중요한 특징은 HTTP 요청과 직접 연결되어 있다는 점이다. 예를 들어 localStorage에 저장한 값은 JavaScript가 직접 읽고 필요한 경우 Request Header 등에 넣어야 한다.반면 Cookie는 브라우저가 Host, Domain, Path,.. 2026. 9. 25.

웹 인증의 기본 — Cookie / Session / Token 웹 애플리케이션에서 로그인 기능을 구현하다 보면 Cookie, Session, Token이라는 용어가 반복해서 등장한다.세 가지 모두 로그인과 인증 과정에서 함께 사용되기 때문에 비슷한 개념처럼 보이지만 실제로 담당하는 역할은 다르다.개념역할Cookie브라우저가 값을 저장하고 요청에 전달하는 메커니즘Session서버가 사용자의 상태를 유지하는 방식Token클라이언트가 서버에 제시하는 Credential특히 Cookie와 Session은 서로 경쟁하는 인증 방식이 아니다.예를 들어 Session 방식에서는 서버가 로그인 상태를 Session Store에 저장하고, 그 Session을 찾기 위한 Session ID를 Cookie에 담아 브라우저에 전달하는 경우가 많다. Token 역시 Cookie에 저장할 .. 2026. 9. 25.

VPN과 Overlay Network — WireGuard와 NetBird 서로 다른 네트워크에 있는 장비가 통신하려면 목적지까지 패킷이 이동할 수 있는 경로가 필요하다.같은 LAN에 있는 장비라면 같은 네트워크 안에서 비교적 단순하게 통신할 수 있다. 하지만 사무실 PC에서 데이터센터의 Private Network에 접근하거나, 서로 다른 지역의 서버를 하나의 내부망처럼 연결하려면 중간의 인터넷이나 다른 네트워크를 거쳐야 한다. 이때 사설 IP 주소는 공용 인터넷에서 그대로 Routing되지 않기 때문에 서로 떨어진 네트워크 사이에 별도의 논리적인 통신 경로가 필요할 수 있다. 이런 경로를 만드는 방법 중 하나가 VPN(Virtual Private Network)이다.WireGuard는 암호화된 Tunnel을 구성하는 VPN Protocol이고, NetBird는 WireGua.. 2026. 9. 25.

네트워크 기초 — IP, Subnet, CIDR 그리고 Routing 앞에서는 Reverse Proxy가 외부 요청을 받아 내부 서비스로 전달하는 구조를 살펴봤다.하지만 Reverse Proxy에 요청이 도착하기 전에는 IP 네트워크에서 패킷이 목적지까지 이동하는 과정이 먼저 일어난다.Client는 목적지 IP가 같은 네트워크에 있는지 판단하고, 다른 네트워크라면 라우팅 테이블에 따라 다음 홉(Next Hop)으로 패킷을 전달한다. 라우터 역시 자신의 라우팅 테이블을 확인하면서 같은 과정을 반복한다.WireGuard나 NetBird에서 등장하는 CIDR, Routing Peer, Network Resource 같은 개념도 결국 이 IP Routing 구조 위에서 동작한다.이번 글에서는 그 기반이 되는 IP 주소, 서브넷, CIDR, 기본 게이트웨이와 라우팅을 알아본다.목차.. 2026. 9. 25.

Reverse Proxy — 구조와 운영 시 주의할 점 웹 서비스를 구성하다 보면 사용자가 보는 하나의 서비스 뒤에 여러 서버가 존재하게 된다.예를 들어 화면은 Frontend가 처리하고, 로그인과 세션은 IAM이 담당하며, 실제 데이터 요청은 별도의 Backend API가 처리할 수 있다.역할서비스 예시화면 제공Frontend로그인·인증IAM데이터 처리Backend API운영 기능Admin Console 각 서비스를 서로 다른 주소와 Port로 직접 노출하는 것도 가능하다.서비스주소 예시Frontendapp.example.com:3000IAMauth.example.com:8000Backend APIapi.example.com:9000하지만 브라우저가 각 서비스의 주소를 직접 알고 접근하는 구조에서는 Cookie, CORS, TLS 인증서, Client IP.. 2026. 9. 25.

PostgreSQL 내부구조 1~8편 총정리 PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 PostgreSQL 내부구조 시리즈에서는 각각의 기능을 따로 외우기보다, 데이터 하나가 저장되고, 읽히고, 수정되고, 복구되고, 정리되는 과정을 따라가며 PostgreSQL의 내부 동작을 살펴봤다. 시리즈 전체에서 반복해서 등장한 가장 기본적인 단위는 8KB Heap Page와 Tuple이다.Page에 저장된 Tuple을 여러 Transaction이 동시에 읽고 수정하고, 변경 내용은 WAL에 기록되며.. 2026. 9. 25.

PostgreSQL 내부구조 (8) ㅡ TOAST PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 1편에서는 PostgreSQL의 Heap이 기본적으로 8KB Page 단위로 저장된다고 살펴봤다.Page 안에는 여러 Tuple이 들어가지만, 하나의 Heap Tuple은 Page 경계를 넘어 저장될 수 없다. 그런데 PostgreSQL에서는 TEXT, JSONB, BYTEA 같은 컬럼에 하나의 Page보다 훨씬 큰 값을 저장할 수 있다.CREATE TABLE documents ( id bigint.. 2026. 9. 25.

PostgreSQL 내부구조 (7) ㅡ Scan과 Optimizer PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 6편에서는 PostgreSQL의 인덱스가 Key와 ctid를 저장하고, ctid를 통해 실제 Heap Tuple을 찾아가는 과정을 살펴봤다.하지만 인덱스가 존재한다고 해서 PostgreSQL이 항상 인덱스를 사용하는 것은 아니다.CREATE INDEX idx_users_age ON users(age);SELECT *FROM usersWHERE age >= 20;age에 인덱스가 있어도 실행 계획에서는 S.. 2026. 9. 25.

PostgreSQL 내부구조 (6) ㅡ Index PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 1편에서 본 ctid, 4편에서 본 Visibility Map. 이 둘이 인덱스에서 어떻게 쓰이는지 알아보자. 인덱스는 별도의 자료구조처럼 생각하지만, 실제로는 1편의 힙 페이지 구조 위에 얹혀 동작한다. 이 글에서 다루는 것:인덱스가 저장하는 것 — 키와 ctid, 그리고 저장하지 않는 것모든 인덱스가 보조 인덱스(secondary index)라는 의미인덱스 스캔의 비용 — 힙 random I/O인덱스.. 2026. 7. 18.

PostgreSQL 내부 구조 (5) — WAL과 Checkpoint, 장애 복구의 핵심 PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 1편에서 dirty 페이지를 디스크에 쓰기 전에 "WAL이 먼저 flush되어야 한다"고 언급했다. PostgreSQL이 어떻게 갑작스러운 크래시 후에도 일관된 상태를 복원하는지 알아본다. 이 글에서 다루는 것: Write-Ahead Logging 원칙LSN과 pd_lsn, full page writes (torn page 문제)Checkpoint (redo point · checkpoint_timeou.. 2026. 4. 18.

PostgreSQL 내부 구조 (4) — VACUUM, 옛 버전은 누가 치우는가 PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 2편(MVCC) 에서 본 것처럼 PostgreSQL은 옛 버전을 안 지운다. 시간이 지나면 어떤 트랜잭션도 더 이상 보지 않는 dead tuple이 쌓인다. 이걸 누가, 언제, 어떻게 치우는지 알아보자.이 글에서 다루는 것:dead tuple, table bloat, VACUUM의 두 가지 역할 (페이지 회수 / freeze),Visibility Map (all-visible · all-frozen), .. 2026. 4. 18.

PostgreSQL 내부 구조 (3) — Locking, 동시성의 또 다른 축 PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 2편에서 다룬 MVCC가 "읽기와 쓰기를 어떻게 분리하는가"라면, 락은 "동시 쓰기를 어떻게 조율하는가"다. 이 글에서 다루는 것:테이블 락 8단계와 호환성, 행 락 4종행 락의 여부의 저장 위치 (튜플 헤더)데드락, lock wait 디버깅 (pg_locks · pg_blocking_pids)타임아웃 설정 (statement_timeout · lock_timeout · idle_in_transactio.. 2026. 4. 18.

PostgreSQL 내부 구조 (2) — MVCC와 격리 수준 PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 1편에서 본 t_xmin, t_xmax가 어떻게 동시성 제어에 쓰이는지, 왜 PostgreSQL은 행을 덮어쓰지 않고 여러 버전을 남겨두는지 알아보자. 이 글에서 다루는 것:MVCC (INSERT · UPDATE · DELETE의 실제 동작)CLOG(Commit Log), hint bits이상현상 (dirty read · nonrepeatable read · phantom read · serializat.. 2026. 4. 18.

PostgreSQL 내부 구조 (1) — 페이지와 Shared Buffers PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 PostgreSQL의 모든 데이터가 저장되는 물리 구조를 알아보자. 이후 편에서 다룰 MVCC, VACUUM, 인덱스가 왜 그렇게 동작하는지는 이 구조를 알아야 이해된다. 이 글에서 다루는 것:8KB 페이지 레이아웃 (PageHeaderData, Line Pointer, 튜플 헤더 (xmin · xmax · ctid · t_infomask))Shared Buffers (Hash Table · Buffer.. 2026. 4. 18.

PostgreSQL 내부 구조 (0) — 연결과 프로세스 구조 PostgreSQL 내부 구조 시리즈시작. 시리즈를 시작하며0. 연결과 프로세스 구조1. 8KB 페이지와 Shared Buffers2. MVCC와 격리 수준3. Locking4. VACUUM5. WAL과 Checkpoint6. Index7. Scan과 Optimizer8. TOAST정리. 1~8편 총정리 쿼리가 실행되기까지 "클라이언트 → 서버" 사이에서 일어나는 과정과 PostgreSQL의 프로세스 모델과 데이터 흐름을 정리한다. PostgreSQL은 프로세스 기반이다PostgreSQL은 멀티스레드가 아니라 멀티프로세스 구조다. 클라이언트 연결 하나당 OS 프로세스 하나가 붙는다. 이 구조의 중심에 있는 것이 Postmaster다.Postmaster — 모든 프로세스의 부모PostgreSQL 서버를 .. 2026. 4. 18.

대용량 파일 멀티파트 업로드, 정말 빠를까? 대용량 파일 업로드에서 "멀티파트로 쪼개면 빨라진다." 라고 가볍게 생각했다. 7GB 파일을 5가지 방식으로 실측한 결과, 네트워크가 병목인 환경에서는 모든 방식의 전송 속도가 동일했다.이 글에서 전달하려는 메시지는 세 가지다.멀티파트 청킹의 목적은 속도가 아니라 안정성과 서버 리소스 효율이다. (멀티파트로 청킹한 데이터를 병렬 업로드, 병렬 조회를 하면 물론 속도는 빨라진다. 하지만 네트워크 대역폭에 제한을 받는다.)병렬 업로드는 단일 TCP가 대역폭을 못 채울 때만 의미 있다.파일 업로드 경로에서 가장 느린 구간이 전체 속도를 결정한다. 병목이 아닌 구간을 최적화해도 전체 속도는 변하지 않는다.대용량 파일 업로드 파이프라인파일이 클라이언트에서 스토리지까지 도달하는 전체 경로는 다음과 같다.이 파이프라.. 2026. 4. 17.

PostgreSQL 내부 구조 — 시리즈를 시작하며 PostgreSQL 18의 내부 동작 원리를 공식 문서와 실제 동작을 기준으로 정리한 시리즈다. SQL 문법이나 사용법보다는 PostgreSQL이 내부에서 Connection을 처리하고, 데이터를 저장하고, Transaction을 제어하고, 변경 내용을 복구하고, 필요한 데이터를 찾아 실행하는 과정을 중심으로 살펴본다. 각 편은 독립적인 주제를 다루지만, 앞에서 설명한 구조가 뒤에서 다시 등장한다. 예를 들어 1편에서 살펴본 Tuple Header의 xmin, xmax는 MVCC에서 다시 등장하고, ctid는 Index에서 사용된다. VACUUM의 Visibility Map은 이후 Index Only Scan과 연결되며, Shared Buffers의 Dirty Page는 WAL과 Checkpoint로 .. 2026. 4. 16.

이전 1 2 3 다음

티스토리툴바