{3줄 요약}

요구사항 정의는 팀이 무엇을 만들지 합의하는 과정이지 기능 나열만이 아니에요.
좋은 문서는 사용자 목표·제약·성공 조건까지 담아서 "버튼을 넣자"가 아니라 "몇 초 안에 로그인을 끝낸다"처럼 말해요.
이걸 건너뛰면 개발 중에 방향이 흔들리고 늦을수록 고치는 비용이 커져요.

이 방법이 필요한 순간이에요

새 기능을 개발하기 전, 주요 리디자인 전, 또는 여러 팀이 협업해야 할 때 요구사항 정의가 필요해요.

"개발 시작하고 나서 필요한 것 말해줄게요"는 가장 비효율적인 방식이에요.
요구사항이 명확하지 않으면 개발자는 가장 단순하게 구현하거나, 자신의 판단으로 결정해요.
그 결과가 원하는 것과 다를 수 있어요.

요구사항 정의는 완벽한 문서를 만드는 게 목표가 아니에요.
팀이 같은 방향을 보고 있는지 확인하고, 모르는 것을 드러내는 과정이에요.

실행 순서를 이렇게 나눠요

1단계 — 사용자 관점의 목표 정의하기

기능 명세 전에 먼저 "사용자는 이것으로 무엇을 달성하려 하는가"를 써요.

형식: "[사용자 유형]로서, [목표]를 하고 싶어요. 왜냐하면 [이유] 때문이에요. "

User Story라고 불리는 이 형식은 기능이 아닌 목표 중심으로 생각하게 해요.

예시:

  • "첫 구매 사용자로서, 내 배송지를 빠르게 입력하고 싶어요. 여러 번 반복 입력하기 번거롭기 때문이에요."
  • "자주 이체하는 사용자로서, 최근 이체 기록을 한 번 탭으로 다시 보낼 수 있으면 좋겠어요. 매번 계좌번호를 찾기 귀찮기 때문이에요."

User Story가 있으면 개발자가 "이게 왜 필요한지"를 알아요.
맥락을 알면 더 좋은 기술적 결정을 내릴 수 있어요.

2단계 — 기능 범위 명확히 하기

무엇을 만들 것인지 (In Scope)와 이번에 만들지 않을 것인지 (Out of Scope)를 명확히 써요.

"나중에 추가하면 되지"로 남겨두면 개발 중에 "이것도 해야 하는 거 아닌가요?"가 계속 나와요.
"이번 버전에서는 X는 안 한다"를 명시해야 그 논쟁이 줄어요.

예시 (이체 기능 v1):

  • In Scope: 계좌번호 직접 입력, 최근 이체 목록에서 선택
  • Out of Scope: 연락처 기반 이체, 예약 이체, 자동 이체 설정

3단계 — 성공 기준 정의하기

"잘 됐다"를 어떻게 판단할지 미리 정해요.

성공 기준은 측정 가능해야 해요.

  • ❌ "이체가 빠르고 쉬워야 한다"
  • ✅ "이체 완료까지 3단계 이하, 소요 시간 평균 30초 이내"

이게 없으면 개발이 끝난 후 "이게 잘 됐나요?"를 판단할 기준이 없어요.
또한 이후 A/B 테스트나 UX 테스트의 측정 기준이 돼요.

4단계 — 제약 조건 파악하기

제약 조건을 모르면 나중에 "이건 기술적으로 안 돼요"가 나와요.

파악해야 할 제약:

  • 기술적 제약: 현재 인프라에서 가능한 것, API 제한
  • 시간 제약: 언제까지 만들어야 하는가
  • 디자인 제약: 기존 Design System 컴포넌트만 쓸 것인가
  • 법적/정책 제약: 금융, 의료, 개인정보 관련 규제
  • 비즈니스 제약: 이 기능이 수익 모델과 어떻게 연결되는가

제약을 모르고 설계하면 구현 불가능한 UI가 나와요.

5단계 — 우선순위 붙이기

모든 요구사항이 동등하게 중요하지 않아요.
MoSCoW 방법을 써요.

  • Must Have: 이게 없으면 출시 못 함
  • Should Have: 중요하지만 없어도 출시 가능
  • Could Have: 있으면 좋지만 없어도 됨
  • Won't Have (이번엔): 이번 범위 밖

이 분류가 있으면 일정이 촉박할 때 무엇을 먼저 줄일지 기준이 생겨요.

요구사항 문서의 형태

요구사항 문서가 꼭 긴 Word 파일일 필요 없어요.
팀 규모와 프로젝트 복잡도에 따라 달라요.

소규모 팀: Notion 페이지 하나에 User Story + In/Out Scope + 성공 기준을 정리해요.

중규모 프로젝트: PRD(Product Requirements Document).
배경, 목표, 사용자, 기능 목록, 성공 기준, 타임라인이 들어가요.

살아있는 문서예요.
리서치 결과가 바뀌면 요구사항도 업데이트돼요.

하지 말아야 할 것

기능 목록을 요구사항이라고 착각하지 마세요: "로그인 버튼, 비밀번호 찾기, 소셜 로그인" — 이건 기능 목록이에요.
왜 이게 필요한지, 어떤 사용자가 어떤 목적으로 쓰는지가 없어요.

모든 것을 Must Have로 만들지 마세요: 전부 Must Have이면 우선순위가 없는 거예요.
진짜 Must Have는 3~5개 이내여야 해요.

요구사항 없이 개발을 시작하지 마세요: "가면서 정하면 되지"는 개발 중 방향이 계속 바뀌는 결과를 낳아요.

실행 후 확인하기

  • User Story 형식으로 사용자 목표가 정의됐나요?
  • In Scope / Out Scope가 명확히 구분됐나요?
  • 성공 기준이 측정 가능한가요?
  • 기술적, 법적, 비즈니스 제약이 파악됐나요?
  • 팀 전체가 이 문서를 보고 같은 것을 생각하고 있나요?

관련 아티클

참고 문헌

  • Dan Olsen, 《The Lean Product Playbook》(2015) — 제품 요구사항을 사용자 목표와 연결하는 방법론이에요. Product-Market Fit 피라미드가 요구사항 정의에 유용해요.