🎯 아키텍처 접근을 ‘최소한의 단계’로 단순화하면 단 3단계다

✔ 1단계: “나는 무엇이 자주 바뀔까?”부터 찾기

✔ 2단계: “바뀌는 것을 어떻게 분리하지?”를 고민

✔ 3단계: “그걸 분리한 뒤 코드가 어떻게 생기지?”를 보는 것

단 3단계.
여기서 Clean Architecture나 Hexagonal이 자동으로 떠오름.


🔥 1단계: "자주 바뀌는 것"만 찾으면 70% 끝난다

아키텍처의 본질은 1개야:

변하는 것과 변하지 않는 것을 분리하기

실제로 네 MCP Hub 기준으로 보면:

✔ 자주 바뀌는 것

  • 모델 제공자(OpenAI, Anthropic, Groq...)
  • 툴(MCP Tool들: FS, DB, Web, GPU 등)
  • 클라이언트 타입(WebSocket, API)
  • DB나 캐시 기술
  • 스토리지 경로, 구성
  • API 스펙
  • 인증 전략

✔ 잘 안 바뀌는 것(핵심 로직)

  • 세션 관리
  • 메시지 라우팅
  • 메시지 이벤트 흐름
  • 모델 호출이라는 개념 자체
  • Tool 호출이라는 개념
  • 스트림 전달 규칙

이걸 찾으면 “아키텍처 선택”이 이미 끝난 거나 다름없어.

왜냐면:

  • 외부 의존성이 자주 바뀜 → Hexagonal / Clean
  • 내부 규칙 고정 → Domain 중심 설계
  • 스트림/이벤트 흐름 존재 → Event-driven 구조 필요

너의 프로젝트는 이 특징을 가짐 → 아키텍처 답이 자동으로 정해지는 것.


🔥 2단계: 바뀌는 것들은 “인터페이스로 추상화” 한다

아키텍처 이름은 어려워도 실제 개념은 한 줄임:

바뀌는 것들은 전부 인터페이스(Port)로 만들고, 실제 구현(Adapter)은 나중에 끼운다.

예시로:

 
# Port (추상화) class ModelProviderPort: async def stream(self, messages: list): ...
 
# Adapter (구현체) class OpenAIProvider(ModelProviderPort): async def stream(...): # openai 호출 코드
 
class GroqProvider(ModelProviderPort): async def stream(...): # groq 호출 코드

이렇게 구조가 자동으로 분리됨.

이게 바로 “헥사고날 아키텍처”고,
Clean Architecture의 핵심 규칙인 “의존성 역전 원칙”이야.

어려운 용어를 몰라도 패턴은 그냥 이렇게 생겨.


🔥 3단계: 실제 폴더 구조에 녹이면 Clean Architecture가 완성됨

단순하게 이렇게 나누면 끝이야:

 
app/ domain/ # 규칙(바뀌지 않는 것) application/ # 유즈케이스 ports/ # 추상화 인터페이스 adapters/ # 실제 구현 presentation/ # FastAPI 등 I/O

딱 여기까지만 이해하면 Clean Architecture가 90% 끝난 것.


🧘 비유로 한 번 더 설명해줄게 (완전 쉬운 버전)

🍔 햄버거 가게를 만든다고 해보자

바뀌는 것:

  • 패티 공급자
  • 소스 레시피
  • 매장 위치
  • POS 장비

바뀌지 않는 것:

  • 햄버거 만드는 규칙 (빵→패티→야채→소스)

그럼 어떻게 구조화할까?

  • “패티 공급자”는 인터페이스로 만들고 실제 공급업체끼리 교체 가능하게
  • “POS 장비”는 인터페이스로 만들고 실제 기기는 어댑터로 구성
  • 햄버거 조립 로직은 동일

이게 바로 Clean Architecture의 핵심 원리.

너는 그냥 “바뀌는 것들은 자리를 따로 마련해둔다”라고만 생각하면 돼.


🎯 그래서 너는 어디서 시작하면 되냐?

✔ 1) “내 프로젝트에서 자주 바뀌는 것 5개”만 적어

✔ 2) 그걸 “인터페이스(Port)”로 만들자

✔ 3) 나머지 “고정 규칙”은 domain/application에 둔다

끝.

 

🚀 디자인 패턴 vs 아키텍처 패턴은 원래 층위가 다르다

