Deep Dive Notes
이 문서는 단순한 구조 설명이 아니라
설계 의도를 검증하기 위한 사고 질문 세트를 정리한 메모다.
1. Ownership – 책임은 어디에 있는가
Section titled “1. Ownership – 책임은 어디에 있는가”- 이 데이터 / 객체는 누가 소유하는가?
- 누가 변경할 수 있는가?
- 누가 정리(Dispose / Release / Destroy)해야 하는가?
더 깊은 질문
Section titled “더 깊은 질문”- Ownership이 타입에 있는가, 컨텍스트에 있는가?
- 논리적 소유자와 물리적 소유자가 다른가?
- 소유자가 바뀔 가능성이 있는 구조인가?
설계 리뷰 핵심 질문
Section titled “설계 리뷰 핵심 질문”- 이걸 정리하지 않으면 어디서 터지는가?
- 실패했을 때 책임을 지는 위치는 어디인가?
2. Lifecycle – 언제 존재해야 정상인가
Section titled “2. Lifecycle – 언제 존재해야 정상인가”표면적인 사고
Section titled “표면적인 사고”- Awake → Start → Update → OnDestroy
- Load → Use → Unload
확장된 사고
Section titled “확장된 사고”- Lifecycle의 기준은 시간인가, 사건인가?
- 엔진 기준 Lifecycle인가, 도메인 기준 Lifecycle인가?
- 이 객체가 살아 있는 상태는 의도된 것인가, 우연인가?
설계 리뷰 핵심 질문
Section titled “설계 리뷰 핵심 질문”- 이 객체는 언제 죽어야 가장 안전한가?
- 지금 살아 있어야 할 이유를 명확히 말할 수 있는가?
3. Boundary – 책임의 경계는 어디까지인가
Section titled “3. Boundary – 책임의 경계는 어디까지인가”- 이 시스템의 책임은 어디까지인가?
- 이 레이어가 이 결정을 내려도 되는가?
더 깊은 질문
Section titled “더 깊은 질문”- 이 Boundary를 넘는 순간, 어떤 결정을 강요하는가?
- 어떤 정보가 이 경계를 넘는 순간 되돌릴 수 없게 되는가?
- Boundary가 API로 드러나는가, 암묵적으로 새고 있는가?
설계 리뷰 핵심 질문
Section titled “설계 리뷰 핵심 질문”- 이 경계를 깨면, 미래에 어떤 선택지를 잃는가?
4. Coupling / Cohesion – 바꾸기 쉬운 구조인가
Section titled “4. Coupling / Cohesion – 바꾸기 쉬운 구조인가”일반적인 정의
Section titled “일반적인 정의”- Coupling은 낮게
- Cohesion은 높게
실제 검증 방법
Section titled “실제 검증 방법”- 무엇을 바꾸려 할 때 몇 개의 파일이 같이 바뀌는가?
- 변경 이유는 하나인가, 여러 개인가?
- 이 코드는 변경의 중심인가, 변경을 흡수하는 쪽인가?
설계 리뷰 핵심 질문
Section titled “설계 리뷰 핵심 질문”- 이 코드들이 같이 바뀌는 이유는 무엇인가?
- 같이 바뀌는 것이 의도된 설계인가?
5. Trade-offs – 무엇을 포기했는가
Section titled “5. Trade-offs – 무엇을 포기했는가”미성숙한 상태
Section titled “미성숙한 상태”- “일단 이렇게 했습니다”
- “나중에 바꿀 수 있어요”
성숙한 상태
Section titled “성숙한 상태”- 무엇을 포기했는지 명확히 말할 수 있음
- 왜 지금은 그 포기가 괜찮은지 설명 가능
설계 리뷰 핵심 문장
Section titled “설계 리뷰 핵심 문장”이 구조는 X를 포기하고 Y를 얻기 위해 선택했습니다.
6. Meta Questions – 설계 레벨을 가르는 질문들
Section titled “6. Meta Questions – 설계 레벨을 가르는 질문들”이 질문들이 나오기 시작하면
설계는 구조 설명이 아니라 의사결정 설명이 된다.
- 이 설계는 누구를 편하게 하는가?
- 이 구조는 어떤 실수를 하기 어렵게 만드는가?
- 가장 위험한 오용 시나리오는 무엇인가?
- 처음 보는 사람이 가장 잘못 쓰기 쉬운 지점은 어디인가?
Summary
Section titled “Summary”이 문서의 목적은
정답 구조를 찾는 것이 아니라
의도와 선택을 설명할 수 있는 설계 사고를 정리하는 것이다.
- 구조보다 질문이 먼저다
- 결합보다 변경 시나리오를 본다
- Trade-off를 말할 수 있으면 설계는 이미 성숙하다