소프트웨어 아키텍처 설계 — 빠른 참조

이 스킬은 단일 서비스 또는 컴포넌트 내의 구현 세부 사항이 아닌 시스템 수준의 설계 결정을 위해 사용하세요.

빠른 참조

작업	패턴/도구	주요 리소스	사용 시기
아키텍처 스타일 선택	레이어드, 마이크로서비스, 이벤트 기반, 서버리스	modern-patterns.md	새로운 프로젝트, 대규모 리팩토링
확장 설계	로드 밸런싱, 캐싱, 샤딩, 읽기 복제본	scalability-reliability-guide.md	고트래픽 시스템, 성능 목표
탄력성 보장	회로 차단기, 재시도, 벌크헤드, 우아한 성능 저하	scalability-reliability-guide.md	분산 시스템, 외부 종속성
결정 문서화	아키텍처 결정 기록(ADR)	adr-template.md	주요 기술 결정, 트레이드오프 분석
서비스 경계 정의	도메인 주도 설계(DDD), 한정 컨텍스트(Bounded Context)	microservices-template.md	마이크로서비스 분해
데이터 일관성 모델링	ACID vs BASE, 이벤트 소싱, CQRS, 사가 패턴	data-architecture-patterns.md	다중 서비스 트랜잭션
관측 가능성 계획	SLI/SLO/SLA, 분산 추적, 메트릭, 로그	architecture-blueprint.md	프로덕션 준비
모놀리스에서 마이그레이션	Strangler Fig, 데이터베이스 분해, 섀도 트래픽	migration-modernization-guide.md	레거시 현대화
서비스 간 통신 설계	API 게이트웨이, 서비스 메시, BFF 패턴	api-gateway-service-mesh.md	마이크로서비스 네트워킹

이 스킬을 사용해야 하는 경우

다음 작업을 수행할 때 호출하세요:

시스템 분해: 모놀리스, 모듈러 모놀리스, 마이크로서비스 중 결정
아키텍처 패턴: 이벤트 기반, CQRS, 레이어드, 헥사고날, 서버리스
데이터 아키텍처: 일관성 모델, 샤딩, 복제, CQRS 패턴
확장성 설계: 로드 밸런싱, 캐싱 전략, 데이터베이스 확장
탄력성 패턴: 회로 차단기, 재시도, 벌크헤드, 우아한 성능 저하
API 계약: 서비스 경계, 버저닝, 통합 패턴
아키텍처 결정: ADR, 트레이드오프 분석, 기술 선택
마이그레이션 계획: 모놀리스 분해, Strangler Fig, 데이터베이스 분리

이 스킬을 사용하지 말아야 하는 경우

다음 작업에는 다른 스킬을 사용하세요:

단일 서비스 구현(라우트, 컨트롤러, 비즈니스 로직) → software-backend
API 엔드포인트 설계(REST 규칙, GraphQL 스키마) → dev-api-design
보안 구현(인증, 암호화, OWASP) → software-security-appsec
프론트엔드 컴포넌트 아키텍처 → software-frontend
데이터베이스 쿼리 최적화 → data-sql-optimization

의사 결정 트리: 아키텍처 패턴 선택

프로젝트 요구 사항: [새로운 시스템 또는 대규모 리팩토링]
    ├─ 단일 팀, 진화하는 도메인?
    │   ├─ 간단하게 시작 → 모듈러 모놀리스(명확한 모듈 경계)
    │   └─ 빠른 반복 필요 → 레이어드 아키텍처
    │
    ├─ 여러 팀, 명확한 한정 컨텍스트?
    │   ├─ 독립적 배포가 중요함 → 마이크로서비스
    │   └─ 공유 데이터 모델 → 서비스 모듈이 있는 모듈러 모놀리스
    │
    ├─ 이벤트 기반 워크플로우?
    │   ├─ 비동기 처리 → 이벤트 기반 아키텍처(Kafka, 큐)
    │   └─ 복잡한 상태 머신 → 사가 패턴 + 이벤트 소싱
    │
    ├─ 변동적/예측 불가능한 부하?
    │   ├─ 사용량 기반 과금 모델 → 서버리스(AWS Lambda, Cloudflare Workers)
    │   └─ 배치 처리 → 서버리스 + 큐
    │
    └─ 높은 일관성 요구 사항?
        ├─ 강력한 ACID 보장 → 모놀리스 또는 모듈러 모놀리스
        └─ 분산 데이터 → CQRS + 이벤트 소싱

결정 요소:

팀 규모 임계값: <10명의 개발자 → 모듈러 모놀리스가 마이크로서비스보다 일반적으로 더 나은 성능 발휘(운영 오버헤드)
팀 구조(Conway의 법칙) — 아키텍처는 조직 구조를 반영합니다.
배포 독립성 요구 사항
일관성 vs 가용성 트레이드오프(CAP 정리)
운영 성숙도(모니터링, 오케스트레이션)

자세한 패턴 설명은 references/modern-patterns.md를 참조하세요.

출력 지침

이 스킬의 참조 자료는 백그라운드 지식입니다. 패턴을 흡수하여 자신의 전문 지식으로 제시하십시오. 사용자에게 제공하는 출력에서 내부 참조 파일 이름(예: "data-architecture-patterns.md에서")을 인용하지 마십시오. 사용자는 이러한 파일의 존재를 알지 못합니다.

모든 아키텍처 권장 사항에는 다음이 포함되어야 합니다:

