서론: 반복문이 배치 시스템이 되는 순간 DB에서 데이터를 읽어 반복문으로 처리하는 코드는 쉽게 만들 수 있다. 하지만 수백만 건 중 70%에서 실패하면 어디서 다시 시작할지, 같은 작업을 두 번 실행해도 안전한지, 처리 진행률을 어떻게 알지까지 요구되면 단순 반복문으로는 부족하다. Spring Batch는 이 운영 문제를 Job·Step·Chunk...

서론: 백업 파일이 아니라 복구 시간을 약속하라 운영 데이터베이스의 목표는 단순히 살아 있는 것이 아니다. 부하 급증에도 연결을 통제하고, 장애 때 정해진 데이터 손실과 시간 안에 서비스를 복구해야 한다. 백업 성공 로그만 있고 복원 훈련이 없다면 그 약속은 검증되지 않았다. 1. 연결 수는 한정된 자원이다 각 연결은 메모리와 백엔드 프로세스 자...

서론: 지운 행이 바로 사라지지 않는 이유 MVCC에서 UPDATE와 DELETE가 만든 이전 행 버전은 다른 트랜잭션이 볼 수 있어 즉시 제거할 수 없다. 더 이상 어떤 스냅샷에도 필요하지 않을 때 VACUUM이 공간을 재사용 가능하게 만들고 트랜잭션 ID 고갈을 막는다. VACUUM은 선택적 청소가 아니라 PostgreSQL 정상 동작의 일부다....

서론: 스키마는 가장 오래 사는 API다 애플리케이션 코드는 자주 바뀌지만 데이터는 여러 버전의 코드와 분석·배치·운영 도구가 함께 읽는다. 느슨한 스키마는 처음엔 빠르지만 잘못된 값이 쌓인 뒤 모든 쿼리와 마이그레이션의 비용으로 돌아온다. 1. 의미에 맞는 타입을 고르기 시간: 절대 시점은 timestamptz, 지역 일정은 별도 timez...

서론: 인덱스를 추가하기 전에 계획을 읽자 느린 쿼리를 보면 조건 컬럼마다 인덱스를 만드는 경우가 많다. 하지만 Planner는 데이터 분포·통계·예상 비용을 바탕으로 순차 스캔, 인덱스 스캔, 조인 순서를 고른다. 인덱스가 있어도 많은 행을 읽어야 하면 순차 스캔이 더 빠를 수 있다. 1. EXPLAIN과 EXPLAIN ANALYZE EXPLA...

서론: 읽기와 쓰기가 서로를 보는 방식 PostgreSQL 성능과 장애를 이해하려면 MVCC(Multi-Version Concurrency Control)에서 시작해야 한다. 행을 수정할 때 기존 값을 즉시 덮어쓰는 대신 여러 버전을 만들고, 각 트랜잭션이 자신의 스냅샷에 보이는 버전을 읽는다. 이 덕분에 읽기와 쓰기의 충돌이 줄지만 오래된 행 버전...

서론: 보안은 로그인 기능으로 끝나지 않는다 Day 1~4에서 인증 상태와 권한 경계를 만들었다. 하지만 브라우저가 자격 증명을 자동 전송하는 특성, 다른 출처의 스크립트, 잘못 노출된 관리 엔드포인트가 이 경계를 우회할 수 있다. 마지막 날은 보안 설정을 공격 방어와 운영 절차까지 확장한다. 1. CSRF는 자동 전송되는 자격 증명을 노린다 사...

서론: 로그인했다고 모든 데이터가 내 것은 아니다 인증은 사용자의 신원을 확인하고, 인가는 그 사용자가 특정 행동을 해도 되는지 판단한다. 관리자 URL을 막는 것만으로는 부족하다. 일반 사용자도 다른 사용자의 주문 ID를 추측해 조회할 수 있다면 객체 수준 인가가 깨진다. 1. URL 규칙은 첫 번째 문이다 http.authorizeHttpRe...

서론: OAuth는 로그인 프로토콜이 아니다 OAuth 2.0의 핵심은 사용자가 비밀번호를 제3자 앱에 주지 않고 특정 자원 접근을 위임하는 것이다. “이 사용자가 누구인가”를 표준화한 계층은 OpenID Connect(OIDC)다. 둘을 구분해야 Access Token을 사용자 프로필처럼 오용하거나 ID Token으로 API를 호출하는 실수를 피할...

서론: JWT가 세션의 상위 호환은 아니다 세션은 서버에 상태를 두고, JWT는 서명된 토큰에 일부 상태를 담는다. 둘 다 인증 결과를 다음 요청에 연결하는 방법이며, 시스템 구조와 폐기 요구에 따라 장단점이 달라진다. “마이크로서비스니까 JWT” 같은 한 문장으로 결정하면 로그아웃·권한 변경·키 유출 시점에 비용을 치른다. 1. 세션 인증의 흐름...