Architecture & Design

1. Overview

아키텍처 및 설계(Architecture & Design, SAD)는 요구사항이라는 종이 위의 글자들을, 수백 명의 개발자가 동시에 코드를 짜도 무너지지 않는 단단한 '골조(Skeleton)'로 변환하는 물리적 구조화 작업을 다룹니다.

집을 지을 때 배관과 기둥의 위치를 먼저 잡지 않고 벽돌부터 쌓으면 결국 무너지듯, 소프트웨어도 코딩 이전에 아키텍처를 설계해야 합니다. 학습자는 객체 지향의 뼈대인 SOLID 원칙과 디자인 패턴을 시작으로, 시스템을 여러 계층으로 나누는 레이어드(Layered) 아키텍처, 그리고 비즈니스 로직을 외부 기술로부터 격리하는 헥사고날(Hexagonal) 아키텍처를 배웁니다. 나아가 도메인 주도 설계(DDD)를 통해 코드가 곧 비즈니스 언어가 되게 만들고, 구조적 결정 사항을 ADR(Architecture Decision Record)로 문서화하여 시스템의 진화 방향을 통제하는 아키텍트의 시야를 확보합니다.

2. Scope & Boundaries

In-Scope

• 설계 원칙과 패턴 (Design Principles & Patterns): SOLID, GRASP 원칙, GoF 디자인 패턴(생성, 구조, 행위).
• 아키텍처 스타일 (Architectural Styles): Monolithic, Layered, Hexagonal (Ports & Adapters), Microkernel, Event-Driven.
• 도메인 주도 설계 (Domain-Driven Design): 전략적 설계(Bounded Context), 전술적 설계(Entity, Value Object, Aggregate).
• 아키텍처 문서화 및 평가 (Documentation & Evaluation): C4 모델 시각화, ADR(Architecture Decision Record), ATAM(Architecture Tradeoff Analysis Method).

Out-of-Scope

• 네트워크 인프라의 물리적 스케일링: 로드 밸런서 튜닝이나 쿠버네티스 클러스터 오토스케일링 로직 $\rightarrow$ 07. System Architecture 영역으로 위임.
• UI/UX 화면 설계서 작성: 프론트엔드 화면의 시각적 컴포넌트 배치 $\rightarrow$ 12. Human-Computer Interaction 영역으로 위임.

Boundaries

• SAD vs. Requirements (09-02): REQ(09-02)가 '이 시스템은 초당 1만 건의 결제를 처리해야 한다'고 선언한다면, SAD(09-03)는 그 요구사항을 만족시키기 위해 '결제 모듈과 장바구니 모듈을 메시지 큐(Kafka)로 분리하고, DB를 샤딩(Sharding)한다'라는 기술적 뼈대를 설계합니다.
• SAD vs. Implementation (05. FPL): SAD는 언어에 종속되지 않는 논리적/구조적 청사진을 제시하며, FPL은 그 청사진을 Java나 Python 특유의 문법으로 세밀하게 채워 넣습니다.

3. Counterexample

• 디자인 패턴 오남용 (Patternitis): 단순한 CRUD 게시판을 만드는데 Abstract Factory 패턴과 Observer 패턴을 억지로 우겨넣어 코드를 5배로 부풀리는 행위. 패턴은 '반복되는 문제'에 대한 해결책일 뿐, 목적 자체가 아닙니다. 불필요한 추상화는 코드를 읽는 동료의 뇌 메모리를 고갈시키는 최악의 안티 패턴(Over-engineering)입니다.
• 은통알 아키텍처 맹신 (Microservices Fallacy): 트래픽도 없고 도메인도 단순한 초기 스타트업이 "요즘 대세니까"라며 무턱대고 마이크로서비스 아키텍처(MSA)를 도입하는 현상. MSA는 기술적 과시용이 아니라, 모놀리식 구조에서 조직과 트래픽이 감당할 수 없을 정도로 커졌을 때 도입하는 '극약 처방'입니다. 도메인 경계(Bounded Context)에 대한 이해 없이 분리된 MSA는 분산 트랜잭션의 지옥을 열어버리는 분산형 모놀리스(Distributed Monolith)가 됩니다.

4. Prerequisites

• 소프트웨어 프로세스 (Basic): 요구사항이 어떻게 도출되고(REQ), 이후 어떻게 테스트(QA)되는지 생명 주기를 알아야 설계의 범위를 한정할 수 있습니다. (09-01, 09-02)
• 객체 지향 프로그래밍 (Recommended): 클래스, 인터페이스, 다형성(Polymorphism)의 개념을 알아야 의존성 역전(DIP)을 물리적으로 구현할 수 있습니다. (05-01. OOP)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: SOLID 원칙과 디자인 패턴 기초 (Principles & Patterns)

