순환 대기 (Circular Wait)

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

본질: 순환 대기 (Circular Wait)는 교착 상태(Deadlock)를 완성하는 4대 필요조건의 마지막 퍼즐로, 여러 프로세스가 자원을 요청하고 대기하는 관계가 꼬리를 무는 원형(Cycle) 사슬 구조를 이룰 때 발생하는 치명적 현상이다.

가치: 점유 대기나 비선점 같은 다른 조건들은 실무에서 성능이나 무결성 때문에 깨기가 매우 어렵지만, 순환 대기 조건만큼은 **개발자의 코딩 컨벤션(락 획득 순서 강제화)**만으로도 오버헤드 없이 데드락을 100% 원천 차단할 수 있는 가장 현실적인 타깃이다.

융합: 운영체제나 데이터베이스는 자원 할당 그래프(Resource Allocation Graph)나 대기-그래프(Wait-For Graph)를 그려 사이클(Cycle)의 유무를 탐지하는 알고리즘을 내부적으로 가동하여 데드락을 사후에 감지하고 치료한다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 프로세스의 집합 ${P_0, P_1, \dots, P_n}$이 있을 때, $P_0$은 $P_1$이 점유한 자원을 대기하고, $P_1$은 $P_2$가 점유한 자원을 대기하며, 마지막으로 $P_n$이 다시 $P_0$이 점유한 자원을 대기하는, 시작과 끝이 맞물린 닫힌 루프(Closed Loop) 상태다.
필요성: 만약 A가 B를 기다리고, B가 C를 기다리기만 한다면(일직선 대기), C가 작업을 끝내면 B도 끝나고 A도 끝날 수 있다. 즉, 무한 대기가 아니다. 영원히 끝나지 않는 무한 파업 상태가 성립하려면 논리적으로 "서로가 서로의 발목을 잡는 뫼비우스의 띠"가 만들어져야 한다. 이를 수학적으로 정의한 것이 순환 대기다.
💡 비유: 4대의 자동차가 좁은 사거리 교차로에 동시에 진입했습니다. 앞차가 빠져야 내가 직진할 수 있는데, 내 앞차의 앞차의 앞차가 다시 내 차의 옆구리를 막고 있어서 4대 모두 영원히 빵빵거리기만 하는 상황과 완벽히 일치합니다.
등장 배경: 시스템 자원이 복잡하게 얽히기 시작하면서, 데드락이 발생하는 조건에 대한 수학적 그래프 이론이 도입되었다. 자원과 프로세스를 노드(Node)로, 요청과 할당을 간선(Edge)으로 그렸을 때, "사이클(Cycle)이 없다면 데드락은 절대 발생하지 않는다"는 위대한 증명이 탄생하며 순환 대기가 데드락의 핵심 조건으로 격상되었다.

  [자원 할당 그래프(RAG)를 통한 순환 대기(Circular Wait)의 시각화]

  (1) 일직선 대기 (데드락 아님, 언젠간 풀림)
  [ P1 ] ──(요청)──▶ [ 자원 A ] ◀──(할당됨)── [ P2 ] ──(요청)──▶ [ 자원 B ] ◀──(할당됨)── [ P3 ]
  ▶ P3가 B를 다 쓰고 나가면, P2가 B를 먹고, P2가 나가면 P1이 A를 먹음. 시스템 정상!

  (2) 순환 대기 (데드락 폭발, 영원히 멈춤)
  ┌────────────────────────────────────────────────────────┐
  │                                                        │
  ▼                                                        │
  [ P1 ] ──(요청)──▶ [ 자원 A ] ◀──(할당됨)── [ P2 ]       │
  │                                            │           │
  └─(할당됨)── [ 자원 B ] ◀──(요청)─────────────┘          │
  │                                                        │
  └────────────────────────────────────────────────────────┘

[다이어그램 해설] 아래 그림이 바로 전산학에서 말하는 '죽음의 링(Ring of Death)'이다. 화살표를 따라가 보면 $P_1 \to A \to P_2 \to B \to P_1$ 으로 완벽하게 닫힌 동그라미(사이클)가 완성된다. 이 사이클이 완성되는 순간, 외부의 신(OS)이 강제로 누군가를 죽이지(Kill) 않는 이상 이 고리는 영원히 풀리지 않는다.

📢 섹션 요약 비유: 회사에서 기획팀은 디자인팀의 시안을 기다리고, 디자인팀은 개발팀의 구조를 기다리고, 개발팀은 다시 기획팀의 기획안을 기다립니다. 3팀 모두 "저 팀이 주면 할게요"라며 영원히 월급만 축내는 환장할 핑퐁 게임이 바로 순환 대기입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

