세마포어 P, V 연산

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

본질: 세마포어(Semaphore)는 네덜란드의 천재 에츠허르 다익스트라(Edsger Dijkstra)가 발명한 동기화 기법으로, 임계 구역에 들어갈 수 있는 '사용 가능한 자원의 개수'를 나타내는 정수형 변수(Integer)와 이를 원자적으로 조작하는 두 개의 연산(P, V)으로 이루어진 신호등 체계다.

메커니즘: 스레드는 자원을 쓸 때 **P 연산(Wait)**을 호출하여 세마포어 값을 1 감소시키고(0이면 잠듦), 자원을 다 쓰고 반납할 때 **V 연산(Signal)**을 호출하여 값을 1 증가시키고 잠든 스레드를 깨운다. 이 P와 V는 반드시 OS가 보장하는 원자적(Atomic) 연산이어야 한다.

소유권의 부재: 뮤텍스와 가장 큰 차이점은 "세마포어는 소유권(Ownership)이 없다"는 것이다. 즉, P 연산을 한 스레드가 아닌 제3의 스레드가 V 연산을 호출해 락을 풀어버릴 수 있으며, 이 특성 때문에 단순한 락(Lock)을 넘어 스레드 간의 실행 순서(Ordering)를 제어하는 강력한 도구로 쓰인다.

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

개념:
- 세마포어 (Semaphore): 기차역의 '신호기(수신호)'에서 유래한 단어. 자원의 개수를 세는 카운터와 대기 큐로 이루어진 추상 자료형(ADT).
- P 연산 (Proberen, Wait / Acquire): 네덜란드어로 '검사하다'. 자원을 획득하는 행위 ($S = S - 1$).
- V 연산 (Verhogen, Signal / Release): 네덜란드어로 '증가하다'. 자원을 반납하는 행위 ($S = S + 1$).
필요성 (다중 자원의 한계 극복):
- 화장실 칸이 1개일 때는 뮤텍스(Mutex)나 스핀락 하나면 충분했다.
- 하지만 식당 주차장에 자리가 5개 있다면? 뮤텍스 5개를 만들어서 1번부터 5번까지 차례대로 돌려가며 lock()을 획득하게 짜려면 코드가 너무 길어지고 데드락이 발생하기 십상이다.
- 해결책: "자물쇠(Lock) 대신 카운터(Counter)를 만들자. 빈자리가 5개면 5부터 시작해서, 차가 들어올 때마다(P 연산) 1씩 빼고, 나갈 때마다(V 연산) 1씩 더하자. 만약 카운터가 0이면 새로 온 차는 게이트 앞에서 무조건 자게(Sleep) 만들자!"
💡 비유:
- 뮤텍스: 1인용 공중화장실의 문고리 (1명만 들어감, 들어간 사람이 열고 나옴).
- 세마포어: 주차장 차단기와 빈자리 전광판.
  - 현재 전광판 숫자(S) = 5.
  - 차가 들어온다 (P 연산): 전광판 숫자가 4로 줄고 차단기가 열린다.
  - 차가 계속 들어와 전광판이 0이 되었다.
  - 또 다른 차가 들어온다 (P 연산): 숫자가 0이므로 차단기는 안 열리고, 이 차는 차단기 앞에서 엔진을 끄고 잔다(Block).
  - 주차장 안에서 차 한 대가 밖으로 나간다 (V 연산): 숫자를 1로 늘리면서, 동시에 차단기 앞에서 자고 있던 차에게 클락션을 울려 깨워준다(Wake-up).
발전 과정:
1. 바쁜 대기 세마포어 (초기): 카운터가 0일 때 while(S <= 0)을 돌며 CPU를 낭비하는 무식한 형태.
2. 슬립-웨이트 세마포어 (Block & Wakeup): 카운터가 음수(-1)로 내려가면 스레드를 큐(Queue)에 넣고 재우는 방식. (현대 OS의 표준)
📢 섹션 요약 비유: 세마포어는 클럽 입구의 기도(Bouncer)가 들고 있는 '입장 카운터기'입니다. 안에 사람이 꽉 차면(0) 못 들어가게 막고, 한 명이 나오면 밖에서 기다리던 첫 번째 사람을 정확히 들여보내는 완벽한 입장 통제 시스템입니다.

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

세마포어의 내부 자료구조와 P/V 연산의 C 코드

세마포어의 핵심은 단순히 정수 $S$가 아니라, $S$를 감싸고 있는 **원자적 함수(P, V)**와 **대기 큐(Wait Queue)**다.

typedef struct {
    int value;               // 사용 가능한 자원의 수
    struct process *list;    // 자원을 기다리며 잠든 프로세스들의 큐 (Wait Queue)
} semaphore;

