Unity에서 ScriptableObject를 처음 배울 때 가장 흔한 오해는 “데이터를 에셋으로 빼면 구조가 좋아진다”는 식으로 너무 빨리 결론을 내리는 것입니다. ScriptableObject는 분명 유용하지만, 아무 값이나 에셋으로 분리하면 오히려 프로젝트가 더 복잡해집니다.
먼저 구분해야 할 것은 “데이터냐 코드냐”가 아니라 무엇이 자주 바뀌고, 무엇이 규칙으로 고정되어야 하는가입니다.
1. 자주 바뀌는 값과 규칙을 분리합니다
예를 들어 아이템을 만든다고 해 보겠습니다. 이름, 설명, 아이콘, 가격, 최대 보유 수량은 기획 과정에서 자주 바뀔 수 있습니다. 이런 값은 ScriptableObject로 분리하기 좋습니다.
반대로 “소모품을 사용하면 인벤토리 수량이 줄어든다”, “장비 아이템은 장착 슬롯이 필요하다” 같은 동작 규칙은 단순 데이터가 아니라 시스템의 책임입니다. 이런 규칙까지 ScriptableObject 안에 섞어 넣으면 에셋 하나가 데이터와 로직을 동시에 떠안게 됩니다.
2. Inspector에서 편집하기 쉬운 값만 먼저 뺍니다
ScriptableObject의 장점은 Inspector에서 데이터를 보고 수정하기 쉽다는 점입니다. 따라서 처음에는 디자이너나 개발자가 직접 비교하고 조정할 값부터 분리하는 편이 안전합니다.
- 캐릭터 기본 능력치
- 아이템 이름, 설명, 아이콘
- 스킬 쿨타임과 비용
- 적 캐릭터의 이동 속도와 감지 거리
- 대화 선택지의 표시 문장
반대로 런타임 중 계속 바뀌는 현재 HP, 현재 경험치, 현재 인벤토리 수량 같은 값은 주의해야 합니다. 원본 ScriptableObject 에셋을 직접 변경하면 Play Mode가 끝난 뒤에도 값이 남거나, 여러 오브젝트가 같은 상태를 공유하는 문제가 생길 수 있습니다.
3. “원본 데이터”와 “런타임 상태”를 나눕니다
ScriptableObject는 원본 정의에 가깝게 쓰는 편이 안정적입니다.
- ScriptableObject: 아이템의 이름, 아이콘, 기본 가격
- 런타임 객체: 현재 수량, 강화 단계, 소유자, 사용 여부
이 구분을 해두면 같은 아이템 정의를 여러 캐릭터가 참조해도, 각 캐릭터의 실제 상태는 따로 관리할 수 있습니다. 작은 프로젝트에서는 차이가 잘 보이지 않지만, 아이템이나 스킬 수가 늘어나면 이 구분이 유지보수 난이도를 크게 좌우합니다.
4. ScriptableObject가 해결하지 않는 문제도 있습니다
ScriptableObject를 쓰면 데이터 관리가 쉬워질 수 있지만, 모든 구조 문제가 자동으로 해결되지는 않습니다.
- 데이터 참조 관계가 너무 복잡하면 여전히 추적하기 어렵습니다.
- 런타임 상태를 에셋에 저장하면 예측하기 어려운 버그가 생깁니다.
- 이벤트 흐름과 시스템 책임이 흐리면 에셋 수만 늘어납니다.
- 폴더와 네이밍 규칙이 없으면 Inspector에서 찾기 어려워집니다.
그래서 ScriptableObject를 도입할 때는 “어떤 값을 에셋으로 만들 것인가”보다 “이 값은 누가 읽고, 언제 바뀌며, 런타임 상태와 어떻게 분리되는가”를 먼저 정하는 편이 좋습니다.
정리
ScriptableObject를 잘 쓰기 위한 첫 기준은 다음 세 가지입니다.
- 자주 바뀌는 설정값과 고정된 동작 규칙을 나눕니다.
- Inspector에서 비교하고 조정할 가치가 있는 값부터 분리합니다.
- 원본 데이터와 런타임 상태를 같은 에셋에 섞지 않습니다.
이 기준만 지켜도 ScriptableObject는 단순한 “데이터 에셋”을 넘어, 프로젝트 구조를 정리하는 좋은 출발점이 됩니다.
이 주제를 더 체계적으로 정리한 전자책도 준비되어 있습니다. 먼저 무료 맛보기판으로 전체 흐름이 맞는지 확인할 수 있습니다.