순환 대기 파괴의 원리: 자원 계층화 (Lock Ordering / Hierarchy)

데드락의 4가지 조건 중 상호 배제는 데이터 보호를 위해 건드릴 수 없고, 비선점과 점유 대기를 깨려면 타임아웃이나 롤백 같은 성능 저하 꼼수가 필요하다. 하지만 순환 대기만큼은 "코딩 컨벤션(법칙)" 하나만으로 성능 저하 0%로 완벽하게 부술 수 있다.

자원 할당 순서(Lock Ordering) 강제화

시스템 내의 모든 자원(Mutex, DB 테이블 등)에 **고유한 순서 번호(Index)**나 등급을 매긴다. (예: $R_1=1, R_2=2, R_3=3$).
프로세스가 자원을 요청할 때는 반드시 번호가 오름차순(작은 번호 ─▶ 큰 번호)으로만 요청해야 한다는 법을 만든다.
내 손에 2번 락을 쥐고 있다면, 1번 락은 절대 요청할 수 없다. 1번 락이 꼭 필요하면 내가 쥔 2번 락을 버리고, 빈손으로 돌아가 1번부터 다시 잡고 와야 한다.

  ┌────────────────────────────────────────────────────────────────────────┐
  │         자원 계층화(Lock Ordering)에 의한 사이클 형성 원천 차단 증명   │
  ├────────────────────────────────────────────────────────────────────────┤
  │                                                                        │
  │   [ ❌ 데드락이 발생하는 기존 코드 ]                                   │
  │   스레드 A: lock(R1) ─▶ lock(R2)                                       │
  │   스레드 B: lock(R2) ─▶ lock(R1)  (서로 엇갈리게 잡아서 사이클 완성)   │
  │                                                                        │
  │   [ ✅ 자원 계층화를 강제한 안전한 코드 ]                              │
  │   (시스템 법률: 무조건 번호가 작은 것부터 잡아라!)                     │
  │                                                                        │
  │   스레드 A: lock(R1) ─▶ lock(R2)  (합법)                               │
  │   스레드 B: lock(R1) ─▶ lock(R2)  (합법으로 교정됨!)                   │
  │                                                                        │
  │   ▶ 결과 분석: 스레드 B가 R1을 잡으려 할 때, 스레드 A가 이미 R1을      │
  │     쥐고 있으므로 B는 진입조차 못 하고 대기한다. 스레드 A는 R2마저     │
  │     여유롭게 쥐고 연산을 끝낸다. '순환' 자체가 물리학적으로 성립 불가. │
  └────────────────────────────────────────────────────────────────────────┘

[수학적 증명] 사이클이 만들어지려면 $P_1$은 작은 번호를 쥐고 큰 번호를 원하고, $P_n$은 큰 번호를 쥐고 작은 번호를 원해야 꼬리가 물린다. 하지만 모두가 오름차순으로만 요구하면, 가장 큰 번호 자원을 쥔 녀석은 더 큰 자원만 요구할 수 있으므로 절대 자기가 왔던 뒤쪽(작은 번호)을 향해 화살표를 쏠 수 없다. 화살표가 무조건 한 방향으로만 흐르므로 수학적으로 원형 궤도(Cycle)는 100% 생길 수 없다.

📢 섹션 요약 비유: 교차로 꼬리물기(데드락)를 막는 가장 완벽한 방법은, 길 한가운데에 중앙분리대를 쳐서 무조건 차들이 시계 방향(한 방향)으로만 돌게(회전교차로) 강제하는 것입니다. 직진이나 유턴(역방향 락 획득)을 법으로 금지하면 막히긴 해도 영원히 멈추는 데드락은 터지지 않습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

점유 대기(Hold & Wait) vs 순환 대기(Circular Wait) 타파 전술 비교

두 전략 모두 데드락을 예방하는 훌륭한 수단이지만, 실무에서 체감하는 난이도가 다르다.

비교 항목	점유 대기 타파 (`tryLock` / All-or-nothing)	순환 대기 타파 (Lock Ordering / Hierarchy)
설계 철학	"남의 걸 못 잡으면 내 것도 쿨하게 버린다"	"애초에 꼬이지 않게 순서대로만 잡는다"
장점	구조가 유연함. 순서를 신경 안 써도 됨.	성능 저하가 0%, 타임아웃 대기 지연조차 없음.
단점 (오버헤드)	내가 잡았던 락을 풀고 롤백(Rollback)하는 로직을 짜야 함	동적으로 자원이 계속 추가되는 환경에선 락 번호를 미리 매기기가 매우 어려움
실무 적용	분산 환경, MSA(Saga), 타임아웃 튜닝	커널 내부 락, 단일 프로그램 내부의 Multi-mutex 환경

