요구사항 인터뷰 망하는 질문 vs 먹히는 질문: 고객·현업 30개(복붙)

현업이 말을 아낄수록, 질문은 더 선명해야 합니다. 이 글은 “다음 회의에서 바로 쓰는” 버전입니다.

서론: “필요한 거 뭐예요?”로는 아무 것도 못 얻는다

제가 처음 IT 기획자로 현업 업무 회의에 참석하였을 때 현업이 필요한 사항을 정확하게 알려 주지 않아 어떻게 기획을 해야할 지 난감할 때가 많았습니다. 질문을 던져도 답이 흐릿하고, 회의가 끝나면 “정리해서 공유해 주세요”만 남는 그 느낌. 그때 알게 된 사실이 하나 있어요. 요구사항이 없는 게 아니라 안전한 말만 남도록 질문이 설계되어 있었던 겁니다.

“원하시는 기능이 있나요?” 같은 넓은 질문은 상대를 편하게 해주지만, 기획자는 그대로 추측 지옥에 떨어집니다. 누락, 변경, 예외 폭탄, QA에서 뒤늦게 터지는 불꽃놀이까지 🎇

그래서 이 글에서는 망하는 질문 vs 먹히는 질문을 비교하고, 고객용 15개 + 현업용 15개로 나눠서 인터뷰 질문 30개를 제공합니다. 복붙해서 쓰고, 회의 끝나면 바로 요구사항으로 정리할 수 있게 정리 템플릿도 같이 넣었습니다.

10분 준비: 인터뷰를 “질문지”로 끝내지 않는 법

인터뷰는 질문 수가 아니라 의도(검증)로 성패가 갈립니다. 아래 3가지만 준비하면 “말은 했는데 문서로 못 남는 상황”이 크게 줄어요.

오늘의 결론 형태를 정한다: “요구사항 후보 리스트”인지, “의사결정(Yes/No)”인지.
범위를 고정한다: 이번 릴리스/이번 분기/이번 프로젝트 중 어디까지가 범위인지.
성공 기준을 먼저 뽑는다: “잘 됐다”를 숫자든 문장이든 정의해두기.

인터뷰 진행 한 줄 스크립트
“오늘은 (범위) 안에서 (목표)을 위해 필요한 요구사항을 정리하고, 마지막에 (결론 형태)까지 만들겠습니다.”

1) 망하는 질문 vs 먹히는 질문 (바로 교체표)

아래 왼쪽 질문이 입 밖으로 나오려는 순간, 오른쪽으로 즉시 갈아타면 됩니다. (기획자의 언어는 변신 로봇이 좋습니다 🤖)

망하는 질문	먹히는 질문(대체 문장)
원하시는 기능이 있나요?	이번 목표를 막는 가장 큰 장애물 1개가 뭔가요? 그걸 줄이는 기능이면 무엇이 좋을까요?
필요한 건 다 말씀해 주세요.	우선 반드시 있어야 하는 것 3개만 뽑아주실래요? 그다음 있으면 좋은 것 3개요.
이 기능 꼭 필요해요?	이 기능이 없으면 어떤 손해가 발생하나요? 시간/돈/리스크 중 어디가 가장 크죠?
어떤 화면이 좋을까요?	사용자가 이 화면에서 최종적으로 해야 하는 행동 1개는 뭔가요?
이건 나중에 정하죠.	지금 결정 안 하면 누가 언제 어떤 비용을 치르나요? 그 비용이 크면 지금 결정합시다.
예외는 없겠죠?	“안 되는 경우”를 3개만 떠올려볼게요. 권한/상태/시간으로 나눠보면 뭐가 있나요?
대충 이런 느낌 맞나요?	제가 이해한 걸 한 문장으로 말해볼게요. 틀린 단어만 바로 잡아주세요: “A가 B를 위해 C한다.”
데이터는 있나요?	결정에 필요한 데이터는 어디에 있고, 누가 관리하며, 신뢰도는 어느 정도인가요?

2) 고객 인터뷰 질문 15개 (고객용)

고객은 “기능”보다 “상황”을 먼저 말합니다. 그래서 질문도 상황 → 목적 → 기준 순서가 잘 먹혀요.

2-1) 문제와 상황(As-Is) 파악

