UI 최적화 (1) - 캔버스와 리빌드 시스템 - soo:bak

작성일 : 2026년 02월 16일

화면에 항상 있는 UI의 비용

지금까지 시리즈에서는 게임 루프와 렌더링의 기초부터 스크립트와 메모리 관리까지, 게임 전반에 걸친 주제를 다루었습니다.

이제부터는 Unity 개별 서브시스템의 최적화 패턴을 다룹니다. 그 첫 번째가 UI(User Interface) 입니다.

UI를 가장 먼저 다루는 이유는, UI가 게임플레이 내내 지속적으로 화면에 머무는 요소이기 때문입니다.

3D 오브젝트는 카메라 밖으로 나가면 렌더링되지 않고, 파티클은 일시적으로만 존재합니다.

반면 체력바, 미니맵, 채팅창, 인벤토리 버튼 같은 UI 요소는 특별히 숨기지 않는 한 매 프레임 화면 위에 남아 있습니다.

화면에 떠 있는 동안 UI는 매 프레임 렌더링되므로, UI 시스템의 불필요한 연산은 작은 비용이라도 플레이 시간 내내 누적됩니다.

이 글에서는 Unity UI 시스템의 핵심인 Canvas 아키텍처와 리빌드(Rebuild) 시스템을 다룹니다.

Canvas가 UI 요소를 화면에 그려내는 과정을 따라가면서, 그 안에서 어떤 변경이 비용을 발생시키는지 살펴봅니다.

Canvas의 역할

Canvas는 Unity UI 시스템에서 모든 UI 요소의 컨테이너 역할을 합니다. Button, Image, Text 같은 UI 컴포넌트는 Canvas의 자식 오브젝트로 있어야만 화면에 표시됩니다.

Canvas의 두 번째 역할은 렌더링 준비입니다. 화면에 표시되는 모든 UI는 결국 GPU가 그릴 수 있는 형태인 메쉬(Mesh) 로 변환되어야 하는데, 이 변환을 관리하는 것이 바로 Canvas입니다. 변환된 여러 UI 요소의 메쉬를 하나로 모아 GPU에 한꺼번에 제출하는 작업까지 함께 담당합니다.

UI에 어떤 변경이 생기면 이 변환과 제출 과정이 다시 수행될 수 있기 때문에, Canvas는 UI 성능의 출발점이 됩니다.

UI 요소와 메쉬

렌더링 기초 (1) - 메쉬의 구조에서 3D 오브젝트가 정점과 삼각형으로 이루어진 메쉬로 표현된다고 설명했습니다.

UI 역시 같은 원리로 메쉬가 되는데, Image, Text, RawImage 같은 요소는 대부분 평면이므로 내부적으로는 사각형 메쉬의 형태를 띱니다.

하나의 UI Image는 정점 4개와 삼각형 2개로 구성된 사각형 메쉬가 됩니다.

Text는 글자 하나당 하나의 사각형 메쉬를 생성합니다. “Hello”라는 텍스트는 5개의 사각형, 즉 정점 20개와 삼각형 10개로 구성됩니다.

화면에 보이는 실제 UI는 대부분 Image와 Text의 조합입니다. “확인” 버튼 하나만 해도 배경 Image의 정점 4개와 라벨 Text “확인”의 정점 8개(2글자 x 4)가 합쳐져, 총 정점 12개로 그려집니다.

UI가 조금만 복잡해져도 정점 수가 빠르게 불어납니다.

Canvas의 메쉬 생성과 배칭

앞 섹션에서 본 것처럼, Canvas에 속한 각 UI 요소는 자신만의 메쉬를 가집니다. Canvas는 이 개별 메쉬들을 그대로 GPU에 보내지 않고, 일정 조건을 만족하는 요소끼리 하나의 메쉬로 합친 뒤 제출합니다. 이 과정이 배칭(Batching) 이며, 합쳐진 메쉬 하나가 하나의 드로우콜(Draw Call)로 처리되고, 그에 맞춰 SetPass Call의 발생 횟수도 함께 줄어듭니다.

드로우콜은 CPU가 GPU에 렌더링 명령을 보내는 횟수로, 게임 루프의 원리 (2) - CPU-bound와 GPU-bound에서 다루었듯이 값이 커질수록 CPU 부하도 같이 커집니다. SetPass Call은 머티리얼이나 셰이더 상태를 GPU에 설정하는 호출로, 머티리얼이 바뀔 때마다 발생합니다.

