88c11682b1
- route table: extension route for products with an existing visual language, feedback row, derived state tokens stay local - completion: blocking 0 plus reported unverified; hard-gate surface is the touched scope; delivery report starts with what and how to open - design.md created at step 0 with a skeleton, fingerprint line and change log; product-surface rubric reading; direction delegation states the chosen card and reason - layout: hero families, nav forms, footer forms; art-direction page convergence 6 axes; genre sections; image treatments; placeholder conventions; multi-screen order; Tailwind theme mapping - platform: scroll-driven examples, anchor positioning, canvas OT, three/R3F pins, shadcn style prefixes, Safari 26 notes, subgrid - design-gate: four result states, exit codes, cwd module resolution, --url/--out-dir/--strict, oklch contrast, dead selector word match - Korean font budget split from the Latin baseline
155 lines
14 KiB
Markdown
155 lines
14 KiB
Markdown
# feedback-loop — "별로야"를 다루는 법
|
|
|
|
사용자가 결과물을 보고 평가를 말할 때 연다. "별로야", "뭔가 싸 보여", "우리 느낌이 아냐"처럼 모호한 불만, "이건 좋다"처럼 짧은 칭찬, 같은 지적의 반복이 여기 해당한다. 2단계 방향 카드가 전부 기각됐을 때도 이 문서의 좁히기 절차를 쓴다([brief-interview.md §16-5](brief-interview.md)).
|
|
|
|
이 문서가 소유하는 것은 **취향 피드백을 진단하고, 바꾸고, 기록하는 절차**다. 결함 보고("버튼이 잘려요", "모바일에서 겹쳐요")는 취향이 아니라 계측 문제다 — 그쪽은 SKILL.md 핵심 규칙 6과 [audit-gate-rules.md](audit-gate-rules.md)의 게이트 규칙(G1~G36, 스크린샷을 픽셀 판정으로 해부)을 따른다. 한 발화에 둘이 섞여 있으면 결함부터 고치고, 취향은 이 문서로 다룬다.
|
|
|
|
## 이 문서를 읽는 법
|
|
|
|
| 상황 | 읽을 곳 |
|
|
|---|---|
|
|
| 사용자가 무엇이 싫은지 말하지 않았다 | §2 |
|
|
| 축은 알겠는데 어느 쪽으로 바꿀지 모르겠다 | §3 |
|
|
| 무엇부터 바꿀지 정한다 | §4 |
|
|
| 바꾼 것과 반응을 어디에 어떻게 남기는가 | §5 |
|
|
| "이건 좋다"는 말을 들었다 | §6 |
|
|
| 바꾼 것을 되돌려 달라고 한다("아까 게 낫다") | §5-b |
|
|
| 같은 불만이 또 왔다 | §7 |
|
|
| 같은 결함을 고쳤는데 계속 실패한다 | §8 |
|
|
|
|
---
|
|
|
|
## 1. 원칙
|
|
|
|
1. **짐작으로 고치지 않는다.** "별로야"를 듣고 에이전트가 고른 축을 전부 바꾸면, 맞힐 확률은 꽃집 인터뷰 사례(넷 중 넷 오답)와 다르지 않다. 그리고 사용자가 좋아하던 것까지 같이 사라진다.
|
|
2. **방어하지 않는다.** "의도한 선택입니다"로 답하지 않는다. 근거를 설명하는 것은 좋지만, 취향과 방향의 승인권자는 사용자다. 기술 QA에서는 사용자를 쓰지 않는다(SKILL.md 핵심 규칙 6) — 그러나 취향은 QA가 아니다.
|
|
3. **한 번에 한 축만 바꾼다.** 여러 축을 동시에 바꾸면 무엇이 효과였는지 알 수 없고, 다음 불만을 진단할 근거도 사라진다.
|
|
4. **지적받은 자리만 고치지 않는다.** 섹션 하나를 손볼 때마다 전체 리듬이 무너진 실측 사고가 있다([antipatterns.md](antipatterns.md) §9-c "지적받은 자리만 고치면 전체가 무너진다"). 바꾼 축은 페이지 전체에 같은 규칙으로 적용하고, 토큰으로 바꾼다.
|
|
5. **물었으면 턴을 끝낸다.** 이 문서의 좁히기 질문과 A/B 질문도 인터뷰 게이트 규칙 4를 그대로 따른다. 빈 답·오류·자동 해제는 [harness.md §3](harness.md)대로 처리한다 — 메인 세션에서는 가정으로 진행하지 않는다.
|
|
|
|
---
|
|
|
|
## 2. 모호한 불만을 축으로 좁힌다
|
|
|
|
사용자 발화에 축이 이미 들어 있으면("글씨가 답답해") 이 절을 건너뛰고 §3으로 간다. 축이 없으면 **질문 하나로** 좁힌다. 여러 번 캐묻지 않는다.
|
|
|
|
**방향은 말했는데 축이 없으면**("더 고급스럽게", "더 밝게", "좀 더 젊게") 축 질문을 따로 내지 않는다. 그 방향을 서로 다른 축으로 해석한 변형 둘을 만들어 §3의 A/B로 바로 묻는다 — 예: A는 타이포로(표제 대비를 키우고 굵기를 낮춘다), B는 여백과 색으로(섹션 간격을 넓히고 강조 면적을 줄인다). 선택지에 "둘 다 아님 — 어디가 걸리는지 말하기"를 두면 축 질문을 겸한다. 축 질문과 반대 방향 A/B를 차례로 거치면 세 번째 턴에야 화면이 바뀌고, 그중 한 장("덜 고급")은 처음부터 버릴 시안이다.
|
|
|
|
| 축 | 이런 말이면 후보 | 바꿀 수 있는 레버 |
|
|
|---|---|---|
|
|
| **레이아웃** | "답답해", "평범해", "어디를 봐야 할지 모르겠어" | 히어로 구도, 그리드 비대칭, 섹션 순서, 첫 화면 정보량 |
|
|
| **타이포** | "싸 보여", "촌스러워", "글씨가 안 읽혀" | 표제 서체, 크기 대비, 굵기, 자간·행간, 줄 길이 |
|
|
| **색** | "칙칙해", "너무 튀어", "차가워" | 바탕 명도, 강조 면적, 채도, 온도 |
|
|
| **밀도·여백** | "비어 보여", "빽빽해", "성의 없어 보여" | 섹션 간 여백, 요소 간 간격, 한 화면의 정보량 |
|
|
| **모션** | "정신없어", "밋밋해", "느려" | 등장 방식, 지속 시간, 스크롤 연동 여부 |
|
|
| **카피** | "우리 말투가 아냐", "광고 같아", "딱딱해" | 표제 문장, 문장 길이, 존댓말 수위, 구체성 |
|
|
| **이미지** | "사진이 별로", "AI 같아", "분위기가 안 맞아" | 크롭, 조도, 피사체, 사진 수, 생성물 여부 |
|
|
| **전부** | "다 별로", "처음부터 다시", "방향이 틀렸어" | 축이 아니라 방향 — §7의 방향 복귀로 바로 간다 |
|
|
|
|
**질문 형식**
|
|
|
|
- 질문은 하나다. "어디가 가장 걸리세요? (최대 두 개)"를 다중 선택으로 낸다.
|
|
- 선택지에는 에이전트의 **가설을 추천으로** 맨 앞에 두고, 근거를 한 줄 붙인다(예: "타이포 (추천 — 표제가 본문의 1.4배뿐이라 위계가 약하다)"). 근거 없는 추천은 붙이지 않는다.
|
|
- "어느 화면·섹션이 가장 걸리는지"를 같은 질문의 자유 답 칸에서 받는다.
|
|
- 축이 여덟 개라 대부분의 구조화 도구에서 선택지 한도를 넘는다. 묶는 방법은 [harness.md §2-1](harness.md)을 따른다.
|
|
- 가설을 세울 때는 [critique.md](critique.md) §4의 Direction 판정 기준(D1~D7)과 §2-1 루브릭의 약한 축을 먼저 대어 본다. Direction 기준에 걸리는 불만("다른 데랑 똑같아", "우리 같지 않아")은 축 하나가 아니라 방향 문제일 가능성이 높다 — §7로 간다.
|
|
|
|
**사용자가 "모르겠어, 그냥 별로야"라고 답하면** 다시 묻지 않는다. 에이전트의 가설 축 하나를 골라 §3의 A/B로 바로 보여 준다 — 말로 고르기 어려운 사람도 두 장을 나란히 보면 고를 수 있다.
|
|
|
|
---
|
|
|
|
## 3. A/B로 방향을 확인한다
|
|
|
|
축이 정해지면 **같은 화면을 그 축만 다르게 바꾼 변형 두 개**를 보여 주고 "어느 쪽이 더 가까운가"를 묻는다.
|
|
|
|
- **같은 조건**: 같은 viewport(390·1440 중 문제가 된 쪽, 모르면 둘 다), 같은 카피·자산·상태. 바꾼 축 외에는 아무것도 다르지 않아야 한다.
|
|
- **방향을 모르면 반대인 두 변형**: "더 대담하게 / 더 조용하게", "더 따뜻하게 / 더 차갑게", "더 촘촘하게 / 더 여유 있게". 현재 버전을 기준점으로 함께 보여 줄 수 있다. **방향을 알면 같은 방향의 다른 해석 두 변형**이다(§2). 사용자가 원하지 않는다고 이미 말한 쪽은 만들지 않는다.
|
|
- **차이가 보일 만큼**: 한 단계 이상 움직인다(예: 표제 크기 대비 1.4배 → 2.5배, 바탕 명도 한 단계 이상). 눈으로 구분되지 않는 변형은 사용자를 시험하는 것이다.
|
|
- **되돌릴 수 있게**: 변형은 토큰 값이나 하나의 클래스 토글로 만든다. 브랜치·파일 사본을 늘리지 않고, 고르지 않은 변형은 지운다(값은 §5 기록에 남긴다).
|
|
- **보여 주는 수단**: 브라우저 캡처가 가능하면 두 캡처를 나란히. 캡처할 수 없으면 바뀐 토큰 값의 전후 표와 ASCII 실루엣으로 보여 주고, 렌더를 확인하지 못했다고 말한다(도구는 [harness.md §6](harness.md)).
|
|
- **답**: "A", "B", "그 중간", "둘 다 아님". "둘 다 아님"이면 축 가설이 틀린 것이다 — §2로 돌아가 다른 축을 묻는다. 같은 축에서 A/B를 두 번 넘게 반복하지 않는다.
|
|
|
|
---
|
|
|
|
## 4. 싼 레버부터 바꾼다
|
|
|
|
같은 축 안에서도 바꾸는 비용이 다르다. 아래 순서로 싼 쪽부터 시도한다. 싼 레버로 해결되면 구조를 건드리지 않는다.
|
|
|
|
```
|
|
카피 → 크롭·스케일 → 서체 → 색 → 밀도·간격 → 구조(레이아웃 패밀리·섹션 순서)
|
|
```
|
|
|
|
구조를 바꿔야 한다는 판단이 서면 그것은 국소 수정이 아니라 방향 문제일 수 있다 — §7을 먼저 본다. 바꾼 결과는 SKILL.md 5단계의 하드 게이트를 다시 통과해야 한다. 취향 수정이 대비·포커스·넘침을 깨뜨리면 그 수정은 채택하지 않는다.
|
|
|
|
---
|
|
|
|
## 5. 변경 기록
|
|
|
|
피드백마다 `design.md`의 "피드백 기록" 절에 한 행을 남긴다. 기록이 없으면 같은 불만이 몇 번째인지(§7) 셀 수 없고, 다음 사람이 이미 기각된 방향으로 되돌린다.
|
|
|
|
```markdown
|
|
## 피드백 기록
|
|
| 날짜 | 불만 원문 | 진단 축 | 가설 | 바꾼 레버(전 → 후) | 사용자 반응 | 보존 목록 영향 |
|
|
|---|---|---|---|---|---|---|
|
|
| 2026-10-02 | "뭔가 싸 보여" | 타이포 | 표제·본문 크기 대비가 약하다 | --step-6 2.0rem → 3.5rem | "B가 낫다" | 없음 |
|
|
```
|
|
|
|
- 불만은 **사용자 원문 그대로** 적는다. 에이전트의 해석은 "가설" 칸에 따로 둔다.
|
|
- 사용자 반응이 아직 없으면 "대기"로 두고, 다음 턴에 채운다.
|
|
- 국소 경로에서 `design.md`가 없으면 이 표를 최종 응답에 남기고, `design.md` 생성은 제안만 한다.
|
|
|
|
---
|
|
|
|
## 5-b. "아까 게 낫다" — 되돌리기
|
|
|
|
1. **고치기 전에 돌아올 지점을 남긴다.** 피드백 수정을 시작할 때 현재 상태의 1440·390 캡처를 남기고, 바꾸는 값의 이전 값을 §5 기록에 적는다. 구조를 바꾸는 수정이면 사용자의 저장소 관행 안에서 돌아올 수 있게 한다 — 커밋되지 않은 변경이 있으면 그렇다고 말하고, 커밋을 대신 만들지는 않는다.
|
|
2. **가리키는 것이 하나면 묻지 않고 되돌린다.** 직전 수정이 하나뿐이면 "아까 게"는 그 수정 전이다. 되돌리고 캡처로 확인시킨다. 여기서 좁히기 질문을 다시 내지 않는다 — 사용자는 이미 답을 말했다.
|
|
3. **가리킬 수 있는 것이 둘 이상이면**(수정 전 원본, 고르지 않은 변형, 그 전 버전) 캡처나 이름으로 나열해 하나를 고르게 한다. 질문은 하나다.
|
|
4. **되돌린 것은 정보다.** §5 기록의 사용자 반응 칸에 "되돌림"을 적고, 되돌아간 상태의 그 속성을 §6 보존 목록에 올린다(요소 + 속성 + 값). 같은 축을 다시 바꾸자는 제안을 먼저 꺼내지 않는다.
|
|
5. **3회 계수.** 되돌림은 그 축의 불만 한 번으로 센다. 원래 불만("더 고급스럽게")은 아직 풀리지 않았으므로, 되돌린 뒤 "그 축은 그대로 두고 다른 축으로 해 볼까요"를 §2의 방식으로 한 번 묻는다.
|
|
|
|
---
|
|
|
|
## 6. 좋다는 반응에서 보존 목록을 만든다
|
|
|
|
"히어로는 마음에 들어", "이 색 좋다"는 다음 수정에서 지켜야 할 계약이다. 칭찬을 흘려들으면 다음 불만을 고치다가 사용자가 좋아하던 것을 지운다.
|
|
|
|
1. `design.md`의 "보존 목록"에 **요소 + 속성 + 값**으로 적는다(예: "히어로 사진 크롭 — 인물 눈높이 상단 1/3, `object-position: 50% 30%`"). "히어로가 좋다"처럼 뭉뚱그려 적지 않는다.
|
|
2. 칭찬이 모호하고("좋네요") 곧 그 근처를 바꿔야 한다면, 무엇이 좋은지 한 번만 확인한다. 바꿀 계획이 없으면 묻지 않는다.
|
|
3. 이후 모든 수정 전에 보존 목록과 대조한다. 보존 항목을 건드려야만 해결되는 수정이면, 바꾸기 전에 그렇다고 말하고 확인받는다.
|
|
4. 보존 목록은 방향 복귀(§7) 때 새 방향 카드의 경계 조건이 된다.
|
|
|
|
---
|
|
|
|
## 7. 같은 불만 3회 → 방향 단계로 돌아간다
|
|
|
|
같은 축의 불만(§5 기록의 "진단 축"이 같거나, 원문이 같은 뜻)이 **세 번째로** 오면 국소 수정을 멈춘다. 레버를 계속 바꾸는 것은 방향이 틀렸다는 신호를 무시하는 것이다.
|
|
|
|
1. 멈췄다고 말한다: "같은 지적이 세 번째입니다. 부분 수정으로는 해결되지 않는 것 같아 방향부터 다시 보겠습니다."
|
|
2. SKILL.md 2단계로 돌아가 [brief-interview.md §16](brief-interview.md)의 방향 체크포인트를 다시 돈다. 새 카드는 피드백 기록의 기각 이유와 §6 보존 목록을 경계 조건으로 삼는다.
|
|
3. 불만의 축이 톤 자체라면 0단계 톤·취향 앵커를 다시 확인한다.
|
|
4. 연장·국소 경로에서 이 규칙에 걸리면 사용자에게 확인받고 전체(리디자인)로 올린다.
|
|
|
|
축이 "전부"인 불만은 첫 번째부터 이 절로 온다.
|
|
|
|
---
|
|
|
|
## 8. 재작업 상한 — 같은 결함을 세 번 고쳐도 실패하면 멈춘다
|
|
|
|
취향이 아니라 결함(넘침·겹침·대비·상태 오류 등)을 고치는 루프에도 상한이 있다. 상한이 없으면 고칠 수 없는 원인(서드파티 임베드, 하네스가 못 하는 실기기 검증) 앞에서 수정 → 재검사를 끝없이 반복하거나, 반대로 미검증을 통과로 읽고 완료를 선언한다.
|
|
|
|
- **같은 결함에 수정 → 재검사가 3회 실패하면** 더 고치지 않는다. 사용자에게 아래를 보고하고 멈춘다.
|
|
- 결함과 재현 조건(viewport·상태)
|
|
- 원인 가설
|
|
- 시도한 수정 3개와 각각의 결과
|
|
- 남은 위험과, 사용자가 정해야 할 것(예: "이 지도 임베드를 빼거나 다른 제공자로 바꿀지")
|
|
- **고칠 수 없는 외부 원인**(서드파티 코드, 하네스 능력 부족)은 시도 횟수를 기다리지 않고 "미검증/외부"로 분리해 보고한다. 하드 게이트 통과로 세지 않는다.
|
|
- 5단계 자동 감사 루프의 상한과 보고 형식은 [audit-gate.md](audit-gate.md)가 정한다. 두 상한이 다르게 읽히면 audit-gate.md를 따른다.
|
|
|
|
---
|
|
|
|
## 9. 위임과 비대화형
|
|
|
|
- **"알아서 고쳐"**: 축 질문을 생략한다. 가설 축 하나를 골라 §4의 싼 레버부터 한 축만 바꾸고, 전후 캡처(또는 전후 값)와 고른 이유를 보여 준 뒤 §5에 기록한다. 위임은 이번 피드백 한 건에 대한 것이다 — 다음 불만에서는 다시 좁힌다.
|
|
- **서브에이전트**: 피드백 좁히기 질문을 직접 할 수 없다. 진단 가설과 질문을 호출자에게 반환하고 멈춘다.
|
|
- **비대화형 실행**: 질문과 A/B 설명을 최종 응답에 남기고 파일을 바꾸지 않은 채 끝낸다.
|