고객 진단 스펙

<!-- 고객 진단 스펙 v0.1 · https://namtank96.github.io/assets/a02-diagnosis -->

# 고객 진단 스펙

고객의 페인·현황·요구를 **원문과 해석을 분리한 채** 축적하는 포맷.
선제안·컨설팅 초기처럼 정보가 부족한 상태에서 시작해, 미팅을 거치며 채워 나가는 것을 전제로 한다.

## 0. 담는 것 / 담지 않는 것

- 담는다: 고객이 실제로 한 말, 그 말에 대한 우리 해석과 근거, 해석이 바뀐 궤적, 확인해야 할 질문.
- 담지 않는다: 최종 제안서 문장, 화면 설계, 견적 로직. 전부 이 문서에서 **파생**되는 산출물이고, 여기 저장하지 않는다.

## 1. 최소 입력 = 페인 1건

나머지는 전부 선택이다. 못 채워서 시작을 못 하는 것보다, 얕게라도 시작해 미팅에서 채우는 게 낫다.
빈 곳은 삭제하지 말고 **가정 배지**를 붙여 남긴다. 무엇을 모르는지가 곧 다음 미팅의 질문지다.

| 항목 | 최소 입력 시 |
|---|---|
| `pain` | **필수 (1건 이상).** 페인이 없으면 이후 모든 산출물의 근거가 없다 |
| `need` | 권장. pain에서 도출 가능 |
| `goal` | 권장. 없으면 "pain 해소"로 가정 |
| `currentData` / `currentSystem` | 선택. 있으면 정밀해짐 |
| `cost` | 선택 |
| `gap` | **입력하지 않는다.** 계산되는 것이다 (§4) |

## 2. 구조

```yaml
meta:
  id: dg-001
  customer: "{고객}"          # 익명 표기 가능. 업종·규모만으로도 충분할 때가 많다
  stage: 선제안 | 제안 | 수행
  updated: YYYY-MM-DD

context:
  trigger: "왜 지금 이 논의가 시작됐는가"
  constraints: ["예산 주기", "기존 시스템 제약", "조직 제약"]

actors:                        # 누구의 일인가
  - id: ac-01
    label: "{역할}"            # 실명 금지. 역할로 적는다
    raw: "고객 원문에 근거가 있을 때만 채운다"
    responsibility: "이 사람이 실제로 하는 일"
    authority: ["이 사람이 확정할 수 있는 결정"]
    confidence: 낮음 | 중간 | 높음

items:                         # 본체. 각 항목이 하나의 추론 궤적
  - id: it-01
    type: pain | need | goal | currentData | currentSystem | cost | other
    actorRef: ac-01
    raw: "고객이 실제로 한 말. 두루뭉술해도 그대로."
    interpretations:
      - at: YYYY-MM-DD
        text: "우리 해석"
        basis: "웹서칭 | 업종패턴 | 미팅발언 | 자료"
        confidence: 낮음 | 중간 | 높음
        status: 현행 | 후보 | 폐기
        retiredReason: "폐기일 때만. 왜 틀렸는지."
    verify:
      method: 미팅질문 | 자료요청 | 데모반응
      question: "확인할 질문 한 문장"
      resolved: false
    customerFacing: false      # 표출층 노출 여부 (§5)

benchmarks:
  - id: bm-01
    type: target | competitive # 기본 target. 확실한 정보가 있을 때만 competitive
    raw: "확인된 사실만"
    source: "출처"
    confidence: 낮음 | 중간 | 높음
```

## 3. 작성 규칙

