나는 반복되는 불만을 볼 때 같은 단어끼리 먼저 묶지 않는다. 표현은 달라도 일이 끊기는 순간은 같을 수 있기 때문이다. 고객의 문장을 곧바로 기능 이름으로 바꾸면 요청은 빠르게 정리되지만, 제품은 더 복잡해지고 구매자는 무엇이 실제로 달라지는지 알기 어려워진다.
아래 내용은 판단 구조를 설명하기 위해 만든 합성 예시다. 특정 회사·제품·고객·화면·성과를 재현하지 않으며 실제 수치를 사용하지 않는다.
BEFORE — 불만 하나를 기능 하나로 바꾼다
가상의 업무용 소프트웨어에 비슷한 문의가 반복된다고 해보자. 어떤 사람은 조건이 바뀔 때 설정을 다시 해야 한다고 말한다. 다른 사람은 예외 사항이 다음 담당자에게 전달되지 않는다고 한다. 또 다른 사람은 문제가 생긴 뒤에야 현재 상태를 알 수 있다고 불만을 남긴다.
팀은 요청을 문장 그대로 정리한다. 설정 기능, 전달 기능, 상태 표시 기능이 각각 제품 목록에 추가된다. 고객의 목소리에 빠르게 반응한 것처럼 보이지만, 서로 다른 화면과 규칙이 생기면서 사용자는 더 많은 위치를 확인해야 한다. 판매 화면에는 기능이 늘어나고, 정작 구매자가 알고 싶은 “내 업무가 어디서 덜 끊기는가”는 흐려진다.
문제는 요청을 들은 데 있지 않다. 고객의 표현을 원인으로 확정한 것에 있다.
DIAGNOSIS — 요청 문장은 증상이고, 업무 상태는 원인 후보이다
고객은 자신이 겪은 순간을 말한다. 제품 팀은 그 말에서 문제가 발생한 상태, 책임자, 전환과 실패 조건을 찾아야 한다. 같은 업무 실패도 사람마다 다르게 표현할 수 있고, 비슷한 문장도 전혀 다른 원인에서 나올 수 있다.
- 상태 변화: 조건이 바뀌었는데 이전 규칙이 계속 적용된다.
- 예외 전달: 정상 경로를 벗어난 정보가 다음 사람에게 넘어가지 않는다.
- 책임 경계: 누가 확인하고 결정해야 하는지 불분명하다.
- 연속성 위험: 문제가 커진 뒤에야 상태 이상을 발견한다.
이 네 가지는 기능 이름이 아니라 일이 실패하는 방식이다. 여기까지 내려가야 여러 요청을 하나의 흐름으로 묶을지, 별도 문제로 나눌지 판단할 수 있다. 구매 설명도 달라진다. “기능이 몇 개 추가됐다”보다 “어떤 상태 변화와 예외를 놓치지 않게 되는가”가 더 직접적인 구매 근거가 된다.
VISUAL EVIDENCE — 서로 다른 불만은 어디에서 하나로 묶이는가
이 표가 답하는 질문은 하나다. 고객 문장을 기능 목록으로 옮기기 전에 어떤 공통 업무 실패를 확인해야 하는가? 정량 자료가 없으므로 빈도 점수나 우선순위 차트를 만들지 않는다.
| 합성 불만 | 먼저 확인할 업무 상태 | 실패 조건 | 개입 뒤 검증 |
|---|---|---|---|
| 조건이 바뀔 때마다 다시 설정해야 한다 | 상태 전환 | 새 조건이 적용되는 시점과 범위가 불명확하다 | 전환 뒤 잘못된 상태가 반복되는지 본다 |
| 예외 사항이 다음 담당자에게 전달되지 않는다 | 예외 전달과 책임 경계 | 정보는 남지만 확인할 사람이 지정되지 않는다 | 예외가 책임자에게 도달하고 처리까지 이어지는지 본다 |
| 문제가 생긴 뒤에야 현재 상태를 알 수 있다 | 연속성 위험 | 이상 신호와 확인 시점이 없다 | 문제가 커지기 전에 발견·확인되는지 본다 |
| 같은 내용을 여러 화면에 반복해서 입력한다 | 업무 단계 사이의 인계 | 앞 단계의 정보가 다음 단계에 이어지지 않는다 | 중복 입력뿐 아니라 누락과 재작업이 줄어드는지 본다 |
DECISION — 요청보다 실패 순간을 먼저 지도에 놓는다
첫 단계는 요청을 세는 일이 아니다. 각 불만이 언제, 어떤 조건에서, 누구의 업무를 멈추게 했는지 적는다. 같은 시점과 인계에서 발생한 요청은 하나의 묶음 후보가 된다.
- 상황을 적는다. 문제가 발생하기 직전 어떤 조건이 바뀌었는지 확인한다.
- 업무 단계를 찾는다. 입력, 판단, 인계, 실행, 확인 중 어디에서 일이 끊겼는지 표시한다.
- 책임자를 구분한다. 문제를 겪는 사람과 해결해야 하는 사람이 같은지 본다.
- 실패 조건을 쓴다. 누락, 지연, 잘못된 상태, 책임 공백 가운데 무엇이 실제 손실을 만드는지 정한다.
- 개입 형태를 비교한다. 새 기능이 필요한지, 기존 흐름의 연결이나 정보 위계만 고치면 되는지, 운영 규칙이 필요한지 나눈다.
- 출시 뒤 행동을 확인한다. 사용 여부, 같은 문의의 반복, 재작업과 실패 빈도를 본다. 충분한 근거가 없으면 매출이나 유지 효과까지 확대해 말하지 않는다.
이 순서에서 기능은 결론이 아니라 가능한 개입 중 하나다. 같은 실패를 해결하는 더 작은 연결 수정이 있을 수도 있고, 반대로 겉보기에는 비슷한 요청을 책임과 위험이 달라 분리해야 할 수도 있다.
AFTER — 요청 목록에서 업무 실패 지도로 바꾼다
| 비교축 | BEFORE | AFTER |
|---|---|---|
| 정리 단위 | 고객이 말한 기능 이름 | 상태 변화·예외·책임·인계 |
| 우선순위 | 반복해서 언급된 횟수 | 실패의 영향과 발생 조건 |
| 설계 시작점 | 새 화면과 새 기능 | 업무 흐름에서 끊긴 연결 |
| 구매 설명 | 추가된 기능의 수와 목록 | 놓치지 않게 되는 상태와 책임 |
| 출시 판단 | 기능을 배포하면 완료 | 관련 행동과 실패가 달라졌는지 확인 |
| 보류 기준 | 요청이 많으면 일단 만든다 | 공통 원인과 책임을 확인할 수 없으면 큰 변경을 보류한다 |
합성 사례의 수정안에서는 기능을 네 개로 늘리지 않는다. 먼저 상태 전환과 예외 인계가 같은 책임 흐름 안에 있는지 확인한다. 같은 원인이라면 한 곳에서 상태, 책임자와 다음 행동이 이어지도록 설계한다. 다른 위험이라면 억지로 합치지 않는다. 판매 문구도 기능 목록을 늘리는 대신, 구매자가 자신의 실패 순간과 달라질 흐름을 대응해 볼 수 있게 만든다.
WHEN NOT TO APPLY — 모든 요구를 패턴으로 합치면 안 된다
- 법적·계약상 요구는 자주 언급되지 않아도 그대로 충족해야 할 수 있다.
- 접근성·안전 문제는 요청 빈도보다 피해 가능성과 기본 권리를 우선한다.
- 긴급 장애와 데이터 손실은 충분한 묶음이 쌓일 때까지 기다리지 않고 먼저 복구한다.
- 표현은 같지만 책임과 위험이 다른 요청은 하나의 기능으로 억지로 합치지 않는다.
- 한 사람의 요청이라도 영향이 매우 큰 경우에는 빈도가 낮다는 이유로 제외하지 않는다.
패턴화는 요구를 지우는 작업이 아니다. 기능 수를 줄이기 위한 편집 기술도 아니다. 고객이 겪은 구체적인 순간을 잃지 않으면서, 제품이 해결해야 할 더 안정적인 구조를 찾는 과정이다.
DECISION RULE
서로 다른 요청이 같은 업무 실패를 가리킨다면 기능 수를 늘리기 전에 상태, 책임과 인계를 다시 설계한다. 기능을 배포한 사실은 개입의 증거일 뿐, 문제가 해결됐다는 증거는 아니다.