1. 정의

발견 이슈 정리는 프로젝트 자료와 사용자 요구를 분석해서 중요한 문제를 찾아내고 정리하는 과정이다.

이슈는 해결을 검토해야 하는 중요한 문제나 쟁점을 뜻한다. 쉽게 말하면 “이 프로젝트에서 반드시 봐야 하는 문제”다.

발견 이슈는 단순한 불만과 다르다. 불만은 사용자가 느낀 감정이나 의견일 수 있다. 이슈는 그 불만 속에서 실제로 해결해야 할 문제를 정리한 것이다.

예를 들어 사용자가 “앱이 너무 불편해요”라고 말했다고 하자. 이 문장만 보면 불만이다. 아직 이슈로 정리된 상태는 아니다.

이 불만을 분석하면 다음과 같은 이슈가 나올 수 있다.

• 사용자가 현재 진행 단계를 알기 어렵다.
• 전문 용어가 많아 내용을 이해하기 어렵다.
• 오류가 발생했을 때 수정 방법이 안내되지 않는다.
• 버튼 위치가 일관되지 않아 다음 행동을 찾기 어렵다.

이렇게 모호한 불만을 구체적인 문제로 바꾸는 과정이 발견 이슈 정리다.

서비스경험디자인기사 실기에서는 발견 이슈를 정리할 때 사용자 문제, 서비스 문제, 운영 문제를 함께 볼 수 있어야 한다. 서비스디자인은 사용자 화면만 보는 분야가 아니기 때문이다.

2. 필요한 이유

발견 이슈 정리가 필요한 이유는 프로젝트의 핵심 문제를 명확하게 만들기 위해서다.

사용자 요구를 많이 수집해도 바로 해결책을 만들면 안 된다. 먼저 어떤 문제가 반복되는지, 어떤 문제가 중요한지, 어떤 문제가 서비스 목표와 연결되는지 정리해야 한다.

이슈 정리가 부족하면 다음 문제가 생긴다.

• 중요하지 않은 문제에 시간을 쓰게 된다.
• 진짜 원인이 아니라 겉으로 보이는 현상만 고치게 된다.
• 조사 범위가 흐려진다.
• 디자인 원칙이 모호해진다.
• 아이디어가 문제 해결과 연결되지 않는다.
• 최종 산출물의 설득력이 떨어진다.

실제 개발에서도 이슈 정리는 중요하다. 예를 들어 회원가입 화면에서 사용자가 많이 이탈한다고 가정하자.

이때 “회원가입 화면을 개선한다”는 말만으로는 부족하다. 무엇을 개선해야 하는지 알 수 없기 때문이다.

다음처럼 이슈를 구체화해야 한다.

• 입력 항목이 많아 사용자가 부담을 느낀다.
• 비밀번호 규칙이 명확하게 안내되지 않는다.
• 오류 메시지가 원인을 알려주지 않는다.
• 필수 입력 항목과 선택 입력 항목이 구분되지 않는다.

이렇게 이슈를 정리하면 이후 해결 방향이 분명해진다. 입력 항목을 줄일지, 안내 문구를 바꿀지, 오류 메시지를 개선할지 판단할 수 있다.

서비스디자인에서도 마찬가지다. 발견 이슈는 이후 사용자 조사, 페르소나, 사용자 여정맵, 디자인 원칙, 아이디어 도출의 기준이 된다.

3. 핵심 개념

3-1. 이슈

이슈는 프로젝트에서 중요하게 다뤄야 하는 문제나 쟁점이다.

이슈는 단순히 “문제가 있다”는 말이 아니다. 해결할 필요가 있고, 프로젝트 방향에 영향을 주는 문제다.

3-2. 발견 이슈

발견 이슈는 자료 분석, 사용자 조사, 서비스 관찰을 통해 찾아낸 문제다.

예를 들어 “사용자가 결제 단계에서 많이 이탈한다”는 발견 이슈가 될 수 있다. “상담원이 같은 문의를 반복해서 받는다”도 발견 이슈가 될 수 있다.

3-3. 문제

문제는 현재 상태와 원하는 상태 사이의 차이다.

