refactor(topics): 멀티 에이전트용 지식 재편 — _Common(공통 기본기) + Domain_* 구조
에이전트 8종(대화형/프로그래머 C·S/디자이너/설계자/기획자/QA/PD/PM)에게 [공통 기본 능력 + 롤별 Specialty] 2층으로 지식을 주입하기 위한 재분류. 문서 내용·포맷은 무수정, 폴더 이동만 (6,372개 문서 수 보존 확인). - Topic_Programming → Domain_Programming (내부 구조 보존) - Topic_Graphic → Domain_Design - Topic_Business → Domain_Product - Topic_General → Domain_General - _Common 신설: Math(구 Topic_Math_Specialty), Reasoning(구 General/From_Thinking & Reasoning), Reasoning_Creativity(구 General/From_창의성), Communication(Poetic_Blog_Writing + From_writing) - 타 도메인의 From_* 폴더는 유지 (출처 표기일 뿐, 이미 도메인에 맞게 분류된 문서) - 빈 폴더 정리 (memory/procedures) - 에이전트→폴더 매핑은 workspace의 .astra/agent-knowledge-map.json (9개 에이전트) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,204 @@
|
||||
---
|
||||
id: wiki-2026-0508-유스케이스-use-cases
|
||||
title: 유스케이스 (Use Cases)
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Use Cases, 유스케이스, Use Case Analysis]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [requirements, analysis, uml, agile, design]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: any
|
||||
framework: any
|
||||
---
|
||||
|
||||
# 유스케이스 (Use Cases)
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 actor 가 매 system 의 의 의 의 achieve 의 의 의 goal 의 의 narrative"**. 매 Ivar Jacobson (1986) 가 의 의 OOSE 의 의 의 introduce 의 requirement engineering 의 의 의 핵심 의 의 의 artifact. 매 2026 — 매 Clean Architecture 의 의 application layer 의 의 의 first-class 의 building block.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 구성 요소
|
||||
- **Actor** — 매 system 외부 entity (user, system, time).
|
||||
- **Goal** — 매 actor 의 의 achieve 의 want 의 outcome.
|
||||
- **Scenario** — 매 step-by-step 의 flow.
|
||||
- **Precondition / Postcondition** — 매 state 의 boundary.
|
||||
- **Extensions** — 매 alternate 의 exception flow.
|
||||
|
||||
### 매 Use case 의 levels (Cockburn)
|
||||
1. **Cloud** — 매 strategic 의 vague.
|
||||
2. **Kite** — 매 summary level.
|
||||
3. **Sea** — 매 user goal (most common).
|
||||
4. **Fish** — 매 sub-function.
|
||||
5. **Clam** — 매 too low / implementation detail.
|
||||
|
||||
### 매 vs User Story
|
||||
- Use case — 매 흐름 의 narrative 의 detailed.
|
||||
- User story — 매 한 줄 의 "As a X, I want Y, so that Z".
|
||||
- 매 Agile — 매 user story; 매 enterprise — 매 use case.
|
||||
|
||||
### 매 Use case 의 Clean Architecture 의 의 의 manifestation
|
||||
- 매 application layer 의 의 의 한 use case = 한 class.
|
||||
- 매 input port (request) + output port (response).
|
||||
- 매 framework / DB 의 의 의 independence.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### 매 Use case template (Cockburn)
|
||||
```markdown
|
||||
# UC-007: Place Order
|
||||
|
||||
**Primary Actor**: Customer
|
||||
**Goal**: Submit order and receive confirmation
|
||||
**Precondition**: User authenticated, cart non-empty
|
||||
**Postcondition (success)**: Order persisted, payment authorized
|
||||
**Postcondition (failure)**: Cart unchanged
|
||||
|
||||
## Main Success Scenario
|
||||
1. Customer reviews cart
|
||||
2. Customer enters shipping address
|
||||
3. Customer selects payment method
|
||||
4. System calculates total (items + tax + shipping)
|
||||
5. Customer confirms
|
||||
6. System charges payment
|
||||
7. System creates order
|
||||
8. System sends confirmation email
|
||||
|
||||
## Extensions
|
||||
6a. Payment declined:
|
||||
6a1. System notifies customer
|
||||
6a2. Return to step 3
|
||||
7a. Inventory unavailable:
|
||||
7a1. System refunds payment
|
||||
7a2. System notifies customer
|
||||
```
|
||||
|
||||
### 매 Clean Architecture 의 의 의 use case (Java)
|
||||
```java
|
||||
public interface PlaceOrder {
|
||||
Result execute(Request req);
|
||||
|
||||
record Request(UUID userId, List<Item> items, Address ship) {}
|
||||
sealed interface Result {
|
||||
record Success(UUID orderId) implements Result {}
|
||||
record PaymentFailed(String reason) implements Result {}
|
||||
record OutOfStock(List<UUID> skus) implements Result {}
|
||||
}
|
||||
}
|
||||
|
||||
@Component
|
||||
class PlaceOrderInteractor implements PlaceOrder {
|
||||
private final OrderRepo orders;
|
||||
private final PaymentGateway pay;
|
||||
private final InventoryService inv;
|
||||
|
||||
@Override
|
||||
public Result execute(Request req) {
|
||||
var unavailable = inv.check(req.items());
|
||||
if (!unavailable.isEmpty()) return new OutOfStock(unavailable);
|
||||
|
||||
var charge = pay.charge(req.userId(), total(req));
|
||||
if (charge.failed()) return new PaymentFailed(charge.reason());
|
||||
|
||||
var order = Order.create(req);
|
||||
orders.save(order);
|
||||
return new Success(order.id());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 매 Use case diagram (PlantUML)
|
||||
```plantuml
|
||||
@startuml
|
||||
left to right direction
|
||||
actor Customer
|
||||
actor Admin
|
||||
rectangle Shop {
|
||||
Customer --> (Browse Catalog)
|
||||
Customer --> (Place Order)
|
||||
Customer --> (Track Shipment)
|
||||
(Place Order) ..> (Charge Payment) : <<include>>
|
||||
(Place Order) ..> (Apply Discount) : <<extend>>
|
||||
Admin --> (Manage Inventory)
|
||||
}
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 매 User story 의 의 의 의 mapping
|
||||
```markdown
|
||||
# Story
|
||||
As a Customer
|
||||
I want to place an order
|
||||
So that I receive my purchase
|
||||
|
||||
## Acceptance Criteria (Gherkin)
|
||||
Given I have items in my cart
|
||||
When I confirm checkout with valid payment
|
||||
Then the order is created
|
||||
And I receive a confirmation email
|
||||
```
|
||||
|
||||
### 매 Test 의 의 use case 별
|
||||
```java
|
||||
@Test
|
||||
void placeOrder_success() {
|
||||
when(inv.check(any())).thenReturn(List.of());
|
||||
when(pay.charge(any(), any())).thenReturn(Charge.ok());
|
||||
|
||||
var result = useCase.execute(req);
|
||||
|
||||
assertInstanceOf(Success.class, result);
|
||||
verify(orders).save(any());
|
||||
}
|
||||
|
||||
@Test
|
||||
void placeOrder_paymentFails() {
|
||||
when(pay.charge(any(), any())).thenReturn(Charge.declined("insufficient"));
|
||||
|
||||
var result = useCase.execute(req);
|
||||
|
||||
assertInstanceOf(PaymentFailed.class, result);
|
||||
verify(orders, never()).save(any());
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 enterprise / regulated | 매 Cockburn full template |
|
||||
| 매 agile / startup | 매 User story + acceptance criteria |
|
||||
| 매 Clean Arch impl | 매 Interactor pattern (interface + class) |
|
||||
| 매 stakeholder communication | 매 Use case diagram (high-level) |
|
||||
|
||||
**기본값**: 매 Sea-level use case + Cockburn template (extensions essential) → 매 Interactor.
|
||||
|
||||
## 🔗 Graph
|
||||
- 응용: [[Clean Architecture]] · [[Hexagonal Architecture]]
|
||||
- Adjacent: [[BDD]] · [[Domain-Driven Design]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 새 feature 의 design — 매 main flow + extension 의 enumerate.
|
||||
**언제 X**: 매 매 algorithm / library 의 internal — 매 use case 의 의 user-facing.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **CRUD use case**: 매 "Create User", "Update User" — 매 implementation 의 leak.
|
||||
- **No extensions**: 매 happy path 의 만 — 매 edge case 의 의 miss.
|
||||
- **Too low level**: 매 "Click button" — 매 fish/clam.
|
||||
- **God use case**: 매 한 use case 의 의 의 모든 의 cover.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified — Alistair Cockburn, *Writing Effective Use Cases* (2000); Robert C. Martin, *Clean Architecture*; Ivar Jacobson, *OOSE*.
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Cockburn template + Clean Arch interactor |
|
||||
Reference in New Issue
Block a user