카테고리로 나눈 네트워크 디자인 패턴 총 정리

네트워크 디자인 패턴

분산 시스템 혹은 네트워크 기반 애플리케잇녀 설계 시 자주 사용되는 구조적인 해결책

다양한 서비스 통신, 데이터 흐름, 확장성을 고려한 효율적인 설계를 지원

 

- 구성요소

클라이언트 (요청을 전송하고 결과를 수신하는 주체)

서버 (클라이언트 요청을 처리하고 응답을 반환)

미들웨어 (클라이언트와 서버 간 데이터 반환, 로깅, 보안 등을 처리)

네트워크 프로토콜 (데이터 전송을 규정하는 규약)

로드밸런서 (서버 간 부하를 분산하여 성능 최적화)

프록시 (클라이언트의 요청을 대신 서버로 전달하고 서버의 응답을 다시 클라이언트로 전달)

 

- 참고

네트워크 디자인 패턴은 소프트웨어 개발 디자인 패턴처럼 GoF와 같은 정형화된 패턴은 없으나 본 글에서는 카테고리를 나눠서 묶어봄

 

 

 

 

 

통신 구조 패턴

어떻게 데이터를 주고 받는가에 초점

 

 

Client-Server

클라이언트와 서버 간 명확한 역할 분담

중앙 집중식 구조로 데이터와 비즈니스 로직이 서버에 집중

HTTP, 웹소켓, FTP 등 다양한 프로토콜 사용

 

- 사용 시기

다수의 클라이언트가 하나의 데이터 소스(서버)를 공유해야 할 때

웹 애플리케이션, 모바일 애플리케이션, IoT 시스템 등 네트워크 기반 서비스를 설계 할 때

데이터 및 로직의 중앙 집중화가 필요할 때

 

 

Peer-to-Peer

네트워크에 연결된 모든 노드가 동등한 지위를 가지는 형태

중앙 서버 없이 노드 간 직접 통신으로 데이터를 교환

각 노드는 클라이언트이자 서버 역할을 동시에 수행

 

- 사용 시기

네트워크의 특정 노드에 의존하지 않고 높은 가용성을 유지해야 할 때

데이터 분산 저장이나 파일 공유 분산 컴퓨팅이 필요할 때

 

 

Publish-Subscribe

메시지 발행자 (Publisher)와 구독자 (Subscriber)가 직접적으로 연결되지 않고 중앙 브로커(메시지 큐 등)를 통해 통신

발행자는 특정 주제나 이벤트에 대해 메시지를 발행

구독자는 관심있는 주제나 이벤트를 구독하고 해당 메시지만 수신

비동기적으로 작동하여 느슨한 결합과 확장성을 제공

 

- 사용 시기

비동기적 데이터 처리와 이벤트 기반 설계가 필요할 때

다수의 클라이언트가 동일한 데이터를 수신해야할 때

마이크로서비스 환경에서 서비스 간 의존도를 낮추고 싶을 때

 

 

Event-Driven

이벤트를 중심으로 시스템이 동작하는 구조

이벤트는 특정 작업이나 상태 변화가 발생했을 때 생성

이벤트가 발생하면 이를 처리하기 위한 이벤트 핸들러가 실행됨

비동기적으로 반응형 특정을 가짐

마이크로 서비스, 실시간 데이터 처리 시스템에서 많이 사용

 

- 사용 시기

비동기 처리와 실시간 반응성이 필요한 경우

상태 변화나 작업 완료를 기준으로 특정 로직을 실행해야할 때

마이크로서비스 간 느슨한 결합과 독립적 확장을 원할 때

로그 처리, 알림 서비스, 주문 처리 시스템 등 이벤트 기반 워크플로우가 필요한 경우

 

 

Request-Response

클라이언트가 요청(Request)를 보내고 서버가 응답(Response)을 반환하는 동기적인 통신 패턴

클라이언트는 요청을 보낸 후 응답이 올 때까지 기다림

웹 애플리케이션에서 가장 일반적으로 사용되는 패턴

 

- 사용 시기

클라이언트가 명확한 요청을 보내고 그에 따른 응답이 필요한 경우

데이터 생성(Create), 읽기(Read), 수정(Update), 삭제(Delete)와 같은 작업

사용자 인터페이스가 동작에 대한 즉각적인 피드백을 제공해야 할 때

 

 

Message-Queue / Broker

메시지 전달을 위해 브로커(Broker)를 중심으로 동작하는 비동기 패턴

생산자(Producer)가 메시지를 생성하고 큐(Queue)에 추가

