DesignPattern | Notion

<aside> 💡

디자인패턴 : → GoF (gang of four, 1994년 4저자에 의해 23가지 디자인패턴이 소개됨) → 오리지날 파운데이션 패턴 이라 불림

정의
- context - 반복적으로 일어나는 상황
- problem - 컨텍스트내의 목표와 제약조건
- solution - 제약조건을 충족하며 목표를 이루는 방법론 (패턴)
카탈로그
디자인원칙
오리지날 파운데이션 디자인패턴 → (C)는 클래스패턴으로 상속관계초점, 정적 관계 → 나머지는 객체패턴으로 소유관계초점, 보통 동적 관계
- 생성패턴 Creational : 객체 생성 방식 제어 → 생성 추상화
  - 싱글톤 singleton → 생성자아닌 getter조건부생성, 정적변수기반 유일객체 유지
  - 팩토리 factory (C) → 다형성 타입에 담을, 적절한 객체 생성하기
  - +빌더 builder → 팩토리(세트메뉴)의 옵션화버전, 복합 객체 생성과정 지원
  - +프로토타입 prototype → 깊은 복사 생성을 clone()등으로 함수/캡슐화, 다형성활용
  - +의존성주입 dependency injection → 모든 객체간 의존성을 생성자로 표현, 결정되게 하는 것
- 행위패턴 Behavioral : 객체간 책임 분배 → 행위 추상화
- 구조패턴 Structuaral : 클래스 관계 최적화 → 연결(구조) 추상화
  - 데코레이터 decorator → 대상을 소유한, 다형의 데코상속라인으로 래퍼함수를 구현
  - 어답터 adapter (C) → 서로다른 API의 인터페이스 연결을 추구
  - 퍼사드 facade → 껍데기란 뜻, 복잡한 기능의 간단한 사용 인터페이스 추구
  - 컴포지트 composite → 상속된 행동의 다형성 구현 (형제개별or형제단의 단체행동)
  - 프록시 proxy → 특정 객체에 접근을 제어 관리
  - +브릿지 bridge → n*k조합 관계 경우, n을 대표하는 추상클래스층으로 묶어 소유관계 정의
  - +플라이웨이트 flyweight → 중복생성에 따른 객체수 증가를 최소화하는 캐시 저장소 활용
복합패턴 Compound
- 패턴 섞어쓰기 (복합패턴 X)
- MVC
- MVVC
  - Model뿐만아니라 ViewModel을 따로 둔다는 점에서 다르다.
기타
- CRTP (CuriouslyRecurringTemplatePattern) → 템플릿부모를 두고, 부모함수로 자식이 자신을 인자로 넘김
- PIMPL (PrivateImplementation) → 인터페이스 클래스가 구현용 클래스를 소유하는 식으로 구현 은닉
- J2EE 패턴
- JSP 패턴
- 아키텍쳐 패턴
- 게임디자인 패턴
- 컨커런트 패턴
- 엔터프라이즈 패턴
Anti-Pattern 나쁜 해결책으로 이르는 길
- 카탈로그
  - 이름
  - 문제
  - 컨텍스트
  - 원인 → 익숙하지 않은 것에 대한 거부 등 다양
  - 잘못된 해결책 → 나쁘지만 매력적인, 빠지기 쉬운
  - 바람직한 해결책
  - 예시

대표적 아키텍쳐

Clean Architecture (Robert C. Martin, 2012)

가장 바깥 Frameworks & Drivers (외부 도구, DB, UI) Interface Adapters (컨트롤러, 게이트웨이) Application Use Cases (비즈니스 유스케이스) 가장 안쪽 Entities (핵심 비즈니스 규칙)
```
          ※ 의존성은 항상 안쪽으로만 흐른다
```

Hexagonal Architecture (Alistair Cockburn)

          Core Domain
            ↕
          Ports (인터페이스)
            ↕
          Adapters (구현체 — DB, CLI, API 등)

OS 커널 계층 (가장 유사)

L6 Applications (사용자 프로그램) L5 System Libraries (libc, Win32 API) L4 System Call Interface L3 Kernel Subsystems (프로세스, 파일시스템, 네트워크, 디바이스) L2 HAL (하드웨어 추상화) L1 Firmware/BIOS L0 Hardware

