나만의 아키텍처 구성하기

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

아키텍처 패턴

대상자

• 소프트웨어 아키텍처 설계자, 팀 리더, 중간 이상 개발자
• 중간~고급 난이도 (아키텍처 패턴 이해 및 선택 기준 필요)

핵심 요약

• 프로젝트 규모에 따라 아키텍처 선택:

- 1일 작업 → 모놀리식

- 1개월 → 계층형 아키텍처

- 3개월 이상 → 하위 도메인 모듈/서비스 분리 (예: SOA, 마이크로 서비스)

• 팀 수에 따른 아키텍처 적합성:

- 3개 이상 팀 → 서비스 기반 아키텍처 또는 파이프라인

- 공유 리소스 → 계층형 아키텍처 (병목 방지)

• 비기능 요구사항 처리 전략:

- 복제 (내결함성), 샤딩 (처리량), 공간 기반 아키텍처 (고성능)

- MVP/MVC, 전략 주입, 계층 구조 (지연 최소화)

섹션별 세부 요약

1. 프로젝트 규모에 따른 아키텍처 선택

• 모놀리식: 단일 프로세스 실행, 초기 개발 및 유지보수 용이
• 계층형 아키텍처: 도메인 로직과 비즈니스 로직 분리, 팀 병목 방지
• SOA/마이크로 서비스: 3개월 이상 프로젝트, 서비스 분리로 확장성 확보
• 파이프라인: 데이터/이벤트 중심 처리, 유연성 높음

2. 도메인 및 팀 구조 고려

• 하향식 계층 구조: 계층형 도메인에 적합, 팀별 모듈 독립 운영
• 오케스트레이터: 복잡한 글로벌 사용 사례 처리, 커지면 레이어/서비스로 분리
• 공유 저장 공간: 데이터 중심 시스템, 공간 기반 아키텍처 필요

3. 비기능 요구사항 대응

• 성능: 샤딩 (대규모 데이터 처리), 복제 (내결함성), 공간 기반 아키텍처 (메모리 복제)
• 확장성: 나노 서비스, 마이크로 서비스, 공간 기반 아키텍처
• 지연 최소화: MVP/MVC, 전략 주입, IIoT 계층 구조

4. 커스터마이징 및 확장성

• 플러그인: 제품 커스터마이징 필요 시 사용
• 헥사고날 아키텍처: 10년 이상 운영 시 공급업체 변경 가능
• 마이크로커널: 리소스/서비스 중개 시 사용

5. 의존성 관리 및 데이터 분석

• 부패 방지 계층: 서비스 간 상호 의존성 줄이기
• CQRS 뷰: 데이터 분석 대규모 시스템 구축 시 데이터 메시 구현 고려

결론

• 아키텍처 선택은 프로젝트 규모, 팀 수, 비기능 요구사항에 따라 유연하게 결정해야 하며, 모듈/서비스 분리, 복제, 샤딩 등 전략적 기술을 적절히 활용해야 합니다.
• 핵심 팁: 초기 설계 단계에서 서비스 경계 설정, 부패 방지 계층 도입, 공간 기반 아키텍처 적용을 고려하세요.