종류예시적용 범위
아키텍처 패턴 Clean, Hexagonal, MSA, Modular Monolith “애플리케이션 전체” 구조
디자인 패턴 Strategy, Adapter, Factory, Observer “코드 레벨” 해결책

 

 

🧭 아키텍처 패턴 선택 4단계 질문


⭐ 1) 프로젝트가 얼마나 커지고 복잡해지는가?

  • 팀원 많다
  • 기능 많다
  • 도메인 복잡하다

YES → Clean Architecture, Hexagonal, DDD
NO → 간단한 MVC / Lightweight 구조


⭐ 2) 외부 의존성이 자주 바뀌는가? (API, DB, 모델, SDK…)

  • GPT 바뀜
  • MCP Tool 바뀜
  • DB 교체될 수 있음
  • 저장소/네트워크 다양함

YES → Hexagonal Architecture(Ports & Adapters)
YES → Clean Architecture (역방향 의존성)


⭐ 3) 확장성과 유지보수가 중요한가?

  • 장기 운영 서비스
  • 기능이 지속 증가
  • 팀 별 책임 분리 필요

YES → Clean / Modular Monolith


⭐ 4) 서비스가 분산되어야 하는가?

  • 각 기능을 독립 배포
  • 트래픽 편차가 크다
  • 장애 격리가 중요

YES → MSA
NO → Modular Monolith 유지


📌 아키텍처 패턴 선택 기준 요약

필요 조건추천 아키텍처
내부/외부 의존성 변화가 많음 Hexagonal / Clean
코드 유지보수 + 명확한 책임 분리가 중요 Clean Architecture
점진적 확장이 중요 Modular Monolith
엄청 큰 서비스, 수십 팀 협업 MSA
스트리밍/이벤트 중심 Event-driven + Hexagonal

디자인 패턴 판단 흐름

문제 → 패턴 → 이유 → 적용

 

 

🧱 1단계: 프로젝트가 어떤 성질인지 먼저 파악하기

패턴을 결정하는 가장 중요한 기준 4가지.

✔ A. 변화가 많은가?

  • API가 자주 바뀜?
  • 모델 공급자(GPT, Anthropic 등) 계속 교체됨?
  • UI/플랫폼 여러 개?

전략 패턴, 어댑터 패턴, 퍼사드, 팩토리 패턴이 강함
(변화의 파도를 흡수하는 패턴들)


✔ B. 복잡한 로직/도메인이 많은가?

프로젝트가:

  • 복잡한 규칙
  • 여러 엔터티 상호작용
  • 추론/검증/상태관리

같이 복잡하면…

DDD, 상태 패턴, 커맨드 패턴, 체인 오브 리스판서빌리티
도메인 복잡성을 나누는 패턴들.


✔ C. 성능, 확장성, 분산 처리 중요한가?

  • 모델 스트리밍
  • 이벤트 기반 시스템
  • 고속 처리

옵저버, 이벤트 버스 패턴, 파이프라인 패턴, 싱글톤(캐시)
성능·대량 처리를 돕는 패턴들.


✔ D. 구성요소를 갈아끼우는 구조인가?

너처럼:

  • 모델 제공자 바뀌고
  • MCP 도구 연결되고
  • GPU 노드 선택되고

이런 경우…

어댑터, 전략, 포트/어댑터(헥사고날), DI/IoC
다른 구현체를 쉽게 갈아끼우게 해줌.


🔍 요약하면 패턴을 선택하는 기준은 딱 4가지

항목내용대표 패턴
변화 외부 API, 정책, 구현체가 자주 바뀜 전략, 어댑터, 팩토리
복잡성 도메인/규칙이 많음 DDD, 상태, 커맨드
성능 대량 이벤트·스트리밍 옵저버, 이벤트 버스
확장성 모듈 교체 필요 헥사고날, DI, 인터페이스

🧩 2단계: 프로젝트에서 문제가 되는 지점을 찾아라

디자인 패턴은 문제를 해결하기 위한 도구이기 때문에
항상 문제부터 출발해야 한다.

예를 들어:

 
- 모델 제공자(API)가 계속 추가/삭제되고 - 클라이언트/툴 종류가 많고 - 스트리밍 처리 복잡하고 - 상태 관리 필요

→ 이 문제를 보면

  • 외부 의존성 변화 → 전략/어댑터
  • 스트리밍 이벤트 → 옵저버/이벤트버스
  • 모델/툴 교체 구조 → 포트/어댑터
  • 로직 복잡 → DDD-lite

