오픈 후 유지보수가 제작비보다 중요한 이유

홈페이지·앱·쇼핑몰 발주에서 가장 눈에 띄는 숫자는 제작 견적입니다. 화면 수, 기능 목록, 일정, 1차 오픈 범위가 표로 정리되면 “이 정도면 끝”이라고 느끼기 쉽습니다. 그런데 실제 비용 곡선은 오픈 당일부터 다시 그려집니다.

운영체제·브라우저·결제사·스토어 정책이 바뀝니다. 상품·메뉴·약관·배너·공지 문구는 매주 바뀝니다. “조금만 고쳐 주세요” 요청이 쌓이고, 누가 고칠지·얼마나 걸리는지·부작용은 없는지 매번 협상합니다. 장애가 나면 제작 당시 담당자가 이미 다른 프로젝트에 있거나, 인수인계 문서가 없습니다.

제작비는 일회성 지출처럼 보이지만, 유지보수는 서비스가 살아있는 동안 계속되는 운영 비용입니다. 이 구조를 견적 단계에서 빠뜨리면, 저렴해 보였던 프로젝트가 1~2년 안에 재개발·긴급 외주·매출 손실로 더 비싸집니다.

제작이 끝나는 시점과 운영이 시작되는 시점

오픈 성공의 정의는 “주소가 열린다”가 아닙니다. 아래가 동시에 갖춰져야 운영이 됩니다.

제작 계약만 있고 운영 계약이 없으면, 오픈 다음날부터 “누구 일인가” 공백이 생깁니다.

왜 유지보수 비용이 제작비를 앞지를 수 있나요?

변경 요청이 잦다

마케팅 시즌, 가격 정책, 이벤트, 약관 개정, 앱 스토어 심사 대응은 예측보다 잦습니다. 소액 수정이 월 단위로 누적되면 연간 합계가 초기 제작비의 상당 부분을 차지합니다.

한 곳 수정이 여러 곳에 퍼진다

“버튼 문구만” 같아도 앱·웹·관리자·알림 문구가 묶여 있으면 여러 채널을 맞춰야 합니다. 구조가 약하면 수정 한 번에 다른 화면이 깨집니다.

바깥 환경이 바뀐다

결제 모듈, 본인인증, 지도·푸시, 운영체제 강제 업데이트는 발주 당시 범위 밖처럼 보여도, 서비스 중단을 막으려면 대응해야 합니다.

지식이 끊긴다

인수인계 없이 제작자가 빠지면, 다음 수정은 “처음부터 읽는 비용”이 붙습니다. 같은 기능을 다시 파악하는 시간이 실제 수정 시간보다 길어질 수 있습니다.

장애·보안 사고 비용이 비대칭이다

평상시 유지보수 비용은 예측 가능합니다. 장애·유출·결제 오류는 한 번에 매출·신뢰·대응 비용이 붙습니다. 예방형 운영이 사후 복구보다 싸다는 패턴은 반복해서 확인됩니다.

유지보수를 ‘고쳐 주는 일’로만 보면 실패합니다

좋은 유지보수는 단순 티켓 처리가 아니라, 운영 가능한 제품 상태를 유지하는 일입니다.

• 예방: 의존 부품·인증서·스토어 정책·디스크·로그 용량 점검
• 개선: 느린 화면, 반복 문의가 많은 흐름, 관리자 실수 방지
• 대응: 장애 등급, 연락 체계, 임시 조치와 근본 조치 분리
• 기록: 무엇을 왜 바꿨는지, 다음 담당자가 읽을 수 있는지

“문의 오면 그때 고친다”만 있으면, 항상 급한 일만 남고 구조 개선은 밀립니다. 그 상태가 1년 지나면 기술 부채가 재개발 논의로 이어집니다.

견적서에서 반드시 확인할 운영 항목

제작 제안서를 볼 때 아래가 비어 있으면, 총소유비용을 아직 모르는 상태입니다.

저가 견적이 위험한 이유는 기능이 적어서만이 아닙니다. 오픈 후 공백을 고객이 떠안게 설계된 경우가 많기 때문입니다.

내부와 외주, 어떻게 나누면 좋은가

중소·중견 조직에서는 전담 개발 조직이 없는 경우가 흔합니다. 현실적인 분담 예시는 다음과 같습니다.

• 내부: 콘텐츠 정책, 승인, 고객 문의 1차 분류, 우선순위 결정
• 전문 업체: 코드 수정, 배포, 연동 장애, 보안·성능 이슈, 스토어 대응
• 공동: 월간 리뷰(장애·요청·개선 후보), 분기 로드맵 점검

“전부 내부” 또는 “전부 외주 티켓” 한쪽만 고수하면, 응답 속도나 비즈니스 맥락 중 하나가 무너집니다.

자주 하는 선택이 만드는 결과

• 제작만 계약하고 운영을 미루면, 오픈 직후 수정마다 별도 견적·일정 협상이 생기고 마케팅 타이밍을 놓칩니다
• 인수인계 없이 끝내면 계정·소스·배포 방법을 몰라 다음 업체가 재분석 비용을 청구하거나 재개발을 권합니다
• 개인 메신저로만 요청하면 담당자 퇴사 시 히스토리가 사라집니다
• 장애 대응을 정하지 않으면 주말 결제 장애에 연락 창구가 없습니다
• 저가 제작 뒤 고가 긴급 수정을 반복하면, 연간 합산이 정상 유지보수 패키지보다 커질 수 있습니다

이렇게 준비하면 좋아요

• □ 오픈 정의에 소스·배포·권한·백업·연락망이 포함되어 있는가
• □ 유지보수 범위(콘텐츠 / 기능 / 장애 / 보안)가 문서에 나뉘어 있는가
• □ 월 포함 분량과 초과 단가가 명시되어 있는가
• □ 장애 등급과 1차 연락 경로가 정해져 있는가
• □ 관리자 권한·계정 명의·도메인·인증서·스토어 계정이 고객 소유인가
• □ 수정 요청 접수 채널이 개인 메신저가 아닌 추적 가능한 방식인가
• □ 분기 1회 이상 기술 점검·정책 변경 리뷰 일정이 있는가
• □ 계약 종료 시 인수인계 산출물 목록이 사전에 합의되어 있는가

LB Contents는 앱·홈페이지·쇼핑몰을 만들고 끝내는 일이 아니라, 오픈 이후에도 수정·배포·연동 장애에 대응할 수 있는 운영 구조까지 함께 설계합니다. 제작 견적과 유지보수 범위를 한 번에 정리하고 싶다면, 요구사항이 완전하지 않은 단계에서도 상담이 가능합니다.