1. **원문을 다듬지 않는다.** `raw`는 고객이 말한 그대로 적는다. 요약하는 순간 나중에 근거로 쓸 수 없다.
2. **원문과 해석을 같은 칸에 넣지 않는다.** 섞이면 어디까지가 사실이고 어디부터가 추측인지 두 달 뒤에 아무도 구분 못 한다.
3. **해석에는 반드시 `basis`와 `confidence`를 단다.** 근거가 없으면 confidence는 자동으로 `낮음`이고, `verify.question`을 함께 채운다.
4. **`현행` 해석은 항목당 1개.** 대안은 `후보`로 병렬 보관한다.
5. **`폐기`를 삭제하지 않는다.** `retiredReason`과 함께 남긴다. 틀린 궤적이 다음 건의 재료다.
6. **행위자가 다르면 같은 항목으로 묶지 않는다.** 대상이 같아도 쓰는 사람이 다르면 다른 건이다. 이걸 안 지키면 뒤에서 화면 하나에 두 사람의 요구가 뭉개진다.
7. **`authority`에 없는 권한을 산출물에 만들지 않는다.** 확정 권한이 확인되지 않은 역할에 승인 버튼을 그리지 않는다.
8. **`actors.raw`는 근거가 있을 때만 채운다.** 없으면 비우고 가정 배지. 우리가 상상한 조직도를 그리지 않는다.
9. **`actors`는 해석 궤적을 타지 않는다.** 페인은 좁혀가는 것이지만 행위자는 식별되는 것이다. `confidence` 한 축만 둔다.
10. **벤치마크는 기본 `target`.** 초기에는 경쟁 정보가 부실하므로 "이런 방향이 좋다" 수준으로 방어적으로 둔다. 확정 정보가 생겼을 때만 `competitive`로 승격한다.
11. **추적성 없는 결론을 만들지 않는다.** 모든 파생 산출물은 어느 `items[].id`에서 나왔는지 달고 나간다. 달 수 없으면 그 결론은 만들지 않는다.
12. **미기재는 질의 대상으로 넘긴다.** 고객이 말하지 않은 것을 없는 것으로 처리하지 않는다.
13. **모르는 것을 적는 칸을 비워두지 않는다.** `verify.question`이 비어 있으면 그 항목은 아직 진단이 아니다.
14. **도메인 용어를 골격에 하드코딩하지 않는다.** 업종 어휘는 `{도메인}` 자리에 태그로 얹고, 골격은 중립으로 둔다.
15. **규격과 산출물이 어긋나면 규격을 먼저 고친다.** 산출물 쪽에서 우회하면 다음 건에서 같은 문제가 다시 난다.

## 4. 갭은 저장하지 않고 계산한다

갭은 필드가 아니라 **파생 뷰**다.

```
gap = {
  requirement: "산출물이 요구하는 데이터·기능·기준",
  current:     현황 항목의 현행 해석,
  target:      요구 항목의 현행 해석,
  delta:       자동 생성 문구 — 검토 전까지 draft,
  approved:    false        # 승인 전까지 표출층 노출 금지
}
```

- **갭은 요구 관계로 잡는다.** "같은 대상의 현재 vs 목표"로 맞추려 하면 자료 명사와 업무 명사의 층위가 달라 짝이 안 맞는다. "산출물이 요구하는 것 ↔ 현재가 제공하는 것"으로 대조한다.
- **`current`가 아예 없으면 가정 배지로 둔다.** 있는데 요구에 못 미칠 때만 갭이다. 미확인이 확인되는 순간 배지가 갭으로 승격한다.
- 도출은 자동, **표출은 승인 후.**

## 5. 내부층 / 표출층

고객에게 나가는 것은 다음을 **모두** 만족하는 항목뿐이다.

- `raw`에 실제 근거가 있고
- `customerFacing: true`이고
- 현행 해석이 있고
- 갭이라면 `approved: true`

나머지는 전부 내부 전용이다. 확신도 `낮음`인 해석을 고객 문서에 넣지 않는다.

> 내부층/표출층은 **산출물을 누가 보느냐**(우리 팀 vs 고객)이고, `actors`는 **만들 시스템을 누가 쓰느냐**다. 섞지 않는다.

## 6. 최소 예시 (페인 1건으로 시작)

```yaml
meta: { id: dg-001, customer: "{도메인} 중견기업", stage: 선제안, updated: 2026-08-10 }
context: { trigger: "현장 점검 이력 관리가 수기라 월말 집계에 며칠 걸린다는 언급" }
actors: []                       # 미확인 → 가정 배지 '행위자 미확인'
items:
  - id: it-01
    type: pain
    raw: "점검 결과가 여기저기 흩어져 있어서 매번 취합하느라 시간을 씁니다"
    interpretations:
      - at: 2026-08-10
        text: "부서별 수기 취합 → 집계 자동화가 1차 니즈"
        basis: 초도미팅 발언
        confidence: 중간
        status: 현행
    verify: { method: 미팅질문, question: "취합은 어느 주기로, 누가 하시나요?", resolved: false }
    customerFacing: true
```

이 상태로도 진단은 성립한다. `actors`는 비어 있어 가정 배지가 붙었고, `verify.question`은 다음 미팅에서 물을 것이다.