// P 연산 (Wait, Acquire) - 원자적으로 실행됨
void wait(semaphore *S) {
    S->value--;              // 일단 자원 1개를 가져감 (차감)
    if (S->value < 0) {      // 0보다 작다? = 자원이 모자란데 내가 억지로 뺀 거다!
        // 이 프로세스를 S->list 큐에 넣음
        sleep();             // CPU를 놓고 딥슬립에 빠짐 (Block)
    }
}

// V 연산 (Signal, Release) - 원자적으로 실행됨
void signal(semaphore *S) {
    S->value++;              // 자원을 다 쓰고 반납함
    if (S->value <= 0) {     // 0 이하라면? = 누군가 음수(-1)를 만들어놓고 큐에서 자고 있다는 뜻!
        // S->list 큐에서 프로세스 P를 하나 꺼냄
        wakeup(P);           // P를 깨워서 Ready Queue로 보냄
    }
}

[다이어그램/코드 해설] 초보자들이 가장 헷갈려하는 부분이 S->value가 음수일 때의 의미다. 초기값이 1인 세마포어에서:

A가 진입 (P 연산): value는 0. (A는 통과)
B가 진입 (P 연산): value는 -1. (B는 수면)
C가 진입 (P 연산): value는 -2. (C는 수면) 여기서 **음수의 절댓값(2)은 "현재 세마포어를 기다리며 자고 있는 스레드의 개수(B, C)"**를 의미한다. 수학적으로 너무나 우아하고 완벽한 상태 관리다.

세마포어의 2가지 종류

이진 세마포어 (Binary Semaphore):
- $S$의 값이 0과 1만 가질 수 있다.
- 뮤텍스(Mutex)와 거의 동일하게 임계 구역 상호 배제 용도로 쓰인다. (단, 소유권이 없다는 점만 다름)
카운팅 세마포어 (Counting Semaphore):
- $S$의 값이 0 이상의 모든 정수를 가질 수 있다.
- 예: DB 커넥션 풀(Pool)이 10개라면, 초깃값 $S=10$으로 세팅하고 쓴다.

Ⅲ. 융합 비교 및 다각도 분석

Mutex vs Binary Semaphore의 결정적 차이 (소유권)

이 둘은 0과 1을 쓴다는 점에서 같아 보이지만, 철학이 완전히 다르다.

비교 항목	Mutex (뮤텍스)	Binary Semaphore (이진 세마포어)
소유권 (Ownership)	있음 (Lock을 건 스레드만 Unlock 가능)	없음 (A 스레드가 P를 하고, B 스레드가 V를 할 수 있음)
목적	자원의 독점 (상호 배제)	자원 독점 + 스레드 간 실행 순서 맞추기 (Ordering)
Priority Inversion 방어	OS가 `우선순위 상속`으로 데드락 방어 가능	소유권이 없어 누가 쥐고 있는지 OS가 몰라 방어 불가능

스레드 순서 제어 (Ordering) 활용법

세마포어의 '소유권 없음'은 버그가 아니라 엄청난 기능이다.

