출시가 끝이 아닙니다 — 운영과 유지보수 가이드

출시 후에 무슨 일이 생기나

많은 분이 개발 견적을 받을 때 ‘완성해서 오픈하는 비용’만 계산합니다. 그런데 서비스는 만들어 놓으면 그대로 멈춰 있는 물건이 아닙니다. 서비스가 올라가 있는 서버는 매달 요금이 나가고, 도메인은 1년마다 갱신해야 하고, 사용하는 라이브러리는 계속 새 버전이 나오며, 스마트폰 운영체제는 해마다 크게 바뀝니다. 아무것도 손대지 않아도 주변 환경이 변하기 때문에 서비스는 가만히 있어도 서서히 낡아 갑니다.

실제로 오픈 이후 6개월 사이에 자주 발생하는 일을 꼽아 보면 대략 이렇습니다. 결제나 로그인 같은 외부 연동 서비스의 규격이 바뀌어 연동이 끊깁니다. 이용자가 늘면서 서버 사양이 부족해집니다. 스팸 가입이나 도배 글이 들어와 관리 기능이 필요해집니다. 사업 내용이 바뀌어 화면의 문구와 가격표를 고쳐야 합니다. 이런 일들은 버그가 아니라 서비스가 살아 있다는 증거에 가깝습니다.

그래서 예산을 세울 때는 개발비와 별개로 ‘운영비’ 항목을 처음부터 잡아 두는 편이 좋습니다. 개발비가 한 번에 크게 나가는 돈이라면, 운영비는 작지만 끝나지 않는 돈입니다. 두 가지를 섞어서 생각하면 오픈 직후에 예상하지 못한 지출이 생기고, 그때부터 서비스 관리가 밀리기 시작합니다.

계속 나가는 고정 비용

운영비 중에서 가장 예측하기 쉬운 부분이 고정 비용입니다. 서비스 규모와 무관하게 거의 반드시 나가고, 갱신 주기도 정해져 있어서 미리 달력에 표시해 둘 수 있습니다. 대표적인 항목은 다음과 같습니다.

비용 폭은 상당히 넓습니다. 방문자가 하루 수백 명인 소개형 웹사이트와, 이용자 데이터를 계속 쌓는 서비스형 앱은 서버 비용이 열 배 이상 차이 날 수 있습니다. 정확한 금액은 서비스 구조와 트래픽에 따라 달라지므로, 계약 전에 예상 트래픽 기준으로 한 달 청구액을 개발사와 함께 계산해 보시길 권합니다. 전체적인 비용 구조는 웹·앱 개발 비용과 기간은 어떻게 정해지나 글에서 더 자세히 다루고 있습니다.

보안 업데이트를 미루면 생기는 일

요즘 웹·앱은 처음부터 끝까지 직접 만들지 않습니다. 로그인 처리, 이미지 업로드, 날짜 계산 같은 기능은 이미 검증된 오픈소스 라이브러리를 가져다 씁니다. 개발 속도가 빨라지는 대신, 그 라이브러리에서 취약점이 발견되면 우리 서비스도 같이 위험해집니다. 취약점은 공개적으로 발표되기 때문에 공격자도 똑같이 알게 되고, 공개 직후가 가장 위험합니다.

라이브러리 취약점

보통은 라이브러리 제작자가 수정 버전을 내놓습니다. 우리가 할 일은 그 버전으로 올리고, 서비스가 정상 동작하는지 확인하는 것입니다. 문제는 오래 미룰수록 올리기 어려워진다는 점입니다. 2년치 업데이트를 한꺼번에 적용하면 여기저기서 호환성 문제가 터져서, 반나절이면 끝날 작업이 며칠짜리 작업으로 커집니다. 분기에 한 번이라도 점검하는 편이 결과적으로 비용이 적게 듭니다.

서버 운영체제 패치

서버에 깔린 리눅스나 데이터베이스도 마찬가지입니다. 게다가 운영체제 버전에는 지원 종료일이 정해져 있습니다. 지원이 끝나면 새 취약점이 발견돼도 수정판이 나오지 않습니다. 사용 중인 버전의 지원 종료일을 미리 확인하고, 최소 6개월 전에는 상위 버전 이전 계획을 세워 두는 게 좋습니다.

보안 사고는 확률은 낮지만 한 번 터지면 복구 비용이 큽니다. 개인정보가 포함된 서비스라면 유출 시 신고 의무와 이용자 통지 의무가 따르고, 신뢰 회복에는 훨씬 더 긴 시간이 듭니다. 정기 점검은 사고를 막기 위한 보험이라고 생각하시면 됩니다.

백업은 있어야 의미가 있습니다

백업을 ‘하고 있다’는 말과 ‘복구할 수 있다’는 말은 다릅니다. 자동 백업이 도는 것 같았는데 실제로는 몇 달 전부터 실패하고 있었다거나, 백업 파일은 있는데 복구 절차를 아무도 모르는 상황은 생각보다 흔합니다. 백업의 가치는 복구에 성공한 순간에만 확인됩니다.