자연스럽게 매핑됨.


🧪 3단계: 디자인 패턴은 32개 → 실제로 자주 쓰는 건 8개만

현업에서 정말 '계속 쓰는' 패턴은 아래 8개야.

★ 핵심 GoF 패턴 (정말 자주 사용됨)

  • Strategy (전략)
  • Adapter (어댑터)
  • Factory / Abstract Factory
  • Observer (옵저버)
  • Decorator
  • Facade
  • Command
  • Singleton(캐시용)

솔직히 이 8개만 마스터하면 충분함.

나머지는 특별한 상황에서만 필요해.


🧭 4단계: 패턴 선택 체크리스트 (바로 적용 가능)

아래 질문 중 YES가 많을수록 그 패턴은 적합함.


✔ Strategy 패턴이 필요한 경우?

  • 알고리즘(또는 선택 로직)을 교체해야 한다.
  • 모델 공급자(GPT, Anthropic 등)가 자주 바뀐다.
  • 정책이 자주 수정된다.

✔ Adapter 패턴이 필요한 경우?

  • 기존 코드에 새로운 API/SDK 연결해야 한다.
  • 동일한 인터페이스로 여러 구현체를 감싸야 한다.

✔ Factory 패턴이 필요한 경우?

  • 객체 생성 로직이 복잡하거나 환경에 따라 달라진다.
  • 여러 종류의 모델/도구를 동적으로 생성해야 한다.

✔ Observer / EventBus 패턴이 필요한 경우?

  • 이벤트 기반 처리 (Tool → Hub → Client)
  • 스트리밍
  • 알림/상태 변경

✔ Command 패턴이 필요한 경우?

  • "명령" 단위로 작업을 관리하고 싶다.
  • Tool Execution, Model Call 등을 같은 형태로 다루고 싶다.

✔ Decorator 패턴이 필요한 경우?

  • 기능을 동적으로 증/감하고 싶다.
    • 예: 로깅, 인증, 모니터링, 캐싱

✔ Facade 패턴이 필요한 경우?

  • 복잡한 것을 단순한 API로 감싸고 싶다.
  • 외부에 “간단한 인터페이스”만 주고 싶다.

💡 실제로 패턴을 고르는 사고 흐름 예시

🧩 당신의 MCP Hub에 적용하면?

문제 → 패턴을 매핑해보면:

● 모델/API 여러 개 → Strategy + Adapter

● MCP Tool 여러 종류 → Adapter + Factory

● 스트리밍 이벤트 → Observer(EventBus)

● Tool 호출/Model 호출 모두 command 단위 → Command Pattern

● 복잡도 증가 → DDD-lite

● 외부와 내부 분리 → Hexagonal (Ports/Adapters)

이렇게 자연스럽게 답이 나오게 됨.


🎉 결론:

디자인 패턴 선택은
프로젝트 성질 → 문제 포인트 → 패턴의 목적
이 3개만 연결하면 끝

1️⃣ Clean Architecture (클린 아키텍처)

가장 많이 언급되고 가장 이상적으로 여겨지는 구조.

✔ 특징

  • 비즈니스 로직(도메인)이 프레임워크, DB에 의존하지 않음
  • 테스트 용이
  • 서비스 규모가 커질수록 유지보수가 편함

✔ 어디서 많이 쓰나?

  • 스타트업 ~ 대기업까지 전 범위
  • Python FastAPI, Node.js NestJS, Java Spring 등 대부분 적용 가능

2️⃣ Hexagonal Architecture (헥사고날 / Ports & Adapters)

클린 아키텍처와 비슷하지만 조금 더 실용적.

✔ 특징

  • 내부 로직 — 외부 I/O(DB, 메시지 큐, API) 완전 분리
  • 외부 시스템이 바뀌어도 핵심 로직 수정 없음

✔ 어디서 쓰나?

  • 쿠버네티스 기반 MSA
  • 금융권, 물류, 물류 자동화 시스템에서 많이 채택

3️⃣ Domain-Driven Design (DDD) + Layered Architecture

대기업과 MSA 환경에서 가장 인기 있음.

✔ 특징

  • 복잡한 도메인을 도메인 모델 중심으로 설계
  • 비즈니스 로직을 중심으로 모듈링
  • 전략 패턴, 어그리게이트, 이벤트 기반 설계와 결합됨