• Why to Learn: 코드를 조금만 고쳐도 다른 곳에서 버그가 터지는 '스파게티 코드'의 굴레에서 벗어나, 유연하고 확장 가능한 모듈을 만들기 위함입니다.
• What to Learn:
  • Concepts: SOLID 5대 원칙 (SRP, OCP, LSP, ISP, DIP), 결합도(Coupling)와 응집도(Cohesion).
  • Skills: GoF 디자인 패턴(Singleton, Factory Method, Strategy, Observer 등)의 적용 및 리팩토링 물리.
  • Tools: UML(통합 모델링 언어) 클래스 다이어그램.
  • Trade-offs: 전략(Strategy) 패턴을 쓰면 if-else 분기문이 완전히 사라져 코드가 깔끔해지는 마법 vs 클래스 개수가 폭발적으로 늘어나 파일 시스템이 복잡해지는 대가.
• How to Learn:
  • 1단계: '할인 정책(정액 할인, 비율 할인)'이 추가될 때마다 기존 코드를 뜯어고쳐야 하는 Order 클래스를, 인터페이스(DiscountPolicy)에 의존하게 하여 기존 코드 수정 없이 새 할인을 추가하는 OCP(개방-폐쇄 원칙)를 증명합니다.
  • 2단계: '의존성 주입(DI)'을 통해 객체가 자신이 쓸 부품을 직접 만들지 않고 밖에서 주입받게 함으로써, 테스트하기 쉬운 코드로 변환(DIP)하는 리팩토링을 실습합니다.
• Implement: 현재 진행 중인 토이 프로젝트의 메인 로직 중 하나를 골라, 변경 가능성이 높은 부분을 찾아내어 Strategy 패턴과 Factory 패턴을 적용한 Before/After 코드 및 UML 보고서.

Recommended

Core Topic 02: 거시적 아키텍처 스타일 (Architectural Styles)

• Why to Learn: UI 프레임워크나 데이터베이스가 바뀌더라도, 시스템의 심장인 '비즈니스 로직'은 단 한 줄도 수정되지 않게 방어벽을 치기 위해서입니다.
• What to Learn:
  • Concepts: 모놀리식(Monolithic), 레이어드(Layered), 헥사고날(Hexagonal / Ports & Adapters), 양파(Onion) 아키텍처.
  • Skills: 제어의 역전(IoC) 물리, 도메인 레이어의 외부 라이브러리 격리, 관심사의 분리(Separation of Concerns).
  • Tools: 의존성 분석 도구 (예: JDepend).
  • Trade-offs: Controller $\rightarrow$ Service $\rightarrow$ Repository로 일직선으로 떨어지는 레이어드 아키텍처의 직관성과 빠른 초기 개발 속도 vs 서비스가 커지면 결국 도메인 로직이 DB에 종속되어 버리는 데이터베이스 주도 설계의 함정.
• How to Learn:
  • 1단계: 일반적인 레이어드 아키텍처에서 Service 클래스가 DB 연결용 Repository를 직접 호출할 때 발생하는 강결합(Tight Coupling) 구조를 분석합니다.
  • 2단계: 헥사고날 아키텍처를 도입하여 Service 중심에 인터페이스(Port)를 두고, DB 접근 코드를 바깥쪽 어댑터(Adapter)로 밀어내어 방향을 역전(DIP)시키는 물리적 방어벽을 구축합니다.
• Implement: 하나의 핵심 도메인(예: 결제)을 헥사고날 아키텍처 구조(Domain, Port, Adapter)의 패키지로 나누어 구현하고, DB를 RDBMS에서 NoSQL로 교체할 때 도메인 로직이 전혀 변경되지 않음을 증명하는 프로토타입.

Practical

Core Topic 03: 도메인 주도 설계 (Domain-Driven Design, DDD)

• Why to Learn: 대규모 시스템에서 비즈니스 로직이 너무 복잡해져서 개발자조차 도메인을 이해하지 못하는 상황을 막고, 코드가 곧 비즈니스 문서가 되게 하기 위함입니다.
• What to Learn:
  • Concepts: 유비쿼터스 언어(Ubiquitous Language), Bounded Context(바운디드 컨텍스트).
  • Skills: 전략적 설계(도메인 분할과 컨텍스트 매핑), 전술적 설계(Entity, Value Object, Aggregate Root, Repository).
  • Tools: Event Storming(이벤트 스토밍).
  • Trade-offs: "상품(Product)"이라는 단어가 영업팀과 배송팀에서 완전히 다른 의미로 쓰임을 분리(Bounded Context)하여 시스템 충돌을 막는 통찰 vs 전술적 패턴(Aggregate 등)의 극악한 학습 곡선과 보일러플레이트 코드 폭증.
• How to Learn:
  • 1단계: '이커머스'라는 거대한 도메인을 주문, 상품, 배송, 정산이라는 하위 도메인(Sub-domain)으로 쪼개고, 각 영역이 서로 침범하지 않는 물리적 경계(Bounded Context)를 긋는 이벤트 스토밍(Event Storming)을 진행합니다.
  • 2단계: '주문(Order)'과 '주문 항목(OrderLine)'을 묶어 하나의 생명 주기를 갖는 '애그리거트(Aggregate)' 단위로 묶고, 데이터를 변경할 때는 오직 애그리거트 루트(Aggregate Root)를 통해서만 접근하도록 강제하는 트랜잭션 경계를 설계합니다.
