SKILL.md
데이터 플랫폼 아키텍처 스타일
데이터 플랫폼의 아키텍처 스타일을 비교하고, 상황에 맞는 하나를 고르고, 그 근거를 남기는 문서를 작성한다. 유행하는 이름을 나열하는 문서가 아니라, 제약 조건에서 결론이 도출되는 문서를 만든다.
먼저 읽을 것
references/styles.md — 9개 스타일의 정의·구성요소·적합 조건·한계, 그리고 선택 기준표. 문서를 쓰기 전에 반드시 읽고, 거기 적힌 사실만 사용한다. 카탈로그에 없는 스타일을 다루게 되면 같은 형식으로 항목을 먼저 추가한다.
examples/ecommerce-modernization.md — 완성 예시 하나. 중앙 데이터팀 1개인 이커머스가 Redshift 배치에서 CDC 기반 Streaming Lakehouse로 가는 판단 과정을 3단락 구조로 담았다. 분량·표 밀도·완료 판정의 구체성 기준으로 삼는다.
작성 전 확인 (모르면 추정하지 말고 묻는다)
이 네 가지가 스타일 선택을 사실상 결정한다. 사용자가 주지 않았으면 묻는다.
| 항목 | 왜 결정적인가 | | --- | --- | | 지연 요구 | 일 배치 / 시간 단위 / 초 단위 — Kappa·Streaming Lakehouse는 초 단위에서만 값을 한다 | | 조직 형태 | 중앙 데이터팀 1개인지, 도메인 팀이 여럿인지 — Data Mesh는 후자에서만 성립한다 | | 기존 자산 | 이미 있는 DW·레이크·계약 — 대체 비용이 스타일 선택을 뒤집는 경우가 많다 | | 주 소비처 | BI 위주 / ML 위주 / 둘 다 — 단일 복사본(Lakehouse) 필요성을 가른다 |
문서 구조 (3단락 고정)
## 1. [핵심 한마디], [주제]의 개요 ← 3노드 흐름도 + 정의 + 특징
## 2. [주제]의 아키텍처 스타일 비교
### 가. 스타일별 구조와 동작 ← 스타일당 Mermaid + 설명
### 나. 스타일 비교표 ← 축별 정면 비교
## 3. 선택 기준 및 적용 방안 ← 의사결정 흐름 + 단계별 도입안1단락 — 개요
제목: ## 1. [핵심 한마디], [주제]의 개요. 한마디는 20자 이내, 현상·역설·가치를 직접 말한다. "~를 위한 아키텍처"보다 "저장은 한 번, 조회는 엔진 자유롭게" 쪽이 낫다.
제목 아래 3노드 LR 흐름도를 먼저 배치한다.
flowchart LR
A["현재 한계<br/>사일로·이중 파이프라인"] --"전환 이유·<br/>핵심 메커니즘"--> B["아키텍처 적용<br/>핵심 가치"] --"결과·<br/>기대 효과"--> C["달성 목표<br/>비즈니스 가치"]
style A fill:#FFEBEE,stroke:#D32F2F,color:#000
style B fill:#E3F2FD,stroke:#1976D2,color:#000
style C fill:#E8F5E9,stroke:#388E3C,color:#000색은 고정이다 — A 빨강(문제), B 파랑(메커니즘), C 녹색(가치).
정의: [핵심 메커니즘]으로 [목적]을 달성하는 [유형] 아키텍처. 뒤에 적용 범위, 핵심 산출물, 적용 조건 세 줄을 붙인다.
2단락 — 스타일 비교
가. 다루는 스타일마다 Mermaid 하나와 3~5줄 설명. 저장 계층·처리 계층·카탈로그를 분리해 그린다. 스타일당 다이어그램은 하나로 제한한다.
나. 비교표는 반드시 아래 축을 포함한다. 축이 다르면 비교가 아니라 나열이 된다.
| 축 | 예시 값 | | --- | --- | | 지연 | 일 배치 / 분 / 초 | | 파이프라인 수 | 단일 경로 / 배치+스트림 이중 | | 저장 복사본 | 단일 / DW·레이크 이중 | | 거버넌스 주체 | 중앙 / 연합 | | 재처리 방법 | 백필 잡 / 로그 리플레이 | | 주 비용 동인 | 컴퓨트 / 스토리지 / 조직 |
각 셀은 사실만 적는다. "우수함" 같은 평가어 대신 "초 단위", "이중 경로"처럼 검증 가능한 값을 쓴다.
3단락 — 선택 기준과 적용
의사결정을 Mermaid flowchart TD로 그린다. 분기 조건은 위의 4개 확인 항목에서 가져온다. 그다음 4행 표로 단계별 도입안 — 단계 / 목표 / 산출물 / 완료 판정 — 을 제시한다. 완료 판정은 관측 가능해야 한다("성능 개선" ✗, "P95 조회 2초 이하" ○).
반드시 지킬 것
- Data Mesh는 조직 설계, Data Fabric은 기술 설계다. 둘을 대안 관계로 나란히
놓지 않는다. 메시를 도입하며 패브릭 도구를 쓰는 것은 모순이 아니다.
- Medallion은 아키텍처가 아니라 레이크하우스 내부의 계층 규약이다. Lakehouse의
대안으로 표에 올리지 않는다.
- Lambda를 기본값으로 제시하지 않는다. 이중 코드 경로의 유지 비용을 감수할
이유(레거시 배치 자산, 스트림 엔진 미도입)를 대지 못하면 Kappa 계열을 먼저 검토한다.
- 테이블 포맷(Iceberg/Delta/Hudi)과 카탈로그(Unity, Polaris, Nessie, Glue)를 구분한다.
포맷은 파일 레이아웃, 카탈로그는 테이블 탐색·권한이다. 섞어 쓰면 문서가 무너진다.
- 벤더 제품명으로 스타일을 부르지 않는다. "Databricks 아키텍처"가 아니라
"Lakehouse, 예: Databricks".
- 근거 없는 수치를 쓰지 않는다. 성능·비용 수치는 사용자가 준 값이거나 출처를 밝힌
값만 쓴다.
출력
한국어. 기술 용어는 영문 병기(레이크하우스(Lakehouse))를 첫 등장에만 붙인다. Mermaid는 렌더 가능한지 노드 라벨의 따옴표·<br/>를 확인하고 넘긴다.