예를 들어 원하는 상태는 “사용자가 민원 신청을 쉽게 완료하는 것”이다. 현재 상태가 “사용자가 중간에 포기하는 것”이라면 그 차이가 문제다.

3-4. 불만

불만은 사용자가 서비스 이용 중 느낀 부정적인 의견이나 감정이다.

“어렵다”, “느리다”, “복잡하다”, “헷갈린다” 같은 표현이 불만에 해당할 수 있다.

불만은 이슈를 찾는 단서다. 하지만 불만 자체가 바로 이슈는 아니다. 불만을 분석해서 구체적인 문제로 바꿔야 한다.

3-5. 원인

원인은 문제가 발생하게 만든 이유다.

예를 들어 사용자가 예약을 포기하는 문제가 있다고 하자. 원인은 어려운 진료과 용어일 수 있다. 복잡한 단계일 수도 있다. 예약 가능 시간 안내 부족일 수도 있다.

3-6. 현상

현상은 겉으로 드러난 결과다.

예를 들어 “사용자가 앱을 종료한다”, “신청 완료율이 낮다”, “고객센터 문의가 많다”는 현상이다.

현상만 보고 해결하면 안 된다. 현상 뒤에 있는 원인을 찾아야 한다.

3-7. 페인포인트

페인포인트는 사용자가 서비스 이용 중 불편을 느끼는 지점이다.

페인포인트는 발견 이슈와 자주 연결된다. 예를 들어 “본인인증 절차가 반복되어 사용자가 피로감을 느낀다”는 페인포인트이면서 이슈가 될 수 있다.

3-8. 우선순위

우선순위는 여러 이슈 중 먼저 해결해야 할 순서를 정하는 것이다.

모든 문제를 한 번에 해결할 수는 없다. 사용자 영향도, 발생 빈도, 해결 가능성, 서비스 목표와의 관련성을 기준으로 우선순위를 정해야 한다.

4. 주변 기초 개념

4-1. 사용자 요구

사용자 요구는 사용자가 서비스에서 바라는 것 또는 필요로 하는 것이다.

발견 이슈는 사용자 요구와 연결된다. 사용자가 원하는 것이 충족되지 않을 때 이슈가 생기기 때문이다.

4-2. 요구사항

요구사항은 프로젝트에서 해결해야 할 조건이다.

발견 이슈는 요구사항으로 발전할 수 있다. 예를 들어 이슈가 “사용자가 현재 단계를 알기 어렵다”라면 요구사항은 “사용자는 현재 진행 단계를 확인할 수 있어야 한다”로 정리할 수 있다.

4-3. 문제 정의

문제 정의는 해결해야 할 문제를 명확한 문장으로 정리하는 것이다.

발견 이슈 정리는 문제 정의 전 단계 또는 문제 정의와 연결되는 단계다. 이슈를 잘 정리해야 문제 정의도 명확해진다.

4-4. 인사이트

인사이트는 조사 결과에서 발견한 의미 있는 해석이다.

단순한 사실과 인사이트는 다르다.

“사용자 40%가 신청 단계에서 이탈했다”는 사실이다. “사용자는 신청 조건을 이해하지 못해 다음 단계로 이동하지 못한다”는 인사이트에 가깝다.

4-5. 근본 원인

근본 원인은 문제를 발생시키는 가장 핵심적인 원인이다.

예를 들어 사용자가 “버튼이 작다”고 말할 수 있다. 하지만 근본 원인은 버튼 크기가 아니라 화면에서 중요한 기능의 우선순위가 낮은 것일 수 있다.

4-6. 이해관계자

이해관계자는 서비스와 관련된 사람이나 조직이다.

발견 이슈는 사용자만의 문제가 아닐 수 있다. 운영자, 상담원, 관리자, 제공자에게도 이슈가 생길 수 있다.

4-7. 정성자료

정성자료는 숫자보다 말, 행동, 감정, 이유를 담은 자료다.

인터뷰 기록, 관찰 메모, 사용자 발화, 상담 내용이 정성자료다. 이슈의 이유와 맥락을 파악하는 데 유용하다.

4-8. 정량자료

정량자료는 숫자로 표현되는 자료다.