이 프로젝트에 가장 가까운 건 OS 커널 모델입니다. "시스템 자동화 도구"니까 당연합니다.

통합아키텍쳐 (os+hexagonal+clean arch)

Total Architecture — 통합 아키텍처 연속체

                     OS 계층         헥사고날        클린 아키텍처
                     ──────          ────────       ─────────────
H0 Domain            L6 loop peek    Core Domain    Entities
H1 Application       L6 loop up/down Services       Use Cases
H2 Presentation      L6 loop up/down Ports          Interface Adapters
H3 Human/UI          L6 loop stt/end Adapters       Frameworks & Drivers
	                   ─────── Application Boundary ───────
L6 Infra Service     App Layer       ·              ·
L5 Integration       Libraries       ·              ·
L4 OS Abstraction    Sys Calls       ·              ·
L3 Diagnostic        Kernel          ·              ·
L2 HW Abstraction    HAL             ·              ·
L1 HW Integration    Firmware/BIOS   ·              ·
L1 HW                HW              ·              ·
	                   ─────── Global Base ───────
B0 Foundation        ...             ·              ·

이 프로젝트는 아래에서 시작해서 위로 자라는 구조입니다. 지금은 Infrastructure 영역이 주력이고, Domain → Delivery 방향으로 확장 잠재력이 있습니다.

Zone-Tier 체계 (Z0~Z9, 총 42 Tier)

