Use Case 작성법 (Ch 6)

유스케이스는 "시스템이 사용자에게 어떤 가치를 제공하는가"를 시나리오로 기술한 것이다. 기능 목록(feature list)이 아니라 목표 지향적 스토리다.

왜 기능 목록이 아닌 유스케이스인가

기능 목록은 수십~수백 페이지의 분절된 항목이 된다. 서로 맥락 없이 나열되니 "이걸 왜 만드는지"가 보이지 않는다. 유스케이스는 기능들을 사용 시나리오라는 맥락 안에 배치해서, 누가(Actor) 무슨 목표로(Goal) 시스템을 쓰는지를 드러낸다.

Fully Dressed 형식

가장 정밀한 형식이다. Inception에서 핵심 유스케이스 1~2개만 이 수준으로 쓰고, Elaboration에서 점진적으로 늘린다.

구조:

Primary Actor — 시스템을 호출하는 주된 행위자.

Stakeholders and Interests — 이 유스케이스에 이해관계를 가진 모든 주체와 그들의 관심사. 이게 생각보다 중요하다. "시스템이 뭘 해야 하는가"의 범위를 결정하기 때문이다. 예를 들어 POS 시스템의 Process Sale에서 Salesperson의 "커미션 기록" 관심사를 빠뜨리면, 커미션 기능 자체를 놓칠 수 있다.

Preconditions — 시나리오 시작 전 반드시 참이어야 하는 조건. 시나리오 안에서 테스트하지 않는다.

Success Guarantee (Postconditions) — 성공 완료 시 반드시 참이어야 하는 상태. 모든 이해관계자의 관심사를 충족해야 한다.

Main Success Scenario — 해피 패스. 조건 분기 없이 가장 일반적인 성공 경로만 기술한다. 세 종류의 스텝이 있다: 액터 간 상호작용, 시스템의 검증, 시스템의 상태 변경.

Extensions — 메인 시나리오에서 분기하는 모든 대안 경로. 성공과 실패 모두 포함. 보통 메인 시나리오보다 훨씬 길다. 3a. 잘못된 식별자: 처럼 메인 시나리오의 스텝 번호를 기준으로 표기한다.

블랙박스 스타일로 쓸 것

유스케이스는 시스템이 무엇을 하는지만 기술한다. 어떻게 하는지(DB에 저장, SQL 실행 등)는 쓰지 않는다.

✅ "시스템이 판매를 기록한다" ❌ "시스템이 판매를 데이터베이스에 기록한다"

바이브 코딩에서의 활용

유스케이스를 LLM에게 전달하면 시스템의 행동 범위를 명확하게 알려줄 수 있다. 특히 Stakeholders and Interests 목록은 LLM이 놓치기 쉬운 부수 기능(로깅, 커미션, 재고 업데이트 등)을 잡아준다.

프롬프트 예시:
"다음 유스케이스의 Main Success Scenario를 구현해줘.
각 스텝에서 시스템이 하는 일을 함수로 분리하고,
Extensions는 에러 핸들링으로 처리해."