개발 비용과 일정은 어떻게 판단하는가

개발 견적은 왜 사람마다 다를까

개발 비용은 단순히 "화면 몇 개를 만드는가"로 정해지지 않는다. 더 정확히는 사람이 문제를 이해하고, 규칙을 정리하고, 화면과 서버와 데이터베이스를 연결하고, 오류를 줄이고, 실제 운영 가능한 상태로 만드는 데 드는 시간과 책임에 가깝다.

그래서 같은 말을 듣고도 업체마다 견적이 다를 수 있다. 누군가는 "예약 기능"을 간단한 신청서 정도로 이해하고, 누군가는 결제, 취소, 관리자 승인, 문자 알림, 중복 예약 방지까지 포함해 생각할 수 있다. 겉으로는 같은 기능처럼 보이지만 실제 작업 범위가 전혀 다른 것이다.

개발 견적은 식당 메뉴판처럼 완전히 정해진 가격표라기보다, 아직 설계가 끝나지 않은 집을 짓기 전에 내는 예상 비용에 가깝다. 방 개수만으로 집값을 판단하기 어렵듯이, 개발도 기능 이름만으로는 정확한 비용을 알기 어렵다. 중요한 것은 "무엇을 만든다"보다 "어디까지 작동해야 한다"이다.

AI 생성 이미지

기능 수보다 복잡도가 비용을 키운다

많은 사람이 개발 비용을 볼 때 기능 개수를 먼저 센다. 로그인, 게시판, 결제, 검색, 관리자 화면처럼 목록을 만들고 "기능이 다섯 개니까 이 정도면 되겠지"라고 생각한다. 그러나 실제 비용을 크게 바꾸는 것은 기능의 개수보다 복잡도다.

예를 들어 "검색 기능"이라고 해도 차이가 크다. 단순히 제목에 포함된 단어를 찾는 검색은 비교적 작다. 하지만 오타를 어느 정도 알아듣고, 인기순으로 정렬하고, 지역과 가격을 함께 필터링하고, 검색 속도까지 빠르게 유지해야 한다면 작업은 훨씬 커진다.

"예약 기능"도 마찬가지다. 사용자가 날짜와 시간을 선택해 신청만 하면 되는 예약은 단순하다. 하지만 같은 시간대에 여러 사람이 동시에 예약할 때 어떻게 막을지, 예약금을 받을지, 취소 수수료를 어떻게 계산할지, 관리자 승인이 필요한지, 알림을 문자로 보낼지까지 들어가면 구조가 복잡해진다.

비용을 키우는 대표적인 요소는 다음과 같다.

• 규칙이 많은 기능: 할인, 쿠폰, 등급, 취소 정책처럼 조건이 많은 경우

• 외부 서비스 연동: 결제, 문자, 지도, 배송, 본인 인증, 소셜 로그인처럼 다른 회사의 API와 연결하는 경우

• 예외 처리: 결제는 됐는데 주문 저장이 실패한 경우, 같은 좌석을 동시에 예매한 경우처럼 예상 밖의 상황을 처리해야 하는 경우

• 운영 기능: 관리자 화면, 통계, 권한 관리, 로그 확인, 백업, 신고 처리처럼 서비스 운영자가 필요로 하는 기능

• 성능과 안정성 요구: 사용자가 몰려도 느려지지 않아야 하거나, 장애가 나면 큰 피해가 생기는 경우

사용자에게는 버튼 하나로 보이지만, 그 버튼 뒤에는 데이터 확인, 권한 검사, 외부 API 호출, 실패 처리, 기록 저장이 함께 움직일 수 있다. 개발 비용은 바로 이 보이지 않는 부분에서 커진다.

로그인 하나에도 많은 일이 숨어 있다

가장 흔한 예가 로그인이다. 많은 사람이 로그인을 기본 기능이라고 생각한다. "회원가입하고 로그인하면 되는 거 아닌가요?"라고 묻기 쉽다. 하지만 실제 서비스에서 로그인은 여러 기능의 묶음이다.

