designpaca/packages/skill/references/feedback-loop.md

feedback-loop — "별로야"를 다루는 법

사용자가 결과물을 보고 평가를 말할 때 연다. "별로야", "뭔가 싸 보여", "우리 느낌이 아냐"처럼 모호한 불만, "이건 좋다"처럼 짧은 칭찬, 같은 지적의 반복이 여기 해당한다. 2단계 방향 카드가 전부 기각됐을 때도 이 문서의 좁히기 절차를 쓴다(brief-interview.md §16-5).

이 문서가 소유하는 것은 취향 피드백을 진단하고, 바꾸고, 기록하는 절차다. 결함 보고("버튼이 잘려요", "모바일에서 겹쳐요")는 취향이 아니라 계측 문제다 — 그쪽은 SKILL.md 핵심 규칙 6과 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 §9-c "지적받은 자리만 고치면 전체가 무너진다"). 바꾼 축은 페이지 전체에 같은 규칙으로 적용하고, 토큰으로 바꾼다.
5. 물었으면 턴을 끝낸다. 이 문서의 좁히기 질문과 A/B 질문도 인터뷰 게이트 규칙 4를 그대로 따른다. 빈 답·오류·자동 해제는 harness.md §3대로 처리한다 — 메인 세션에서는 가정으로 진행하지 않는다.

---

2. 모호한 불만을 축으로 좁힌다

사용자 발화에 축이 이미 들어 있으면("글씨가 답답해") 이 절을 건너뛰고 §3으로 간다. 축이 없으면 질문 하나로 좁힌다. 여러 번 캐묻지 않는다.

방향은 말했는데 축이 없으면("더 고급스럽게", "더 밝게", "좀 더 젊게") 축 질문을 따로 내지 않는다. 그 방향을 서로 다른 축으로 해석한 변형 둘을 만들어 §3의 A/B로 바로 묻는다 — 예: A는 타이포로(표제 대비를 키우고 굵기를 낮춘다), B는 여백과 색으로(섹션 간격을 넓히고 강조 면적을 줄인다). 선택지에 "둘 다 아님 — 어디가 걸리는지 말하기"를 두면 축 질문을 겸한다. 축 질문과 반대 방향 A/B를 차례로 거치면 세 번째 턴에야 화면이 바뀌고, 그중 한 장("덜 고급")은 처음부터 버릴 시안이다.

축	이런 말이면 후보	바꿀 수 있는 레버
레이아웃	"답답해", "평범해", "어디를 봐야 할지 모르겠어"	히어로 구도, 그리드 비대칭, 섹션 순서, 첫 화면 정보량
타이포	"싸 보여", "촌스러워", "글씨가 안 읽혀"	표제 서체, 크기 대비, 굵기, 자간·행간, 줄 길이
색	"칙칙해", "너무 튀어", "차가워"	바탕 명도, 강조 면적, 채도, 온도
밀도·여백	"비어 보여", "빽빽해", "성의 없어 보여"	섹션 간 여백, 요소 간 간격, 한 화면의 정보량
모션	"정신없어", "밋밋해", "느려"	등장 방식, 지속 시간, 스크롤 연동 여부
카피	"우리 말투가 아냐", "광고 같아", "딱딱해"	표제 문장, 문장 길이, 존댓말 수위, 구체성
이미지	"사진이 별로", "AI 같아", "분위기가 안 맞아"	크롭, 조도, 피사체, 사진 수, 생성물 여부
전부	"다 별로", "처음부터 다시", "방향이 틀렸어"	축이 아니라 방향 — §7의 방향 복귀로 바로 간다

질문 형식

• 질문은 하나다. "어디가 가장 걸리세요? (최대 두 개)"를 다중 선택으로 낸다.
• 선택지에는 에이전트의 가설을 추천으로 맨 앞에 두고, 근거를 한 줄 붙인다(예: "타이포 (추천 — 표제가 본문의 1.4배뿐이라 위계가 약하다)"). 근거 없는 추천은 붙이지 않는다.
• "어느 화면·섹션이 가장 걸리는지"를 같은 질문의 자유 답 칸에서 받는다.
• 축이 여덟 개라 대부분의 구조화 도구에서 선택지 한도를 넘는다. 묶는 방법은 harness.md §2-1을 따른다.
• 가설을 세울 때는 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).
• 답: "A", "B", "그 중간", "둘 다 아님". "둘 다 아님"이면 축 가설이 틀린 것이다 — §2로 돌아가 다른 축을 묻는다. 같은 축에서 A/B를 두 번 넘게 반복하지 않는다.

