아이디어를 요구사항으로 — 개발 전 준비 가이드

왜 기획 단계가 비용을 좌우하나

소프트웨어에서 ‘수정’의 비용은 단계마다 크게 달라집니다. 기획 문서에서 문장 한 줄을 고치는 데는 몇 분이면 됩니다. 디자인이 끝난 뒤 화면 구조를 바꾸면 디자인과 개발을 함께 손봐야 합니다. 개발이 절반쯤 진행된 상태에서 데이터 구조를 바꾸면, 이미 만들어 둔 화면과 서버 로직을 연쇄적으로 다시 만들어야 합니다. 같은 ‘한 가지 변경’이라도 뒤로 갈수록 몇 배의 시간이 드는 이유입니다.

견적의 정확도도 기획의 구체성에 달려 있습니다. 요구사항이 모호하면 개발사는 두 가지 중 하나를 택합니다. 불확실성을 감안해 여유분을 얹은 높은 금액을 제시하거나, 일단 낮게 잡고 나중에 추가 비용을 협의하는 방식입니다. 어느 쪽도 발주자에게 유리하지 않습니다. 반대로 요구사항이 구체적이면 개발사는 실제 작업량에 가깝게 계산할 수 있고, 여러 업체의 견적을 같은 기준으로 비교할 수 있게 됩니다.

예를 들어 제안서에 ‘회원가입 기능’이라고만 적혀 있다고 해 봅니다. 이메일 가입만 있는지, 카카오나 구글 같은 소셜 로그인을 붙이는지, 휴대폰 본인인증이 필요한지, 약관 동의 항목을 관리자가 수정할 수 있어야 하는지에 따라 작업량은 몇 배까지 차이가 납니다. 기획은 이 차이를 미리 드러내는 작업입니다.

아이디어와 요구사항은 다릅니다

아이디어는 ‘누구의 어떤 불편을 어떻게 해결할 것인가’에 대한 답입니다. 요구사항은 ‘그러기 위해 시스템이 무엇을 해야 하는가’를 문장으로 적은 것입니다. 아이디어는 설레는 문장이어도 되지만, 요구사항은 지루하고 검증 가능한 문장이어야 합니다.

검증 가능하다는 것은, 다 만들었을 때 ‘됐다 / 안 됐다’를 예와 아니오로 답할 수 있다는 뜻입니다. 아래 두 문장을 비교해 보시면 차이가 분명합니다.

• 모호한 문장 — 사용자가 편리하게 예약할 수 있어야 한다.
• 검증 가능한 문장 — 사용자는 날짜와 시간을 선택하고 예약 버튼을 누르면 예약이 저장되며, 등록한 이메일로 예약 확인 메일을 받는다. 이미 마감된 시간대는 선택할 수 없다.

두 번째 문장에는 화면에서 하는 행동, 저장되는 데이터, 시스템이 자동으로 하는 일, 막아야 하는 예외 상황이 모두 들어 있습니다. 개발팀은 이런 문장 하나에서 화면 요소, 데이터베이스 항목, 메일 발송 연동, 중복 방지 로직을 각각 추정합니다. 문서를 잘 쓸 필요는 없습니다. 이 정도 수준의 문장을 기능별로 몇 줄씩 적어 두는 것만으로도 대화의 질이 달라집니다.

화면 단위로 생각하기

기능 목록만으로는 작업량이 잘 보이지 않습니다. 같은 기능이라도 화면 하나로 끝나는지, 다섯 화면을 거쳐야 하는지에 따라 만드는 양이 달라지기 때문입니다. 그래서 기획을 처음 정리할 때는 기능이 아니라 화면 단위로 접근하는 편이 훨씬 수월합니다.

화면 목록 만들기

사용자가 서비스를 처음 열어서 목적을 이룰 때까지 거치는 화면을 순서대로 적어 봅니다. 예약 서비스라면 이런 식이 됩니다. 시작 화면, 로그인 및 회원가입, 매장 목록, 매장 상세, 날짜와 시간 선택, 예약 확인, 예약 완료, 내 예약 목록, 예약 상세 및 취소, 마이페이지. 여기까지가 사용자 쪽 화면입니다.

여기서 많은 분들이 빠뜨리는 것이 관리자 화면입니다. 예약을 확인하고 승인하거나 거절하는 화면, 영업시간과 휴무일을 설정하는 화면, 매장 정보를 수정하는 화면, 통계를 보는 화면이 필요합니다. 관리자 영역은 사용자 화면만큼, 때로는 그 이상의 작업량을 차지합니다. 견적이 예상보다 높게 나오는 이유의 상당 부분이 여기에 있습니다.

화면별 할 수 있는 일 적기

