搜索没有结果，就能清掉用户选好的条件吗？
用户想找黑色、5万韩元以内的键盘，结果为空就把条件全清掉，会发生什么？我会先确认搜索有没有正常完成。这个虚构商城案例交给三款AI后，WekeyLab AI选择Claude的设计作底稿：它把主搜索和条件数量查询的迟到响应一起处理，也写清了返回列表时恢复哪个状态。
先用Claude的状态设计，再确定这次范围
三家都反对自动清空条件，都区分正常空结果与搜索失败，并让用户主动修改。Claude进一步写了加载时不能出现零结果页面、补充查询的迟到响应，以及用户修改条件后的恢复规则。这些细节能让开发和QA看同一份依据。
ChatGPT把热门商品放到另一个需求里，并提醒确认日志收集范围，我会采用这两点。Gemini适合快速讨论，但优先提供清空全部条件，把单项移除作为可选扩展。这次我会先让用户尽量保留另一项条件。
本次范围是状态区分、用户选择后移除条件、只采用当前请求的响应，以及搜索状态恢复。热门商品的目的和位置另行讨论。
8加3，为什么不是总数？
输入是无线键盘、黑色、5万韩元以内，结果为0。只移除价格条件得到8项，只移除颜色得到3项，全部移除得到23项。这是同一时点分别查询的结果，不能当成可相加的分类数量，也不能只凭数量推出集合关系。
移除价格后仍然保留黑色，移除颜色后仍然保留价格上限。8项比3项多，不代表用户更愿意放弃价格要求。该由用户选择。
另外，折叠显示器在没有筛选条件时也正常返回0；服务器失败时没有返回数量；旧的键盘响应还会覆盖后来的鼠标结果。把它们都写成“没有结果”，就无法确定下一步。
保留条件：无线键盘 · 黑色 · 5万韩元以内 → 0项 仅移除价格：无线键盘 · 黑色 → 8项 仅移除颜色：无线键盘 · 5万韩元以内 → 3项 全部移除：无线键盘 → 23项
查看不同条件的画面
查看不同条件的画面
依据虚构输入制作的文案示例，不连接真实商城。
先判断搜索是否正常完成
把页面分成加载、错误、有结果、带筛选条件的空结果、无筛选条件的空结果。请求未完成时显示加载；收到成功响应和有效数量后再确定结果状态。请求失败或数量缺失时，保留搜索词、筛选和排序，提供重试。
有筛选条件，并不能证明它就是空结果的原因。键盘案例已经通过放宽条件找到商品，其他查询未必有相同证据。因此状态名称用“当前条件下没有结果”。
在这个状态下单独查询各项移除后的数量。查询中或失败时保留“移除价格条件”按钮，不写数量。主搜索已经正常结束，补充查询失败不应把整个页面变成错误。用户点击后，只修改对应条件并重新搜索，显示实际响应。
查看文字步骤
- 开始搜索时显示加载状态，成功前不显示零结果。
- 响应不属于当前搜索时丢弃；主搜索和备选数量查询遵守相同规则。
- 当前主搜索失败或未返回有效数量时，保留条件并提供重试。重试从加载状态重新开始。
- 数量大于零时展示列表。零结果且有筛选时允许移除指定筛选；无筛选时提供修改搜索词。
| 已确认状态 | 展示及操作 | 保留内容 |
|---|---|---|
| 有筛选的零结果 | 移除指定筛选，仅展示已确认数量 | 搜索词和未移除的筛选 |
| 无筛选的零结果 | 修改搜索词 | 已输入的搜索词 |
| 备选数量查询失败 | 不带数字的筛选移除按钮 | 主搜索零结果画面和筛选 |
| 主搜索失败或无数量 | 错误提示及重试 | 搜索词、筛选、排序 |
ChatGPT适合整理范围
ChatGPT明确指出，即使取消旧请求失败，也必须阻止旧响应写入页面。固定输入下，单独移除价格、颜色与全部移除的QA数量也正确。
它把数量查询失败后的处理留为两个选项：隐藏按钮，或保留不带数字的按钮。我会选后者，让用户仍然能修改条件，并补上加载状态的显示规则。
同一条件在判断、页面、开发范围和QA里重复出现。交接时可以把状态表作为统一依据，再让各项测试链接到对应状态。
ChatGPT原文：“취소가 실패하더라도 오래된 응답을 화면에 반영하지 않는 것이 필수 조건” 译文：即使取消失败，也必须阻止过期响应更新页面。
Gemini的短稿适合开会，执行条件还要补齐
这次Gemini复制原文为3,932字符，ChatGPT为5,675，Claude为5,787。Gemini最快能看完正常空结果、服务器错误和请求顺序，也明确要求补充查询失败不阻塞主页面。
但它把“清空全部条件（23项）”作为默认操作，单项移除是可选扩展。数字没有算错，选择顺序却和我不同。我会先放移除价格、移除颜色，后放全部移除。
它还把无筛选的0结果说成没有与搜索词相关的商品。已知事实只是当前查询返回0。商品库存、搜索处理仍需调查，页面先准确说明这次搜索没找到商品。
Gemini原文：“(선택적 확장) 조건별 단일 해제 요청이 성공했을 경우” 译文：作为可选扩展，在单项条件移除的查询成功时提供。
Claude把数量查询也写进了检验
改搜鼠标后，旧键盘的“移除价格后8项”也不能继续出现。Claude把最新请求规则用于补充数量，并写了查询期间改变搜索词的测试。这是我选择它的主要原因。
它要求用户移除条件后，以变更后的状态作为返回恢复依据；预览数量与实际搜索不同，要显示实际响应。8项是之前查询的值，并不保证用户点击时仍然为8。
需要改的是“因为条件而为0”这个状态名，以及“服务器没有改动”的确定说法。我会把前者改成“当前条件下0结果”，把后者放入开发确认项，先核对响应字段、补充查询支持和调用负载。
Claude原文：“해제 버튼용 개수 조회도 같은 규칙을 적용합니다. 검색 상태가 바뀐 뒤 도착한 개수는 버립니다.” 译文：移除条件按钮的数量查询也遵循同样规则，搜索状态变化后才到达的旧数量要丢弃。
WekeyLab AI交接稿：状态和操作
企划文档先说明目的和范围：准确显示搜索状态，让用户保留选择并决定下一步。设计文档则把状态、文案、按钮变化和响应采用规则连起来。
企划确认状态、文案与发布范围；开发确认成功与有效数量的表达、补充查询能力、调用上限和超时；QA核对页面与保留的条件。负责人和日期使用团队实际约定的值。
调用上限和等待时间先列为开发确认项。确定后，把长期等待的终止处理和连续点击同步到设计与测试。
目的：准确说明搜索状态，保留用户选择。 范围：状态区分、主动移除条件、最新响应校验、从详情返回时恢复搜索词·筛选·排序。 加载：“正在搜索。” 数量尚未确认。 搜索失败：“未能加载搜索结果。” 保留原搜索词·筛选·排序重试。 带筛选的0结果：“没有找到符合当前条件的商品。” 提供只移除价格、只移除颜色、全部移除。 无筛选的0结果：“这次搜索没有找到商品。” 返回修改搜索词。 补充数量：只显示与当前状态对应的成功查询值。等待或失败时保留无数字按钮。 响应采用：忽略旧的主查询和数量响应，显示实际重新搜索结果。 恢复：用户修改过条件时，以修改后的状态为准。 开发确认：必要字段、补充查询支持、调用上限、超时与终止处理。 日志确认：明确目的、字段、保留与访问范围，并确认是否需要保存原始搜索词。
先复现迟到响应和返回路径
使用固定输入，移除价格后保留黑色与搜索词，得到8项；移除颜色后保留价格上限，得到3项；全部移除得到23项。不操作则条件完全不变。
分别制造主搜索失败、部分补充查询失败、全部补充查询失败。只有主搜索失败进入错误页面，补充查询失败保留可用的无数字按钮。
把响应顺序倒过来：先搜键盘，再搜鼠标，最后送回键盘结果和数量。鼠标页面与提示都应保持。进入详情再返回时，对照进入前的搜索词、条件和排序。预览与实际数量不同也单独测试。
日志拆成搜索开始、成功、失败、移除条件、重新搜索结果和商品跳转。正常0结果率用正常完成的搜索作分母，错误率另算。条件修改后是否成功搜到商品并点击，也要连接查看；点了按钮不等于完成目标。
先核对旧日志定义。如果旧0结果混入失败且无法分离，就用发布后分开的值建立基线。比较相同长度的时间段，同时查看搜索词组成和库存变化。
让AI连接条件，而不只画一个页面
这次给三家各发一次相同韩语输入，再按预先确定的八项要求检查原文。下面是后续可以使用的指示示例，不是本次又执行过的对话。
使用时替换搜索词、筛选、数量和已有能力。没有约定的负责人、日期、实现参数保留为确认事项。相关的转化率文章介绍如何区分观察与原因，优惠券和运费QA文章则展示输入与预期结果的连接。
后续指示示例：“把主搜索和各项补充数量查询的状态分开，先说明你理解的条件。连接只移除价格后保留哪些值、如何处理迟到响应、从详情返回时恢复什么。写清失败时的文案和按钮，再把相同规则变成QA输入与预期结果。尚未约定的实现参数列为确认事项。”
来源与实际记录
2026年9月24日12:11—12:16 KST，在三个服务的新对话各提交一次相同韩语问题，并通过回答复制功能保存原文。ChatGPT Free、Think关闭、未显示具体模型；Gemini Flash、套餐未核实；Claude Free、Sonnet 5中等。没有长度限制、重新生成或后续执行，保留既有账号设置。提问前固定虚构输入和八项要求，再核对三份原文的24项。交接稿与后续指示为WekeyLab AI编写，没有实际商城上线、营收或可用性实测。字符数包含复制格式和换行。英文与中文是同一次韩语执行的本地化，搜索量未确认。
Baymard — Search UX: improving no-results pages
Nielsen Norman Group — Designing empty states
쿠폰·배송비 QA 비교 / Checkout QA comparison
가입 전환율 판단 / Signup conversion readout
ChatGPT · 2026-09-24T03:14:07.251Z
쇼핑몰 검색 화면을 고치는 서비스 기획을 맡았어. 아래는 가상 안건이야. 운영팀에서는 “검색 결과가 없으면 필터를 전부 자동으로 풀고 인기 상품을 보여주자”고 요청했어. 이 요청을 어떻게 검토하고 어떤 범위로 개발에 넘기면 좋을까? 기획 판단부터 화면 동작과 안내 문구, 개발·QA에 전달할 내용까지 써줘.
지금 확인한 상황은 이래.
- 검색어는 '무선 키보드', 선택한 조건은 '검정'과 '5만 원 이하'야. 검색 요청은 정상 완료됐고 현재 조건의 결과는 0개야. 같은 검색어에서 가격 조건만 해제하면 8개, 색상 조건만 해제하면 3개가 나와. 두 조건을 모두 해제하면 23개야. 이 수치는 같은 시점의 별도 조회 결과이며 서로 더할 수 있는 분류 수는 아니야.
- 다른 검색어 '접이식 모니터'는 필터가 없는 정상 검색에서도 0개야.
- 검색 서버가 일시적으로 실패하는 경우도 있어. 이때는 결과 개수가 오지 않는데, 현재 화면에서는 빈 배열로 바꿔서 똑같이 '검색 결과가 없습니다'라고 표시해.
- 사용자가 '키보드'를 검색한 직후 '마우스'로 바꾸면, 먼저 보낸 키보드 요청의 응답이 늦게 도착해서 마우스 결과를 덮어쓰는 현상이 재현됐어.
- 결과 상품을 보고 뒤로 돌아왔을 때에는 검색어, 선택한 조건, 정렬이 유지돼야 해.
이번에 사용할 수 있는 기능도 정해져 있어. 서버는 검색 성공 여부와 현재 검색의 결과 수를 알려줄 수 있어. 조건을 하나 해제했을 때의 결과 수는 별도 요청으로 조회해야 하고 실패할 수도 있어. 오타 교정, 동의어 추천, 개인화 추천은 제공하지 않아. 인기 상품 목록은 있지만 해당 검색어와 관련된 상품이라는 보장은 없어. 검색 시스템을 바꾸는 작업은 이번 범위에 들어가지 않아.
사용자가 고른 조건은 확인 없이 바뀌지 않아야 해. 화면을 바꾼 뒤 무엇을 기록하고 어떤 상황을 검수해야 개선 여부를 판단할 수 있을지도 함께 정리해줘. 아직 확인하지 않은 원인이나 수익 효과는 결정된 사실처럼 채우지 말아줘.
아래처럼 잡는 것이 좋습니다. 핵심은 **“0개면 필터를 자동으로 해제하고 인기 상품을 보여준다”를 그대로 구현하지 않고, 검색 실패와 정상적인 0건을 먼저 구분한 뒤, 사용자가 선택한 조건은 유지하면서 선택적 대안을 제공하는 것**입니다.
## 1. 기획 판단
### 결론
운영팀 요청은 **그대로 개발 범위로 넘기지 않는 것**을 권합니다.
이유는 세 가지입니다.
1. **정상적인 0건과 검색 시스템 실패를 현재 데이터만으로 구분할 수 있어야 함**
* 정상 검색인데 조건 때문에 0건인 경우와
* 검색 서버 실패로 결과 수 자체를 받지 못한 경우를
같은 “검색 결과가 없습니다”로 처리하면 사용자가 잘못된 안내를 받습니다.
* 서버가 `검색 성공 여부 + 결과 수`를 제공할 수 있으므로 이번 작업에서 반드시 구분하도록 합니다.
2. **사용자가 고른 조건을 확인 없이 바꾸면 안 됨**
* `검정 + 5만 원 이하`를 선택한 사용자가 0건을 봤다고 해서 시스템이 임의로 조건을 풀어버리면 현재 검색 조건과 화면의 결과가 불일치하게 됩니다.
* 특히 가격 조건만 풀었을 때 8개, 색상만 풀었을 때 3개라는 사실은 **어느 조건을 자동으로 풀어야 하는지 결정해 주지 않습니다.**
3. **인기 상품은 '무선 키보드'와 관련 있다는 보장이 없음**
* 조건을 자동 해제한 결과보다 더 나아가 인기 상품을 보여주면 검색 의도와 무관한 상품을 노출할 수 있습니다.
* 따라서 이번 범위에서는 인기 상품을 **검색 결과의 대체 결과처럼 자동 노출하지 않는 것**이 안전합니다.
### 이번 사례에서의 권장 동작
`무선 키보드 + 검정 + 5만 원 이하 → 0개`라면:
> **현재 조건에서는 검색 결과가 없습니다.**
> [가격 조건 해제] → 8개
> [색상 조건 해제] → 3개
> [조건 모두 해제] → 23개
여기서 사용자가 버튼을 누르면 **그때 해당 조건을 해제**합니다.
즉, 시스템이 조건을 몰래 변경하는 것이 아니라 **사용자가 선택한 변경을 명시적으로 반영**합니다.
그리고 `접이식 모니터`처럼 **필터가 없는 상태에서도 0개**라면 조건 해제 안내가 아니라 일반적인 검색 결과 0건 화면을 보여줍니다.
---
## 2. 화면 동작 정의
### A. 정상 검색 + 결과 있음
예:
`무선 키보드 / 검정 / 5만 원 이하 → 0건이 아닌 경우`
* 검색 결과 표시
* 검색어, 필터, 정렬 상태 유지
* 상품 클릭 후 뒤로 돌아오면 동일한 검색 상태 복원
### B. 정상 검색 + 현재 조건에서 0건
예:
`무선 키보드 / 검정 / 5만 원 이하 → 0건`
화면에는:
검색 결과가 없습니다.
현재 선택한 조건을 해제하면 더 많은 상품을 확인할 수 있습니다.
[가격 조건 해제 (8개)]
[색상 조건 해제 (3개)]
[모든 조건 해제 (23개)]
버튼을 누른 경우에만 해당 조건을 실제로 변경합니다.
단, **조건 하나를 해제했을 때의 결과 수 조회가 실패했다면 해당 숫자를 임의로 표시하지 않습니다.** 예를 들어 가격 조건 해제 결과를 조회하지 못했다면:
> 가격 조건 해제
정도로만 표시하거나 해당 선택지를 숨기는 식으로 정의할 수 있습니다. 어느 쪽을 택할지는 UI 정책으로 확정해야 합니다.
### C. 정상 검색 + 필터 없음 + 0건
예:
`접이식 모니터 / 필터 없음 → 0건`
이 경우에는 “조건을 해제하세요”가 의미가 없습니다.
검색 결과가 없습니다.
다른 검색어로 다시 검색해 주세요.
오타 교정이나 동의어 추천은 이번 기능에서 제공하지 않으므로 그런 기능이 있는 것처럼 안내하지 않습니다.
### D. 검색 서버 실패
이 경우는 **0건과 완전히 다른 상태**로 취급해야 합니다.
서버의 성공 여부가 실패이거나 결과 수를 받지 못했다면:
검색 결과를 불러오지 못했습니다.
잠시 후 다시 시도해 주세요.
[다시 검색]
중요한 것은 **실패 응답을 빈 배열로 변환해서 0건으로 처리하는 현재 동작을 제거하는 것**입니다.
---
## 3. 검색 요청 순서 문제도 이번 범위에 포함
현재 발견된
> `키보드 검색 → 마우스 검색 → 늦게 도착한 키보드 응답이 마우스 결과를 덮어씀`
문제는 단순 UI 문구 문제가 아니라 **검색 결과 정확성 문제**이므로 함께 수정하는 것이 좋습니다.
### 개발 요구사항
각 검색 요청에는 요청 식별자를 두고,
* 현재 화면이 기다리고 있는 최신 요청인지 확인한 뒤 결과를 반영
* 이전 요청의 늦은 응답은 무시
* `키보드 → 마우스` 순서로 검색했을 때 키보드 응답이 늦게 도착해도 마우스 결과를 덮어쓰지 않도록 함
으로 명시합니다.
가능하면 이전 요청 취소도 고려할 수 있지만, **취소가 실패하더라도 오래된 응답을 화면에 반영하지 않는 것이 필수 조건**입니다.
---
## 4. 뒤로 가기 동작
상품 상세에서 검색 결과 화면으로 돌아오면 다음 상태를 그대로 복원해야 합니다.
* 검색어
* 선택한 필터
* 정렬
* 검색 결과 상태
예를 들어
> `무선 키보드 / 검정 / 5만 원 이하 / 인기순`
에서 상품을 눌렀다가 돌아왔다면 동일한 상태여야 합니다.
특히 **사용자가 명시적으로 조건을 해제하지 않았다면 조건을 자동으로 변경하지 않습니다.**
---
# 5. 개발 전달 범위
개발 티켓은 다음 정도로 쪼개는 것이 명확합니다.
### [검색 상태 처리]
**정상**
* 서버 성공 여부 확인
* 성공 + 결과 수 0 → 0건 상태
* 성공 + 결과 수 > 0 → 결과 표시
**실패**
* 서버 실패 또는 결과 수를 받을 수 없는 상태 → 검색 오류 상태
* 실패를 빈 배열로 변환하여 0건으로 처리하지 않음
### [0건 대안 조회]
현재 조건이 0건이고 필터가 선택되어 있는 경우:
* 각 조건을 하나씩 해제했을 때의 결과 수를 별도 요청
* 요청 성공 시 결과 수 표시
* 요청 실패 시 임의의 수를 표시하지 않음
* 하나의 조건을 해제한 결과와 다른 조건을 해제한 결과는 별도 집합이므로 **수를 합산하거나 중복 제거한 것처럼 계산하지 않음**
### [사용자 선택에 따른 필터 변경]
* 자동으로 필터를 변경하지 않음
* 사용자가 `[가격 조건 해제]`를 누르면 가격 조건만 해제
* `[색상 조건 해제]`를 누르면 색상 조건만 해제
* `[모든 조건 해제]`를 누르면 모든 필터 해제
* 변경 후 새로운 검색 요청
### [인기 상품]
이번 범위에서는:
* 검색 0건의 대체 결과로 자동 표시하지 않음
* “검색어와 관련된 결과”처럼 표현하지 않음
인기 상품을 활용하려면 **관련성 보장 여부와 노출 목적을 별도의 기획으로 검토**하는 것이 좋습니다.
### [동시 검색 요청]
* 최신 검색 요청에 해당하는 응답만 화면에 반영
* 이전 요청의 늦은 응답은 무시
* `키보드 → 마우스` 순서의 빠른 검색 전환 테스트 포함
---
# 6. QA 테스트 케이스
| 상황 | 기대 결과 |
| ----------------------- | ------------------- |
| 조건 있는 정상 검색 + 결과 있음 | 상품 결과 표시 |
| `무선 키보드 + 검정 + 5만 원 이하` | 0건 + 조건 해제 선택지 |
| 가격 조건만 해제 | 8개 결과 |
| 색상 조건만 해제 | 3개 결과 |
| 모든 조건 해제 | 23개 결과 |
| 필터 없는 `접이식 모니터` | 0건 + 다른 검색어 안내 |
| 검색 서버 실패 | 오류 상태, 0건으로 표시하지 않음 |
| 조건 해제 결과 조회 실패 | 결과 수를 추측하지 않음 |
| 키보드 검색 후 마우스 검색 | 최종적으로 마우스 결과 유지 |
| 늦은 키보드 응답 도착 | 마우스 결과를 덮어쓰지 않음 |
| 상품 상세 진입 후 뒤로가기 | 검색어/필터/정렬 유지 |
| 0건 상태에서 뒤로가기 | 사용자가 선택한 필터 상태 유지 |
| 사용자가 가격 조건 해제 | 가격만 변경 |
| 사용자가 아무것도 누르지 않음 | 선택 조건 그대로 유지 |
---
# 7. 개선 여부를 판단하기 위해 기록할 것
이번 변경에서는 단순히 **“검색 결과가 몇 개 나왔나”**만 보면 부족합니다.
### 기본적으로 기록할 이벤트
* 검색 실행
* 검색어
* 선택된 필터 종류/값
* 정렬
* 성공/실패
* 결과 수
* 0건 발생
* 0건 화면에서 조건 해제 선택
* 어떤 조건을 해제했는지
* 조건 해제 후 검색 결과
* 다시 검색 선택
* 검색 오류 재시도
* 상품 클릭
* 상품 상세에서 검색 결과로 복귀
가능하다면 조건 해제 이후의 **상품 클릭, 장바구니, 구매 등 후속 행동**도 연결해서 볼 수 있게 합니다.
단, 검색어 원문 등은 개인정보·민감정보가 섞일 가능성을 고려해 실제 로그 정책에 맞게 수집 범위를 정해야 합니다.
---
# 8. 개선 여부를 볼 때 주의할 점
현재 자료만으로는 **수익이 증가할지, 전환율이 좋아질지, 어떤 조건 해제가 더 좋은지 결정할 수 없습니다.**
이번 변경 후에는 최소한 다음을 비교할 수 있게 만드는 것이 좋습니다.
1. 검색 중 0건이 발생하는 비율
2. 0건 이후 조건 해제 선택률
3. 조건 해제 후 실제 상품 조회/클릭률
4. 검색 결과에서 상품 상세로 이동하는 비율
5. 검색 후 구매 등 후속 행동
6. 검색 오류율
7. 검색 결과가 늦은 응답으로 잘못 덮어써지는 오류 발생 여부
8. 뒤로가기 후 검색 상태가 유지되지 않는 오류 발생 여부
그리고 **0건 감소 자체를 성공으로 정의하지 않는 것**도 중요합니다. 필터를 자동으로 풀면 0건은 줄어들 수 있지만, 그것만으로 사용자가 원하는 상품을 더 잘 찾았거나 매출이 증가했다고 결론 낼 수는 없습니다.
---
## 9. 아직 결정하면 안 되는 것
현재 정보만으로는 다음은 미확정 사항으로 남겨야 합니다.
* 가격과 색상 중 어느 조건을 우선적으로 해제할지
* 조건 해제 결과 조회가 실패했을 때 버튼을 숨길지, 숫자 없이 보여줄지
* 인기 상품을 향후 0건 화면에 사용할지
* 0건 이후 조건 해제가 구매율/매출에 미치는 영향
* 어떤 조건 해제가 사용자 만족도에 더 유리한지
* 검색 서버 실패의 실제 원인과 발생률
* 검색어별로 관련 상품이 충분하지 않은 원인
특히 **“가격을 풀면 8개니까 가격을 우선 해제하는 게 낫다”라고 결론 내리면 안 됩니다.** 8개와 3개는 단지 해당 조건 하나를 제거했을 때의 결과 수이고, 사용자 의도나 사업 효과를 나타내는 지표는 아니기 때문입니다.
### 한 줄로 개발 범위를 정리하면
> **이번 릴리스는 ‘0건이면 조건을 자동 변경하거나 인기 상품으로 대체하는 기능’이 아니라, 정상 0건과 검색 실패를 구분하고, 사용자가 선택한 조건을 유지하면서 조건별 대안을 명시적으로 선택할 수 있게 하며, 검색 응답 순서 및 검색 상태 보존 문제를 함께 수정하는 범위로 정의하는 것이 적절합니다.**
Gemini · 2026-09-24T03:15:07.624Z
쇼핑몰 검색 화면을 고치는 서비스 기획을 맡았어. 아래는 가상 안건이야. 운영팀에서는 “검색 결과가 없으면 필터를 전부 자동으로 풀고 인기 상품을 보여주자”고 요청했어. 이 요청을 어떻게 검토하고 어떤 범위로 개발에 넘기면 좋을까? 기획 판단부터 화면 동작과 안내 문구, 개발·QA에 전달할 내용까지 써줘.
지금 확인한 상황은 이래.
- 검색어는 '무선 키보드', 선택한 조건은 '검정'과 '5만 원 이하'야. 검색 요청은 정상 완료됐고 현재 조건의 결과는 0개야. 같은 검색어에서 가격 조건만 해제하면 8개, 색상 조건만 해제하면 3개가 나와. 두 조건을 모두 해제하면 23개야. 이 수치는 같은 시점의 별도 조회 결과이며 서로 더할 수 있는 분류 수는 아니야.
- 다른 검색어 '접이식 모니터'는 필터가 없는 정상 검색에서도 0개야.
- 검색 서버가 일시적으로 실패하는 경우도 있어. 이때는 결과 개수가 오지 않는데, 현재 화면에서는 빈 배열로 바꿔서 똑같이 '검색 결과가 없습니다'라고 표시해.
- 사용자가 '키보드'를 검색한 직후 '마우스'로 바꾸면, 먼저 보낸 키보드 요청의 응답이 늦게 도착해서 마우스 결과를 덮어쓰는 현상이 재현됐어.
- 결과 상품을 보고 뒤로 돌아왔을 때에는 검색어, 선택한 조건, 정렬이 유지돼야 해.
이번에 사용할 수 있는 기능도 정해져 있어. 서버는 검색 성공 여부와 현재 검색의 결과 수를 알려줄 수 있어. 조건을 하나 해제했을 때의 결과 수는 별도 요청으로 조회해야 하고 실패할 수도 있어. 오타 교정, 동의어 추천, 개인화 추천은 제공하지 않아. 인기 상품 목록은 있지만 해당 검색어와 관련된 상품이라는 보장은 없어. 검색 시스템을 바꾸는 작업은 이번 범위에 들어가지 않아.
사용자가 고른 조건은 확인 없이 바뀌지 않아야 해. 화면을 바꾼 뒤 무엇을 기록하고 어떤 상황을 검수해야 개선 여부를 판단할 수 있을지도 함께 정리해줘. 아직 확인하지 않은 원인이나 수익 효과는 결정된 사실처럼 채우지 말아줘.
운영팀의 요청은 검색 실패 시 사용자 이탈을 막으려는 의도지만, "사용자가 직접 설정한 조건을 임의로 모두 해제하는 동작"은 사용자의 의도를 왜곡하고 혼란을 줄 수 있습니다.
요청 조건을 안전하게 수정하고, 제시된 기술적 제약과 Edge Case(검색 서버 오류, 경쟁 상태 등)를 반영한 **서비스 기획안**입니다.
---
## 1. 기획 판단 및 개선 방향
### 운영팀 요청 검토
* **위험 요인:** 사용자가 explicit하게 선택한 조건(예: '검정', '5만 원 이하')을 시스템이 임의로 완전히 지워버리면, 사용자는 자신이 선택한 조건의 상품인 줄 착각하고 구매하거나 의도치 않은 화면 변경에 혼란을 느낍니다. "사용자가 고른 조건은 확인 없이 바뀌지 않아야 한다"는 원칙에 위배됩니다.
* **대안 제시:**
1. 조건 무단 해제 대신 **"필터 완화 제안(조건 완화)"** 버턴/UI를 노출하여 사용자가 주도권을 갖게 합니다.
2. 필터를 풀어도 결과가 0개인 검색어('접이식 모니터')에는 검색어 자체에 대한 연관 상품이 없으므로, 인기 상품 노출 시 "해당 검색어와 무관한 전체 인기 상품일 수 있음"을 명확히 안내합니다.
---
## 2. 화면 동작 및 안내 문구 (UX/UI 상세)
시나리오별 화면 동작 규칙입니다.
```
[시나리오별 화면 처리 흐름]
1. 정상 조회 결과 0개 (필터 있음)
└─ 기존 필터 유지 + "조건 완화" 안내 및 개수별 칩 노출
2. 정상 조회 결과 0개 (필터 없음)
└─ "검색 결과 없음" + 전체 인기 상품 노출 (검색어와 무관함 안내)
3. 검색 서버 일시적 오류 (응답 실패)
└─ 빈 배열 처리 금지 → "일시적 오류 발생" + 재시도 버튼 노출
4. Race Condition (검색어 연속 변경)
└─ 이전 요청 취소 또는 Sequence ID 검증으로 최신 요청만 반영
```
### 시나리오 1: 필터 선택 후 결과 0개 ('무선 키보드' + '검정' + '5만 원 이하')
* **기존 조건 유지:** 상단 필터 칩 영역에는 사용자가 선택한 '검정', '5만 원 이하' 상태를 그대로 유지합니다.
* **안내 문구:**
> `"선택하신 조건에 맞는 '무선 키보드' 상품이 없습니다."`
> `"아래 조건을 해제하여 더 많은 상품을 찾아보세요."`
* **조건 해제 제안 버튼 (Action):**
* `[전체 조건 해제하기 (23개)]` 버튼 제공
* *(선택적 확장)* 조건별 단일 해제 요청이 성공했을 경우: `[가격 조건만 해제 (8개)]`, `[색상 조건만 해제 (3개)]` 칩/버튼 노출. (별도 조회 실패 시 해당 버튼은 숨기거나 기본 전체 해제 버튼만 노출)
### 시나리오 2: 필터 없는 정상 검색 결과 0개 ('접이식 모니터')
* **기존 조건:** 필터 없음.
* **안내 문구:**
> `'접이식 모니터'에 대한 검색 결과가 없습니다.`
> `단어의 철자가 정확한지 확인하거나, 다른 검색어로 검색해 보세요.`
* **하단 영역 (인기 상품 노출):**
* 타이틀: `지금 많이 찾는 인기 상품`
* 캡션/안내: `* 검색어와 직접적인 연관이 없는 전체 인기 상품입니다.`
### 시나리오 3: 검색 서버 오류 (일시적 실패)
* **주의:** 결과를 빈 배열(`[]`)로 변환하여 "결과 없음"으로 노출하는 기존 로직 폐지.
* **안내 문구:**
> `검색 결과를 불러오지 못했습니다.`
> `잠시 후 다시 시도해 주세요.`
* **Action:** `[다시 시도]` 버튼 노출.
---
## 3. 개발 및 QA 전달 명세
### 개발 요구사항 (Functional Requirements)
#### 1) API 응답 구분 및 예외 처리
* **검색 성공/실패 구분:** Server HTTP Status 또는 Response `success: false` 시, 결과 0개 화면이 아닌 **오류 화면**을 노출해야 합니다.
* **조건 해제 조회 예외 처리:** 조건 완화 개수 조회를 위한 별도 API 호출 실패 시, 사용자 화면 전체가 블록되지 않고 기본 결과 0개 안내만 노출되도록 비동기 독립 처리합니다.
#### 2) 경쟁 상태 (Race Condition) 해결
* **문제:** '키보드' 검색 후 '마우스' 검색 시, 이전 응답이 나중에 도착하여 화면을 덮어씀.
* **해결 방안:**
* Client-side: 새로운 검색 요청 시 이전 pending 상태인 `axios/fetch` AbortController로 취소.
* Request Sequence Tracking: 각 검색 요청에 `requestId` 또는 `timestamp`를 부여하여, 가장 마지막에 발송한 요청의 응답만 UI에 바인딩.
#### 3) 뒤로가기(Back Button) 상태 보존
* **보존 대상:** 검색어, 선택된 필터 조건(색상, 가격 등), 정렬 순서, 스크롤 위치.
* **구현 방식:** 검색 실행 시 URL Query Parameter(예: `?q=무선키보드&color=black&maxPrice=50000&sort=popular`)에 상태를 동기화하고, 뒤로가기 시 URL 파라미터를 읽어 화면 상태를 복원.
---
### QA 검수 시나리오 (Test Cases)
| 번호 | 테스트 상황 | 입력/동작 | 기대 결과 |
| --- | --- | --- | --- |
| **TC-01** | 필터 적용 후 결과 0개 | '무선 키보드' + '검정' + '5만 원 이하' 검색 | 선택한 필터 상태 유지, 결과 0개 안내 문구 및 '조건 해제' 버튼 노출 확인 |
| **TC-02** | 필터 전체 해제 동작 | TC-01 상태에서 '전체 조건 해제' 클릭 | 필터 해제 상태로 재검색되어 23개 상품 정상 노출 |
| **TC-03** | 필터 없는 결과 0개 | '접이식 모니터' 검색 | 결과 없음 문구와 함께 인기 상품 노출 (검색어 연관성 미보장 안내 문구 확인) |
| **TC-04** | 검색 서버 일시 오류 | 검색 API 500/Timeout 유발 | "결과 없음"이 아닌 "다시 시도" 오류 UI 노출 |
| **TC-05** | 연속 검색 요청 (Race Condition) | '키보드' 입력 직후 빠른 속도로 '마우스' 입력 | 최종 화면에 '마우스' 검색 결과만 노출되어야 함 |
| **TC-06** | 상세 진입 후 뒤로가기 | 검색 결과 상품 클릭 후 뒤로가기 버튼 클릭 | 기존 검색어, 필터 조건, 정렬, 스크롤 위치 완벽 복원 |
---
## 4. 로깅 및 개선 검증 계획
개선 작업의 효과를 정확히 측정하기 위한 이벤트 로깅 및 검수 지표입니다.
### 로그 수집 정의 (Analytics Events)
1. **`search_zero_result` (결과 0개 노출):**
* Property: `keyword`, `has_filter` (boolean), `filter_types`
2. **`click_filter_reset` (조건 해제 클릭):**
* Property: `keyword`, `reset_type` (all / single)
3. **`click_popular_item_on_zero` (결과 0개 화면 내 인기 상품 클릭):**
* Property: `keyword`, `item_id`
### 검수 및 판단 지표
* **검색 재시도 비율 (Search Retry Rate):** 결과 0개를 접한 후 이탈하지 않고 필터 완화 버튼을 누르거나 검색어를 수정하는 비율.
* **결과 0개 페이지에서의 전환율 (Conversion Rate from Zero-Result):** 결과 0개 노출 후 필터 해제 또는 인기 상품을 통해 최종 상품 상세/구매로 이어지는 비율.
* **검색 관련 C/S 발생 건수:** "필터가 멋대로 풀려요", "원하지 않는 상품이 나와요" 등 사용자 불편 접수 건수 추이 모니터링.Claude · 2026-09-24T03:15:24.885Z
쇼핑몰 검색 화면을 고치는 서비스 기획을 맡았어. 아래는 가상 안건이야. 운영팀에서는 “검색 결과가 없으면 필터를 전부 자동으로 풀고 인기 상품을 보여주자”고 요청했어. 이 요청을 어떻게 검토하고 어떤 범위로 개발에 넘기면 좋을까? 기획 판단부터 화면 동작과 안내 문구, 개발·QA에 전달할 내용까지 써줘.
지금 확인한 상황은 이래.
- 검색어는 '무선 키보드', 선택한 조건은 '검정'과 '5만 원 이하'야. 검색 요청은 정상 완료됐고 현재 조건의 결과는 0개야. 같은 검색어에서 가격 조건만 해제하면 8개, 색상 조건만 해제하면 3개가 나와. 두 조건을 모두 해제하면 23개야. 이 수치는 같은 시점의 별도 조회 결과이며 서로 더할 수 있는 분류 수는 아니야.
- 다른 검색어 '접이식 모니터'는 필터가 없는 정상 검색에서도 0개야.
- 검색 서버가 일시적으로 실패하는 경우도 있어. 이때는 결과 개수가 오지 않는데, 현재 화면에서는 빈 배열로 바꿔서 똑같이 '검색 결과가 없습니다'라고 표시해.
- 사용자가 '키보드'를 검색한 직후 '마우스'로 바꾸면, 먼저 보낸 키보드 요청의 응답이 늦게 도착해서 마우스 결과를 덮어쓰는 현상이 재현됐어.
- 결과 상품을 보고 뒤로 돌아왔을 때에는 검색어, 선택한 조건, 정렬이 유지돼야 해.
이번에 사용할 수 있는 기능도 정해져 있어. 서버는 검색 성공 여부와 현재 검색의 결과 수를 알려줄 수 있어. 조건을 하나 해제했을 때의 결과 수는 별도 요청으로 조회해야 하고 실패할 수도 있어. 오타 교정, 동의어 추천, 개인화 추천은 제공하지 않아. 인기 상품 목록은 있지만 해당 검색어와 관련된 상품이라는 보장은 없어. 검색 시스템을 바꾸는 작업은 이번 범위에 들어가지 않아.
사용자가 고른 조건은 확인 없이 바뀌지 않아야 해. 화면을 바꾼 뒤 무엇을 기록하고 어떤 상황을 검수해야 개선 여부를 판단할 수 있을지도 함께 정리해줘. 아직 확인하지 않은 원인이나 수익 효과는 결정된 사실처럼 채우지 말아줘.
# 0건 검색 화면 개선안: 자동 해제 대신 "선택형 해제 + 오류 분리"
## 1. 결론
- 운영팀 요청("필터 전부 자동 해제 후 인기 상품 노출")은 **그대로 받지 않기를 권장**합니다. 사용자 조건을 확인 없이 바꾸고, 무관한 인기 상품이 검색 결과처럼 보일 수 있기 때문입니다.
- 대신 이번 범위는 다섯 가지입니다.
1. 0건 원인을 세 가지로 구분해 다르게 보여줍니다: 조건 때문에 0건, 조건 없이도 0건, 검색 실패.
2. 조건 해제는 사용자가 직접 누르게 하고, 가능하면 해제 시 결과 수를 함께 보여줍니다.
3. 검색 실패를 "결과 없음"으로 표시하지 않습니다.
4. 늦게 도착한 이전 응답이 최신 결과를 덮어쓰지 않게 합니다.
5. 뒤로가기 시 검색어, 조건, 정렬을 유지합니다.
- 인기 상품은 "검색 결과가 아닌 별도 영역"으로만 노출합니다.
## 2. 현황과 판단 근거
| 확인된 사실 | 판단 |
|---|---|
| '무선 키보드' + 검정 + 5만 원 이하 = 0개. 가격만 해제 8개, 색상만 해제 3개, 둘 다 해제 23개 | 조건 조합이 원인인 0건. 어느 조건을 풀지는 사용자가 골라야 함. 세 수치는 합산 불가이므로 합산이나 비율로 표시하지 않음 |
| '접이식 모니터'는 필터 없이도 0개 | 해제할 조건이 없으므로 해제 안내는 부적합. 원인은 미확인이며 이번 범위에서 규명·해결 대상 아님 |
| 서버 실패 시 빈 배열로 변환해 "결과가 없습니다" 표시 | 실패와 0건이 구분되지 않는 화면 결함. 기존 "결과 없음" 로그에도 실패가 섞였을 가능성이 있어 과거 지표를 기준선으로 쓰기 어려움 |
| 이전 검색 응답이 최신 결과를 덮어씀(재현됨) | 요청 순서 관리 결함. 화면 쪽에서 막을 수 있음 |
| 인기 상품은 검색어와 관련성 보장 없음 | 검색 결과 자리에 넣으면 오해 유발. 별도 영역과 별도 라벨 필요 |
**자동 해제를 권장하지 않는 이유**
1. 사용자가 고른 조건이 확인 없이 바뀌어 요구사항에 어긋납니다.
2. 예시에서 "검정" 조건은 사용자에게 중요한 조건일 수 있는데, 전부 풀면 23개가 나와도 원하는 결과가 아닐 수 있습니다.
3. 자동 해제가 운영팀이 기대하는 효과를 낸다는 근거는 아직 없습니다. 이 검증은 아래 8번의 기록으로 합니다.
## 3. 이번 범위
| 포함 | 제외 |
|---|---|
| 0건 3분류 화면, 조건 해제 버튼(결과 수 표시는 best-effort), 인기 상품 별도 영역 | 검색 시스템 변경 |
| 실패 화면과 다시 시도 | 오타 교정, 동의어 추천, 개인화 추천 |
| 최신 요청만 반영 | '접이식 모니터' 0건의 원인 규명과 상품 보강 |
| 뒤로가기 상태 유지 | 필터 자동 해제 |
| 로그 이벤트 추가 | 수익 효과 목표치 설정 |
## 4. 화면 동작
**상태 분기 (서버의 성공 여부와 결과 수 기준)**
| 상태 | 조건 | 표시 |
|---|---|---|
| 로딩 | 최신 요청 진행 중 | 로딩 표시. 0건 화면 노출 금지 |
| 결과 있음 | 성공 + 결과 ≥ 1 | 기존 목록 |
| **A. 조건 때문에 0건** | 성공 + 0건 + 선택 조건 ≥ 1 | 안내, 현재 조건 표시, 해제 버튼, 인기 상품 영역 |
| **B. 조건 없이 0건** | 성공 + 0건 + 선택 조건 없음 | 안내, 인기 상품 영역. 해제 버튼 없음 |
| **C. 검색 실패** | 성공 여부 false, 네트워크 오류, 또는 결과 수 누락 | 오류 안내와 다시 시도. 검색어, 조건, 정렬 유지. 해제 버튼과 인기 상품 없음 |
**상태 A 세부**
1. 현재 조건을 칩으로 표시합니다(예: 검정, 5만 원 이하).
2. 해제 버튼은 "조건 하나씩 해제"와 "모든 조건 해제"를 제공합니다. 조건이 1개면 "모든 조건 해제" 하나만 둡니다.
3. 결과 수 표시:
- 별도 조회로 가져오며 버튼 클릭 전에는 참고값입니다.
- 조회 실패나 지연 시 숫자 없이 버튼만 표시합니다.
- 조회 결과가 0인 버튼은 숨깁니다(눌러도 0건이므로).
- 어떤 버튼도 숫자 합산이나 "총 N개"로 표시하지 않습니다.
4. 버튼을 누르면 해당 조건만 해제하고 **실제 재검색 결과를 표시**합니다(표시했던 숫자와 다를 수 있음). 이 상태가 이후 뒤로가기 복원 기준입니다.
5. 사용자가 아무것도 누르지 않으면 조건은 그대로 유지합니다.
**인기 상품 영역 (A, B에서만)**
- 해제 버튼 아래(A) 또는 안내 아래(B)에 배치하고, "검색 결과"와 시각적으로 분리합니다.
- 라벨로 검색어와 무관할 수 있음을 명시합니다.
- 상품 클릭은 검색 결과 클릭과 구분해 기록합니다.
- 운영팀 요청의 취지는 살리되, 효과 검증 전이므로 기능 플래그로 켜고 끌 수 있게 하는 것을 권장합니다.
**요청 순서 관리**
- 검색어, 조건, 정렬이 바뀔 때마다 요청 식별자를 부여하고 **가장 최근 요청의 응답만 화면에 반영**합니다.
- 이전 요청은 가능하면 취소하고, 취소가 안 되더라도 응답을 무시합니다.
- 해제 버튼용 개수 조회도 같은 규칙을 적용합니다. 검색 상태가 바뀐 뒤 도착한 개수는 버립니다.
**뒤로가기**
- 검색어, 조건, 정렬을 복원합니다(URL 파라미터 방식 권장).
- 복원 시 상태 A/B/C를 다시 판정합니다.
- 자동 해제된 조건이 복원 상태에 남는 일이 없어야 합니다.
## 5. 안내 문구 (초안)
| 상태 | 문구 |
|---|---|
| A 제목 | '무선 키보드'에 맞는 상품이 없어요. |
| A 보조 | 선택한 조건: 검정 · 5만 원 이하 / 조건을 해제하면 상품이 나올 수 있어요. |
| A 버튼 | 가격 조건 해제 (8개) · 색상 조건 해제 (3개) · 모든 조건 해제 (23개) |
| B 제목 | '접이식 모니터'에 맞는 상품이 없어요. |
| B 보조 | 다른 검색어로 다시 검색해 보세요. |
| 인기 상품 라벨 | 인기 상품 (검색어와 관련 없을 수 있어요) |
| C 제목 | 검색 결과를 불러오지 못했어요. |
| C 보조 | 잠시 후 다시 시도해 주세요. 선택한 검색어와 조건은 그대로 유지됩니다. |
| C 버튼 | 다시 시도 |
문구 유의점:
- 상태 C에서는 "없습니다", "없어요" 표현을 쓰지 않습니다.
- B에서는 오타 교정이나 추천을 암시하는 문구를 쓰지 않습니다(미제공 기능).
- 개수는 "N개" 형태로만 쓰고, 조회 시점 값이라 실제와 다를 수 있음을 알고 있어야 합니다.
## 6. 개발 전달 사항
1. **실패 판정**: 서버 성공 여부가 false이거나 네트워크 오류이거나 결과 수가 없으면 상태 C로 처리합니다. 빈 배열로 변환하는 기존 로직을 제거합니다.
2. **0건 판정**: 성공 + 결과 수 0일 때만 A/B로 분기하며, 선택 조건 유무로 A와 B를 나눕니다.
3. **개수 조회**: 조건별 1건과 전체 해제 1건. 상태 A일 때만 호출하고, 실패나 타임아웃이면 숫자 없이 버튼만 노출합니다.
- 조건이 많을 때의 호출 수 상한과 타임아웃 값은 개발 검토 후 확정 필요(아래 9번).
4. **최신 요청만 반영**: 4번 항목 규칙 적용.
5. **인기 상품**: 기존 목록 API 사용. 별도 영역과 라벨, 기능 플래그.
6. **뒤로가기 복원**: 검색어, 조건, 정렬.
7. **로그**: 8번 이벤트.
8. **변경 금지**: 사용자 조건을 코드가 임의로 바꾸는 경로가 없어야 합니다.
## 7. QA 시나리오
| # | 상황 | 기대 결과 |
|---|---|---|
| 1 | '무선 키보드' + 검정 + 5만 원 이하 | 상태 A, 조건 칩 표시, 세 버튼과 개수 표시 |
| 2 | 가격 해제 클릭 | '무선 키보드' + 검정으로 재검색, 실제 결과 표시, 색상 조건 유지 |
| 3 | 모든 조건 해제 클릭 | 조건 없이 재검색 |
| 4 | '접이식 모니터', 조건 없음 | 상태 B, 해제 버튼 없음, 인기 상품 영역 |
| 5 | 검색 서버 실패 | 상태 C, "없습니다" 문구 없음, 조건 유지, 인기 상품·해제 버튼 없음 |
| 6 | 상태 C에서 다시 시도 성공 | 정상 결과 표시, 조건 유지 |
| 7 | 결과 수 누락 응답 | 상태 C |
| 8 | '키보드' 후 즉시 '마우스'(이전 응답을 나중에 도착시킴) | 마우스 결과 유지 |
| 9 | 조건 변경 직후 이전 응답 지연 도착 | 최신 조건 결과 유지 |
| 10 | 개수 조회 일부 실패 | 해당 버튼만 숫자 없이 노출 |
| 11 | 개수 조회 전부 실패 | 모든 조건 해제 버튼은 동작 |
| 12 | 개수 조회 중 검색어 변경 | 이전 개수가 새 화면에 표시되지 않음 |
| 13 | 해제 버튼 표시 개수 ≠ 실제 재검색 결과 | 실제 결과 표시, 오류 없음 |
| 14 | 조건 해제 후 상품 상세에서 뒤로가기 | 해제된 상태 그대로 복원 |
| 15 | 조건 유지 상태에서 뒤로가기 | 검색어, 조건, 정렬 유지 |
| 16 | 해제 후 결과가 또 0건 | 상태 A 또는 B로 재판정 |
| 17 | 인기 상품 클릭 | 상세 이동, 로그에 인기 상품 클릭으로 구분 기록 |
| 18 | 아무 버튼도 누르지 않음 | 조건이 바뀌지 않음 |
## 8. 기록과 판단 기준
**추가 로그 (검색 세션 식별자, 검색어, 조건, 정렬 포함)**
| 이벤트 | 구분 값 |
|---|---|
| 0건 화면 노출 | 상태 A/B, 개수 조회 성공·실패 여부 |
| 검색 실패 화면 노출 | 오류 유형 |
| 다시 시도 클릭과 그 결과 | 성공·실패 |
| 해제 버튼 클릭 | 어떤 조건, 표시했던 개수, 실제 결과 수 |
| 인기 상품 노출·클릭 | |
| 이전 응답 폐기 | 발생 횟수 |
| 뒤로가기 복원 | 복원 성공·불일치 |
**개선 여부 판단 지표**
- 상태 A에서 해제 버튼을 눌러 결과 ≥ 1이 된 비율, 이후 상품 클릭까지 이어진 비율
- 상태 A/B 노출 후 재검색, 이탈, 상품 클릭 비율(인기 상품 클릭은 별도)
- 검색 실패 비율과 재시도 성공률(0건과 분리해서 집계)
- 이전 응답 폐기 횟수, 뒤로가기 복원 불일치 건수
- 비교는 배포 전후 동일 길이의 기간으로 하되, 기존 "결과 없음" 지표에는 실패가 섞여 있어 그대로 기준선으로 쓰지 않습니다. 배포 후 분리된 값을 기준으로 삼는 것을 권장합니다.
- 결제 전환 등 수익 지표는 관찰 항목으로만 두고 목표치는 이번에 정하지 않습니다.
## 9. 비용·기대효과·미확인 사항
**비용**
- 프런트엔드: 상태 분기, 요청 순서 관리, 뒤로가기 복원, 로그.
- 서버 변경은 없으나, 상태 A에서 개수 조회가 최대 조건 수 + 1건 추가됩니다.
- 공수 산정은 개발팀 검토 후 확정합니다(여기서는 수치를 추정하지 않음).
**기대효과 (검증 전 가설)**
- 사용자가 조건을 잃지 않고 다음 행동을 고를 수 있음
- 실패와 0건이 분리되어 지표가 정확해짐
- 결과가 뒤바뀌는 현상 제거
**미확인 사항**
- '접이식 모니터' 0건의 원인(상품 부재인지 색인 문제인지 등)
- 서버 실패가 일시적 장애인지 특정 패턴이 있는지
- 인기 상품 노출이 실제 이탈을 줄이는지(기능 플래그로 검증)
**가정 (확정 필요)**
1. 개수 조회 상한과 타임아웃은 개발 검토 후 정합니다.
2. 인기 상품은 A, B 모두에서 노출하되 기능 플래그로 제어합니다.
3. 뒤로가기 복원은 URL 파라미터 방식이며, 스크롤 위치 복원은 이번 범위에 넣을지 별도 확인이 필요합니다.
운영팀에는 "자동 해제는 사용자 선택권 문제로 제외하고, 선택형 해제와 인기 상품 별도 노출로 같은 목적을 달성한다"고 전달하면 됩니다. 다음 단계로 운영팀 전달용 요약이나 개발 티켓 문안 중 어느 쪽을 먼저 정리할까요?