서버 운영 유지보수, 출시 다음 날 장애가 나면 누가 대응하는가 — 인수 전에 정해야 할 6가지

서버 운영 유지보수는 개발이 끝난 뒤에 생각하면 이미 늦습니다. 출시 당일까지는 모두가 화면을 보고 있습니다. 그런데 그 다음 주 화요일 새벽 두 시, 결제가 되지 않는다는 문의가 쌓이기 시작하면 상황이 완전히 달라집니다. 발주사 담당자는 개발사 PM에게 전화를 걸지만 받지 않습니다. 아침이 되어 연락이 닿으면, 프로젝트를 만들었던 개발자는 이미 다른 프로젝트에 배정되었다는 답을 듣습니다. 계약서에는 ‘유지보수 1년’이라고 적혀 있습니다. 그런데 그 한 줄이 지금 이 장애를 누가 몇 시간 안에 고치는지는 아무것도 정해주지 않습니다.

디비컨설팅은 100건 이상의 웹·앱·플랫폼 프로젝트를 구축하고 운영까지 이어받아 왔습니다. 삼성물산 홈닉, GS건설 엘리시안 리조트, 하나투어 하나오픈챗, LS일렉트릭 테크스퀘어, 가천대학교 학사관리 시스템처럼 출시 이후에도 계속 돌아가야 하는 시스템들입니다. 그 경험에서 반복적으로 확인한 것은, 운영 단계의 사고가 기술 문제로 시작되는 경우는 드물다는 사실입니다. 대부분은 ‘누가 책임지는지’를 발주 단계에서 정하지 않은 결과로 나타납니다.

출시 직후가 가장 위험한 구간인 이유

개발 기간 중에는 모든 관심이 프로젝트에 집중되어 있습니다. 개발자도 배정되어 있고, PM도 매주 회의를 잡고, 문제가 생기면 그 자리에서 잡힙니다. 문제는 검수가 끝나고 잔금이 지급된 다음부터입니다. 프로젝트 조직은 해산되고, 시스템은 그때부터 실제 사용자를 받기 시작합니다. 관심이 가장 낮아지는 시점과 부하가 가장 높아지는 시점이 겹칩니다.

실사용자는 테스트 데이터처럼 행동하지 않습니다

검수 환경에서는 수십 건의 데이터로 확인합니다. 실제 서비스에서는 첫 주에 수천 건이 들어옵니다. 동시 접속, 이미지 업로드 용량, 푸시 발송량, 결제 재시도 같은 항목은 실사용 트래픽을 받아본 뒤에야 한계가 드러납니다. 개발 검수 단계에서 기능이 모두 통과했다는 것과, 실제 부하에서 견딘다는 것은 다른 이야기입니다.

장애는 대부분 코드가 아니라 연결 지점에서 납니다

운영 중 실제로 서비스를 멈추는 원인은 대개 외부와 맞닿은 부분입니다. 결제 대행사 인증서 만료, 문자·알림톡 발송 한도 초과, 도메인이나 SSL 인증서 갱신 누락, 서버 디스크 용량 초과, 외부 API 사양 변경. 어느 것도 개발사가 잘못 만들어서 생긴 문제가 아닙니다. 그래서 ‘하자보수’에 해당하지 않고, 그래서 아무도 자기 일이라고 생각하지 않습니다.

만든 사람이 남아 있지 않으면 대응 시간이 몇 배로 늘어납니다

같은 장애를, 그 코드를 직접 쓴 개발자는 한 시간 안에 원인을 찾습니다. 처음 보는 개발자는 구조를 파악하는 데만 이틀이 걸립니다. 문서가 없으면 더 걸립니다. 유지보수 계약이 ‘월 몇 시간 지원’ 형태로만 되어 있으면, 발주사는 그 파악 시간까지 자기 비용으로 지불하게 됩니다.

SLA를 꼼꼼히 써도 해결되지 않는 부분

이 문제를 검색하면 대부분 ‘SLA를 제대로 쓰라’는 조언이 나옵니다. 응답 시간, 복구 시간, 가동률을 숫자로 못 박으라는 것입니다. 맞는 조언이고, 개발 외주 계약서에 반드시 들어가야 하는 항목입니다.

