게임 화면에 보이는 화려한 그래픽 뒤에는 보이지 않는 조율자가 있어요. 바로 리소스 매니저입니다. 텍스처나 사운드 같은 자산은 제멋대로 메모리에 올라오지 않아요. 매니저의 관리 아래 필요할 때만 로드됩니다.
쓰임이 끝나면 정리하는 역할도 이 친구가 맡고 있죠. 이 역할이 없다면 메모리가 금방 낭비될 거예요. 불필요한 자산이 성능을 갉아먹는 일도 생깁니다. 효율적인 게임을 위해 꼭 필요한 존재랍니다.
리소스 매니저의 진짜 역할
이 시스템은 파일만 여는 도구가 아닙니다. 오프라인 작업부터 실행 단계까지 모두 아우르는 개념이에요. 리소스는 엔진이 바로 쓸 수 있는 상태가 아닙니다. 아티스트가 만든 데이터는 변환 과정을 거쳐야 해요.
변환된 데이터는 엔진 전용 포맷이 됩니다. 게임이 실행되면 런타임 매니저가 이를 읽어오죠. 그리고 실제 게임 시스템이 쓰도록 연결해 줍니다. 처음 접하면 과정이 조금 복잡해 보일 수 있어요.
고유 식별자로 중복 방지하기
수많은 자산을 섞이지 않게 관리해야 합니다. 그래서 대부분 GUID라는 고유 식별자를 사용해요. 파일 경로일 수도 있고 해싱된 값일 수도 있습니다. 중요한 건 유일하게 식별된다는 기준이죠.
덕분에 엔진은 중복 로드를 막을 수 있습니다. 이미 메모리에 있는지 빠르게 확인이 가능해요. 이 과정에는 레지스트리라는 목록이 쓰입니다. GUID와 실제 객체의 짝을 맞춰둔 장부 같은 거예요.
어떤 시스템이 리소스를 요청하면 장부를 먼저 봅니다. 이미 있다면 바로 내어주고 없다면 새로 불러와요. 이렇게 하면 접근 속도가 아주 안정적으로 유지됩니다. 프로그래머 입장에서도 관리가 편해지죠.
로딩 시점 결정하기
리소스를 언제 불러올지도 아주 중요합니다. 필요할 때 자동으로 불러오면 편할 것 같나요? 하지만 플레이 도중에 로딩하면 화면이 끊길 수 있어요. 프레임 드랍이 생기면 게임 몰입이 깨지죠.
그래서 많은 게임이 미리 로드하는 방식을 씁니다. 레벨이 시작되거나 특정 구간에 들어가기 전에 준비해요. 플레이어가 눈치채지 못하게 미리 챙겨두는 겁니다. 아주 영리한 전략이죠.
복합 리소스와 의존성
리소스는 혼자 독립적으로 존재하지 않아요. 메시에는 머티리얼이 필요합니다. 머티리얼에는 다시 여러 텍스처가 붙어 있죠. 서로 꼬리에 꼬리를 무는 의존 관계입니다.
엔진은 이걸 복합 리소스로 다룹니다. 상위 데이터를 부르면 하위 데이터도 같이 딸려와요. 이 연결이 끊기면 화면에 구멍이 뚫릴 수도 있습니다. 그래서 참조 관계를 정확히 잇는 게 중요해요.
메모리 관리와 스트리밍
다 쓴 리소스는 언제 정리할까요? 계속 메모리에 두면 용량이 부족해집니다. 이때 참조 카운팅이라는 방법을 자주 써요. 사용 중인 곳이 없으면 카운트가 0이 됩니다.
0이 된 리소스는 언로드 대상이 되어 사라지죠. 월드가 아주 큰 게임이라면 스트리밍 기술도 필요해요. 한 번에 다 못 부르니 필요한 것만 조금씩 가져옵니다. 이때 우선순위를 잘 정해야 끊김이 없어요.
패키지 파일로 묶어서 관리하기
마지막으로 파일 저장 방식을 살펴볼게요. 보통은 엔진 전용 바이너리 포맷으로 만듭니다. 그리고 여러 개를 하나의 패키지로 묶어버려요. 낱개로 두는 것보다 디스크 읽는 속도가 훨씬 빠르거든요.
리소스 매니저는 이 패키지를 해석해서 데이터를 꺼냅니다. 보안 관리나 무결성 확인도 더 쉬워지죠. 이렇게 리소스 매니저는 게임의 성능과 경험을 책임집니다. 보이지 않는 곳에서 정말 많은 일을 하고 있죠?
