1. MVC 패턴
MVC는 Model-View-Controller의 약자로, model, view, controller로 이루어진 패턴을 말한다. 이 패턴은 자바의 스프링 프레임워크, Node.js의 Exprdss.js에서 대표적으로 사용하는 패턴이다.

Controller
컨트롤러는 사용자의 입력 처리와 흐름 제어를 담당하고 사용자의 요청을 알맞게 해석한 뒤, 모델에 비즈니스 로직 실행을 위임한다.
컨트롤러에서는 사용자 입력값 유효성 검증, 쿼리 문자열을 알맞은 데이터 모델로 변환한다. 또한 비즈니스 로직에 포함되지 않는 사용자 인증과 같은 기능을 담당하기도 한다. 컨트롤러만 모델과 뷰에 의존해 컨트롤러 상관없이 모델과 뷰를 변경할 수 있어 유지보수에 용이하다.
Model
모델은 사용자가 요청한 기능을 실행한 후 처리 결과를 컨트롤러에 리턴한다. 모델은 회원가입, 암호 변경 등 비즈니스와 관련된 로직만 처리한다. 사용자에게 제공할 화면(HTML 등)이나 UI 흐름 제어에 대한 처리는 하지 않는다. 모델과 뷰는 분리되어 있기에 서로의 영향을 덜 받는다.
View
컨트롤러는 모델의 처리 결과를 기준으로 사용자에게 보여줄 뷰를 선택한 후 뷰는 사용자에게 결과 화면을 보여준다.
API를 구현한 컨트롤러는 JSON 응답을 생성하는 뷰를 선택하고,
웹 페이지를 구현한 컨트롤러는 HTML 결과를 응답하는 뷰를 선택한다.
뷰는 사용자에게 알맞은 응답을 제공하는 역할만 하고 로직이나 흐름 제어는 하지 않는다.
2. 계층형 아키텍처(Layered Architecture)
계층형 아키텍처는 각 계층마다 특정 역할을 수행하고, 하위에 위치한 계층에만 의존하는 특징을 가진 구조이다. 오래된 패턴으로 많은 곳에서 사용된다.

계층형 아키텍처에서 하위 계층은 상위 계층에 대한 의존을 갖지 않는다. 오직 상위 계층에서 하위 계층으로의 의존만 허용한다. 위 그림에서 계층 1은 계층2에 의존하지만, 반대로 계층2는 계층1에 의존하지 않는다.
웹 애플리케이션을 계층형 아키텍처로 구현할 때는 일반적으로 4개 계층으로 구성한다.
- 표현(UI) 계층 : 사용자와의 상호작용 담당, MVC 패턴의 컨트롤러, 뷰 역할
- 응용 계층 :사용자 요청을 실제 처리 하는 계층이고, MVC 패턴의 서비스 역할이다. 모델 인프라 계층 결과를 표현 계층에 리턴한다.
- 도메인(모델) : 도메인 로직을 구현하는 역할이다. 주문 모델의 취소 제약조건, 상태 변경 같은 로직이 포함된다.
- 인프라(영속) : DAO처럼 DB 연동, 문자 발송 같은 구현 기술을 지원한다.
장점
- 구조가 단순하고 규칙이 명확해 코드 실행 흐름을 추적하기 쉽다
3. DDD(Domain Driven Design)와 전술 패턴
로직이 복잡한 도메인을 구현할 때는 DDD에 소개된 패턴 사용을 검토해보자. DDD에서 소개하는 전술패턴을 사용하면 도메인 영역에 도메인 로직을 집중시키는 데 도움이 된다.
DDD에서 도메인 모델 구성요소
| 엔티티(Entity) | 각 엔티티 객체는 고유의 식별자를 가지며, 각 엔티티는 식별자로 구분된다. 내부 상태가 바뀌어도 식별자는 바뀌지 않는다. 예를 들어 각 주문 엔티티는 서로 다른 주문번호를 식별자로 갖는다. |
| 밸류(Value) | 밸류는 고유의 식별자를 갖지 않으며 개념적인 값을 표현한다. 금액, 배송 주소 같은 값이 밸류가 된다. 값은 불변으로 구현하는 것을 추천한다. |
| 애그리거트(Aggregate) | 애그리거트는 관련된 객체를 묶어 하나의 개념적인 단위를 표현한다. 예를 들어 주문 애그리거트는 Order 엔티티, OrderLine 밸류 집합, ShippingAddress 밸류로 구성될 수 있다. 애그리거트는 모델의 일관성을 관리하는 단위가 된다. |
| 리포지토리(Repository) | 리포지토리는 도메인 객체를 물리적인 저장소와 연결할 때 사용하는 모델이다. 리포지토리는 도메인 객체를 저장하고 조회할 때 사용되는 인터페이스를 제공한다. 리포지토리는 애그리거트 단위로 존재한다. |
| 도메인 서비스 (DomainService) |
특정한 애그리거트에 속하지 않은 로직을 구현한다. 외부 연동이 필요한 도메인 로직도 도메인 서비스로 사용해서 표현한다. |
| 도메인 이벤트 (Domain Event) |
도메인 내에서 발생한 이벤트를 표현한다. 도메인의 상태가 변경될 때 도메인 이벤트가 발생한다. 도메인 이벤트는 주로 다른 부분에 변화를 알리기 위해 사용된다. |
DDD는 도메인 로직을 애그리거트 단위로 묶는다. 그 이점은 다음과 같다.
- 복잡한 모델을 애그리거트 단위로 관리할 수 있게 함으로써 복잡도를 낮추고
- 애그리거트에 관련 로직을 모아 응집도를 높이고
- 복잡한 도메인의 유지보수성을 높여준다.
4. 마이크로서비스 아키텍처
마이크로서비스 아키텍처는 서비스를 더 작은 단위로 분리하고 각 서비스가 연동되는 구조를 갖는다.

