Blog·인사이트

외주 개발, 유지보수가 진짜 시작이다

··4분 읽기
요약

런칭했습니다. 축하합니다.

런칭했습니다. 축하합니다. 앱스토어에 올라갔고, 도메인도 연결됐고, 첫 사용자가 가입했습니다. 여기서 끝이라고 생각하는 분이 많습니다. 하지만 실제로는 여기서부터가 진짜입니다.

런칭 직후, 전쟁이 시작된다

런칭 직후는 흡사 전쟁과 같습니다. 힘떨어진 전쟁.

개발에 모든 여력을 다 쏟아부었습니다. 자금도, 체력도, 팀원들의 에너지도 바닥난 상태에서 서비스를 출시합니다. 그런데 여기서부터 진짜 문제가 시작됩니다.

  • 출시했는데 무반응. 사용자가 안 옵니다. 마케팅 예산을 개발에 다 써버렸습니다.
  • 버그가 너무 많음. 실사용자가 쓰기 시작하면 개발 환경에서 안 보이던 문제가 쏟아집니다.
  • 유지보수할 자금이 없음. 개발비만 준비했지, 출시 후 운영할 비용을 애초에 계획하지 않았습니다.
  • 업데이트칠 체력이 없음. 버그를 고치고 싶어도, 팀이 이미 지쳐있습니다.

이 시점에 인하우스 개발자들이 나갑니다. 동업자들도 나갑니다. 출시 직전, 출시 직후 — 이 시기가 스타트업이 가장 많이 무너지는 시점입니다.

내부에서도 이렇게 전쟁통인데, 외주 개발사들은 어떨까요? 외주 개발사는 납품이 끝나면 다음 프로젝트로 넘어갑니다. 유지보수 계약이 없으면, 연락해도 우선순위에서 밀립니다. 가장 급한 시점에 가장 느린 대응을 받게 됩니다.

런칭 후 안정화 기간이 가장 중요하다

서비스는 런칭 직후가 가장 불안정합니다. 개발 환경에서는 발견되지 않던 문제들이 실사용자에 의해 드러나는 시기입니다.

  • 다양한 기기와 OS 버전에서 예상 못한 동작 발생
  • 실제 데이터가 쌓이면서 성능 이슈 발견
  • 사용자가 개발자가 상상하지 못한 경로로 서비스를 이용
  • 동시 접속자가 늘면 서버 부하 문제 표면화

이 안정화 기간(프로젝트마다 다르지만, 보통 1~3개월)에 빠르게 대응하지 못하면, 초기 사용자가 이탈합니다. 첫인상은 한 번뿐입니다.

사용자 1,000명과 동시접속자 1,000명은 전혀 다른 이야기

"사용자 1,000명이니까 괜찮겠지"라고 생각하기 쉽습니다. 하지만 사용자 수와 동시접속자 수는 완전히 다른 문제입니다.

가입자가 1,000명이면 보통 동시에 접속하는 사람은 수십 명입니다. 이 정도는 대부분의 서버가 감당합니다. 하지만 이벤트나 프로모션으로 1,000명이 동시에 몰리면?

  • 서버 CPU/메모리가 한계에 도달
  • 데이터베이스 커넥션 풀이 고갈
  • 결제 요청이 동시에 들어오면서 데이터 정합성 문제
  • 페이지 로딩이 10초 이상 걸리면서 사용자 이탈

개발 단계에서 동시접속 1,000명을 테스트하는 경우는 거의 없습니다. 실제 트래픽이 몰렸을 때 비로소 드러나는 문제들입니다.

유지보수 없이 방치되는 서비스들

개발비만 준비하고 유지보수 예산을 잡지 않는 경우가 생각보다 많습니다. "일단 만들고 나서 생각하자"는 접근입니다. 결과는 예측 가능합니다.

  • 버그가 발견돼도 수정할 사람이 없음
  • 사용자 문의가 들어와도 기술적 대응 불가
  • iOS나 Android OS 업데이트 후 앱이 깨지는데 방치
  • 서버 인증서 만료, 도메인 갱신 누락으로 서비스 접속 불가
  • 6개월 뒤 돌아와서 보면 이미 손댈 수 없는 상태

수천만 원을 들여 만든 서비스가, 유지보수 계약 몇백만 원을 아끼려다 1년 만에 사실상 폐기되는 경우를 여러 번 봤습니다. 개발비의 10~20%를 연간 유지보수에 투자하는 것이 일반적인 기준입니다. 이 예산을 처음부터 잡아두는 것이 중요합니다.

