멀티코어 CPU와 멀티스레드 구조를 공부하다 보면 결국 “여러 작업이 동시에 움직이는 환경”이 얼마나 복잡한지 조금씩 느껴지기 시작한다. 나도 처음에는 컴퓨터가 여러 작업을 동시에 처리한다는 게 그냥 성능 좋은 기술 정도로만 보였다. 그런데 실제로는 여러 스레드가 동시에 같은 데이터를 건드리는 순간 생각보다 위험한 상황들이 굉장히 많이 발생할 수 있었다. 그리고 그 대표적인 문제가 바로 Race Condition이다.
처음 이름만 들었을 때는 자동차 경주 같은 느낌이라 왜 이런 이름이 붙었는지 이해가 잘 안 됐다. 그런데 구조를 보고 나니까 이유가 바로 보였다. 여러 작업이 “누가 먼저 실행되느냐”를 두고 경쟁(Race)하는 상황이기 때문이다.
Race Condition은 실행 순서에 따라 결과가 달라지는 문제다
Race Condition은 여러 스레드나 프로세스가 동시에 같은 데이터에 접근할 때 발생한다. 핵심은 “실행 순서에 따라 결과가 달라질 수 있다”는 점이다.
예를 들어 은행 계좌 잔액을 수정하는 프로그램이 있다고 가정해보자. 동시에 두 개의 스레드가 같은 계좌에서 돈을 출금하려고 하면 문제가 생길 수 있다.
처음에는 나도 “컴퓨터가 계산하는 건데 뭐가 문제지?” 싶었다. 그런데 실제로는 출금 과정이 단순 한 번에 끝나는 작업이 아니라:
- 현재 잔액 읽기
- 금액 계산하기
- 새로운 값 저장하기
같은 여러 단계로 이루어져 있다는 걸 알게 됐다.
문제는 이 사이에 다른 스레드가 끼어들 수 있다는 점이다. 예를 들어 두 스레드가 동시에 같은 잔액 값을 읽어버리면, 계산 결과가 꼬여서 실제 돈보다 더 많이 출금되는 상황도 생길 수 있다.
나도 처음에는 이런 버그가 너무 비현실적으로 느껴졌다. 그런데 실제로 멀티스레드 환경에서는 이런 문제가 생각보다 흔하게 발생할 수 있다고 한다. 특히 서버처럼 수많은 요청이 동시에 들어오는 환경에서는 “동시에 같은 데이터 접근” 자체가 굉장히 자주 일어나는 상황이었다.
그걸 보고 처음으로 “동시성 프로그래밍이 왜 어려운지” 조금 실감하게 됐다.
Race Condition이 무서운 이유는 재현이 어렵기 때문이다
Race Condition이 특히 무서운 이유는 항상 발생하는 버그가 아니라는 점이다. 어떤 때는 정상 동작하고, 어떤 때는 갑자기 이상한 결과가 나온다.
즉, 코드 자체는 멀쩡해 보이는데 특정 타이밍에서만 문제가 터지는 것이다.
나도 예전에 간단한 멀티스레드 예제 코드를 돌려본 적이 있었는데, 몇 번은 정상 결과가 나오다가 어느 순간 갑자기 값이 꼬이는 걸 보고 꽤 신기했던 기억이 있다. 처음에는 내가 코드 잘못 짠 줄 알았는데, 실행 순서 자체가 매번 달라질 수 있기 때문이라는 걸 알고 나니까 왜 이런 현상이 생기는지 이해가 됐다.
특히 Race Condition은 디버깅도 굉장히 어렵다고 한다. 왜냐하면 디버깅 로그를 찍거나 속도가 조금만 바뀌어도 실행 순서가 달라져서 문제가 안 나타날 수도 있기 때문이다.
실제로 서버 개발 쪽에서는 “가끔만 발생하는 이상한 버그”가 알고 보니 Race Condition이었던 경우도 많다고 한다. 나도 관련 장애 사례들을 찾아보다가, 아주 작은 동기화 실수 때문에 데이터가 꼬이거나 서비스 전체가 불안정해지는 경우를 보고 꽤 놀랐다.
그 이후로는 “동시에 실행된다”는 게 단순히 빠른 게 아니라, 훨씬 더 복잡한 세계라는 걸 느끼게 됐다.
그래서 운영체제와 프로그래밍 언어는 동기화 도구를 제공한다
Race Condition을 막기 위해 등장한 대표적인 개념이 바로 동기화(Synchronization)다. 쉽게 말하면 “한 번에 한 작업만 접근 가능하게 제한하는 구조”에 가깝다.
대표적으로:
- Mutex
- Lock
- Semaphore
같은 기술들이 사용된다.
예를 들어 어떤 스레드가 데이터를 수정하는 동안에는 다른 스레드가 접근하지 못하게 잠시 잠그는 방식이다.
처음에는 이런 락(Lock) 구조를 보고 “굳이 이렇게까지 해야 하나?” 싶었는데, Race Condition 사례들을 보다 보니까 왜 이런 개념들이 꼭 필요한지 조금 이해가 됐다.
하지만 또 재미있는 건, 락을 너무 많이 사용하면 성능이 떨어질 수도 있다는 점이었다. 결국 현대 서버 구조는 “동시에 빠르게 처리하고 싶지만, 데이터 충돌은 막아야 하는” 굉장히 어려운 균형 위에서 움직이고 있는 셈이다.
이걸 공부하면서 가장 인상 깊었던 건 컴퓨터가 단순히 계산만 잘한다고 끝나는 게 아니라는 점이었다. 현대 시스템에서는 수많은 스레드가 동시에 움직이고 있고, 그 흐름을 얼마나 안전하게 제어하느냐가 성능만큼 중요해진 것이다.
한 줄로 정리하면 Race Condition은 여러 스레드가 동시에 같은 데이터를 수정하면서 실행 순서에 따라 결과가 달라지는 문제이며, 재현이 어렵고 예측 불가능한 버그를 만들기 때문에 특히 위험하다.