번호 체계: Z(zone).T(tier) — Zone 단위로 독립 확장 가능, 새 Tier 추가 시 기존 번호 불변.


  ═══════════════════════════════════════════════════════════════════
    H 계층: 역방향 의존 (Protocol/DI, 동적 결합)
    "L6 내부의 파동형 루프"

    데이터 흐름: H3(시작) → H2 → H1 → H0(정점) → H1 → H2 → H3(종료)
    의존성 방향: H3 → H2 → H1 → H0 ← (모두가 H0을 향함)
  ═══════════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────────────────────────────────┐
  │ H3  Human/UI  (어댑터 + 프레임워크)                               │
  │     L6 Loop: 시작점/종료점                                        │
  │                                                                  │
  │     역할: 사용자/외부의 물리적 접점. H2 Port를 인프라로 구현,         │
  │           모든 의존성을 조립하는 Composition Root                    │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     H3.0  Adapter       Port 구현체 (L4-L6 인프라 사용)            │
  │     H3.1  CLI           명령행 진입점, 인자 파싱                    │
  │     H3.2  GUI           Tkinter/웹 프레임워크 바인딩                │
  │     H3.3  API           REST/gRPC 엔드포인트 (미래)                │
  │     H3.4  Composer      Composition Root (DI 조립 공장)            │
  │                                                                  │
  │     suffix: -Adapter / -Controller / -View / -Composer            │
  │     코딩: Protocol 구현 + 생성자 주입 조립                          │
  │     의존: B0, H2(Port 구현), H0(타입 참조), L4-L6(인프라 사용)      │
  ├─────────────────────────────────────────────────────────────────┤
  │ H2  Presentation  (포트 + 인터페이스 어댑터)                        │
  │     L6 Loop: 상행/하행 변환 지점                                    │
  │                                                                  │
  │     역할: Domain과 외부 세계 사이의 "번역기".                        │
  │           Port Protocol을 정의하고, 데이터 형식을 변환               │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     H2.0  InboundPort   구동 포트 (앱이 제공하는 인터페이스)         │
  │     H2.1  OutboundPort  피동 포트 (앱이 외부에 요구하는 인터페이스)    │
  │     H2.2  DTO           Data Transfer Object (계층 간 데이터 캡슐)  │
  │     H2.3  Mapper        Domain ↔ 외부 형식 변환기                   │
  │                                                                  │
  │     suffix: -Port / -DTO / -Mapper                                │
  │     코딩: typing.Protocol 또는 abc.ABC로 정의만                     │
  │     의존: B0, H0(도메인 타입 참조), H1(유스케이스 시그니처 참조)      │
  ├─────────────────────────────────────────────────────────────────┤
  │ H1  Application  (유스케이스 / 서비스)                              │
  │     L6 Loop: 상행/하행 조율 지점                                    │
  │                                                                  │
  │     역할: "무엇을 할 것인가"를 정의. Domain 로직을 조율하되            │
  │           "어떻게"는 H2 Port에 위임                                 │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     H1.0  Command       쓰기 유스케이스 (상태 변경)                  │
  │     H1.1  Query         읽기 유스케이스 (조회)                      │
  │     H1.2  AppService    다단계 유스케이스 조합                       │
  │                                                                  │
  │     suffix: -UseCase / -Command / -Query / -AppService            │
  │     코딩: __init__에서 Port Protocol 타입 힌트로 주입받음             │
  │     의존: B0, H0(엔티티+도메인서비스 사용)                           │
  │     주의: H2 Port를 사용하되, import하지 않음!                       │
  │           → __init__ 파라미터의 타입 힌트로만 참조 (Protocol 덕타이핑) │
  ├─────────────────────────────────────────────────────────────────┤
  │ H0  Domain  (핵심 비즈니스 규칙)                                   │
  │     L6 Loop: 정점 (Peek)                                          │
  │                                                                  │
  │     역할: 기술에 독립적인 비즈니스 진실. POPO(Plain Old Python Object) │
  │           FastAPI, SQLAlchemy, Tkinter 등 외부 패키지 import 절대 금지│
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     H0.0  Entity        식별자 기반 비즈니스 객체                    │
  │     H0.1  ValueObject   불변 값 객체                               │
  │     H0.2  DomainSvc     엔티티 간 비즈니스 규칙                     │
  │     H0.3  DomainEvent   도메인 상태 변경 이벤트                     │
  │                                                                  │
  │     suffix: -Entity / -Value / -DomainService / -Event            │
  │     코딩: 순수 파이썬만. dataclass, enum, 표준 라이브러리            │
  │     의존: B0만. L 계층 절대 금지, H1-H3 절대 금지                   │
  └─────────────────────────────────────────────────────────────────┘

  ══════════════ Application Boundary (응용 경계) ═══════════════════

  ═══════════════════════════════════════════════════════════════════
    L 계층: 순방향 의존 (직접 import, 정적 결합)
    "하위 계층에서 자원이 공급되는 수직 파이프라인"

    의존성 방향: L6 → L5 → L4 → L3 → L2 → B0 (아래로만)
  ═══════════════════════════════════════════════════════════════════

  ┌─────────────────────────────────────────────────────────────────┐
  │ L6  Infra Service  (인프라 서비스 조율)                            │
  │     OS 아키텍처: Application Layer                                │
  │                                                                  │
  │     역할: 다수의 L4/L5 자원을 조합하는 인프라 비즈니스 로직           │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     L6.0  Install       소프트웨어 설치 오케스트레이션               │
  │     L6.1  Configure     환경 구성 (경로/변수/권한 복합 세팅)         │
  │     L6.2  Resolve       의존성 해석 (ensure_installed, get_version) │
  │     L6.3  Build         빌드/패키징 (PyInstaller)                  │
  │                                                                  │
  │     suffix: -Orchestrator / -Service                              │
  │     코딩: from L4/L5 import (직접)                                │
  │     의존: B0, L2-L5                                               │
  ├─────────────────────────────────────────────────────────────────┤
  │ L5  Integration  (외부 도구 1:1 래핑)                              │
  │     OS 아키텍처: System Libraries                                  │
  │                                                                  │
  │     역할: 하나의 외부 도구/서비스를 파이썬으로 래핑                    │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     L5.0  PackageMgr    pip, winget, conda, vcpkg 래퍼             │
  │     L5.1  SystemTool    netsh 래퍼                                 │
  │     L5.2  DevTool       git, claude-cli, antigravity 래퍼          │
  │     L5.3  AIService     ollama, gemini 클라이언트                   │
  │     L5.4  PlatformAPI   notion 클라이언트                           │
  │                                                                  │
  │     suffix: -Client / -Wrapper                                    │
  │     코딩: from L4 import (직접)                                   │
  │     의존: B0, L2-L4                                               │
  ├─────────────────────────────────────────────────────────────────┤
  │ L4  OS Abstraction  (OS 자원 추상화)                               │
  │     OS 아키텍처: System Calls                                      │
  │                                                                  │
  │     역할: 단일 OS 자원에 대한 원자적 접근                            │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     L4.0  Execution     명령 실행 (subprocess)                     │
  │     L4.1  Process       프로세스 생명주기                           │
  │     L4.2  FileAccess    파일/디렉토리 CRUD                         │
  │     L4.3  Environment   환경변수, 레지스트리                        │
  │     L4.4  NetPrimitive  URL 다운로드, HTTP                         │
  │                                                                  │
  │     suffix: -Executor / -System                                   │
  │     코딩: from L3 import (직접), os/subprocess/pathlib 사용        │
  │     의존: B0, L2-L3                                               │
  ├─────────────────────────────────────────────────────────────────┤
  │ L3  Diagnostic  (진단/관측)                                       │
  │     OS 아키텍처: Kernel                                            │
  │                                                                  │
  │     역할: 시스템 관찰. 로깅/추적/에러처리                            │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     L3.0  Error         JErrorSystem + Error* 예외 계층            │
  │     L3.1  Logging       JLogger (로그, 타이밍, 프로파일링)           │
  │     L3.2  Tracing       JTracer (함수 호출 추적)                    │
  │     L3.3  Pooling       JThreadPooler (쓰레드 풀)                  │
  │                                                                  │
  │     suffix: -er / -Error                                          │
  │     코딩: from B0 import (직접)                                   │
  │     의존: B0만 (L4 이상 절대 금지!)                                 │
  ├─────────────────────────────────────────────────────────────────┤
  │ L2  HW Abstraction  (하드웨어 추상화)                               │
  │     OS 아키텍처: HAL                                               │
  │                                                                  │
  │     역할: 하드웨어 정보 조회 (GPU, CUDA, 디바이스)                   │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     L2.0  Hardware      IoSystem (GPU/CUDA 상태 조회)              │
  │                                                                  │
  │     suffix: -System                                               │
  │     코딩: from B0 import (직접), ctypes/subprocess                │
  │     의존: B0만                                                    │
  │     참고: L0(HW), L1(Firmware)은 Python 범위 밖 — 생략             │
  └─────────────────────────────────────────────────────────────────┘

  ══════════════ Global Base (전역 기반) ════════════════════════════

  ┌─────────────────────────────────────────────────────────────────┐
  │ B0  Foundation  (기반)                                           │
  │                                                                  │
  │     역할: 의존성 제로. 모든 계층이 참조할 수 있는 전역 기반            │
  │     ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄            │
  │     B0.0  Primitive     타입, 상수, Enum, NamedTuple               │
  │     B0.1  Pattern       SingletonBase, ErrorSingletonBase         │
  │     B0.2  Runtime       JFoundation (is_frozen, script_path, env) │
  │     B0.3  Processing    TextUtils (텍스트/데이터 변환)              │
  │                                                                  │
  │     suffix: -Base / -Util / (없음)                                │
  │     코딩: Python 표준 라이브러리만. 외부 패키지 금지                  │
  │     의존: 없음                                                    │
  └─────────────────────────────────────────────────────────────────┘
  
  L 계층 파일: import를 열면 의존 대상이 즉시 보임 (정적, 명시적)
  H 계층 파일: __init__의 파라미터를 보면 "무엇이 필요한지"만 보임 (동적, 계약적)

  ---
  의존성 매트릭스

  행(→)이 열(↓)을 의존할 수 있는가?

  의존 →     B0   L2   L3   L4   L5   L6  ┃  H0   H1   H2   H3
  ──────────────────────────────────────────╋──────────────────────
  B0          ·    X    X    X    X    X   ┃   X    X    X    X
  L2          O    ·    X    X    X    X   ┃   X    X    X    X
  L3          O    O    ·    X    X    X   ┃   X    X    X    X
  L4          O    O    O    ·    X    X   ┃   X    X    X    X
  L5          O    O    O    O    ·    X   ┃   X    X    X    X
  L6          O    O    O    O    O    ·   ┃   X    X    X    X
  ━━━━ App Boundary ━━━━━━━━━━━━━━━━━━━━━━━╋━━━━━━━━━━━━━━━━━━━━━
  H0          O    X    X    X    X    X   ┃   ·    X    X    X
  H1          O    X    X    X    X    X   ┃   O    ·    X    X
  H2          O    X    X    X    X    X   ┃   O    O    ·    X
  H3          O    X    X    O    O    O   ┃   O    X    O    ·
  ──────────────────────────────────────────╋──────────────────────
  결합 방식     ← 직접 import (정적) →      ┃  ← Protocol/DI (동적) →

  매트릭스 해설

  L 계층 (좌상 삼각형): 깨끗한 계단형. 아래만 참조.

  H → L 관계 (우하 영역):
  - H0~H2는 L 계층에 전면 차단 (X). POPO 원칙.
  - H3만 L4-L6 사용 가능 (O). Adapter가 인프라를 사용하는 유일한 다리.

  H 내부 (우하 삼각형):
  - H0 → 아무것도 모름 (정점, Peek)
  - H1 → H0만 (유스케이스가 엔티티 사용)
  - H2 → H0, H1 (Port가 도메인 타입과 유스케이스 시그니처 참조)
  - H3 → H0(타입), H2(Port 구현). H1은 참조 안 함 — H3는 Port만 알고, UseCase는 Composer가 조립

  ---
  U자 파동으로 보는 데이터 흐름 vs 의존 방향

  시계열 데이터 흐름 (→)                    코드 의존 방향 (→)
  ─────────────────────                    ─────────────────────

  H3 ──→ H2 ──→ H1 ──→ H0               H0 (의존 없음)
  │      │      │      │ (peek)            ↑       ↑
  │      │      │      ↓                  H1 ──→ H0
  │      │      H1 ←── H0                 ↑
  │      H2 ←── H1                       H2 ──→ H0, H1
  H3 ←── H2                               ↑
                                         H3 ──→ H0, H2, L4-L6

  데이터는 바깥→안→바깥으로 왕복          의존은 항상 안쪽(H0)을 향함
  H3이 시작/종료점                        H0이 무의존 정점

  이것이 "의존성 역전의 역설"입니다: 데이터의 진입점(H3)이 가장 많은 의존성을 가지고, 데이터의 정점(H0)이 가장 적은    
  의존성을 가집니다. 흐름의 방향과 의존의 방향이 정반대.

