---
title: "뮤텍스: 공유 상태를 지키는 잠금은 어디부터 어디까지일까"
author: "Lee"
published_at: "2026-10-13T13:43:00.651Z"
updated_at: "2026-09-30T09:08:08.211Z"
tags: ["컴퓨터공학","운영체제"]
canonical_url: "https://ariser.io/@writer_a1cd615ab19e/%EB%AE%A4%ED%85%8D%EC%8A%A4-%EA%B3%B5%EC%9C%A0-%EC%83%81%ED%83%9C%EB%A5%BC-%EC%A7%80%ED%82%A4%EB%8A%94-%EC%9E%A0%EA%B8%88%EC%9D%80-%EC%96%B4%EB%94%94%EB%B6%80%ED%84%B0-%EC%96%B4%EB%94%94%EA%B9%8C%EC%A7%80%EC%9D%BC%EA%B9%8C"
ai_assisted: false
---

# 뮤텍스: 공유 상태를 지키는 잠금은 어디부터 어디까지일까

[원문](https://ariser.io/@writer_a1cd615ab19e/%EB%AE%A4%ED%85%8D%EC%8A%A4-%EA%B3%B5%EC%9C%A0-%EC%83%81%ED%83%9C%EB%A5%BC-%EC%A7%80%ED%82%A4%EB%8A%94-%EC%9E%A0%EA%B8%88%EC%9D%80-%EC%96%B4%EB%94%94%EB%B6%80%ED%84%B0-%EC%96%B4%EB%94%94%EA%B9%8C%EC%A7%80%EC%9D%BC%EA%B9%8C)

뮤텍스는 여러 실행 흐름이 같은 임계 구역에 동시에 들어가지 못하게 하는 상호 배제 장치다. 공유 목록을 수정하거나 여러 값 사이의 규칙을 유지할 때, 작업 하나가 잠금을 얻은 뒤 보호 구간을 수행하고 잠금을 해제한다. 일반적인 뮤텍스에는 소유권이 있어 잠금을 얻은 실행 흐름이 해제하는 규칙을 따른다.

![열쇠를 가진 한 스레드만 공유 연결 리스트의 갱신 구간에 들어가고 다른 스레드는 기다리는 그림](/api/v1/media/cf722ed4-ef7b-4293-86e2-65426210c251)

*뮤텍스는 모든 접근 경로가 같은 규약을 따를 때 임계 구역의 규칙을 지킨다.*

## 변수보다 규칙을 보호한다

연결 리스트의 첫 노드 앞에 새 노드를 삽입한다고 하자. 새 노드가 이전 첫 노드를 가리키도록 하고, 목록의 시작 포인터를 새 노드로 바꾼다. 다른 스레드가 중간 상태를 보지 않게 하려면 이 갱신 관계를 하나의 임계 구역으로 묶어야 한다. 포인터 하나의 쓰기가 원자적이어도 목록 전체의 논리적 규칙이 자동으로 유지되지는 않는다.

잠금은 자료 자체에 마법의 보호막을 붙이는 것이 아니다. 자료를 읽고 변경하는 코드가 같은 잠금 규약을 따라야 보호된다. 한 경로가 잠금을 생략하면 다른 경로가 성실히 잠가도 문제가 생긴다. 보호 대상 상태와 그 상태를 접근하는 경로를 문서화하는 일이 뮤텍스 함수 이름을 선택하는 것보다 중요하다.

## 기다리는 방식도 구현의 일부

잠금을 얻지 못한 실행 흐름은 운영체제에 의해 잠들거나, 짧게 반복 검사하거나, 두 방식을 조합할 수 있다. [Linux의 뮤텍스 설계 문서](https://www.kernel.org/doc/html/latest/locking/mutex-design.html)는 빠른 획득 경로와 경쟁 시 처리 방식을 설명한다. 스핀락과 뮤텍스를 모두 같은 방식으로 계속 CPU를 쓰는 잠금으로 생각하면 실제 비용을 잘못 판단한다.

같은 뮤텍스는 상호 배제뿐 아니라 보호된 자료의 관찰 순서를 정하는 역할도 한다. 앞선 소유자가 수행한 변경을 뒤이어 잠금을 얻은 스레드가 올바르게 보도록 언어와 라이브러리의 동기화 규칙이 제공된다. 단순히 여러 스레드의 시간표만 겹치지 않게 한다고 충분한 것은 아니며, 적절한 메모리 가시성도 필요하다.

## 짧게 잡되 필요한 작업은 함께

잠금 안에서 네트워크 응답을 오래 기다리면 다른 작업이 모두 지연될 수 있다. 보호가 필요 없는 계산을 밖으로 옮기면 경쟁을 줄일 수 있다. 하지만 확인한 상태가 잠금 밖에서 바뀔 수 있다면 다시 검사해야 한다. 예를 들어 빈 공간 확인과 실제 삽입을 분리하면, 그 사이 다른 작업이 공간을 차지할 수 있다.

오류나 조기 반환이 생겨도 잠금은 반드시 해제해야 한다. 언어의 범위 기반 자원 관리나 컨텍스트 관리 구문을 사용하면 예외 경로에서도 규칙을 유지하기 쉽다. 재귀 뮤텍스는 같은 실행 흐름의 중복 획득을 지원할 수 있지만 모든 뮤텍스가 그렇지는 않다. 잠금 종류와 라이브러리의 소유권 규약을 명확히 확인해야 한다.

잠금 둘을 반대 순서로 잡으면 교착 상태가 생길 수 있다. 여러 잠금이 필요하면 순서를 통일하고, 잠금을 보유한 채 호출하는 코드가 추가 잠금을 요구하는지도 살펴야 한다. 뮤텍스는 경쟁 상태를 해결하는 도구지만 잘못된 범위와 순서는 새로운 대기 문제를 만든다. 올바른 설계는 보호할 규칙, 획득 순서, 해제 수명을 함께 설명한다.

### 참고 자료

- [Linux Kernel — Generic Mutex Subsystem](https://www.kernel.org/doc/html/latest/locking/mutex-design.html)