유지보수는 비용이 아니라 보험이다

유지보수 계약을 비용으로만 바라보면 아깝게 느껴집니다. 하지만 관점을 바꿔보면 다릅니다.

  • 서비스가 갑자기 멈추면 매출이 멈춤
  • 결제 오류가 방치되면 고객 신뢰가 무너짐
  • 보안 취약점이 방치되면 개인정보 유출 리스크
  • OS 업데이트에 대응하지 않으면 앱스토어에서 삭제

월 100~300만 원의 유지보수 비용은, 서비스 전체를 다시 만드는 비용에 비하면 미미합니다. 보험과 같습니다. 사고가 안 나면 아깝게 느껴지지만, 사고가 나면 없으면 안 되는 것입니다.

유지보수 계약 시 확인할 것

모든 유지보수 계약이 같은 것은 아닙니다. 최소한 아래 항목은 확인하세요.

  • 대응 시간: 긴급 장애 시 몇 시간 안에 대응하는지
  • 범위: 버그 수정만인지, 소규모 기능 개선도 포함인지
  • 월 공수: 포함된 작업 시간이 얼마인지
  • 서버 관리: 서버 모니터링과 장애 대응이 포함되는지
  • 보고: 월간 리포트나 이슈 목록을 공유하는지

프로덕트 메이커의 방식

프로덕트 메이커는 프로젝트 납품 후 무상으로 버그를 수정합니다 (기간은 프로젝트 규모와 계약에 따라 다릅니다). 기획과 다르게 동작하는 부분, 런칭 후 발견되는 오류 — 이런 것들은 추가 비용 없이 대응합니다.

이후에도 유지보수가 필요하시면, 서비스 규모에 맞는 유지보수 계약을 안내드립니다. 단, "기능 추가"는 유지보수가 아닌 별도 개발 범위입니다. 이 기준은 계약 시 명확히 안내드립니다.

서비스는 만드는 것보다 살리는 것이 더 어렵습니다. 런칭은 시작일 뿐입니다.

*런칭 후 유지보수 계획이 필요하시거나, 방치된 서비스를 다시 살리고 싶으시다면 프로젝트 상담을 통해 문의해 주세요.*


유지보수,운영,런칭,외주개발
다른 포스팅
Blog·인사이트

외주 개발, 유지보수가 진짜 시작이다

··4분 읽기

런칭했습니다. 축하합니다. 앱스토어에 올라갔고, 도메인도 연결됐고, 첫 사용자가 가입했습니다. 여기서 끝이라고 생각하는 분이 많습니다. 하지만 실제로는 여기서부터가 진짜입니다.

런칭 직후, 전쟁이 시작된다

런칭 직후는 흡사 전쟁과 같습니다. 힘떨어진 전쟁.

개발에 모든 여력을 다 쏟아부었습니다. 자금도, 체력도, 팀원들의 에너지도 바닥난 상태에서 서비스를 출시합니다. 그런데 여기서부터 진짜 문제가 시작됩니다.

  • 출시했는데 무반응. 사용자가 안 옵니다. 마케팅 예산을 개발에 다 써버렸습니다.
  • 버그가 너무 많음. 실사용자가 쓰기 시작하면 개발 환경에서 안 보이던 문제가 쏟아집니다.
  • 유지보수할 자금이 없음. 개발비만 준비했지, 출시 후 운영할 비용을 애초에 계획하지 않았습니다.
  • 업데이트칠 체력이 없음. 버그를 고치고 싶어도, 팀이 이미 지쳐있습니다.

이 시점에 인하우스 개발자들이 나갑니다. 동업자들도 나갑니다. 출시 직전, 출시 직후 — 이 시기가 스타트업이 가장 많이 무너지는 시점입니다.

내부에서도 이렇게 전쟁통인데, 외주 개발사들은 어떨까요? 외주 개발사는 납품이 끝나면 다음 프로젝트로 넘어갑니다. 유지보수 계약이 없으면, 연락해도 우선순위에서 밀립니다. 가장 급한 시점에 가장 느린 대응을 받게 됩니다.

런칭 후 안정화 기간이 가장 중요하다

서비스는 런칭 직후가 가장 불안정합니다. 개발 환경에서는 발견되지 않던 문제들이 실사용자에 의해 드러나는 시기입니다.

  • 다양한 기기와 OS 버전에서 예상 못한 동작 발생
  • 실제 데이터가 쌓이면서 성능 이슈 발견
  • 사용자가 개발자가 상상하지 못한 경로로 서비스를 이용
  • 동시 접속자가 늘면 서버 부하 문제 표면화

