앱·웹 개발 요구사항은 어떻게 정리하나요? 화면 목록으로 부족한 이유

요구사항 문서에는 무엇이 들어가나요?

화면 목록이 아니라 다섯 가지입니다. 사용자가 거치는 흐름, 각 건이 가질 수 있는 상태, 흐름이 어긋났을 때의 예외, 주고받는 데이터 항목, 그리고 무엇이 되면 끝난 것으로 볼지의 완료 조건입니다. 화면 목록만 넘기면 개발사는 화면을 그릴 수 있지만 그 화면이 언제 무엇을 보여 줘야 하는지는 모릅니다.

이 다섯 가지 중에서 가장 많이 빠지는 것이 상태와 예외입니다. 그리고 개발 중에 범위가 늘어나는 원인도 대부분 이 두 칸에서 나옵니다. 나중에 묻기 때문에 늘어나는 것이 아니라, 묻는 시점에 이미 화면이 만들어져 있어서 고치는 비용이 붙습니다.

쓰기 전에 모아야 하는 자료

요구사항은 새로 발명하는 문서가 아니라 지금 하고 있는 일을 옮겨 적는 문서입니다. 아래 자료가 있으면 작성 속도가 크게 달라집니다.

• 지금 그 업무를 처리하는 엑셀 파일이나 수첩, 카카오톡 대화 캡처
• 실제로 받은 신청·문의 20~30건. 비정상 건이 섞여 있어야 예외를 적을 수 있습니다.
• 업무를 처리하는 담당자와, 결정을 내리는 사람의 구분
• 외부에 이미 약속한 조건. 환불 기한, 응답 시간, 계약서에 적힌 항목이 여기에 들어갑니다.

특히 비정상 건을 모으는 일이 중요합니다. 정상적으로 끝난 신청만 보면 상태가 두세 개로 보이지만, 중간에 멈춘 건과 되돌린 건을 섞어 보면 상태가 다섯 개 이상으로 늘어납니다. 그 늘어난 목록이 그대로 요구사항이 됩니다.

자료를 모으는 사람과 쓰는 사람은 같아도 되지만, 완료 조건을 정하는 사람은 그 업무의 결과에 책임이 있는 사람이어야 합니다. 이 구분이 없으면 완료 조건이 "잘 되면 된다"로 적힙니다.

채워 본 요구사항 한 장 — 온라인 수강 신청

기능 하나에 아래 다섯 칸을 채웁니다. 기능이 열 개면 같은 표가 열 장 나옵니다.

칸	적는 내용	채운 예
사용자 흐름	행동 순서	강좌 선택 → 신청서 작성 → 결제 → 신청 완료 안내
상태	한 건이 가질 수 있는 값	작성 중, 결제 대기, 신청 완료, 취소, 대기자
예외	흐름이 어긋나는 경우	정원 초과, 결제 실패, 중복 신청, 개강 후 취소
데이터	항목과 보관 기간	이름·연락처·강좌·결제내역, 환불 기한까지 보관
완료 조건	무엇이 되면 끝인가	정원 집계와 결제 내역이 어긋나는 건이 0

완료 조건은 기능이 "동작한다"가 아니라 숫자나 상태로 적어야 검수할 수 있습니다. 위 예에서는 정원 집계와 결제 내역을 대조해 어긋난 건이 없는지로 확인합니다. 이 한 줄이 있으면 검수 때 무엇을 열어 볼지 정해집니다.

상태와 예외를 비워 두면 생기는 일

상태를 적지 않으면 화면은 만들어지지만 운영이 안 됩니다. 정원 초과를 대기자로 받을지 그냥 막을지 정하지 않으면, 개발사는 막는 쪽으로 만들고 운영자는 전화로 대기자를 받기 시작합니다. 그러면 신청자 수와 실제 수강생 수가 처음부터 어긋납니다.

데이터 칸도 같은 이유로 중요합니다. 어떤 항목을 받는지만 적고 언제까지 보관할지 적지 않으면, 1년 뒤 운영자는 지난 수강생 연락처를 지워도 되는지 판단할 수 없습니다. 보관 기간은 환불 기한, 세무 자료, 민원 대응 같은 실제 필요에서 나오므로 기획 단계에서 정할 수 있습니다.

예외를 적지 않으면 실패한 건이 어디에도 남지 않습니다. 결제 실패 건이 상태로 남지 않으면 운영자는 결제가 안 된 신청자에게 연락할 목록을 만들 수 없습니다. 예외를 적는 일은 기능을 늘리는 일이 아니라, 이미 일어나고 있는 일을 화면에 보이게 하는 일입니다.

우리가 정하지 않아도 따라오는 요구사항

아래는 서비스 기획과 무관하게 조건이 먼저 정해져 있는 항목입니다. 요구사항 문서에 처음부터 적어 두면 출시 직전에 일정이 밀리는 일을 줄일 수 있습니다.

이름과 연락처를 받는 기능이 하나라도 있으면 개인정보 처리방침을 정해 공개해야 합니다. 개인정보 보호법 제30조는 처리 목적, 보유 기간, 제3자 제공, 파기 절차, 권리 행사 방법, 개인정보 보호책임자의 연락처 등을 처리방침에 담도록 정하고 있습니다. 즉 "어떤 항목을 받는지"는 기획 단계에서 정해야 하는 값이고, 개발 막바지에 문구만 붙여 끝낼 수 있는 항목이 아닙니다.

앱이라면 스토어 요건이 완료 조건에 들어갑니다. 구글은 2026년 8월 31일부터 새 앱과 업데이트가 안드로이드 16(API 수준 36) 이상을 대상으로 해야 제출할 수 있고, 기존 앱은 대상 수준이 안드로이드 15(API 수준 35) 미만이면 그보다 높은 버전을 쓰는 기기의 신규 사용자에게 노출되지 않는다고 안내합니다. 연장은 2026년 11월 1일까지 신청할 수 있습니다. 이런 날짜는 협의 대상이 아니므로 일정표에 먼저 올려 둡니다.

개발사에 넘기기 전에 확인할 한 가지

기능 목록에서 아무 기능이나 하나 골라, 위 다섯 칸이 모두 채워지는지 확인해 보시기 바랍니다. 상태 칸에 값이 두 개만 적힌다면 아직 업무를 옮겨 적지 않은 것입니다. 실제 신청 건 스무 개를 펼쳐 놓고 각 건이 어느 상태였는지 적어 보면 빠진 상태와 예외가 함께 드러납니다. 이 작업을 먼저 하면 견적의 범위도 같이 좁혀집니다.