파이썬은 C++과 달리 '동적 타이핑(Dynamic Typing)' 언어이기 때문에, 의존성 역전을 구현할 때 `abc` 모듈(추상 기저 클래스)이나 파이썬 3.8부터 도입된 `typing.Protocol`(덕 타이핑 기반 인터페이스)을 적극 활용하는 것이 핵심입니다.

이러한 파이썬만의 특징을 완벽하게 녹여낸 시스템 to UI 통합 아키텍처 가이드라인입니다.

                     OS 계층         헥사고날        클린 아키텍처
                     ──────          ────────       ─────────────
H0 Domain            L6 loop peek    Core Domain    Entities
H1 Application       L6 loop up/down Services       Use Cases
H2 Presentation      L6 loop up/down Ports          Interface Adapters
H3 Human/UI          L6 loop stt/end Adapters       Frameworks & Drivers
	                   ─────── Application Boundary ───────
L6 Infra Service     App Layer       ·              ·
L5 Integration       Libraries       ·              ·
L4 OS Abstraction    Sys Calls       ·              ·
L3 Diagnostic        Kernel          ·              ·
L2 HW Abstraction    HAL             ·              ·
L1 HW Integration    Firmware/BIOS   ·              ·
L1 HW                HW              ·              ·
	                   ─────── Global Base ───────