이탈률, 완료율, 클릭 수, 대기시간, 문의 건수 등이 정량자료다. 이슈의 규모와 심각도를 판단하는 데 유용하다.

5. 실제 흐름

발견 이슈 정리는 다음 순서로 진행할 수 있다.

5-1. 자료를 수집한다

먼저 프로젝트와 관련된 자료를 모은다.

• 사용자 인터뷰 기록
• 관찰조사 메모
• 고객센터 문의 기록
• 서비스 이용 데이터
• 기존 화면 또는 서비스 흐름
• 운영 매뉴얼

자료가 많을수록 좋지만, 무조건 많이 모으는 것이 목적은 아니다. 프로젝트 문제와 관련 있는 자료를 골라야 한다.

5-2. 반복되는 내용을 찾는다

자료에서 반복적으로 등장하는 불편이나 문제를 찾는다.

예를 들어 여러 사용자가 “용어가 어렵다”고 말한다면 중요한 이슈일 가능성이 높다.

5-3. 현상과 원인을 구분한다

겉으로 보이는 현상과 그 뒤의 원인을 구분해야 한다.

“신청 완료율이 낮다”는 현상이다. “사용자가 필수 서류 안내를 이해하지 못한다”는 원인에 가깝다.

5-4. 사용자 관점으로 문제를 정리한다

이슈는 사용자가 겪는 문제로 정리하는 것이 좋다.

예를 들어 “화면 구성이 비효율적이다”보다 “사용자가 다음 행동을 찾기 어렵다”가 더 사용자 관점에 가깝다.

5-5. 서비스 운영 관점도 함께 본다

서비스디자인은 사용자만 보는 것이 아니다. 서비스를 제공하는 사람과 운영 과정도 함께 본다.

예를 들어 사용자가 같은 문의를 반복한다면 상담원의 업무 부담도 이슈가 된다.

5-6. 이슈를 그룹화한다

비슷한 이슈끼리 묶는다.

• 정보 이해 문제
• 절차 복잡성 문제
• 접근성 문제
• 오류 대응 문제
• 운영 프로세스 문제

이슈를 그룹화하면 전체 문제 구조를 쉽게 볼 수 있다.

5-7. 우선순위를 정한다

모든 이슈를 같은 수준으로 다루면 안 된다.

다음 기준으로 우선순위를 정할 수 있다.

• 사용자에게 미치는 영향이 큰가
• 자주 발생하는가
• 서비스 목표와 관련이 큰가
• 해결 가능성이 있는가
• 운영 부담을 줄일 수 있는가

5-8. 요구사항으로 연결한다

마지막으로 발견 이슈를 요구사항으로 바꾼다.

예를 들어 이슈가 “사용자가 오류 원인을 알기 어렵다”라면 요구사항은 “사용자는 오류 발생 시 원인과 수정 방법을 확인할 수 있어야 한다”가 될 수 있다.

6. 예시

아래는 발견 이슈 정리 예시다.

서비스 상황:
```

공공기관 온라인 민원 신청 서비스에서 신청 완료율이 낮다.

수집 자료:
사용자 인터뷰
고객센터 문의 기록
신청 단계별 이탈률 데이터
기존 신청 화면

반복 발견 내용:
사용자가 행정 용어를 이해하지 못한다.
사용자가 필수 서류를 어디서 확인해야 하는지 모른다.
사용자가 입력 오류 발생 시 수정 방법을 모른다.
사용자가 현재 몇 단계까지 진행했는지 알기 어렵다.

발견 이슈:
어려운 행정 용어로 인해 사용자가 신청 조건을 이해하기 어렵다.
필수 서류 안내가 분산되어 있어 사용자가 준비물을 놓친다.
오류 메시지가 수정 방법을 알려주지 않아 사용자가 신청을 포기한다.
진행 단계 표시가 부족해 사용자가 남은 절차를 예측하기 어렵다.

이슈 그룹:
정보 이해 문제
절차 안내 문제
오류 대응 문제
진행 상태 인지 문제

요구사항:
사용자는 어려운 행정 용어에 대한 쉬운 설명을 확인할 수 있어야 한다.
사용자는 신청 전에 필요한 서류를 한 화면에서 확인할 수 있어야 한다.
사용자는 오류 발생 시 원인과 수정 방법을 확인할 수 있어야 한다.
사용자는 현재 진행 단계와 남은 단계를 확인할 수 있어야 한다.

7. 코드 또는 설정 설명

이 주제는 개발 코드보다 이슈를 분석하고 정리하는 방식이 중요하다. 따라서 위 예시를 항목별로 설명한다.

7-1. 서비스 상황

공공기관 온라인 민원 신청 서비스에서 신청 완료율이 낮다.

서비스 상황은 현재 어떤 문제가 발생하는지 설명한다.

여기서 “신청 완료율이 낮다”는 현상이다. 아직 원인은 아니다. 이 현상의 원인을 찾기 위해 자료 분석이 필요하다.

7-2. 수집 자료

사용자 인터뷰
```