이 일을 하게 되는 상황은 언제 시작되나요? (트리거)
지금은 어떤 방법으로 해결하고 있나요? (우회/대체 수단 포함)
가장 불편한 순간은 언제인가요? 딱 1개만 고르면요.
불편함이 발생할 때 보통 어떤 순서로 행동하나요? (1,2,3단계)
문제가 해결되지 않으면 어떤 손해가 나나요? 시간/돈/스트레스 중 어디가 큽니까?

2-2) 목적과 성공 기준(“잘 됐다” 정의)

이 기능/서비스가 생기면 가장 먼저 좋아질 건 무엇인가요?
“성공했다”를 판단하는 기준이 있나요? (예: 처리시간, 완료율, 오류율)
하루/주/월 기준으로 이 일을 몇 번 하나요? 빈도는요?
이 과정에서 꼭 지켜야 하는 규칙이나 관행이 있나요?
누가 최종 결정을 내리나요? (본인/팀장/다른 부서/가족 등)

2-3) 우선순위와 대안(범위 고정)

반드시 필요한 것 3개, 있으면 좋은 것 3개를 나눠주세요.
만약 딱 1개만 된다면 어떤 걸 고르겠어요? 이유는요?
지금 쓰는 대안(다른 앱/엑셀/수기/전화)이 있다면, 그 대안의 좋은 점은 뭔가요?
이 기능이 도입되면 걱정되는 점은요? (복잡함, 개인정보, 실수 등)
이 기능이 “절대 안 맞는 사람”도 있을까요? 있다면 왜요?

고객 답변이 두루뭉술할 때 후속 질문 3종
1) “그때 정확히 어떤 화면/상황이었나요?”
2) “그 행동의 목적은 뭐였나요?”
3) “그 결과가 ‘성공’인지 ‘실패’인지 어떻게 판단했나요?”

3) 현업(내부) 인터뷰 질문 15개 (현업용)

현업은 “업무 프로세스”와 “책임/리스크”가 중심입니다. 그래서 질문은 프로세스 → 정책 → 예외 → 책임 순서로 캐면 잘 나옵니다.

3-1) 업무 흐름과 책임(프로세스)

이 업무의 시작과 끝을 한 문장으로 정의하면요? (범위 고정)
현재 프로세스는 단계가 몇 개인가요? 1,2,3으로 쪼개면요.
각 단계의 담당자와 승인자는 누구인가요?
업무가 몰리는 시간대/기간이 있나요? (월말, 성수기, 이벤트)
가장 자주 발생하는 병목 단계는 어디인가요? 왜요?

3-2) 정책, 데이터, 권한

반드시 지켜야 하는 정책/규정/약관이 있나요? (문서 위치까지)
권한은 어떻게 나뉘나요? 역할(관리자/담당자/조회자) 기준으로 정리해볼까요?
필수 데이터는 무엇인가요? 입력/조회/수정 중 어디가 핵심인가요?
데이터의 “정답”은 어디에 있나요? 마스터는 어느 시스템인가요?
로그는 어떤 수준까지 필요하나요? (누가/언제/무엇을/왜/결과)

3-3) 예외, 운영, 리스크

업무가 실패하는 대표 케이스 3개만 꼽으면요? (권한/상태/시간으로 나눠보기)
실패했을 때 복구는 어떻게 하나요? 누가 어떤 순서로요?
알림은 누가 언제 받아야 하나요? (즉시/일배치/주간)
이 변경이 생기면 가장 먼저 항의할 사람(또는 부서)은 어디인가요? 이유는요?
이번 범위에서 “하지 말아야 할 것”이 있나요? (리스크/비용/정치적 지뢰밭 포함)

현업이 “그건 그냥 그렇게 해요”라고 말할 때
“그렇게 해야 하는 이유가 정책인지, 리스크인지, 시스템 제약인지 구분만 해볼게요. 셋 중 뭐에 가장 가까울까요?”

4) 질문을 요구사항으로 바꾸는 정리 템플릿(복붙)

인터뷰가 끝나도 문서가 안 나오면, 질문만 잘한 겁니다. 요구사항은 아래처럼 “형태”로 굳혀야 살아남아요. 그대로 복사해서 회의록이나 요구사항정의서에 붙이세요.

[요구사항 ID] RQ-___
[한 줄 요약] 누가(역할)가 무엇을(행동) 왜(목적) 하도록 한다.

1) 배경/문제(As-Is)
- 현재 방식:
- 불편/손해(시간/돈/리스크):
- 발생 빈도:

2) 목표(To-Be)
- 기대 변화:
- 성공 기준(KPI/체감 기준):

3) 범위
- 포함:
- 제외(이번에는 안 함):

4) 상세 규칙/정책
- 규칙:
- 권한:
- 데이터(마스터/소스):

5) 예외/오류/경계조건
- 예외 1:
- 예외 2:
- 예외 3:

6) 수용 기준(Acceptance Criteria)
- [Given] ___일 때
- [When] ___하면
- [Then] ___이 되어야 한다

7) 리스크/의존성
- 리스크:
- 의존 시스템/부서:
- 결정 필요 사항(미정):

팁: 수용 기준(AC)은 길게 쓰지 말고 “테스트 가능한 문장”으로만 남기면 QA에서 천사가 됩니다 😇

5) 요구사항 인터뷰 실수 TOP 5

실수: 기능부터 묻는다
증상: “뭐 넣을까요?”만 돌고 끝남
대응: 목적(왜) 1문장 먼저 고정: “A가 B를 위해 C한다”
실수: 범위를 안 자른다
증상: 요구사항이 회의 중에 계속 늘어남
대응: “이번 릴리스 포함/제외”를 먼저 선언하고, 제외는 백로그로 분리
실수: 예외를 끝까지 안 판다
증상: 배포 직전 QA에서 예외 폭발
대응: 권한/상태/시간 3축으로 예외 3개만 강제로 뽑기
실수: 책임자와 결정자를 안 묻는다
증상: “그건 제가 몰라요” 릴레이 시작
대응: 담당자/승인자/최종결정자 3명을 분리해서 기록
실수: 인터뷰 내용을 “확인”하지 않는다
증상: 나중에 “그렇게 말한 적 없는데요?” 발생
대응: 회의 말미에 한 문장 리캡: “오늘 결론은 ___입니다. 틀린 단어 있나요?”

결론

요구사항 인터뷰는 상대의 입을 여는 기술이기도 하지만, 더 정확히는 모호함을 문서로 바꾸는 기술입니다. 오늘 글의 핵심은 하나예요. “좋은 질문”은 친절한 질문이 아니라, 결정을 만들 수 있는 질문입니다. 다음 회의에서 이 30개 중 5개만 꺼내도 회의록의 밀도가 달라질 겁니다.

FAQ

Q 고객 인터뷰와 현업 인터뷰, 어느 쪽을 먼저 해야 하나요?

A 가능하면 고객(또는 사용자) → 현업 순서가 깔끔합니다. 고객이 “왜”를 주고, 현업이 “어떻게”와 “제약”을 줍니다.

Q 현업이 바쁘다며 답을 회피할 때는요?

A “다 필요해요” 같은 질문 대신, 3개만 뽑아달라고 범위를 줄이세요. 그리고 “오늘 결론은 후보 3개 정리”처럼 결론 형태를 낮추면 협조가 올라갑니다.

Q 인터뷰에서 나온 말이 서로 충돌하면 어떻게 정리하죠?

A 충돌을 숨기지 말고 문서에 선택지 A/B로 올리세요. 각각의 장단점, 비용, 리스크를 붙이면 의사결정이 빨라집니다.

Q 질문을 다 했는데도 요구사항이 애매해요.

A 그때는 수용 기준(AC)으로 전환하세요. “어떤 조건에서 어떤 행동을 하면 어떤 결과가 나와야 하는가”로 문장을 만들면 애매함이 줄어듭니다.

Q 예외는 어디까지 파야 하나요?

A 전부 파려다 지칩니다. 대신 가장 자주 발생 1개 + 가장 위험 1개 + 가장 황당 1개만 먼저 잡고, 나머지는 운영 로그를 보고 확장하세요.

Q 질문 30개를 회의에서 다 쓰면 시간이 터지지 않나요?

A 그래서 “전부”가 아니라 “상황별”입니다. 첫 회의는 문제/목표/범위 위주, 두 번째부터 정책/예외/AC로 깊게 들어가면 됩니다.

Q 신입 기획자에게 가장 추천하는 질문 3개만 꼽는다면?

A 1) “이걸 해결하려는 목적은 한 문장으로 뭐죠?”
2) “반드시 필요한 3개만 고르면요?”
3) “안 되는 경우 3개만 떠올리면요?”
이 3개는 회의의 방향을 바로 세웁니다.

이 블로그 검색

AI야, 기획 아이디어 줄래?