필수 기능 가려내기, 예산 잡아먹는 과잉 기능 6가지

만들고 싶은 기능을 스무 개, 서른 개씩 적어 오시는 분이 많습니다. 2026년 기준으로 첫 버전에 실제로 필요한 기능은 대개 여덟에서 열 개 남짓입니다. 나머지를 어떻게 걸러내느냐가 견적과 오픈 시점을 가릅니다. 이 글은 기능을 네 등급으로 나누는 방법과, 예산을 조용히 잡아먹는 과잉 기능 여섯 가지, 그리고 등급을 가르는 세 가지 질문을 정리합니다. 만들 것을 줄이자는 이야기가 아니라, 순서를 정해 첫 버전을 가볍게 열고 나머지를 근거를 갖고 붙이자는 이야기입니다.

핵심 요약

• 기능을 반드시·있으면 좋음·여유되면·이번엔 제외 네 등급으로 나누면 첫 버전 범위가 저절로 정해집니다.
• '반드시'에는 없으면 서비스가 성립하지 않는 기능만 넣습니다. 이 칸이 부풀면 견적과 일정이 같이 무너집니다.
• 실시간 채팅·자체 앱·다국어를 비롯한 여섯 가지는 첫 버전에선 대부분 과함입니다. 각각 더 싼 대안이 있습니다.
• 등급은 세 질문으로 가릅니다. 없으면 오픈이 불가능한가, 수익이나 핵심 행동에 직접 닿는가, 나중에 붙여도 손해가 없는가.
• 노바랩 공개 기준으로 기능 범위는 150만원대부터 1,000만원대까지 가격 티어를 직접 움직입니다.

기능을 다 넣으면 왜 프로젝트가 터지나

홈페이지나 앱 외주를 진행하다 보면 첫 미팅에서 기능 목록을 빼곡히 적어 오시는 경우가 흔합니다. 회원가입에 실시간 채팅, 포인트 적립, 관리자 통계 대시보드, 앱 푸시까지. 하나하나는 다 좋아 보입니다. 문제는 이 목록을 그대로 견적에 넣으면 금액이 처음 생각의 두세 배가 되고 오픈은 몇 달씩 밀린다는 점입니다.

이렇게 범위가 통제 없이 불어나는 현상을 스코프 크립이라고 부릅니다. 위키백과는 이를 프로젝트 범위가 지속적으로, 통제되지 않은 채 확대되는 것으로 정의합니다. 범위가 처음부터 명확하지 않거나 문서로 정리되지 않았을 때 생깁니다. 발주자 입장에서 무서운 건 기능이 하나 늘 때마다 개발 시간만 느는 게 아니라, 그 기능과 얽힌 화면·데이터·예외 처리가 같이 늘어난다는 데 있습니다.

기능 하나가 늘 때 실제로 늘어나는 일도 짚어 둘 만합니다. 화면 한 장을 그리는 데서 끝나지 않고 그 화면이 다루는 데이터를 저장할 자리, 잘못 눌렀을 때의 예외 처리, 제대로 도는지 확인하는 점검까지 딸려 옵니다. 그래서 목록에서 기능 하나를 지우면 견적은 그 한 줄보다 크게 줄고 하나를 더하면 생각보다 많이 오릅니다. 발주자가 느끼는 금액의 출렁임은 대부분 이 보이지 않는 뒷일에서 나옵니다.

그래서 잘 짜인 프로젝트는 기능을 더하는 회의가 아니라 빼는 회의부터 시작합니다. 무엇을 첫 버전에 남기고 무엇을 2차로 미룰지 먼저 합의하면 남은 예산과 기간이 핵심 기능에 집중됩니다. 반대로 다 넣고 보자는 식으로 출발하면 끝까지 못 만들고 중단되거나, 다 만들었는데 정작 손님이 안 쓰는 기능만 잔뜩 남습니다.

기능을 네 등급으로 나누는 법