B0 Foundation        ...             ·              ·

[아키텍처 모델 부연 설명] 이 표는 물리적 하드웨어(L0)부터 사용자/외부 접점(H3)까지를 관통하는 통합 아키텍처 멘탈 모델입니다. 파이썬 환경에서 단일 계층으로 의존성을 관리하는 것이 아니라, 데이터의 생애 주기와 의존성 역전의 본질까지 통제하기 위한 **'듀얼 의존성 시스템(Dual Dependency System)'**을 채택하며 다음 4가지 핵심 규칙을 따릅니다.

1. 하단 기반 계층 (L0 ~ L6 Infra): 단방향 파이프라인과 순방향 의존

물리적 하드웨어에서 시작해 파이썬의 os, sys, ctypes 등의 내장 모듈이나 C-extension을 거쳐 파이썬 런타임(L6)으로 자원이 공급되는 수직적이고 종속적인 흐름입니다.
위로 올라갈수록 하위 계층에 대한 의존성이 커지는 '순방향 의존성'을 가집니다.

2. 상단 응용 계층 (H3 ~ H0): L6 내부의 파동형 루프 (L6 Loop)

H 계층은 클린/헥사고날 아키텍처를 동적인 시계열 흐름으로 재해석한 것입니다.
데이터 흐름(시계열): H3(시작) ➔ H2 ➔ H1 ➔ H0(정점, Peek) ➔ H1 ➔ H2 ➔ H3(종료) 형태의 분기형 U자 파동 구조를 가집니다.