Canvas는 같은 머티리얼을 쓰는 UI 요소들을 하나의 메쉬로 묶어 두 호출의 수를 함께 줄입니다. 같은 머티리얼의 UI 요소가 100개일 때 하나씩 따로 그리면 드로우콜은 100회에 이르지만, 배칭이 적용되면 수 회 수준으로 내려갑니다.

Canvas의 배칭은 네 단계를 거쳐 이루어집니다. 먼저 모든 UI 요소의 메쉬 데이터(정점, UV, 색상)를 수집하고, 같은 머티리얼을 쓰는 요소끼리 그룹으로 분류합니다.

그 다음 각 그룹의 메쉬를 하나의 연속된 버퍼로 합친 뒤, 그 버퍼를 GPU에 제출합니다.

이 전체 과정은 CPU에서 수행됩니다.

GPU는 이미 합쳐진 최종 메쉬를 받아서 렌더링만 하고, 메쉬를 수집하고 분류하고 합치는 모든 연산은 CPU의 몫입니다.

리빌드(Rebuild)란

Canvas가 한 번 배칭을 완료하고 GPU에 메쉬를 제출한 뒤, UI에 아무런 변경이 없는 동안에는 추가 작업이 발생하지 않습니다. GPU가 이미 받은 메쉬를 그대로 계속 렌더링하므로, CPU는 다른 작업에 자원을 쓸 수 있습니다.

그러나 Canvas 안의 UI 요소가 하나라도 바뀌면, 바뀐 내용을 반영하기 위해 메쉬를 재생성하고 배칭을 다시 실행해야 합니다.

이 재처리 과정이 리빌드(Rebuild) 입니다.

리빌드는 Canvas 단위로 일어납니다. Canvas 안에 UI 요소가 100개 있고 그중 1개만 바뀌어도, 변경되지 않은 99개까지 포함한 100개 전체의 메쉬가 다시 수집되고 배칭됩니다.

Canvas에 포함된 요소가 많을수록 리빌드 비용도 함께 커집니다. UI 요소 하나의 변경이 Canvas 전체의 CPU 비용을 유발한다는 점이 UI 성능 문제의 핵심입니다.

리빌드를 유발하는 변경들

Canvas의 리빌드를 유발하는 변경은 크게 두 종류로 나뉩니다.

UI 요소의 크기와 위치를 재계산해야 하는 변경과 UI 요소의 시각 표현만 갱신하면 되는 변경이 그것이며, Unity의 Canvas UI 시스템 내부에서는 이 두 종류를 각각 Layout Rebuild와 Visual Rebuild(Graphic Rebuild) 로 구분합니다.

Visual Rebuild는 텍스트 내용 교체, 이미지 스프라이트 변경, Color 프로퍼티 변경처럼 배치는 그대로 둔 채 메쉬의 시각 정보만 갱신하면 되는 경우에 일어납니다.

한편 Layout Rebuild는 RectTransform의 크기 변경처럼 요소 자체의 배치가 달라지는 경우에 트리거됩니다.

두 리빌드가 함께 일어나는 경우도 있는데, SetActive로 요소를 켜거나 끄는 경우, SetSiblingIndex로 Hierarchy 순서를 바꾸는 경우, Canvas 내 UI 요소(Image, Button, Text 등)를 Instantiate로 새로 생성하거나 Destroy로 제거하는 경우가 여기에 해당합니다.

앞에서 나열한 변경들은 UI에서 흔히 수행하는 거의 모든 조작에 해당합니다.

체력바의 숫자가 바뀌는 것, 아이템 아이콘이 교체되는 것, 버프 효과로 아이콘 색상이 변하는 것 모두 Canvas 리빌드의 트리거입니다.

Canvas의 Layout Rebuild

Canvas의 Layout Rebuild는 UI 요소의 크기와 위치를 재계산하는 과정이며, RectTransform 크기(Width, Height) 변경, UI 요소의 활성화/비활성화, Hierarchy 순서 변경, Canvas 내 UI 요소의 생성·제거 등이 이를 유발합니다.

이 재계산은 각 UI 요소의 RectTransform을 대상으로 이뤄집니다.

RectTransform은 모든 UI 요소가 갖는 Transform 컴포넌트로, 위치·크기·앵커 정보를 담고 있습니다. 스크립트가 sizeDelta·anchoredPosition 같은 RectTransform 속성을 변경하거나 요소를 활성화·생성·제거하면, 해당 RectTransform에 “갱신이 필요하다”는 dirty flag가 설정되고 CanvasUpdateRegistry에 등록됩니다.