회원가입만 해도 입력해야 할 정보가 있다. 이메일을 받을지, 휴대폰 번호를 받을지, 이름과 생년월일이 필요한지 정해야 한다. 이메일 형식이 맞는지 확인해야 하고, 이미 가입된 계정인지도 검사해야 한다. 약관 동의와 개인정보 수집 동의도 필요하다.

로그인 이후에는 비밀번호 찾기가 필요하다. 사용자가 비밀번호를 잊어버렸을 때 이메일이나 문자로 본인 확인을 할 것인지, 인증 링크는 몇 분 동안 유효한지, 여러 번 틀리면 계정을 잠글 것인지 같은 규칙도 정해야 한다.

보안도 빠질 수 없다. 비밀번호를 데이터베이스에 그대로 저장하면 안 된다. 앞 장에서 본 것처럼 비밀번호는 해시와 솔트 같은 방식으로 안전하게 다뤄야 한다. 사용자가 로그인한 뒤에는 이 사람이 정말 본인인지 확인하는 인증뿐 아니라, 어떤 화면과 데이터에 접근할 수 있는지 판단하는 인가도 필요하다.

소셜 로그인도 생각보다 단순하지 않다. 카카오, 네이버, 구글, 애플 로그인을 붙이면 사용자는 편해지지만, 각 서비스의 정책과 연동 방식이 다르다. 이미 이메일로 가입한 사람이 나중에 소셜 로그인을 시도하면 같은 계정으로 합칠지, 별도 계정으로 만들지도 정해야 한다.

결국 "로그인 하나" 안에는 다음과 같은 작업이 들어갈 수 있다.

• 회원가입 화면과 입력값 검증

• 이메일 또는 휴대폰 인증

• 비밀번호 찾기와 재설정

• 약관 동의와 개인정보 동의 기록

• 비밀번호의 안전한 저장

• 로그인 상태 유지와 로그아웃

• 권한에 따른 접근 제한

• 소셜 로그인 연동

• 탈퇴와 개인정보 처리

물론 모든 서비스가 처음부터 이 모든 것을 가져야 하는 것은 아니다. 오히려 초기 서비스라면 로그인 없이도 핵심 기능을 시험할 수 있는지 먼저 검토하는 편이 좋다. 회원 기능은 편리하지만, 동시에 개발 범위와 보안 책임을 늘린다.

처음부터 완벽하게 만들 필요는 없다

개발 비용과 일정을 현실적으로 판단하려면 MVP 관점이 필요하다. MVP는 Minimum Viable Product의 줄임말로, 한국어로는 "최소 기능 제품" 정도로 이해할 수 있다. 여기서 중요한 단어는 "최소"가 아니라 "작동 가능한"이다.

MVP는 대충 만든 저가형 서비스가 아니다. 사용자의 핵심 문제를 확인할 수 있을 만큼만 작게 만든 첫 버전이다. 처음부터 모든 기능을 넣기보다, 정말 필요한 기능으로 시작해 사용자의 반응을 보고 다음 단계를 정하는 방식이다.

예를 들어 동네 빵집 예약 서비스를 만든다고 하자. 처음부터 앱, 포인트, 추천, 리뷰, 쿠폰, 배달 연동, AI 상품 추천까지 넣으면 비용과 일정이 크게 늘어난다. 하지만 초기 목표가 "단골 고객이 원하는 빵을 미리 예약할 수 있는지 확인하는 것"이라면 첫 버전은 훨씬 작아질 수 있다.

첫 버전에는 다음 정도만 넣을 수 있다.

• 오늘 예약 가능한 빵 목록 보기

• 이름과 연락처를 입력해 예약 요청하기

• 사장님이 관리자 화면에서 예약 확인하기

• 예약 상태를 문자나 알림으로 안내하기

반대로 포인트 적립, 리뷰, 추천, 복잡한 통계, 여러 지점 관리 등은 나중으로 미룰 수 있다. 처음부터 완벽한 서비스를 만들면 좋아 보이지만, 실제 사용자가 그 기능을 원하지 않을 수도 있다. 쓰이지 않는 기능은 개발비뿐 아니라 유지보수 비용도 만든다.

