“로그인, 게시판, 결제 기능이 필요합니다. 견적이 어떻게 될까요?” 웹·앱 개발 상담에서 가장 자주 받는 질문입니다. 기능 이름을 들으면 대략적인 그림은 떠오르지만, 그 정보만으로 정확한 견적을 내기는 어렵습니다.
같은 ‘로그인’도 이메일 하나로 가입하는 서비스와, 회사 계정으로만 접속하고 승인받은 사람에게 서로 다른 메뉴를 보여 주는 서비스는 전혀 다른 일입니다. 같은 ‘결제’도 한 번 결제하고 끝나는 경우와 취소·부분 환불·세금계산서·정산까지 이어지는 경우의 범위는 크게 달라집니다.
견적이 나중에 흔들리는 이유는 개발사가 기능을 몰라서가 아니라, 기능 뒤에 숨어 있는 운영 방식이 처음에 빠져 있기 때문인 경우가 많습니다.
기능 이름은 시작점일 뿐이다
기능 목록은 “무엇을 만들까”를 알려 줍니다. 하지만 개발 범위를 정하려면 그 기능이 실제로 어떻게 쓰이는지까지 알아야 합니다. 아래 다섯 가지를 함께 정리하면 대부분의 빈칸이 드러납니다.
- 누가 쓰는가: 사용자 종류와 각 역할이 할 수 있는 일
- 무엇을 다루는가: 입력·조회·수정해야 하는 데이터
- 어디와 연결되는가: 기존 시스템, 결제, 문자, 지도, 파일 저장소 같은 외부 연동
- 예외가 생기면 어떻게 하는가: 취소, 반려, 중복, 누락, 오류에 대한 처리
- 출시 후 누가 운영하는가: 관리자 화면, 권한, 알림, 로그, 유지보수 방식
첫 번째 질문: 사용자는 한 종류인가
사용자를 “회원” 하나로만 적으면 필요한 화면과 권한을 놓치기 쉽습니다. 서비스에 따라 고객, 운영자, 관리자, 협력사, 승인자처럼 여러 역할이 존재합니다.
예를 들어 예약 서비스에서 고객은 예약을 만들고 취소할 수 있습니다. 담당자는 자신의 일정만 관리하고, 관리자는 모든 예약을 조정하며, 정산 담당자는 금액 정보만 봐야 할 수 있습니다. 이 차이는 메뉴 하나를 추가하는 문제가 아니라 데이터 접근 권한과 업무 흐름 전체에 영향을 줍니다.
그래서 기능을 적을 때는 “예약 관리”보다 “고객은 본인 예약만, 담당자는 배정된 예약만, 관리자는 전체 예약을 수정한다”처럼 역할별로 적는 편이 정확합니다.
두 번째 질문: 이미 있는 데이터는 어디에 있는가
새 시스템이 모든 데이터를 처음부터 입력받는지, 엑셀 파일이나 기존 프로그램의 정보를 가져와야 하는지에 따라 작업이 달라집니다. 기존 데이터가 있다면 다음을 먼저 확인해야 합니다.
- 어떤 형식으로 보관되어 있는가: 엑셀, 데이터베이스, 외부 서비스 등
- 누가 최신 정보를 수정하는가
- 새 시스템과 기존 시스템 중 어느 쪽이 기준이 되는가
- 같은 고객이나 상품이 중복되면 어떻게 판단하는가
“엑셀을 업로드하면 됩니다”라는 말도 세부 조건이 필요합니다. 열 이름이 매번 같은지, 잘못된 형식의 행은 어떻게 표시할지, 이미 등록된 정보는 덮어쓸지 추가할지까지 정해야 실제 운영에서 문제가 생기지 않습니다.
세 번째 질문: 외부 연동은 화면 하나가 아니다
결제, 문자 발송, 지도, 배송, 사내 ERP 연동은 사용자가 보기에는 버튼 하나처럼 보입니다. 하지만 개발 범위에는 인증 정보 관리, 요청 실패 처리, 재시도, 상태 확인, 개인정보 보호가 함께 들어갑니다.
외부 연동은 “연결된다”가 끝이 아닙니다. 연결이 늦거나 실패했을 때 사용자가 무엇을 보고, 운영자가 어떻게 다시 처리할지도 기능입니다.
예를 들어 결제 요청은 성공했는데 우리 서비스 화면이 멈췄다면, 돈은 결제됐는지 확인하고 주문 상태를 맞춰야 합니다. 이런 경우를 미리 정리하지 않으면 출시 직전에 별도 작업이 생기거나, 운영자가 수작업으로 맞추게 됩니다.
네 번째 질문: 정상 흐름 밖에서는 무엇이 일어나는가
기획 문서는 보통 가장 자연스러운 흐름을 중심으로 작성됩니다. 회원이 가입하고, 상품을 고르고, 결제하고, 완료하는 흐름입니다. 실제 서비스에서는 정상 흐름 밖의 일이 더 자주 문제를 만듭니다.
- 동시에 마지막 상품을 두 명이 주문하면 어떻게 되는가
- 담당자가 승인하기 전에 사용자가 취소하면 어떻게 되는가
- 필수 파일이 누락되거나 형식이 맞지 않으면 어떻게 안내하는가
- 권한이 없는 사용자가 주소를 직접 열면 어떻게 되는가
- 알림 발송에 실패했을 때 다시 보낼 방법이 있는가
이 질문에 모두 완벽한 답이 있어야만 시작할 수 있는 것은 아닙니다. 다만 답이 정해지지 않은 항목은 견적과 일정의 가정으로 남겨야 합니다. 그래야 나중에 새 요구가 생겼을 때 처음 약속한 범위와 구분할 수 있습니다.
다섯 번째 질문: 출시 후에는 누가 무엇을 하는가
관리자 화면은 마지막에 덧붙이는 부속 기능이 아닙니다. 운영자가 직접 처리해야 하는 일이 있다면 그 일을 위한 화면과 기록이 필요합니다.
운영 준비에는 보통 다음이 포함됩니다.
- 회원, 게시물, 주문 같은 데이터를 검색하고 수정하는 방법
- 관리자와 일반 사용자의 권한을 구분하는 방법
- 오류와 변경 이력을 확인하는 방법
- 알림을 받는 사람과 재전송하는 방법
- 개인정보를 보관하고 삭제하는 기준
출시 뒤에도 개발자에게 매번 요청해야만 정보를 수정할 수 있다면, 처음에는 저렴해 보여도 운영 비용이 계속 쌓입니다. 반대로 모든 항목을 관리 화면에서 바꾸게 만들면 처음 범위가 불필요하게 커질 수 있습니다. 자주 바뀌고 운영자가 책임져야 하는 항목부터 고르는 것이 좋습니다.
견적을 요청하기 전에 적어 두면 좋은 한 장
복잡한 요구사항 문서를 만들 필요는 없습니다. 아래 정도를 한 장에 정리해도 상담의 밀도가 달라집니다.
- 목적: 이 서비스가 해결할 문제를 한 문장으로 적습니다.
- 사용자: 역할별로 할 수 있는 일과 볼 수 있는 정보를 적습니다.
- 핵심 흐름: 사용자가 처음 들어와 목표를 이루기까지의 순서를 적습니다.
- 외부 연동: 이미 쓰는 시스템과 새로 연결할 서비스를 적습니다.
- 예외: 취소·반려·오류처럼 꼭 대비해야 할 세 가지를 적습니다.
- 우선순위: 첫 출시에서 반드시 필요한 것과 다음 단계로 미룰 것을 나눕니다.
정리
개발 견적은 기능 이름의 개수를 세는 작업이 아닙니다. 누가 어떤 데이터를 어떤 규칙으로 다루고, 문제가 생겼을 때 어떻게 운영할지를 함께 이해하는 과정입니다.
처음부터 모든 세부 사항을 확정할 수는 없습니다. 대신 정해진 것, 가정인 것, 다음 단계로 미룬 것을 구분해 두면 견적과 일정은 훨씬 투명해집니다. 좋은 개발 프로젝트는 완벽한 기능 목록보다, 서로 같은 그림을 보고 시작하는 데서 만들어집니다.