다만 SLA는 약속을 문서로 만드는 장치이고, 그 약속을 실행할 사람이 남아 있는지는 다른 문제입니다. 프로젝트 단위로 발주하면, 개발사는 납품 시점에 그 인력을 다음 프로젝트로 옮깁니다. 계약상 ‘4시간 내 응답’은 지켜집니다. 접수 담당자가 4시간 안에 접수했다는 뜻이기 때문입니다. 실제로 코드를 열어볼 사람이 언제 붙는지는 SLA에 적혀 있지 않습니다.

그래서 운영 문제는 조항의 문제가 아니라 팀 연속성의 문제입니다. 계약서를 강하게 쓰는 것보다, 만든 팀이 남는 구조로 발주하는 것이 먼저입니다.

발주사가 실제로 선택하는 세 가지 구조

운영을 누가 맡느냐는 결국 어떤 구조로 발주했는지에 따라 결정됩니다. 선택지는 세 가지입니다.

	국내 개발사 (프로젝트 단위)	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
출시 후 인력 잔류	낮음	보통	높음
장애 시 1차 응답 주체	접수 창구	발주사 본인	한국 PM
업무시간 외 장애 대응	어려움	발주사가 직접 대응	시차를 활용해 커버
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

해외에 직접 발주하면 단가는 분명히 내려갑니다. 문제는 운영 단계입니다. 장애가 났을 때 상황을 정리하고, 우선순위를 정하고, 영어로 지시하고, 조치 결과를 검증하는 일이 전부 발주사 담당자에게 넘어옵니다. 사내에 그 일을 할 개발 인력이 없다면, 절감한 단가는 담당자의 밤과 주말로 지불됩니다.

반대로 시차는 제대로 설계하면 오히려 자산입니다. 한국 시간 새벽은 인도 기준으로 업무 시간입니다. 한국인 PM이 접수와 판단을 맡고 글로벌 개발팀이 그 시간대에 손을 대는 구조라면, 국내 개발사가 ‘내일 오전에 확인하겠습니다’라고 답하는 시간에 이미 조치가 진행됩니다.

인수 전에 정해야 할 6가지

운영을 넘겨받기 전에 다음 여섯 가지는 문서로 확정하시기를 권합니다. 여섯 항목 모두 개발이 끝난 뒤에는 협상력이 급격히 떨어지는 항목입니다.

1. 장애 등급과 등급별 대응 시간

‘신속히 대응’은 기준이 아닙니다. 서비스 전체 중단, 핵심 기능 장애, 일부 화면 오류를 등급으로 나누고, 등급별로 최초 응답 시간과 임시 복구 목표를 각각 적으십시오. 특히 ‘최초 응답’과 ‘복구 착수’를 구분해서 쓰는 것이 중요합니다. 이 둘을 한 문장으로 합쳐 두면 접수만으로 의무가 이행됩니다.

2. 대응 시간대와 시차 처리 주체

평일 09-18시인지, 24시간인지, 주말과 공휴일은 어떻게 되는지를 명시합니다. 해외 인력이 포함된 팀이라면 시차를 누가 흡수하는지가 핵심입니다. 발주사가 영어로 직접 연락해야 하는 구조인지, 한국인 PM이 창구가 되는 구조인지에 따라 담당자의 실제 부담이 완전히 달라집니다.

3. 서버·도메인·계정의 명의

클라우드 계정, 도메인, SSL 인증서, 앱스토어와 구글 플레이 개발자 계정, 결제 대행사 가맹점 계정. 이것들이 개발사 명의로 되어 있으면 나중에 업체를 바꿀 때 서비스를 인질로 잡힌 상태가 됩니다. 가능하면 전부 발주사 명의로 개설하고, 개발사에는 접근 권한만 부여하십시오. 이미 개발사 명의로 진행되었다면 개발사 교체를 검토하기 전에 명의 이전 절차부터 확인해야 합니다.

4. 운영 서버 배포 권한과 절차

누가 운영 서버에 코드를 반영할 수 있는지, 반영 전에 누구의 승인이 필요한지, 문제가 생겼을 때 되돌리는 절차가 무엇인지를 정합니다. 권한이 한 사람에게만 있으면 그 사람이 휴가일 때 서비스가 멈춥니다. 반대로 아무나 반영할 수 있으면 원인 추적이 불가능해집니다.

