프로토타이핑과 사용자 인터뷰 실습 — 요구 도출 결과를 화면으로 확인받기

개념

이 레슨의 경계 — 세션 운영도 기법 목록도 아니다

앞뒤로 겹칠 수 있는 레슨이 둘 있어 먼저 선을 긋는다.

즉 이 레슨은 요구 도출(elicitation) 쪽이다. 사용성 테스트는 "이미 만든 것이 쓰기 쉬운가" 를 묻고, 여기서 하는 인터뷰와 프로토타입 워크스루는 "무엇을 만들어야 하는가, 우리가 이해한 것이 맞는가" 를 묻는다. 목적이 다르니 같은 방에서 같은 도구를 써도 성공 기준이 다르다.

한 사이클의 모양

① 학습 목표 정의   무엇을 알아내야 결정을 내릴 수 있는가
② 인터뷰 설계      학습 목표 → 질문, 유도 질문 제거
③ 인터뷰 실시      3~6명. 기록은 해석 말고 발언 그대로
④ 로우파이 프로토타입  들은 것을 화면으로 그린다(1~2시간)
⑤ 워크스루로 확인   "이게 맞습니까" 를 그림으로 묻는다
⑥ 수용 기준 번역    관찰·합의 → Given-When-Then → 테스트 대상

한 바퀴가 보통 3~5일이다. ④를 정성껏 만들면 ⑤가 늦어지고, ⑤가 늦어지면 잘못 이해한 채로 개발이 시작된다. 그래서 프로토타입의 충실도는 일부러 낮게 잡는다.

① 학습 목표부터 — 질문은 거꾸로 짠다

인터뷰 실패의 대부분은 질문을 먼저 쓰기 때문에 생긴다. 순서를 뒤집는다.

[결정]   정산 화면에 '보류 금액' 항목을 따로 노출할 것인가
   ↓
[학습 목표]
  L1. 판매자가 지금 보류 금액을 어디서 어떻게 확인하고 있는가
  L2. 보류 금액을 잘못 이해해서 생긴 문의·실수가 실제로 있는가
  L3. 보류 해제 시점을 판매자가 무엇으로 예측하는가
   ↓
[질문]
  L1 → "지난달 정산금이 예상과 달랐을 때, 그때 무엇부터 보셨어요?"
  L2 → "정산 금액 때문에 고객센터에 문의하신 적이 있나요? 그때 이야기를 해 주세요."
  L3 → "돈이 언제 들어올지 어떻게 아세요?"

학습 목표에 연결되지 않는 질문은 지운다. 질문이 10개를 넘으면 대개 학습 목표가 흐린 것이다. 그리고 결정 없는 인터뷰는 하지 않는다 — 이 인터뷰 결과로 무엇을 정할지 못 쓰겠다면 아직 인터뷰할 때가 아니다.

② 유도 질문을 걸러낸다

유도 질문은 답을 미리 심어 둔 질문이다. 정중해 보여서 알아채기 어렵다.

원칙 셋으로 줄일 수 있다. 과거의 실제 행동을 묻는다(미래·가정이 아니라). 예/아니요로 끝나지 않게 연다. 해결책이 아니라 문제를 묻는다 — 사용자는 해결책 설계자가 아니라 문제의 목격자다. 관련 있는 상황을 말하면 "그때 이야기를 더 해 주세요" 로 이어 가고, 침묵이 와도 3초는 기다린다.

기록은 해석하지 말고 발언 그대로 남긴다. "UX 가 불편하다고 함" 이 아니라 "정산일에 앱을 세 번 들어와서 계속 새로고침했다" 다. 앞의 문장은 나중에 무엇으로도 검증할 수 없다.

④ 로우파이 프로토타입 — 왜 일부러 거칠게 만드는가

충실도(fidelity)는 정확도가 아니라 의도된 미완성도 다.

예쁘게 만들수록 이해관계자는 "이미 정해진 것" 으로 받아들여 반대 의견을 덜 낸다. 요구를 확인받는 단계에서는 이게 치명적이다. 손으로 그린 선과 회색 상자는 "아직 고칠 수 있다" 는 신호를 준다. 색·폰트·문구 논쟁이 시작되면 그 자체가 충실도가 너무 높다는 뜻이다.

QA 가 프로토타입을 볼 때는 화면 하나가 아니라 상태 를 본다. 빈 상태, 로딩, 부분 실패, 권한 없음, 금액이 0원이거나 음수, 목록이 1,000건인 경우. 기획자가 그린 것은 대개 정상 상태 하나이고, 나머지 상태가 요구사항의 구멍이다. 이 구멍을 워크스루 전에 찾아 두는 것이 이 단계에서 QA 가 만드는 가장 큰 가치다.

⑤ 워크스루 — 그림으로 "이게 맞습니까" 를 묻는다

프로토타입 워크스루는 데모가 아니다. 내가 이해한 것을 되돌려 보여 주고 틀린 곳을 찾아 달라고 부탁하는 자리 다. 30~40분이면 된다.

