fork

Overview

선호는 진술되지 않는다. 드러난다.

사용자는 오더를 던지는 시점에 판단 기준이 없을 수 있다. 기준은 결과물을 보고 나서야 생긴다. 그러니 기준을 묻지 마라. 반응하게 하라. 갈라지는 길을 먼저 보여주고, "이건 아니다 / 이건 괜찮다"에서 기준을 역추출한다.

이 스킬의 산출물은 결과물이 아니라 기준 한 줄이다.

발동 판단 — 4문항, 순서 강제

하나라도 실패하면 발동하지 않는다. 순서를 지켜라 — 뒤 문항을 먼저 보면 판정이 사후 합리화로 변한다.

1. 두 결과물 지목 — 오더의 문장을 전부 지키면서 서로 다른 결과물 2개를, 지금 이 자리에서 구체적으로 적어낼 수 있는가? 적어내라. 실존 레퍼런스나 구체적 형태로. 하나만 적히면 발동하지 않는다.

2. 거부 가능성 — 그 둘을 사용자에게 내밀면, 하나는 받고 하나는 거부할 것 같은가? 둘 다 받아들일 것 같으면 발동하지 않는다. 아무거나 해도 되는 오더다.

3. 선례 테스트 — 코드베이스 컨벤션·스펙 문서·주어진 소스가 이미 그 선택을 정해두었는가? 정해져 있으면 발동하지 않고 선례를 따른다. 확정된 것을 후보로 되돌리는 건 무르기다.

일관된 부재도 선례다. 기존 문서 6개 전부에 에러 코드 섹션이 없으면, 그 부재가 결정이다. "아무도 안 건드린 빈칸"으로 읽지 않는다. 단 표본이 하나뿐이면 선례가 아니다 — 우연과 구분이 안 된다.

4. 측정 테스트 — 재보면 답이 나오는 오더인가? ("이 쿼리 느린데 빠르게" → 병목을 재면 정답이 하나다) 재서 답이 나오면 발동하지 않는다. 재고 나서도 트레이드오프가 남으면 그때 발동한다.

축 이름은 판정이 끝난 뒤 1번에서 지목한 두 결과물의 차이에서 뽑는다. 짧은 명사구면 된다(정보밀도 · 격식 · 추상화 수준 · 조사 범위). 축을 먼저 짓지 않는다.

문항 1의 통과는 문항 3까지 가서야 확정된다. 선례를 모른 채 적은 두 결과물 중 하나는, 선례를 보면 애초에 성립하지 않는 선택지일 수 있다. 1번에서 둘이 적혔다고 발동이 정해진 게 아니다.

오더 하나에 축이 여러 개면, 축마다 따로 판정한다

4문항은 오더 전체가 아니라 축 하나에 대한 판정이다. 오더 하나가 여러 축을 동시에 열어두는 일이 흔하다.

"우리 팀 온보딩 문서 써줘. 대충 좋게." — 기존 docs/에 같은 보이스의 문서 3개가 있다

• 톤·구성 축 → 문항 3 실패. 선례가 정했다. 갈래 없음
• 내용 범위 축 → 기존 문서가 정한 건 보이스와 헤딩 깊이지 포괄 범위가 아니다. 발동 또는 사실 공백

한 축이 선례로 닫혔다고 오더 전체가 닫힌 게 아니다. 열린 축이 남았는지 한 번 더 본다. 반대로 축 하나가 열렸다고 모든 축에 갈래를 내지 않는다 — 열린 축만.

축이 셋 이상 열리면 갈래를 세 벌 내지 말고 가장 비싼 축 하나만 고른다. 비싼 축은 이렇게 찾는다.

의존 테스트 — 다른 축의 선택이 이 축에 의존하는가? 의존받는 축이 비싸다. 비주얼 스타일이 정해지면 정보 밀도와 톤은 그 안에서 결정되지만, 역방향은 성립하지 않는다. 먼저 고정되어야 하는 것이 먼저다.

