dev-architecture
기능 개발을 위한 아키텍처 설계 문서를 작성한다. AI가 기술 옵션 분석과 트레이드오프를 제시하고, 사용자가 기술 판단과 시스템 영향을 평가하여 결정한다. 사용 시점: "아키텍처 설계해줘", "기술 구조 잡아줘", "시스템 설계 시작하자", "/dev-architecture {기능명}" 등 아키텍처 단계 요청 시 트리거. PRD 문서(docs/dev-pro
SKILL.mdskills/dev-architecture/SKILL.md
GitHubdev-architecture
기능 개발의 두 번째 단계로, 시스템 구조와 기술 방향을 설계한다. AI가 기술 옵션과 트레이드오프를 분석하고, 사용자가 최종 기술 결정을 내린다.
Workflow
1. 선행 문서 및 코드베이스 분석
다음을 순서대로 확인한다:
docs/dev-process/PRD.md가 존재하면 읽어서 요구사항을 파악한다- 프로젝트 구조를 Glob으로 탐색한다 (package.json, go.mod, requirements.txt, Cargo.toml 등으로 기술 스택 파악)
- 기존 아키텍처 패턴을 코드에서 파악한다 (디렉토리 구조, 모듈 구성, 의존성 흐름)
PRD가 없으면 사용자에게 기능 개요를 직접 물어본다.
2. 정보 수집 — 1차 질문 (기술 맥락)
- 현재 사용 중인 기술 스택과 유지해야 할 제약은?
- 이 기능의 예상 트래픽/데이터 규모는? (해당 시)
- 특별히 고려해야 할 비기능 요구사항(성능, 보안, 확장성)은?
3. 정보 수집 — 2차 질문 (설계 방향)
1차 답변과 코드베이스 분석을 바탕으로:
- 기존 시스템에서 재사용하거나 확장할 부분은?
- 새로 도입을 검토 중인 기술이나 패턴이 있는가?
- 외부 시스템 연동이 필요한가? (API, 메시지 큐, 외부 서비스 등)
4. 기술 옵션 분석
주요 설계 결정 포인트별로 기술 옵션을 분석한다:
각 결정 포인트마다:
- 2~3개 옵션 제시
- 옵션별 장단점(Pros/Cons) 정리
- 현재 프로젝트 맥락에서의 추천과 근거
AI는 추천안을 제시하되, 최종 결정은 사용자에게 맡긴다.
5. 아키텍처 문서 작성
사용자의 결정을 반영하여 references/architecture-template.md 형식으로 문서를 작성한다.
작성 원칙:
- 구현 코드가 아닌 구조에 집중한다
- 컴포넌트 간 의존성과 데이터 흐름을 명확히 한다
- 기존 코드베이스와의 통합 지점을 구체적으로 명시한다
- 결정의 근거(ADR)를 반드시 기록한다
6. 리뷰 및 확정
초안을 사용자에게 보여주고:
- 기술 결정에 대한 최종 확인
- 누락된 컴포넌트나 연동 포인트 확인
- 시스템 영향 범위 검증
피드백을 반영하여 확정한다.
7. Output
docs/dev-process/ARCHITECTURE.md에 저장한다.
파일 저장 후 한 줄 요약과 함께 다음 단계(/dev-spec)를 안내한다.