다중 인스턴스 자원(Multi-instance)에서의 사이클의 배신

순환 대기(사이클)가 데드락의 필요충분조건이 되는 것은 **'자원의 개수가 1개(Single Instance)'**일 때뿐이다. 만약 프린터(자원 A)가 3대 있는 다중 인스턴스 환경이라면, 사이클이 존재해도 데드락이 아닐 수 있다. 화살표가 꼬리를 물고 있어도, 3대 중 하나를 쓰고 있는 제3의 녀석(사이클 밖에 있는 놈)이 볼일을 다 보고 1대를 툭 뱉어주면, 그 순간 사이클의 한 축이 자원을 획득하며 꽉 막힌 링이 스르륵 풀려버리기 때문이다. 따라서 자원이 여러 개일 때는 단순한 사이클 검사가 아닌 복잡한 은행원 알고리즘(Banker's Algorithm) 계열의 시뮬레이션이 필요하다.

📢 섹션 요약 비유: 의자 뺏기 게임에서 의자가 1개(Single Instance)일 때 두 명이 동시에 앉으려 하면 완벽한 교착 상태입니다(사이클 = 데드락). 하지만 의자가 10개(Multi-Instance)인데 두 명이 하나의 의자에만 앉겠다고 싸우고 있어도(사이클), 옆에서 놀던 친구가 자기 의자를 하나 양보해 주면 싸움이 풀립니다. 자원이 많으면 숨구멍이 트입니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

자바(Java) 백엔드에서의 계좌 이체(Transfer) 락 오더링: 개발자가 A계좌에서 B계좌로 돈을 보내는 코드를 짰다.
- 위기: transfer(A, B) 와 transfer(B, A) 가 동시에 호출되면 100% 데드락(순환 대기)이 터진다.
- 실무 해결책: 파라미터로 들어온 A와 B의 계좌 번호(Account ID)를 무조건 비교한다.
```
Account first = A.id < B.id ? A : B;
Account second = A.id < B.id ? B : A;
synchronized(first) {
    synchronized(second) {
        // 이체 로직 실행 (A->B든 B->A든 무조건 ID가 작은 놈부터 락을 잡음!)
    }
}
```
  이 간단한 3줄의 코드가 바로 **자원 계층화(Lock Ordering)**를 애플리케이션 레벨에서 구현한 완벽한 튜닝이다.
Oracle / MySQL 데이터베이스의 데드락 그래프 탐지: RDBMS 엔진 내부에는 스레드들이 어떤 테이블/행(Row)의 락을 잡고 기다리는지를 실시간으로 추적하는 Wait-for Graph 구조체가 메모리에 떠 있다.
- 아키텍트 조치: DB 데몬은 1초에 한 번씩 그래프 알고리즘(DFS/BFS의 Cycle Detection)을 돌려 트리에 '순환 대기(Cycle)'가 형성되었는지 찾아낸다. 사이클이 발견되는 순간 즉각적으로 Undo 로그가 적은 만만한 트랜잭션 하나를 KILL 하여 강제로 연결 고리를 끊어(순환 대기 파괴) 시스템을 구출한다.

  ┌──────────────────────────────────────────────────────────────────────┐
  │     백엔드 아키텍트의 데드락(순환 대기) 방지 설계 가이드라인         │
  ├──────────────────────────────────────────────────────────────────────┤
  │                                                                      │
  │   [ 1단계: 설계 시점 - Share Nothing 구조 지향 ]                     │
  │     - 스레드 간 락을 공유하지 않게 Thread-Local 변수나,              │
  │       메시지 큐(Actor 모델)를 써서 원천적으로 락 획득을 금지함.      │
  │                                                                      │
  │   [ 2단계: 코딩 시점 - Lock Ordering 강제 ]                          │
  │     - 락을 여러 개 잡아야 한다면, 무조건 HashCode나 ID를 비교해      │
  │       오름차순/내림차순으로만 잡도록 코드 리뷰(PR) 시 칼같이 검증함. │
  │                                                                      │
  │   [ 3단계: 런타임 시점 - 타임아웃(TryLock) 적용 ]                    │
  │     - 아무리 락 오더링을 잘해도 써드파티 라이브러리에서 꼬일 수 있음.│
  │     - 모든 락 획득에는 무조건 최대 3초의 타임아웃을 걸어, 사이클이   │
  │       형성되더라도 3초 뒤에 한 놈이 자폭하여 고리를 끊게 만듦.       │
  └──────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "OS가 데드락을 안 잡아주니 개발자가 잡아야 한다." 실무에서 가장 빈번하게 터지는 이 순환 대기의 악몽을 막기 위해, 시니어 아키텍트는 설계-코딩-런타임이라는 3중 방어막을 친다. 특히 ID 순으로 락을 잡는 기법은 거의 모든 C++/Java 동시성 프레임워크 내부에 숨겨진 마법의 공식이다.

📢 섹션 요약 비유: 순환 대기는 마치 여러 사람이 손을 잡고 원을 만드는 '강강술래'와 같습니다. 원이 완성되면 영원히 빙빙 돌게 됩니다. 이를 막기 위해 "왼손잡이와는 절대 손을 잡지 마라(Lock Ordering)"라고 교육하거나, "5분 돌았으면 무조건 손을 놔라(타임아웃)"라고 룰을 세우는 것이 실무적 아키텍처입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

순환 대기 방지(Lock Ordering) 규칙을 전사적 코딩 컨벤션으로 강제하면, 락(Lock)을 획득하고 반환하는 과정에서 성능 오버헤드를 1%도 추가하지 않으면서 데드락(Deadlock) 발생 확률을 수학적으로 0%로 떨어뜨릴 수 있는 가성비 최강의 안전성을 확보할 수 있다.

결론 및 미래 전망

순환 대기는 인간이 락(Lock)을 중첩해서 쓰려는 얄팍한 구조적 욕심에서 비롯된 버그다. 에드워드 코프만이 이를 데드락의 4조건으로 밝혀낸 이후, 반세기 동안 수많은 락 계층화(Lock Hierarchy) 방법론이 연구되었다. 미래의 최신 언어(Rust 등)들은 이 끔찍한 순환 대기 책임을 프로그래머의 머리에 맡겨두지 않는다. 컴파일러가 소스 코드를 분석하여 "너 지금 락 잡는 순서 엇갈렸어. 데드락 날 거니까 빌드 안 해줘!"라고 강제로 컴파일 에러를 뿜어내는 정적 분석(Static Analysis)의 시대로 접어들었다. 나아가, 아예 데이터 자체를 불변(Immutable)으로 만들어 여러 스레드가 동시에 쳐다봐도 락을 잡을 필요가 없는 함수형 패러다임이 순환 대기라는 단어 자체를 교과서 속 유물로 만들어가고 있다.

📢 섹션 요약 비유: 옛날엔 폭탄(데드락)의 파란 선과 빨간 선(락 순서)을 사람이 땀을 뻘뻘 흘리며 눈치껏 잘랐다면, 이제는 가위를 대는 순간 로봇(컴파일러)이 "선이 꼬였습니다!" 하고 알려주거나, 아예 터지지 않는 투명 폭탄(불변 데이터)으로 대체되는 눈부신 기술 발전을 이루고 있습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
교착 상태 (Deadlock)	순환 대기라는 뱀(Ouroboros)이 자기 꼬리를 무는 순간 완성되는 최후의 비극적 현상이다.
점유 대기 (Hold and Wait)	내 것을 쥐고 남의 것을 탐하는 행위. 이 행위가 연쇄적으로 이어져 원을 그리면 순환 대기로 진화한다.
비선점 (No Preemption)	누군가 억지로 락을 뺏을 수 있다면 순환 고리는 바로 깨지겠지만, 비선점 때문에 링이 단단하게 유지된다.
자원 할당 그래프 (RAG)	운영체제가 시스템 내부의 락 현황을 그림으로 그려서, "원(Cycle)이 생겼나?" 찾아내기 위해 돌리는 탐지 알고리즘이다.
락 계층화 (Lock Ordering)	순환 대기를 부수기 위해, 무조건 정해진 오름차순으로만 락을 집어 들게 강제하는 백엔드 코딩의 십계명이다.

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

4명의 아이가 소꿉놀이를 하는데, A는 칼을 쥐고 도마를 원하고, B는 도마를 쥐고 냄비를 원하고, C는 냄비를 쥐고 칼을 원해요.
이렇게 원하는 게 꼬리에 꼬리를 물고 원형(동그라미)으로 꽉 막혀버려서 아무도 요리를 시작하지 못하는 상황을 **순환 대기(Circular Wait)**라고 해요.
선생님이 "앞으로는 무조건 번호가 적힌 순서대로(칼 -> 도마 -> 냄비) 장난감을 집어!"라고 규칙을 세우면, 꼬이는 일(동그라미)이 영원히 사라져서 데드락이 터지지 않아요!