217. 클린 아키텍처 (Clean Architecture) - 로버트 C. 마틴 (Uncle Bob) 의존성 규칙 엔티티 유스케이스 인터페이스 어댑터 프레임워크 독립성

핵심 인사이트: (216번 헥사고날 심화) "야! 216번 육각형(헥사고날) 구조 좋지? 그걸 로버트 C. 마틴 아저씨가 더 깐깐하고 명확한 '4겹짜리 양파 껍질 원표'로 정리해 주마! 제일 안쪽 노란색 핵(Entities)에는 전 우주가 망해도 변하지 않는 핵심 비즈니스 규칙만 넣어! 그 바깥 빨간색 껍질(Use Cases)에는 애플리케이션의 동작 순서를 넣고! 그 밖의 파란색 껍질(Adapters)에는 번역기들을 넣고! 제일 바깥쪽 파란색 껍질(Frameworks)에는 웹이나 DB 같은 쓰레기 기계들을 던져놔! 그리고 절대 잊지 마. '모든 코드의 화살표(의존성)는 무조건 바깥 껍질에서 안쪽 껍질을 향해서만 찔러야 해!!' 안쪽 껍질 놈이 바깥 껍질 놈의 이름을 부르는 순간 네 코드는 쓰레기통행이야!!" 도메인 주도 설계와 모든 아키텍처의 영혼을 집대성한 우주 최강의 양파망, 클린 아키텍처다.

Ⅰ. 부패한 아키텍처의 징후 (Why Clean?)

로버트 C. 마틴(Uncle Bob)은 프레임워크(Spring, Django)에 노예처럼 끌려다니는 개발자들을 구원하고자 했습니다.

  • 나쁜 설계: 데이터베이스가 오라클에서 MySQL로 바뀌거나, 화면이 웹에서 모바일로 바뀌면 시스템 핵심 로직(뇌) 코드까지 피를 토하며 다 뜯어고쳐야 합니다. (강한 결합, 의존성 부패)

Ⅱ. 클린 아키텍처 (Clean Architecture)의 개념 🌟

  • 개념: 시스템의 관심사(관심 영역)를 명확한 계층(Layer)으로 완벽하게 분리하고, 시스템의 가장 핵심인 비즈니스 규칙(도메인)을 중심에 두어, UI, 데이터베이스, 웹 프레임워크 같은 외부의 세부적인 기술(변동성이 큰 것들)로부터 도메인을 100% 철저하게 독립(격리)시키는 소프트웨어 설계 철학입니다.

Ⅲ. 클린 아키텍처를 지배하는 단 하나의 절대 법칙 🌟 핵심 기출 🌟

  • 의존성 규칙 (The Dependency Rule):
    • "모든 소스 코드의 의존성(화살표, Import 문)은 반드시 밖에서 안으로, 오직 고수준의 정책(중심부)을 향해서만 가리켜야 한다!"
    • 바깥쪽 원(프레임워크)에 있는 클래스, 함수, 변수의 이름을 안쪽 원(엔티티, 유스케이스)에 있는 코드에서 단 한 번이라도 언급(Import)하거나 호출하면 그 즉시 사형입니다.

Ⅳ. 4겹의 양파 껍질 (동심원 구조) 🌟

안쪽으로 갈수록 절대 변하지 않는 신성한 영역입니다.

1. 엔티티 (Entities) - "절대 변하지 않는 우주의 진리" (최심장부)

  • 가장 안쪽 원입니다. 계좌, 대출 이자 계산 공식 같은 기업의 핵심 비즈니스 규칙(데이터 구조와 함수)이 들어갑니다.
  • 페이지 디자인이 웹에서 앱으로 바뀌든, 보안 DB가 해킹당하든 이 엔티티 코드는 단 한 줄도 0.1%도 수정되어서는 안 됩니다. 프레임워크가 없는 순수한 자바(Plain Old Java Object) 덩어리입니다.

