버그를 '되감기'해서 똑같이 재현한다 — 결정론적 .NET 런타임 WoofWare.PawPrint

무슨 일이냐면

개발하다 보면 제일 짜증 나는 버그가 뭔지 아세요? 바로 '가끔만 터지는 버그' 예요. 분명히 어제 한 번 봤는데, 오늘 다시 돌려보면 멀쩡하고, 로그를 아무리 봐도 왜 그랬는지 모르겠는 그런 버그요. 이런 걸 보통 '플래키(flaky)한 버그'라고 부르는데, 재현이 안 되니 고치기가 정말 고통스럽죠.

이번에 소개할 WoofWare.PawPrint는 바로 이 문제를 정면으로 노린 프로젝트예요. 한마디로 결정론적(deterministic) .NET 런타임을 만들겠다는 시도인데요. 여기서 "결정론적이 뭐냐면", 똑같은 입력을 주면 항상 한 치의 오차도 없이 똑같은 결과와 똑같은 실행 순서가 나오도록 보장한다는 뜻이에요.

왜 이게 어려운 일일까

"아니 프로그램은 원래 똑같이 돌아가는 거 아냐?" 싶을 텐데, 사실 현대 프로그램은 생각보다 비결정적이에요. 예를 들어볼게요. 여러 스레드가 동시에 돌아가면 누가 먼저 실행될지 매번 달라지고, 현재 시각을 읽거나(DateTime.Now), 난수를 뽑거나, 네트워크 응답을 받거나, 딕셔너리를 순회하는 순서조차 실행할 때마다 미묘하게 바뀔 수 있어요. 이 모든 '예측 불가능한 요소들' 때문에 버그가 어쩌다 한 번씩만 얼굴을 비치는 거죠.

WoofWare.PawPrint은 .NET 프로그램이 실행되는 기반인 IL(중간 언어, Intermediate Language)을 한 명령어씩 직접 해석(interpret)하는 자체 런타임을 만드는 방식으로 이 문제에 접근해요. 무슨 말이냐면, 보통 .NET 코드는 마이크로소프트의 CoreCLR이라는 런타임이 알아서 빠르게 돌려주는데, PawPrint은 그 실행 과정을 자기가 직접 한 발짝씩 통제하겠다는 거예요. 실행의 모든 단계를 자기 손안에 두니까, 스레드 스케줄링이든 시간이든 난수든 전부 정해진 규칙대로 재현 가능하게 만들 수 있는 거죠.

이렇게 실행을 완전히 통제할 수 있으면 엄청난 일이 가능해져요. 바로 시간 여행 디버깅(time-travel debugging) 이에요. 일반 디버거는 코드를 앞으로만 한 줄씩 진행할 수 있지만, 실행이 완벽하게 결정론적이면 버그가 터진 지점에서 시간을 거꾸로 되감아 "이 변수가 대체 언제 잘못된 값으로 바뀐 거지?"를 추적해 들어갈 수 있거든요. 마치 영상 되감기처럼요.

업계 맥락에서 보면

이런 결정론적 실행이라는 아이디어 자체는 새로운 건 아니에요. 마이크로소프트에는 TTD(Time Travel Debugging) 라는 윈도우용 도구가 있고, 리눅스 진영엔 Mozilla가 만든 rr이라는 record-and-replay 디버거가 유명하죠. 게임 업계나 분산 시스템 테스트에서도 결정론적 시뮬레이션은 핵심 기법이에요. 대표적으로 분산 데이터베이스 FoundationDB는 결정론적 시뮬레이션으로 수많은 장애 시나리오를 재현 가능하게 테스트하는 걸로 유명합니다.

WoofWare.PawPrint이 특별한 건, 이걸 .NET 생태계 안에서, IL 인터프리터 수준에서 처음부터 구현한다는 점이에요. 외부 도구로 프로세스를 기록하는 게 아니라 런타임 자체가 결정론적이니, 좀 더 근본적인 통제가 가능한 셈이죠. 물론 명령어를 일일이 해석하는 방식이라 속도는 실제 운영용 런타임보다 훨씬 느릴 수밖에 없어요. 그래서 이건 '빠른 실행'이 목적이 아니라 '분석과 검증, 디버깅'이 목적인 도구로 이해하는 게 맞습니다.

한국 개발자에게 주는 시사점

.NET/C#으로 일하는 분이라면 당장은 실험적인 프로젝트라 운영에 쓰긴 이르지만, '결정론'이라는 개념 자체는 어떤 언어를 쓰든 알아둘 가치가 큽니다. 테스트가 가끔 실패하는 플래키 테스트 때문에 CI가 빨갰다 파랬다 하는 경험, 다들 있잖아요? 그 근본 원인이 바로 코드 어딘가에 숨은 비결정성(시간, 난수, 스레드 순서, 정렬되지 않은 컬렉션 등)이거든요.

그래서 실무 팁을 드리자면, 테스트하기 어려운 부분일수록 시간·난수 같은 비결정적 요소를 코드 바깥으로 빼서(주입받아서) 테스트 때는 고정값을 넣어주는 설계를 习관화하면 좋아요. PawPrint이 런타임 차원에서 하려는 일을, 우리는 설계 차원에서 흉내 낼 수 있는 거죠.

마무리

정리하면, "실행을 완벽히 통제해서 버그를 항상 똑같이 재현하고, 심지어 시간을 되감아 추적하자" 는 야심 찬 .NET 런타임 프로젝트예요. 여러분은 재현 안 되는 버그 때문에 밤새운 경험, 있으신가요? 만약 모든 실행을 되감기할 수 있다면, 디버깅 방식이 어떻게 바뀔 것 같으세요?