"가동률 99.9%"라는 계약 문구가 아무것도 보장하지 못하는 이유
계약서에 "월 가동률 99.9% 보장"이라고 적혀 있는 프로젝트는 흔합니다. 그런데 그 문장 하나로는 실제 장애 상황에서 아무것도 결정되지 않습니다. 무엇을 가동으로 볼지, 누가 측정할지, 측정 실패 시 누구 말이 맞는지가 정의되어 있지 않기 때문입니다.
측정 기준이 없는 숫자는 분쟁만 남깁니다. 99.9%는 30일 기준 월 43분의 다운타임을 허용합니다. 그런데 이 43분을 "서버 프로세스가 죽어 있던 시간"으로 재느냐, "사용자가 주문을 완료하지 못한 시간"으로 재느냐에 따라 결과는 10배 이상 벌어집니다. 실제로 헬스체크 엔드포인트는 200을 반환하는데 결제 PG 연동만 끊겨 매출이 3시간 동안 0원이었던 사례가 드물지 않습니다. 서버는 "정상"이었으므로 계약상 가동률은 100%로 집계됩니다.
반대 상황도 있습니다. 인프라 팀은 야간 배포 중 5분 재시작을 장애로 기록했지만, 그 시간대 실사용자는 2명이었고 둘 다 재시도로 성공했습니다. 이 5분은 사용자 경험 관점에서 사실상 무해합니다. 측정 대상이 서버가 아니라 사용자 여정이어야 하는 이유입니다.
여기에 한 가지가 더 겹칩니다. 개발은 끝났는데 운영 책임이 정해지지 않은 채 인수인계된 프로젝트입니다. 장애가 나면 고객사는 개발사에 연락하고, 개발사는 "계약 범위가 아니다"라고 답하고, 그 사이 서비스는 멈춰 있습니다. 운영 체계는 개발 완료 시점이 아니라 개발 착수 시점에 설계되어야 합니다.
SLI·SLO를 실제로 정하는 순서
1단계: 핵심 경로 3~5개 선정
모든 API를 측정하려 들면 아무것도 관리하지 못합니다. 서비스의 수익과 직결되는 사용자 여정만 고릅니다. 커머스라면 로그인 → 상품 조회 → 장바구니 → 주문 → 결제입니다. B2B 시스템이라면 로그인, 데이터 조회, 리포트 생성, 배치 처리 정도입니다. 5개를 넘기면 관리 비용이 효익을 넘어섭니다.
2단계: 경로별 지표 선택
경로마다 봐야 할 지표가 다릅니다.
측정 위치도 정해야 합니다. 서버 로그 기준과 클라이언트 실측 기준은 다른 숫자를 냅니다. 사용자 관점을 대표하려면 로드밸런서 이상 지점에서 재는 것이 안전합니다.
3단계: 목표치를 100%로 잡지 않기
목표를 100%로 두면 모든 변경이 위험 요소가 되어 배포가 멈춥니다. 99.9%로 잡으면 월 43분의 에러 버짓이 생깁니다. 이 버짓이 남아 있으면 새 기능을 배포하고, 소진되면 배포를 멈추고 안정화에 투입합니다. 목표치가 릴리스 속도를 조절하는 실무 장치가 되는 지점입니다.
경로별로 목표를 다르게 잡아야 합니다. 결제는 99.95%, 상품 조회는 99.5%, 리포트 생성은 99%로 두는 편이 현실적입니다. 모든 경로에 같은 숫자를 적용하면 가장 비싼 요구사항이 전체 비용을 결정합니다.
4단계: SLA와 SLO를 분리
SLA는 계약이고 SLO는 운영 기준입니다. 이 둘을 같은 숫자로 두면 SLO를 놓친 순간이 곧 계약 위반이 됩니다. 내부 SLO는 계약 SLA보다 한 단계 엄격하게 잡습니다. SLA가 99.5%라면 SLO는 99.9%로 두는 식입니다. 이 완충 구간이 계약 위반 이전에 대응할 시간을 만들어 줍니다.
새벽 3시에 누가 어떻게 대응하는가
온콜 로테이션의 현실
교과서적인 온콜은 최소 6명이 주 단위로 순환하는 구조입니다. 그래야 개인당 6주에 한 번 당번이 돌아옵니다. 3명 이하로 돌리면 번아웃이 확정적입니다.
인력이 부족한 조직의 현실적 대안은 이렇습니다.
알림 설계: 깨울 것과 아침에 볼 것
온콜이 무너지는 가장 흔한 원인은 인력이 아니라 알림 피로입니다. 하루 50건씩 오는 알림 중 실제 조치가 필요한 것이 2건이면, 사람은 곧 전부를 무시하게 됩니다.
호출 알림은 반드시 "증상 기반"으로 작성합니다. "CPU 80% 초과"가 아니라 "결제 성공률 5분간 90% 미만"이 좋은 호출 조건입니다. 전자는 무해할 수 있고 후자는 반드시 문제입니다.
심각도와 역할 분리
| 등급 | 정의 | 대응 | 고객 공지 |
|------|------|------|----------|
| S1 | 서비스 전면 중단, 데이터 유실 | 즉시 호출, 전원 소집 | 30분 내 |
| S2 | 핵심 기능 일부 장애 | 즉시 호출 | 1시간 내 |
| S3 | 부가 기능 장애, 우회 가능 | 업무 시간 대응 | 요청 시 |
| S4 | 성능 저하, 사용자 영향 미미 | 백로그 등록 | 불필요 |
S1·S2에서는 역할을 반드시 분리합니다. 장애를 고치는 사람과 상황을 알리는 사람이 같으면 둘 다 실패합니다. 대응 지휘(Incident Commander), 기술 조치, 고객 커뮤니케이션을 최소 2명 이상으로 나눕니다.
런북이 실제로 쓰이려면
대부분의 런북은 작성 후 한 번도 열리지 않습니다. 실제로 쓰이는 런북에는 공통점이 있습니다.
같은 장애를 두 번 겪지 않는 조직
비난 없는 포스트모템
원인을 사람으로 지목하는 순간 조직은 정보를 감추기 시작합니다. "왜 그렇게 했는가"가 아니라 "그 시점에 그 판단이 합리적으로 보인 이유는 무엇인가"를 묻습니다. 담당자가 잘못된 명령을 실행할 수 있었다면 그것은 개인의 부주의가 아니라 그런 명령을 막지 못한 시스템의 문제입니다.
포스트모템 문서에 반드시 들어갈 항목은 다음과 같습니다.
S1은 예외 없이, S2는 반복되면 작성합니다. 발생 후 5영업일 내 작성이 현실적인 기준입니다.
재발 방지 과제가 사라지지 않게
포스트모템의 실패는 대부분 마지막 단계에서 일어납니다. 과제를 백로그에 넣고 기능 개발에 밀려 6개월 후 그대로 남아 있는 상황입니다.
MTTR보다 유용한 지표들
MTTR(평균 복구 시간)은 장애 건수가 적으면 통계적으로 무의미하고, 큰 장애 하나에 쉽게 왜곡됩니다. 다음 지표가 더 실질적입니다.
내부 인력이 부족한 조직의 선택지
| 방식 | 월 비용 감각 | 책임 범위 | 적합한 경우 |
|------|------------|----------|-----------|
| 자체 운영 | 인력 2~3명 인건비 | 전면 | 서비스가 사업의 핵심이고 인력 확보가 가능한 경우 |
| MSP | 인프라 규모 비례 | 인프라 계층 중심 | 서버·네트워크 운영만 위임하고 애플리케이션은 내부 처리 |
| 유지보수 계약 | 개발비의 연 10~15% | 버그 수정 중심 | 변경이 적고 안정화된 시스템 |
| 구독형 운영 | 정액 | 모니터링·장애 대응·개선 | 변경이 계속 발생하며 전담 인력을 두기는 이른 규모 |
MSP는 서버가 살아 있는지는 봐 주지만 결제 성공률이 떨어진 것은 대개 감지하지 못합니다. 애플리케이션 레벨 SLO를 함께 볼 주체가 누구인지 계약 단계에서 명확히 해야 합니다.
인수인계 시 반드시 받아야 할 산출물
개발사에서 운영을 넘겨받을 때 다음이 없으면 인수인계가 완료된 것이 아닙니다.
특히 롤백 절차서와 인증서 만료일이 누락되는 경우가 많습니다. 인증서 만료로 인한 전면 중단은 매년 반복되는 대표적 장애 유형입니다.
POLYGLOTSOFT와 함께 운영 체계를 만드십시오
POLYGLOTSOFT는 개발 착수 시점부터 운영을 함께 설계합니다. 핵심 경로 SLI/SLO 정의, 증상 기반 알림 체계, 장애 등급별 런북, 포스트모템 프로세스를 프로젝트 산출물에 포함하여 전달합니다.
개발이 끝난 뒤에는 SM 플랜으로 운영을 이어받습니다. Basic SM(월 9만원) 은 버그 수정과 서버 모니터링을, Standard SM(월 19만원) 은 장애 대응과 복구를, Pro SM(월 39만원) 은 성능 모니터링과 DB 튜닝을 전담 PM과 함께 제공합니다. Team SM(월 79만원) 은 인프라 확장과 온사이트 대응까지 포함합니다.
이미 운영 중인 시스템의 신뢰성 체계 진단부터 시작하셔도 좋습니다. [POLYGLOTSOFT](https://polyglotsoft.dev)에 문의하시면 현재 모니터링 구성과 장애 대응 절차를 검토하고 개선 로드맵을 제안해 드립니다.