Atomicity란? 여러 Thread가 동시에 실행해도 연산이 중간에 끊기지 않게 하는 원리 쉽게 이해하기
Atomicity는 연산이 중간 상태 없이 하나의 단위처럼 수행되는 성질입니다. count++ Lost Update·Lock·CAS·Database Transaction·Saga까지 초보 기준으로 정리합니다.
`count = count + 1`은 한 줄이지만 개념적으로는 읽기 → 1 더하기 → 저장(Read-Modify-Write)입니다. Thread A·B가 동시에 `10`을 읽고 둘 다 `11`을 쓰면 기대는 `12`인데 결과는 `11`이 될 수 있습니다. 증가 한 번이 사라지는 Lost Update입니다. 이를 막으려면 연산이 중간에 끼어들 수 없는 하나의 단위처럼 보여야 합니다. 이것이 Atomicity(원자성)입니다. 은행 이체에서 출금만 되고 입금이 안 된 채 확정되면 안 되는 것과 같고, Database Transaction의 ACID에서 A도 같은 「전부 성공 또는 전부 실패」 직관입니다. CPU·Thread Atomic과 DB Transaction Atomicity는 아이디어는 비슷하지만 계층이 다릅니다. Atomic하지 않은 Shared 수정은 대표적인 Race Condition 원인이 될 수 있습니다.
count=10 A·B 둘 다 10 읽음 → 둘 다 11 저장 → 실제 11 (기대 12) Atomic increment → 10→11, 11→12
Ordering과 구분 · Lock · Check-Then-Act
Memory Consistency의 Ordering·Visibility와 Atomicity는 다릅니다. Atomic Flag로 `ready`만 안전하게 바꿔도 `data` Visibility는 Ordering 규칙(Acquire/Release)에 달릴 수 있습니다. Atomic Counter는 작은 증가에 적합하고, 잔액·재고·주문처럼 여러 상태를 함께 바꾸려면 Lock Critical Section이나 Transaction이 필요합니다. `atomic_x++`와 `atomic_y++` 각각은 Atomic이어도 묶음 전체가 Atomic은 아닙니다. `if (stock > 0) stock--`처럼 확인 후 행동 사이에 끼어들면 Check-Then-Act Race입니다. DB에서도 SELECT 후 별도 UPDATE보다 `stock > 0`일 때만 감소하는 Atomic Update·Transaction이 안전합니다. Isolation은 「다른 Transaction이 중간 상태를 보는가」로 Atomicity와 다릅니다.
CAS · Contention · 분산 Saga
CAS(Compare-And-Swap)는 예상값과 같을 때만 새 값으로 바꾸는 Atomic Operation입니다. 실패하면 다시 읽고 재시도하는 CAS Loop로 Counter를 구현할 수 있습니다. Contention이 심하면 Retry Storm·Cache Coherence Traffic이 늘고 Atomic이 항상 Lock보다 빠르지 않습니다. Backoff·Jitter로 재충돌을 줄일 수 있습니다. Lock-Free는 「누군가 계속 진행」, Wait-Free는 「각 Thread가 유한 단계 내 완료」에 가깝고 직접 구현은 어렵습니다. Atomicity만으로 Deadlock·Starvation·Ordering이 사라지지 않습니다. 주문·결제·재고가 서비스별로 나뉘면 단일 DB Transaction이 어렵고 2PC 같은 Distributed Transaction은 비용이 큽니다. Saga는 Local Transaction + 보상으로 현실적 Business Consistency를 만듭니다. Idempotency(같은 요청 재시도)와 Durability(Commit 유지)는 Atomicity와 다른 축입니다. Atomic File Write·배포 Symlink 전환도 「중간 깨진 상태」를 줄이는 같은 질문입니다. Redis INCR·DB `UPDATE count = count + 1`은 애플리케이션 GET+SET 분리보다 안전할 수 있습니다. Transaction은 짧게, 외부 API를 길게 잡지 않습니다. Contention·Bulkhead로 Shared Hotspot을 줄이는 설계도 같이 봅니다. SEO 전용 개념은 아닙니다.
계층별 수단 CPU/Thread → Atomic / CAS App → Lock DB → Transaction 여러 서비스 → 2PC / Saga
자주 묻는 질문
Atomicity란?
연산이나 작업 묶음이 중간 상태 없이 하나의 단위로 수행된 것처럼 보이도록 보장하는 성질입니다.
한 줄이면 Atomic한가?
아닙니다. `count++`도 Read-Modify-Write로 나뉠 수 있습니다.
Atomic과 Lock 차이는?
Atomic은 작은 Operation에, Lock은 더 큰 Critical Section 보호에 적합합니다.
Atomic 여러 개면 전체도 Atomic한가?
아닙니다. 각 연산만 Atomic이고 그 사이에 다른 Thread가 끼어들 수 있습니다.
Atomicity와 Isolation?
Atomicity는 All or Nothing, Isolation은 동시 Transaction이 중간 상태를 어떻게 보는지입니다.
CAS란?
예상값과 같을 때만 새 값으로 교체하는 Atomic Operation입니다. 실패 시 재시도할 수 있습니다.
정리
Atomicity = 중간 상태가 다른 작업과 섞이지 않는 하나의 단위처럼 보이게 하는 성질입니다. Read-Modify-Write·Check-Then-Act를 확인하고, 작은 단위는 Atomic/CAS, 여러 상태는 Lock·Transaction, 분산은 2PC/Saga로 범위를 맞춥니다. 핵심 질문은 「중간 상태가 보이면 안 되는가?」입니다. 그런데 CAS로 Atomic 수정을 할 때 Thread A가 `10`을 읽은 사이 B가 `10→20→10`으로 바꿨다면, A는 다시 `10`을 보고 「변경이 없었다」고 잘못 판단할 수 있습니다. 이처럼 값이 A에서 다른 값으로 바뀌었다가 다시 A로 돌아와 CAS가 중간 변경을 놓칠 수 있는 문제를 ABA Problem(ABA 문제)이라고 합니다.