프레임 끝의 Layout 업데이트 시점에 등록된 dirty RectTransform들만 한꺼번에 재계산되어 새 크기와 위치가 RectTransform에 반영되고, 계산이 끝나면 dirty flag가 해제됩니다.

이렇게 dirty flag로 변경된 요소만 선별하는 방식 덕분에, Unity는 매 프레임 모든 UI 요소를 다시 계산하는 부담 없이 변경이 없는 요소는 그대로 두어 CPU 비용을 아낄 수 있습니다.

LayoutGroup(HorizontalLayoutGroup, VerticalLayoutGroup, GridLayoutGroup)처럼 자식을 자동으로 배치하는 컴포넌트가 붙어 있으면, 그 내부에서 배치 규칙을 재적용하는 추가 재계산이 일어납니다.

이 내부 재계산은 Canvas의 Layout Rebuild와는 구분되는 LayoutGroup 고유의 과정이라 본 글에서는 다루지 않으며, LayoutGroup의 재계산 흐름은 Unity의 Layout Update Cycle에서 다룹니다.

Canvas의 Visual Rebuild (Graphic Rebuild)

Canvas의 Visual Rebuild는 UI 요소의 시각적 표현을 구성하는 메쉬 데이터를 재생성하는 과정입니다.

이 단계에서는 UI 요소가 실제로 어떤 색·글자·그림으로 보일지를 메쉬에 기록합니다.

메쉬 데이터 중 어느 부분을 다시 써야 하는지는 어떤 프로퍼티가 바뀌었는지에 따라 달라집니다.

예를 들어 색상(Color 프로퍼티)이 바뀌면 메쉬에 기록된 정점 색상(Vertex Color) 값만 갱신하면 되고, 스프라이트가 교체되면 새 아틀라스 내 위치가 다르므로 UV 좌표를 다시 계산해야 합니다.

텍스트 내용이 "100"에서 "99"로 바뀌면 글자 수·배치·UV가 전부 달라져 메쉬 자체를 새로 만들어야 하며, Image.Filled 타입의 fillAmount가 바뀌는 경우에도 채워진 영역의 정점이 달라지므로 메쉬 형태를 다시 생성해야 합니다.

변경	재생성이 필요한 데이터
색상 변경 (Color 프로퍼티 변경)	정점 색상 (Vertex Color)
텍스트 내용 변경 (“100” → “99”)	전체 메쉬 재생성 (글자 수, 글자 배치, UV 모두 변경)
스프라이트 교체 (sprite 프로퍼티 변경)	UV 좌표 재계산 (아틀라스 내 위치가 다르므로)
fillAmount 변경 (Image.Filled 타입)	메쉬 형태 재생성 (채워진 영역의 정점 재계산)

네 가지 변경 중 Visual Rebuild 비용이 가장 큰 것은 텍스트 재생성입니다.

색상·스프라이트·fillAmount는 기존 메쉬의 특정 데이터만 고쳐 쓰면 되지만, 텍스트는 내용이 조금만 바뀌어도 글자 수·배치·UV 좌표가 함께 달라지기 때문에 메쉬 전체를 다시 만들어야 합니다.

메쉬를 다시 만들 때는 먼저 텍스트 전체의 커닝(글자 간격)·줄바꿈·정렬을 계산해 각 글자가 놓일 위치를 정한 뒤, 폰트 텍스처에 미리 저장된 각 글자의 픽셀 이미지(이를 글리프(Glyph) 라고 합니다)를 가져와 UV 좌표를 메쉬 데이터에 기록합니다.

결국 텍스트 메쉬 생성은 필요한 글리프를 모아 배치하는 작업이므로, 글리프가 미리 준비되어 있느냐 필요할 때마다 새로 만들어야 하느냐에 따라 텍스트 재생성 비용이 달라집니다.

영어처럼 글자 집합이 작은 언어는 준비 과정이 단순합니다.

대소문자·숫자·기호를 모두 합쳐도 약 100자 수준이므로, 빌드 시점에 모든 글리프를 하나의 폰트 텍스처에 미리 렌더링해두면 런타임에는 텍스처에서 해당 글자의 UV 좌표만 조회해 사용할 수 있습니다.

반면 한글은 조합 가능한 음절이 11,172자(가~힣)에 이르기 때문에 모두 미리 렌더링해 폰트 텍스처에 담아두기 어렵습니다.

그래서 Unity는 한글을 동적 폰트(Dynamic Font), 즉 필요한 글리프를 런타임에 생성하는 방식으로 처리하는 경우가 많습니다.

