# 나들이 동행 — User Stories & Acceptance Criteria v0.1

기획일: 2026-10-03. 기준: outing-agent-plan.md.
상태: 설계 및 인터랙션 프로토타입. 실제 지도 조회·일정 추론·예약·결제·공유 백엔드 미구현.

## 제품 목표와 주 사용자

계획을 준비하는 사용자가 장소 검색을 반복하지 않고, 동행인과 원하는 경험에 맞는 본안·대안을 선택하고 실제로 움직일 수 있도록 돕는다. 초기 범위는 당일 피크닉·데이트·가벼운 나들이다.

화면 성격: Operate(계획을 선택하고 실행), Compare(본안·대안 비교)는 보조. 휴대폰에서 한 화면에 하나의 중요한 결정만 요구한다. 지도 자체를 첫 화면으로 만들지 않는다.

## 모바일 Storyboard v0.2

첫 화면은 2열 Wireframe 대신 최대480px 단일열 Storyboard다. 장면마다 상황 그림·사용자 행동·에이전트 판단·결과와 접힌 User Story를 연결한다. 하단 이전/다음 버튼으로 이동하고 세로 스크롤로도 읽는다.

|장면|사용자 상황|연결 Story|
|---|---|---|
|SB01|집에서 함께 보낼 시간을 이야기함|US01|
|SB02|가까운 후보의 당일 행사·운영을 검토함|US03|
|SB03|휴식 또는 축제 참여를 선택함|US02|
|SB04|필수 조건·미확인·포기한 조건을 비교함|US04·05|
|SB05|픽업부터 현장 활동·귀가까지 이동함|US06|
|SB06|지연 발생 후 변경안을 승인·거절함|US07·08|
|SB07|동행인과 계획을 공유하고 시간을 보냄|US09·10|

Storyboard의 활동 완료는 조건이 확인됐다는 가상의 결말이며 실제 실행 증거가 아니다. 기존 클릭형 화면은 prototype.html에 보존한다. 분위기 선택은 SB04·05에도 반영하며 변경안 버튼은 승인/거절 시연이다.

## 핵심 사용자 여정

WF01 요청 → WF02 목적·필수조건 확인 → [실제 제품: 조사·상황 검토] → WF03 본안·대안 → WF04 이동 안내.

어느 단계에서나 변경 요청 → WF05 기존/새 계획 비교 → 승인 시 새 버전 채택, 거절 시 기존 계획 유지.

공유 또는 외부 행위 요청 → WF06 공개 범위·실행 권한 확인.

WF02의 질문에 답하지 않아도 가정을 드러낸 조건부 추천으로 진행한다. 실패·미확인·이전 버전은 숨기지 않는다.

## Story map

|활동|이해하기|판단하기|선택하기|움직이기|바꾸기|함께 보기|
|---|---|---|---|---|---|---|
|P0|US01·02|US03·04|US05|US06|US07·08|US09|
|P1|선호 저장 동의|US10 재확인|추가 비교|도착 체크|알림·감시|동행인 투표|

P0는 첫 MVP 필수다. P1은 상시 알림·자동 감시까지 요구하지 않는 수동 재확인부터 구현한다.

## US01 — 일상 언어로 계획 요청하기 (P0 / WF01)

사용자로서, 목적·동행인·출발지·시간을 자연스럽게 말하고 싶다. 여러 검색 폼을 채우기 전에 에이전트가 내가 원하는 경험을 이해하도록 하기 위해서다.

인수 조건:
- AC01.1 텍스트를 제출하면 원문과 구조화된 목적·조건을 WF02에서 확인할 수 있다.
- AC01.2 출발지·날짜·시간을 모르면 빈칸 또는 ‘미확인’으로 유지한다. 현재 위치 접근을 자동 승인하지 않는다.
- AC01.3 무의미한 빈 입력은 제출되지 않고 접근 가능한 설명을 표시한다.
- AC01.4 프로토타입은 입력을 실제로 해석했다고 주장하지 않고, 작성한 원문과 고정 시나리오의 차이를 표시한다.

## US02 — 필수 조건과 분위기를 구분하기 (P0 / WF02)

사용자로서, 반드시 하고 싶은 활동과 가능하면 원하는 분위기를 수정하고 싶다. 에이전트가 추정한 취향 때문에 추천이 왜곡되지 않도록 하기 위해서다.

인수 조건:
- AC02.1 조건은 사용자 명시·잠정 가정·미확인 등 유래와 함께 나타난다. 분위기 선택은 활동의 필수 조건을 바꾸지 않는다.
- AC02.2 ‘축제 참여’와 ‘한적한 휴식’을 바꾸면 행사에 대한 판단 근거가 바뀐다. 행사 자체를 무조건 부적합으로 처리하지 않는다.
- AC02.3 답변 건너뛰기를 허용하며, 추천에는 분위기 미확인을 표시한다.
- AC02.4 이미 확인한 조건은 다음 화면과 재계획에서도 유지한다.