의존 관계가 안 보이면 버려지는 작업량 순서로 간다 — 형태·구조 > 내용 배치 > 문구. 구조가 틀리면 전부 다시 만들고, 문구가 틀리면 단어만 고친다.

보류한 축은 다음 라운드로 미루지 않는다. 이 스킬은 1라운드로 끝난다. 보류한 축은 기본값으로 조용히 처리하고, 기준 한 줄에 그 기본값을 적어 드러낸다.

기준 잡혔습니다 → 비주얼은 에디토리얼 빅타이포. 밀도는 슬라이드당 메시지 하나, 톤은 기존 문서체로 갑니다.

사용자가 그 줄을 보고 걸면 그때 다룬다. 갈래를 두 번 내밀면 이 스킬이 관문이 된다.

아래 표는 판정자가 아니다

감각을 맞추는 참고물이다. 표를 먼저 보고 칸을 정한 뒤 4문항을 끼워 맞추면 판정한 게 아니다.

경계가 애매하면 1번 문항으로 돌아가라. 두 결과물이 적히면 발동, 안 적히면 발동 안 함.

갈래로 메우지 않는 것 — 사실 공백

갈래는 취향 공백만 메운다. 사실 공백은 그냥 묻는다.

산출물 종류가 안 잡히면 축도 못 잡는다. "벤치마킹해줘"는 조사일 수도 제작일 수도 있고, 둘의 축은 완전히 다르다(조사 범위 vs 표현 강도). 먼저 확정하라.

사실 질문은 막힌 것만, 최대 2개. 질문 4개를 나열하는 순간 이 스킬이 없을 때와 같아진다.

사실 질문과 갈래는 별개 예산이다. 한 응답에 사실 질문 최대 2개 + 갈래 1축이 정상 형태다. 예산이 아깝다고 사실 질문을 갈래 설명 안에 숨기지 않는다 — 숨기면 내가 답을 추측해 넣은 채로 사용자가 고르게 된다.

사실 공백 확인은 한 번 지나가는 관문이 아니다. 갈래는 제품을 몰라도 글로 쓸 수 있지만 실물은 못 만든다 — 제품명·카피·브랜딩이 없으면 목업이 허구로 채워진다. 실물로 올리기 직전에 다시 본다. 사실 공백을 실물로 때우지 않는다.

갈래 뽑는 규칙

이 스킬이 망하는 길은 하나다 — 갈래가 다 비슷해서 "다 비슷한데"로 끝나는 것.

1. 직교성 — 각 갈래는 서로 다른 것을 희생한다.

갈래 두 개의 이름표를 맞바꿔도 사용자가 눈치채지 못하면, 그건 같은 갈래다. 버리고 다시 뽑아라.

2. 형용사 금지, 실존 레퍼런스 강제.

❌  [2] 과감하고 개성 있는 스타일
✅  [2] Arc, Framer 계통 — 큰 타이포, 과감한 색, 스크롤 액션

"과감한"은 사람마다 다른 걸 떠올린다. Arc는 안 갈린다. 디자인 밖도 같다 — 문서면 "a16z 메모 톤", 구조면 "Rails식 컨벤션 우선".

3. 각 갈래에 대가 한 줄 필수.

→ 안전하지만 다들 이런다
→ 기억에 남지만 호불호 갈린다

장점만 나열하면 고를 수 없다. 무엇을 잃는지가 적혀 있어야 반응이 나온다.

4. 갈래당 34줄, 총 24개. 기본 3개. 길면 안 읽는다.

5. 억지 갈래 금지. 발동 4문항을 통과하지 못했으면 갈래를 만들지 말고 그냥 작업한다. 침묵이 정답이다.

6. 글이 먼저, 실물은 나중. 기본은 글이다. 반응이 안 나올 때만 실물로 올린다 — 조건과 규격은 아래.

제시 형식은 examples.md 참조.

실물 승격 규격 (규칙 6)

"실물로 짧게"는 이렇게 읽는다.

ASCII 스케치는 실물이 아니다 — 글의 연장이라 이미 실패한 자리를 반복한다.