고객센터 문의 기록
신청 단계별 이탈률 데이터
기존 신청 화면

수집 자료는 이슈를 찾기 위한 근거다.

사용자 인터뷰는 사용자의 생각과 불편을 알 수 있게 한다. 고객센터 문의 기록은 반복되는 질문을 보여준다. 이탈률 데이터는 사용자가 어느 단계에서 포기하는지 보여준다. 기존 신청 화면은 실제 정보 구조와 절차를 확인하게 해준다.

7-3. 반복 발견 내용

사용자가 행정 용어를 이해하지 못한다.
```

사용자가 필수 서류를 어디서 확인해야 하는지 모른다.
사용자가 입력 오류 발생 시 수정 방법을 모른다.
사용자가 현재 몇 단계까지 진행했는지 알기 어렵다.

반복 발견 내용은 자료에서 자주 나타나는 문제다.

반복되는 내용은 중요한 이슈가 될 가능성이 높다. 단, 반복 횟수만 보지 말고 서비스 목표와의 관련성도 함께 봐야 한다.

7-4. 발견 이슈

어려운 행정 용어로 인해 사용자가 신청 조건을 이해하기 어렵다.
```

필수 서류 안내가 분산되어 있어 사용자가 준비물을 놓친다.
오류 메시지가 수정 방법을 알려주지 않아 사용자가 신청을 포기한다.
진행 단계 표시가 부족해 사용자가 남은 절차를 예측하기 어렵다.

발견 이슈는 반복 발견 내용을 문제 문장으로 정리한 것이다.

좋은 이슈 문장은 원인과 사용자 문제를 함께 포함한다. 예를 들어 “오류 메시지가 불편하다”보다 “오류 메시지가 수정 방법을 알려주지 않아 사용자가 신청을 포기한다”가 더 좋다.

7-5. 이슈 그룹

정보 이해 문제
```

절차 안내 문제
오류 대응 문제
진행 상태 인지 문제

이슈 그룹은 비슷한 문제를 묶은 것이다.

그룹화하면 문제를 한눈에 볼 수 있다. 이후 디자인 원칙을 세울 때도 도움이 된다.

7-6. 요구사항

사용자는 어려운 행정 용어에 대한 쉬운 설명을 확인할 수 있어야 한다.
```

사용자는 신청 전에 필요한 서류를 한 화면에서 확인할 수 있어야 한다.
사용자는 오류 발생 시 원인과 수정 방법을 확인할 수 있어야 한다.
사용자는 현재 진행 단계와 남은 단계를 확인할 수 있어야 한다.

요구사항은 발견 이슈를 해결하기 위한 조건이다.

“문제가 있다”로 끝나면 부족하다. 문제를 해결하기 위해 서비스가 어떤 조건을 갖춰야 하는지까지 정리해야 한다.

8. 주의점

8-1. 불만을 그대로 이슈로 쓰면 안 된다

“불편하다”, “복잡하다”, “어렵다”는 불만 표현이다. 실기 답안에서는 더 구체적인 이슈 문장으로 바꿔야 한다.

좋지 않은 표현은 다음과 같다.

사용자가 앱을 불편해한다.

더 좋은 표현은 다음과 같다.

사용자가 신청 단계에서 필수 정보를 찾지 못해 다음 단계로 이동하지 못한다.