3. 의존성 역전 (Dependency Inversion)의 역설

데이터의 시계열 흐름은 H3에서 시작하지만, 코드의 의존성은 철저하게 시계열의 정점인 H0(Domain)을 향합니다.
즉, 데이터의 진입점인 H3가 가장 높은 의존성을 가지며, 논리의 판단점인 H0는 파이썬의 외부 패키지(FastAPI, SQLAlchemy, PySide 등)나 인프라에 절대 의존하지 않는 순수 파이썬 객체(Plain Old Python Object) 상태를 유지합니다.

4. 듀얼 의존성 구현 전략 (DIP / DI / IoC) 및 리팩터링 원칙

상단의 역방향 의존성 구조(H 계층)는 파이썬 생태계의 유연성을 극대화하기 위해 설계된 것으로, 로우레벨(L 계층)과는 완전히 다른 코드 구현 스킬을 요구합니다.

DIP (목표) / DI (스킬) / IoC (환경)의 분리:
목표(DIP): H0(핵심 비즈니스 로직)가 H3/L6(외부 인프라 패키지)에 종속되지 않게 한다.
환경(IoC): asyncio의 이벤트 루프나 FastAPI, Celery 같은 프레임워크가 거대한 '분기형 디스펜서 시스템' 역할을 하여, 내 코드가 능동적으로 외부를 부르는 것이 아니라 프레임워크에 의해 수동적으로 호출당하게 제어권을 넘긴다.
코드 레벨의 2원화 전략:
L 계층 (순방향 의존 구현): 모듈 레벨의 직접적인 import와 상속(Inheritance)을 사용. 상대방 모듈을 런타임에 직접 끌어안아 **'정적 결합(강한 동기화)'**을 이룸.
H 계층 (역방향 의존 구현): 파이썬의 abc.ABC 또는 typing.Protocol(덕 타이핑)을 활용하여 추상화된 '계약서'만 정의하고, __init__ 메서드를 통한 **'생성자 주입(Constructor Injection, DI)'**을 사용. 구체적인 클래스를 파일 상단에서 import 하지 않고, 외부(엔트리포인트)에서 밀어 넣어주는 **'동적 결합(선택적 인젝션)'**을 이룸.
초기 리팩터링 시사점: 파이썬은 모듈 간 순환 참조(Circular Import) 오류가 발생하기 매우 쉬운 언어입니다. 상단 아키텍처는 이 '선택적 인젝션(DI)'의 성질을 활용해 의존성을 한 방향으로 정렬하고 플러그인 교체를 가능하게 하려고 존재합니다. 따라서 최초의 리팩터링 단계부터 반드시 Protocol이나 추상 클래스로 껍데기를 추출하고, 생성자 주입(__init__)을 염두에 두고 코드를 분리해야만 끔찍한 스파게티 import 지옥에서 벗어나 미래를 준비할 수 있습니다.

</aside>