5. 하자보수와 유지보수의 경계

계약한 기능이 명세대로 동작하지 않는 것은 하자이고 무상입니다. 새 기능을 추가하는 것은 유상입니다. 분쟁은 그 사이에서 발생합니다. 외부 API 사양이 바뀌어서 연동이 깨진 경우, OS 버전이 올라가서 화면이 틀어진 경우, 사용자가 늘어서 느려진 경우는 어느 쪽인지 미리 적어두어야 합니다. 비용 산정 구조 자체는 앱 유지보수 비용에서 항목별로 정리해 두었습니다.

6. 원 개발 인력의 잔류 여부와 인계 문서

가장 중요하지만 가장 자주 빠지는 항목입니다. 만든 개발자 중 몇 명이 운영 기간에도 남는지, 남지 않는다면 무엇을 문서로 남기는지를 확정하십시오. 최소한 API 명세, DB 스키마, 배포 절차, 외부 연동 계정 목록, 알려진 이슈 목록은 인계 대상이어야 합니다. 이 문서가 없으면 나머지 다섯 항목을 아무리 잘 써도 대응 속도가 나오지 않습니다.

디비컨설팅이 운영을 이어받는 방식

IT 아웃소싱을 전담팀 형태로 진행하기 때문에, 운영은 별도 단계가 아니라 같은 팀이 계속 맡는 구간입니다. 진행 절차는 다섯 단계입니다.

1. 상담 및 요구 분석 — 비즈니스 목표와 기술 요건을 한국어로 문서화합니다. 이 단계에서 운영 기준까지 함께 정의합니다. 장애 등급, 대응 시간대, 계정 명의를 개발 착수 전에 정해두면 인수 시점의 협상이 사라집니다. 무엇을 문서로 정리해야 하는지는 요구사항 정의서에서 다뤘습니다.
2. 개발팀 구성 — 전담팀을 2~4주 안에 구성합니다. 인력 단위가 아니라 팀 단위로 배정되기 때문에, 출시 이후에도 같은 인원이 유지됩니다.
3. 프로젝트 개발 — 애자일 방식으로 진행하고 진행 상황을 투명하게 공유합니다. 발주사 담당자가 하루를 조율에 쓰지 않는 것이 기준입니다.
4. 테스트 및 배포 — QA 프로세스를 거친 뒤 배포합니다. QA를 전담 조직이 맡는지 개발자가 겸하는지의 차이는 QA 전담팀에서 설명했습니다.
5. 운영 및 유지보수 — 문서와 함께 인계하고 장기적으로 지원합니다. 소스코드는 발주사에 귀속되며, API 명세·DB 스키마·배포 절차 문서까지 인계 대상입니다.

구조의 핵심은 단순합니다. 발주사는 한국인 PM 한 사람과 한국어로 소통하고, 그 PM이 요구사항 정의·일정·검수·장애 접수와 판단을 책임집니다. 글로벌 개발팀을 발주사가 직접 관리하지 않습니다.

출시 후에도 계속 돌아가고 있는 시스템들

운영을 감당할 수 있는지는 실제로 운영해 본 시스템으로 판단하시는 편이 정확합니다.

• 삼성물산 — 홈닉 · 주거 플랫폼 앱. 입주민이 매일 쓰는 서비스로, 중단이 곧 민원이 되는 유형입니다.
• GS건설 — 엘리시안 리조트 · 리조트 웹과 앱 통합 구축. 예약이 몰리는 성수기 부하를 전제로 설계했습니다.
• 하나투어 — 하나오픈챗 · 여행 상담 채팅 서비스. 실시간 응답이 서비스 품질 그 자체인 구조입니다.
• LS일렉트릭 — 테크스퀘어 · 산업 B2B 거래 플랫폼.
• 직방 — 호갱노노 · 부동산 데이터 서비스.
• 가천대학교 · 학사관리 시스템. 수강신청처럼 특정 시점에 부하가 집중되는 시스템입니다.
• 센터필드 · 센트로폴리스 · 그랑서울 · 프라임 오피스 빌딩 관리 시스템.
• 교보생명 · 사내벤처(글펍) 커뮤니티 서비스.

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역의 구축 경험이 있습니다. 전체 목록은 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 사내에 개발 인력이 없거나 한두 명뿐이어서, 장애 시 판단을 내려줄 사람이 없는 기업
• 이미 출시한 서비스가 있는데 만든 개발사와 연락이 잘 되지 않는 기업
• 구축과 운영을 한 팀에 맡겨 인계 손실을 줄이고 싶은 기업
• 실사용자가 매일 쓰는 서비스여서 중단 시간이 그대로 비용이 되는 기업
• 웹 개발 외주 또는 앱 개발 외주를 준비 중이면서, 발주 단계에서 운영 조건까지 함께 정하고 싶은 기업

