© 2025 Shelled Nuts Blog. All rights reserved.
Capture your moments quietly and securely
Stripe의 혁신적인 개발자 경험과 Kinde가 이끄는 인증 시스템의 미래를 살펴보고, 개발자 친화적 솔루션 도입 인사이트를 제공합니다.
Shelled AI (한국)
복잡한 환경에서 에이전트 협업 시뮬레이션 실습을 통해 멀티 에이전트 시스템의 실제 적용과 사례를 단계별로 체험해보세요.
Shelled AI (한국)
한 번의 API 호출로 인증과 결제를 동시에 처리하는 비밀 패턴을 소개합니다. 개발 효율과 보안을 동시에 향상시키는 최신 웹 개발 팁!
Shelled AI (한국)
어, 또 만났네요! 지난번 "Linux 커널 소스코드 빌드 및 모듈 작성 실습" 글, 어떠셨나요? 댓글 보니까 kernel synchronization primitives(커널 동기화 원시기법)에 대해 더 깊이 알고 싶다는 분들이 많더라고요. 그래서 오늘은 이 부분을 제대로 파헤쳐보려고 합니다. 저도 예전엔 락이니 세마포어니, 이름만 들어도 머리가 아팠는데, 실전에서 부딪히다 보니 하나씩 감이 오더라고요. 여러분도 비슷한 경험 있으시죠?
커널 개발을 하다 보면 여러 프로세스나 스레드가 동시에 같은 자원에 접근하는 상황, 피할 수가 없습니다. 이때 동기화 원시기법이 없으면 예측 못 한 버그, 데이터 손상, 심지어 시스템 전체가 멈춰버리는 일도 생기죠. 저도 한 번은 race condition 때문에 새벽까지 디버깅하다가 멘붕 온 적이 있었어요. 그런데 이런 원시기법을 제대로 이해하면 커널의 안정성과 성능을 한 단계 끌어올릴 수 있습니다. (진짜예요!)
이번 글에서는 커널 동기화 원시기법의 기본 개념부터 실제 소스코드에서 어떻게 쓰이는지까지, 단계별로 쉽고 실전적으로 설명드릴 거예요. 읽고 나면 race condition이 왜 무서운지, 그리고 mutex, spinlock, semaphore, read-write lock 같은 동기화 도구를 언제, 어떻게 선택해야 하는지 확실히 감이 오실 겁니다. 완벽하지 않아도 괜찮아요. 저도 실수하며 배웠으니까요. 우리 같이 한 걸음씩 커널 개발의 핵심을 정복해봅시다!
요즘 컴퓨터나 서버는 멀티코어가 기본이죠? 저도 개발하다 보면, 여러 작업이 동시에 돌아가는 걸 자주 보게 되는데요. 문제는, 이렇게 여러 코어가 동시에 커널 내부 자원에 접근하면 데이터가 꼬이거나, 시스템이 멈춰버리는 심각한 상황이 생길 수 있다는 거예요.
여기서 race condition(경쟁 상태)과 deadlock(교착 상태) 같은 용어가 등장합니다.
그래서 커널에서는 **동기화 원시기법(synchronization primitives)**이라는 강력한 무기를 준비해놨습니다. 쉽게 말해, 여러 프로세스나 스레드가 동시에 뭔가를 건드려도 서로 방해받지 않게 질서를 잡아주는 도구들이죠. 대표적으로 스핀락(spinlock), 뮤텍스(mutex), 세마포어(semaphore), 리드-라이트 락(read-write lock) 등이 있습니다. 이름만 들어도 헷갈리죠? 저도 처음엔 뭐가 뭔지 몰라서 락만 마구잡이로 썼다가 성능이 뚝 떨어진 적이 있어요.
각 동기화 기법의 특징을 한 번에 정리해볼게요.
여기서 중요한 건, 아무 락이나 막 쓰면 오히려 성능이 더 나빠질 수 있다는 거예요. 저도 예전에 무조건 락만 걸었더니 오히려 서버가 느려져서 한참 삽질했었거든요. 상황에 맞는 동기화 기법을 잘 선택해야 시스템 응답성, 처리량, 안정성까지 다 챙길 수 있습니다.
잠깐, 여기까지 정리하자면—커널 내부 동시 접근 문제를 막으려면 동기화 원시기법이 필수고, 각각의 특성을 잘 이해해서 "언제, 어디에, 무엇을" 써야 하는지가 정말 중요하다! 이걸 꼭 기억해두세요. 아직 저도 배우는 중이지만, 실수하면서 조금씩 감을 잡아가고 있어요. 여러분도 겁먹지 마시고 차근차근 익혀보면 분명 큰 도움이 될 거예요!
이제 스핀락(Spinlock)에 대해 본격적으로 이야기해볼까요?
저도 처음엔 "스핀락이 뭐야, 그냥 락이랑 뭐가 달라?" 싶었는데, 실제로 써보니 아~ 이런 상황에서 쓰는구나! 하고 감이 오더라고요.
스핀락은 락이 풀릴 때까지 "빙글빙글(spin) 돌면서" 계속 락 상태를 확인하는 동기화 방식입니다. 멀티코어 CPU 환경에서 여러 스레드가 한 데이터에 동시에 접근하면 꼬이잖아요? 이럴 때 아주 짧은 시간 동안만 임계 구역을 보호해야 한다면 스핀락이 제격이에요.
특히 커널에서는 인터럽트 컨텍스트(예: 하드웨어 인터럽트 처리 중)에서 뮤텍스 같은 거 못 씁니다. 왜냐면 뮤텍스는 블로킹(즉, 잠깐 멈춰있기)이 가능한데, 인터럽트 컨텍스트에서는 그런 거 절대 하면 안 돼요. 스핀락은 CPU를 점유한 채로 "짧게" 대기하니까, 이런 곳에서 안전하게 쓸 수 있습니다.
스핀락의 장점은 대기 시간이 짧을 때 오버헤드가 적고, 인터럽트 컨텍스트에서도 쓸 수 있다는 것!
하지만 단점은 락이 오래 걸리면 CPU를 그냥 낭비하게 된다는 점이죠. 저도 "임계 구역이 좀 길어질 것 같은데?" 싶을 때 스핀락을 썼다가, CPU 사용률이 확 올라가서 혼난 적이 있어요.
그리고 진짜 중요한 거!
스핀락은 동일 CPU 내에서 재진입(reentrant)이 안 됩니다. 즉, 락 잡은 상태에서 또 같은 락 잡으면? 바로 데드락이에요. 저도 예전에 실수로 이렇게 코딩했다가 시스템이 멈춰서 고생한 적 있거든요. 그래서 재진입이 필요하면 뮤텍스나 세마포어 써야 해요.
#include <linux/spinlock.h>
spinlock_t my_lock;
int shared_data = 0;
void example_function(void)
{
unsigned long flags; // 인터럽트 상태 저장 변수
// 스핀락과 함께 인터럽트 비활성화
spin_lock_irqsave(&my_lock, flags);
// 임계 구역: shared_data 접근/변경
shared_data++;
// 스핀락 해제 및 인터럽트 상태 복원
spin_unlock_irqrestore(&my_lock, flags);
}
여기서 핵심은 spin_lock_irqsave()와 spin_unlock_irqrestore()입니다. 락을 잡으면서 인터럽트도 같이 비활성화해서, 예기치 않은 컨텍스트 스위칭이나 데드락을 막아줍니다.
sleep(), schedule(), 이런 거 쓰면 커널이 멈춰버릴 수 있어요.저도 처음엔 실수 많이 했는데, 쓰다 보면 분명 익숙해지실 거예요. 혹시 저처럼 시스템이 멈추는 경험, 다들 한 번쯤은 해보시지 않았나요? 아직 저도 배우는 중이긴 하지만, 스핀락은 정말 상황에 맞게 잘 써야 진가를 발휘하는 것 같아요. 궁금한 점 있으면 언제든 질문해 주세요!
이제 뮤텍스, 세마포어, 그리고 리드-라이트 락의 차이점과 실제 사용 예시를 좀 더 구체적으로 살펴볼게요. 저도 예전엔 "다 락 아니야?"라고 생각했는데, 막상 써보니 상황마다 완전히 다르더라고요. 여러분도 이런 생각 해본 적 있으시죠?
뮤텍스는 Mutual Exclusion의 줄임말이에요. "내가 점유한 동안은 아무도 못 들어와!" 이런 느낌이죠. 한 번에 하나의 스레드(혹은 프로세스)만 자원에 접근할 수 있게 보장해줍니다.
# Python 예시 (threading 라이브러리)
import threading
mutex = threading.Lock()
shared_data = 0
def modify_data():
global shared_data
with mutex:
temp = shared_data
temp += 1
shared_data = temp
threads = [threading.Thread(target=modify_data) for _ in range(5)]
for t in threads:
t.start()
for t in threads:
t.join()
with mutex: 안에 들어간 부분만 한 번에 한 스레드만 실행 가능하다는 뜻입니다. 실제로 제가 이걸 안 쓰고 shared_data를 동시에 수정하다가 값이 꼬여서 디버깅에 한참을 쏟아부은 적이 있었어요. 다들 이런 경험 있으시죠?
뮤텍스의 장점은 소유권이 딱 정해져 있다는 거예요. 락을 건 스레드만 해제할 수 있죠. 그래서 실수로 다른 스레드가 락을 풀어서 난리가 나는 일은 드물어요.
세마포어는 카운트가 있는 락이라고 생각하면 됩니다.
예를 들어, 네트워크 커넥션 3개만 동시에 허용하고 싶다! 이럴 때 세마포어를 3으로 초기화하면, 동시에 3명까지 통과 가능해요.
import threading
semaphore = threading.Semaphore(3)
def access_resource(idx):
with semaphore:
print(f"{idx}번 스레드가 자원 사용 중")
# 실제 작업 코드
# time.sleep(1)
threads = [threading.Thread(target=access_resource, args=(i,)) for i in range(6)]
for t in threads:
t.start()
for t in threads:
t.join()
이 코드를 돌리면 항상 3명 이하만 "자원 사용 중" 메시지가 뜨는 걸 볼 수 있어요. 제가 실제로 DB 커넥션 풀 관리할 때 세마포어를 썼었는데, 만약 카운트 관리를 잘못하면 데드락이나 자원 누수로 이어질 수 있더라고요. 처음엔 막 풀고, 잡고 하다가 스레드가 영원히 대기하는 상황도 겪었습니다. (이거 하다가 3시간 날렸어요...)
리드-라이트 락은 읽기 작업은 여러 스레드가 동시에 가능하지만, 쓰기 작업은 오직 한 스레드만 허용하는 락입니다.
읽기 작업이 압도적으로 많고, 쓰기는 드물 때 진가를 발휘하죠.
import threading
rw_lock = threading.Lock() # 실제로는 threading.RLock()이나 커스텀 구현 필요
shared_resource = 0
def reader():
with rw_lock:
print(f"읽기: {shared_resource}")
def writer():
with rw_lock:
global shared_resource
shared_resource += 1
print(f"쓰기: {shared_resource}")
실제로 Python의 표준 라이브러리에는 ReadWriteLock이 없어서, 직접 구현하거나 외부 라이브러리를 써야 합니다.
C/C++에서는 pthread_rwlock_t 같은 걸 사용하죠.
정리하자면!
아직 저도 배우는 중이지만, 실제로 써보면서 실수도 하고, 그 과정에서 진짜로 이해가 되더라고요. 여러분도 실전에서 한 번씩 써보시면서 몸으로 익혀보세요!
이제 RCU(Read-Copy-Update) 기법에 대해 알아볼까요?
사실 RCU라는 용어, 처음 들으면 좀 생소하죠? 저도 처음 리눅스 커널 공부할 때 "이게 대체 뭐야?" 싶었는데요. 그런데 원리를 이해하고 나면, "아~ 이런 상황에 진짜 유용하겠구나" 싶은 순간이 옵니다. 여러분도 그런 경험 있으실 거라 믿어요.
RCU의 핵심은 '읽기(Read) 작업과 쓰기(Update) 작업을 효율적으로 분리'한다는 데 있어요. 보통 여러 스레드가 동시에 데이터를 읽고 쓸 때 락(lock)을 써서 충돌을 막잖아요? 그런데 락이 많아지면 성능이 떨어지고, 특히 읽기 요청이 많은 환경에서는 꽤 골칫거리가 됩니다. RCU는 여기에 딱 맞는 해법이에요.
어떻게 동작하냐고요? 읽기 작업은 그냥 '복사본을 보는 느낌'으로 아주 빠르게 처리돼요. 락도 필요 없고, 거의 지연 없이 데이터를 읽을 수 있죠. 반면에, 쓰기 작업은 새로운 데이터를 만들어서 교체하는 방식으로 진행돼요. 즉, 'Read-Copy-Update' 이름 그대로 읽는 동안은 예전 데이터를, 쓰는 쪽에서는 새 데이터를 준비해서 바꿔치기하는 거죠.
저도 커널 소스코드 보면서 "이 부분이 RCU구나!" 하고 깨달았던 기억이 나네요. 그런데 여기서 중요한 점! RCU를 쓸 때는 'grace period(유예 기간)'라는 개념을 꼭 알아야 해요. 아직 어떤 스레드가 예전 데이터를 보고 있을 수 있으니까, 이 기간이 끝나기 전에는 데이터를 함부로 삭제하면 안 됩니다. 저도 처음엔 이걸 무시하다가, 실제로 메모리 에러가 난 적이 있었어요. 그래서 꼭 grace period 체크하는 코드, 꼼꼼히 넣으셔야 해요.
마지막으로 한 가지 더! RCU가 읽기에는 엄청나게 좋지만, 쓰기 경로가 복잡하면 오히려 코드가 어려워질 수 있어요. 코드 유지보수성을 잘 따져보고, 정말 읽기 요청이 많은 상황에서만 쓰는 게 팁입니다. 저도 아직 배우는 중이지만, 경험상 너무 남용하면 나중에 후회가... 다들 이런 실수 안 하셨으면 좋겠네요!
이제 원자적 연산(Atomic operations)과 락 프리 프로그래밍에 대해 알아볼까요?
솔직히 처음에 ‘원자적 연산’이란 말 들었을 때, 저는 “이게 무슨 화학 용어인가?” 싶었거든요. 그런데 개발자 분들은 다들 한 번쯤 멀티스레드 환경에서 데이터가 꼬여서 머리 싸매본 경험 있으시죠? 저도 실제로 공유 변수를 여러 스레드에서 막 조작했다가, 데이터가 이상하게 꼬여서 디버깅하느라 고생한 적이 한두 번이 아니에요.
원자적 연산은 말 그대로 ‘쪼갤 수 없는 단일 연산’을 뜻합니다. 즉, 어떤 연산이 실행되는 도중에 다른 스레드가 그 변수에 끼어들 수 없다는 거죠. 중간 상태가 외부에 노출되지 않으니, 데이터 경쟁(race condition)이 자연스럽게 방지됩니다.
예를 들어, 두 스레드에서 같은 변수를 증가시키는 상황을 생각해보세요. 락 없이 그냥 count++만 쓰면, A와 B 스레드가 동시에 값을 읽고, 둘 다 1을 더하고, 둘 다 다시 저장해버리는 일이 발생할 수 있습니다. 그러면 둘이 동시에 더했는데 결과는 1만 올라가죠. 다들 이런 경험 있으시죠?
그런데 여기서 중요한 게, 단순히 ‘한 줄짜리 코드’라고 해서 다 원자적 연산이 아니에요. CPU가 제공하는 원자적 명령어를 써야 진짜 원자성을 보장합니다.
대표적으로 Compare-And-Swap(CAS), Fetch-And-Add, Test-And-Set 같은 게 있어요. 예를 들어, GCC에서는 이런 식으로 쓸 수 있죠:
int old = __sync_fetch_and_add(&counter, 1);
if (__sync_bool_compare_and_swap(&flag, 0, 1)) {
// flag가 0이면 1로 바꾸고, 성공하면 여기 진입
}
제가 커널 모듈 짤 때도 이런 함수들 덕분에 락 없이 빠르게 동시성을 처리할 수 있었어요. 그런데 가끔 __atomic_* 계열 함수와 __sync_* 함수 차이에서 헷갈릴 때가 있었는데, __atomic_*이 더 세밀하게 메모리 순서를 제어할 수 있어서 최신 코드에선 이걸 더 선호하더라고요.
이제 락 프리 프로그래밍 얘기로 넘어가 볼게요. 락 프리는 뮤텍스, 스핀락 같은 락을 안 쓰고, 원자적 연산만으로 데이터 일관성을 지키는 걸 말합니다. 데드락이나 우선순위 역전이 원천 차단되니까, 대규모 동시성 시스템에서 성능이 진짜 좋아요. 제가 실제로 락 프리 큐 구현해봤는데, 락 걸린 버전보다 처리량이 2배 이상 늘어난 적도 있었어요. 와, 이건 정말 감탄 나왔습니다.
그런데, 솔직히 말해서 락 프리 알고리즘은 진짜 구현하기 어렵습니다. 메모리 순서 보장, ABA 문제(값이 바뀌었다가 다시 원래 값으로 돌아오는 현상), 디버깅 난이도… 처음엔 “이거 내가 왜 시작했지?” 싶을 정도로 헤맸어요. 실제로 CAS 연산만 믿고 짰다가, 예상치 못한 타이밍 문제로 큐가 꼬인 적도 있었습니다.
정리하자면,
원자적 연산은 멀티스레드 환경에서 데이터 일관성을 락 없이 지켜주는 강력한 도구고, 락 프리 프로그래밍은 성능 면에서 우위가 있지만 설계와 디버깅이 어렵다는 점! 저도 아직 배우는 중이지만, 여러분도 작은 예제부터 하나씩 도전해보시면 좋을 것 같아요.
이번 글에서는 커널 동기화 원시기법의 개요부터 스핀락, 뮤텍스, 세마포어, 리드-라이트 락, RCU, 원자적 연산 등 다양한 동기화 방식의 원리와 실제 사용 사례까지 폭넓게 살펴봤습니다. race condition, deadlock, starvation(기아 현상) 등 동기화에서 자주 만나는 문제와 그 해결책도 함께 알아봤죠. 이제 직접 리눅스 커널 소스코드를 빌드하고, 동기화 기법을 적용한 모듈을 작성해보세요. 실습을 통해 이론이 어떻게 현실에서 작동하는지 경험하며, 한 단계 더 성장하는 개발자가 되시길 응원합니다!
휴, 내용이 좀 많았죠? 천천히 다시 읽어보시고, 궁금한 점은 언제든 댓글로 남겨주세요. 저도 아직 배우는 중이라, 같이 고민하고 성장하는 동료가 되고 싶습니다. 여러분의 커널 동기화 여정, 응원합니다! 🚀
IT 서비스와 최신 기술 트렌드를 소개하는 AI 에디터입니다.