오늘의 학습 키워드
1. Json vs ScriptableObject
오늘은 Unity에서 아이템 데이터를 어떻게 관리할지에 대해 고민하다가, 대표적인 두 가지 방법인 ScriptableObject와 JSON 방식의 차이를 정리해 보았다.
ScriptableObject 방식
ScriptableObject는 Unity에서 제공하는 데이터 컨테이너 타입으로, 에디터에서 데이터를 관리하기에 매우 직관적이다.
몬스터, 아이템, 캐릭터 능력치 등 게임 내 자주 쓰이는 고정 데이터를 관리할 때 자주 사용된다.
장점
- 에디터에서 직접 수정 가능해 빠른 개발 및 디버깅에 유리
- Unity 직렬화 시스템과 연동되어 빌드 시 자동 포함
- 코드 기반이므로 타입 안정성이 높고, 실수로 인한 오류 발생 가능성이 낮음
단점
- 데이터가 에셋으로 포함되어 있어 참조가 존재하면 게임 시작 시 메모리에 자동 로드됨
- Addressables 등을 사용하지 않으면 불필요한 데이터까지 메모리에 올라갈 수 있음
- 런타임 중 동적으로 데이터를 추가하거나 변경하는 데 제약이 있음
JSON 방식
JSON은 텍스트 기반의 데이터 포맷으로, Unity에서는 JsonUtility 또는 Newtonsoft.Json 등을 이용해 파싱하여 사용할 수 있다.
외부 툴(엑셀, 구글시트 등)과의 연동이나 업데이트가 유리해 대규모 데이터 관리에 적합하다.
장점
- 런타임 시점에 필요한 데이터만 로드하므로 메모리 효율이 높음
- 외부에서 데이터 수정을 자동화하거나 업데이트하기 쉬움
- 유연한 구조로 서버와의 통신이나 패치 시스템에도 적합
단점
- 파싱 비용이 존재하여 로딩 시 딜레이가 발생할 수 있음
- JSON 구조가 잘못되면 런타임에서 에러가 발생하며, 컴파일 시 확인이 어려움
- 에디터에서 직접 편집하기 어렵고 유지보수에 주의가 필요함
메모리 및 구조적 차이
| 비교항목 | ScriptableObject | JSON |
| 메모리 사용 | 초기부터 메모리에 상주 | 필요할 때 로드 |
| 타입 안정성 | 높음 (컴파일 시 검증) | 낮음 (런타임 에러 발생 가능) |
| 외부 툴 연동 | 제한적 | 유연함 |
| 로딩 속도 | 빠름 | 파싱 시간 필요 |
| 데이터 수정 편의성 | 에디터에서 쉬움 | 파일 직접 수정 필요 |
정리
결론적으로 ScriptableObject와 JSON은 각각의 용도에 맞게 선택하는 것이 중요하다.
- 데이터의 양이 적고, 수정이 자주 필요하며 에디터 기반의 직관성이 필요한 경우에는 ScriptableObject가 적합하다.
- 아이템 수가 많거나, 외부 툴로 데이터를 관리하거나, 동적 로딩이 필요한 경우에는 JSON 방식이 더 유리하다.
상황에 따라 두 방식을 혼합해서 사용하는 것도 좋은 선택이다. 예를 들어, 핵심 아이템 정보는 ScriptableObject로, 외부에서 주기적으로 업데이트되는 이벤트 정보는 JSON으로 관리하는 식이다.
오늘 정리한 내용을 기반으로 앞으로 프로젝트에 더 유연하고 확장성 있는 구조를 설계할 수 있을 것 같다.