스킬 Database Architect
🏛️

Database Architect

안전

확장 가능한 데이터베이스 아키텍처 설계

잘못된 데이터베이스 선택이나 불충분한 스키마 설계는 비용이 많이 드는 재작업과 성능 문제를 야기합니다. 이 스킬은 데이터베이스 기술 선택, 데이터 모델링, 아키텍처 설계에 대한 전문가 수준의 지침을 제공하여 처음부터 확장 가능한 데이터 계층을 구축할 수 있도록 도와줍니다.

지원: Claude Codex Code(CC)
🥉 72 브론즈
1

스킬 ZIP 다운로드

2

Claude에서 업로드

설정 → 기능 → 스킬 → 스킬 업로드로 이동

3

토글을 켜고 사용 시작

테스트해 보기

"Database Architect" 사용 중입니다. Design a schema for a blog platform with users, posts, comments, and tags.

예상 결과:

권장 스키마에는 다음이 포함됩니다: users 테이블(id, email, created_at), 사용자에 대한 외래 키가 있는 posts 테이블, 스레딩을 위한 자체 참조 parent_id가 있는 comments 테이블, 다대다 결합 테이블 post_tags가 있는 tags 테이블. posts.user_id, comments.post_id에 인덱스, posts의 제목과 본문에 대한 전체 텍스트 인덱스.

"Database Architect" 사용 중입니다. Should I use Redis or PostgreSQL for session storage?

예상 결과:

빠른 액세스, TTL을 통한 자동 만료, 수평 확장이 필요할 때는 Redis를 사용하세요. 세션이 Redis 재시작 후에도 유지되어야 하거나, 복잡한 쿼리가 필요하거나, 데이터베이스 트랜잭션에 참여해야 할 때는 PostgreSQL을 사용하세요. 대부분의 웹 앱에는 PostgreSQL 지속성이 함께 제공되는 Redis가 최상의 균형을 제공합니다.

보안 감사

안전
v1 • 2/24/2026

Static analysis scanned 0 files with risk score 0/100. Evaluation confirms this is a prompt-only skill with no executable code. The skill provides database architecture guidance through instructional text only. No dangerous patterns, network access, or code execution vectors detected. Safe for publication.

0
스캔된 파일
0
분석된 줄 수
0
발견 사항
1
총 감사 수
보안 문제를 찾지 못했습니다
감사자: claude

품질 점수

38
아키텍처
100
유지보수성
87
콘텐츠
50
커뮤니티
100
보안
74
사양 준수

만들 수 있는 것

신규 플랫폼 설계

기술 선택, 스키마 설계, 확장 전략을 포함하여 새로운 SaaS 플랫폼을 위한 전체 데이터베이스 아키텍처를 설계합니다.

데이터베이스 마이그레이션 계획

모놀리식 MySQL 데이터베이스에서 폴리글로트 지속성을 가진 마이크로서비스 아키텍처로 전환하기 위한 상세한 마이그레이션 계획을 수립합니다.

NoSQL 스키마 설계

MongoDB 또는 DynamoDB를 사용하는 고속 분석 대시보드를 위한 문서 스키마 및 액세스 패턴을 설계합니다.

이 프롬프트를 사용해 보세요

기본 기술 선택
사용자 프로필, 거래, 활동 로그를 저장해야 하는 새 애플리케이션을 구축하고 있습니다. 초기에 하루 10,000명의 활성 사용자가 예상됩니다. 적절한 데이터베이스 기술을 선택하고 트레이드오프를 설명해 주세요.
스키마 설계 요청
멀티테넌트 프로젝트 관리 도구의 데이터베이스 스키마를 설계하세요. 각 테넌트에는 사용자, 프로젝트, 작업, 댓글이 있습니다. 필요한 테이블, 관계, 키 인덱스를 보여주세요.
마이그레이션 전략 계획
단일 MySQL 인스턴스에서 100M 이상의 레코드를 지원하는 셰이징 아키텍처로 마이그레이션해야 합니다. 단계, 롤백 절차, 성공 기준이 포함된 무중단 마이그레이션 계획을 만들어주세요.
고급 CQRS 아키텍처
주문 관리 시스템을 위한 CQRS 이벤트 소싱 아키텍처를 설계하세요. 이벤트 스토어 설계, 읽기 모델 프로제션, 스냅샷 전략, 시간에 따른 스키마 진화 처리 방법을 포함하세요.

모범 사례

  • 데이터베이스 기술을 선택하기 전에 항상 액세스 패턴과 확장 요구 사항을 이해하세요
  • 정규화 상태로 시작한 후 측정된 쿼리 성능에 따라 선택적으로 비정규화하세요
  • 자동화된 롤백 절차로 마이그레이션을 계획하고 스테이징에서 충분히 테스트하세요

피하기

  • 운영 복잡성을 이해하지 않고 유행하는 데이터베이스 선택
  • 과도한 JOIN 연산을 유발하는 읽기 집약적 워크로드 과정규화
  • 프로덕션 마이그레이션 전 백업 및 롤백 계획 건너뛰기

자주 묻는 질문

스타트업에 어떤 데이터베이스를 선택해야 하나요?
대부분의 애플리케이션에는 PostgreSQL로 시작하세요. 관계형 데이터를 잘 처리하고 유연성을 위한 JSON을 지원하며 수백만 사용자에게 확장됩니다. 시계열 데이터, 그래프 관계, 대규모 쓰기 처리량과 같은 특정 요구 사항이 있을 때만 특수화된 데이터베이스로 전환하세요.
데이터베이스를 언제 셰이딩해야 하는지 어떻게 알 수 있나요?
수직 확장이 비용 부담이 되거나, 쓰기 처리량이 단일 노드 용량을 초과하거나, 데이터량이 백업 및 유지보수 창에 영향을 줄 때 셰이딩을 고려하세요. 셰이딩 전에 읽기 레플리카, 캐싱, 쿼리 최적화로 먼저 최적화하세요.
CRUD 작업과 타입 안전성을 위해 Prisma 또는 SQLAlchemy 같은 ORM을 사용하세요. 복잡한 분석 쿼리, 대량 작업, 또는 ORM이 비효율적인 쿼리를 생성할 때는 네이티브 SQL을 작성하세요. 많은 팀이 둘 다 사용합니다: 표준 작업에는 ORM, 성능 중요한 경로에는 네이티브 SQL.

개발자 세부 정보

파일 구조

📄 SKILL.md