## US03 — 오늘의 사실과 목적에 대한 영향을 함께 보기 (P0 / WF02·03)

사용자로서, 행사·휴장·날씨·운영 조건이 내 계획에 어떤 영향을 주는지 보고 싶다. 가까운 장소가 오늘 나에게 적합한지는 별개의 문제이기 때문이다.

인수 조건:
- AC03.1 각 중요한 관측은 사실 / 출처·관측 시각 / 목적에 대한 영향 / 판단 상태를 분리한다.
- AC03.2 거리·가격보다 필수 조건과 실행 가능성을 먼저 비교한다.
- AC03.3 행사 규모만으로 혼잡도·자리 부족을 확정하지 않는다. 취식 구역 미확인은 미확인으로 남는다.
- AC03.4 실제 제품에는 증거와 검토 상태가 없는 ‘조사 완료’ 문구가 없어야 한다. 프로토타입은 모든 관측이 설계용 데이터임을 항상 표시한다.

## US04 — 핵심 조건이 불확실한 계획을 알아보기 (P0 / WF03)

사용자로서, 계란 재고나 접근 조건이 미확인인 것을 추천 전에 알고 싶다. 현장에 도착한 뒤 필수 활동이 불가능하다는 사실을 처음 알게 되지 않도록 하기 위해서다.

인수 조건:
- AC04.1 모든 필수 활동은 확인·조건부·불가 중 하나의 판정 또는 아직 미확인 상태를 가진다.
- AC04.2 계란을 필수로 설정했고 재고가 미확인인 경우, ‘확정 일정’ 선택은 차단한다. 조건부 검토 또는 계란 없는 안 검토는 명시적으로 선택할 수 있다.
- AC04.3 핵심 미확인이 추천 머리말과 출발 전 확인 목록 양쪽에 남는다. 낮은 우선순위 경고를 늘어놓지 않는다.
- AC04.4 계란을 선택 활동으로 낮추면 라면 동선은 유지할 수 있지만 재고 확인 표시가 사라지지는 않는다.

## US05 — 본안·대안과 포기한 조건 선택하기 (P0 / WF03)

사용자로서, 추천 한 개와 대안 한 개의 이유·부담·미확인을 비교하고 싶다. 많은 후보 목록 대신 지금 움직일 결정을 하기 위해서다.

인수 조건:
- AC05.1 본안·대안에는 활동 적합성·이동 부담·시간·비용·핵심 미확인이 같은 구조로 표시된다.
- AC05.2 선택한 안과 조건부 상태가 WF04로 전달된다. 대안을 눌렀는데 본안 이동 안내를 보여주면 실패다.
- AC05.3 임의의 92점 같은 숫자로 판단을 포장하지 않는다.
- AC05.4 전부 부적합하면 가능한 척 순위를 만들지 않고, 최소 변경할 조건과 다음 선택을 제시한다.

## US06 — 현재 단계에 맞는 이동 안내 받기 (P0 / WF04)

사용자로서, 픽업 뒤 어디로 어떤 방향으로 가야 하는지 한 단계씩 보고 싶다. 장소 이름과 거리만으로는 실제 이동할 수 없기 때문이다.

인수 조건:
- AC06.1 도보·대중교통·택시 전환 시 소요시간과 이동 지시가 함께 바뀐다.
- AC06.2 실제 제품의 대중교통 안내에는 승차·하차 정류장과 방향·환승·마지막 도보가 포함된다. 확인 못한 정류장 ID는 만들지 않는다.
- AC06.3 이동·배차·픽업 대기·착석·활동·귀가를 구분한다. 최신 교통 조회가 없으면 과거 배차를 ‘곧 도착’으로 보여주지 않는다.
- AC06.4 단계 완료 표시는 로컬 사용자 체크일 뿐 GPS 도착 감지·예약 성공을 뜻하지 않는다.
- AC06.5 프로토타입 지도 버튼은 외부 지도 호출을 하지 않고 실제 제품에서 필요한 연결 정보를 표시한다.

## US07 — 새 사실을 반영하되 약속은 지키기 (P0 / WF04·05)

사용자로서, 픽업 지연·비·행사 같은 변화를 말하면 해당 부분만 다시 계획하고 싶다. 이미 정한 픽업·예산·귀가 시간을 매번 설명하고 싶지 않기 때문이다.