소비자(Consumer)가 큐에서 메시지를 가져와 처리

비동기적이고 느슨하게 결합된 구조를 제공하여 시스템 확장성과 유연성을 높임

 

- 사용 시기

시스템 간 데이터 전달을 효율적으로 처리해야할 때

비동기적인 작업 처리가 필요할 때

데이터 처리 부하를 분산하거나 소비자가 메시지를 개별적으로 처리해야할 때

대규모 분산 시스템에서 구성 요소 간의 독립성을 유지하고 싶을 때

 

 

 

 

 

트래픽 관리 및 인프라 패턴

성능, 확장성, 장애 대응에 집중

 

 

Load Balancing

하나의 서버에 집중되는 부하를 분산하여 여러 서버가 작업을 처리할 수 있도록 설계된 패턴

클라이언트 요청을 여러 서버로 분배하여 시스템의 성능, 안정성, 가용성을 높임

주로 네트워크 레벨에서 동작하며 로드밸런서라는 중간 장치나 소프트웨어가 중심 역할을 수행

 

- 사용 시기

트래픽이 급격히 증가하거나 고가용성이 요구될 때

여러 서버에서 동일한 서비스를 제공하며 부하를 균등하게 분배하고 싶을 때

서버의 장애 발생 시 자동으로 요청을 다른 서버로 라우팅 하고 싶을 때

 

 

Proxy

클라이언트와 서버 사이에 위치한 프록시를 통해 클라이언트의 요청을 대신 처리

클라이언트는 프록시를 통해 서버와 통신하며 서버의 직접적인 위치나 정보를 알 필요가 없음

주로 보안, 캐싱 익명성 보장, 트래픽 필터링에 사용됨

 

- 사용 시기

클라이언트의 IP를 숨기고 익명성을 보장해야할 때

캐싱을 통해 요청 속도를 높이고 리소스 사용량을 줄이고 싶을 때

특정 요청을 필터링하거나 제한해야 할 때

 

 

Reverse Proxy

서버와 클라이언트 사이에 위치하여 서버의 요청을 대신  처리하는 중간자 역할

클라이언트는 역방향 프록시를 실제 서버로 인식

주로 부하 분산, SSL 종료, 요청 라우팅, 보안 강화 등에 사용 됨

 

- 사용 시기

여러 서버로 트래픽을 분산하여 부하를 줄이고 싶을 때

외부 트래픽을 보호하고 보안 위협을 줄이고 싶을 때

SSL 인증서를 관리 및 처리하고 싶을 때

클라이언트가 내부 서버의 위치나 정보를 알지 못하도록 숨기고 싶을 때

 

 

Circuit Breaker

서비스 간 호출에서 장애를 방지하기 위해 사용하는 보호 메커니즘

장애가 발생했을 때 실패를 빠르게 감지하고 차단하여 시스템의 다른 부분에 영향이 확산되지 않도록 함

전기 회로의 차단기와 비슷하게 동작하며 장애가 발생하면 차단하여 요청을 멈춤

 

- 사용 시기

마이크로 서비스 환경에서 서비스 간 호출이 빈번한 경우

호출 대상 서비스나 네트워크의 응답 속도가 느려지고 장애가 발생할 가능성이 높을 때

장애 전파를 장비하여 시스템의 다른 서비스가 영향을 받지 않도록 보호하고 싶을 때

 

 

Service Discovery

서비스 간의 통신에서 동적으로 위치를 검색하고 연결할 수 있도록 하는 패턴

마이크로서비스 환경에서 각 서비스가 동적으로 스케일링 되거나 변경 될 때 유용

서비스의 위치(IP, 포트)를 고정하지 않고 서비스 레지스트리에 등록하여 관리

 

- 사용 시기

마이크로 서비스 환경에서 개별 서비스의 위치가 고정되지 않을 때

컨테이너 오케스트레이션 플랫폼에서 서비스 디스커버리를 사용해야할 때

수많은 서비스가 존재하고 이들 간의 통신이 빈번한 시스템에서

 

 

Rate Limiting

서비스 요청 횟수를 제한하여 시스템 과부하를 방지하고 공정환 자원 사용을 보장

주로 API 서버, 웹 애플리케이션, 마이크로서비스에서 클라이언트 별 요쳥을 제어하는데 사용됨

한정된 리소스를 보호하고 악성 요청을 차단하는데 효과적

 

- 사용 시기

API 요청이 특정 시간 동안 과도하게 증가할 가능성이 있을 때

