개발사를 알아보기 시작하면 꼭 듣는 말이 있습니다. "요구사항을 정리해서 보내주세요."
그래서 검색을 합니다. 앱 기획서 작성법, 요구사항 정의서 양식 같은 단어가 나오고, 템플릿도 몇 개 찾을 수 있어요. 그런데 막상 열어보면 빈칸이 뭘 묻는 건지부터 막힙니다. 기능 요구사항, 비기능 요구사항, 인터페이스 정의, 데이터 항목… 한 줄도 채우기 전에 탭을 닫게 되거든요.
아마 이 글을 읽고 계신 분도 비슷한 경험을 하셨을 거예요. 머릿속에는 분명히 있습니다. 이 서비스가 어떻게 돌아가는지, 사용자가 들어오면 뭘 하게 되는지, 대략적인 그림은 다 그려져 있어요. 다만 그걸 개발사가 이해할 수 있는 형태로 옮기는 방법을 모르는 겁니다.
그래서 이 글에서는, 앱 외주를 준비하는 분이 개발사에 전달할 내용을 어떤 방식으로 정리하면 되는지를 다뤄보겠습니다.
기능 목록부터 쓰면 안 되는 이유
요구사항을 정리하라는 말을 들으면, 대부분 기능 목록부터 적기 시작합니다. 회원가입, 로그인, 마이페이지, 결제, 알림, 관리자 페이지… 떠오르는 대로 나열하는 거예요.
자연스러운 출발점처럼 보이지만, 여기서 시작하면 두 가지 문제가 생깁니다.
하나는 빠지는 게 생긴다는 겁니다. 기능을 개별로 나열하면 "이 기능과 저 기능 사이에서 사용자가 어떻게 이동하는지"가 빠져요. 회원가입 다음에 뭘 보여줄 건지, 결제 전에 어떤 정보를 확인시킬 건지, 이런 연결 지점이 기능 목록에는 안 담기거든요. 나중에 개발사가 "이 부분은 어떻게 할까요?"라고 물어오면, 그때서야 생각하지 못한 부분이 드러납니다.
다른 하나는 우선순위를 정할 수 없다는 겁니다. 기능이 스무 개쯤 나열되면, 어떤 걸 먼저 만들어야 하는지 판단하기가 어려워요. 전부 다 중요해 보이거든요. 결국 "다 넣어주세요"가 되고, 견적은 올라가고, 일정은 늘어납니다. 이게 개발 외주에서 범위가 끝없이 커지는 가장 흔한 원인이에요.
요구사항 정리, 기능이 아니라 시나리오부터 쓰세요
접근 방식을 바꿔보면 훨씬 수월해집니다. 기능을 나열하는 대신, 사용자가 이 서비스를 처음 만나는 순간부터 목적을 달성하는 순간까지의 흐름을 써보는 겁니다.
예를 들어볼게요. 과외 매칭 플랫폼을 만든다고 가정하면 이런 식입니다.
학부모가 검색으로 우리 사이트에 들어옵니다. 첫 화면에서 과목과 지역을 선택하면, 조건에 맞는 선생님 목록이 나옵니다. 프로필을 눌러서 경력과 수업 방식을 확인하고, 마음에 드는 선생님에게 상담을 신청합니다. 상담 신청이 들어가면 선생님한테 알림이 가고, 선생님이 수락하면 양쪽에 연락처가 공유됩니다.
이렇게 쓰면 자연스럽게 드러나는 게 있습니다. 검색 필터가 필요하고, 선생님 프로필 페이지가 필요하고, 상담 신청과 알림 기능이 필요하다는 것까지 시나리오 안에서 기능이 스스로 나타나요. 기능 목록을 억지로 짜내는 게 아니라, 사용자 흐름을 따라가다 보면 빠뜨릴 게 없어지는 거예요.
그리고 우선순위도 분명해집니다. 시나리오에서 핵심 흐름은 "검색 → 프로필 확인 → 상담 신청"이에요. 이 세 단계가 매끄럽게 돌아가면 서비스의 핵심 가치는 전달됩니다. 리뷰 기능이나 결제 시스템은 그 다음에 붙여도 되거든요. 사용자 시나리오를 먼저 쓰면 "뭘 먼저 만들어야 하는지"가 자연스럽게 보입니다.
기획서에 담을 때, 이 세 가지만 챙기세요
시나리오를 쓴다고 해서 소설처럼 길게 쓸 필요는 없습니다. 다만 세 가지만 챙기면 개발사에 전달했을 때 훨씬 정확하게 소통됩니다.
같은 서비스라도 사용자 유형이 다르면 흐름이 달라져요. 과외 매칭 플랫폼이라면 학부모와 선생님, 두 사용자가 각각 다른 시나리오를 갖습니다. 한쪽만 써놓으면 다른 쪽 흐름에서 빈 곳이 생기거든요. 사용자 유형별로 시나리오를 분리해서 쓰는 게 좋습니다.
"프로필을 본다"보다는 "프로필에서 경력, 수업 방식, 수강 후기를 확인한다"가 개발사에 더 명확하게 전달돼요. 이게 나중에 화면 설계의 기초가 됩니다. 사용자가 보는 정보와 하는 행동을 구분해서 적어두면, 개발사 입장에서 화면을 구성하기가 훨씬 쉬워지거든요.
"상담 신청을 했는데 선생님이 48시간 안에 응답하지 않으면 어떻게 되나요?" 같은 거예요. 모든 예외를 다 적을 필요는 없습니다. 다만 핵심 흐름에서 벗어나는 상황을 한두 개만 적어두면, 개발사가 "아, 이 부분도 고려하고 있구나"라는 걸 알 수 있어요. 나머지 예외는 설계 단계에서 함께 정리하면 됩니다.
요구사항 정리 방법 비교
연결이 안 보임, 우선순위 불명확
빠진 기능이 드러남, 우선순위가 보임
그런데 시나리오에서 기능을 뽑아내는 건 또 다른 문제입니다
여기까지 읽고 나면 시나리오를 한번 써볼 수 있을 거예요. 사용자가 들어와서 뭘 하고, 어디로 가고, 최종적으로 뭘 달성하는지를 흐름으로 정리하는 건 생각보다 어렵지 않습니다.
그런데 그 다음 단계에서 다시 막히는 분이 많습니다. 시나리오는 썼는데, 이걸 개발사가 바로 가져다 쓸 수 있는 형태로 바꾸려면 또 다른 작업이 필요하거든요. 시나리오 속에서 기능을 분리해내야 합니다. 화면 단위로 묶어야 하고, 데이터가 어디서 어디로 흐르는지도 정리해야 해요. 이 과정은 서비스 설계 경험이 있어야 수월하게 할 수 있는 영역이에요.
이걸 혼자 완벽하게 해내려고 하면 시간이 오래 걸리고, 결국 "이게 맞나?" 싶은 불안이 계속 따라옵니다.
흐름소프트에서 프로젝트 초기 미팅을 할 때, 요구사항 정의서를 받는 것보다 이야기를 먼저 듣는 이유가 이겁니다. "이 서비스에서 사용자가 어떤 경험을 하게 되나요?"라는 질문으로 시작해서, 대화를 나누다 보면 시나리오가 잡혀요. 거기서 기능을 분리하고, 우선순위를 정하고, 빠진 부분을 채우는 건 저희가 함께하거든요. 완벽한 기획서를 가져오지 않아도 괜찮습니다. 머릿속에 있는 그림을 말로 설명해주시면, 그걸 개발 가능한 형태로 바꾸는 과정은 같이 할 수 있습니다.
정리하면 이렇습니다
개발사에 기획서를 전달할 때, 기능 목록부터 쓰려고 하면 막힙니다. 대신 사용자가 서비스를 처음 만나는 순간부터 목적을 달성하는 순간까지의 흐름을 시나리오로 써보세요. 시나리오 안에서 필요한 기능이 자연스럽게 드러나고, 우선순위도 보이게 됩니다.
사용자 유형별로 나누고, 각 단계에서 뭘 보고 뭘 하는지를 구체적으로 적고, 핵심 예외 상황을 한두 개만 메모해두면 충분합니다. 거기서부터 기능을 뽑아내고 화면 단위로 정리하는 건, 경험 있는 파트너와 함께하는 게 훨씬 빠르고 정확합니다.
