콘텐츠로 바로가기
HY_TECH_BASE

Foundations & Architectural Patterns

소프트웨어 시스템의 대규모 구조를 결정하는 기본 설계 원칙과 레이어드, 헥사고날 등 현대적 아키텍처 패턴의 물리적 구성을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

기초 및 아키텍처 패턴(Foundations & Architectural Patterns, FAP)은 복잡한 소프트웨어를 관리 가능한 단위로 분할하고, 변경에 유연하게 대응할 수 있도록 시스템의 '뼈대'를 설계하는 원칙을 다룹니다.

아키텍처는 나중에 바꾸기 힘든 '중요한 결정들'의 집합입니다. 학습자는 높은 응집도와 낮은 결합도라는 물리적 목표를 달성하기 위해 어떠한 구조적 선택(Layered, Onion, Hexagonal)을 해야 하는지 학습합니다. 이를 통해 코드의 물리적 배치가 유지보수 비용과 시스템의 생명주기에 미치는 결정적인 영향을 파악하고, 기술 부채를 최소화하는 견고한 시스템의 기초를 다집니다.

2. Scope & Boundaries

In-Scope

  • Core Principles: 유지보수성, 확장성, 테스트 가능성 등 품질 속성(Quality Attributes) 정의
  • Classic Architectures: Layered, Client-Server, Pipe-and-Filter 패턴의 물리 구조
  • Modern Paradigms: Clean Architecture, Hexagonal (Ports & Adapters), DDD(Domain Driven Design) 기초
  • Component Mechanics: 결합도(Coupling)와 응집도(Cohesion)의 정량적/정성적 분석

Out-of-Scope

  • 구체적인 인프라 클라우드 설정 상세 (07-07 Cloud-Native 영역으로 위임)
  • 코드 레벨의 상세 디자인 패턴 (Singleton, Factory 등 - 05. Programming Languages 영역으로 위임)

Boundaries

  • FAP vs. Distributed Principles: FAP는 '단일 애플리케이션 또는 시스템 내부의 논리적 구조'에 집중하고, 07-02(Distributed Principles)는 '네트워크로 연결된 여러 노드 간의 상호작용'에 집중합니다.

3. Counterexample

  • 단순히 폴더를 controller, service, repository로 나누는 것은 FAP 학습이 아닙니다. 비즈니스 로직(Domain)이 외부 프레임워크나 DB 기술에 **물리적으로 의존(Dependency)**하지 않도록 하기 위해 어떻게 의존성 역전(DIP)을 적용하고 인터페이스를 설계할지 아키텍처 관점에서 논증할 수 있어야 합니다.

4. Prerequisites

  • 언어 설계 및 타입 시스템 기초 (Basic): 객체 지향 및 인터페이스 개념에 대한 프로그래밍 언어적 이해가 필요합니다. (05. LDT)
  • 소프트웨어 공학 및 DevOps 기초 (Recommended): 소프트웨어 생애주기와 유지보수 비용에 대한 개념 선행이 권장됩니다. (09. Software Engineering)

5. Learning Map

  1. Thinking in Structures: 코드를 넘어 시스템 전체를 컴포넌트와 관계로 바라보는 안목을 익힙니다.
  2. Traditional Layering: 가장 직관적인 레이어드 아키텍처의 물리적 한계와 개선점을 이해합니다.
  3. Inverting Dependencies: 외부 변화로부터 핵심 로직을 물리적으로 격리하는 고수준 패턴(Hexagonal)을 배웁니다.
  4. Evaluating Design: 설계안의 득실(Trade-offs)을 품질 속성 관점에서 정량적으로 평가하는 법을 실습합니다.

6. Learning Topics

Basic

Core: 아키텍처의 목적과 품질 속성 (Architectural Goals)

  • Why to Learn: '돌아가는 코드'를 넘어 '변할 수 있는 시스템'을 만들기 위함입니다.
  • What to Learn:
    • 소프트웨어 가치: 기능(Function) vs 구조(Architecture)
    • 6대 품질 속성: 가용성, 변경 가능성, 성능, 보안, 테스트 가능성, 사용성
    • 비기능 요구사항(Non-functional requirements)이 물리적 설계에 주는 제약
  • How to Learn:
    • 기존 레거시 프로젝트에서 '변경하기 힘들었던 코드'를 품질 속성 관점에서 원인 분석
    • 특정 시스템의 아키텍처 기술서(SAD)를 읽고 주요 설계 동기(Design Decisions) 파악
  • Implement: 특정 비즈니스 요구사항에 우선순위가 정해진 아키텍처 품질 속성 체크리스트

Core: 계층형 및 클린 아키텍처 (Layered to Clean)

  • Why to Learn: 기술의 변화(DB 교체, UI 변경)가 비즈니스 로직을 파괴하지 않게 하기 위해서입니다.
  • What to Learn:
    • Layered Architecture: 물리 배치 순서와 하향식 의존성의 문제점
    • Hexagonal Architecture (Ports & Adapters): 외부 환경과의 물리적 분리 메커니즘
    • Clean Architecture: 엔티티 중심의 원형 구조와 의존성 규칙(Dependency Rule)
  • How to Learn:
    • 레이어드 아키텍처 코드를 헥사고날 아키텍처로 리팩토링하며 인터페이스 도입 전후 비교
    • 의존성 그래프 도구를 사용하여 레이어 간의 순환 참조(Circular Dependency) 물리적 탐지
  • Implement: 도메인 로직이 외부 라이브러리 없이 독립적으로 테스트 가능한 프로젝트 골격 소스