2. 유스케이스 (Use Cases) - "애플리케이션의 동작 시나리오"

  • 두 번째 원입니다. 사용자가 시스템을 조작하는 흐름(예: 직원_등록하기(), 장바구니_결제하기())을 통제합니다.
  • 밖에서 들어온 요청을 받아 안쪽의 엔티티에게 "야 엑셀 줘봐! 이자 계산해!" 하고 일을 시키고 결과를 다시 밖으로 내보내는 오케스트라 지휘자입니다.
  • (안쪽 엔티티를 부르니까 화살표가 안쪽을 향하므로 합법입니다.)

3. 인터페이스 어댑터 (Interface Adapters) - "통역사"

  • 세 번째 원입니다. (216번 헥사고날의 어댑터와 100% 같은 놈입니다.)
  • 웹 브라우저가 던진 JSON 껍데기 데이터를 찢어서 유스케이스가 좋아하는 순수 자바 데이터로 번역(Controller)해 주거나, 유스케이스가 뱉어낸 순수 자바 데이터를 오라클 DB가 좋아하는 SQL 쿼리문으로 번역(Gateway, Presenter)해 주는 번역기들입니다.

4. 프레임워크 & 드라이버 (Frameworks & Drivers) - "세부 기계들" (최외곽)

  • 가장 바깥쪽 껍질입니다. 우리가 흔히 쓰는 Spring Boot, MySQL, React, Android UI 같은 **'언제든 갈아치울 수 있는 하찮은 도구와 기계 덩어리'**들이 사는 곳입니다.
  • 이곳에는 핵심 로직을 짜지 않고, 그냥 3번 어댑터와 연결해 주는 끈(설정 코드)만 둡니다.

Ⅴ. 클린 아키텍처의 기적과 트레이드오프

  • 장점: 프레임워크 독립성(Spring을 내일 당장 Django로 바꿔도 1, 2번 껍질은 무사함), UI 독립성, DB 독립성, 그리고 **데이터베이스 쇳덩어리 없이도 1, 2번 껍질만 쏙 빼서 1초 만에 수만 번의 유닛 테스트를 돌릴 수 있는 미친 테스트 용이성(Testability)**을 가집니다.
  • 단점: "버튼 누르면 DB에 1 더하기"라는 단순한 기능 하나 만들 때도, 껍질을 관통하는 클래스와 인터페이스(어댑터) 파일을 5개 이상 쪼개서 만들어야 하므로, 초보 개발자는 멘탈이 나가고 타자 치다 손가락이 부러집니다(초기 개발 속도 극악).

📢 섹션 요약 비유: **클린 아키텍처(Clean Architecture)**는 국가의 심장인 '대통령(엔티티)'을 보호하는 4중 철통 벙커 시스템입니다. 가장 깊은 지하 1층에는 국가 통치 철학(핵심 로직)만 고민하는 대통령(엔티티)이 있습니다. 지하 2층에는 대통령의 명령을 각 부서로 전달하는 비서실장(유스케이스)이 있습니다. 지하 3층에는 외부에서 오는 영어, 불어 문서를 한국어로 번역해서 비서실장에게 올려주는 통역사(인터페이스 어댑터)들이 대기합니다. 그리고 지상 1층(프레임워크)에는 인터넷, 팩스, 오토바이 배달부 같은 외부 통신 기계들이 널려 있습니다. 이 벙커의 절대 규칙(의존성 규칙)은 **"모든 결재 서류(화살표)는 지상 1층에서 시작해 무조건 지하 1층(안쪽)으로만 내려가야 한다"**는 것입니다. 대통령(엔티티)이 지상 1층의 배달부(DB) 이름을 직접 부르며 전화를 거는 짓(밖을 가리키는 의존성)은 헌법으로 금지됩니다. 지상 1층의 통신망이 팩스에서 카카오톡으로 바뀌든(프레임워크 교체), 러시아가 쳐들어오든 지하 1층의 대통령은 바깥세상의 소음을 1도 모르고 영원히 평화롭게 국가(핵심 로직)를 다스릴 수 있는 궁극의 격리 요새입니다.