[로블록스]#18 - 시스템 분리 & Service 구조

[로블록스]#18 - 시스템 분리 & Service 구조

처음에는 Script 하나로도 충분하다.
그런데 기능이 하나둘 늘어나는 순간,
그 Script는 곧 괴물이 된다.
이번 글에서는 로블록스 프로젝트를 Service 단위로 분리하는 설계 사고를 다룬다.

---

 

 

1. “Main Script”가 생기는 순간 망한다

많은 로블록스 프로젝트가 이렇게 시작한다.

• 게임 상태 관리
• 플레이어 입장 처리
• 보상 지급
• UI 통신
• 데이터 저장

그리고 이 모든 걸 하나의 Script에 넣는다.

Script가 커졌다는 건
기능이 많다는 뜻이 아니라,
역할 구분이 없다는 뜻이다.

 

 

 

---

2. 시스템 분리란 무엇인가

시스템 분리는 “파일을 나눈다”는 의미가 아니다.

하나의 책임 = 하나의 시스템

각 시스템은 자기 역할만 알고, 다른 시스템의 내부는 모른다.

 

 

 

---

3. 로블록스식 Service 구조 개념

로블록스에서 말하는 Service 구조는 Unity의 Manager 패턴과 매우 비슷하다.

ServerScriptService
 └─ Services
     ├─ GameStateService
     ├─ PlayerService
     ├─ RewardService
     ├─ DataService
     └─ MatchService
    

각 Service는 명확한 책임 하나만 가진다.

 

 

 

---

4. Service의 책임 예시

• GameStateService : 상태 전환
• PlayerService : 입장/퇴장
• RewardService : 보상 계산
• DataService : 저장/로드
• MatchService : 게임 시작 조건

이 구조에서는 “이 로직이 어디 있어야 하지?”라는 고민이 사라진다.

 

 

 

---

5. Service 간 통신 원칙

시스템 분리에서 가장 중요한 규칙은 이것이다.

Service는
다른 Service의 내부를 직접 건드리지 않는다.

대신, 함수 호출이나 이벤트로만 소통한다.

 

 

 

---

6. ModuleScript를 쓰는 이유

Service 구조는 ModuleScript 없이는 성립하지 않는다.

• 역할 단위 코드 캡슐화
• 명확한 공개 API
• 의존성 관리 용이

ModuleScript는 “재사용”보다 구조 안정화에 더 큰 의미가 있다.

 

 

 

---

7. 잘못된 분리 예시

이런 분리는 오히려 독이다.

• 기능별이 아닌 파일 크기별 분리
• 모든 Service가 서로 require (dependency를 끊어야 하는데....)
• Service가 UI를 직접 조작
• Service가 플레이어 입력을 직접 처리

분리는 책임 기준이어야 한다.

 

 

 

---

8. Service 구조가 주는 실전 이점

• 버그 위치 추적 쉬움
• 기능 추가 시 영향 범위 최소
• 팀 작업에 유리
• 라이브 수정 안전

이 단계부터 프로젝트가 “작품”이 아니라 서비스가 된다.

 

 

 

---

9. 개발자가 가장 많이 하는 실수

• Manager 하나로 모든 걸 처리하려 한다
• Script 분리를 미루다가 나중에 폭발
• 의존성 방향을 고려하지 않는다

로블록스에서는 구조가 곧 안정성이다.

 

 

 

---

10. 시스템 분리 핵심 요약

• Script는 역할 단위로 나눈다
• Service는 책임 하나만 가진다
• ModuleScript로 구조를 고정한다
• Service 간 직접 참조 최소화
• 구조는 초반에 잡아야 한다

 

 

 

---

11. 다음 글 예고

다음 글에서는 멀티플레이 동기화 사고를 다룬다.

“이건 서버에서 보여야 하나?
아니면 나만 보면 되나?”

---