반대로 권하지 않습니다

• 사내에 운영 조직이 이미 있는 경우. 인프라 담당과 백엔드 인력이 상시 대기하는 조직이라면, 외부에 운영을 맡기는 것이 오히려 단계를 늘립니다. 필요한 구간만 인력 단위로 보강하는 편이 낫습니다.
• 내부 정책상 외부 인력의 운영 서버 접근이 불가능한 경우. 접근 권한 없이 장애 대응을 위탁하면 책임만 이전되고 조치는 되지 않습니다.
• 월 운영 예산을 전혀 잡지 않은 경우. 구축비만 확보하고 운영비를 0으로 두면, 어떤 구조를 택하든 두세 달 안에 같은 문제가 반복됩니다. 이 경우에는 구축 범위를 줄여서 운영 예산을 확보하는 것이 먼저입니다.
• 단순 서버 임대나 모니터링 도구만 필요한 경우. 그것은 호스팅 업체의 영역이고, 개발팀을 붙일 필요가 없습니다.

자주 묻는 질문

해외 개발팀이 대응하는데 의사소통은 어떻게 하나요?

발주사는 한국인 PM하고만 한국어로 소통합니다. 장애 접수, 상황 판단, 우선순위 결정, 조치 결과 확인이 모두 PM 책임입니다. 발주사가 영어로 개발자에게 직접 지시하는 상황은 발생하지 않습니다.

소스코드와 서버는 누구 소유가 되나요?

소스코드는 발주사에 귀속됩니다. API 명세, DB 스키마, 배포 절차 문서까지 인계 대상입니다. 서버와 클라우드 계정도 발주사 명의로 개설하는 것을 권장하며, 저희는 필요한 접근 권한만 받아 운영합니다. 언제든 다른 업체로 이관하거나 내부 인력으로 전환할 수 있는 상태를 유지하는 것이 원칙입니다.

다른 회사가 만든 시스템의 운영만 맡길 수 있나요?

가능합니다. 다만 인계 자료의 상태를 먼저 확인해야 합니다. 소스코드 접근, 서버와 계정 권한, DB 구조, 외부 연동 목록이 확보되는지에 따라 착수 시점이 달라집니다. 자료가 부족하면 구조 파악 기간을 별도로 잡고, 그 결과를 문서로 남긴 뒤 운영에 들어갑니다.

기획서나 문서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 필수 기능 3~5개, 일정과 예산 범위만 있으면 개략 견적을 드립니다. 운영 위탁의 경우에는 현재 서비스 주소, 월 사용자 규모, 최근 발생한 장애 유형 정도만 알려주시면 검토가 가능합니다.

운영 중에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택할 수 있고 진행 중에도 조정할 수 있습니다. 출시 직후 몇 달은 인력을 두텁게 두고 안정화된 뒤 축소하는 방식이 일반적입니다.

정리

서버 운영 유지보수에서 실제로 문제가 되는 것은 계약서에 적힌 시간이 아니라, 그 시간을 지킬 사람이 남아 있는지입니다. 장애 등급, 대응 시간대, 계정 명의, 배포 권한, 하자와 유지보수의 경계, 원 개발 인력의 잔류 여부 — 이 여섯 가지를 인수 전에 문서로 정해두면 대부분의 분쟁이 사라집니다. 그리고 이 여섯 가지가 자연스럽게 지켜지는 구조는 구축과 운영을 같은 팀이 맡고, 그 팀과의 소통을 한국인 PM이 책임지는 형태입니다. IT 외주에서 분쟁이 반복되는 이유도 결국 같은 지점에 있습니다.