핵심 정리
text
Runtime.asmdef
Editor.asmdef
Tests.asmdef구조 이해
컴파일 범위와 재컴파일 비용
asmdef는 스크립트를 논리적 어셈블리 단위로 나눠 컴파일 범위와 의존성을 명시적으로 관리하게 해 줍니다. asmdef가 없으면 스크립트 하나를 수정할 때 프로젝트 전체를 다시 컴파일합니다. asmdef를 사용하면 변경이 일어난 어셈블리와 그것을 참조하는 어셈블리만 다시 빌드하므로, 프로젝트 규모가 커질수록 컴파일 대기 시간을 줄이는 효과가 커집니다.
런타임·에디터·테스트 분리 구조
asmdef는 역할에 따라 코드를 계층적으로 나누는 구조와 잘 맞습니다. 아래는 대표적인 구성 예입니다.
text
Core.Runtime.asmdef
UI.Runtime.asmdef -> Core.Runtime 참조
Gameplay.Tests.asmdef -> Gameplay.Runtime 참조런타임 코드는 에디터 전용 API를 참조하지 않도록, 에디터 코드는 테스트 코드와 분리하도록 의존성 방향을 명시할 수 있습니다. 이렇게 하면 릴리스 빌드에 에디터 코드가 포함되는 실수도 방지할 수 있습니다.
도입 시점과 단계적 확장
asmdef를 너무 일찍, 너무 잘게 나누면 설정 파일이 늘어나고 참조 관계를 관리하는 부담이 생깁니다. 아키텍처 관점에서 "어느 계층이 어느 계층을 참조할 수 있는가"를 명확히 하고 싶어지는 시점, 또는 재컴파일 비용이 체감될 정도로 팀과 코드 규모가 커진 시점에서 단계적으로 도입하는 편이 현실적입니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| 스크립트 수정 시 전체 재컴파일이 느림 | asmdef 도입 |
| 에디터 코드를 런타임 빌드에서 제외 | Editor.asmdef 별도 생성 |
| 테스트 코드를 릴리스 빌드에서 제외 | Tests.asmdef 분리 |
| 의존성 방향을 명시적으로 제한 | asmdef 참조 관계 설정 |
| 소규모 프로토타입 | asmdef 없이도 가능 |
주의할 점
asmdef를 너무 잘게 나누면 참조 관계 관리가 오히려 복잡해집니다. 3계층 분리부터 시작하세요.
text
// ❌ 기능별 세분화 — 참조 관계 폭발, 순환 의존 위험
Player.Core.asmdef
Player.Movement.asmdef
Player.Combat.asmdef
Player.Animation.asmdef
// ✅ 역할 계층으로만 분리 — 단순하고 관리하기 쉬움
Game.Runtime.asmdef (런타임 코드)
Game.Editor.asmdef (에디터 도구, Runtime 참조)
Game.Tests.asmdef (테스트 코드, Runtime 참조)참고 링크
2 sources