기능을 줄일 때는 단순히 "싼 것부터 하자"가 아니라 다음 질문을 던지는 것이 좋다.

• 이 기능이 없으면 사용자의 핵심 문제가 해결되지 않는가?

• 지금은 사람이 수동으로 처리해도 되는가?

• 나중에 추가해도 전체 구조를 다시 만들지 않아도 되는가?

• 법적 의무나 보안상 반드시 필요한 기능인가?

• 이 기능을 만들면 실제 의사결정에 도움이 되는 데이터를 얻을 수 있는가?

좋은 MVP는 미래를 포기하는 것이 아니다. 지금 검증해야 할 것을 먼저 만들고, 나중에 확장할 수 있도록 순서를 정하는 것이다.

일정은 코딩 시간만으로 계산되지 않는다

개발 일정도 마찬가지다. "개발자가 코드를 쓰는 시간"만으로 전체 기간을 계산하면 대부분 빗나간다. 실제 프로젝트에는 요구사항 정리, 화면 설계, 디자인, 개발, 테스트, 수정, 배포, 운영 준비가 모두 포함된다.

특히 일정에 큰 영향을 주는 것은 결정 지연과 변경이다. 버튼 위치 하나를 정하는 일은 작아 보이지만, 그 버튼이 결제와 연결되어 있다면 화면, 서버, 데이터베이스, 테스트가 함께 바뀔 수 있다. 프로젝트 중간에 "이 기능도 추가하면 좋겠다"는 요청이 반복되면 일정은 자연스럽게 늘어난다.

테스트 시간도 반드시 필요하다. 개발이 끝났다는 말은 코드 작성이 끝났다는 뜻일 수 있다. 사용자가 실제로 문제없이 쓸 수 있다는 뜻과는 다르다. 결제 실패, 네트워크 끊김, 중복 클릭, 권한 오류, 잘못된 입력처럼 여러 상황을 확인해야 서비스로 내보낼 수 있다.

따라서 견적서에서 "2주 개발"이라고 쓰여 있다면 그 2주가 무엇을 포함하는지 확인해야 한다. 화면 디자인은 포함인지, 테스트는 포함인지, 배포와 수정 기간은 포함인지, 관리자 기능은 포함인지에 따라 의미가 달라진다.

현실적인 일정은 보통 다음 요소를 함께 봐야 한다.

• 요구사항을 정리하고 확정하는 시간

• 화면과 정책을 설계하는 시간

• 실제 개발 시간

• 외부 API 연동과 승인 대기 시간

• 테스트와 오류 수정 시간

• 앱스토어 심사나 배포 준비 시간

• 사용자 피드백을 반영하는 시간

빠른 일정이 항상 나쁜 것은 아니다. 다만 빠르게 만들려면 범위를 줄여야 한다. 일정, 비용, 품질, 범위는 서로 연결되어 있다. 예산과 기간이 고정되어 있다면 기능 범위를 조정해야 하고, 기능 범위가 고정되어 있다면 충분한 일정과 비용이 필요하다.

개발비 이후의 비용도 함께 봐야 한다

서비스는 출시하면 끝나는 물건이 아니다. 오히려 출시 후부터 운영이 시작된다. 그래서 개발 비용을 판단할 때는 처음 만드는 비용뿐 아니라 이후에 계속 드는 비용도 함께 봐야 한다.

첫째, 유지보수 비용이 있다. 발견된 버그를 고치고, 작은 기능을 수정하고, 운영 중 생긴 문제를 해결하는 비용이다. 브라우저나 스마트폰 운영체제가 바뀌면서 기존 기능이 다르게 작동할 수도 있다. 보안 업데이트도 필요하다.

둘째, 서버와 클라우드 비용이 있다. 사용자가 적을 때는 크지 않을 수 있지만, 이미지나 영상 저장이 많거나 접속자가 늘어나면 비용이 올라간다. 백업, 로그 저장, 모니터링, 데이터 전송량도 비용에 영향을 준다.