가장 널리 쓰이는 분류 방법은 기능을 네 칸에 나눠 담는 것입니다. 제품 기획에서는 이를 머스코(MoSCoW)라고 부릅니다. 프로덕트 스쿨의 정리를 빌리면 등급은 이렇게 나뉩니다. 반드시(Must)는 없으면 제품이 아예 작동하지 않거나 목적을 못 이루는 기능입니다. 있으면 좋음(Should)은 가치가 크지만 당장 출시에 꼭 필요하진 않은 기능입니다. 여유되면(Could)은 시간이나 예산이 남을 때 넣는, 빠져도 되는 기능입니다. 이번엔 제외(Won't)는 이번 목표와 안 맞아 다음으로 미루는 기능입니다.

핵심은 '반드시' 칸을 최대한 얇게 유지하는 데 있습니다. 프로덕트 스쿨도 반드시 칸을 진짜 필수 기능으로 제한하라고 조언합니다. 이 칸을 무겁게 채우면 등급을 나눈 의미가 사라지고 팀이 감당 못 할 약속을 하게 됩니다. 실무에서 저는 발주자가 반드시라고 표시한 기능을 다시 하나씩 되묻습니다. 이게 없으면 정말 오픈을 못 하나요, 아니면 없어도 손님은 서비스를 쓸 수 있나요. 이 질문을 통과하는 기능만 남기면 보통 절반 이하로 줄어듭니다.

등급을 나눌 때 가장 흔한 실수는 목록 전부에 반드시를 붙이는 것입니다. 내 서비스에선 다 중요하게 느껴지니 당연한 반응입니다. 그럴 때는 한 가지 제약을 스스로 겁니다. 예산이 지금의 절반만 있다면 무엇을 남기겠는가. 이 질문을 던지면 진짜 반드시와 그저 넣고 싶은 것이 갈립니다. 반대로 이번엔 제외 칸이 비어 있다면 아직 우선순위를 안 매긴 것과 같습니다. 무엇을 뺄지 정하지 못한 목록은 결국 예산이 대신 잘라내고 그 시점은 대개 오픈을 코앞에 둔 가장 나쁜 때입니다.

등급	뜻	판단 질문	예약 사이트 예시
반드시	없으면 서비스가 성립하지 않음	이게 빠지면 오픈이 불가능한가	예약 신청·확인, 예약 목록 관리
있으면 좋음	가치는 크지만 출시엔 불필요	수익·핵심 행동에 직접 닿는가	예약 알림 문자, 취소·변경
여유되면	남으면 넣고 빠져도 되는 것	없어도 첫 손님이 불편하지 않은가	후기·별점, 관리자 통계
이번엔 제외	다음 버전으로 미룸	지금 목표와 무관한가	포인트 적립, 자체 앱, 다국어

예산을 잡아먹는 과잉 기능 6가지

등급을 나눠 보면 발주자가 반드시라고 여겼지만 실제로는 첫 버전에 과한 기능이 매번 비슷하게 나옵니다. 견적을 조용히 부풀리는 대표 여섯 가지를 대안과 함께 정리했습니다. 없애자는 뜻이 아니라 첫 버전에서 미루고 더 싼 방법으로 대신하자는 이야기입니다.

첫째, 실시간 채팅 상담입니다. 상담 창을 붙이려면 메시지 서버와 상담원 화면, 알림까지 따라옵니다. 첫 손님이 하루 몇 명인 단계라면 카카오톡 채널이나 전화·문의 폼으로 충분합니다. 둘째, 자체 모바일 앱입니다. 앱은 웹과 별개로 만들어야 하고 스토어 심사·업데이트까지 따라와 비용이 배로 뜁니다. 반응형 웹으로 폰 화면을 먼저 잡고 수요가 확인된 다음 앱을 논의해도 늦지 않습니다.

셋째, 관리자 대시보드 풀커스텀입니다. 매출 그래프와 각종 통계 화면을 처음부터 맞춤으로 만들면 앞단 서비스만큼 손이 갑니다. 초기엔 목록을 보고 수정하는 최소 관리 화면이면 되고 통계는 구글 애널리틱스 같은 무료 도구로 대신합니다. 넷째, 다국어입니다. 손님이 국내 위주라면 다국어는 화면마다 번역과 검수를 두 배로 늘리는 짐이 됩니다. 다섯째, 회원 등급·포인트·적립입니다. 적립 규칙과 정산, 예외 처리가 생각보다 복잡해 결제만큼 손이 갑니다. 여섯째, 추천·개인화 알고리즘입니다. 데이터가 쌓이기 전에는 추천할 근거 자체가 없어 첫 버전엔 인기순·최신순 정렬이면 충분합니다.

여섯 가지에는 공통점이 하나 있습니다. 겉으로는 화면 하나처럼 보이지만 뒤에 서버·정산·예외 처리 같은 보이지 않는 일이 딸려 온다는 점입니다. 견적에서 값이 크게 튀는 자리도 대개 여기입니다. 이 기능들을 없애자는 게 아니라, 서비스가 자리를 잡고 손님 행동이 확인된 뒤에 근거를 갖고 붙이자는 이야기입니다. 첫 버전에서는 그 자리에 더 싼 대안을 넣어 두고 반응을 보며 진짜 필요한 것부터 승격시키면 됩니다.

등급을 가르는 3가지 질문

기능 하나를 앞에 두고 어느 칸에 넣을지 헷갈릴 때는 순서대로 세 가지만 물으면 됩니다. 이 순서가 곧 발주 전에 스스로 해볼 점검표입니다.

1. 이 기능이 빠지면 오픈 자체가 불가능한가. 답이 그렇다면 반드시입니다. 예약 서비스에서 예약 신청이 그렇습니다.
2. 오픈은 되지만 이 기능이 수익이나 손님의 핵심 행동에 직접 닿는가. 그렇다면 있으면 좋음입니다. 예약 알림 문자가 여기 속합니다. 없어도 열지만 있으면 노쇼가 줍니다.
3. 나중에 붙여도 손해가 없는가. 지금 없어도 첫 손님이 불편하지 않고 데이터가 쌓인 뒤에 넣는 게 오히려 나은 기능이라면 여유되면이나 이번엔 제외로 미룹니다. 후기·통계·추천이 대표적입니다.

세 질문을 한 줄로 줄이면 이렇습니다. 없으면 못 여는 기능이면 반드시, 열 수는 있지만 돈이나 핵심 행동에 바로 닿으면 있으면 좋음, 나중이 오히려 나으면 미룸입니다. 이 세 갈래로만 나눠도 목록은 한결 가벼워집니다. 한 가지 덧붙이면, 이 판단은 혼자 하지 말고 만들 업체와 같이 하는 편이 낫습니다. 같은 기능이라도 어떻게 만드느냐에 따라 비용이 크게 달라지는데, 그 감은 만들어 본 쪽이 더 정확하기 때문입니다. 발주자가 원하는 결과를 말하면 업체가 그걸 이루는 가장 가벼운 방법을 제안하는 흐름이 이상적입니다.

자주 하는 오해 세 가지

상담 현장에서 반복해 듣는 오해가 있습니다. 첫째, 기능이 많아야 경쟁력이 생긴다는 생각입니다. 실제로는 손님이 안 쓰는 기능은 경쟁력이 아니라 유지비이자 고장날 곳입니다. 기능 수보다 핵심 한두 가지를 매끄럽게 만드는 쪽이 첫인상을 좌우합니다.

둘째, 나중에 넣으면 더 비싸니 처음에 다 넣어야 한다는 생각입니다. 물론 나중에 붙이면 추가 비용이 듭니다. 그러나 다 넣으려다 예산이 떨어져 오픈 자체를 못 하는 쪽이 훨씬 비쌉니다. 대신 확장 가능성이 큰 구조로만 만들어 두면 나중에 기능을 얹는 비용은 크게 줄어듭니다. 그래서 첫 계약에서 챙길 것은 모든 기능이 아니라, 나중에 붙일 자리를 막지 않는 설계입니다. 셋째, 관리자 페이지는 무조건 처음부터 갖춰야 한다는 생각입니다. 초기엔 데이터를 직접 보고 고치는 최소 화면이면 충분하고 화려한 관리 통계는 서비스가 자리 잡은 뒤에 만들어도 됩니다. 관리 화면에 들이는 공은 대개 손님에게 보이지 않아 첫인상을 좌우하는 앞단에 쓰는 편이 남는 장사입니다.

노바랩 기준, 기능 범위가 가격 티어를 움직이는 폭

기능을 얼마나 넣느냐는 곧 가격 티어를 결정합니다. 노바랩이 공개한 제작 기준으로 보면 그 폭이 뚜렷합니다. 반응형 다섯 페이지 안팎에 필수 기능만 담은 기본형은 150만원대부터 시작합니다. 게시판·문의·예약처럼 있으면 좋음 단계를 더한 표준형은 350만원대, 쇼핑몰이나 예약 시스템은 400만원대, 회원·결제·맞춤 로직이 얽히는 웹앱은 1,000만원대부터로 올라갑니다.

구성	담기는 기능 범위	노바랩 시작가	대략 기간
기본형	반응형 5페이지 안팎, 소개·문의 등 필수만	150만원대부터	2~3주
표준형	10페이지+, 게시판·문의·예약 등 있으면 좋음까지	350만원대부터	4~6주
쇼핑몰·예약	상품·결제 또는 예약·달력 등 거래 기능	400만원대부터	범위 상담
웹앱	회원·권한·맞춤 로직이 얽히는 서비스	1,000만원대부터	범위 상담

이 표에서 읽을 수 있는 건 단순합니다. 앞서 정리한 과잉 기능을 첫 버전에서 빼면 견적 티어가 한 단계 내려가고 반대로 다 넣으면 한 단계 올라갑니다. 그러니 업체와 견적을 이야기할 때 이렇게 물어보길 권합니다. "이 기능을 1차에서 빼고 2차에 붙이면 견적이 얼마나 줄고, 나중에 붙일 때 추가 비용은 대략 얼마인가요?" 이 한 질문이면 어떤 기능이 값을 크게 움직이는지 바로 드러납니다. 견적서를 항목별로 뜯어 보는 법은 웹사이트 제작 비용 글에서, 그 기능을 문서로 옮기는 법은 기능 명세서 작성법 글에서 이어 보시면 됩니다.

가상 예시, 동네 학원 예약 사이트를 9개 기능으로

실제 판단이 어떻게 흘러가는지 가상 예시로 그려 보겠습니다. 동네 학원이 예약·상담 사이트를 만들며 기능을 서른 개 적어 왔다고 하겠습니다. 반드시 칸에는 수업 소개, 상담 예약 신청과 확인, 예약 목록 관리, 위치·연락처, 문의 폼처럼 없으면 문을 못 여는 아홉 개만 남깁니다. 있으면 좋음 칸에는 예약 알림 문자와 후기, 취소·변경을 두고 여유되면 칸에는 관리자 통계와 블로그를 둡니다. 자체 앱, 다국어, 포인트 적립, 실시간 채팅은 이번엔 제외로 미룹니다.

이렇게 나누면 첫 버전은 필수 아홉 개로 가볍게 열고 손님 반응을 보며 있으면 좋음부터 하나씩 붙일 수 있습니다. 처음부터 서른 개를 다 만들었다면 오픈은 훨씬 늦고 예산은 몇 배로 들었을 겁니다. 게다가 문을 연 뒤에야 알게 되는 사실이 하나 있습니다. 손님이 실제로 찾는 기능은 처음 상상과 다른 경우가 많다는 점입니다. 예약 알림이 후기보다 문의를 더 끌 수도 있고 정작 공들인 기능은 아무도 안 쓸 수도 있습니다. 가볍게 열어 두면 이 신호를 보고 다음 예산 쓸 곳을 정하지만 다 만들어 버리면 확인하기도 전에 돈이 사라집니다. 만들 서비스가 예약 중심인지 판매 중심인지에 따라 반드시 칸의 내용은 달라지니, 첫 버전에서 뺄 것과 남길 것을 더 자세히 보려면 MVP 범위 정하기 글을 함께 참고하세요. 기능이 단순한 소개형이라면 홈페이지 제작으로, 회원·결제가 얽힌다면 웹앱 개발으로 범위를 잡으면 됩니다. 어느 쪽이든 시작은 반드시 칸을 얇게 지키는 데서 갈립니다.