상황: 스레드 1(파일 다운로드)이 끝나야만 스레드 2(압축 해제)가 실행되어야 한다.
구현: 세마포어 초깃값 $S = 0$ 으로 둔다.
- 스레드 2는 시작하자마자 P 연산을 한다. $S=0$이므로 즉시 잠든다.
- 스레드 1이 파일을 다 다운받고 마지막에 V 연산을 때린다.
- 잠들어있던 스레드 2가 깨어나 압축 해제를 시작한다.
이처럼 세마포어는 단순히 남을 못 들어오게 막는 자물쇠(Mutex)가 아니라, "내가 끝났으니 이제 네가 해!"라고 신호를 보내는 완벽한 바통 터치(Signal) 기법으로 쓰인다.
📢 섹션 요약 비유: 뮤텍스는 화장실 열쇠입니다. 들어간 사람이 반드시 문을 열고 나와야 합니다. 세마포어는 경주용 바통입니다. 1번 주자가 뛰고 나서 2번 주자에게 바통을 넘겨야만 2번 주자가 뛸 수 있습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — JDBC 커넥션 풀(Connection Pool) 고갈 및 타임아웃 장애: 자바/스프링 환경에서 DB 커넥션을 10개로 제한(HikariCP 등)해 두었는데, 갑자기 트래픽이 몰리면서 앱이 멈춤(Hang).
- 원인 분석: 커넥션 풀 10개는 전형적인 카운팅 세마포어(초깃값 10) 구조로 관리된다. 스레드 11번째가 getConnection()을 호출하면 내부적으로 P 연산(Wait)이 걸려 쓰레드가 잠든다. 이때 앞에 커넥션을 가져간 10명의 스레드가 쿼리를 너무 길게(Slow Query) 날려서 V 연산(Release)을 안 해주면, 11번째부터 10,000번째 스레드까지 전부 세마포어 큐에 쌓이면서 톰캣 전체가 죽어버리는 현상이다.
- 대응 (기술사적 가이드): 세마포어를 쓸 때는 영원히 잠들지 않도록 반드시 Timeout 파라미터를 적용해야 한다 (sem_timedwait). 예를 들어 3초 안에 커넥션(자원)이 안 나오면, 큐에서 강제로 빠져나와 사용자에게 503 Service Unavailable 예외를 던지는(Fail-fast) 아키텍처가 시스템 붕괴를 막는다.
시나리오 — 세마포어 V 연산 누락으로 인한 자원 릭(Leak): 5개의 버퍼를 관리하는 카운팅 세마포어(S=5). 개발자가 예외 처리를 대충 짰다. try { P(); 파일 쓰기; V(); } catch (e) { 에러 로그 }.
- 원인 분석: 만약 '파일 쓰기' 도중 디스크 꽉 참 에러가 터져서 catch 블록으로 넘어가면? V 연산이 영원히 호출되지 않는다. 이런 일이 5번 누적되면 세마포어 값은 0에서 영원히 올라오지 못하고, 전체 시스템이 이 버퍼를 쓰지 못하는 영구적 데드락(자원 누수)에 빠진다.
- 아키텍처 적용: 세마포어와 락은 반드시 finally 블록이나 C++의 RAII (Resource Acquisition Is Initialization), Go의 defer를 사용하여, 함수가 어떤 식으로 박살 나서 종료되든 OS 차원에서 무조건 V 연산을 호출하여 자원을 반환하도록 언어적 족쇄를 채워야 한다.

의사결정 및 튜닝 플로우

  ┌───────────────────────────────────────────────────────────────────┐
  │                 동시성 제어 객체 (Mutex vs Semaphore) 선택 플로우         │
  ├───────────────────────────────────────────────────────────────────┤
  │                                                                   │
  │   [멀티스레드 환경에서 보호하거나 순서를 맞춰야 할 자원 발생]                    │
  │                │                                                  │
  │                ▼                                                  │
  │      보호해야 할 자원이 "동시에 단 1명만" 접근해야 하는 배타적 자원인가?         │
  │      (예: 전역 변수 증가, 파일 하나에 동시에 쓰기)                           │
  │          ├─ 예 ─────▶ [Mutex (뮤텍스) 선택 권장]                     │
  │          │            (우선순위 역전 방지 및 소유권에 의한 에러 추적 용이)       │
  │          └─ 아니오 (자원이 여러 개 거나, 접근 순서 제어가 필요하다)            │
  │                │                                                  │
  │                ▼                                                  │
  │      자원의 개수가 N개(2개 이상) 인가? (예: DB 커넥션 풀, 워커 스레드 수)       │
  │          ├─ 예 ─────▶ [Counting Semaphore (초깃값 N) 선택]           │
  │          └─ 아니오                                                │
  │                │                                                  │
  │                ▼                                                  │
  │      특정 스레드 A가 끝난 후에만 스레드 B가 실행되어야 하는가? (실행 순서 동기화) │
  │          ├──▶ [Binary Semaphore (초깃값 0) 선택]                     │
  │          │    (A가 끝나며 V(1)를 날려주면, B가 P(0->-1)로 기다리다 깨어남)  │
  └───────────────────────────────────────────────────────────────────┘

[다이어그램 해설] "세마포어 초깃값을 1로 주면 뮤텍스랑 똑같으니까, 그냥 평생 세마포어만 쓰면 안 되나?" 이것은 매우 위험한 생각이다. 세마포어는 소유권이 없기 때문에, 버그가 난 엉뚱한 스레드가 V 연산을 막 호출해서 잠긴 문을 다 부수고 열어버릴 수 있다. 뮤텍스는 오직 문을 잠근 놈만이 문을 열 수 있도록 OS가 철저히 감시하므로, 배타적 통제(상호 배제)에는 무조건 뮤텍스를 쓰는 것이 아키텍처의 정석이다.

도입 체크리스트