특정 클라이언트가 서비스 자원을 독점하거나 악요하는 것을 방지하고 싶을 때

유료 서비스에서 요금제 별 요청 한도를 설정해야 할 때

백엔드 서버 보호가 필요할 때

 

 

CDN (Content Delivery Network) 사용 패턴

콘텐츠 (이미지, 동영상, HTML 파일 등)를 사용자의 지리적 위치와 가까운 서버에서 제공하여 로딩 속도를 최적화

주로 정적 콘텐츠를 빠르게 제공하고 원본 서버의 부하를 줄이기 위해 사용

글로벌 네트워크를 통해 캐싱 및 분산된 데이터를 제공

 

- 사용 시기

대규모 트래픽을 처리해야하는 경우

정적 콘텐츠를 효율적으로 배포해야할 때

웹 사이트의 로딩 속도를 개선하여 사용자 경험을 향상시키고 싶을 때

DDos 공격이나 갑작 스러운 트래픽 스파이크로 부터 원본 서버를 보호해야할 때

 

 

 

 

 

보안 및 접근 제어 패턴

안전한 네트워크 통신을 위한 설계

 

Gateway / API Gateway

클라이언트 요청을 하나의 진입점(게이트웨이)로 수렴하고 내부 마이크로 서비스로 요청을 분산 시키는 패턴

클라이언트는 여러 마이크로 서비스를 개별적으로 호출하지 않고 API Gateway를 통해 요청을 처리

일반적으로 로드 밸런싱, 인증, 요청 라우팅, 데이터 변환, 캐싱 등의 기능을 수행

 

- 사용 시기

마이크로서비스 아키텍처에서 서비스 간의 복잡성을 클라이언트에서 감추고 싶을 때

클라이언트와 서비스 간의 통합된 인터페이스를 제공하고 싶을 때

요청을 중앙에서 관리하여 보안, 성능, 로깅 등을 일관성 있게 적용하고 싶을 때

클라이언트 디바이스 별로 요청 포맷을 조정해야할 때

 

 

Authentication Proxy

클라이언트와 백엔드 서비스 사이에 프록시 역할을 하는 인증 전용 프록시를 두는 형태

클라이언트 요청이 백엔드 서비스에 도달하기 전에 인증 과정을 수행

주로 OAuth, SAML, OpenID Connect와 같은 인증 프로토콜을 지원하며 JWT 토큰 검증 등의 역할도 포함

인증 실패 시 요청을 백엔드로 전달하지 않고 클라이언트에게 에러 응답

 

- 사용 시기

단일 인증 로직 관리가 필요할 때

모든 요청에 대해 중앙에서 인증 제어가 필요할 때

멀티테넌트 환경에서 테넌트 별 인증 정책을 관리해야할 때

웹 애플리케이션이나 API에 접근하는 클라이언트를 인증하고 싶을 때

 

 

Zero Trust Network Architecture (ZTNA)

네트워크 경계(내부/외부)를 신뢰하지 않고 모든 요청과 리소스 접근에 대해 인증 및 권한 검증을 수행

사용자, 디바이스, 애플리케이션, 네트워크 상태를 기반으로 세부적인 보안 정책 적용

동적 보안 평가와 세분화된 권한 제어가 핵심

 

- 사용 시기

원격 근무가 활성화 되어 네트워크 내부와 외부의 경계가 희미해졌을 때

민감한 데이터를 다루는 환경에서 내부 위협이나 데이터 유출 방지가 필요할 때

클라우드 환경이나 멀티테넌트 인프라에서 동작하는 시스템 보안 강화가 필요할 때

규제 준수가 요구되는 산업에서 엄격한 보안 관리가 필요할 때

 

- 구성요소

정체성 및 접근 관리 (IAM / Identity & Access Management)

> 사용자 및 디바이스의 정체성을 검증하고 세분화된 접근 권한 부여

 

디바이스 보안 

> 디바이스 상태를 검증하여 관리 대상 디바이스만 네트워크에 접근 허용

> ex) 디바이스 헬스 체크, MDM

 

애플리케이션 계층 보안

> 애플리케이션 및 데이터 레벨에서 접근 제어 정책을 적용

> ex) API Gateway, WAF

 

모니터링 및 로깅

> 모든 활동을 실시간으로 모니터링 및 기록

> ex) SIEM, 행동 분석 도구

 

 

Token-Based Access (OAuth2, JWT)

클라이언트가 서버에 로그인하거나 인증을 하면 서버가 토큰을 발급

