리고니

아키텍처 접근 고찰

리고니 — Wed, 26 Nov 2025 11:45:30 +0900

아키텍처 접근을 ‘최소한의 단계’로 단순화하면 단 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에 둔다

끝.

아키텍처 패턴 판단

리고니 — Wed, 26 Nov 2025 11:44:02 +0900

디자인 패턴 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

디자인 패턴 판단

리고니 — Wed, 26 Nov 2025 11:28:38 +0900

디자인 패턴 판단 흐름

문제 → 패턴 → 이유 → 적용

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개만 연결하면 끝

요즘 가장 대세인 소프트웨어 아키텍처 TOP 7

리고니 — Wed, 26 Nov 2025 09:32:46 +0900

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 1주차, 2주차 AI 로또 번호 예측

리고니 — Thu, 6 Apr 2023 17:36:12 +0900

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] nifi SSL인증서 설치 및 portman anonymous authentication has not been configured. 해결

리고니 — Thu, 18 Aug 2022 19:38:08 +0900

문제

자체 구성한 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로 변경