[진행 순서]
1. 목적 선언(2분)   "지난주 인터뷰에서 들은 걸 화면으로 옮겼습니다.
                    틀린 곳을 찾는 게 오늘의 목표입니다. 예쁘지 않은 건 일부러입니다."
2. 시나리오 낭독(3분) "정산일 아침, 입금액이 예상보다 적은 걸 발견한 상황입니다."
3. 화면 넘기기(15분)  한 화면씩. "여기서 무엇을 하시겠어요?" / "이 숫자는 무슨 뜻으로 읽히세요?"
4. 예외 상태 보여주기(10분) 보류 금액이 0원일 때, 정산이 지연될 때, 권한 없는 계정일 때
5. 합의·미결 정리(5분) 확정된 것 / 바뀐 것 / 아직 모르는 것을 그 자리에서 소리 내어 읽고 동의받는다

4번이 QA 가 넣는 항목이다. 정상 흐름은 누구나 확인하지만 예외 상태는 워크스루에서 묻지 않으면 개발 중에 개발자가 혼자 정하게 된다.

5번의 세 칸 정리는 회의록보다 유용하다.

[워크스루 결과 — 정산 상세 / 2026-09-24 / 판매자 3인]
확정   보류 금액을 정산 합계와 같은 화면에 분리 표시한다
확정   보류 사유는 항목별로 한 줄씩 보여 준다
변경   '예상 입금일' 대신 '보류 해제 예정일' 로 부른다(P2 발언: 입금일로 오해)
미결   보류 해제 예정일이 지났는데 해제 안 된 경우의 표기 — 정산팀 정책 확인 필요

⑥ 수용 기준으로 번역한다 — 여기가 QA 의 몫

인터뷰 기록과 워크스루 합의는 아직 검증할 수 없는 문장이다. 이것을 관찰 → 요구 → 수용 기준 으로 내려보내는 일이 QA 가 이 사이클에 들어가는 이유다.

[관찰]  P2: "입금액이 적어서 놀랐는데, 어디에 얼마가 묶여 있는지는 안 보여서
             고객센터에 전화했어요." (2026-09-17 인터뷰, 00:14:20)
   ↓
[요구]  REQ-217 판매자는 정산 상세 화면에서 보류 금액의 총액과 항목별 사유를
             문의 없이 확인할 수 있어야 한다.
   ↓
[수용 기준]
AC-217-1  Given 보류 금액이 1건 이상 있는 판매자로 로그인했을 때
          When  정산 상세 화면을 열면
          Then  '보류 금액' 총액이 정산 합계와 같은 화면에 표시된다
AC-217-2  Given 보류 항목이 3건 있을 때
          When  보류 금액 영역을 펼치면
          Then  각 항목의 금액·사유·해제 예정일이 항목 수만큼 표시된다
AC-217-3  Given 보류 금액이 0원일 때
          When  정산 상세 화면을 열면
          Then  보류 금액 영역은 '보류 중인 금액이 없습니다' 로 표시된다
AC-217-4  Given 보류 해제 예정일이 오늘보다 이전인 항목이 있을 때
          When  정산 상세 화면을 열면
          Then  (미결 — 정산팀 정책 확정 전까지 개발 착수하지 않는다)

좋은 수용 기준의 조건은 관찰 가능 하고, 판정 기준이 하나 이고, 데이터 전제가 명시 되어 있는 것이다.

AC-217-4 처럼 미결을 미결로 남기는 것 도 산출물이다. 빈칸을 개발자가 상상으로 채우면 나중에 결함으로 돌아온다.

추적성 — 발언에서 테스트까지 한 줄로

번역이 끝나면 한 행이 남는다. 이 표가 있으면 "왜 이렇게 만들었나" 라는 질문에 6개월 뒤에도 답할 수 있다.

실무에서 왜 필요한가

요구사항 결함은 가장 늦게 발견되고 가장 비싸게 고쳐진다. 코드가 명세대로 동작하는데도 사용자가 원하던 것이 아니면 테스트는 전부 통과하고 제품만 실패한다. 이 사이클은 그 실패를 개발 착수 전에 잡는 가장 값싼 장치다 — 판매자 세 명과 두 시간, 회색 상자 다섯 장이면 된다.

QA 가 여기 참여하면 얻는 것이 하나 더 있다. 테스트 설계를 개발 전에 끝낼 수 있다. 워크스루에서 예외 상태를 물어 수용 기준으로 적어 두면, 그것이 그대로 테스트 케이스의 뼈대가 된다. 요구사항이 확정된 뒤에 테스트를 설계하는 팀과, 요구사항을 확정하면서 테스트를 설계하는 팀은 같은 기간에 전혀 다른 품질을 낸다.

채용시장에서의 위치

서비스 기획·프로덕트 QA·BA 공고에서 "요구사항 정의 및 수용 기준 작성 경험" 은 흔한 요구사항이고, 인터뷰 기록이나 와이어프레임을 포트폴리오로 요구하는 곳도 있다. 인터뷰 발언에서 수용 기준까지 한 줄로 이어진 사례 하나를 정리해 두면, 그 자체가 요구 분석 능력의 증거가 된다.