인수 조건:
- AC07.1 변경 사유, 영향을 받는 단계, 유지되는 약속, 새 제안이 나타난다.
- AC07.2 귀가 제한을 맞출 수 없는 경우 그대로 유지되는 것처럼 표시하지 않고 불가 또는 새 승인을 요구한다.
- AC07.3 비 예시에서는 야외 식사 대신 실내 이용 조건을 검토하되, 외부 음식 허용을 확인 없이 보장하지 않는다.
- AC07.4 변경 중에도 이전 계획은 사라지지 않는다. 승인 전에는 새 제안을 채택한 상태가 아니다.

## US08 — 변경을 승인·거절하고 이전 안 복구하기 (P0 / WF05)

사용자로서, 바뀐 계획의 차이를 보고 적용하거나 거절하고 싶다. 에이전트가 내 약속과 선택을 조용히 덮어쓰지 않도록 하기 위해서다.

인수 조건:
- AC08.1 이전 계획과 새 제안, 유지/변경 항목을 한 화면에서 비교한다.
- AC08.2 거절하면 계획 버전·선택·이동 단계가 유지된다.
- AC08.3 적용하면 버전이 증가하고 이동 안내와 추천 제목이 같은 새 버전을 가리킨다.
- AC08.4 이전 안 복구는 외부 예약·결제를 취소하거나 되돌리는 행위와 별개이며, 자동으로 외부 행위를 하지 않는다.

## US09 — 공유와 외부 실행을 분리하기 (P0 / WF06)

사용자로서, 동행인에게 공개 가능한 일정만 보여주고, 예약·결제는 별도로 승인하고 싶다. 주소·연락처가 노출되거나 내 동의 없이 비용이 발생하지 않도록 하기 위해서다.

인수 조건:
- AC09.1 공유 미리보기에서 동행인 실명·정확한 출발 위치·연락처·예약 식별자는 기본 제외한다.
- AC09.2 공개 링크 발행 전에 공개 범위를 보여주고 동의받는다. 비공개 공유에는 실제 인증·접근통제가 필요하며 추측하기 어려운 URL만으로 비공개라고 부르지 않는다.
- AC09.3 예약·결제·전화는 별도 행위별 확인을 요구한다. 공유 승인으로 실행 권한까지 얻지 않는다.
- AC09.4 프로토타입 공유 버튼은 ‘시연만 완료 / 링크 미발행’으로 표시하고 실제 발행 성공처럼 표현하지 않는다.
- AC09.5 공개 호스트에 게시하는 프로토타입은 고정 예시만 포함하고 사용자가 작성한 요청을 네트워크로 전송하지 않는다.

## US10 — 출발 전 중요한 조건 재확인하기 (P1 / WF03·04)

사용자로서, 시간이 지난 뒤 출발하기 전에 계획을 다시 확인하고 싶다. 영업·재고·행사가 바뀐 계획을 믿고 이동하지 않도록 하기 위해서다.

인수 조건:
- AC10.1 중요한 관측마다 유효성을 구분하며, 재고 같은 순간 상태와 운영 일정의 검증 시점을 하나로 뭉치지 않는다.
- AC10.2 실제 새 조회 없이 시각만 갱신하거나 ‘재확인 완료’로 표시하지 않는다.
- AC10.3 재확인 실패 시 기존 근거를 유지하되 과거 정보임을 표시하고 대안 검토를 제공한다.
- AC10.4 상시 감시·푸시 알림은 별도 명시된 서비스가 없으면 약속하지 않는다.

## 프로토타입의 범위와 실제 제품 요구사항 분리

이번 HTML에서 작동하는 것: 화면 전환, 원문 입력 유지, 분위기·계란 중요도 전환, 목적별 추천 설명, 본안·대안 선택, 수단별 예시 이동 안내, 단계 체크, 지연/비 변경안의 적용·거절·복구, 공유 범위 시연.

고정 예시: 장소명·이벤트·계란 미확인·시간·요금·소요시간. 실제 여행 의사결정에 사용하지 않는다.

공개 배포 주의: 앱 코드에는 입력 전송 기능이 없지만, 기존 공개 호스트의 Cloudflare CDN은 접속 통계 스크립트를 삽입한다. 공개 시연에는 민감한 정보를 입력하지 않는다. 글로벌 CDN 설정은 변경하지 않는다.

미구현: 자연어 분석, 실제 검색·지도·날씨·재고조회, 예약·전화·결제, 인증된 공유 링크, 실시간 감시, 음성입력, 동행인 협업.

## 테스트 추적

브라우저 실행 결과를 별도 ux-verification.json에 저장한다. 화면 렌더·흐름 테스트 통과가 실제 조사와 일정 판단 엔진의 합격을 뜻하지 않는다.

MVP 백엔드의 다음 검증: 본안의 모든 필수 조건에 증거 또는 명시적 미확인이 있는지, 조사 담당의 관측을 상황 검토 담당이 목적 영향으로 연결하는지, 불가·미확인 상태가 화면까지 보존되는지 계약 테스트로 검증한다.