✔ 어디서?

  • 마이크로서비스, 플랫폼 서비스
  • Java/Spring + DDD가 가장 흔함

4️⃣ Microservices Architecture (MSA)

모놀리스를 쪼개는 아키텍처.

✔ 2025년 기준 트렌드

  • 무분별한 MSA는 퇴조
  • 핵심 서비스만 MSA, 나머지는 모놀리스 유지(모듈러 모놀리스)
  • 즉, 선택적 MSA가 대세

5️⃣ Modular Monolith (모듈러 모놀리스) — 요즘 가장 현실적 대세

MSA보다 훨씬 현실적이고 유지보수 쉬움.

✔ 장점

  • 모놀리스처럼 쉬움 + MSA처럼 독립성
  • 배포/운영 비용 저렴
  • 스타트업, 중견 회사에서 리얼 대세

6️⃣ Event-Driven Architecture (EDA)

Kafka, NATS, RabbitMQ 등 기반의 이벤트 중심 구조.

✔ 대세 이유

  • 실시간 데이터 처리
  • 서비스 간 결합도 낮음
  • AI 파이프라인, 분석 시스템 필수

7️⃣ Serverless + FaaS 아키텍처

AWS Lambda, Cloud Functions 중심.

✔ 최근 트렌드

  • 백엔드 전부 서버리스는 힘들다
  • 부분적으로 도입하는 기업이 많음
    • 이미지 처리
    • 파일 파이프라인
    • 알림/배치 작업

2023.04.01 예측 (초기모델)

- 예측 : 22 26 31 35 38 

- 실제 : 4 24 27 35 37 45 15

- 평가

* 정답 35

* 1차이 : 26(27), 38(37)

* 2차이 : 22(24)

 

2023.04.08 예측 (성능 고도화 모델)

- 예측 (Train / Val set 다르게 적용)

8 14 19 25 31 35 21

8 15 19 24 30 38 23

- 실제 : 예정

- 평가 : 예정

문제

자체 구성한 nifi의 restapi에 curl을 쉽게 날리기 위하여 Postman을 사용하여 진행하고자 함.

Postman에서 curl을 날렸을 때 nifi api에서 certificate exired가 떠서, SSL인증서를 새롭게 만들어 넣으려 함.

 

1. certificate nifi에 설치

nifi home으로 사용할 경로에 nifi-toolkit-[사용할 버전]을 받는다.

nifi toolkit download 받고 압축 푼 후 사진

1-1 toolkit download (버전은 자유롭게 바꿔서 받아도 무방)

wget https://archive.apache.org/dist/nifi/1.6.12/nifi-toolkit-1.6.12-bin.tar.gz

 

1-2 압축 해제

tar zxvf nifi-toolkit-1.16.2-bin.tar.gz

1-3 위치 이동

cd $NIFI_HOME/nifi-toolkit-1.16.2/bin

1-4 toolkit을 사용하여 nifi 인증서를 생성

./tls-toolkit.sh standalone -n 'localhost' -C 'CN=cnName, OU=nifi' -O -o $NIFI_HOME/nifi-1.16.2/conf

1-5 만들어진 conf 폴더 내에 localhost folder가 생성되었을 것

1-6 /nifi-1.16.2/conf에 이미 keystore.jks, truststore.jks, nifi.properties가 있기 때문에 기존에 있던 파일들을 backup한 후에 .jks 파일은 옮기고, nifi.properties는 변경된 부분만 merge한다.

*nifi.properties에서 아래 부분을 변경하지 않으면 새로운 인증서가 적용되지 않음.

merge 부분

*nifi.cluster.protocol.is.secure=true도 설정하면 좋음

 

1-7 추가로 authorizers.xml을 backup 후에

userGroupProvider : Initial User Identity 

accessPolicyProvider : Initial Admin Identity에 CN정보와 OU정보를 넣을 것

<identifier>file-user-group-provider</identifier>
...
<property name="Initial User Identity 1">CN=cnName, OU=nifi</property>
...
<identifier>file-access-policy-provider</identifier>
...
<property name="Initial Admin Identity">CN=cnName, OU=nifi</property>

 

1-8 nifi 재기동하면, 정상 적용 확인 가능

 

2. anonymous authentication has not been configured. 문제

nifi.properties 파일에서 아래 부분 false -> true로 변경

 

 

3. self-signed certificate 때문에 나는 오류

SSL certificate verification ON -> OFF로 변경

 

 

+ Recent posts