앱 제작 의뢰서에 개발 언어부터 적을 필요는 없다. 누가, 무엇을 넣고, 어떤 결과를 받아야 하는지를 실제 업무 순서로 설명하면 된다. 기술을 모른다는 이유로 원하는 결과까지 모호하게 남겨둘 필요는 없다.
예를 들어 학원에서 상담 신청을 받고 싶다면 “예약 시스템”이라고만 적기보다 “학부모가 희망 시간을 고르면 담당자가 가능 여부를 확인해 연락한다”라고 쓰는 편이 낫다. 자동 확정인지 담당자 확인 뒤 확정인지도 이 문장에서 드러난다.

목차
평소에 하던 일을 순서대로 적는다
현재 전화·메신저·엑셀로 처리하는 과정을 먼저 쓴다. 이 중 어떤 단계를 앱으로 옮길지 표시한다. 지금도 사람마다 판단이 다른 일은 앱 화면을 만들기 전에 규칙을 정해야 한다.
| 질문 | 상담 신청의 가상 예시 |
|---|---|
| 쓰는 사람 | 신청자와 담당자 |
| 입력 | 희망 날짜, 상담 주제 |
| 처리 | 담당자가 가능한 시간인지 확인 |
| 결과 | 신청 상태를 확인하고 연락 |
| 예외 | 같은 시간에 두 명이 신청 |
이 표를 채운 다음에는 각 결과를 눈으로 확인할 수 있는 완료 조건으로 바꾼다. Atlassian은 완료 조건을 기능이 받아들여지기 전에 충족해야 할 명확하고 검증 가능한 조건으로 설명한다.
정상 예제와 곤란한 예제를 하나씩 준비한다
완벽한 기획서보다 입력 두 개가 더 구체적일 때가 있다. 정상 신청 하나와 일정이 겹친 신청 하나를 적어보면 좋다. 개발자는 이 둘을 어떻게 처리할지 묻고, 의뢰인은 실제 업무에서 쓰는 판단을 설명할 수 있다.
화면 참고 자료에는 마음에 드는 이유도 적는다. “이 사이트처럼”보다 “휴대폰에서 날짜를 먼저 고르는 순서가 좋다”가 작업 범위를 분명하게 한다. 참고 사이트의 이미지·문구를 그대로 사용할 권리가 있다는 뜻은 아니다.
처음 버전에서 하지 않을 일도 적는다
결제, 회원 등급, 문자 자동 발송을 나중으로 미룬다면 의뢰서에 남긴다. 빠진 기능으로 오해하지 않게 하고, 지금 결정할 질문을 줄일 수 있다. 미룬 기능이 향후 구조에 영향을 줄 수 있는지는 상담 때 확인한다.
의뢰서의 목적은 전문가처럼 말하는 것이 아니다. 서로 같은 사용 장면을 보고 있는지 확인하는 데 있다.
작성 완료 예시는 이렇게 쓴다
상담 신청 앱을 가정해 한 번 완성해보자. 실제 고객 사례가 아니라 양식을 채우는 방법을 보여주기 위한 예시다.
- 쓰는 사람 상담을 신청하는 학부모와 신청 내역을 확인하는 담당자
- 현재 순서 전화나 메신저로 희망 시간을 받고 담당자가 일정표를 확인해 회신한다.
- 앱으로 바꿀 단계 이름, 연락처, 상담 주제, 희망 시간을 받고 담당자가 확인 상태를 바꾼다.
- 정상 입력 9월 21일 오후 3시, 필수 연락처와 상담 주제가 모두 입력된 신청
- 곤란한 입력 같은 시간에 이미 신청이 있거나 연락처가 비어 있는 신청
- 기대 결과 신청자에게
접수됐으며 확정 전이 보이고 담당자 목록에는 같은 신청과확인 대기상태가 생긴다. - 첫 버전 제외 자동 문자, 온라인 결제, 회원 등급, 자동 확정
완료 조건은 “잘 작동한다”보다 확인 가능하게 쓴다. 필수 항목이 비면 제출을 막고, 중복 시간은 담당자 확인 대기로 표시한다. 정상 제출 뒤 신청자에게는 접수됐으며 확정 전, 담당자에게는 확인 대기가 보여야 한다.
견적과 인계에 필요한 범위도 적는다
기능 흐름만으로는 견적과 납품 범위를 맞추기 어렵다. 아래 조건은 모르는 값을 억지로 확정하지 말고, 현재 아는 범위와 업체와 협의할 항목을 구분해 적는다.
- 대상 환경 휴대폰 웹인지 앱스토어 앱인지, 지원할 운영체제와 브라우저
- 접근 범위 신청자 로그인 여부, 담당자 화면과 관리자 권한
- 데이터 저장할 항목, 보관 기간, 삭제 방법, 개인정보 접근 주체
- 외부 연동 결제, 문자, 지도, 기존 회원·예약 시스템 연결 여부
- 예산·일정 가능한 예산 범위, 반드시 필요한 날짜, 조정 가능한 항목
- 납품·유지보수 소스 파일, 배포 계정 소유자, 사용 설명, 수정 요청 범위와 기간
예산이나 일정을 모른다고 빈칸을 숨길 필요는 없다. 범위 확인 뒤 협의라고 적으면 업체가 질문해야 할 지점이 드러난다. 외주 견적 비교 항목과 함께 보면 포함·제외 조건을 맞추기 쉽다.
빈 양식에 내 업무를 옮긴다
아래 항목을 메모장에 복사한 뒤 한 줄씩 채우면 된다. 실제 개인정보 대신 형식만 같은 가상 값을 먼저 넣어 흐름을 확인한다.
이 앱을 쓰는 사람:
지금 업무 순서:
앱으로 바꿀 단계:
정상 입력 예제:
곤란한 입력 예제:
기대 결과:
참고 화면에서 원하는 부분:
첫 버전에서 제외할 일:
대상 기기·운영체제:
로그인·관리자 기능:
저장할 데이터와 보관 조건:
외부 서비스 연동:
예산 범위와 희망 일정:
받을 파일·계정·설명서와 유지보수 범위:
완료 조건:
견적을 받기 전에는 정상 입력과 곤란한 입력을 각각 한 번 따라가며 빠진 결과를 찾는다. 결제, 개인정보, 외부 시스템 연동처럼 실패 비용이 큰 기능은 이 양식만으로 확정하지 말고 보안과 운영 조건을 별도로 확인해야 한다.
다음 행동
바로 위 빈 양식을 메모장에 복사해 자신의 업무 한 가지로 바꿔본다. 같은 값의 처리 규칙을 더 보고 싶다면 CSV 중복 정리 실습의 요구사항 부분을 함께 확인할 수 있다.
앱 제작 의뢰서에서 자주 막히는 질문
화면을 모두 그려야 하나요?
모든 화면을 완성할 필요는 없다. 사용자가 처음 넣는 정보와 마지막에 확인할 결과, 중간에 사람이 판단할 지점을 순서대로 적으면 된다.
개발 언어를 정해서 보내야 하나요?
특정 기술이 필수인 이유를 모른다면 원하는 결과와 운영 조건부터 전달한다. 기존 시스템 연동처럼 기술 제약이 확인된 경우에는 사용 중인 서비스와 접근 범위를 별도 항목으로 적는다.
검증 기준
- 마지막 업데이트일: 2026-09-14
- 확인 환경: 공개 요구사항 작성 가이드와 자체 실습 자료를 대조한 설명형 글. 상담 신청은 가상 예시이며 고객 납품 실적이나 실행 성과가 아닙니다.
- 주요 근거: Atlassian의 완료 조건 가이드, Atlassian의 사용자 스토리 가이드
직접 만든 실습 자료와 새 도구 소식
AI 도구로 만든 실습 자료, 달라진 기능과 강의 소식을 준비하고 있습니다. 발송을 시작하면 안내해 드려요. 먼저 확인 메일에서 본인 이메일을 확인해 주세요.
신청하기 전에 첫 소식 미리보기에서 내용과 자료를 확인해 보세요.