Table of Contents

06. Core

이 문서의 목표

Framework의 진입점, 로깅, 메시징, 스케줄링, Tick 등 핵심 계약을 이해한다.

왜 필요한가

Core는 모든 System이 공통으로 의존하는 기반이다. 로깅/틱/메시지버스가 System마다 제각각이면 Diagnostics 연동, Release 빌드 최적화가 불가능해진다.

언제 사용하는가

  • 로그를 남길 때: 반드시 Log (Debug.Log 직접 호출 금지)
  • 매 프레임 갱신이 필요할 때: TickSystem.Register
  • Feature 간 이벤트 통신: MessageBus.Publish/Subscribe
  • 지연 실행: Scheduler.Delay/Scheduler.Repeat

프로젝트에서 어떤 역할인가

  • BuildMode: Editor/Development/Release 분기의 단일 기준 (Application.isEditor 등 직접 사용 금지)
  • Result/Optional: 예상 가능한 실패를 예외 대신 값으로 반환

실제 게임에서는 언제 호출되는가

RootBootstrap.Initialize() 시점에 TickSystem/MessageBus 등이 연결되고, 이후 게임 전체 수명 동안 사용된다.

코드 예제

Log.Info("플레이어 스폰 완료");
TickSystem.Register(myTickable);
_messageBus.Publish(new PlayerDiedMessage());
var result = await _save.SaveAsync("slot1", data);
if (!result.IsSuccess) Log.Error(result.Error);

관련 Sample

Samples/Core/CoreSample.cs

Best Practice

  • Info/Warning은 Development 전용, Error/Exception만 모든 빌드에 남긴다.
  • 비용이 큰 로그 인자는 IsDevelopment 조건으로 감싼다.
  • Feature 내부 이벤트에는 MessagePipe(MessageBus)를 쓰지 않는다 (Feature 간 이벤트에만 사용).

자주 하는 실수

  • Debug.Log 직접 호출 (Editor 전용 스크립트 제외 금지)
  • Time.deltaTime 직접 사용 (ITimeSystem.DeltaTime 사용해야 함, 17_TimeSystem.md 참고)
  • 예외를 흐름 제어 수단으로 사용

실습 과제

  1. Log.Info로 로그를 남기고 Release 빌드에서 제거되는지 확인한다.
  2. 간단한 Message 구조체를 정의해 MessageBus.Publish/Subscribe로 통신해본다.

이전 문서 / 다음 문서

이전: 05_Common.md 다음: 07_Patterns.md

관련 API

MCP_Index.md Core 섹션 전체

Edit this page