멀티코어 CPU와 동시성(concurrency) 구조를 공부하다 보면 결국 계속 등장하는 문제가 하나 있다. 바로 여러 스레드가 동시에 같은 데이터를 다루는 순간 어떻게 안전하게 처리할 것인가 하는 문제다. 나도 처음에는 그냥 Lock이나 Mutex를 사용하면 대부분 해결되는 줄 알았다. 실제로 많은 프로그램들은 락을 사용해서 Race Condition 같은 문제를 막는다. 그런데 조금 더 찾아보니까 현대 서버나 고성능 시스템에서는 오히려 “락을 최대한 줄이려는 방향”으로 계속 발전하고 있다는 걸 알게 됐다. 그리고 그 과정에서 등장하는 대표적인 개념이 바로 Lock-Free Programming이다.
처음 이름만 들었을 때는 솔직히 굉장히 멋있어 보였다. “락 없이 동시성을 처리한다”는 말 자체가 뭔가 엄청 효율적이고 미래 기술 같은 느낌이었다. 그런데 구조를 이해하기 시작하니까 왜 이 분야가 어려운지 바로 체감되기 시작했다. 단순히 락을 안 쓰는 게 아니라, CPU와 메모리의 아주 미세한 동작 흐름까지 전부 고려해야 하는 세계였기 때문이다.
락(Lock)은 안전하지만 동시에 성능 문제도 만든다
멀티스레드 환경에서는 동시에 같은 데이터를 수정하면 Race Condition 같은 문제가 발생할 수 있다. 그래서 가장 기본적인 해결 방법이 Lock이다. 쉽게 말하면 어떤 스레드가 데이터를 사용하는 동안 다른 스레드는 잠시 기다리게 만드는 구조다.
처음에는 나도 “그럼 락 쓰면 끝 아닌가?”라고 생각했다. 실제로 락은 구조도 직관적이고 안정적이다. 특히 동시성 문제를 처음 배울 때는 거의 필수처럼 등장한다.
그런데 문제는 스레드 수가 많아질수록 락 경쟁(lock contention)도 심해진다는 점이었다. 예를 들어 수십 개 스레드가 하나의 락을 기다리기 시작하면 CPU가 실제 계산보다 기다리는 시간에 더 많은 자원을 쓰게 될 수도 있다.
특히 서버 환경에서는 이런 문제가 더 크게 나타난다고 한다. 요청이 엄청 많이 들어오는 상황에서 특정 락 하나 때문에 전체 처리량이 갑자기 떨어지는 경우도 꽤 많다고 한다.
나도 예전에 서버 성능 관련 글을 보다가 “멀티코어 시대에는 락 자체가 병목이 되기도 한다”는 표현을 본 적이 있었는데, 처음에는 과장인 줄 알았다. 그런데 CPU 코어 수가 많아질수록 동시에 접근하는 스레드도 늘어나니까, 결국 락 경쟁이 성능 한계로 이어질 수 있다는 걸 이해하게 됐다.
그래서 현대 고성능 시스템에서는 “가능하면 락 없이 처리할 수 없을까?”라는 방향으로 최적화가 계속 발전하게 된 것이다.
Lock-Free 구조는 CPU 원자 연산(Atomic Operation)을 활용한다
Lock-Free Programming의 핵심은 락 없이도 데이터 충돌을 안전하게 처리하는 것이다. 여기서 중요한 역할을 하는 것이 바로 Atomic Operation이다.
대표적으로 CAS(Compare-And-Swap) 같은 연산이 자주 사용된다. 쉽게 말하면 “현재 값이 내가 예상한 값과 같으면 새로운 값으로 바꿔라”라는 구조다.
예를 들어 어떤 스레드가 데이터를 수정하려고 할 때, 중간에 다른 스레드가 값을 바꾸지 않았는지 확인하는 방식이다. 만약 값이 이미 달라졌다면 다시 시도한다.
처음에는 나도 “그럼 그냥 CAS 계속 쓰면 락 없어도 되는 거 아닌가?”라고 생각했다. 그런데 실제로는 이 구조가 생각보다 훨씬 복잡했다.
특히 여러 스레드가 동시에 계속 CAS를 시도하면 실패와 재시도가 반복될 수 있고, 메모리 순서(memory ordering) 문제까지 함께 고려해야 한다. 결국 단순히 락을 없앤다고 끝나는 게 아니라, CPU 캐시 구조와 Memory Barrier까지 전부 연결되는 문제였던 것이다.
나도 처음 Lock-Free 구조 그림들을 봤을 때 꽤 충격이었다. 예전에는 프로그램이 그냥 순서대로 실행되는 줄 알았는데, 실제로는 CPU 내부 최적화와 캐시 동기화까지 전부 고려하면서 코드를 설계하고 있었기 때문이다.
Lock-Free Programming이 어려운 이유는 ‘가끔만 터지는 문제’가 많기 때문이다
Lock-Free 구조가 특히 어려운 이유는 버그가 항상 발생하지 않는다는 점이다. 특정 CPU 환경이나 아주 드문 타이밍에서만 문제가 나타나는 경우도 많다.
예를 들어 평소에는 잘 동작하는데, 서버 부하가 높아지거나 특정 멀티코어 환경에서만 갑자기 데이터가 꼬이는 상황이 생길 수도 있다.
나도 처음에는 “결국 테스트 많이 하면 잡히는 거 아닌가?” 싶었는데, 실제 동시성 버그들은 재현 자체가 굉장히 어렵다고 한다. 심지어 디버깅 로그를 찍는 순간 실행 타이밍이 바뀌어서 문제가 사라지는 경우도 있다고 한다.
특히 Lock-Free 구조에서는 ABA Problem 같은 추가 문제도 등장한다. 값이 A였다가 B로 바뀌었다가 다시 A가 되면, CAS 입장에서는 “변화 없음”처럼 보일 수도 있다는 것이다. 처음 이 개념을 봤을 때는 진짜 머리가 복잡해졌다.
그걸 보면서 처음으로 “현대 서버 개발이 왜 어려운지” 조금 실감하게 됐다. 단순히 코드를 빨리 실행하는 수준이 아니라, 수많은 코어와 캐시, 메모리 재정렬 속에서 동시에 안전하게 동작해야 하기 때문이다.
결국 Lock-Free Programming은 단순히 락을 안 쓰는 기술이 아니라, CPU와 메모리 구조를 깊게 이해한 상태에서야 겨우 다룰 수 있는 굉장히 고급스러운 동시성 최적화 방식이라는 생각이 들었다.
한 줄로 정리하면 Lock-Free Programming은 락 없이 원자 연산과 CPU 동기화 구조를 활용해 동시성을 처리하는 방식이며, 성능은 뛰어나지만 메모리와 실행 순서를 모두 고려해야 해서 구현이 매우 어렵다.