항상 기록하고, 필요할 때만 남긴다 — 게임 버그 캡처의 롤링 버퍼 접근

Unity 버그 리포트 3부작 — ① 재현이 실패하는 이유 · ② 항상 기록하는 접근 · ③ Unity 최소 구현

앞 글의 결론은 이랬습니다. 버그를 인지한 시점은 이미 버그가 발생한 다음이고, 그래서 녹화 버튼은 항상 늦게 눌린다. 필요한 건 t-30초 구간인데 그때는 아무도 녹화 중이 아니다.

여기서 나오는 요구사항은 하나입니다. 모든 플레이 세션이 항상 기록되고 있어야 한다. 문제는 그걸 실제로 어떻게 돌리느냐입니다. 매 세션을 통째로 디스크에 쓰는 건 QA PC에서도 부담이고, 그렇게 쌓인 영상 중 실제로 열어보는 건 극소수입니다.

세 가지 접근

게임에서 "그 순간을 되돌려 보는" 방법은 대체로 셋입니다.

결정적 리플레이는 재현율이 가장 높습니다. 입력만 다시 흘리면 같은 상황이 나오니까요. 대신 대가가 큽니다. 난수 시드, 물리 스텝, 네트워크 응답 순서까지 전부 결정적으로 만들어야 하고, 이건 프로젝트 초기에 구조를 잡지 않으면 나중에 얹기 어렵습니다. 서드파티 에셋 하나가 Random을 자체적으로 쓰면 거기서 어긋납니다.

상태 스냅샷은 가볍고 붙이기 쉽습니다. 대신 발생 이후의 한 시점만 남습니다. 앞 글의 t-30초 구간, 즉 "거기까지 어떻게 갔는가"가 통째로 빠집니다. 조건 유실 문제는 일부 메우지만 타이밍 문제는 손대지 못합니다.

롤링 버퍼는 OBS의 리플레이 버퍼와 같은 개념입니다. 재현율은 결정적 리플레이에 못 미치지만, 프로젝트 구조를 요구하지 않으면서 t-30초 구간을 확보합니다. 게임 클라이언트에 나중에 붙이기에는 이쪽이 가장 무난합니다.

롤링 버퍼가 하는 일

동작은 단순합니다.

• 플레이 중 최근 N초를 메모리에서 계속 덮어쓰며 유지한다
• 버그를 목격하면 그 시점에 버퍼를 디스크로 확정한다
• 영상·로그·게임 상태·성능 지표를 같은 타임라인에 정렬해 함께 남긴다

제목의 "필요할 때만 남긴다"가 두 번째 항목입니다. 기록은 항상 돌지만 디스크 쓰기는 확정 시점에만 일어납니다. 링 버퍼는 용량이 고정이라 몇 시간을 플레이해도 메모리 사용량이 늘지 않고, 확정하지 않은 구간은 그냥 덮여 사라집니다. 열어보지 않을 영상 수백 개가 쌓이는 문제가 여기서 없어집니다.

N을 얼마로 잡을지는 버그 종류에 달렸습니다. 프레임 경합이나 UI 오작동처럼 직전 맥락만 필요한 버그는 15~30초로 충분하고, 퀘스트 상태나 인벤토리 누적처럼 원인이 먼 버그는 60초 이상이 필요합니다. 실무에서는 기본값을 30초쯤 두고 프로젝트가 겪는 버그 성격에 맞춰 조정하는 편이 낫습니다.

핵심은 같은 시간축

세 항목 중 실제로 진단 속도를 바꾸는 건 마지막입니다.

영상만 있으면 "무엇을 했는지"는 알 수 있지만 "내부에서 무슨 일이 있었는지"는 모릅니다. 로그만 있으면 예외는 보이는데 그때 화면이 어땠는지 모릅니다. 둘이 따로 있으면 개발자가 머릿속에서 맞춰야 하고, 그 맞추는 작업이 곧 "재현해 보기"입니다.

같은 시간축에 정렬돼 있으면 질문의 성격이 달라집니다.

• 화면이 멈춘 그 프레임에 어떤 예외가 났는가
• 프레임 스파이크 직전에 GC가 돌았는가, 아니면 로딩이 걸렸는가
• UI가 깨진 시점의 인벤토리 개수는 몇 개였는가

전부 "영상 재생 위치를 옮기면 나머지가 따라오는" 형태로 답이 나옵니다. 개발자는 절차를 상상하는 대신 그 순간을 다시 봅니다.

이렇게 되면 티켓의 성격도 바뀝니다. 재현 절차를 글로 옮기면서 잃던 정보가 애초에 글을 거치지 않습니다.

저희가 Rekon을 만들면서 잡은 방향이 정확히 이것입니다. Unity 플레이 모드에서 항상 롤링 버퍼를 돌리고, 핫키 한 번에 직전 구간의 영상·스크린샷·로그·게임 상태를 한 묶음으로 남깁니다. 다만 이 글에서 하고 싶은 이야기는 특정 도구가 아니라 "버그 리포트는 작성하는 것이 아니라 남는 것이어야 한다"는 쪽에 가깝습니다.

접근을 정했다면 다음은 구현입니다. 마지막 글에서 Unity 프로젝트에 로그와 게임 상태 캡처를 붙이는 최소 코드를 다룹니다.