문제 16 — 동시성 버그 재현과 검출: 데이터 레이스 디텍터(ThreadSanitizer/Helgrind)와 결정적 재현 기법

게임서버의 데이터 레이스는 로컬 테스트에서는 멀쩡히 통과하다가, 운영 트래픽·특정 코어 배치·GC 타이밍이 겹치는 순간에만 터지는 경우가 많다. "왜 재현이 어려운가"와 "어떻게 검출·재현하는가"를 다음 항목으로 설명하라.

1. 재현이 드문 이유: 데이터 레이스가 실제 운영에서 극히 낮은 확률로만 증상을 드러내는 이유를 스케줄링 비결정성 관점에서 설명하라. OS 스케줄러의 타임슬라이스·코어 배치, 컴파일러/CPU의 명령어 재배열, 캐시 상태(락 경합 타이밍)가 어떻게 "레이스는 존재하지만 대부분의 실행 순서에서는 우연히 안전한 결과가 나오는" 상황을 만드는가? 하이젠버그(Heisenbug) 현상(디버거/로깅을 붙이면 타이밍이 바뀌어 증상이 사라지는 것)과 연결해 설명하라.

2. 동적 분석 도구의 원리: ThreadSanitizer(TSan)나 Helgrind 같은 동적 레이스 디텍터가 실제로 프로그램을 실행하며 레이스를 탐지하는 원리를 설명하라.

   • shadow memory: 프로그램의 각 메모리 워드마다 "누가 언제 어떻게 접근했는가"를 기록하는 그림자 상태를 별도로 유지하는 방식과, 이 때문에 메모리·실행 시간 오버헤드가 왜 큰지(TSan은 통상 5~15배 느려지고 메모리도 수 배 더 쓴다).
   • happens-before 관계: 락 해제→획득, 스레드 생성→시작, 조인 등이 만드는 부분순서(happens-before)를 어떻게 벡터 클록(vector clock) 등으로 추적하는지, 그리고 두 접근(적어도 하나는 쓰기) 사이에 happens-before 관계가 없고 서로 다른 스레드에서 발생하면 레이스로 보고하는 원리를 설명하라.
   • Helgrind(락셋 알고리즘 기반)와 TSan(happens-before 기반)의 접근 차이를 간단히 비교하라.

3. 정적 분석과의 차이: 정적 분석(코드를 실행하지 않고 소스/IR을 분석)이 레이스를 찾는 방식과, 동적 분석(실제 실행 경로만 관찰)의 근본적 차이를 설명하라. 정적 분석의 장점(실행되지 않은 경로도 검사)과 한계(오탐 다수, 락 상속·복잡한 동기화 패턴 오판), 동적 분석의 장점(실제 실행 기반이라 오탐이 적음)과 한계(그 실행에서 지나간 경로만 검사 가능 — false negative)를 대비하라.

4. CI 통합의 트레이드오프: 게임서버 CI 파이프라인에 TSan 빌드를 상시 통합할 때 고려할 점을 논하라. 실행 속도 저하(5~15배)로 인한 테스트 시간 증가와 타임아웃 조정, 메모리 사용량 증가로 인한 빌드 에이전트 리소스, "그 테스트 실행 경로에서 레이스가 지나가지 않으면 검출되지 않는다"는 false negative 가능성(커버리지가 낮은 테스트 스위트에서는 한계), 그럼에도 상시 통합이 갖는 가치(회귀 조기 발견)를 정리하라.

5. 결정적 재현을 돕는 기법: 우연히만 재현되는 레이스를 의도적으로 자주/결정적으로 재현시키는 기법을 설명하라.

   • 스케줄 강제: 임계구역 앞뒤에 인위적 지연(sleep/yield)을 넣어 특정 인터리빙을 유도하는 방법, 스트레스 테스트(스레드 수↑, 반복 횟수↑)로 확률을 끌어올리는 방법.
   • 결정적 재현 도구: 레코드&리플레이(스케줄 기록 후 동일 스케줄 재생), 랜덤화된 스케줄러로 시드를 고정해 같은 인터리빙을 재현하는 접근(예: 랜덤 시드 기반 스케줄 퍼징).
   • 로깅 설계: 레이스 진단에 유용한 로그(스레드 ID, 타임스탬프, 접근한 변수/락 상태)를 남기되, 로깅 자체가 타이밍을 바꿔 하이젠버그를 유발하지 않도록 하는 절충(예: 저오버헤드 링버퍼 로깅).

게임서버 개발 관점에서, 위 도구·기법을 어떤 상황에 어떻게 적용할지 실무적으로 정리하라.