숏컷 코드
Manager
-> 조정과 orchestration
System
-> 규칙 실행과 처리 파이프라인
Service
-> 재사용 가능한 기능 제공문법과 예시
이름보다 중요한 것은 호출 방향과 책임 범위다
Manager, System, Service는 팀마다 다르게 쓰지만, 같은 말처럼 섞어 버리면 구조를 읽기 어려워집니다. 핵심은 이름이 아니라
"누가 누구를 호출하는가"와 "이 객체가 판단을 하는가, 기능을 제공하는가, 흐름을 조정하는가"입니다.
InventoryManager
-> 여러 하위 요소를 조정
DamageSystem
-> 데미지 규칙을 계산/적용
SaveService
-> 저장/불러오기 기능 제공Manager는 여러 하위 요소를 묶는 조정자일 때 가장 자연스럽다
매니저는 보통 여러 객체나 흐름을 묶어 순서를 조정합니다. 직접 모든 규칙을 품기보다 "언제 무엇을 부를지"를 결정하는 orchestration 역할에 가깝습니다.
System은 입력을 받아 규칙을 실행하는 처리 경계에 가깝다
시스템은 상태와 입력을 받아 어떤 규칙을 일관되게 적용하는 단위에 더 가깝습니다. CombatSystem, DamageSystem, NavigationSystem 같은 이름은
특정 도메인 규칙을 수행할 때 자연스럽습니다.
Service는 여러 곳에서 공통 기능을 제공할 때 잘 맞는다
서비스는 보통 호출자가 누구든 같은 기능을 제공합니다. SaveService, LocalizationService, AuthService 같은 이름은
"기능 제공"이 중심일 때 적합합니다. 상태를 강하게 소유하거나 전체 흐름을 조정하기 시작하면 service보다 다른 이름이 낫습니다.
가장 흔한 실패는 이름과 실제 책임이 어긋나는 것이다
InventoryManager라는 이름인데 실제로는 저장, 정렬, UI 갱신, 아이템 규칙, 서버 통신을 전부 품고 있으면 이름이 구조를 숨깁니다.
반대로 단순 기능 래퍼인데 무조건 manager라고 부르면 호출 방향이 흐려집니다.
구조 이름을 고를 때 핵심
| 상황 | 더 자연스러운 선택 |
|---|---|
| 여러 객체와 흐름을 조정할 때 | manager |
| 특정 규칙을 반복 적용하는 처리 경계일 때 | system |
| 공통 기능을 제공하는 호출 가능한 유틸리티일 때 | service |
| 상태 소유와 조정, 기능 제공이 한곳에 다 섞일 때 | 먼저 책임 분리부터 검토 |
| 이름은 그럴듯한데 호출 방향이 안 읽힐 때 | 이름보다 의존 방향 재설계 |
특이 케이스와 주의할 점
흔한 실패는 팀 안에서 manager, system, service를 완전히 동의어처럼 쓰는 것입니다. 이름이 계약 역할을 못 하면 새 사람이 코드를 읽을 때 구조를 추측해야 합니다. 이름을 통일하기보다 책임 기준을 먼저 통일하세요.
실패 예시
- SaveManager가 저장, UI 토스트, 씬 이동, 업적 갱신까지 전부 담당
결과
- 이름은 저장처럼 보이지만 실제 책임은 흐름 조정자에 가까움
- 호출 방향도 읽기 어려워짐