Practical Mermaid v11 실무 다이어그램 쿡북 테스트
프로그래머를 위한 실전 응용 사례 모음 만들기
1. CI/CD 파이프라인 — GitHub Actions 기반 배포 플로우
실제 모노레포 프로젝트의 CI/CD 파이프라인을 flowchart로 표현한 예시. subgraph 중첩, 조건 분기, 스타일링을 활용합니다.
flowchart TD
trigger["🔔 Push / PR to main"]
trigger --> lint_check
subgraph CI["CI Pipeline"]
direction TB
lint_check["ESLint + Prettier Check"]
type_check["TypeScript tsc --noEmit"]
unit_test["Unit Tests (Vitest)"]
integration["Integration Tests (Playwright)"]
build["Build Artifacts"]
lint_check --> type_check
type_check --> unit_test
unit_test --> integration
integration --> build
end
build --> is_main{main branch?}
is_main -- "Yes" --> staging_deploy
is_main -- "No (PR)" --> preview_deploy
subgraph CD_Preview["Preview Environment"]
preview_deploy["Deploy to Vercel Preview"]
preview_url["Generate Preview URL"]
preview_comment["Comment PR with URL"]
preview_deploy --> preview_url --> preview_comment
end
subgraph CD_Staging["Staging → Production"]
staging_deploy["Deploy to Staging (k8s)"]
smoke_test["Smoke Tests"]
approval{Manual Approval?}
canary["Canary Deploy (10%)"]
monitor["Monitor Error Rate (15min)"]
error_check{Error Rate < 0.1%?}
full_rollout["Full Rollout (100%)"]
rollback["🔴 Rollback"]
notify_slack["Notify Slack #deploy"]
staging_deploy --> smoke_test
smoke_test --> approval
approval -- "Approved" --> canary
approval -- "Rejected" --> rollback
canary --> monitor --> error_check
error_check -- "Pass" --> full_rollout --> notify_slack
error_check -- "Fail" --> rollback --> notify_slack
end
style trigger fill:#4A90D9,color:#fff
style rollback fill:#E74C3C,color:#fff
style full_rollout fill:#2ECC71,color:#fff
style notify_slack fill:#611f69,color:#fff
2. 마이크로서비스 Sequence Diagram — 주문 처리 흐름
실제 이커머스 마이크로서비스 아키텍처에서 주문이 처리되는 과정. 비동기 메시지, 에러 처리(alt), 병렬 처리(par)를 모두 활용합니다.
sequenceDiagram
actor User
participant GW as API Gateway
participant Auth as Auth Service
participant Order as Order Service
participant Inv as Inventory Service
participant Pay as Payment Service
participant MQ as Message Queue (Kafka)
participant Notify as Notification Service
participant Ship as Shipping Service
User ->>+ GW: POST /orders (JWT)
GW ->>+ Auth: Validate Token
Auth -->>- GW: ✓ Valid (userId: 42)
GW ->>+ Order: CreateOrder(items, userId)
Order ->>+ Inv: ReserveStock(items)
alt Stock Available
Inv -->>- Order: Reserved (reservationId: R-001)
Order ->>+ Pay: ChargePayment(amount, paymentMethod)
alt Payment Success
Pay -->>- Order: Charged (txId: TX-9876)
Order ->> Order: Status → CONFIRMED
par Async Notifications
Order -)+ MQ: OrderConfirmed Event
MQ -)+ Notify: Consume Event
Notify --) User: 📧 Order Confirmation Email
Notify --) User: 📱 Push Notification
deactivate Notify
and Fulfillment
MQ -)+ Ship: Consume Event
Ship ->> Ship: Create Shipping Label
Ship -->>- MQ: ShipmentCreated Event
deactivate MQ
end
Order -->>- GW: 201 Created {orderId: ORD-5678}
else Payment Failed
Pay -->> Order: ❌ Declined (reason: insufficient_funds)
Order ->> Inv: ReleaseStock(R-001)
Inv -->> Order: Released
Order -->> GW: 402 Payment Required
end
else Out of Stock
Inv -->> Order: ❌ Unavailable (item: SKU-123)
Order -->> GW: 409 Conflict (out_of_stock)
end
GW -->>- User: Response
3. Entity-Relationship Diagram — SaaS 멀티테넌트 스키마
실제 B2B SaaS 제품의 멀티테넌트 데이터 모델.
erDiagram
TENANT ||--o{ USER : has
TENANT ||--o{ WORKSPACE : owns
TENANT ||--|| SUBSCRIPTION : subscribes
TENANT {
uuid id PK
string name
string slug UK
string plan_tier "free|pro|enterprise"
timestamp created_at
jsonb settings
}
USER ||--o{ WORKSPACE_MEMBER : "joins"
USER ||--o{ API_KEY : generates
USER ||--o{ AUDIT_LOG : creates
USER {
uuid id PK
uuid tenant_id FK
string email UK
string password_hash
enum role "owner|admin|member"
boolean mfa_enabled
timestamp last_login_at
}
WORKSPACE ||--o{ PROJECT : contains
WORKSPACE ||--o{ WORKSPACE_MEMBER : "has members"
WORKSPACE {
uuid id PK
uuid tenant_id FK
string name
text description
jsonb settings
}
WORKSPACE_MEMBER {
uuid workspace_id FK
uuid user_id FK
enum role "admin|editor|viewer"
timestamp joined_at
}
PROJECT ||--o{ ISSUE : tracks
PROJECT ||--o{ LABEL : defines
PROJECT ||--o{ MILESTONE : plans
PROJECT {
uuid id PK
uuid workspace_id FK
string key "e.g. PROJ"
string name
integer issue_counter
enum status "active|archived"
}
ISSUE ||--o{ COMMENT : has
ISSUE ||--o{ ISSUE_LABEL : tagged
ISSUE }o--o| MILESTONE : "assigned to"
ISSUE }o--o| USER : "assigned to"
ISSUE {
uuid id PK
uuid project_id FK
integer number
string title
text body_markdown
enum priority "urgent|high|medium|low"
enum status "backlog|todo|in_progress|done|cancelled"
uuid assignee_id FK
uuid reporter_id FK
timestamp due_date
}
SUBSCRIPTION ||--o{ INVOICE : generates
SUBSCRIPTION {
uuid id PK
uuid tenant_id FK
string stripe_subscription_id
enum status "active|past_due|cancelled"
timestamp current_period_end
}
AUDIT_LOG {
uuid id PK
uuid tenant_id FK
uuid actor_id FK
string action "e.g. issue.created"
jsonb metadata
inet ip_address
timestamp created_at
}
API_KEY {
uuid id PK
uuid user_id FK
string key_prefix "first 8 chars"
string key_hash
timestamp expires_at
string[] scopes
}
4. State Diagram — PR 리뷰 라이프사이클
Pull Request가 생성부터 머지까지 거치는 복합 상태 전이. 중첩 상태(composite state)를 활용합니다.
stateDiagram-v2
[*] --> Draft : Create PR
Draft --> Open : Mark Ready for Review
Draft --> Closed : Close
state Open {
[*] --> WaitingReview
WaitingReview --> InReview : Reviewer assigned
state InReview {
[*] --> Reviewing
Reviewing --> Approved : All reviewers approve
Reviewing --> ChangesRequested : Request changes
ChangesRequested --> Reviewing : Push new commits
}
InReview --> WaitingReview : Reviewer unassigned
}
state CI_Check <<choice>>
Open --> CI_Check : CI Pipeline runs
CI_Check --> MergeReady : CI passes + Approved
CI_Check --> Open : CI fails (fix needed)
state MergeConflict <<choice>>
MergeReady --> MergeConflict : Check conflicts
MergeConflict --> Merged : No conflicts → Squash & Merge
MergeConflict --> Open : Has conflicts → Rebase needed
Open --> Closed : Close PR
Closed --> Open : Reopen
Merged --> [*]
note right of Draft
Branch protection rules
may require reviews,
CI checks, and linear history
end note
note left of Merged
Post-merge: auto-delete branch,
trigger CD pipeline,
update linked issues
end note
5. Git Graph — Feature Branch 전략 (GitFlow 변형)
실제 프로젝트의 릴리스 사이클을 gitGraph로 표현.
gitGraph
commit id: "init"
commit id: "v1.0.0" tag: "v1.0.0"
branch develop
checkout develop
commit id: "setup-ci"
branch feature/auth
checkout feature/auth
commit id: "add-login-api"
commit id: "add-jwt-middleware"
commit id: "add-refresh-token"
checkout develop
merge feature/auth id: "merge-auth" tag: "auth-done"
branch feature/dashboard
checkout feature/dashboard
commit id: "dashboard-layout"
commit id: "add-charts"
checkout develop
commit id: "fix-lint-config"
merge feature/dashboard id: "merge-dashboard"
branch release/1.1
checkout release/1.1
commit id: "bump-version"
commit id: "fix-edge-case"
checkout main
merge release/1.1 id: "release-1.1" tag: "v1.1.0"
checkout develop
merge release/1.1 id: "backport-fix"
branch hotfix/security-patch
checkout hotfix/security-patch
commit id: "patch-xss-vuln"
checkout main
merge hotfix/security-patch id: "hotfix" tag: "v1.1.1"
checkout develop
merge hotfix/security-patch id: "backport-hotfix"
commit id: "continue-dev"
6. Gantt Chart — 스프린트 플래닝 & 릴리스 일정
실제 2주 스프린트 기반 릴리스 계획.
gantt
dateFormat YYYY-MM-DD
section Test
A :a1, after a2, 3d
B :after a1, 2d
7. Class Diagram — 플러그인 아키텍처 (Strategy + Observer 패턴)
Eclipse RCP 스타일의 플러그인 시스템을 클래스 다이어그램으로 표현. 인터페이스, 추상 클래스, 제네릭, 패턴 적용을 보여줍니다.
classDiagram
direction TB
class IPlugin {
<<interface>>
+getId() String
+getVersion() SemVer
+activate(context: PluginContext) void
+deactivate() void
}
class AbstractPlugin {
<<abstract>>
#context: PluginContext
#logger: Logger
+activate(context: PluginContext) void
+deactivate() void
#onActivate()* void
#onDeactivate()* void
#registerCommand(id: String, handler: CommandHandler) void
}
class PluginContext {
-services: Map~String, Object~
-subscriptions: Disposable[]
+getService~T~(type: Class~T~) T
+registerService~T~(type: Class~T~, impl: T) void
+subscribe(event: String, listener: EventListener) Disposable
}
class PluginRegistry {
-plugins: Map~String, IPlugin~
-depGraph: DAG~String~
+register(descriptor: PluginDescriptor) void
+resolve() IPlugin[]
+activate(id: String) void
+deactivateAll() void
-topologicalSort() String[]
}
class EventBus {
-listeners: Map~String, Set~EventListener~~
+emit(event: String, data: Object) void
+on(event: String, listener: EventListener) Disposable
+once(event: String, listener: EventListener) Disposable
+off(event: String, listener: EventListener) void
}
class ICommandHandler {
<<interface>>
+execute(args: Object) Promise~Result~
+canExecute(args: Object) boolean
}
class CommandRegistry {
-commands: Map~String, ICommandHandler~
+register(id: String, handler: ICommandHandler) void
+execute(id: String, args: Object) Promise~Result~
+getAll() CommandDescriptor[]
}
class EditorPlugin {
-editors: Map~String, EditorInstance~
+openFile(path: String) EditorInstance
+getActiveEditor() EditorInstance
#onActivate() void
}
class GitPlugin {
-repo: Repository
+getStatus() FileStatus[]
+commit(msg: String) Commit
+push(remote: String) void
#onActivate() void
}
class TerminalPlugin {
-sessions: TerminalSession[]
+createSession(shell: String) TerminalSession
+getActiveSession() TerminalSession
#onActivate() void
}
IPlugin <|.. AbstractPlugin : implements
AbstractPlugin <|-- EditorPlugin
AbstractPlugin <|-- GitPlugin
AbstractPlugin <|-- TerminalPlugin
AbstractPlugin --> PluginContext : uses
PluginRegistry o-- IPlugin : manages
PluginContext --> EventBus : contains
PluginContext --> CommandRegistry : contains
ICommandHandler <|.. EditorPlugin : implements
ICommandHandler <|.. GitPlugin : implements
CommandRegistry o-- ICommandHandler : stores
note for PluginRegistry "Dependency resolution via\ntopological sort on DAG.\nCyclic deps → error"
note for EventBus "Observer pattern:\nloose coupling between plugins"
8. Kanban Board — 스프린트 태스크 보드
v11의 신규 다이어그램 타입. 실제 스프린트 보드를 표현합니다.
---
---
config:
kanban:
ticketBaseUrl: 'https://mermaidchart.atlassian.net/browse/#TICKET#'
---
kanban
Todo
[Create Documentation]
docs[Create Blog about the new diagram]
[In progress]
id6[Create renderer so that it works in all cases. We also add some extra text here for testing purposes. And some more just for the extra flare.]
id9[Ready for deploy]
id8[Design grammar]@{ assigned: 'knsv' }
id10[Ready for test]
id4[Create parsing tests]@{ ticket: MC-2038, assigned: 'K.Sveidqvist', priority: 'High' }
id66[last item]@{ priority: 'Very Low', assigned: 'knsv' }
id11[Done]
id5[define getData]
id2[Title of diagram is more than 100 chars when user duplicates diagram with 100 char]@{ ticket: MC-2036, priority: 'Very High'}
id3[Update DB function]@{ ticket: MC-2037, assigned: knsv, priority: 'High' }
id12[Can't reproduce]
id3[Weird flickering in Firefox]
9. Sequence Diagram — OAuth2 Authorization Code Flow (PKCE)
보안 관련 프로토콜을 상세히 문서화한 예시.
sequenceDiagram
participant App as SPA (Client)
participant Browser as Browser
participant AuthZ as Authorization Server
participant Token as Token Endpoint
participant API as Resource Server
Note over App: Generate code_verifier (random 43-128 chars)<br/>code_challenge = BASE64URL(SHA256(code_verifier))
App ->> Browser: Redirect to /authorize
Browser ->> AuthZ: GET /authorize?<br/>response_type=code<br/>&client_id=spa-app<br/>&redirect_uri=https://app.example.com/callback<br/>&scope=openid profile api:read<br/>&state=xyz123<br/>&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8...<br/>&code_challenge_method=S256
AuthZ ->> Browser: Show Login Page
Browser ->> AuthZ: Submit credentials
AuthZ ->> AuthZ: Authenticate user
AuthZ ->> Browser: 302 Redirect to callback?code=SplxlOBeZQQ&state=xyz123
Browser ->> App: Callback with auth code
App ->> App: Verify state matches
App ->>+ Token: POST /token<br/>grant_type=authorization_code<br/>&code=SplxlOBeZQQ<br/>&redirect_uri=https://app.example.com/callback<br/>&client_id=spa-app<br/>&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Note over Token: Verify: BASE64URL(SHA256(code_verifier)) == stored code_challenge
Token -->>- App: 200 OK<br/>{ access_token, refresh_token, id_token, expires_in: 3600 }
Note over App: Store tokens in memory (NOT localStorage)
App ->>+ API: GET /api/user/profile<br/>Authorization: Bearer eyJhbGciOi...
API ->> API: Validate JWT signature & claims
API -->>- App: 200 OK { user data }
Note over App: Token expired after 1 hour
App ->>+ Token: POST /token<br/>grant_type=refresh_token<br/>&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA<br/>&client_id=spa-app
Token ->> Token: Rotate refresh token
Token -->>- App: New access_token + new refresh_token
10. Flowchart — 인시던트 대응 런북 (On-Call)
실제 SRE 팀의 인시던트 대응 절차를 런북으로 표현.
flowchart TD
alert["🚨 Alert Triggered\n(PagerDuty / Grafana)"]
ack["Acknowledge Alert\n(5분 이내)"]
assess["심각도 평가"]
alert --> ack --> assess
assess --> sev{Severity?}
sev -- "SEV1\n서비스 전면 장애" --> war_room
sev -- "SEV2\n주요 기능 장애" --> investigate
sev -- "SEV3\n경미한 이슈" --> log_ticket
war_room["🔴 War Room 오픈\n• Slack #incident-sev1\n• Zoom bridge 시작\n• 경영진 알림"]
war_room --> ic_assign["Incident Commander 지정"]
ic_assign --> investigate
investigate["원인 조사"]
investigate --> check_metrics["메트릭 확인\n• Error rate\n• Latency p99\n• CPU/Memory"]
check_metrics --> check_deploys{"최근 배포\n있었나?"}
check_deploys -- "Yes" --> rollback_decide{롤백 가능?}
rollback_decide -- "Yes" --> rollback["🔙 즉시 롤백\nkubectl rollout undo"]
rollback_decide -- "No" --> deep_dive
check_deploys -- "No" --> check_infra{"인프라 이슈?"}
check_infra -- "DB" --> db_check["DB 상태 확인\n• Connection pool\n• Slow queries\n• Replication lag"]
check_infra -- "Network" --> net_check["네트워크 확인\n• DNS resolution\n• TLS certificates\n• Load balancer health"]
check_infra -- "3rd Party" --> vendor_check["외부 서비스 상태 확인\n• Status page\n• API health check"]
check_infra -- "Unknown" --> deep_dive
deep_dive["Deep Dive 분석\n• 로그 (Kibana/Loki)\n• Traces (Jaeger)\n• Thread dump"]
rollback --> verify
db_check --> mitigate["완화 조치 적용"]
net_check --> mitigate
vendor_check --> mitigate
deep_dive --> mitigate
mitigate --> verify["서비스 정상 확인\n• Health check green\n• Error rate < baseline\n• Customer reports 감소"]
verify --> resolved{해결 확인?}
resolved -- "Yes" --> post_incident
resolved -- "No" --> investigate
post_incident["📝 포스트모템\n• Timeline 정리\n• Root cause 분석\n• Action items 도출"]
log_ticket["📋 Jira 티켓 생성\n→ 다음 스프린트 처리"]
post_incident --> done["✅ 인시던트 종료"]
log_ticket --> done
style alert fill:#E74C3C,color:#fff
style war_room fill:#E74C3C,color:#fff
style rollback fill:#F39C12,color:#fff
style done fill:#2ECC71,color:#fff
style post_incident fill:#3498DB,color:#fff
11. C4 Context Diagram (Flowchart 활용) — 시스템 아키텍처 개요
C4 Model의 Context Level을 Mermaid로 표현.
flowchart TB
subgraph boundary["Enterprise Boundary"]
direction TB
subgraph core["Core Platform"]
api["🖥️ API Gateway\n(Kong / Nginx)"]
app["📱 Web Application\n(Next.js)"]
mobile["📱 Mobile App\n(React Native)"]
worker["⚙️ Background Workers\n(Bull + Redis)"]
end
subgraph data["Data Layer"]
pg[("🐘 PostgreSQL\nPrimary DB")]
redis[("🔴 Redis\nCache + Queue")]
es[("🔍 Elasticsearch\nSearch Engine")]
s3[("📦 S3\nFile Storage")]
end
subgraph infra["Infrastructure"]
k8s["☸️ Kubernetes\n(EKS)"]
monitor["📊 Monitoring\n(Prometheus + Grafana)"]
log["📋 Logging\n(Loki + Fluentd)"]
end
end
users(["👥 End Users"])
admin(["🔧 Admin Users"])
ci["🔄 CI/CD\n(GitHub Actions)"]
idp["🔐 Auth0\n(Identity Provider)"]
stripe["💳 Stripe\n(Payments)"]
sendgrid["✉️ SendGrid\n(Email)"]
slack_ext["💬 Slack\n(Notifications)"]
users --> app
users --> mobile
admin --> app
app --> api
mobile --> api
api --> pg
api --> redis
api --> es
worker --> pg
worker --> redis
worker --> s3
api --> idp
api --> stripe
worker --> sendgrid
worker --> slack_ext
ci --> k8s
k8s --> monitor
k8s --> log
style boundary fill:none,stroke:#999,stroke-dasharray: 5 5
style core fill:#E8F4FD,stroke:#2980B9
style data fill:#FEF9E7,stroke:#F39C12
style infra fill:#FDEDEC,stroke:#E74C3C
12. Requirement Diagram — GDPR 컴플라이언스 요구사항
규제 준수 요구사항을 추적하는 Requirement Diagram.
requirementDiagram
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
functionalRequirement test_req2 {
id: 1.1
text: the second test text.
risk: low
verifymethod: inspection
}
performanceRequirement test_req3 {
id: 1.2
text: the third test text.
risk: medium
verifymethod: demonstration
}
interfaceRequirement test_req4 {
id: 1.2.1
text: the fourth test text.
risk: medium
verifymethod: analysis
}
physicalRequirement test_req5 {
id: 1.2.2
text: the fifth test text.
risk: medium
verifymethod: analysis
}
designConstraint test_req6 {
id: 1.2.3
text: the sixth test text.
risk: medium
verifymethod: analysis
}
element test_entity {
type: simulation
}
element test_entity2 {
type: word doc
docRef: reqs/test_entity
}
element test_entity3 {
type: "test suite"
docRef: github.com/all_the_tests
}
test_entity - satisfies -> test_req2
test_req - traces -> test_req2
test_req - contains -> test_req3
test_req3 - contains -> test_req4
test_req4 - derives -> test_req5
test_req5 - refines -> test_req6
test_entity3 - verifies -> test_req5
test_req <- copies - test_entity2
13. User Journey — 개발자 온보딩 경험
신규 개발자가 팀에 합류해서 첫 PR을 머지하기까지의 여정.
journey
title 신규 개발자 온보딩 Journey Map
section Day 1 환경 셋업
노트북 수령 및 계정 생성: 3: 신입, IT팀
개발 환경 설치 (IDE / Docker / k8s): 2: 신입
Git repo clone 및 빌드 성공: 4: 신입
Slack 채널 가입 및 자기소개: 5: 신입, 팀원
section Day 2-3 코드베이스 이해
아키텍처 문서 읽기: 3: 신입
멘토와 코드 워크스루: 5: 신입, 멘토
로컬에서 서비스 실행: 2: 신입
테스트 실행 및 디버깅: 3: 신입
section Day 4-5 첫 기여
Good First Issue 선택: 4: 신입, 멘토
브랜치 생성 및 구현: 4: 신입
테스트 작성: 3: 신입
첫 PR 제출: 5: 신입
section Week 2 정착
코드 리뷰 피드백 반영: 3: 신입
첫 PR 머지 성공: 5: 신입, 리뷰어
스탠드업 미팅 참여: 4: 신입, 팀원
두 번째 이슈 자율 선택: 5: 신입
14. Packet Diagram — TCP 3-Way Handshake 패킷 구조
v11의 신규 다이어그램. 네트워크 패킷 구조를 시각화합니다.
packet-beta
title TCP SYN Packet Structure (3-Way Handshake - Step 1)
0-15: "Source Port (e.g. 52431)"
16-31: "Destination Port (e.g. 443)"
32-63: "Sequence Number (ISN: 0xA1B2C3D4)"
64-95: "Acknowledgment Number (0x00000000)"
96-99: "Data Offset (5)"
100-102: "Reserved"
103: "NS"
104: "CWR"
105: "ECE"
106: "URG"
107: "ACK=0"
108: "PSH"
109: "RST"
110: "SYN=1"
111: "FIN"
112-127: "Window Size (65535)"
128-143: "Checksum"
144-159: "Urgent Pointer"
15. Sankey Diagram — 유저 퍼널 분석
사용자 유입 경로부터 전환까지의 흐름량을 시각화.
sankey-beta
Google Ads,Landing Page,12000
Organic Search,Landing Page,8500
Social Media,Landing Page,4200
Email Campaign,Landing Page,3800
Referral,Landing Page,2500
Landing Page,Signup Page,18600
Landing Page,Bounce,12400
Signup Page,Signup Complete,9800
Signup Page,Drop Off,8800
Signup Complete,Onboarding Start,8900
Signup Complete,Inactive,900
Onboarding Start,Onboarding Complete,6200
Onboarding Start,Abandoned,2700
Onboarding Complete,Free Trial Active,5800
Onboarding Complete,Skipped Trial,400
Free Trial Active,Paid Conversion,2100
Free Trial Active,Trial Expired,3700
Paid Conversion,Monthly Plan,1500
Paid Conversion,Annual Plan,600
16. Timeline — 기술 스택 진화 히스토리
프로젝트의 기술적 마일스톤을 타임라인으로 정리.
timeline
title Project Aurora — 기술 스택 진화
2023 Q1 : 프로젝트 시작
: Monolith (Express + EJS)
: PostgreSQL + Redis
: Heroku 배포
2023 Q3 : Frontend 분리 (React SPA)
: REST API 도입
: GitHub Actions CI
2024 Q1 : TypeScript 전환 완료
: Next.js 마이그레이션
: Vercel + AWS 하이브리드 배포
2024 Q3 : 마이크로서비스 분리 시작
: Kubernetes (EKS) 도입
: gRPC 서비스간 통신
: OpenTelemetry 계측
2025 Q1 : Event-driven 아키텍처
: Kafka 메시지 브로커
: CQRS 패턴 적용
2025 Q3 : AI 기능 통합
: RAG 파이프라인 (Embedding + pgvector)
: Edge Computing (Cloudflare Workers)
2026 Q1 : Multi-region 배포
: CockroachDB (Geo-distributed)
: Feature Flag 시스템 (자체 구축)
17. Quadrant Chart — 기술 부채 우선순위 매트릭스
기술 부채 항목들을 Impact × Effort로 매핑.
quadrantChart
title Reach and engagement of campaigns
x-axis Low Reach --> High Reach
y-axis Low Engagement --> High Engagement
quadrant-1 We should expand
quadrant-2 Need to promote
quadrant-3 Re-evaluate
quadrant-4 May be improved
Campaign A: [0.3, 0.6]
Campaign B: [0.45, 0.23]
Campaign C: [0.57, 0.69]
Campaign D: [0.78, 0.34]
Campaign E: [0.40, 0.34]
Campaign F: [0.35, 0.78]
18. 아키텍처 다이어그램
architecture-beta
group targets(server)[Monitored Hosts]
group collect(cloud)[Collection Layer]
group store(database)[Storage]
group visual(cloud)[Visualization]
service app(server)[App Servers] in targets
service node_exp(server)[Node Exporter] in targets
service filebeat(server)[Filebeat] in targets
service prom(server)[Prometheus] in collect
service logstash(server)[Logstash] in collect
service tsdb(database)[Prometheus TSDB] in store
service elastic(database)[Elasticsearch] in store
service grafana(internet)[Grafana] in visual
service kibana(internet)[Kibana] in visual
node_exp:R --> L:prom
filebeat:R --> L:logstash
prom:B --> T:tsdb
logstash:B --> T:elastic
tsdb:R --> L:grafana
elastic:R --> L:kibana
부록: Mermaid v11 다이어그램 타입 정리
| 다이어그램 | 키워드 | 주요 용도 |
|---|---|---|
| Flowchart | flowchart |
프로세스, 아키텍처, 의사결정 |
| Sequence | sequenceDiagram |
API 흐름, 프로토콜, 통신 |
| Class | classDiagram |
OOP 설계, 패턴 문서화 |
| State | stateDiagram-v2 |
상태 기계, 라이프사이클 |
| ER | erDiagram |
데이터 모델링 |
| Gantt | gantt |
프로젝트 일정 |
| Git Graph | gitGraph |
브랜칭 전략 |
| User Journey | journey |
UX 플로우, 온보딩 |
| Pie | pie |
비율 시각화 |
| Quadrant | quadrantChart |
2×2 매트릭스 분석 |
| Requirement | requirementDiagram |
요구사항 추적 |
| Timeline | timeline |
마일스톤, 히스토리 |
| Sankey | sankey-beta |
흐름량 시각화 |
| Kanban | kanban |
태스크 보드 (v11 신규) |
| Packet | packet-beta |
네트워크 패킷 구조 (v11 신규) |
| Architecture | architecture-beta |
인프라 토폴로지 (v11 신규) |
| Block | block-beta |
블록 다이어그램 |
| Mindmap | mindmap |
마인드맵 |
| XY Chart | xychart-beta |
꺾은선/막대 그래프 |
| ZenUML | zenuml |
시퀀스 다이어그램 (대안 문법) |
댓글 없음