오픈 뒤에 개발비가 또 나가는 곳 | 문의가 만드는 3가지 비용
오픈하면 개발비가 한 번 더 나가요. 연 유지보수를 개발비의 10～20%로 잡는 게 실무 추정인데, 여기에 고객 문의가 만드는 개선 요청이 얹혀요. 자체 SaaS 4종을 운영하며 본 순서와 발주 단계에서 견적에 넣어둘 3가지를 정리했어요.
3줄 요약 — 서비스는 오픈하면 끝이 아니라 거기서 비용 구조가 바뀌어요. 연 유지보수를 개발비의 10～20%로 잡는 게 실무 추정인데, 실제로는 고객 문의에서 시작된 개선 요청이 그 위에 얹혀요. 자체 SaaS 4종을 직접 운영하며 본 순서와, 발주 단계에서 견적에 미리 넣어둘 세 가지를 정리했어요.
“오픈했으니 이제 유지보수만 하면 되죠?”
계약 마무리 단계에서 자주 나오는 말이에요. 저희도 처음 자체 서비스를 열었을 땐 비슷하게 생각했어요. 그런데 오픈 다음 달부터 개발 일정표가 다시 채워지더라고요. 새 기능을 만들어서가 아니라 문의에서 시작된 일들 때문이었어요.
1. 오픈하고 나면 어디에 돈이 다시 들까요
세 갈래로 나가요. 셋 다 성격이 달라요.
발주 단계에서 잡는 예산은 대개 만드는 비용이에요. 오픈 뒤에 나가는 돈은 다른 이름으로 붙어요.
- 고치는 비용 — 버그 수정. 무상 하자보수 기간(보통 1～3개월)이 지나면 유지보수 계약으로 넘어가요. 연 단위로 개발비의 10～20% 수준을 잡는 게 실무 추정이에요.
- 굴리는 비용 — 서버, 외부 서비스 사용료, 결제 수수료. 쓸수록 늘어나요.
- 고쳐 만드는 비용 — 쓰다 보니 불편해서 손보는 일. 견적서에 항목이 없는 게 보통이에요.
문제는 세 번째예요. 버그가 아니라서 유지보수에 안 들어가고, 새 기능도 아니라서 예산이 없어요. 그런데 실제로 개발 일정을 가장 많이 잡아먹어요.
2. 문의 한 건이 개발 요청이 되는 경로
중간에 사람이 대신 처리하면 티가 안 나요.
경로는 대체로 이렇게 흘러요. 사용자가 어디선가 막혀서 문의를 보내요. 담당자가 답을 해줘요. 같은 문의가 또 와요. 담당자가 또 답을 해줘요. 이게 스무 번쯤 쌓이면 그제야 “이거 화면을 고쳐야겠는데요” 하는 이야기가 나와요.
사람이 잘 대응할수록 이 지점이 늦게 발견돼요. 문의가 잘 처리되고 있으니 문제로 안 보이거든요. 그래서 저희는 문의를 처리한 건수보다 같은 문의가 몇 번 반복됐는지를 봐요. 반복 횟수가 개발 우선순위를 정해주는 신호예요.
3. 저희가 자체 서비스에서 겪은 순서예요
운영해보고 나서야 보이는 것들이 있었어요.
저희는 자체 SaaS 4종을 직접 운영하고 있어요. 만들어서 납품하는 게 아니라 저희가 매일 쓰고, 사용자 문의도 저희가 받아요. 그 자리에서 배운 게 몇 가지 있어요.
먼저 문의는 기능이 부족해서만 오지 않아요. 잘 만들어놨는데 어디 있는지 몰라서 오는 문의가 생각보다 많아요. 이런 건 개발이 아니라 안내 문구 한 줄로 끝나는데, 그 문구를 고치려면 개발자가 필요한 구조로 만들어놨다면 매번 요청이 올라가요.
둘째, 운영 중에만 드러나는 문제가 있어요. 롯데백화점 수원 푸드홀 프로젝트에서 관리자 페이지로 등록한 광고가 사이니지에서 끊기는 현상이 있었어요. 개발 단계에서는 안 보이다가 실제 매장에서 돌려보니 나타났고, 결국 처음 JavaFX로 만든 부분을 C#으로 다시 구현해서 해결했어요. 만들 때 드는 비용과 버티게 만드는 비용은 이렇게 따로 계산되더라고요.
셋째, 도구를 만들면 문의 자체가 줄어요. 캐논코리아 카메라 펌웨어 업데이트 유틸리티를 만든 뒤 관련 고객 문의가 줄었어요. 사용자가 스스로 처리할 수 있게 되면 대응할 일도 같이 사라져요.
4. 문의를 줄이는 건 인력이 아니라 화면이에요
같은 질문이 반복된다면 답을 잘하는 것보다 안 묻게 만드는 게 싸요.
문의를 유형별로 세어보면 대개 몇 가지에 몰려 있어요. 결제가 안 된다, 비밀번호를 못 찾겠다, 이 기능이 어디 있는지 모르겠다. 상위 몇 개가 전체의 상당 부분을 차지해요.
여기서 판단이 갈려요. 사람을 늘려 답을 빨리 하는 쪽과, 화면을 고쳐 질문 자체를 없애는 쪽이에요. 앞쪽은 매달 나가는 비용이고 뒤쪽은 한 번 드는 비용이에요. 반복되는 문의라면 계산은 대체로 뒤쪽이 유리해요.
다만 화면을 고치려면 조건이 하나 필요해요. 무엇이 반복되는지 숫자로 볼 수 있어야 해요. 기록이 남지 않으면 담당자 기억에 의존하게 되고, 그러면 목소리 큰 문의가 우선순위를 가져가요.
운영까지 염두에 둔 견적을 받아보고 싶다면 무엇을 넣어야 할지부터 같이 정리해드릴게요 →
5. 발주 단계에서 견적에 넣어둘 3가지
오픈 전에 넣으면 싸고, 오픈 후에 넣으면 비싸요.
- 문의 기록 — 어떤 문의가 몇 번 들어왔는지 유형별로 쌓이게 해두세요. 별도 시스템이 아니라 관리자 화면의 표 하나여도 충분해요.
- 문구·안내 수정 권한 — 화면에 나가는 문장을 개발자 없이 담당자가 고칠 수 있게 해두세요. 여기 하나로 사소한 요청의 상당수가 사라져요.
- 사용자 상태 조회 — 문의한 사람의 현재 상태(결제 여부, 진행 단계, 오류 기록)를 한 화면에서 볼 수 있게 해두세요. 이게 없으면 문의 한 건마다 개발자가 데이터를 뒤져야 해요.
세 가지 모두 오픈 전에는 작은 작업이에요. 관리자 화면을 만드는 김에 같이 들어가니까요. 오픈 후에 붙이면 이미 쌓인 데이터를 정리하는 일이 앞에 붙어서 규모가 달라져요. 관리자 화면의 범위가 견적을 어떻게 바꾸는지는 관리자 페이지 비용이 갈리는 이유에 자세히 적어뒀어요.
6. 예산은 어떻게 나눠 잡을까요
한 덩어리로 잡으면 개선 예산이 사라져요.
오픈 후 1년 예산을 잡을 때 항목을 나눠두면 나중에 다투지 않아요.
| 항목 | 성격 | 잡는 기준 |
|---|---|---|
| 하자보수 | 무상 | 보통 1～3개월, 계약서에 명시 |
| 유지보수 | 연 계약 | 개발비의 10～20% 수준(실무 추정) |
| 운영 사용료 | 종량 | 서버·외부 서비스·수수료, 사용량 기준 |
| 개선 작업 | 별도 | 문의 상위 항목 처리용, 분기 단위로 확보 |
마지막 줄이 이 글의 핵심이에요. 개선 작업 예산이 따로 없으면 모든 요청이 유지보수 계약 안에서 처리되길 기대하게 되고, 그러면 개발사와 발주사 양쪽이 서로 다른 기준으로 이야기하게 돼요. 유지보수 범위를 어디까지 잡을지는 유지보수 비용은 얼마를 잡아야 할까요를 참고하시면 좋아요.
7. 자주 묻는 질문 (FAQ)
오픈 후 유지보수 비용은 얼마로 잡아야 하나요?
실무에서는 연 단위 유지보수를 개발비의 10～20% 수준으로 잡는 추정이 많이 쓰여요. 무상 하자보수 기간은 보통 1～3개월이고요. 다만 이 숫자는 버그를 고치는 비용이지 개선 요청을 처리하는 비용은 아니에요. 문의가 많은 서비스라면 개선 항목 예산을 따로 확보해두는 편이 현실적이에요.
고객 문의를 줄이려면 사람을 더 뽑아야 하나요?
같은 문의가 반복된다면 사람보다 화면을 먼저 보세요. 문의를 유형별로 세어보면 대개 몇 가지에 몰려 있고, 그 몇 가지는 안내 문구나 화면 순서를 고쳐서 줄일 수 있어요. 캐논코리아 펌웨어 유틸리티도 도구가 생기면서 관련 문의가 줄었어요.
발주할 때 운영 도구를 어디까지 요청해야 하나요?
문의 기록, 문구 수정 권한, 사용자 상태 조회. 이 셋은 견적에 넣어달라고 요청하세요. 없으면 사소한 수정마다 개발 요청이 올라가서 운영비가 계속 새요.
8. 마무리 — 오픈은 비용의 끝이 아니라 갈림길이에요
정리하면 이래요. 오픈 뒤 비용은 버그를 고치는 돈, 굴리는 돈, 그리고 고쳐 만드는 돈으로 갈라져요. 앞의 둘은 견적서에 있고 마지막 하나는 대개 없어요. 그런데 실제로 일정을 가장 많이 차지하는 건 마지막이에요. 문의 기록과 수정 권한을 오픈 전에 넣어두면 이 항목이 줄어들어요.
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 만들어 넘기는 자리와 매일 굴리는 자리를 둘 다 겪어봐서, 견적을 볼 때 오픈 다음 달의 일정표를 먼저 그려보는 습관이 생겼어요. 지금 준비 중인 프로젝트가 있다면 프로젝트 상담받기 →로 편하게 물어보세요.
관련 글: 오픈 후 안정화에는 얼마가 들었을까요