검색 결과가 없다고, 사용자가 고른 조건을 지워도 될까?
검정 키보드를 5만 원 안에서 찾고 있는데, 결과가 없다는 이유로 조건이 전부 풀리면 어떨까? 나는 먼저 검색이 정상으로 끝났는지부터 확인할 거야. 이 가상 쇼핑몰 안건을 세 AI에 맡겨봤어. 위키렙AI는 Claude의 설계를 바탕으로 잡았어. 본 검색뿐 아니라 조건별 개수를 조회하는 요청까지 늦은 응답을 처리했고, 뒤로 돌아올 때 복원할 상태도 구체적이었거든.
Claude의 상태 설계를 쓰고, 이번 범위부터 정리할 거야
세 답 모두 조건을 자동으로 풀지 말자고 했어. 결과 0개와 검색 실패를 나누고, 사용자가 직접 조건을 바꾸도록 제안했지. 차이는 그다음이야. Claude는 로딩 중에 0건 화면을 보이지 않는 조건, 보조 조회의 늦은 응답, 조건을 해제한 뒤의 복원까지 이어서 적었어. 개발과 QA가 같은 기준을 보기 좋은 답이었어.
ChatGPT는 인기 상품을 이번 범위에서 분리하고 로그 수집 범위를 확인하자고 했어. 이 부분은 가져갈 거야. Gemini는 세 화면을 빠르게 훑기 좋지만 전체 조건 해제를 앞세우고 단일 조건 해제는 선택적 확장으로 뒀어. 이번 안건에서는 사용자가 중요하게 고른 조건을 최대한 남기는 쪽으로 순서를 잡겠어.
최종 범위는 검색 상태 구분, 선택한 조건만 해제, 최신 응답만 반영, 검색 상태 복원이야. 인기 상품은 운영팀과 노출 목적을 따로 정한 뒤 검토할 거야.
8개와 3개를 더하면 왜 안 되지?
입력은 무선 키보드, 검정, 5만 원 이하야. 이 조합에서는 0개였고 가격만 풀면 8개, 색상만 풀면 3개, 두 조건을 모두 풀면 23개였어. 같은 시점에 각각 조회한 결과라 서로 더할 수 없어. 두 조건 모두에 걸리지 않는 상품도 있을 수 있고, 집합 사이의 관계를 개수만 보고 계산하면 안 돼.
가격을 풀어 8개가 나온다는 건 검정 조건을 남겼을 때의 결과야. 색상을 풀어 3개가 나온다는 건 5만 원 이하 조건을 남겼을 때고. 숫자가 더 크다는 이유로 가격을 먼저 해제할 수는 없어. 사용자가 가격과 색상 중 무엇을 더 중요하게 보는지는 아직 모르니까.
입력에는 다른 문제도 있었어. 접이식 모니터는 필터 없이도 정상 검색 결과가 0개였고, 서버가 실패한 경우에는 결과 수가 오지 않았어. 키보드의 늦은 응답이 마우스 결과를 덮어쓰는 현상도 있었지. 이 세 가지를 한 화면의 “없음”으로 묶으면 처리 방법을 정할 수 없어.
현재 조건 유지: 무선 키보드 · 검정 · 5만 원 이하 → 0개 가격만 해제: 무선 키보드 · 검정 → 8개 색상만 해제: 무선 키보드 · 5만 원 이하 → 3개 두 조건 해제: 무선 키보드 → 23개
조건별 화면 확인
조건별 화면 확인
가상 입력으로 만든 화면 문안이야. 실제 쇼핑몰과 연결되지 않아.
먼저 검색이 정상 완료됐는지 확인해
화면 설계는 로딩, 오류, 결과 있음, 현재 조건의 결과 0개, 필터 없는 결과 0개로 나눌 거야. 검색 요청 중에는 로딩을 보여주고, 성공 응답과 유효한 결과 수가 왔을 때 결과 화면을 정해. 실패했거나 결과 수를 받지 못하면 같은 검색어와 조건을 보존한 재시도 화면으로 보내.
필터가 선택돼 있다는 사실만으로 “필터 때문에 상품이 없다”고 확정하지는 않아. 이번 키보드 예제는 조건을 해제한 조회에서 상품이 나왔지만, 다른 검색에서도 그렇다는 보장은 없어. 그래서 상태 이름은 “현재 조건의 결과 0개”로 쓸 거야.
그 상태에서 조건별 개수 조회를 따로 시작해. 조회 중이거나 실패한 버튼에는 숫자를 붙이지 않고 “가격 조건 해제”처럼 행동만 표시할 거야. 본 검색은 이미 정상으로 끝났으니 보조 조회 실패로 화면 전체를 오류로 바꾸지 않아. 사용자가 누르면 해당 조건만 바꿔 새로 검색하고 실제 받은 결과를 표시해.
순서를 글로 보기
- 검색을 시작하면 로딩을 표시해. 성공 전에 0개라고 쓰지 않아.
- 응답의 검색 상태가 현재 검색과 다르면 버려. 본 검색과 조건별 개수 조회에 같은 규칙을 써.
- 현재 본 검색이 실패했거나 결과 수가 유효하지 않으면 조건을 보존하고 재시도를 제공해. 재시도는 로딩부터 다시 시작해.
- 성공한 본 검색의 결과가 있으면 목록을 보여줘. 0개라면 필터가 있을 때에는 선택한 조건의 해제를, 필터가 없을 때에는 검색어 수정을 제공해.
| 확인한 상태 | 보여줄 내용 | 남길 조건 |
|---|---|---|
| 현재 조건의 결과 0개 | 선택한 필터만 해제. 확인된 개수만 표시 | 검색어와 해제하지 않은 필터 |
| 필터 없는 결과 0개 | 검색어 수정 | 입력한 검색어 |
| 조건별 개수 조회 실패 | 개수 없는 조건 해제 버튼 | 본 검색의 0개 화면과 선택 조건 |
| 본 검색 실패 / 개수 미수신 | 오류 안내와 재시도 | 검색어 · 필터 · 정렬 |
ChatGPT는 범위를 정리하기 좋았어
ChatGPT가 짚은 핵심은 요청을 취소하는 것과 오래된 응답을 막는 것이 서로 다른 조건이라는 점이야. 취소가 실패해도 최신 검색 결과를 지켜야 한다고 적었어. 가격만 해제, 색상만 해제, 전체 해제에 대한 QA 기대값도 입력과 맞았어.
다만 조건별 개수 조회에 실패하면 버튼을 숨길지, 숫자 없이 남길지 결정이 열려 있어. 나는 숫자 없이 남기는 쪽을 선택할 거야. 개수 안내가 없어도 사용자는 자기 조건을 수정할 수 있어야 하니까. 요청을 기다리는 로딩 상태도 화면 명세에 추가하겠어.
설명·화면 정의·개발 범위·QA에 같은 조건이 반복돼. 실제 인계할 때에는 상태표 한 곳을 기준으로 두고 각 검수 항목에서 그 상태를 연결하면 읽는 양을 줄일 수 있어.
ChatGPT 원문: “취소가 실패하더라도 오래된 응답을 화면에 반영하지 않는 것이 필수 조건”
Gemini의 짧은 안은 회의에 쓰고, 실행 조건은 더 붙일 거야
Gemini는 이번 세 답 중 가장 짧았어. 원문은 3,932자였고 ChatGPT는 5,675자, Claude는 5,787자였어. 정상 0건, 서버 오류, 응답 순서 문제를 빠르게 훑기 좋고, 보조 조회가 실패해도 본 화면을 막지 말라는 조건도 있었어.
다만 기본 버튼이 “전체 조건 해제하기 (23개)”이고 단일 조건 해제는 선택적 확장이야. 이건 숫자 오류는 아니지만 이번에 내가 고를 우선순위와 달라. 가격만 풀지, 색상만 풀지 먼저 고를 수 있게 하고 전체 해제는 그다음에 놓겠어.
또 필터 없는 0건을 설명하며 “검색어 자체에 대한 연관 상품이 없으므로”라고 했어. 확인된 사실은 현재 검색의 결과가 0개라는 것까지야. 실제 상품 부재인지 검색 처리 문제인지는 조사할 항목으로 남기고, 안내는 “이번 검색에서 상품을 찾지 못했어요”로 쓰겠어.
Gemini 원문: “(선택적 확장) 조건별 단일 해제 요청이 성공했을 경우”
Claude에서 가져갈 건 보조 조회까지 이어진 검수야
검색어를 마우스로 바꾸면 상품 목록뿐 아니라 이전 키보드의 “가격 해제 8개”도 사라져야 해. Claude는 조건 해제 버튼용 개수 조회에도 같은 최신 요청 규칙을 적용했어. 늦은 개수가 새 화면에 붙는 경우까지 QA에 넣은 게 선택 이유야.
조건 해제 후 상품을 보고 돌아오면 해제한 이후의 검색어·조건·정렬을 복원하라고 했어. 재검색 결과가 안내 숫자와 달라도 실제 응답을 보여주라는 조건도 유용해. 8개는 앞서 조회한 값이고, 사용자가 클릭할 때에도 반드시 8개여야 하는 건 아니거든.
고칠 표현도 있어. 상태명 “조건 때문에 0건”은 “현재 조건의 결과 0개”로 바꾸고, “서버 변경은 없으나”는 개발 확인 항목으로 옮길 거야. 성공 여부와 개수, 보조 조회가 실제 인터페이스에 어떤 형태로 제공되는지 확인해야 공수를 정할 수 있어.
Claude 원문: “해제 버튼용 개수 조회도 같은 규칙을 적용합니다. 검색 상태가 바뀐 뒤 도착한 개수는 버립니다.”
위키렙AI 수정안: 개발에 넘길 상태와 동작
나는 기획서에 목적과 범위를 먼저 남길 거야. 목적은 검색 결과를 정확히 안내하고 사용자가 조건을 잃지 않은 채 다음 행동을 고르게 하는 거야. 설계서에는 상태별 문구, 누른 버튼에 따라 바뀌는 조건, 응답 적용 기준을 이어서 적어.
기획 담당자는 아래 상태·문구·이번 범위를 확정하고, 개발 담당자는 검색 성공과 결과 수의 표현, 보조 조회 지원, 호출 상한과 대기 시간을 확인해. QA 담당자는 각 상태에서 실제로 보여야 할 문구와 보존할 조건을 대조해. 확인자와 날짜는 팀에서 정한 값을 문서에 채우면 돼.
인계문에서 조회 대기 시간과 호출 상한은 개발 협의 후 확정할 항목으로 남겼어. 이 값이 정해지면 오래 기다린 요청을 어떻게 끝낼지와 연속 클릭 처리까지 설계서·QA에 같이 반영해.
목적: 검색 상태를 정확히 안내하고 사용자가 고른 조건을 보존한다. 범위: 상태 구분, 사용자 선택에 따른 조건 해제, 최신 응답 반영, 상세에서 돌아왔을 때 검색어·필터·정렬 복원. 로딩: “검색 중이에요.” 결과 수는 미확정. 검색 실패: “검색 결과를 불러오지 못했어요.” 같은 검색어·조건·정렬로 다시 시도. 현재 조건의 결과 0개: “선택한 조건에 맞는 상품을 찾지 못했어요.” 가격만 해제·색상만 해제·전체 해제를 직접 선택. 필터 없는 결과 0개: “이번 검색에서 상품을 찾지 못했어요.” 검색어 수정으로 이동. 조건별 개수: 현재 검색 조건에 대응하는 조회 성공값만 표시. 대기·실패에는 숫자 없이 해제 버튼 유지. 응답 반영: 현재 요청과 다른 본 검색·개수 응답은 무시. 실제 재검색 결과를 적용. 복원: 사용자가 조건을 해제했다면 그 이후 상태를 기준으로 복원. 개발 확인: 필수 응답값 제공 여부, 보조 조회 지원, 호출 상한, 대기 시간과 종료 처리. 로그 검토: 수집 목적·필드·보관·열람 범위를 정하고 검색어 원문 저장 필요성을 확인.
정상 화면보다 늦은 응답과 뒤로가기를 먼저 재현해봐
검수에서는 가격만 풀어 색상과 검색어가 남는지, 색상만 풀어 가격이 남는지 확인해. 고정된 입력 데이터로는 각각 8개와 3개, 전체 해제는 23개가 나와야 해. 사용자가 아무것도 누르지 않았다면 처음 조건 그대로여야 하고.
다음에는 본 검색 실패, 조건별 조회 일부 실패, 전부 실패를 나눠 만들어봐. 본 검색 실패는 오류 화면으로, 개수 조회 실패는 숫자 없는 해제 버튼으로 나와야 해. 보조 조회가 실패했다고 이미 끝난 본 검색의 0개 상태를 없애면 안 돼.
응답 순서도 뒤집어봐. 키보드 요청 뒤 마우스를 검색하고 키보드 응답과 개수 조회를 나중에 도착시켜. 마우스 화면과 안내가 유지돼야 해. 상세에서 돌아왔을 때에는 진입 직전 검색어·조건·정렬과 같은지 대조해. 안내 개수와 실제 결과가 다른 상황도 별도 입력으로 확인할 거야.
기록은 검색 시작·정상 완료·실패, 조건 해제 선택·재검색 결과, 상품 이동으로 나눠. 정상 0건 비율은 정상 완료된 검색 중 0건의 비율로 정의하고 오류율은 별도로 봐. 조건 변경을 선택한 뒤 검색이 성공하고 상품을 눌렀는지도 연결하되, 버튼 클릭만으로 목적 달성이라고 쓰지는 않을 거야.
기존 화면의 0건에 오류가 섞여 있었으니 과거 로그 정의부터 확인해야 해. 실패를 따로 구분할 수 없다면 배포 이후 분리한 값을 새 기준으로 쌓자. 같은 기간 길이로 비교하되 검색어 구성이나 상품 재고 변화도 같이 확인해.
AI에는 화면 하나보다 조건을 연결해서 맡길 거야
이번에는 같은 한국어 입력을 세 곳에 한 번씩 보냈고, 미리 정한 여덟 기준으로 원문을 대조했어. 다음에 실제 설계 문서로 옮길 때 쓸 지시는 아래처럼 적겠어. 먼저 이해한 상태를 확인하고, 한 구간씩 수정한 뒤 검수 결과에 반영하는 순서야.
재사용할 때에는 검색어·필터·조회 결과·제공 가능한 기능을 자기 안건으로 바꿔. 팀과 정하지 않은 담당자와 날짜, 대기 시간을 AI가 채우면 확인 항목으로 돌려놓고. 결과 0개가 왜 나왔는지 조사할 때는 앞선 전환율 글처럼 관측과 원인을 나누고, 테스트 문서로 옮길 때는 쿠폰·배송비 QA 글의 입력과 기대 결과 연결을 참고해봐.
후속 지시 예시: “현재 설계에서 본 검색과 조건별 개수 조회의 상태를 따로 정리해. 먼저 이해한 조건을 보여줘. 사용자가 가격만 해제했을 때 유지할 값, 늦은 응답의 처리, 상세에서 돌아왔을 때 복원할 값을 연결해줘. 실패했을 때 문구와 버튼이 무엇인지 적고, 같은 내용을 QA 입력과 기대 결과로 옮겨줘. 아직 합의하지 않은 구현값은 확인 항목으로 남겨줘.”
출처와 실제 기록
2026년 9월 24일 12:11~12:16 KST에 같은 한국어 질문을 각 서비스 새 대화에 한 번씩 제출하고 응답 복사 기능으로 원문을 보존했어. ChatGPT Free·Think 끔·세부 모델 미표시, Gemini Flash·요금제 미확인, Claude Free·Sonnet 5 중간. 답변 길이 제한·재생성·후속 실행 없이 기존 계정 설정으로 수집했어. 질문 전 가상 입력과 여덟 기준을 고정하고 세 원문의 24항목을 대조했어. 글의 후속 지시와 인계문은 위키렙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 파라미터 방식이며, 스크롤 위치 복원은 이번 범위에 넣을지 별도 확인이 필요합니다.
운영팀에는 "자동 해제는 사용자 선택권 문제로 제외하고, 선택형 해제와 인기 상품 별도 노출로 같은 목적을 달성한다"고 전달하면 됩니다. 다음 단계로 운영팀 전달용 요약이나 개발 티켓 문안 중 어느 쪽을 먼저 정리할까요?