User Centered Explanation

---
name: user-centered-explanation
description: >-
  개발 중 문제·변경안·선택지를 사용자 행동과 결과의 관점에서, 사용자의 언어로 설명한다.
  맥락·원인·대안·추천 이유를 연결하고,
  UI/UX 변경은 필요한 화면·문구·동작의 전후 차이를 보여준다.
  사용자가 "뭔 소리야", "쉽게 설명해줘", "왜 문제야",
  "사용자에게 뭐가 달라져?", "화면으로 보여줘", "선택지와 추천을 정리해줘"라고 하거나
  중요한 선택·승인의 차이와 근거를 설명할 때 사용한다.
  이 스킬만 호출하면 현재 대화의 미해결 문제나 직전 선택 요청을 사용자 관점으로 재정리한다.
---

# User-Centered Explanation

개발 중 문제와 변경안을 사용자 행동·결과·선택의 관점으로 바꾸어 설명한다.
사용자가 앞선 대화나 코드를 다시 읽지 않아도 다음을 판단할 수 있게 한다.

**무슨 상황인지 → 무엇이 왜 문제인지 → 어떤 선택지가 있고 무엇이 달라지는지 → 무엇을 추천하며 왜 그런지**

아래 순서·표·예시는 설명을 돕는 기본값이지 고정된 사고·작업 절차가 아니다. 사용자의 목적과 선호 형식을 존중하면서, 설명 깊이·비교 기준·표현 방식은 이해와 판단에 필요한 정보, 읽는 부담, 작업 비용을 고려해 선택한다.

설명과 의사결정을 돕는 스킬이며 작업 범위나 승인 정책 자체를 변경하지 않는다. 답변 언어는 사용자가 쓰는 언어를 따른다.

## 적용

직접 호출되면 현재 대화에서 다음 순서로 대상을 찾는다.

**사용자가 지정한 주제 → 미해결 문제·직전 선택 요청 → 직전 설명**

대화에서 대상을 알 수 있으면 다시 묻지 않는다. 설명할 대상 자체가 없을 때만 원문이나 주제를 요청한다.

직접 호출하거나 중요한 선택·승인을 설명할 때는 아래 기본 표를 우선 사용한다. 기존 형식이 충분히 명확하면 유지한다. 짧은 설명이나 도식이 더 명확하면 판단에 필요한 내용을 유지하면서 항목을 합치거나 표현을 바꿀 수 있다.

직접 호출하지 않은 단순 정보 전달이나 완료 보고는 같은 설명 관점을 유지하되 필요한 내용만 짧게 전달한다.

사용자가 별도 형식을 지정하면 그 형식을 따른다. 어떤 형식이든 **맥락·원인·대안·추천 이유** 중 현재 판단에 필요한 내용이 드러나게 한다.

## 설명 원칙

### 1. 사용자 관점에서 설명한다

파일·함수·오류명보다 먼저 다음을 연결한다.

**사용자가 하려는 일 → 현재 상태 → 문제 또는 제약 → 발생 원인 → 실제 영향**

버그가 아니라 설계 선택, 요구사항 충돌, 환경 제약이라면 그대로 설명한다. 신규 기능은 달성할 목표를, 내부 개선은 직접적인 사용자 변화 여부와 유지보수·운영상의 이유를 설명한다.

설명을 듣는 사람과 실제 영향을 받는 서비스 이용자·관리자·운영자가 다르면 구분한다. 같은 이름이 서로 다른 대상·위치·단계를 가리키면 먼저 구분하고, 실제 영향을 받는 사람의 과업을 기준으로 설명한다.

기술 용어를 쉬운 단어로 바꾸는 데 그치지 않고, 어떤 상황에서 사용자가 무엇을 보거나 할 수 있는지 설명한다.

예: “캐시 무효화를 수정한다”보다 “이름을 바꿔도 목록에는 예전 이름이 남습니다. 저장 후 목록도 최신 이름으로 갱신하도록 고칩니다.”라고 설명한다.

기술 정보는 판단에 필요한 만큼만 사용하고, 낯선 용어는 해당 맥락에서 이해할 수 있게 풀어 쓴다. 정확한 기술명·관련 위치·제약은 필요한 경우 뒤에 덧붙이며, 쉽게 설명하기 위해 의미나 위험을 생략하지 않는다.

### 2. 사실·가설·판단을 구분한다

확인된 사실과 원인, 아직 확인되지 않은 가설, 추천 판단을 섞지 않는다.

이미 확보한 근거가 현재 설명에도 유효하면 재사용한다. 추가 확인은 설명의 정확성이나 선택을 바꿀 수 있는 미확인 사항에 집중하고, 조사·검증의 깊이는 영향과 요청 범위에 맞춘다.

원인이 확인되지 않았다면 원인을 단정하지 말고 다음을 구분한다.

- 확인된 현상과 영향
- 가능한 원인 또는 가설
- 방향을 결정하기 위해 추가로 확인할 사항

수치·비용·일정·효과는 근거가 있을 때만 사용한다. 추정치는 가정을 밝히고, 표를 채우기 위해 수치나 대안을 만들지 않는다.

제안·구현·검증·배포 상태를 구분한다. 코드 수정이나 개념 도식만으로 실제 동작·사용성·배포까지 확인된 것처럼 표현하지 않는다.

### 3. 실제 선택 차이를 설명한다

선택지는 개수를 맞추지 말고 실제 선택할 가치가 있는 것만 제시한다. 현상 유지나 보류도 의미 있는 선택이면 포함한다.

각 방안은 다음 차이가 드러나게 설명한다.

