architecture
아키텍처 결정 프레임워크
이 스킬은 구조화된 트레이드오프 분석과 ADR 문서화를 통해 팀이 더 나은 아키텍처 결정을 내리는 것을 도와줍니다. 결정 트리, 패턴 지침, 그리고 근거와 함께 아키텍처 선택을 문서화하는 템플릿을 제공합니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"architecture" 사용 중입니다. 1 명의 개발자로 MVP 이커머스 앱의 아키텍처를 계획하는 것을 도와주세요
예상 결과:
1 인 개발자 MVP 의 경우 다음을 권장합니다: Next.js 를 사용한 모놀리식 구조, 데이터 액세스용 Prisma, JWT 인증, PostgreSQL 데이터베이스, 결제용 Stripe. 트레이드오프: 독립적 확장 제한, 필요시 나중에 서비스 추출 가능.
"architecture" 사용 중입니다. MongoDB 대신 PostgreSQL 선택에 대한 ADR 생성
예상 결과:
ADR 템플릿: 컨텍스트 - 신뢰할 수 있는 트랜잭션 데이터 필요. 고려된 옵션: PostgreSQL (ACID, 복잡한 쿼리) vs MongoDB (유연성, 수평 확장). 결정: PostgreSQL. 근거: 이커머스는 트랜잭션 무결성 필요. 수용된 트레이드오프: 초기에 덜 유연한 스키마.
보안 감사
안전All static findings are false positives. The skill is a documentation guide for architectural decision-making. Detected patterns are markdown formatting (backticks), authentication standards (SAML, JWT), and normal decision-making terms (validate). No actual security risks identified.
중간 위험 문제 (1)
낮은 위험 문제 (3)
품질 점수
만들 수 있는 것
새 프로젝트 아키텍처 기획
새로운 프로젝트를 시작할 때, 이 스킬을 사용하여 팀 규모, 확장성 요구사항, 일정 제약을 기반으로 적절한 아키텍처를 결정합니다.
아키텍처 결정 문서화
중요한 아키텍처 선택을 할 때, ADR 템플릿을 사용하여 컨텍스트, 고려된 옵션, 결정 근거, 수용된 트레이드오프를 기록합니다.
패턴 선택 지침
어떤 아키텍처 패턴을 사용할지 불확실할 때, 결정 트리를 참조하여 모놀리식 vs 마이크로서비스, REST vs GraphQL 등의 옵션 간 트레이드오프를 평가합니다.
이 프롬프트를 사용해 보세요
[team size] 명의 개발자와 함께 [project type] 을 위한 아키텍처를 정의하는 것을 도와주세요. [user scale] 명의 사용자를 목표로 하며, 일정은 [timeline] 입니다. 예산은 [budget constraint] 입니다. 아키텍처 스킬을 사용하여 이 결정을 가이드하세요.
[technology/pattern] 을 대안 대신 선택하는 ADR 을 생성하세요. 컨텍스트는 [problem description] 입니다. 이러한 제약 조건을 고려하세요: [list constraints]. 아키텍처 스킬의 트레이드오프 분석 프레임워크를 사용하세요.
[team size] 명의 개발자와 함께 [project description] 에 대해 마이크로서비스와 모놀리식 아키텍처 중 어떤 것을 선택할지 결정하는 것을 도와주세요. 트레이드오프는 무엇인가요? 각각의 접근 방식이 언제 정당화되나요?
[complexity level] 데이터 액세스 요구사항을 가진 [project type] 에 대해 어떤 데이터 액세스 패턴을 권장하시나요? 고려 사항: 팀 규모는 [size], 테스트 요구사항은 [level], 데이터 소스는 [sources] 를 포함합니다.
모범 사례
- 현재 요구사항을 충족하는 가장 간단한 아키텍처로 시작하고, 입증된 경우에만 복잡성을 추가합니다
- 항상 트레이드오프를 문서화하세요 - 모든 아키텍처 선택에는 명시되어야 하는 비용과 이점이 있습니다
- ADRs 를 사용하여 결정된 내용뿐만 아니라 그 이유, 그리고 선택에 영향을 미친 제약 조건도 기록하세요
- 패턴 선택 시 팀의 전문성을 고려하세요 - 팀이 유지보수할 수 없다면 최고의 패턴도 쓸모없습니다
피하기
- 조기 마이크로서비스 - 팀 규모나 확장성이 복잡성을 정당화하기 전에 서비스를 분할
- 간단한 CRUD 로 충분한 경우 Clean/Hexagonal 아키텍처로 과도한 추상화
- 이점을 보여주는 읽기/쓰기 성능 증거 없이 CQRS 또는 이벤트 소싱 선택
- 트레이드오프 무시 - 모든 아키텍처 선택에는 인정되어야 하는 비용이 있습니다