런타임 생성이 가능한 이유는 폰트 파일이 픽셀 이미지가 아니기 때문입니다.

.ttf나 .otf 파일에는 각 글자가 획의 경계선을 점과 곡선 좌표로 표현한 윤곽선 데이터로 저장되어 있어, 글자를 어떤 크기로도 선명하게 표시할 수 있습니다.

다만 화면이나 텍스처는 결국 픽셀 격자이기 때문에, 윤곽선처럼 벡터 형태로 저장된 데이터를 표시 크기에 맞춰 비트맵으로 옮기는 변환 과정이 필요합니다.

이 변환을 래스터라이즈라고 부르며, 폰트에서는 윤곽선을 해당 크기의 글자 비트맵으로 만드는 과정이 이에 해당합니다.

동적 폰트는 텍스트에 새 글자가 등장하면 그 글자의 윤곽선을 래스터라이즈해 글리프를 만들어 폰트 텍스처 아틀라스에 추가합니다.

한 번 아틀라스에 들어간 글리프는 그대로 남기 때문에, 같은 글자가 다시 등장하면 추가 비용 없이 재사용됩니다.

다만 아틀라스의 크기는 유한해서, 새 글자가 계속 등장해 빈 공간이 부족해지면 Unity는 더 큰 텍스처를 새로 만들고 기존 글리프를 전부 다시 배치해야 합니다. 이 재배치는 아틀라스 전체를 다시 구성하는 작업이므로, 글리프 하나를 추가할 때보다 비용이 큽니다.

데미지 숫자·점수 표시·채팅 메시지처럼 내용이 매 프레임 바뀌는 UI에서는 Visual Rebuild가 매번 일어나고, 거기에 추가로 드는 비용은 글자와 아틀라스 상태에 따라 달라집니다.

표시할 글자가 모두 아틀라스에 있다면 Visual Rebuild만 일어나고, 아틀라스에 없는 새 글자가 포함되면 그 글자를 래스터라이즈해 아틀라스에 추가하는 비용이 더해지며, 새 글자가 누적되어 아틀라스 용량을 넘어서면 아틀라스 전체를 다시 구성하는 재배치 비용까지 추가됩니다.

Layout Rebuild와 Visual Rebuild의 실행 순서

Layout Rebuild와 Visual Rebuild가 모두 필요한 프레임에서, 두 리빌드는 Layout Rebuild가 먼저, Visual Rebuild가 나중에 실행됩니다.

이는 Visual Rebuild가 메쉬를 생성할 때 해당 요소의 최종 크기와 위치가 확정되어 있어야 하기 때문입니다.

예를 들어 Text는 텍스트 영역의 너비를 알아야 줄바꿈을 결정할 수 있고, Image는 이미지의 크기를 알아야 정점 좌표를 계산할 수 있습니다.

따라서 Layout Rebuild가 크기와 위치를 먼저 확정하고, Visual Rebuild가 이 정보를 기반으로 메쉬를 생성합니다.

Canvas 단위 리빌드의 비용

Canvas의 리빌드 비용은 그 안에 포함된 UI 요소 수에 비례합니다.

이는 Canvas가 속한 모든 UI 요소를 함께 배칭하기 때문입니다. 요소 하나만 바뀌어도 배치 그룹 분류나 정점 오프셋이 달라져, 모든 요소가 다시 배칭됩니다.

다이어그램처럼 요소 2 하나만 변경되어도 100개 요소 전체가 재배칭됩니다. Canvas는 변경의 영향 범위를 요소별로 추적하지 않기 때문입니다.

Canvas의 배칭 규칙

Canvas 리빌드의 비용은 요소 수에 비례하는데, 리빌드 결과 GPU에 제출되는 드로우콜의 수는 Canvas의 배칭이 얼마나 이루어지느냐에 달려 있습니다.

Canvas 배칭이 가능하려면 같은 머티리얼을 사용하면서 Hierarchy 순서상 연속해야 합니다. 이 조건을 충족하지 못하면 배치가 나뉘어 드로우콜이 늘어납니다.

같은 머티리얼

Canvas 배칭은 같은 머티리얼(Material)을 사용하는 요소끼리만 합칠 수 있습니다.

하나의 드로우콜은 하나의 렌더링 상태(셰이더 + 텍스처 조합)로 처리되므로, 머티리얼이 다르면 별도의 드로우콜로 나뉩니다.