신호 소실 (Lost Wakeup): V 연산은 자고 있는 스레드가 없더라도 카운터를 1 늘려둔다(기억함). 하지만 자바의 wait()/notify() 나 Condition Variable은 자고 있는 놈이 없을 때 깨우기(notify)를 부르면 그냥 허공에 증발해 버린다. 세마포어의 이 상태 저장(Stateful) 특성을 이해하고 비동기 신호 처리 아키텍처에 적용했는가?
📢 섹션 요약 비유: 뮤텍스는 나 혼자 쓰는 화장실 열쇠이고, 카운팅 세마포어는 공용 주차장 차단기이며, 이진 세마포어(초기값 0)는 릴레이 육상 경기의 바통입니다. 용도에 맞게 꺼내 써야 코드가 꼬이지 않습니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	무지성 Spinlock/배열 관리	세마포어(P, V) 적용	개선 효과
정량 (CPU 활용)	자원 기다리며 CPU 100% 태움	모자라면 큐에서 수면 (0%)	멀티스레딩 환경의 전력 및 시스템 효율 극대화
정성 (다중 자원)	N개 자원 관리를 위해 복잡한 코드 필요	카운터 하나로 N개 통제	커넥션 풀/오브젝트 풀 구현의 압도적 단순화
정성 (실행 순서)	`while(flag==0)` 폴링 대기	`V()` 시그널로 즉각 깨어남	스레드 간의 우아한 비동기 이벤트 통신(Event-driven) 달성

미래 전망

락프리 및 비동기 프레임워크로의 흡수: 개발자가 코드 중간에 sem_wait()과 sem_post()를 직접 치는 시대는 저물어가고 있다. 세마포어는 데드락을 유발하기 너무 쉽기 때문이다. 현대 개발 환경은 세마포어의 철학을 라이브러리 내부로 숨겨버렸다. Go 언어의 Channel(버퍼 채널)이 바로 카운팅 세마포어의 현대적이고 안전한 환생이며, Java의 CompletableFuture가 실행 순서를 제어하는 이진 세마포어의 진화형이다.
분산 세마포어: 마이크로서비스 시대에는 Zookeeper나 etcd, Redis를 이용해 수십 대의 서버 간에 카운터를 공유하는 분산 세마포어(Distributed Semaphore) 기술이 API Rate Limiting(초당 100번 호출 제한 등)의 핵심 인프라로 맹활약하고 있다.

결론

에츠허르 다익스트라가 고안한 세마포어(P, V 연산)는, 철학자들처럼 뜬구름 잡던 초기 컴퓨터 과학을 완벽한 논리적 토대 위에 올려놓은 불멸의 금자탑이다. 단지 '정수 하나'와 '더하고 빼는 규칙'만으로, 우리는 수만 개의 스레드가 다투지 않고 10개의 DB 커넥션을 나눠 쓰고, 선행 작업이 끝나기를 얌전히 기다리게 만들 수 있었다. 비록 코딩하기 까다롭고 데드락의 위험을 내포하고 있지만, 멀티프로그래밍이 존재하는 한 이 위대한 네덜란드어 약자(P와 V)는 운영체제의 가장 밑바닥에서 영원히 카운트를 세며 시스템의 질서를 지켜낼 것이다.

📢 섹션 요약 비유: 수백 대의 기차가 복잡한 교차로(공유 자원)를 지날 때, 기장들끼리 무전으로 싸우게 놔두지 않고, 중앙 신호등(세마포어 카운터)의 녹색/적색 불빛만 보고 멈출지(P) 달릴지(V) 결정하게 만든 가장 우아한 교통 통제 시스템입니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
P 연산 (Wait / Acquire)	세마포어 카운터를 1 내리고, 0보다 작아지면 프로세스를 영원한 잠(Block)에 빠뜨리는 검문소
V 연산 (Signal / Release)	세마포어 카운터를 1 올리고, 큐에서 자고 있는 불쌍한 프로세스를 깨워주는 구원자
Mutex (뮤텍스)	이진 세마포어(0,1)와 비슷하지만, 오직 락을 쥔 자만이 풀 수 있다는 '소유권'을 가진 상호 배제 전용 자물쇠
Condition Variable (조건 변수)	세마포어처럼 스레드를 깨울 수(Signal) 있지만, 상태를 저장하지 않아 자는 놈이 없으면 신호가 증발해버리는 모니터의 구성 요소
Deadlock (교착 상태)	세마포어 P 연산을 여러 개 순서대로 하려다가, 꼬여서 스레드들이 서로 V 연산을 해주길 영원히 기다리는 참사

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

빵집에 맛있는 소금빵이 딱 5개(세마포어 초깃값) 남았어요.
손님이 한 명 들어갈 때마다(P 연산) 빵 개수가 줄어들어요. 5명이 들어가서 빵이 0개가 되면, 6번째 손님은 문 앞에서 빵이 나올 때까지 텐트를 치고 잠을 잡니다(Block).
주방장이 오븐에서 새 빵을 하나 구워내면(V 연산), 텐트에서 자고 있던 6번째 손님을 깨워서 빵을 쥐여줍니다(Wake-up)! 이게 바로 빵(자원)을 훔치지 않고 질서 있게 나누는 세마포어 규칙이랍니다.