이 안정화 기간(프로젝트마다 다르지만, 보통 1~3개월)에 빠르게 대응하지 못하면, 초기 사용자가 이탈합니다. 첫인상은 한 번뿐입니다.

사용자 1,000명과 동시접속자 1,000명은 전혀 다른 이야기

"사용자 1,000명이니까 괜찮겠지"라고 생각하기 쉽습니다. 하지만 사용자 수와 동시접속자 수는 완전히 다른 문제입니다.

가입자가 1,000명이면 보통 동시에 접속하는 사람은 수십 명입니다. 이 정도는 대부분의 서버가 감당합니다. 하지만 이벤트나 프로모션으로 1,000명이 동시에 몰리면?

  • 서버 CPU/메모리가 한계에 도달
  • 데이터베이스 커넥션 풀이 고갈
  • 결제 요청이 동시에 들어오면서 데이터 정합성 문제
  • 페이지 로딩이 10초 이상 걸리면서 사용자 이탈

개발 단계에서 동시접속 1,000명을 테스트하는 경우는 거의 없습니다. 실제 트래픽이 몰렸을 때 비로소 드러나는 문제들입니다.

유지보수 없이 방치되는 서비스들

개발비만 준비하고 유지보수 예산을 잡지 않는 경우가 생각보다 많습니다. "일단 만들고 나서 생각하자"는 접근입니다. 결과는 예측 가능합니다.

  • 버그가 발견돼도 수정할 사람이 없음
  • 사용자 문의가 들어와도 기술적 대응 불가
  • iOS나 Android OS 업데이트 후 앱이 깨지는데 방치
  • 서버 인증서 만료, 도메인 갱신 누락으로 서비스 접속 불가
  • 6개월 뒤 돌아와서 보면 이미 손댈 수 없는 상태

수천만 원을 들여 만든 서비스가, 유지보수 계약 몇백만 원을 아끼려다 1년 만에 사실상 폐기되는 경우를 여러 번 봤습니다. 개발비의 10~20%를 연간 유지보수에 투자하는 것이 일반적인 기준입니다. 이 예산을 처음부터 잡아두는 것이 중요합니다.

유지보수는 비용이 아니라 보험이다

유지보수 계약을 비용으로만 바라보면 아깝게 느껴집니다. 하지만 관점을 바꿔보면 다릅니다.

  • 서비스가 갑자기 멈추면 매출이 멈춤
  • 결제 오류가 방치되면 고객 신뢰가 무너짐
  • 보안 취약점이 방치되면 개인정보 유출 리스크
  • OS 업데이트에 대응하지 않으면 앱스토어에서 삭제

월 100~300만 원의 유지보수 비용은, 서비스 전체를 다시 만드는 비용에 비하면 미미합니다. 보험과 같습니다. 사고가 안 나면 아깝게 느껴지지만, 사고가 나면 없으면 안 되는 것입니다.

유지보수 계약 시 확인할 것

모든 유지보수 계약이 같은 것은 아닙니다. 최소한 아래 항목은 확인하세요.

  • 대응 시간: 긴급 장애 시 몇 시간 안에 대응하는지
  • 범위: 버그 수정만인지, 소규모 기능 개선도 포함인지
  • 월 공수: 포함된 작업 시간이 얼마인지
  • 서버 관리: 서버 모니터링과 장애 대응이 포함되는지
  • 보고: 월간 리포트나 이슈 목록을 공유하는지

프로덕트 메이커의 방식

프로덕트 메이커는 프로젝트 납품 후 무상으로 버그를 수정합니다 (기간은 프로젝트 규모와 계약에 따라 다릅니다). 기획과 다르게 동작하는 부분, 런칭 후 발견되는 오류 — 이런 것들은 추가 비용 없이 대응합니다.

이후에도 유지보수가 필요하시면, 서비스 규모에 맞는 유지보수 계약을 안내드립니다. 단, "기능 추가"는 유지보수가 아닌 별도 개발 범위입니다. 이 기준은 계약 시 명확히 안내드립니다.

서비스는 만드는 것보다 살리는 것이 더 어렵습니다. 런칭은 시작일 뿐입니다.

*런칭 후 유지보수 계획이 필요하시거나, 방치된 서비스를 다시 살리고 싶으시다면 프로젝트 상담을 통해 문의해 주세요.*


유지보수,운영,런칭,외주개발
다른 포스팅
WebGL프로젝트 상담