475. OLTP (Online Transaction Processing)와 정규화

⚠️ 이 문서는 은행 결제 시스템이나 배달 앱의 주문 시스템처럼, **수만 명의 사용자가 동시에 접속하여 끊임없이 데이터를 읽고, 쓰고, 고치고, 지우는 극한의 '실시간 트랜잭션 처리 환경(OLTP)'**을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 현재 비즈니스가 굴러가기 위해 실시간으로 발생하는 '살아있는 데이터(운영 데이터)'를 가장 빠르고 안전하게 처리하는 시스템이다.
  2. 주요 작업: 복잡한 통계(집계) 쿼리보다는, INSERT, UPDATE, DELETE 같이 데이터를 짧고 빠르게 건드리는 쓰기(Write) 작업 위주로 돌아간다.
  3. 설계 철학: 갱신 이상(Update Anomaly - 404번 문서)을 막고 데이터의 무결성을 100% 보장해야 하므로, 테이블을 잘게 쪼개는 **'정규화(Normalization)'**가 필수적인 설계 원칙이다.

Ⅰ. 개요: 1초의 전쟁터 (Context & Necessity)

금요일 저녁 배달 앱 서버를 상상해 보자.

  • 1초에 1,000명의 고객이 치킨집 메뉴를 누른다. (SELECT)
  • 500명이 장바구니에 치킨을 담고 결제 버튼을 누른다. (INSERT)
  • 사장님이 주문을 수락해서 상태를 '배달 중'으로 바꾼다. (UPDATE)
  • 고객 변심으로 10명이 주문을 취소한다. (DELETE)

이런 시스템에서 가장 중요한 것은 무엇일까? 첫째, 데이터가 꼬이면 안 된다(ACID - 440번 문서). 둘째, 한 사람이 주문할 때 다른 사람이 무한정 대기하면 안 된다(고립성 - 443번 문서). 이렇게 **실시간으로 발생하는 자잘한 트랜잭션들을 0.01초 만에 쳐내기 위해 극한으로 최적화된 시스템을 'OLTP'**라고 부른다.

📢 섹션 요약 비유: OLTP는 눈코 뜰 새 없이 바쁜 **'맥도날드 주방'**과 같습니다. 햄버거 1개를 완벽하게 조립해서 10초 만에 손님에게 내어주는 빠르고 정확한 '실시간 트랜잭션(주문 처리)'이 이 시스템의 유일한 존재 이유입니다.

Ⅱ. OLTP의 핵심 설계 원칙: 정규화 ★

OLTP 시스템이 살아남기 위해 반드시 지켜야 할 철학이다.

1. 정규화 (Normalization)의 강제

  • 주문 테이블에 '고객의 주소'를 같이 적어놓았다고 치자 (비정규화 상태).
  • 고객이 이사를 가서 주소를 바꾸면? 그 고객이 주문한 100건의 옛날 주문 테이블 데이터를 다 찾아서 주소를 UPDATE 해야 한다. (Lock 대기 시간 폭발, 서버 뻗음)
  • 해결책: 고객 테이블과 주문 테이블을 철저하게 쪼갠다(제3정규형 - 398번 문서). 주소가 바뀌면 고객 테이블 딱 1줄만 업데이트하면 되므로, 0.001초 만에 작업이 끝나고 락(Lock)이 바로 풀린다.

2. 짧은 트랜잭션 (Short Transaction)

  • UPDATE를 칠 때는 디스크의 행(Row)에 자물쇠가 걸린다.
  • 트랜잭션이 길어지면 남들이 대기해야 하므로, OLTP에서는 트랜잭션을 최대한 잘게 썰어서 빨리 COMMIT을 때려야 한다.

Ⅲ. 실무 팁: 인덱스의 딜레마

OLTP 개발자들이 가장 많이 하는 실수다. "조회(SELECT)를 빨리하려고 인덱스를 10개나 만들었어요!"

  • 대참사: OLTP는 조회가 전부가 아니다. 쓰기(INSERT, UPDATE)가 엄청나게 많다.
  • 인덱스를 10개 만들어두면, 데이터 1건을 INSERT 할 때마다 10개의 인덱스 책갈피(B-Tree)도 전부 다 뜯어고쳐야 한다. (인덱스 유지 비용 폭발)
  • 결과: 조회는 빠른데, 결제(쓰기)를 누르면 로딩이 5초씩 걸리는 기형적인 쇼핑몰이 탄생한다.
  • 정답: OLTP 시스템의 테이블에는 정말 핵심적인 검색 조건에만 인덱스를 달고(보통 3~4개 이하), 무거운 집계 통계는 밤에 데이터를 퍼 날라서 OLAP(476번 문서) 시스템에서 따로 해야 한다.
┌──────────────────────────────────────────────────────────────┐
│           OLTP (온라인 트랜잭션 처리) 시스템의 특징과 병목 시각화         │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 👨‍💻 유저 수만 명 ] ─(동시다발적 짧은 요청)─▶ [ 🚀 OLTP 시스템 ]     │
│                                                              │
│  요청 1: SELECT (내 주문내역)       ──▶ (0.01초 처리)           │
│  요청 2: INSERT (신규 가입)         ──▶ (0.01초 처리)           │
│  요청 3: UPDATE (결제 완료)         ──▶ (0.01초 처리 + Lock)    │
│  요청 4: SELECT SUM(매출) FROM..  ──▶ 🚨 에러!! (서버 멈춤)       │
│                                                              │
│ ★ 특징: 무거운 쿼리 1방이 들어오면, 0.01초 만에 끝나야 할 수만 개의        │
│       가벼운 결제 트랜잭션들이 다 같이 멈춰버리는(병목) 유리몸 시스템이다.   │
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"OLTP는 돈을 벌고, OLAP는 돈을 아낀다." OLTP는 기업의 숨통이다. 여기서 장애가 나면 고객의 결제가 실패하고 당장 회사의 통장에 돈이 들어오지 않는다. 따라서 이 시스템의 설계자는 '복잡한 통계를 어떻게 뽑을 것인가'를 고민해서는 안 된다. 오직 "어떻게 테이블을 쪼개서(정규화) 잠금(Lock)의 범위를 최소화할 것인가?", "어떻게 트랜잭션을 짧게 가져가서 동시성(Concurrency)을 극대화할 것인가?"라는 데이터 무결성과 속도의 딜레마에만 모든 에너지를 쏟아부어야 한다.

📌 관련 개념 맵

  • 대척점 시스템: OLAP (온라인 분석 처리 - 476번 문서)
  • 필수 이론: ACID 4대 특성 (440번 문서)
  • 설계 원칙: 정규화 (Normalization - 395~404번 문서)
  • 핵심 언어: DML (INSERT, UPDATE, DELETE)

👶 어린이를 위한 3줄 비유 설명

  1. OLTP는 김밥집 주방이에요. 손님들이 "참치김밥 하나요!", "치즈김밥 취소요!"라고 외치면 10초 만에 척척 만들어서 내어주는 곳이죠.
  2. 손님이 엄청 많으니까, 김밥 마는 사람, 썰어주는 사람을 나눠서(테이블 정규화) 꼬이지 않게 빠르게 일하는 게 제일 중요해요.
  3. 근데 여기서 사장님이 "올해 제일 많이 팔린 김밥 10년 치 통계 좀 내봐!"라고 무거운 숙제를 시키면, 주방이 멈춰서 김밥을 하나도 못 팔게 된답니다!