화면 목록이 나왔다면 각 화면 아래에 세 가지를 적습니다. 그 화면에서 보이는 정보, 사용자가 할 수 있는 행동, 그 행동의 결과로 이동하는 화면입니다. 매장 상세 화면이라면 매장 이름과 사진과 영업시간이 보이고, 찜하기와 예약하기를 할 수 있으며, 예약하기를 누르면 날짜 선택 화면으로 넘어간다는 식입니다.

여유가 있다면 정상적인 흐름 외에 세 가지 상태를 추가로 정의해 두시면 좋습니다. 데이터가 하나도 없을 때 보여 줄 화면, 통신이 느려 기다릴 때 보여 줄 화면, 오류가 났을 때 보여 줄 안내 문구입니다. 이 세 가지는 기획서에서 빠지기 쉽지만 실제 개발과 테스트에서는 반드시 필요하고, 나중에 정하면 그만큼 작업이 늘어납니다.

기능 우선순위 정하기

화면과 기능을 적어 놓고 보면 대부분 처음 생각보다 양이 많습니다. 이때 필요한 것이 우선순위입니다. 실무에서는 ‘반드시 필요함 / 있으면 좋음 / 나중에’ 세 단계로 나누는 방식이 가장 쉽고 효과적입니다. 업계에서는 이를 조금 더 세분화한 MoSCoW 기법(Must have, Should have, Could have, Won’t have)이라고 부르기도 하는데, 이름은 몰라도 됩니다. 핵심은 모든 기능을 ‘반드시’로 분류하지 않는 것입니다.

분류할 때 유용한 질문이 하나 있습니다. ‘이 기능 없이 첫 번째 고객이 서비스를 끝까지 쓸 수 있는가’입니다. 쓸 수 있다면 반드시 필요한 기능이 아닙니다. 또 하나, 세 단계로 나눈 목록은 개발사와 공유하시는 편이 좋습니다. 예산이 맞지 않을 때 무엇을 덜어낼지 함께 판단할 수 있고, 일정이 밀릴 때도 협의가 훨씬 빨라집니다.

MVP 범위를 잡는 기준

MVP는 최소 기능 제품을 뜻합니다. ‘대충 만든 것’이 아니라, 확인하고 싶은 가정을 확인하기에 충분한 최소 크기라는 의미입니다. 범위를 잡을 때는 다음 기준을 순서대로 적용해 보시면 좋습니다.

• 핵심 여정 하나가 끝까지 되는가 — 사용자가 들어와서 목적을 달성하고 나가는 흐름 하나는 완결되어야 합니다. 기능 열 개가 반쯤 되는 것보다 세 개가 온전히 되는 편이 낫습니다.
• 무엇을 검증하려는가 — 사람들이 실제로 예약을 하는지 보고 싶다면 예약 기능이 핵심이고, 포인트나 등급 제도는 검증 대상이 아닙니다.
• 사람이 대신할 수 있는가 — 초기에는 시스템이 자동화하지 않아도 되는 일이 많습니다. 알림 발송을 담당자가 직접 하거나, 정산을 스프레드시트로 처리해도 하루 몇 건 규모에서는 문제가 없습니다.
• 외부 서비스로 대체 가능한가 — 문의 게시판 대신 카카오 채널, 결제 대신 외부 결제 링크, 통계 대신 무료 분석 도구를 쓰는 식으로 초기 개발량을 줄일 수 있습니다.

범위가 정해지면 대략적인 규모 감각도 잡힙니다. 다만 기간과 비용은 기능 수뿐 아니라 디자인 수준, 연동해야 할 외부 시스템, 검수 방식에 따라 크게 달라지므로 프로젝트마다 다릅니다. 비용과 기간이 어떤 요소로 결정되는지는 웹·앱 개발 비용과 기간은 어떻게 정해지나에서 더 자세히 정리했습니다.

준비하면 좋은 자료

기획 문서 외에도 미리 챙겨 두면 일정이 눈에 띄게 빨라지는 자료들이 있습니다. 특히 발급에 시간이 걸리는 항목은 개발 착수와 동시에 준비를 시작하시는 편이 안전합니다.

• 참고 사이트와 앱 — 3~5개 정도를 고르고, 각각 ‘어떤 점이 마음에 드는지’를 한 줄씩 적어 주세요. ‘전체적으로 이런 느낌’보다 ‘이 화면의 이 배치’가 훨씬 정확하게 전달됩니다.
• 로고와 브랜드 자료 — 로고 원본 파일(ai, svg 등), 사용하는 색상 코드, 서체 이름과 라이선스 범위를 함께 전달해 주세요. 이미지로만 있는 로고는 화면 크기에 따라 흐려질 수 있습니다.
• 콘텐츠 원고 — 서비스 소개 문구, 이용약관과 개인정보처리방침, 상품 설명, 사진과 같은 실제 내용입니다. 개발이 끝났는데 원고가 없어 출시가 미뤄지는 경우가 생각보다 많습니다.
• 계정 정보 — 도메인, 호스팅, 앱스토어 개발자 계정, 결제 대행사(PG) 계약, 소셜 로그인 개발자 키, 알림톡 발송 계정 등입니다. 심사와 서류 처리에 며칠에서 몇 주가 걸리는 항목이 섞여 있습니다.