셋째, 외부 서비스 이용료가 있다. 문자 발송, 이메일 발송, 결제 수수료, 지도 API, 본인 인증, AI API, 채팅 솔루션 등은 사용량에 따라 비용이 발생할 수 있다. 처음 견적에는 개발 연동 비용만 들어 있고, 실제 이용료는 별도일 때가 많다.

넷째, 업데이트 비용이 있다. 웹서비스는 서버에 반영하면 사용자가 바로 새 버전을 볼 수 있지만, 앱은 사용자가 업데이트를 해야 할 수 있고 앱스토어 심사도 고려해야 한다. 운영체제 정책이 바뀌면 앱을 수정해야 하는 경우도 있다.

이런 비용을 빼고 초기 개발비만 비교하면 잘못된 판단을 하기 쉽다. 처음에는 싸게 보였지만 운영할수록 비용이 커질 수도 있고, 반대로 초기 설계를 조금 더 신중히 해서 장기 비용을 줄일 수도 있다.

견적을 볼 때 확인해야 할 질문

좋은 견적은 금액만 적혀 있는 문서가 아니다. 무엇을 포함하고 무엇을 포함하지 않는지, 어떤 가정으로 산정했는지 드러나야 한다. 그래야 비교와 협상이 가능하다.

견적을 받을 때는 다음 질문을 확인해 보자.

• 이 금액에 포함된 기능 범위는 어디까지인가?

• 관리자 화면, 통계, 알림, 권한 관리는 포함되어 있는가?

• 디자인, 퍼블리싱, 서버 개발, 데이터베이스 설계가 각각 포함되어 있는가?

• 외부 API 연동 비용과 실제 이용료는 어떻게 구분되는가?

• 테스트와 오류 수정 기간은 포함되어 있는가?

• 배포, 서버 설정, 도메인 연결, 보안 설정은 누가 담당하는가?

• 출시 후 무상 수정 기간과 유지보수 조건은 무엇인가?

• 소스 코드, 서버 계정, 디자인 파일의 소유와 접근 권한은 어떻게 되는가?

• 중간에 기능이 바뀌면 비용과 일정은 어떻게 조정되는가?

가장 싼 견적이 항상 좋은 선택은 아니다. 싼 이유가 명확하면 괜찮다. 예를 들어 기능 범위를 작게 잡았거나, 이미 만들어 둔 솔루션을 활용하거나, 디자인을 단순화했기 때문이라면 합리적일 수 있다. 하지만 필요한 보안, 테스트, 운영 기능이 빠져 있어서 싼 것이라면 나중에 더 큰 비용이 들 수 있다.

비용을 줄이는 가장 좋은 방법은 명확하게 정하는 것이다

개발 비용을 줄이는 가장 현실적인 방법은 개발자를 압박하는 것이 아니라, 만들 것을 명확히 정하고 불필요한 것을 뒤로 미루는 것이다. 요구사항이 선명할수록 추정이 쉬워지고, 변경이 줄어들수록 일정도 안정된다.

처음부터 모든 답을 알 필요는 없다. 다만 핵심 사용자가 누구인지, 그 사람이 어떤 문제를 해결해야 하는지, 첫 버전에서 반드시 필요한 기능이 무엇인지는 정해야 한다. 나머지는 2차, 3차 단계로 나눌 수 있다.

개발은 한 번에 완성품을 사는 일이 아니라, 서비스를 만들어 가는 과정이다. 비용과 일정은 그 과정에서 어떤 선택을 하느냐에 따라 달라진다. 기능 이름보다 복잡도를 보고, 초기 개발비보다 운영 비용까지 보고, 완벽한 첫 버전보다 검증 가능한 첫 버전을 생각해야 한다.

무엇이 비용을 키우는지 알면 협상도 달라진다. 무조건 깎는 협상이 아니라, 어떤 기능을 줄이고 어떤 위험을 감수하며 어떤 부분은 꼭 지킬지 결정할 수 있다. 이것이 개발 견적을 이해하는 가장 실용적인 이유다.