클라이언트는 이후 요청 시 이 토큰을 포함해 인증을 증명

서버는 토큰을 검증해 요청을 허용하거나 거부함

토큰은 stateless 수 있어 서버 확장성에 유리

 

- 사용 시기

RESTful API 같은 stateless 통신 환경에서 인증이 필요할 때

여러 서비스 또는 도메인에서 인증 정보를 공유해야할 때

모바일 앱, SPA (Single Page Application) 등 클라이언트-서버 분리 구조에서 인증 관리가 필요할 때

세션 저장소를 줄이고 서버 확장성을 높이고자 할 때 

 

 

 

 

 

구성 및 확장 패턴

네트워크가 유연하고 확장 가능하도록 구성하는 방식

 

Microservices

애플리케이션을 작고 독립적인 여러 서비스로 나누어 설계하는 아키텍처 패턴

각 서비스는 고유한 비즈니스 기능을 담당하며 독립적으로 개발, 배포, 확장 가능

서비스 간에는 주로 경량 프로토콜(HTTP / gRPC 등)로 통신

데이터 저장소도 서비스마다 독립적일 수 있음

 

- 사용 시기

애플리케이션이 커져서 단일 모놀리식 구조가 유지보수, 확장에 어려움이 있을 때

여러 팀이 동시에 개발해야 하거나 독립적인 배포가 필요할 때

기능별로 분리된 서비스가 서로 다른 기술 스택이나 배포주기를 가질 때

빠른 확장성과 유연한 장애 격리가 필요할 때

 

 

Service Mesh

마이크로서비스 환경에서 서비스 간 통신을 관리하는 인프라 계층 패턴

네트워크 통신, 보안, 로깅, 모니터링, 트래픽 관리 같은 기능을 서비스 코드와 분리하여 처리

각 서비스에 사이드카 프록시를 배포해 서비스 간 통신을 투명하게 제어

중앙 집중식 제어 평면(Control Plane)을 통해 정책 설정과 관리를 수행

 

- 사용 시기

마이크로 서비스가 많아져서 서비스 간 통신이 복잡해질 때

서비스 간 보안이 중요해질 때

트래픽 제어 및 관찰성을 강화하고 싶을 때

개발자가 서비스 코드 수정 없이 네트워크 정책을 유연하게 관리하고 싶을 때

 

- 구성요소

사이드카 프록시 (Sidecar Proxy)

> 각 서비스 인스턴스에 함께 배포되는 프록시

> 모든 인바운드/아웃바운드 트래픽을 가로채어 관리

 

제어 평면 (Control Plane)

> 전체 서비스 메시를 관리하고 정책을 배포하는 중앙 관리자

> 서비스 둥록, 트래픽 관리 정책, 인증서 발급 등을 수행

 

데이터 평면 (Data Plane)

> 사이트카 프록시들의 트래픽을 직접 처리하는 계층

 

 

Sidecar Pattern

주 애플리케이션 서비스와 별도로 배포되는 보조 컴포넌트를 의미

주 서비스와 같은 호스트 (컨테이너/VM)에 함께 배포되어 주 서비스의 기능을 보완하거나 확장

주로 네트워크 관련 기능 (로깅, 모니터링, 프록시, 보안 등)을 분리해 독립적으로 관리

마이크로 서비스 환경에서 서비스 메시의 사이드카 프록시가 대표적인 예

 

- 사용 시기

주 애플리케이션 코드 변경 없이 보조 기능을 추가할 때

네트워크 트래픽 관리, 보안, 로깅, 모니터링 기능을 분리하고 싶을 때

여러 서비스에서 공통 기능을 일관되게 적용해야 할 때

독립적 확장 및 업데이트가 필요한 부가 기능이 있을 때

 

 

Multi-tier Architecture (3-tier 등)

애플리케이션을 기능 별로 여러 계층으로 분리

일반적으로 3계층이 많이 사용되며, 각 계층을 독립적으로 동작

각 계층은 서로 다른 책임과 역할을 가지고 서로 통신하며 전체 애플리케이션 동작을 완성

계층 간 인터페이스가 명확해 유지보수와 확장에 유리함

 

- 사용 시기

복잡한 비즈니스 로직을 분리하여 관리할 필요가 있을 때

사용자 인터페이스, 비즈니스 로직, 데이터 저장소를 구분해 개발 및 운영 할 때

대규모 애플리케이션이나 엔터프라이즈 시스템에서 성능, 보안, 확장성을 고려할 때

팀 간 역할 분담과 독립적, 개발/배포가 필요한 상황