AI 시대 개발자가 꼭 알아야 할 소프트웨어 아키텍처 8대 핵심 개념과 설계 메커니즘

유행하는 기술 스택의 맹목적 도입을 멈추고 시스템의 본질을 설계하라! 아키텍처 드라이버와 품질 속성, 전술(Tactic)·패턴·스타일의 위계, 헥사고날/클린 아키텍처, 이벤트 기반(EDA), CQRS/이벤트 소싱, 그리고 아키텍처 결정 기록(ADR) 작성법을 완벽 정리합니다.
IT·과학
저자

Ikmyungterran

공개

2026년 9월 8일

Modified

2026년 9월 8일

0. 도구 우선(Tool-First) 사고의 함정: Redis와 Kafka부터 고르지 마라

주니어 개발자들이 시스템 설계를 시작할 때 가장 흔히 범하는 실수가 있습니다. 요구사항을 듣자마자 “어? 캐시로 Redis 붙이고, 메시지 큐로 Kafka 쓰고, 서버는 마이크로서비스(MSA)로 쪼갠 다음 쿠버네티스에 올리죠!”라고 외치는 것입니다.

이것이 바로 전형적인 ‘도구 우선(Tool-First) 사고의 함정’입니다.

소프트웨어 아키텍처는 유행하는 멋진 오픈소스 도구들을 레고 블록처럼 이어 붙이는 기술이 아닙니다. 진정한 아키텍처는 다음과 같은 냉정한 질문에 답하는 체계적인 엔지니어링 과정입니다:

graph TD
    A["1. 무엇이 비즈니스에 가장 중요한가? (Architecture Driver)"] --> B["2. 시스템이 얼마나 뛰어나야 하는가? (Quality Attribute)"]
    B --> C["3. 그 목표를 어떤 원리로 달성할 것인가? (Tactic & Pattern)"]
    C --> D["4. 무엇을 얻고 무엇을 희생할 것인가? (Trade-off)"]
    D --> E["5. 최종 선택의 이유와 맥락을 기록했는가? (ADR)"]
    style A fill:#E0F2FE,stroke:#0284C7,stroke-width:2px;
    style B fill:#F0FDF4,stroke:#16A34A,stroke-width:2px;
    style C fill:#FEF3C7,stroke:#D97706,stroke-width:2px;
    style D fill:#FEE2E2,stroke:#DC2626,stroke-width:2px;
    style E fill:#F3E8FF,stroke:#9333EA,stroke-width:2px;

1. 아키텍처의 3대 계층: 전술(Tactic) vs 패턴(Pattern) vs 스타일(Style)

많은 개발자가 이 용어들을 뒤섞어 사용합니다. 하지만 이 셋은 추상화의 수준이 완전히 다릅니다.

구분 개념 정의 비유 (도시 건축) 소프트웨어 실무 예시
아키텍처 스타일 (Style) 시스템 전체의 거시적 구조와 통신 철학 “우리는 격자형 계획도시로 짓겠다.” 모놀리식, 마이크로서비스(MSA), 파이프-필터, 이벤트 기반(EDA)
아키텍처 패턴 (Pattern) 특정 서브시스템의 문제를 해결하는 입증된 구조적 해법 “상업 지구에는 고층 복합 상가 건물을 짓겠다.” 헥사고날(포트-어댑터), CQRS, 레이어드 아키텍처
아키텍처 전술 (Tactic) 단 하나의 품질 속성(성능/가용성)을 달성하기 위한 구체적 설계 테크닉 “정전에 대비해 건물 지하에 비상 발전기를 두겠다.” 하트비트 핑, 지수 백오프 재시도, 커넥션 풀링, 캐싱

2. 현대 소프트웨어를 지배하는 핵심 아키텍처 6선

2-1. 계층화 아키텍처 (Layered Architecture)

  • 구조: Presentation(컨트롤러) \(\rightarrow\) Business(서비스) \(\rightarrow\) Persistence(리포지토리) \(\rightarrow\) Database.
  • 장점: 모든 개발자에게 친숙하고 단순하며 분업이 쉽습니다.
  • 약점: 업무 로직이 데이터베이스 테이블 구조에 종속(DB 주도 설계)되기 쉽고, 규모가 커지면 상위 레이어가 하위 레이어의 모든 세부사항을 알아야 하는 강결합이 발생합니다.

2-2. 헥사고날 / 클린 아키텍처 (Ports & Adapters)

핵심 비즈니스 로직(도메인 Entity)을 한가운데 순수한 영역으로 가두고, 바깥의 웹 프레임워크, DB, 외부 결제 API 등은 언제든 갈아 끼울 수 있는 부품(Adapter)으로 취급합니다.