---

4. 싼 레버부터 바꾼다

같은 축 안에서도 바꾸는 비용이 다르다. 아래 순서로 싼 쪽부터 시도한다. 싼 레버로 해결되면 구조를 건드리지 않는다.

카피 → 크롭·스케일 → 서체 → 색 → 밀도·간격 → 구조(레이아웃 패밀리·섹션 순서)

구조를 바꿔야 한다는 판단이 서면 그것은 국소 수정이 아니라 방향 문제일 수 있다 — §7을 먼저 본다. 바꾼 결과는 SKILL.md 5단계의 하드 게이트를 다시 통과해야 한다. 취향 수정이 대비·포커스·넘침을 깨뜨리면 그 수정은 채택하지 않는다.

---

5. 변경 기록

피드백마다 design.md의 "피드백 기록" 절에 한 행을 남긴다. 기록이 없으면 같은 불만이 몇 번째인지(§7) 셀 수 없고, 다음 사람이 이미 기각된 방향으로 되돌린다.

## 피드백 기록
| 날짜 | 불만 원문 | 진단 축 | 가설 | 바꾼 레버(전 → 후) | 사용자 반응 | 보존 목록 영향 |
|---|---|---|---|---|---|---|
| 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의 방향 체크포인트를 다시 돈다. 새 카드는 피드백 기록의 기각 이유와 §6 보존 목록을 경계 조건으로 삼는다.
3. 불만의 축이 톤 자체라면 0단계 톤·취향 앵커를 다시 확인한다.
4. 연장·국소 경로에서 이 규칙에 걸리면 사용자에게 확인받고 전체(리디자인)로 올린다.

축이 "전부"인 불만은 첫 번째부터 이 절로 온다.

---

8. 재작업 상한 — 같은 결함을 세 번 고쳐도 실패하면 멈춘다

취향이 아니라 결함(넘침·겹침·대비·상태 오류 등)을 고치는 루프에도 상한이 있다. 상한이 없으면 고칠 수 없는 원인(서드파티 임베드, 하네스가 못 하는 실기기 검증) 앞에서 수정 → 재검사를 끝없이 반복하거나, 반대로 미검증을 통과로 읽고 완료를 선언한다.

• 같은 결함에 수정 → 재검사가 3회 실패하면 더 고치지 않는다. 사용자에게 아래를 보고하고 멈춘다.
  • 결함과 재현 조건(viewport·상태)
  • 원인 가설
  • 시도한 수정 3개와 각각의 결과
  • 남은 위험과, 사용자가 정해야 할 것(예: "이 지도 임베드를 빼거나 다른 제공자로 바꿀지")
• 고칠 수 없는 외부 원인(서드파티 코드, 하네스 능력 부족)은 시도 횟수를 기다리지 않고 "미검증/외부"로 분리해 보고한다. 하드 게이트 통과로 세지 않는다.
• 5단계 자동 감사 루프의 상한과 보고 형식은 audit-gate.md가 정한다. 두 상한이 다르게 읽히면 audit-gate.md를 따른다.

---

9. 위임과 비대화형

• "알아서 고쳐": 축 질문을 생략한다. 가설 축 하나를 골라 §4의 싼 레버부터 한 축만 바꾸고, 전후 캡처(또는 전후 값)와 고른 이유를 보여 준 뒤 §5에 기록한다. 위임은 이번 피드백 한 건에 대한 것이다 — 다음 불만에서는 다시 좁힌다.
• 서브에이전트: 피드백 좁히기 질문을 직접 할 수 없다. 진단 가설과 질문을 호출자에게 반환하고 멈춘다.
• 비대화형 실행: 질문과 A/B 설명을 최종 응답에 남기고 파일을 바꾸지 않은 채 끝낸다.