모놀리식과 마이크로서비스와의 장단점은 다음과 같다.
| 모놀리식 | 마이크로서비스 | |
| 장점 | - 배포가 단순하다. - 코드 관리가 더 쉽다. - 성능을 높이기 위해 복잡한 구조를 가질 필요가 없다. - 테스트와 디버깅이 쉽다. |
- 독립적인 배포와 지속적인 배포가 용이하다. - 성능 확장에 용이하다. - 기술에 대한 유연성을 가질 수 있다. - (보통) 개발자의 만족도가 더 높다. |
| 단점 | - 규모가 커질수록 개발 속도가 느려질 수 있다. - 한 기능의 문제가 전체에 영향을 줄 수 있다. - 구현 기술 변경에 어려움이 있다. - 작은 변경도 전체를 다시 배포해야 한다. |
- 테스트와 디버깅이 어려울 수 있다. - 모놀리식 대비 인프라가 복잡해진다. - 소통에 따른 부하가 증가할 수 있다. - 무분별하게 서비스를 만들면 분산 모놀리식이 될 수 있다. |
마이크로서비스 핵심 개념
- 독립적인 배포
- 다른 마이크로서비스를 배포하지 않고도 마이크로서비스 변경/배포/출시가 가능해야 한다. 그러기 위해선 마이크로서비스 간 결합도를 최대한 낮춰야 한다.
- 도메인 중심으로 모델링
- 각 마이크로서비스는 도메인을 기준으로 구분해야 한다. 한 도메인의 기능 구현이 여러 마이크로서비스에 걸쳐 있으면 출시 비용이 증가
- 자신의 상태를 가짐
- 마이크로서비스는 DB를 공유하지 않는다. 다른 마이크로서비스의 데이터를 사용할 경우 DB에 직접 접근하지 않고 API 등을 통해 접근한다.
- 크기
- 크기에 기준은 없고, 조직이 감당할 수 있는 수준과 마이크로서비스 경계 정의가 필요
- 유연함
- 아키텍처와 조직을 맞춤
4. 이벤트 기반 아키텍처
이벤트 기반 아키텍처는 두 시스템 간에 통신할 때 이벤트를 사용하는 구조를 의미한다. 이벤트는 '주문함', '인증에 실패함' 같은 과거에 발생한 사실을 의미한다.
이벤트 기반 아키텍처의 3가지 구성요소는 다음과 같다.
- 이벤트 생산자
- 이벤트 소비자
- 이벤트 브로커(또는 라우터)

- 이벤트 생산자가 이벤트를 생성해 브로커에게 전달
- 브로커는 해당 이벤트에 관심있는 소비자에게 이벤트를 전달
- 이벤트 소비자는 이벤트를 받아 적절하게 반응한다.
이벤트는 변경된 데이터를 다른 시스템에 전달할 때 주로 사용된다. 예시로 주문 시스템에서 '결제 완료' 이벤트 발생 시 이벤트가 배송 시스템으로 전달되고, 배송 시스템은 전달받은 주문 정보를 바탕으로 배송을 시작한다.
알림 목적에도 사용할 수 있다.
잘못된 암호 반복 입력으로 로그인에 실패 -> 인증 시스템은 '인증 실패' 이벤트 발생 -> 이상 감지 시스템에서 비정상 접근 여부 판단
5. CQRS(Command Query Responsibility Segregation) 패턴
CQRS는 명령을 위한 모델과 조회를 위한 모델을 분리하는 패턴이다. 여기서 명령은 시스템의 상태를 변경하는 것을, 조회는 상태를 조회하는 것을 의미한다.

- 장점
- 각 기능에 맞게 모델을 구현해 모델 간 영향 도를 줄일 수 있다.
- 캐시를 적용하거나 조회 전용 DB를 확장함으로써 조회 모델 향상에도 용이하다.
- 단점
- 작업 코드가 증가한다. 추가 코드 대비 얻는 이점이 큰지 비교가 필요하다
- 구현 기술이 증가한다. 조회 전용 DB가 필요하고 서로 다른 DB 간의 데이터 동기화를 위해 추가적인 메시징 수단이 필요하다
'기타 > 책' 카테고리의 다른 글
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 13. NoSQL (0) | 2026.05.10 |
|---|---|
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 12. 성능 테스트 (0) | 2026.05.05 |
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 10. 네트워크 기초 (0) | 2026.05.03 |
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 9.2 서버 (0) | 2026.04.26 |
| [주니어 백엔드 개발자가 반드시 알아야 할 실무지식] 9.1 서버 (0) | 2026.04.26 |