다만 Unity UI에서는 대부분의 요소가 기본 UI 셰이더를 공유하므로, 배칭 가능 여부는 실질적으로 같은 텍스처를 사용하는지에 따라 결정됩니다.

즉, 서로 다른 스프라이트라도 같은 텍스처 아틀라스(Sprite Atlas) 에 속해 있으면 하나의 텍스처를 공유하므로 같은 배치로 합쳐질 수 있습니다.

아틀라스로 묶지 않은 스프라이트는 각각 별도의 텍스처이므로 배칭되지 않으며, Text 요소 역시 폰트 텍스처를 사용하므로 Image 요소와는 같은 배치로 합쳐지지 않습니다.

Hierarchy 순서와 깊이

같은 머티리얼을 사용하더라도, 요소들이 렌더링 순서상 연속해 있어야 하나의 배치로 합쳐질 수 있습니다.

Unity UI는 Hierarchy를 깊이 우선(depth-first) 으로 순회하여 기본 렌더링 순서를 결정합니다.

부모가 먼저 그려지고 자식들이 순서대로 그려진 뒤 다음 형제로 넘어가므로, Hierarchy 순서가 렌더링 순서의 기준이 됩니다.

예를 들어 같은 머티리얼의 요소 A와 C 사이에 다른 머티리얼의 요소 B가 있고, 이 요소들이 화면상에서 겹치면 렌더링 순서를 바꿀 수 없으므로 A와 C는 별도의 배치로 나뉘는데, 이 현상을 배치 브레이킹(Batch Breaking)이라고 합니다.

다이어그램처럼 A와 C를 Hierarchy에서 연속으로 배치하면 같은 배치로 합쳐져 드로우콜이 3회에서 2회로 줄어듭니다.

다만 실제 UI에서는 수십 개의 요소가 복잡하게 겹치므로 배치 브레이킹이 빈번하게 발생합니다.

화면상의 겹침(Overlap)

배치 브레이킹의 핵심 조건은 화면상의 겹침입니다.

화면에서 서로 겹치지 않는 요소끼리는 Hierarchy 순서를 바꿔도 시각적 결과가 같습니다. 그래서 다른 머티리얼의 요소가 사이에 있더라도, Unity는 순서를 재배치해 배칭할 수 있고 배치 브레이킹은 발생하지 않습니다.

반면 화면상에서 겹치는 요소는 앞뒤 관계가 시각적 결과를 결정하므로, Hierarchy 순서대로 그려야 합니다. 따라서 다른 머티리얼의 요소가 사이에 있으면, Unity는 그 순서를 따르기 위해 배치를 나눕니다.

리빌드 비용의 구성

Canvas의 리빌드 비용은 세 단계로 구성됩니다.

Canvas의 리빌드 비용은 Canvas 내 요소의 수와 변경 빈도가 결정합니다.

요소가 많은 Canvas에서 매 프레임 변경이 일어나면 두 요인이 함께 커지므로, UI 프레임 저하의 흔한 원인이 됩니다.

마무리

UI 요소(Image, Text 등)는 내부적으로 사각형 메쉬(정점 4개, 삼각형 2개)로 표현되며, Canvas는 이 메쉬들을 배칭하여 GPU에 제출합니다.
Canvas 내 UI 요소 하나라도 변경되면, 해당 요소의 Layout Rebuild(크기/위치)와 Visual Rebuild(메쉬/색상/UV) 이후 Canvas 전체의 재배칭이 발생합니다.
배칭은 같은 텍스처를 사용하고 렌더링 순서상 연속해 있는 요소끼리 동작하며, 겹치는 요소 사이에 머티리얼이 다른 요소가 있으면 배치가 나뉘어 드로우콜이 증가합니다.
리빌드 비용은 Canvas 내 요소 수와 변경 빈도에 비례합니다.

UI 변경이 발생하는 프레임마다 이 비용이 반복되므로, Canvas의 리빌드 구조를 이해하는 것이 UI 최적화의 출발점입니다.

이 글에서는 Canvas가 UI를 어떻게 그리는지, 어떤 변경이 비용을 발생시키는지 정리했습니다.

Part 2에서는 Canvas 분리 전략, ScrollRect 풀링, TextMeshPro 활용, 오버드로우 최소화 등 실전에서 적용할 수 있는 UI 최적화 기법을 다룹니다.

관련 글

Unity의 Layout Update Cycle

시리즈

UI 최적화 (1) - 캔버스와 리빌드 시스템 (현재 글)
UI 최적화 (2) - UI 최적화 전략

전체 시리즈