Practical

Core: 컴포넌트 분해와 도메인 중심 설계 (Component & DDD Intro)

  • Why to Learn: 대규모 시스템을 팀별로 독립적으로 개발할 수 있는 경계를 설정하기 위함입니다.
  • What to Learn:
    • 관심사 분리(Separation of Concerns): 컴포넌트 추출 원칙
    • DDD 기초: 전략적 설계(Bouded Context, Context Map)와 전술적 설계(Entity, Aggregate)
    • 공통 재사용 원칙(CRP) vs 공통 폐쇄 원칙(CCP)의 물리적 충돌
  • How to Learn:
    • 비즈니스 도메인을 분석하여 서로 독립적인 바운디드 컨텍스트(Bounded Context)로 구획 나누기 연습
    • 특정 기능을 수정할 때 영향을 받는 파일 수를 측정하여 응집도(Cohesion) 정량 평가
  • Implement: 복잡한 주문 시스템의 도메인 모델과 바운디드 컨텍스트 간의 관계를 도식화한 아키텍처 맵

Advanced

Core: 아키텍처 평가와 의사결정 (Evaluation & ADR)

  • Why to Learn: 주관적인 설계 토론을 배제하고 팀 차원의 합리적이고 기록된 결정을 내리기 위해서입니다.
  • What to Learn:
    • ATAM (Architecture Tradeoff Analysis Method) 기반의 설계 검증 기초
    • 아키텍처 결정 기록(ADR, Architecture Decision Records) 작성법 및 물리적 이력 관리
    • 진화적 아키텍처(Evolutionary Architecture): 피트니스 함수(Fitness Functions) 개념
  • How to Learn:
    • 실제 오픈소스 프로젝트의 ADR 리스트를 분석하며 포기한(Trade-off) 가치가 무엇인지 파악
    • 두 가지 설계 대안(예: 동기 vs 비동기 처리)에 대해 품질 속성별 점수를 매겨 의사결정 시뮬레이션
  • Implement: 새로운 기술 도입이나 아키텍처 변경에 대한 실제 적용 가능한 ADR 문서 양식 및 샘플

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core/misused/legacy)
Dependency Inversion 고수준 모듈이 저수준 모듈에 의존하지 않고, 둘 다 추상화(인터페이스)에 의존하게 하는 설계 원칙입니다. 추천 유연성 확보 SOLID / DIP Dependency Injection '객체 주입' 자체로 오해 P1:CS2023/Software Design core
Cohesion (응집도) 한 컴포넌트 내부의 요소들이 서로 얼마나 밀접하게 관련되어 있는지를 나타내는 물리적 설계 척도입니다. 기본 품질 측정 Coupling SRP '코드가 짧음'과 혼동 P2:SWEBOK Design core
Hexagonal Arch 애플리케이션의 핵심 비즈니스 로직을 외부 환경(DB, UI 등)으로부터 포트와 어댑터를 통해 격리하는 구조입니다. 실무 격리/테스트 Ports & Adapters Onion Architecture '레이어 추가'로만 오해 Industry Cockburn core
ADR 팀 내에서 내린 중요한 아키텍처 결정 사항을 그 배경과 득실을 포함하여 기록한 문서입니다. 실무 지식 관리 Documentation RFC 단순한 '매뉴얼'로 오해 Industry Nygard core

8. References

Primary References

Secondary References

  • [Clean Architecture] Robert C. Martin — Modern implementation authority.
  • [Software Architecture in Practice] Bass et al. — Focus on quality attributes.

Industry References

  • [Gartner: Reference Architecture Patterns] — Enterprise standard definitions.
  • [Martin Fowler - Architecture section] — Pragmatic modern pattern blog.

9. Final Checklist

Primary Checklist

  • 레이어드 아키텍처에서 'DB 스키마 변경'이 'UI 코드'까지 영향을 미치는 물리적 원인을 의존성 관점에서 설명 가능한가? (P2)
  • 특정 설계안이 시스템의 성능(Performance)을 높이는 대신 무엇(예: 유지보수성)을 희생했는지 트레이드오프를 식별 가능한가? (P1, P2)

Secondary Checklist

  • 인터페이스를 통한 추상화가 시스템의 전체적인 물리적 복잡도를 높이는지 낮추는지 목적에 따라 변론할 수 있는가?
  • 응집도는 높고 결합도는 낮은 시스템이 왜 실제 운영 환경에서 장애 전파(Cascading Failure)를 물리적으로 억제하는지 인지하는가?

Industry Checklist

  • 실무 개발 과정에서 발생하는 중요한 설계 변경 사항을 ADR 문서로 남기고 팀원들과 기술적 합의를 이끌어낼 수 있는가? (SFIA)
  • 복잡한 레거시 코드를 보고 물리적 컴포넌트 경계를 다시 설정하는 리팩토링 전략을 제시 가능한가?

Concepts & Tags

#software-architecture#design-patterns#clean-architecture#layered-architecture