⏱ 1 min read

Blitter 중복 초기화 에러 대응

Android에서 일 137,080건 발생하던 Blitter 중복 초기화 에러를 2단계 가설 검증으로 근본 원인까지 추적·수정

Problem

개요

Android 환경에서 아래와 같은 URP 관련 에러 로그가 대량 수집되어 원인 추정 및 방어 코드 적용을 진행했다.

Exception: Blitter is already initialized. Please only initialize the blitter once or you will leak engine resources. If you need to re-initialize the blitter with different shaders destroy & recreate it.

스택 상으로는 UniversalRenderPipeline 생성 과정에서 Blitter.Initialize()가 중복 호출되며 발생하는 형태로 보인다.

집계 건수: AOS 137,080건
관측 환경: Android 중심
참고: GLES 환경에서도 유사 이슈가 Unity Issue Tracker에 등록되어 있음

Approach

가설 검증 사이클을 두 단계로 진행 — 각 단계마다 로그 감소량으로 효과 측정.

단계	가설	검증 방법
1차	그래픽 옵션 적용 시 URP Asset 속성 재대입이 파이프라인 재생성을 유도	동일 값 재적용 방지 가드 → Kibana 모니터링
2차	매 프레임 호출되는 코드 경로에 URP Asset setter가 있다	코드베이스 setter 호출 지점 전수 조사

근본 원인을 한 번에 단정하기보다, 가설별로 가드를 추가하고 로그 변화를 측정해 점진적으로 좁혀나가는 방식 채택. 재현 불가 상황에서 가장 현실적인 접근.

Implementation

01
1차 수정 — GraphicOptionAssets.ApplyURPSettings() 가드
옵션 적용 시점에서 URP Asset 속성이 동일 값으로 재대입되는 것을 차단.

결과: 137,080건 → 2,978건 (−98%) — 효과 확인되었으나 잔존 에러 존재.
02
2차 수정 — 매 프레임 호출 경로의 setter 추적
잔존 2,978건의 원인을 찾기 위해 코드베이스에서 URP Asset setter 호출 지점을 전수 조사한 결과, MaterialGlobalPropertiesFeature.AddRenderPasses() 가 매 프레임 shadowDistance setter를 호출하고 있었음.

Android는 디바이스 재개·포커스 변경 등으로 GraphicsDevice가 빈번히 리셋되어 에러 빈도가 더 높게 나타난 것으로 추정.

Validation

사이드 이펙트 검증 매트릭스

항목	검증 결과
`shadowDistance` 사용처	코드베이스에서 `MaterialGlobalPropertiesFeature.cs`가 유일하게 변경 → 충돌 없음
ShadowVolume on/off 동치성	첫 프레임 적용, 이후 스킵 → 결과 동일
ShadowVolume 값 변경 시	값 바뀐 프레임만 적용 → 결과 동일
Volume on→off 전환	다음 프레임 100 적용 → 결과 동일
외부 임의 변경 시 덮어쓰기	다음 프레임 덮어씀 → 결과 동일
`Mathf.Approximately` 정밀도	100f 기준 epsilon 0.0001 → 셰도우 거리에 충분
NaN 입력	`Approximately(NaN, NaN) == false` → setter 호출 (안전한 fallback)
결정론적 시뮬레이션 영향	비주얼 전용 코드 → 무관
비용	getter 1 + 비교 1, setter 비용 대비 무시 가능

모니터링 지표: Kibana globalManagerException 메시지가 시간당 0건에 수렴하는지 추적.

기기 검증: Vivo Y11, Galaxy A12, S9, S21에서 그래픽 옵션 변경 포함 시나리오 테스트 → 사이드 이펙트 없음.

Note — 향후 가이드라인

URPAsset 속성을 런타임에 변경할 때 주의사항: 1. AddRenderPasses / Update / LateUpdate 등 매 프레임 호출되는 메서드에서 URPAsset 속성을 직접 변경하지 말 것. 2. 부득이한 경우 반드시 변경 감지 후에만 setter 호출. 3. 더 근본적으로, 매 프레임 변경되는 값은 URPAsset 속성이 아닌 Shader Property / GlobalConstantBuffer로 처리하는 것이 정석. URPAsset.setter는 RenderPipeline dirty 플래그를 건드려 재생성을 유발하므로 "데이터 채널"이 아닌 "구성 변경 채널"로만 사용해야 함.

Conclusion

로컬 재현이 불가능한 production-only 이슈를 가설 기반 점진 수정 + 로그 모니터링으로 추적한 사례. 1차 수정은 가시적 가설을 빠르게 검증해 98% 감소를 확보했고, 잔존 로그가 2차 근본 원인 추적의 단서가 되었다. URP 내부 속성 setter가 dirty 플래그를 트리거한다는 동작 특성은 이번 추적으로 명확해졌으며, 동일한 패턴이 다른 RendererFeature·런타임 코드에 잠재할 수 있어 가이드라인으로 남겨 재발을 방지했다.