• 주기 — 데이터가 매일 쌓이는 서비스라면 일 단위 자동 백업이 기본입니다. 주문·결제처럼 손실이 곧 금전 피해인 데이터는 더 촘촘하게 잡습니다.
• 보관 기간 — 최소 2주에서 1개월치를 유지합니다. 문제를 늦게 발견하는 경우가 많아서, 어제 백업만 있으면 이미 오염된 데이터를 덮어쓸 위험이 있습니다.
• 보관 위치 — 원본 서버와 다른 곳에 두어야 합니다. 같은 서버 안에만 있으면 그 서버에 문제가 생겼을 때 백업도 함께 사라집니다.
• 복구 테스트 — 반기에 한 번은 실제로 백업본을 다른 환경에 복원해 봅니다. 이 과정에서 빠진 항목이나 잘못된 설정이 드러납니다.
• 복구 소요 시간 — 복구에 몇 시간이 걸리는지 미리 알아 두면, 장애가 났을 때 이용자에게 안내할 수 있습니다.

백업과 함께 챙길 것이 계정과 접근 정보의 인수인계입니다. 서버 접속 정보, 도메인 관리 계정, 스토어 계정, 외부 서비스 API 키를 발주처가 별도로 보관하고 있어야 합니다. 이 정보가 개발사 담당자 한 사람의 머릿속에만 있으면, 그 사람이 퇴사하는 순간 서비스 전체가 인질이 됩니다.

모바일 앱의 특수성

웹은 서버에 새 파일을 올리면 즉시 반영됩니다. 앱은 다릅니다. 심사를 통과해야 하고, 통과해도 이용자가 직접 업데이트를 받아야 반영됩니다. 이 차이 때문에 앱은 웹보다 운영 부담이 큽니다.

OS 메이저 업데이트 대응

iOS와 안드로이드는 매년 큰 버전이 나옵니다. 새 OS가 나오면 기존 앱에서 화면이 깨지거나, 알림·카메라 같은 기능이 동작하지 않는 경우가 생깁니다. 보통 가을에 정식 배포되므로, 그 전 베타 기간에 확인하고 수정하는 흐름이 안정적입니다. 매년 최소 한 번은 이 작업을 위한 시간과 예산을 잡아 두는 게 좋습니다.

스토어 정책 변경

두 스토어 모두 정책을 자주 바꿉니다. 대표적인 것이 최소 타깃 SDK 요구사항입니다. 예를 들어 구글 플레이는 일정 시점부터 특정 버전 이상을 대상으로 빌드된 앱만 신규 등록·업데이트를 허용하고, 기준에 못 미치는 앱은 새로운 기기에서 검색되지 않게 합니다. 기능을 하나도 바꾸지 않아도 정책 때문에 빌드를 새로 올려야 하는 상황이 주기적으로 옵니다. 개인정보 처리방침 고지, 데이터 수집 항목 신고, 계정 삭제 기능 제공 같은 요구사항도 이런 범주에 들어갑니다.

심사 리젝

업데이트를 올렸다고 바로 배포되지 않습니다. 심사에서 반려되면 사유를 확인하고 고쳐서 다시 올려야 하는데, 이 왕복에 며칠이 걸리기도 합니다. 그래서 앱은 특정 날짜에 맞춰 기능을 여는 일정이 웹보다 훨씬 위험합니다. 오픈 예정일이 있다면 최소 1~2주의 여유를 두시길 권합니다. 앱을 어떤 방식으로 만들었는지에 따라 이 부담도 달라지는데, 이 부분은 앱 개발 방식 비교 글에서 정리했습니다.

모니터링과 장애 대응

서비스가 멈췄을 때 그 사실을 이용자 문의로 알게 된다면, 이미 늦은 상태입니다. 최소한의 감시 장치는 비용이 크지 않으니 처음부터 붙여 두는 편이 좋습니다.

• 가동 확인 — 몇 분 간격으로 서비스 주소에 접속해 응답을 확인하고, 실패하면 담당자에게 알림을 보냅니다. 무료 또는 월 몇천 원 수준의 도구로 충분합니다.
• 에러 로그 수집 — 이용자 화면에서 발생한 오류를 자동으로 모읍니다. 어떤 화면에서 몇 명에게 어떤 오류가 났는지 보이면, 재현이 어려운 문제도 추적할 수 있습니다.
• 자원 사용량 — 서버 CPU, 메모리, 디스크 사용률을 봅니다. 디스크가 가득 차서 서비스가 멈추는 사고는 미리 알림만 있어도 대부분 막을 수 있습니다.
• 결제·연동 실패 알림 — 돈이 오가는 부분은 실패 건이 생기면 즉시 알도록 별도로 설정합니다.

여기에 더해 ‘장애가 나면 누가, 어떤 순서로 대응하는가’를 문서 한 장으로 정해 두면 좋습니다. 1차 연락처, 대응 가능 시간대, 긴급 상황의 정의, 이용자 공지 방법 정도면 충분합니다. 대응 시간을 계약서에 넣는 경우에는 평일 업무시간 기준인지 24시간 기준인지에 따라 비용 차이가 크므로, 서비스 성격에 맞춰 정하시면 됩니다. 하루쯤 멈춰도 되는 소개 사이트와 결제가 계속 일어나는 서비스는 기준이 같을 수 없습니다.