실습 과제

과제 1 — 학습 목표에서 질문으로, 유도 질문 걸러내기 (20분)

자주 쓰는 서비스에서 개선하고 싶은 기능 하나를 고른다. (1) 이 인터뷰로 내릴 결정 을 한 문장으로 쓰고, (2) 학습 목표 3개를 쓰고, (3) 각 목표당 질문 2개씩 총 6개를 쓴다. 다 쓴 뒤 본문의 원칙 셋(과거 행동·열린 질문·문제 중심)으로 자기 질문을 점검해, 걸린 질문에 표시하고 고친 문장을 나란히 적는다.

과제 2 — 로우파이 프로토타입과 워크스루 (30분)

과제 1의 기능을 와이어프레임 3~5장으로 그린다(종이·draw.io·Figma 아무거나, 회색 상자 수준). 정상 흐름 외에 예외 상태 2장 을 반드시 포함한다. 동료나 지인 한 명에게 본문의 5단계 순서대로 워크스루를 진행하고, 결과를 확정 / 변경 / 미결 세 칸으로 정리한다.

과제 3 — 수용 기준으로 번역하고 추적표 만들기 (25분)

과제 2의 확정·변경 항목 중 둘을 골라 관찰 → 요구 → 수용 기준(Given-When-Then)으로 내려쓴다. 수용 기준은 항목당 3개 이상이고, 그중 하나는 예외·경계 상태 여야 한다. 미결 항목은 미결로 표기한 AC 로 남긴다. 마지막으로 발언 ID·요구·수용 기준·테스트 케이스를 잇는 추적표 한 장을 만든다.

자가 체크리스트

• 이 레슨과 s5-m49-l02·s2-m45-l05 의 경계를 설명할 수 있다
• 결정 → 학습 목표 → 질문 순서로 인터뷰를 설계할 수 있다
• 유도 질문을 알아보고 과거 행동을 묻는 열린 질문으로 고칠 수 있다
• 인터뷰 기록을 해석이 아니라 발언 그대로 남기는 이유를 말할 수 있다
• 프로토타입 충실도를 목적에 맞게 고르고, 일부러 낮추는 이유를 설명할 수 있다
• 프로토타입에서 정상 상태 외에 확인할 상태 다섯 가지를 열거할 수 있다
• 워크스루를 5단계로 진행하고 결과를 확정·변경·미결로 정리할 수 있다
• 관찰을 요구와 Given-When-Then 수용 기준으로 번역할 수 있다
• 나쁜 수용 기준을 판정 가능한 문장으로 고칠 수 있다
• 발언에서 테스트 케이스까지 잇는 추적표를 만들 수 있다

흔한 실수

• 해결책을 묻는다. "이런 기능 있으면 쓰시겠어요?" 의 답은 거의 항상 "네" 이고, 아무것도 알려 주지 않는다. 과거에 실제로 한 일을 묻는다.
• 인터뷰를 확인 절차로 쓴다. 이미 만들 것을 정해 두고 동의만 받으러 가면 유도 질문밖에 안 나온다.
• 기록에 해석을 섞는다. "불편해함" 은 검증할 수 없다. 발언과 행동을 그대로 적고 해석은 따로 표시한다.
• 프로토타입을 너무 정교하게 만든다. 예쁠수록 반대 의견이 줄고, 만든 사람도 버리기 아까워진다.
• 정상 흐름만 그린다. 빈 상태·실패·권한 없음이 빠진 프로토타입은 요구사항의 절반만 확인한 것이다.
• 워크스루 결과를 합의로 남기지 않는다. 그 자리에서 확정·변경·미결을 소리 내어 읽고 동의받지 않으면 다음 주에 기억이 갈린다.
• 수용 기준에 형용사를 쓴다. '빠르게·적절히·직관적으로' 는 판정할 수 없다. 숫자나 관찰 가능한 결과로 바꾼다.
• 한 수용 기준에 두 가지를 넣는다. '그리고' 가 들어가면 어느 쪽이 실패했는지 보고할 수 없다.
• 미결을 비워 둔다. 미결은 미결로 명시해 남겨야 개발자가 상상으로 채우지 않는다.

참고 자료

• Nielsen Norman Group — Paper Prototyping — 로우파이 프로토타입의 목적과 진행
• Nielsen Norman Group — Open-Ended vs. Closed Questions in User Research — 질문 형태가 답을 바꾸는 방식
• IIBA — BABOK v3 Techniques: Interviews, Prototyping — 기법의 공식 정의(원문 확인)
• 레슨 s2-m45-l05 — 요구 도출 기법의 목록과 선택 기준(선행)
• 레슨 s5-m49-l02 — 사용성 테스트 세션 설계·모더레이팅
• 레슨 s2-m45-l06 — 정책·규칙·예외를 요구사항으로 옮기기