외주개발 유지보수 SLA 설계 가이드: 장애 대응·버그 수정·서버 운영 계약 기준
답부터 말하면, 외주개발 유지보수 SLA는 ‘월 몇 시간 봐준다’는 문장이 아니라 장애 등급, 최초 응답, 임시 복구, 완전 수정, 백업, 배포 권한, 제외 범위를 숫자와 책임자로 고정하는 운영 계약서입니다. 웹·앱·SaaS MVP에서 결제, 예약, 매칭, 관리자 승인, 알림 같은 기능이 매출이나 CS와 연결돼 있다면 개발 계약 체결 전 유지보수 부속합의서를 따로 만들어야 합니다. 그렇지 않으면 출시 후 ‘버그인지 기능개선인지’, ‘서버 장애인지 개발 오류인지’, ‘주말 장애도 대응해야 하는지’를 매번 다시 협상하게 됩니다.
1. 월 유지보수보다 먼저 봐야 할 것: SLA의 역할
SLA, 즉 서비스 수준 계약은 개발사가 얼마나 빨리 문의에 답하고, 어떤 장애를 먼저 처리하며, 어떤 목표시간 안에 임시 또는 완전 복구를 시도할지 정하는 기준입니다. Atlassian도 SLA를 고객 요청에 대한 응답과 해결 목표시간을 추적·관리하는 장치로 설명하며, SLA 목표는 작업 항목에 응답하거나 해결하기 위해 정한 목표시간이라고 정리합니다. ([support.atlassian.com](https://support.atlassian.com/customer-service-management/docs/create-slas/))
외주개발에서 자주 생기는 문제는 유지보수라는 단어가 너무 넓다는 점입니다. 어떤 업체는 월 유지보수에 서버 모니터링, 버그 수정, 소규모 문구 수정, 라이브러리 업데이트, 배포를 모두 포함한다고 말합니다. 반대로 어떤 업체는 월 비용이 단순 질의응답과 긴급 장애 확인만 의미하고, 실제 수정은 별도 견적으로 처리합니다. 둘 다 틀렸다고 할 수는 없습니다. 문제는 계약 전에 기준을 쓰지 않았다는 데 있습니다.
KOSA의 서비스수준 기반 ITO서비스대가 모델도 서비스등급과 서비스수준은 수요자와 제공자가 기준에 맞게 합의하여 선택할 수 있다고 설명합니다. 애플리케이션뿐 아니라 IT인프라까지 포함하고, 서비스수준에 따라 대가가 달라지는 구조라는 점은 민간 외주개발 유지보수에도 그대로 적용할 수 있는 사고방식입니다. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/View.do?bcIdx=50760&cbIdx=276))
2. 계약서에 들어가야 할 핵심 용어
대표나 PM이 SLA를 검토할 때는 기술 용어 자체보다 ‘운영 의사결정에 어떤 영향을 주는가’를 봐야 합니다. 아래 용어는 견적서, 계약서, 운영 매뉴얼에 같은 뜻으로 쓰이게 맞춰야 합니다.
| 용어 | 운영상 의미 | 계약서에 적을 내용 |
|---|---|---|
| SLA | 서비스 지원 수준에 대한 약속 | 지원시간, 장애 등급, 응답·복구 목표, 제외 범위, 보고 방식 |
| 최초 응답시간 | 담당자가 장애를 확인하고 접수했다는 첫 회신까지의 시간 | 영업시간 기준인지 24시간 기준인지, 전화·메신저·티켓 중 어느 채널인지 |
| 기술 착수시간 | 실제 로그 확인, 롤백, 서버 조치 등 기술 대응이 시작되는 시간 | 단순 답변과 실제 조치를 구분 |
| 임시 복구 | 서비스를 완전 수정하지 않아도 고객 피해를 줄이는 우회 조치 | 롤백, 기능 차단, 수동 결제 처리, 공지 노출, 캐시 비우기 등 |
| 완전 해결 | 원인 수정, 재배포, 재발 방지까지 끝난 상태 | 코드 수정, 테스트, 배포, 사후보고 포함 여부 |
| RTO | 서비스 중단 후 허용 가능한 최대 복구 지연 시간 | 전체 장애, 결제 장애, 관리자 장애별 목표시간 |
| RPO | 장애 발생 시 어느 시점의 데이터까지 복구할 수 있어야 하는지 | 백업 주기, 보관기간, 복구 테스트 주기 |
AWS는 RTO를 서비스 중단과 복구 사이의 최대 허용 지연시간, RPO를 마지막 복구 지점 이후 허용 가능한 데이터 손실 시간으로 정의합니다. 즉 RTO는 ‘얼마나 빨리 살릴 것인가’, RPO는 ‘데이터를 얼마나 잃어도 되는가’의 문제입니다. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html))
3. 장애 대응 SLA는 접수부터 사후보고까지 이어져야 한다
좋은 SLA는 ‘장애 나면 바로 대응’ 같은 문장이 아니라 실제 흐름을 가집니다. 최소한 다음 7단계를 문서화해야 합니다.
- 감지: 고객 문의, 관리자 알림, 서버 모니터링, 결제사 웹훅 오류 중 무엇으로 장애를 인지하는가.
- 접수: 카카오톡, 슬랙, 전화, 이메일, 티켓 중 공식 채널은 무엇인가.
- 등급 판정: 전체 장애인지, 핵심 기능 일부 장애인지, 단순 UI 버그인지 누가 판단하는가.
- 초동 응답: 접수 확인, 현재 영향 범위, 다음 업데이트 예정 시간을 알려주는가.
- 임시 조치: 롤백, 서버 재시작, 특정 기능 차단, 수동 처리 등 고객 피해를 줄이는 조치를 수행하는가.
- 완전 수정: 원인 수정, 테스트, 배포, 데이터 정합성 확인을 완료하는가.
- 사후보고: 원인, 영향 범위, 재발 방지, 추가 비용 여부를 보고서로 남기는가.
NIST의 업무영향분석 관점도 시스템 중단 시 업무 프로세스에 미치는 영향, 허용 가능한 다운타임, 복구에 필요한 자원과 우선순위를 식별하는 것을 강조합니다. 작은 스타트업이라도 이 관점을 적용하면 어떤 기능을 먼저 살려야 하는지 합의할 수 있습니다. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf))
4. 장애 등급은 기능 이름이 아니라 사업 영향으로 나눈다
장애 등급은 개발자가 보기 어려운 기술 난이도보다 발주사가 겪는 사업 영향을 기준으로 나눠야 합니다. Atlassian은 심각도를 사용자 영향의 측정으로, 우선순위를 얼마나 빨리 고쳐야 하는지의 측정으로 구분합니다. 전체 서비스 중단은 심각도와 우선순위가 모두 높지만, 메인 배너 오탈자처럼 기능 영향은 낮아도 브랜드 이슈로 우선순위가 높을 수 있습니다. ([atlassian.com](https://www.atlassian.com/incident-management/kpis/severity-levels))
| 등급 | 예시 | 최초 응답 기준 예시 | 복구 목표 설계 | 주의점 |
|---|---|---|---|---|
| SEV1 긴급 | 전체 접속 불가, 결제 승인 오류, 예약 불가, 데이터 손상 의심, 개인정보 노출 의심 | 24시간 대응 계약이면 15~30분, 영업시간 계약이면 업무시간 내 즉시 | 완전 수정 전이라도 롤백·기능 차단·수동처리로 임시 복구 목표를 별도 설정 | 24시간 대기 인력이 필요하면 월 비용이 달라짐 |
| SEV2 높음 | 일부 고객군 로그인 불가, 관리자 핵심 기능 오류, 특정 PG 또는 알림 연동 실패 | 2~4시간 또는 당일 업무시간 내 | 당일 또는 다음 영업일 내 우회복구와 수정 계획 공유 | 영향 고객 수와 매출 영향 기준을 함께 적어야 함 |
| SEV3 보통 | 화면 깨짐, 특정 조건에서 저장 실패, 통계 수치 일부 오류, 관리자 불편 | 1영업일 내 | 정기 배포 또는 다음 패치 일정에 포함 | 무상 하자인지 개선 요청인지 분류 필요 |
| SEV4 낮음 | 문구 수정, 도움말 변경, 비핵심 UI 개선, 운영자 편의 요청 | 2~3영업일 내 검토 | 백로그 등록 후 별도 견적 또는 월 개선 한도 내 처리 | 유지보수 범위에 넣을지 기능개선으로 볼지 명확히 해야 함 |
위 표의 시간은 모든 서비스에 적용할 정답이 아니라 계약 설계를 위한 출발점입니다. 이용자가 적은 검증용 MVP에 24시간 SEV1 대응을 붙이면 비용이 과도할 수 있고, 반대로 결제·예약 서비스가 업무시간 대응만 계약하면 금요일 밤 장애가 월요일까지 방치될 수 있습니다.
5. 월 유지보수 비용은 ‘몇 퍼센트’보다 범위로 판단한다
월 유지보수 비용이 적정한지 보려면 개발비 대비 비율보다 같은 범위를 비교해야 합니다. 유지보수 견적서에 아래 항목이 빠져 있으면 저렴해 보여도 실제 운영비는 출시 후 계속 늘어날 수 있습니다.
| 구분 | 포함되는 일 | 적합한 서비스 | 견적 검토 포인트 |
|---|---|---|---|
| 기본형 | 업무시간 문의, 경미한 버그 확인, 월 1회 정기 점검, 간단한 문구 수정 | 회사 홈페이지, 초기 MVP, 내부 테스트 도구 | 긴급 장애와 서버 운영이 별도인지 확인 |
| 운영형 | 서버 모니터링, 백업 확인, 정기 배포, 결제·알림 연동 점검, 관리자 오류 대응 | SaaS MVP, 예약·매칭 서비스, 관리자 대시보드 | 배포 횟수, 테스트 범위, 응답시간을 수치화 |
| 비즈니스 핵심형 | 온콜, 장애 회의방, 사후보고, RTO/RPO 기준, 롤백 전략, 보안·라이브러리 업데이트 계획 | 매출 발생 서비스, B2B SaaS, 결제·정산·AI 판정 기능 포함 서비스 | 24시간 대응 인력과 보상 기준을 별도 산정 |
KOSA가 2025년 SW사업 대가산정 가이드 개정에서 개발비와 운영·유지관리비를 분리해 합산하는 대가기준을 마련했다고 밝힌 점도 참고할 만합니다. 민간 외주에서도 개발과 운영은 같은 개발사가 맡더라도 비용 성격이 다릅니다. 개발비는 기능을 만드는 비용이고, 유지보수비는 장애 가능성, 대기 책임, 배포 리스크, 운영 보고를 감당하는 비용입니다. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/View.do?bcIdx=63625&cbIdx=379))
6. 무상 하자보수와 유상 기능개선은 이렇게 나눈다
출시 후 분쟁의 상당수는 ‘이게 버그냐, 새 기능이냐’에서 시작됩니다. 계약서에는 검수 기준과 요구사항 명세서를 기준으로 하자보수와 기능개선을 나눠야 합니다. 요구사항 정리가 약하면 하자보수 범위도 흐려집니다.
| 항목 | 무상 하자보수에 가까운 경우 | 유상 기능개선에 가까운 경우 |
|---|---|---|
| 로그인 | 명세서상 이메일 로그인인데 정상 계정도 로그인 불가 | 카카오·네이버·애플 로그인을 새로 추가 |
| 결제 | 결제 승인 후 주문 데이터가 생성되지 않음 | 새 PG사 추가, 정기결제 정책 변경, 쿠폰 로직 추가 |
| 관리자 | 검수된 검색 조건이 작동하지 않음 | 새 통계 지표, 권한 그룹, 엑셀 양식 추가 |
| 성능 | 합의한 기본 데이터량에서 화면이 오류로 중단됨 | 출시 후 트래픽 급증에 맞춘 구조 개선, 캐시·검색엔진 도입 |
| 외부 API | 개발 오류로 연동 파라미터를 잘못 전송 | 외부 API 정책 변경, 요금제 변경, 인증방식 개편 대응 |
핵심은 기준 문서입니다. 기능목록, 화면정의서, API 명세, 관리자 권한표, 검수 시나리오가 있어야 ‘계약된 동작’과 ‘새로운 요구’를 구분할 수 있습니다. 계약 조항의 큰 틀은 외주개발 계약서 필수 조항 체크리스트를 함께 확인하면 좋습니다.
7. 서버·도메인·소스코드 권한은 유지보수의 핵심이다
SLA가 좋아 보여도 운영 권한이 정리되지 않으면 실제 장애 때 아무것도 못 할 수 있습니다. 특히 초기 창업팀은 개발사 계정으로 클라우드, 도메인, 앱스토어, PG, Git 저장소를 만들고 나중에 이전하려다 지연되는 경우가 있습니다. 원칙은 발주사 명의의 계정에 개발사 권한을 위임하는 구조입니다.
- 소스코드: 발주사 소유 Git 저장소를 만들고 개발사는 권한을 부여받습니다. 브랜치 전략, 배포 태그, 릴리즈 노트를 남깁니다.
- 클라우드: 루트 계정은 발주사가 보유하고, 개발사는 IAM 계정 또는 프로젝트 권한을 사용합니다.
- DB와 백업: 백업 주기, 보관기간, 암호화, 복구 테스트, 접근 로그 확인 책임을 명시합니다.
- 도메인·DNS: 도메인 소유자, 네임서버, SSL 인증서 갱신, DNS 변경 승인자를 정합니다.
- 외부 서비스: PG, 문자·알림톡, 이메일, 지도, AI API, 앱스토어, 광고 픽셀 계정 소유를 정리합니다.
- 배포 권한: 누가 언제 배포할 수 있는지, 긴급 배포와 정기 배포 승인 절차를 나눕니다.
계약이 끝날 때 받을 산출물과 권한 목록은 유지보수 SLA와 한 세트입니다. 소스코드·서버·DB·배포 문서 확인 항목은 외주개발 인수인계 체크리스트를 참고해 프로젝트 초기에 역으로 준비하는 편이 안전합니다.
8. 계약서에 넣을 수 있는 SLA 문장 예시
아래 문장은 법률 자문이 아니라 실무 협의를 위한 예시입니다. 실제 계약에는 서비스 특성, 관할, 손해배상 한도, 개인정보 처리위탁, 보안 요구사항을 포함해 전문가 검토를 거치는 것이 좋습니다.
장애 등급은 서비스 영향도 기준으로 SEV1부터 SEV4까지 구분한다. 전체 서비스 중단, 결제·예약·정산 불가, 데이터 손상 또는 개인정보 침해 의심은 SEV1로 본다. 수행사는 공식 채널 접수 후 합의된 지원시간 내 최초 응답을 제공하고, SEV1의 경우 임시 복구 또는 우회처리 방안을 우선 제시한다.
복구 목표는 완전 해결시간만을 의미하지 않는다. 수행사는 롤백, 기능 차단, 수동 처리, 공지 노출 등 고객 피해를 줄이는 임시 조치를 우선 수행할 수 있으며, 완전 수정은 원인 분석, 코드 수정, 테스트, 배포, 재발 방지 조치가 완료된 상태로 본다.
유지보수 범위에는 검수 기준에 반하는 결함 수정, 운영 중 발견된 오류 확인, 정기 배포 지원, 서버 상태 점검을 포함한다. 신규 기능, 업무 정책 변경, 외부 API 정책 변경, 대규모 성능 개선, 디자인 전면 변경, 데이터 이관은 별도 견적으로 협의한다.
9. 계약 전 체크리스트
견적 비교 전에 아래 항목을 체크하면 유지보수 비용이 왜 다른지 더 명확해집니다.
- 서비스에서 멈추면 안 되는 핵심 기능 3개를 정했는가.
- SEV1, SEV2, SEV3, SEV4의 예시를 우리 서비스 기준으로 썼는가.
- 최초 응답, 기술 착수, 임시 복구, 완전 해결을 구분했는가.
- 지원시간이 평일 업무시간인지, 야간·주말·공휴일 포함인지 정했는가.
- 장애 접수 공식 채널과 담당자 연락망을 정했는가.
- 서버 모니터링, 알림 설정, 로그 보관 책임을 정했는가.
- RTO와 RPO를 핵심 기능별로 다르게 정했는가.
- 백업 복구 테스트를 누가 언제 수행하는지 정했는가.
- 무상 하자보수 기간과 범위를 검수 기준과 연결했는가.
- 월 유지보수에 포함되는 배포 횟수와 테스트 범위를 정했는가.
- 소스코드, 클라우드, 도메인, 앱스토어, PG 계정 소유자가 발주사인지 확인했는가.
- AI API, 결제, 문자, 이메일 같은 외부 서비스 장애의 책임 경계를 정했는가.
- 보안 업데이트와 라이브러리 업데이트를 정기 작업으로 볼지 별도 작업으로 볼지 정했는가.
- 사후보고서 양식과 재발 방지 조치 범위를 정했는가.
- 유지보수 종료 또는 업체 변경 시 인수인계 자료 목록을 정했는가.
초기 예산을 잡는 단계라면 외주개발 비용 산정 방법과 함께 개발비, 운영비, 클라우드비, 외부 API 비용을 분리해서 보는 것이 좋습니다. 한 줄짜리 월 유지보수비보다 어떤 업무가 포함되는지 보는 쪽이 실제 의사결정에 도움이 됩니다.
10. AgentMit이 유지보수 SLA를 볼 때 확인하는 것
AgentMit은 외주개발을 단발성 납품보다 실제 운영 가능한 서비스로 보는 편입니다. 예약·매칭·결제 시스템, SaaS MVP, 관리자 대시보드, CRM·업무자동화, AI 기능이 포함된 서비스는 출시 후 장애 대응과 데이터 운영이 제품 가치의 일부가 됩니다. 그래서 범위 검토 단계에서 기능목록뿐 아니라 관리자 권한, 데이터 흐름, 배포 방식, 서버 계정 소유, 백업 기준, 운영자 업무까지 같이 확인합니다.
BizMit 기반 업무 시스템이나 맞춤형 SaaS를 검토하는 팀이라면 처음부터 모든 SLA를 무겁게 설계할 필요는 없습니다. 다만 핵심 기능이 무엇인지, 어떤 장애가 사업에 치명적인지, 월 유지보수에 어디까지 포함할지 정도는 견적 전 정리해야 합니다. AgentMit은 기획, UI, 백엔드, 관리자 화면, 자동화, AI 연동, 배포, 유지보수 구조를 하나의 운영 흐름으로 검토할 수 있습니다.
이미 외주개발 견적서를 받은 상태라면 유지보수 항목만 따로 검토해도 좋습니다. 개발 범위, MVP 견적, 실서비스 개발과 운영 구조 상담이 필요하다면 AgentMit 제작 문의 또는 BizMit 안내를 통해 현재 기능목록과 운영 우선순위를 공유해 주세요.
FAQ
Q1. 외주개발 유지보수 SLA는 꼭 계약서에 넣어야 하나요?
예약, 결제, 매칭, 관리자 승인, SaaS 과금처럼 장애가 곧 매출·CS·정산 문제로 이어지는 서비스라면 넣는 편이 안전합니다. 단순 홍보용 웹사이트도 서버, 도메인, 백업, 보안 업데이트 책임은 최소한 별도 문서로 정해야 합니다.
Q2. 월 유지보수 비용은 개발비의 몇 퍼센트가 적정한가요?
개발비 대비 비율만으로 판단하면 위험합니다. 지원시간, 장애 등급, 배포 횟수, 모니터링·백업 책임, 기능개선 포함 여부, 외부 API·결제 연동 수, 코드 품질과 문서 수준에 따라 비용 구조가 달라집니다. 같은 금액이어도 24시간 긴급 대응 포함 여부에 따라 전혀 다른 계약입니다.
Q3. 긴급 장애 응답시간과 복구시간은 어떻게 정하나요?
전체 서비스 중단, 결제 오류, 데이터 손상 의심 등 SEV1은 최초 응답, 기술 착수, 임시 우회복구, 완전 해결 목표를 분리해 정해야 합니다. 모든 장애를 몇 시간 내 완전 해결로 약속하기보다는 롤백, 결제 수동처리, 기능 차단 등 우회복구 기준을 함께 두는 것이 현실적입니다.
Q4. 무상 하자보수와 유상 기능개선의 기준은 무엇인가요?
계약된 요구사항과 검수 기준대로 동작하지 않는 결함은 하자보수에 가깝고, 새로운 업무 절차·화면·통계·연동·정책 변경은 기능개선에 가깝습니다. 외부 API 변경, OS 업데이트, 트래픽 급증, 보안 패치처럼 애매한 항목은 계약서의 예외·별도 견적 조항에 넣어야 분쟁이 줄어듭니다.
Q5. 서버·도메인·소스코드 계정은 누가 소유해야 하나요?
원칙적으로 발주사 명의의 클라우드, 도메인, 앱스토어, PG, Git 저장소를 만들고 개발사는 필요한 권한만 위임받는 구조가 안전합니다. 개발사가 모든 계정을 소유하면 담당자 변경, 계약 종료, 분쟁 시 배포와 복구가 막힐 수 있습니다.
참고 기준
이 글은 특정 업체의 가격표가 아니라 공개된 서비스수준, 재해복구, 업무영향분석, SW 대가산정 자료를 외주개발 운영 계약 관점으로 재구성했습니다.
- KOSA 서비스수준 기반 ITO서비스대가 산정 가이드: 서비스등급과 서비스수준 합의, 애플리케이션·인프라 운영 범위 참고. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/View.do?bcIdx=50760&cbIdx=276))
- KOSA SW사업 대가산정 가이드 2025년 개정판 공표: 개발비와 운영·유지관리비 분리 관점, AI·데브옵스 운영 범위 참고. ([sw.or.kr](https://www.sw.or.kr/site/sw/ex/board/View.do?bcIdx=63625&cbIdx=379))
- AWS Well-Architected Reliability Pillar: RTO와 RPO 정의 참고. ([docs.aws.amazon.com](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html))
- NIST SP 800-34 Rev. 1: 업무영향분석, 복구 우선순위, 백업·복구 계획 관점 참고. ([nvlpubs.nist.gov](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-34r1.pdf))
- Atlassian SLA 및 Incident Severity 자료: 응답·해결 목표, 심각도와 우선순위 구분 참고. ([support.atlassian.com](https://support.atlassian.com/customer-service-management/docs/create-slas/))
