유니티 스크립터블 오브젝트로 협업 갈등을 해결한 이야기

“씬을 여는 데 30초 넘게 걸려요.”
“아까 고친 수치가 또 초기화됐어요.”
“충돌은 없었는데, 누가 체력을 500으로 바꿨어요?”

이런 말, Unity 프로젝트에서 한 번쯤 들어보신 적 있지 않나요?
오늘은 실제 Unity 팀에서 있었던 씬 최적화와 협업 개선 사례를 바탕으로, 스크립터블 오브젝트를 통해 어떻게 문제를 해결했는지를 이야기 형식으로 풀어보려고 합니다.

프로젝트가 커질수록 커지는 ‘씬의 부담감’

‘플레이잇’이라는 이름의 소규모 Unity 게임 팀이 있었습니다.
이 팀은 Project Rune이라는 RPG 게임을 만들고 있었죠.

처음에는 씬에 필요한 것들을 다 넣고, 프리팹에 데이터도 몽땅 저장해두는 게 편했어요.
몬스터의 능력치, 아이템 정보, 각종 UI 설정까지 – 전부 프리팹에 포함돼 있었습니다.

그런데 프로젝트가 커지기 시작하면서 문제가 생겼습니다.

• 씬을 열면 로딩에 20~30초 이상 걸리는 일상
• 프리팹 저장 시간이 길어지고
• 팀원 간 작업 충돌도 점점 늘어나기 시작한 거죠

“어…? 체력이 왜 500으로 바뀌었지?”

어느 날, 디자이너 유진은 몬스터의 외형을 조금 다듬고, 위치를 조정한 뒤 씬을 저장했습니다.
같은 날, 프로그래머 준수는 해당 몬스터의 전투 밸런스를 조정하며 체력을 300으로 수정해 두었습니다.

그런데 다음날 열어본 몬스터의 체력은… 500이었습니다.

• “유진님, 혹시 몬스터 체력도 바꾸셨어요?”
• “어? 아니요. 저는 위치만 바꿨는데요?”

이런 일이 반복되자, 팀원들은 서로 신경을 쓰지 않아도 되는 영역까지 조심해야 했고, 데이터 충돌로 인한 버그도 점점 늘어났습니다.

문제의 원인: 모든 데이터를 프리팹에 묶어둔 구조

Unity는 씬이나 프리팹에 있는 모든 데이터를 자동으로 직렬화합니다.
그래서 프리팹을 저장할 때, 겉보기에는 위치나 색상만 수정한 것 같아도 속에 담긴 모든 속성값이 함께 저장됩니다.

결과적으로, 팀원 각자의 변경사항이 서로 다른 의도임에도 불구하고 덮어쓰기로 이어지는 경우가 많았죠.

유진과 준수처럼, 의도치 않은 수치 변경이 일어나는 건 매우 흔한 일입니다.

해결책: 스크립터블 오브트로 데이터 외부화

팀 리더 하람은 회의를 열고 한 가지 제안을 했습니다.

“프리팹에 데이터가 너무 많이 들어가 있으니까,
바뀌지 않는 설정값들은 씬 밖으로 빼내 보는 건 어때요?”

그렇게 해서 도입된 것이 바로 스크립터블 오브젝트(ScriptableObject)입니다.

어떻게 적용했을까?

1. 몬스터 능력치용 MonsterStat_SO ScriptableObject 클래스를 만들었습니다.
2. 모든 몬스터 프리팹은 이제 개별 수치를 직접 가지지 않고, ScriptableObject를 참조하도록 바꿨죠.
3. 유진이 수정하던 외형과 위치는 프리팹에 남아 있고, 준수가 조정하던 체력, 공격력, 이동 속도 등은 별도의 에셋 파일에서 관리하게 되었습니다.

적용 이후 달라진 점

이 구조 변경은 팀 전체에 큰 영향을 줬습니다.

무엇보다 중요한 건, 협업의 질이 달라졌다는 것입니다.

• 준수는 이제 “누가 고쳤지?” 같은 디버깅에 시간을 쓰지 않아도 되었고,
• 유진은 “이 값만 살짝 조정해볼 수 있을까요?”라고 물어볼 필요 없이 직접 테스트해볼 수 있게 됐습니다.

협업을 위한 설계, 스크립터블 오브트가 답일지도

이 사례는 단지 씬을 빠르게 여는 문제만이 아니라,
팀원 간 신뢰와 효율을 지키기 위해 어떻게 구조를 바꿔야 하는지를 보여줍니다.

유니티 스크립터블 오브젝트는 단순한 데이터 컨테이너가 아닙니다.
코드와 데이터의 결합을 끊고, 협업 구조를 유연하게 만드는 도구입니다.

씬과 프리팹에는 오직 위치, 외형, 이벤트 핸들러만 남기고,
나머지 값들은 스크립터블 오브젝트로 외부화해 보세요.

게임 개발이 더 가벼워지고, 팀은 더 즐겁게 협업할 수 있게 됩니다.

혹시 비슷한 문제로 고민 중이신가요?
유니티 스크립터블 오브젝트, 지금 바로 한번 써보셔도 좋습니다.
간단한 데이터부터, 하나씩 바꾸어 보세요. 그 변화는 생각보다 큽니다.