콘텐츠 운영과 관리자 기능

운영에서 의외로 큰 비중을 차지하는 것이 ‘개발자 없이 바꿀 수 있는 범위’입니다. 공지사항 하나 올리는 데, 배너 이미지 하나 교체하는 데 매번 개발사에 요청해야 한다면 시간도 비용도 계속 나갑니다. 반대로 관리자 화면을 지나치게 정교하게 만들면 개발비가 올라갑니다. 이 균형을 기획 단계에서 정하는 게 핵심입니다.

판단 기준은 간단합니다. 한 달에 한 번 이상 바뀌는 것은 관리자 화면에서 수정할 수 있게만들고, 1년에 한두 번 바뀌는 것은 그때 요청하는 편이 낫습니다. 공지·이벤트·상품 정보·가격표·FAQ처럼 자주 손대는 항목은 관리 기능을 넣고, 회사 소개나 이용약관처럼 거의 고정된 내용은 필요할 때 수정 요청으로 처리하는 식입니다.

이용자가 글이나 사진을 올리는 서비스라면 신고 처리와 게시물 숨김 기능도 필요합니다. 오픈 전에는 불필요해 보이지만, 광고성 도배나 부적절한 게시물은 이용자가 늘어나면 반드시 들어옵니다. 처음에는 간단한 목록과 삭제 버튼 수준이라도 있어야 대응할 수 있습니다.

유지보수 계약의 형태

유지보수는 보통 세 가지 방식 중 하나로 계약합니다. 정답은 없고, 예상되는 작업량과 대응 속도에 대한 기대치에 따라 달라집니다.

금액은 서비스 규모와 대응 범위에 따라 크게 달라집니다. 소개형 웹사이트의 단순 관리는 월 십만 원 안팎에서 시작하기도 하고, 서버 운영과 기능 개선이 함께 들어가는 서비스형 앱은 월 수백만 원대가 되기도 합니다. 일반적으로는 초기 개발비의 연 10~20% 정도를 운영·유지보수 예산으로 잡는다는 이야기를 많이 하지만, 이 역시 프로젝트마다 다릅니다. 중요한 것은 금액 자체보다 그 금액에 무엇이 포함되는지입니다.

• 포함 범위 — 오류 수정만인지, 소규모 기능 개선까지인지, 서버 관리까지인지를 문서에 적습니다.
• 대응 시간 — 접수 후 몇 시간 또는 며칠 안에 회신하는지, 어떤 시간대에 대응하는지 정합니다.
• 버그의 정의 — 계약된 기능이 문서대로 동작하지 않는 것이 버그입니다. 새로 원하는 기능은 개선 요청이며 별도 비용입니다. 이 경계를 미리 합의하지 않으면 매번 다툼이 생깁니다.
• 이월과 정산 — 월정액에서 한도 시간을 다 못 썼을 때 다음 달로 넘어가는지 확인합니다.
• 종료 조건 — 계약을 끝낼 때 소스코드, 계정, 문서를 어떻게 넘기는지 명시합니다.

직접 운영할 것인가 맡길 것인가

내부에 개발 인력이 있다면 직접 운영하는 선택지가 열립니다. 반응이 빠르고 장기적으로 비용이 줄어들지만, 사람이 있어야 성립합니다. 반대로 인력이 없는데 직접 하겠다고 하면, 실제로는 아무도 관리하지 않는 상태로 몇 달이 흘러가는 경우가 많습니다.

현실적으로는 나누는 방식이 잘 맞습니다. 콘텐츠 등록과 이용자 응대 같은 일상 운영은 내부에서 하고, 서버 관리·보안 패치·장애 대응·OS 대응처럼 전문성이 필요한 부분은 개발사에 맡기는 형태입니다. 이렇게 하면 고정비를 낮추면서도 기술적 위험은 넘길 수 있습니다.

어느 쪽을 택하든 오픈 전에 정해 두어야 할 것이 있습니다. 계정과 접근 정보의 소유자, 소스코드의 보관 위치, 백업 주기, 장애 시 연락 체계, 그리고 다음 개발사로 넘어갈 때의 인수인계 방법입니다. 이 다섯 가지가 문서로 남아 있으면 담당자가 바뀌어도 서비스는 유지됩니다. 남아 있지 않으면 서비스 자체는 멀쩡해도 아무도 손댈 수 없는 상태가 됩니다.

마지막으로, 운영은 완벽하게 하려고 하면 오히려 지속되지 않습니다. 월 1회 라이브러리·서버 점검, 분기 1회 백업 복구 테스트, 연 1회 OS 대응. 이 정도 리듬만 지켜도 대부분의 사고는 피할 수 있습니다. 서비스를 오래 끌고 가는 데 필요한 것은 큰 결심이 아니라, 작지만 끊기지 않는 습관입니다.

※ 이 글에 적힌 비용과 주기는 2026년 기준의 일반적인 범위이며, 서비스 구조와 트래픽, 계약 조건에 따라 달라집니다. 스토어 정책과 개발자 계정 요금은 각 사업자의 공식 안내를 확인해 주세요.