• Implement: 특정 도메인의 비즈니스 프로세스를 포스트잇(이벤트 스토밍)으로 시각화한 뒤, 도출된 Aggregate와 Bounded Context를 바탕으로 마이크로서비스(MSA) 분리 경계안 제시.

Advanced

Core Topic 04: 아키텍처 의사결정과 시각화 (Architecture Governance)

• Why to Learn: "우리는 왜 MySQL 대신 MongoDB를 썼지?"라는 질문에, 1년 뒤에도 누구든 명확한 공학적 트레이드오프 근거를 대답할 수 있게 시스템의 역사를 남기기 위해서입니다.
• What to Learn:
  • Concepts: 품질 속성(Quality Attributes: 가용성, 확장성, 성능), 피트니스 함수(Fitness Function).
  • Skills: ADR(Architecture Decision Record) 작성, C4 모델(Context, Container, Component, Code) 기반 아키텍처 다이어그래밍.
  • Tools: Structurizr, PlantUML.
  • Trade-offs: 다이어그램을 코드(Doc-as-Code)로 관리하여 항상 최신 상태를 유지하는 엔지니어링의 미학 vs 끊임없이 코드를 수정해야 하는 유지보수 비용.
• How to Learn:
  • 1단계: 시스템 아키텍처를 그릴 때 마구잡이로 네모와 화살표를 그리는 대신, C4 모델의 계층적 추상화(Level 1: System Context $\rightarrow$ Level 2: Container) 규격을 사용하여 개발자와 기획자가 소통할 수 있는 표준 도면을 작도합니다.
  • 2단계: '메시지 브로커로 RabbitMQ와 Kafka 중 무엇을 쓸 것인가'에 대해, 현재 조직의 트래픽 상황과 운영 인력을 근거로 선택한 이유(Context, Decision, Consequences)를 ADR 템플릿에 맞게 문서화합니다.
• Implement: 현재 속한 팀이나 프로젝트의 가장 중요한 아키텍처 결정 사항 2가지를 선정하여 표준 ADR 문서를 작성하고, 전체 시스템의 C4 Model Level 1, 2 다이어그램 도출.

7. Terminology

8. References

Primary

• [P2] SWEBOK v3 - Software Design (Architectural structure, patterns, OOP)
• [P5] SFIA - Enterprise and business architecture (ARCH)

Secondary

• [Clean Architecture] Robert C. Martin - SOLID, Architecture boundaries
• [Domain-Driven Design] Eric Evans - Strategic and Tactical DDD

Industry

• [C4 Model] Simon Brown - Visualizing software architecture
• Repo-Local ZK: 20_ZK/22_Permanent/10-learning/00-tech-cs/tech/ZK-architecture-design.md

9. Final Checklist

Primary

• 단일 책임 원칙(SRP)과 개방-폐쇄 원칙(OCP)을 위반했을 때 발생하는 거대한 GodClass의 비극을 설명하고, SOLID가 어떻게 객체 간의 결합도(Coupling)를 끊어내는지 물리적으로 증명할 수 있는가?
• 단순한 CRUD를 넘어서는 시스템에서, 비즈니스 로직(도메인)이 데이터베이스 기술(SQL)에 멱살 잡혀 끌려다니는 현상을 막기 위해 헥사고날(Ports and Adapters) 아키텍처의 방어벽을 설계할 수 있는가?

Secondary

• 하나의 시스템 내에서 "상품(Product)"이라는 단어가 영업팀과 배송팀에서 완전히 다른 속성을 가짐을 인지하고, 도메인 주도 설계(DDD)의 바운디드 컨텍스트(Bounded Context)를 통해 시스템의 충돌 경계를 찢어발길 수 있는가?
• 이벤트 스토밍(Event Storming)을 통해 비즈니스 흐름을 포스트잇으로 시각화한 뒤, 동일한 생명주기를 가지는 엔티티들을 하나로 묶어 트랜잭션 경계를 방어하는 '애그리거트 루트(Aggregate Root)'를 주조할 수 있는가?

Industry

• 3년 뒤에 합류할 신규 개발자나 AI 에이전트가 "우린 왜 이 기술을 선택했지?"라며 혼란에 빠지지 않도록, 대안(Alternatives)과 트레이드오프를 명확히 남기는 아키텍처 결정 기록(ADR)을 마크다운으로 박제할 수 있는가?
• 머릿속에만 둥둥 떠다니는 복잡한 마이크로서비스(MSA) 통신 구조를, C4 모델(Context, Container, Component, Code)의 4단계 줌인(Zoom-in) 렌즈를 통해 비개발자 직군과도 완벽하게 소통할 수 있는 청사진으로 렌더링할 수 있는가?