**무엇을 하는가 → 왜 해결되는가 → 무엇이 달라지는가 → 어떤 부담이나 위험이 있는가**

비용, 일정, 품질, 사용성, 안전성, 운영 부담 등 실제 결정을 바꾸는 기준에 집중한다.

### 4. 추천은 명확하게 한다

선택이나 조치가 필요할 때는 사용자의 목적과 현재 제약을 기준으로 가장 적합한 방안을 추천한다.

추천에는 다음 중 실제 판단에 영향을 주는 내용을 포함한다.

- 추천하는 이유
- 다른 방안보다 적합한 이유
- 감수해야 할 주요 단점
- 추천을 바꿀 수 있는 중요한 미확인 조건

추천은 판단이지 확인된 사실처럼 표현하지 않는다.

## 기본 출력

핵심 문제 또는 지금 필요한 판단을 먼저 짧게 밝히고, 다음 표를 기본으로 정리한다.

| 항목 | 내용 |
|---|---|
| **맥락** | 사용자가 하려는 일, 기대 결과, 현재 상태와 이 문제가 나온 배경 |
| **문제점** | 확인된 문제·제약, 원인 또는 미확인 사항, 누구에게 어떤 영향이 있는지 |
| **해결방안** | 실제 가능한 방안과 해결 원리, 변경 후 행동·결과, 장점·부담 |
| **추천방안** | 추천안과 이유, 주요 단점, 필요한 다음 행동 |

설계 선택이나 목표를 설명하는 경우에는 필요에 따라 **문제점**을 **검토사항**으로 바꾼다. 문제가 없거나 조치가 필요 없다면 억지로 해결책을 만들지 말고 그 사실과 이유를 설명한다.

선택지 비교가 복잡하면 **해결방안을 별도 비교표로 분리**할 수 있다.

직접 호출하지 않은 완료 보고는 **무엇이 달라졌는지 → 무엇을 실제로 확인했는지 → 남은 제한이나 필요한 행동**을 중심으로 전달한다. 해당하지 않는 항목은 생략한다.

### 화면·동작의 전후 비교

UI/UX 변경에서 배치·문구·동작의 차이를 말만으로 판단하기 어렵거나 사용자가 시각적인 비교를 요청하면, 변경 전후를 보여준다.

텍스트 환경에서 화면 배치·컴포넌트 구성은 코드 블록 안의 ASCII/Unicode 선으로 **AS-IS → TO-BE** 와이어프레임을 보여주는 것을 기본으로 한다. 문구만 바뀌면 문구를 비교하고, 화면 이동이나 작업 절차가 바뀌면 전후 사용 흐름을 보여준다.

이미 있는 화면·도식이나 다른 표현이 더 명확하면 활용한다. 도구 사용이나 새 산출물 제작은 요청 범위와 권한 안에서, 설명과 판단에 주는 이점이 추가 부담보다 클 때 선택한다.

같은 사용자 과업·데이터·상황을 기준으로 비교하고, 변경을 이해하는 데 필요한 영역만 표현한다. 실제 또는 제안하는 버튼명·필드명·안내 문구를 넣어 사용자가 보게 될 내용을 알 수 있게 한다.

상호작용이 있으면 행동 후 결과를 함께 보여준다. 처리 중·실패·복구·권한 제한 상태가 판단에 영향을 주면 필요한 범위만 포함한다. 문구가 약속하는 동작과 제안하는 기능이 일치하도록 한다.

이미 확인한 화면·코드·사용자 설명을 활용하고, 확인된 현재 상태와 가정·제안을 구분한다. 현재 화면을 확인하지 못했다면 사용자 설명을 바탕으로 재구성했다고 밝히거나, AS-IS 미확인으로 표시하고 TO-BE만 보여준다. 신규 화면은 억지로 AS-IS를 만들지 않고 현재 사용 흐름이나 제안 화면을 보여준다.

텍스트 도식은 읽기 쉽도록 **표 밖의 코드 블록**에 둔다. 표를 함께 사용하면 **해결방안**에는 변경의 요지와 이유를 적고, 실제 전후 차이는 도식이 설명하게 한다. 다른 항목도 도식에서 충분히 전달되었다면 요지만 남기거나 합쳐 반복을 줄인다.

## 질문과 승인

질문·승인 여부는 기존 프로젝트 정책과 사용자 위임 범위를 따른다. 그 안에서 사용자 결정이 필요한 미해결 사항만 질문한다.

이미 위임받은 판단은 합리적인 방안을 선택해 처리하고 이유를 설명한다.

질문이 필요하다면 단순히 "어떻게 할까요?"라고 묻지 말고 다음이 드러나게 한다.

**무엇을 결정해야 하는지, 선택지의 차이가 무엇인지, 무엇을 추천하는지**

설명이나 재정리 요청에 `진행할까요?` 같은 불필요한 실행 승인을 덧붙이지 않는다.

## 품질 기준

최종 답변만 읽어도 사용자가 현재 판단에 필요한 범위에서 다음 연결을 이해할 수 있어야 한다.

**맥락 → 문제 또는 검토사항과 원인 → 선택지와 전후 차이 → 추천 이유와 필요한 행동**

화면이나 동작을 바꾸는 설명은 사용자가 무엇을 보고, 무엇을 하면 어떤 결과가 나오는지 예상할 수 있어야 한다. 제안·미확인 사항이 이미 구현되거나 검증된 사실로 읽히지 않는지 확인한다.

형식의 충족보다 사용자가 상황과 변경 결과를 이해하고 판단할 수 있는지로 완성도를 평가한다. 이해와 판단에 충분하면 설명을 마치고, 같은 내용을 도입·표·도식·결론에서 반복하지 않는다.