계정은 가급적 발주자 명의로 직접 개설하시는 편을 권합니다. 나중에 담당 개발사가 바뀌더라도 서비스 소유권을 그대로 유지할 수 있기 때문입니다. 개발팀에는 비밀번호를 그대로 넘기기보다, 각 서비스가 제공하는 팀원 초대나 권한 부여 기능을 이용해 필요한 범위만 열어 주시는 것이 안전합니다.

흔한 함정

완벽한 기획서를 기다리다 시작하지 못함

모든 화면과 예외 상황을 다 정한 뒤에 개발을 시작하겠다는 생각은 대개 실현되지 않습니다. 실제로 화면을 보기 전까지는 무엇이 어색한지 알기 어렵고, 문서만으로 완벽을 추구하다 보면 몇 달이 그냥 지나갑니다. 현실적인 기준은 이렇습니다.핵심 화면과 반드시 필요한 기능이 정리되면 착수하고, 세부 사항은 진행하면서 확정합니다. 대신 무엇이 아직 미확정인지를 목록으로 남겨 두고, 언제까지 정할지 함께 정해 두면 됩니다.

범위가 계속 늘어남

개발이 시작되면 아이디어가 더 잘 떠오릅니다. 문제는 이 추가 요구가 조금씩, 그러나 꾸준히 쌓이면서 일정과 비용을 밀어낸다는 점입니다. ‘버튼 하나 추가’처럼 보이는 요청도 데이터 구조나 권한 처리에 영향을 주면 며칠짜리 작업이 되기도 합니다.

해결책은 요구를 막는 것이 아니라 관리하는 것입니다. 추가 요청은 별도 목록에 모아 두고, 정기 회의에서 ‘지금 넣을 것 / 다음 단계로 미룰 것’을 함께 정합니다. 지금 넣기로 했다면 무엇을 대신 빼거나, 일정과 비용을 얼마나 조정할지 그 자리에서 정리합니다. 이런 변경 절차를 계약서에 미리 적어 두면 분쟁이 크게 줄어듭니다. 관련 내용은 개발 외주 계약 전 확인할 것들에서 이어서 다룹니다.

디자인부터 확정하려 함

예쁜 화면 시안이 먼저 나오면 안심이 되지만, 기능이 정해지지 않은 상태의 디자인은 대부분 다시 그리게 됩니다. 무엇을 만들지가 먼저이고, 어떻게 보일지가 그다음입니다. 마찬가지로 경쟁 서비스의 기능을 전부 따라 만드는 것도 피하시는 편이 좋습니다. 그 서비스가 수년에 걸쳐 붙인 기능을 처음부터 담으면, 정작 자기 서비스의 핵심이 무엇인지 흐려집니다.

정리 체크리스트

개발사에 문의하기 전, 아래 항목을 스스로 답해 보시면 첫 미팅의 밀도가 달라집니다. 전부 채워야 하는 것은 아니고, 답하지 못하는 항목이 무엇인지 아는 것 자체가 도움이 됩니다.

• 대상 사용자 — 누가, 어떤 상황에서, 어떤 불편 때문에 이 서비스를 씁니까.
• 핵심 여정 — 사용자가 들어와서 목적을 달성할 때까지의 흐름을 한 문단으로 설명할 수 있습니까.
• 화면 목록 — 사용자 화면과 관리자 화면을 각각 적었습니까.
• 기능 분류 — 반드시 필요함, 있으면 좋음, 나중에 세 단계로 나눴습니까.
• 플랫폼 — 웹, 모바일 앱, 둘 다 중 무엇입니까. 판단이 어렵다면 개발사와 함께 정해도 됩니다.
• 일정과 예산 — 목표 시점과 감당 가능한 범위를 대략이라도 정했습니까. 숨기는 것보다 밝히는 편이 현실적인 제안을 받는 데 유리합니다.
• 운영 계획 — 출시 후 콘텐츠 등록과 문의 응대는 누가 합니까.
• 준비 자료 — 참고 서비스, 로고, 원고, 계정 준비 상태를 확인했습니까.

이 항목들이 정리되면 개발사와의 대화는 ‘무엇을 만들지 알아내는 대화’에서 ‘어떻게 만들지 정하는 대화’로 넘어갑니다. 그 차이가 결국 견적의 정확도와 결과물의 만족도로 이어집니다.

※ 이 글의 분류 기준과 예시는 일반적인 프로젝트를 기준으로 한 참고 자료입니다. 실제 필요한 준비 범위와 우선순위는 서비스 성격, 규모, 일정에 따라 달라지므로 프로젝트마다 다르게 적용되어야 합니다.