배칭이 왜 끊겼는지는 화면이 알려준다

최적화 글을 읽다 보면 “머티리얼을 통일하세요”, “레이어를 줄이세요” 같은 처방이 줄줄이 나옵니다. 전부 맞는 말인데, 내 프로젝트에서 지금 무엇이 문제인지는 안 알려 줍니다.

그건 화면에 이미 나와 있습니다. 열어 보면 됩니다.

Frame Debugger

Window > Analysis > Frame Debugger 에서 Enable 을 누르면 한 프레임이 멈추고, 그 프레임에 나간 드로우 콜이 순서대로 나열됩니다. 항목을 하나씩 밟으면 화면이 그 시점까지만 그려진 상태로 보입니다. 무엇이 언제 그려지는지가 그대로 보입니다.

여기서 중요한 것은 그림이 아니라 각 항목에 붙는 사유 문장입니다. 배치가 왜 여기서 끊겼는지를 Unity 가 적어 줍니다.

마지막 줄이 2D 에서 제일 자주 걸립니다. 나무, 플레이어, 나무, 적 순서로 깊이가 번갈아 나오면 반투명 순서를 지키기 위해 배치가 강제로 끊깁니다. 머티리얼도 같고 텍스처도 같은데 끊깁니다. 이건 에셋 문제가 아니라 배치 문제라, 스프라이트를 아무리 합쳐도 안 풀립니다.

Frame Debugger 를 켜면 게임이 멈춥니다. 특정 순간을 잡고 싶으면 그 순간에 스크립트로 Time.timeScale = 0 을 걸어 두고 켜는 편이 편합니다.

Memory Profiler 는 반드시 실기에

Window > Analysis > Memory Profiler 로 스냅샷을 뜨면 텍스처와 아틀라스가 실제로 메모리를 얼마나 먹고 있는지 나옵니다. 아틀라스를 다시 묶었을 때 정말 줄었는지를 확인할 수 있는 유일한 자리입니다.

여기에 함정이 하나 있습니다. 에디터에 붙여서 뜬 스냅샷은 믿으면 안 됩니다.

에디터는 아틀라스에 들어간 개별 텍스처를 따로 들고 있는 경우가 있고, 플랫폼별 압축 설정도 빌드와 다르게 적용됩니다. 그래서 에디터에서는 “아틀라스로 묶었는데 메모리가 안 줄었다” 는 결과가 나오기 쉽습니다. 빌드해서 실기에 붙이면 다른 숫자가 나옵니다.

같은 이유로, 아틀라스 그루핑을 바꿨으면 바꾸기 전후를 둘 다 실기에서 떠야 비교가 됩니다. 한쪽만 실기에서 뜨면 아무 말도 못 합니다.

2D Light Batching Debugger

2D 라이트를 여러 개 쓰면 라이트 조합에 따라 렌더 배치가 나뉩니다. 어떤 조합이 배치를 깨는지를 시각화해 주는 것이 이 도구입니다.

표시되는 숫자는 개수가 아니라 배치 인덱스입니다. 0 만 보이면 전부 한 배치이고, 0 과 1 이 섞여 보이면 그만큼 나뉜 것입니다. 이걸 라이트 개수로 읽으면 반대로 해석하게 됩니다.

Sprite Atlas Analyzer

Unity 6.3 부터 들어온 정적 분석 도구입니다. 게임을 돌릴 필요가 없습니다. 아틀라스를 훑어서 이중 압축, 페이지 분할, 빈 공간 낭비를 찾아 줍니다.

정기적으로 돌리는 편이 좋습니다. 이 세 가지는 한 번 잡아도 다시 생깁니다. 스프라이트를 몇 장 추가했더니 아틀라스가 페이지로 쪼개지는 식이라, 사람이 기억해서 막을 수 있는 종류가 아닙니다.

순서

도구가 넷이지만 보는 순서는 정해져 있습니다.

1. Stats 창 으로 드로우 콜과 SetPass Call 을 같이 봅니다. 어느 축이 문제인지부터 정합니다
2. CPU 쪽이면 Frame Debugger 로 배치가 끊긴 상위 몇 지점과 사유를 적습니다
3. 사유가 텍스처나 머티리얼 쪽이면 Sprite Atlas Analyzer 와 임포트 설정으로 갑니다
4. 라이트 쪽이면 Light Batching Debugger 로 인덱스를 봅니다
5. 메모리가 의심되면 Memory Profiler, 단 실기 빌드에

이 순서를 건너뛰고 처방부터 적용하면, 고쳐도 숫자가 왜 안 움직이는지를 모르게 됩니다. 그리고 안 움직이는 이유가 “처방이 틀려서” 가 아니라 “애초에 그게 병목이 아니어서” 인 경우가 대부분입니다.