graph TD
    subgraph Outer["외부 인프라 영역 (어댑터)"]
        Web["REST API 컨트롤러"]
        DB["JPA / MySQL DB"]
        PG["토스페이먼츠 PG사"]
    end
    subgraph Core["내부 순수 도메인 코어 (의존성 역전)"]
        PortIn["인바운드 포트 (인터페이스)"]
        Domain["순수 비즈니스 로직 (도메인 모델)"]
        PortOut["아웃바운드 포트 (인터페이스)"]
    end
    Web --> PortIn --> Domain
    Domain --> PortOut
    DB -.->|구현 Implementation| PortOut
    PG -.->|구현 Implementation| PortOut
    style Core fill:#DCFCE7,stroke:#16A34A,stroke-width:2px;
    style Outer fill:#F1F5F9,stroke:#475569,stroke-width:1px;

  • 의존성 역전 원칙(DIP): 도메인 코어가 DB 라이브러리를 임포트(import)하지 않습니다. 도메인은 순수한 인터페이스(Port)만 선언하고, 외부 어댑터가 이를 구현합니다. DB를 MySQL에서 PostgreSQL로 바꾸어도 핵심 비즈니스 코드는 단 한 줄도 수정되지 않습니다!

2-3. 이벤트 기반 아키텍처 (Event-Driven Architecture)

서비스들이 서로를 직접 HTTP로 호출하지 않고, “어떤 사건이 일어났다(예: OrderPlaced 주문 완료됨)”는 이벤트를 메시지 브로커(Kafka, RabbitMQ)에 발행(Publish)합니다. * 장점: 완벽한 비동기 결합 해제(Decoupling). 결제 시스템이 일시적으로 다운되어도 주문 접수는 멈추지 않고 큐에 쌓입니다.

2-4. CQRS (명령과 조회의 책임 분리)

  • Command (쓰기/수정): 데이터의 일관성과 트랜잭션 무결성이 최우선입니다. 정규화된 RDBMS에 저장합니다.
  • Query (읽기/조회): 복잡한 화면 구성을 위해 조인(JOIN)을 치느라 DB가 뻗는 것을 막기 위해, 쓰기 모델에서 발행한 이벤트를 비동기로 받아 조회 전용 비정규화 캐시(Elasticsearch, Redis)에 미리 완성된 형태로 구워둡니다.

3. 공짜 점심은 없다: 아키텍처 트레이드오프 분석

모든 아키텍처 선택에는 반드시 대가가 따릅니다:

+--------------------------------------------------------------------------+
|                     아키텍처 트레이드오프 매트릭스                       |
+---------------------+-----------------------+----------------------------+
| 선택한 아키텍처     | 우리가 얻는 것 (+)   | 우리가 치러야 할 대가 (-)  |
+---------------------+-----------------------+----------------------------+
| 마이크로서비스(MSA) | 팀별 독립 배포, 확장성| 네트워크 지연, 분산 트랜잭션, 디버깅 지옥|
| 모놀리식 아키텍처   | 개발 단순성, ACID 보장| 단일 장애점, 빌드/배포 시간 급증          |
| 이벤트 기반 (EDA)   | 높은 가용성, 느슨한 결합| 최종 일관성(데이터 시차), 장애 추적 난해   |
| 헥사고날 아키텍처   | 뛰어난 테스트 용이성  | 수많은 DTO 매핑 코드, 보일러플레이트 증가 |
+---------------------+-----------------------+----------------------------+

4. 실무의 꽃: 아키텍처 결정 기록(ADR) 작성법

시스템 아키텍처를 설계하고 난 뒤 6개월이 지나면, “대체 그때 왜 Redis를 안 쓰고 Kafka를 썼지?”라며 본인조차 이유를 까먹게 됩니다. 이를 방지하기 위해 실무에서는 ADR (Architectural Decision Record)을 작성합니다.

힌트📝 실무 ADR 필수 5대 포맷
  1. 맥락 (Context): 우리가 직면한 비즈니스 및 기술적 문제는 무엇인가? (예: 초당 5만 건의 실시간 위치 데이터 수집 필요)
  2. 검토한 대안 (Options): 고려했던 기술 대안들은 무엇인가? (대안 A: HTTP 폴링, 대안 B: WebSocket, 대안 C: MQTT)
  3. 최종 결정 (Decision): 어떤 선택을 내렸는가? (결정: 모바일 배터리 소모가 가장 적은 MQTT 프로토콜 채택)
  4. 결과 및 트레이드오프 (Consequences): 이 결정으로 얻은 긍정적 효과와 감수해야 할 부작용은 무엇인가?
  5. 재검토 조건 (Revisit Conditions): 어떤 상황이 오면 이 결정을 다시 뒤집을 것인가? (예: 동시 접속자가 1,000만 명을 돌파할 경우)

📚 참고 문헌 및 공식 출처

구분 자료명 주요 내용 링크
소프트웨어 아키텍처 바이블 Software Architecture in Practice (Bass, Clements, Kazman 저) SEI 카네기멜론 대학교 아키텍처 드라이버, 품질속성 시나리오 Pearson
클린 아키텍처 Clean Architecture (Robert C. Martin 저) 엉클 밥의 의존성 규칙, 포트와 어댑터 인터페이스 설계 원칙 Prentice Hall
현대 아키텍처 가이드 Fundamentals of Software Architecture (Mark Richards & Neal Ford 저) 모놀리스에서 분산 시스템까지 최신 8대 아키텍처 스타일 분석 O’Reilly Media
ADR 표준 Michael Nygard’s Architecture Decision Records Template 마크다운 기반의 가벼운 아키텍처 의사결정 기록 표준 규약 GitHub ADR Template

함께 읽으면 좋은 글