8-2. 현상과 원인을 구분해야 한다

현상은 겉으로 나타난 결과다. 원인은 그 결과를 만든 이유다.

8-3. 제공자 관점만 보면 안 된다

제공자는 “문의가 많다”고 볼 수 있다. 사용자는 “어디서 정보를 확인해야 하는지 모르겠다”고 느낄 수 있다.

서비스디자인에서는 사용자 관점과 제공자 관점을 함께 봐야 한다.

8-4. 모든 이슈를 같은 중요도로 보면 안 된다

이슈는 우선순위를 정해야 한다.

자주 발생하고, 사용자에게 큰 영향을 주며, 서비스 목표와 관련이 높은 이슈를 먼저 다루는 것이 좋다.

8-5. 해결책을 너무 빨리 정하면 안 된다

이슈를 정리하는 단계에서는 해결책보다 문제 구조를 정확히 파악하는 것이 중요하다.

예를 들어 “버튼을 크게 한다”는 해결책이다. 하지만 진짜 이슈가 “사용자가 다음 행동을 예측하기 어렵다”라면 버튼 크기만 바꿔도 문제가 해결되지 않을 수 있다.

8-6. 이슈는 요구사항과 연결되어야 한다

발견 이슈를 정리한 뒤에는 요구사항으로 바꿔야 한다.

이슈가 “사용자가 진행 단계를 알기 어렵다”라면 요구사항은 “사용자는 현재 진행 단계와 남은 단계를 확인할 수 있어야 한다”가 된다.

9. 요약

발견 이슈 정리는 프로젝트 자료와 사용자 요구에서 중요한 문제를 찾아 구조화하는 과정이다.

이슈는 단순한 불만이 아니다. 프로젝트에서 해결을 검토해야 하는 중요한 문제다.

좋은 이슈 정리는 현상과 원인을 구분하고, 사용자 관점으로 문제를 설명하며, 이후 요구사항으로 연결된다.

핵심 흐름은 다음과 같다.

1. 자료를 수집한다.
2. 반복되는 내용을 찾는다.
3. 현상과 원인을 구분한다.
4. 사용자 관점으로 문제를 정리한다.
5. 서비스 운영 관점도 함께 본다.
6. 이슈를 그룹화한다.
7. 우선순위를 정한다.
8. 요구사항으로 연결한다.

발견 이슈 정리는 이후 문제 정의, 디자인 원칙 수립, 아이디어 도출, 프로토타입 개발의 기준이 된다.

10. 핵심 용어 정리

이슈 = 프로젝트에서 중요하게 다뤄야 하는 문제나 쟁점

발견 이슈 = 자료 분석이나 사용자 조사 과정에서 찾아낸 중요한 문제

문제 = 현재 상태와 원하는 상태 사이의 차이

불만 = 사용자가 서비스 이용 중 느낀 부정적인 의견이나 감정

현상 = 겉으로 드러난 결과

원인 = 문제가 발생하게 만든 이유

근본 원인 = 문제를 만든 가장 핵심적인 원인

페인포인트 = 사용자가 서비스 이용 중 불편을 느끼는 지점

사용자 요구 = 사용자가 서비스에서 바라는 것 또는 필요로 하는 것

요구사항 = 프로젝트에서 해결해야 하는 조건

문제 정의 = 해결해야 할 문제를 명확한 문장으로 정리하는 것

인사이트 = 조사 결과에서 발견한 의미 있는 해석

이해관계자 = 서비스와 관련된 사람이나 조직

정성자료 = 말, 행동, 감정, 이유처럼 맥락을 담은 자료

정량자료 = 이탈률, 완료율, 문의 건수처럼 숫자로 표현되는 자료

이슈 그룹화 = 비슷한 문제를 묶어 구조화하는 과정

우선순위 = 여러 이슈 중 먼저 해결해야 할 순서

사용자 관점 = 사용자가 서비스를 이용하면서 겪는 경험을 중심으로 보는 관점

제공자 관점 = 서비스를 운영하고 제공하는 사람의 업무를 중심으로 보는 관점

요구사항 도출 = 발견 이슈를 해결 조건으로 바꾸는 과정