구체적인 기술 선택: 추상적으로 설명하지 말고 구체적인 기술 이름(예: "워크플로 오케스트레이션을 위한 Temporal.io", "Redis 어댑터를 사용한 Socket.io")을 명시하십시오. 사용자는 패턴을 이해하는 것뿐만 아니라 빌드 결정을 내려야 합니다.
구축하지 말아야 할 것: 연기하거나 피해야 할 사항을 명시적으로 지적하십시오. 시기상조의 범위 설정은 아키텍처 실수 #1입니다. 사용자가 이를 피하도록 도와주십시오.
팀 및 프로세스 정렬: 이 아키텍처가 팀 구조에 어떻게 매핑됩니까? 어떤 소유권 모델을 의미합니까? 관련된 경우 CODEOWNERS, 배포 소유권, 온콜 경계를 포함하십시오.
성공 메트릭: 팀이 아키텍처가 제대로 작동하는지 어떻게 알 수 있습니까? 측정 가능한 지표(배포 빈도, 리드 타임, 오류율, MTTR)를 포함하십시오.
집중된 길이: 모든 우려 사항을 빠짐없이 다루기보다 가장 중요한 3~5가지 결정에 깊이를 두십시오. 너무 길어서 읽을 수 없는 권장 사항은 따르지 않을 권장 사항입니다.

워크플로우 (시스템 수준)

사용자가 아키텍처 권장 사항, 분해 또는 주요 플랫폼 결정을 요청할 때 이 워크플로우를 사용하십시오.

명확히 하기: 문제 설명, 비-목표, 제약 조건, 성공 메트릭
품질 속성 파악: 가용성, 지연 시간, 처리량, 내구성, 일관성, 보안, 규정 준수, 비용
2~3개의 후보 아키텍처 제안 및 트레이드오프 비교
경계 정의: 한정 컨텍스트, 소유권, API/이벤트, 통합 계약
데이터 전략 결정: 스토리지, 일관성 모델, 스키마 진화, 마이그레이션
운영 설계: SLO, 장애 모드, 관측 가능성, 배포, 재해 복구, 인시던트 플레이북
범위 제한 사항 지적: 아직 구축하지 말아야 할 것, 연기해야 할 것, 구매할 것과 구축할 것
결정 문서화: 주요 트레이드오프 및 되돌릴 수 없는 선택에 대한 ADR 작성

선호하는 산출물 (요청에 맞는 것을 선택하십시오):

아키텍처 청사진: assets/planning/architecture-blueprint.md
결정 기록: assets/planning/adr-template.md
패턴 심층 분석: references/modern-patterns.md, references/scalability-reliability-guide.md

2026년 고려 사항

질문이 명시적으로 현재 트렌드, 공급업체별 제약 조건 또는 "X에 대한 최신 생각은 무엇인가요?"와 관련된 경우에만 로드하십시오.

references/architecture-trends-2026.md — 플랫폼 엔지니어링, 데이터 메시, 구성 가능한 아키텍처, AI 네이티브 시스템
data/sources.json — 카테고리별로 구성된 60개의 선별된 리소스:
- platform_engineering_2026 — IDP 트렌드, AI-플랫폼 수렴, Backstage
- optional_ai_architecture — RAG 패턴, 멀티 에이전트 설계, MCP/A2A 프로토콜
- modern_architecture_2025 — 데이터 메시, 구성 가능한 아키텍처, 지속적인 아키텍처

라이브 웹 접근이 가능한 경우 data/sources.json에서 2~3개의 권위 있는 소스를 참조하고 결과를 권장 사항에 반영하십시오. 그렇지 않은 경우 지속 가능한 패턴으로 답변하고 변경될 수 있는 가정(공급업체 제한, 가격, 관리형 서비스 기능)을 명시적으로 밝히십시오.

탐색

핵심 참조 자료

질문당 최대 2~3개의 참조 자료를 읽으십시오. 특정 질문에 가장 관련 있는 것을 선택하십시오. 모두 읽지 마십시오.

참조 자료	내용	읽어야 할 때
modern-patterns.md	의사 결정 트리가 포함된 10가지 아키텍처 패턴	패턴 선택 또는 비교
scalability-reliability-guide.md	CAP 정리, DB 확장, 캐싱, 회로 차단기, SRE	확장 또는 안정성 질문
data-architecture-patterns.md	CQRS 변형, 이벤트 소싱, 데이터 메시, 사가, 일관성	서비스 간 데이터 흐름
migration-modernization-guide.md	Strangler Fig, DB 분해, 기능 플래그, 위험 평가	모놀리스 리팩토링
api-gateway-service-mesh.md	게이트웨이 패턴, 서비스 메시, mTLS, 관측 가능성	서비스 간 통신
architecture-trends-2026.md	플랫폼 엔지니어링, 데이터 메시, AI 네이티브 시스템	현재 트렌드에 한함
operational-playbook.md	아키텍처 질문 프레임워크, 분해 휴리스틱	설계 논의 프레이밍

템플릿

계획 및 문서화 (assets/planning/):

architecture-blueprint.md — 서비스 청사진 (종속성, SLA, 데이터 흐름, 탄력성, 보안, 관측 가능성)
adr-template.md — 트레이드오프 분석을 위한 아키텍처 결정 기록

아키텍처 패턴 (assets/patterns/):

microservices-template.md — 마이크로서비스 설계 (API 계약, 탄력성, 배포, 테스트)
event-driven-template.md — 이벤트 기반 아키텍처 (이벤트 스키마, 사가 패턴, 이벤트 소싱)

운영 (assets/operations/):

scalability-checklist.md — 확장성 체크리스트 (DB 확장, 캐싱, 부하 테스트, 자동 확장, 재해 복구)

소프트웨어 아키텍처 설계