아키텍처 패턴 on Advanced Beginner

계층형 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 아키텍처 패턴을 처음 배우는 개발자 선수 지식: 기본적인 Spring Boot MVC 패턴 이해 소요 시간: 약 15분

가장 기본적이고 널리 사용되는 아키텍처 패턴입니다. 처음 아키텍처를 배운다면 여기서 시작하세요. 계층형 아키텍처는 소프트웨어를 수평으로 나누어 각 계층이 명확한 역할을 가지도록 구성합니다. 각 계층은 위에서 아래로만 호출할 수 있다는 단순하지만 강력한 규칙을 따릅니다.

한 줄 요약#

코드를 4개 층으로 나누고, 위에서 아래로만 호출한다는 원칙을 기본으로 합니다. 이렇게 하면 각 층이 자신의 책임에 집중할 수 있고, 코드의 구조를 이해하기 쉬워집니다.

헥사고날 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 테스트 용이성과 외부 의존성 교체를 고려하는 개발자 선수 지식: 계층형 아키텍처의 한계 이해 소요 시간: 약 20분

Ports and Adapters 패턴이라고도 불립니다. 애플리케이션의 핵심을 외부 세계로부터 완전히 격리시키는 아키텍처입니다. 헥사고날 아키텍처의 핵심 아이디어는 비즈니스 로직을 중심에 두고, 외부와의 모든 상호작용을 Port와 Adapter를 통해 처리한다는 것입니다. 이렇게 하면 외부 기술이 바뀌어도 핵심 비즈니스 로직은 영향을 받지 않습니다.

한 줄 요약#

애플리케이션은 육각형 안에 있고, 외부와의 모든 연결은 Port와 Adapter로 처리합니다. 이를 통해 비즈니스 로직과 기술적 세부사항을 완벽하게 분리할 수 있습니다.

클린 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 엄격한 의존성 관리가 필요한 대규모 프로젝트 개발자 선수 지식: 헥사고날 아키텍처의 Port/Adapter 개념 소요 시간: 약 25분

클린 아키텍처 (Clean Architecture)#

Uncle Bob(Robert C. Martin)이 2012년에 제안한 아키텍처입니다. 의존성 규칙을 엄격하게 지키는 것이 핵심입니다.

클린 아키텍처가 등장한 배경에는 소프트웨어 개발의 고질적인 문제가 있습니다. 비즈니스 로직이 프레임워크나 데이터베이스에 강하게 결합되면, 기술 스택을 변경하거나 테스트를 작성하는 것이 매우 어려워집니다. 예를 들어, JPA 어노테이션이 도메인 객체에 직접 붙어 있으면, 해당 도메인 로직을 테스트하려면 반드시 데이터베이스 연결이 필요하게 됩니다. 클린 아키텍처는 이런 문제를 해결하기 위해 비즈니스 규칙을 기술적 세부사항으로부터 완전히 격리하는 것을 목표로 합니다.

어니언 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: DDD와 잘 어울리는 아키텍처를 찾는 개발자 선수 지식: 헥사고날 아키텍처와 의존성 역전 원칙 소요 시간: 약 20분

어니언 아키텍처 (Onion Architecture)#

Jeffrey Palermo가 2008년에 제안한 아키텍처입니다. 도메인 모델을 가장 중심에 두고, 양파처럼 겹겹이 감싸는 구조입니다.

어니언 아키텍처는 전통적인 계층형 아키텍처의 한계에서 출발합니다. 계층형 아키텍처에서는 상위 계층이 하위 계층에 의존하므로, 데이터베이스 계층의 변경이 서비스 계층에 연쇄적인 영향을 미칩니다. 반면 어니언 아키텍처에서는 도메인 모델이 어떤 것에도 의존하지 않고, 인프라스트럭처가 도메인에 의존하는 방향으로 설계합니다. 이를 통해 도메인 로직은 데이터베이스, 프레임워크, 외부 서비스의 변화와 무관하게 순수한 비즈니스 규칙만을 표현할 수 있습니다. DDD(Domain-Driven Design)와 특히 잘 어울리는 이유도 여기에 있습니다.

CQRS

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 복잡한 조회 요구사항이나 성능 최적화가 필요한 시스템을 설계하는 개발자 선수 지식: 이벤트 기반 아키텍처 또는 이벤트 기반 아키텍처 기본 개념 소요 시간: 약 35분 핵심 질문: “언제 읽기와 쓰기 모델을 분리해야 하는가?”

요약
CQRS 핵심: Command(상태 변경, 도메인 모델 사용) ↔ Query(조회, 최적화된 읽기 모델 사용) 분리로 각각의 요구사항에 맞게 최적화

비유: 도서관
CQRS를 도서관 운영에 비유할 수 있습니다:

기존 방식(단일 모델): 도서 관리자가 책 대출/반납도 처리하고, 도서 검색 요청도 처리합니다. 대출이 밀리면 검색도 느려지고, 검색이 많으면 대출도 느려집니다.

CQRS 방식: 대출 담당자(Command)와 검색 사서(Query)를 분리합니다. 대출 담당자는 책의 상태를 변경하고, 검색 사서는 최적화된 색인(인덱스)을 활용하여 빠르게 응답합니다.

핵심: 대출(쓰기)과 검색(읽기)의 요구사항이 다르므로 각각에 최적화된 방식으로 처리합니다. 대출은 정합성이 중요하고, 검색은 속도가 중요합니다.

이벤트 기반 아키텍처

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

대상 독자: 도메인 모델링과 트랜잭션 개념을 이해한 개발자 선수 지식: 어니언 아키텍처 또는 Aggregate 경계 개념에 대한 이해 소요 시간: 약 30분 핵심 질문: “도메인 이벤트를 언제, 왜 사용해야 하는가?”

이벤트 기반 아키텍처 (Event-Driven Architecture)#

비유: 회사 공지 시스템
도메인 이벤트를 회사 공지 시스템에 비유할 수 있습니다:

이벤트 발행: 인사팀에서 “신입 사원 입사” 공지를 보냅니다. 인사팀은 누가 이 공지를 볼지 모르고, 알 필요도 없습니다.

이벤트 구독: IT팀은 공지를 보고 계정을 생성하고, 총무팀은 명함을 주문하며, 교육팀은 신입 교육 일정을 잡습니다. 각 부서가 독립적으로 행동합니다.

느슨한 결합: 인사팀이 IT팀의 존재를 모르더라도 시스템은 작동합니다. 나중에 “환영 선물 담당 팀"이 추가되어도 인사팀은 수정할 필요가 없습니다.

핵심: 발행자는 “무슨 일이 일어났다"만 알리고, 구독자들이 각자 필요한 일을 합니다.