흐름

오더 수신
  ↓
사실 공백 있나 ── 있음 ──→ 막힌 것만 묻는다 (최대 2개)
  ↓ 없음
발동 4문항 ─── 하나라도 실패 ──→ 그냥 작업 (침묵)
  ↓ 통과
축 이름 뽑기 → 갈래 2~4개 제시 (규칙 1~4)
  ↓
반응 수신
  ↓
기준 한 줄 확정 → 출력 → 작업

기준 확정 한 줄

기준 잡혔습니다 → 레이아웃은 과감, 색은 절제. 이걸로 진행합니다.

두 역할을 한다. 사용자에겐 "아 내가 이걸 원했구나"를 눈으로 확인시키고, 나에게는 이후 작업 내내 붙들 문장이 된다 — 말 안 한 결정을 내릴 때마다 이 문장에 비춰본다.

사용자가 주지 않은 기준을 이 줄에 쓰지 않는다. 기준이 안 잡혔으면 안 잡혔다고 쓴다.

예외 경로

"다 아니다" 1회의 함정 — 기존 갈래 중 하나가 이미 정보밀집형이었다면 새 축을 정보밀도로 잡아선 안 된다. 그건 갈래 하나를 축으로 승격시킨 것이고, 사용자는 이미 거부한 것을 다시 본다.

이름표만 피하는 것으로는 부족하다. 새 갈래가 거부된 갈래의 레퍼런스를 다시 쓰고 있으면 겹친 것이다. 재제시 전에 레퍼런스 목록을 대조한다.

2회 실패 시 열린 질문으로 돌아가지 않는다 — "그럼 어떤 스타일을 원하세요?"는 금지다. 질문은 안 통하는 것으로 확인됐다. 닫힌 확인 질문 하나는 허용된다:

지금까지 6개를 거부하셨습니다. 공통점은 — 전부 여백이 넓고 요소 수가 적습니다. 거부 기준이 "허전함"인 것 같은데, 맞습니까?

거부 데이터도 반응 데이터다. 선택만 신호인 게 아니다.

확인 질문 다음 — 여기서 갈래는 끝난다

접은 뒤 — 사후 대조로 내려간다

사전 제시가 실패했으면 기준은 결과물에서 뽑는다. 절차는 정해져 있다.

마지막 줄이 최종 경로다. 오더에 없어서 내가 정한 것들을 이렇게 드러낸다:

오더에 없어서 제가 임의로 정한 것들입니다. 어긋난 걸 골라주세요. 1 벤치마크 대상을 SaaS 5개로 잡음 → 커머스·핀테크도 봐야 했나? 2 "벤치마킹"을 나열로 해석 → 항목별 점수를 매기는 것이었나? 3 결과를 표로 정리 → 스크린샷 비교가 필요했나?

여기서는 기준이 반드시 나온다. 선택지가 추상적 방향이 아니라 이미 내려진 결정이고, 사용자는 눈앞의 결과물을 보며 고르기 때문이다.

Red Flags — 보이면 STOP

Common Mistakes

• 갈래를 다 구현해보고 제시 → 비용이 목적을 배신한다. 글이 먼저
• 기준 한 줄을 출력하지 않고 바로 작업 → 사용자가 확인할 게 없고, 나도 붙들 문장이 없다
• 취향을 파일로 누적 → 하지 않는다. 맥락이 달라지면 과거 기준이 방해한다
• 갈래 5개 이상 제시 → 안 읽는다. 2~4개
• 같은 축의 값만 바꿔 재제시 → 축이 틀렸는데 값을 바꿔도 같은 거부가 온다
• 사실 공백을 갈래로 때움 → 무슨 제품인지 모르는 채 스타일 갈래를 내면 갈래가 공중에 뜬다
• 실물 승격 때 공들여 만듦 → 버릴 물건이다. 대비가 보이는 최소치
• 취향을 질문으로 캐물음 → 사용자에게 답이 없는 질문이다. 갈래가 질문을 대체한다

검증 기록: tests/tdd-record.md