"서비스가 죽었는데 아무도 몰랐어요. 고객이 먼저 전화로 알려줬습니다." 외주로 받은 서비스가 인계 직후 겪는 가장 허무한 사고예요. 백업도 있고 테스트도 있는데, 정작 "지금 서비스가 정상인지"를 보는 눈과 "문제가 생기면 누가 깨워주는지"가 통째로 빠진 거죠. 2026년 들어 GitHub Actions·클라우드 부분 장애가 잦아지면서, 이 모니터링·옵저버빌리티·온콜(장애 대응) 인계가 외주 분쟁의 새 1순위로 올라왔습니다. 오늘은 계약에 반드시 넣어야 할 8가지 항목을 정리해드려요.
백업은 "잃은 데이터를 되살리는" 사후 장치이고, 테스트는 "배포 전" 안전망이에요. 그런데 운영 중인 서비스가 지금 이 순간 건강한지는 둘 다 말해주지 않습니다. 옵저버빌리티는 보통 3가지로 나뉘어요 — 지표(metrics: CPU·응답시간·에러율), 로그(logs: 무슨 일이 있었나), 추적(traces: 요청이 어느 단계에서 느려졌나). 여기에 알림(alerting)과 온콜(on-call) 로테이션이 붙어야 "사람이 자다가도 깨서 고치는" 체계가 완성됩니다. 외주사가 떠나면 이 체계가 같이 사라지는 경우가 정말 많아요.
여기서 자주 어긋납니다. 발주자는 "모니터링을 해준다"를 누군가 지켜봐 준다로 이해하고, 개발사는 도구를 붙여준다로 이해해요. 계약서에 "모니터링 구축"이라고만 적혀 있으면 이 차이가 인계 시점에 드러납니다. 그래서 업체를 고르기 전에 RFP(제안요청서)에 “무엇을 받는지”를 문장으로 적어 둬야 해요. 계약서는 그 문장을 옮겨 적는 자리예요.
실제로 나뉘는 건 세 층이에요. 어디까지가 이번 계약 범위인지 견적 단계에서 문장으로 정해두세요.
| 층 | 무엇을 받나 | 누가 보나 | 비용 성격 |
|---|---|---|---|
| 도구 구축 | 대시보드·알림 규칙 설정, 로그 수집 파이프라인 | 아무도 안 봄. 설정만 됨 | 개발비에 1회 포함 |
| 알림 수신 | 장애가 나면 지정된 채널로 알림이 감 | 발주사 담당자 | 도구 구독료가 매달 |
| 온콜 대응 | 새벽에도 사람이 일어나 조치 | 외주사 또는 발주사 당번 | 별도 계약. 시간당 또는 월 정액 |
가장 흔한 오해가 1층만 받고 3층까지 된다고 생각하는 것이에요. 대시보드가 있어도 새벽에 보는 사람이 없으면 장애는 아침에 발견됩니다. "모니터링 포함"이라는 견적서를 받으면 "알림은 누구에게 가고, 새벽에는 누가 대응하나요?"를 그 자리에서 물어보세요.
개발비와 별개로 매달 나가는 돈이에요. 견적서에는 대개 안 적혀 있어서 인계 후에야 알게 됩니다.
| 항목 | 과금 방식 | 비용이 튀는 지점 |
|---|---|---|
| 로그 수집·보관 | 수집량(GB) + 보관 기간 | 디버그 로그를 그대로 다 보내면 급증한다 |
| 지표·대시보드 | 호스트 수 또는 시계열 개수 | 컨테이너가 늘어날 때마다 붙는다 |
| 알림·온콜 도구 | 사용자 수 | 팀이 커지면 선형으로 는다 |
| 합성 모니터링 | 체크 수 × 주기 | 1분 주기로 여러 흐름을 돌리면 커진다 |
구체적인 단가는 각 도구의 가격 페이지에서 확인하세요. 요금제가 자주 바뀌고 무료 구간도 제품마다 달라서, 여기 적어두면 금방 틀린 정보가 됩니다.
비용을 잡는 실무적인 방법은 보관 기간을 먼저 정하는 것이에요. 로그를 90일 들고 있어야 하는지 30일이면 되는지에 따라 금액이 크게 달라집니다. 감사 요구가 없다면 짧게 잡고, 필요한 것만 길게 보관하는 이중 정책이 대체로 저렴해요.
도구 이름보다 우리 팀이 그걸 계속 쓸 수 있는가가 기준이에요. 외주사가 익숙한 도구로 깔아놓고 떠나면, 남은 팀이 손을 못 대서 결국 방치됩니다.
도구 선정 자체보다 인계받을 때 무엇을 확인하는가가 실제로 중요합니다. 인계 자산 전반은 외주 인수인계 12자산 체크리스트에, 클라우드 계정 이관은 클라우드·인프라 인계 가이드에 정리했어요.
지연시간·트래픽·에러율·포화도(latency·traffic·errors·saturation) 4가지 골든 시그널을 한 화면에서 보는 대시보드를 인계받으세요. Grafana / Datadog / Vercel Analytics 중 무엇이든, 발주사 계정 소유로 넘어와야 합니다. 외주사 개인 계정에 걸려 있으면 떠나는 순간 깜깜이가 돼요.
로그가 print() 흩뿌리기가 아니라 JSON 구조화 로그(요청ID·사용자ID·레벨 포함)여야 검색이 됩니다. 보관 기간(예: 운영 30일·감사 1년)과 저장소(CloudWatch·Loki·Sentry)를 계약에 적으세요. 개인정보가 로그에 찍히지 않게 마스킹 규칙도 함께요(개인정보보호법 28조).
알림은 "에러율 5분간 2% 초과" 같은 구체 임계값 + 어느 채널(Slack·전화·PagerDuty)로 + 누구에게까지 정의돼야 합니다. 알림이 너무 많아 무시하게 되는 "알림 피로"를 막으려면, P1(즉시 전화)·P2(슬랙)·P3(아침 요약) 3단계로 나누세요.
인계 후 최소 30일은 외주사가 1차 온콜을 맡고, 그 사이 발주사 팀에 로테이션을 인계하도록 명문화하세요. "누가 언제 당번이고, 못 받으면 누구에게 에스컬레이션되는지" 표가 있어야 합니다.
자주 터지는 5개 시나리오(DB 커넥션 고갈·외부 API 장애·결제 실패 급증·배포 후 에러 폭증·디스크 풀)에 대해 "증상 → 확인 명령 → 조치 → 롤백" 런북을 문서로 받으세요. 새벽 3시에 처음 보는 에러를 디버깅하는 것과, 런북을 따라 5분 만에 복구하는 건 천지차이예요.
가용성 목표(예: 99.9%)와 응답시간 목표(p95 800ms)를 SLO로 합의하고, 이를 초과하는 장애가 며칠 안에 몇 회 이상이면 무상 대응 의무가 발생하는지 적으세요. 숫자가 없으면 "이게 장애냐 아니냐"로 매번 싸웁니다.
/health 엔드포인트만으로는 부족해요. 실제 사용자 흐름(로그인 → 핵심 기능 → 결제)을 1~5분마다 자동으로 찔러보는 합성 모니터링(synthetic check)을 걸어야, 첫 문단의 "고객이 먼저 알려주는" 사고를 막습니다.
잔금 지급 조건에 다음 6종을 묶으세요 — ⓐ 대시보드(발주사 계정) ⓑ 알림 규칙 + 채널 설정 ⓒ 온콜 로테이션 표 ⓓ 상위 5개 런북 ⓔ SLO 합의서 ⓕ 합성 모니터링 시나리오. 이게 다 있어야 "운영 가능한 상태"로 인계된 겁니다.
① 골든 시그널 대시보드가 우리 계정에 있는가 ② 로그가 구조화 + 보관 기간 명시인가 ③ 알림 임계값·채널·수신자가 정의됐는가 ④ 온콜 30일 1차 대응이 계약에 있는가 ⑤ 상위 5개 런북이 문서로 있는가 ⑥ SLO·에러버짓이 숫자로 합의됐는가 ⑦ 합성 모니터링이 핵심 흐름을 찌르는가 ⑧ 6종 자산이 잔금에 묶였는가.
포텐랩은 이 모니터링·온콜 6종 자산 묶음을 인계 잔금 표준으로 삼고 있어요. 97% 수행완수율과 모든 과정을 Notion으로 투명하게 공유하는 방식 그대로요. 운영까지 안심하고 받고 싶다면 포텐랩에 편하게 문의 주세요. 실제 사례는 포트폴리오에서 확인하실 수 있습니다.
세 층으로 나뉘어요. 도구 구축(대시보드·알림 규칙 설정), 알림 수신(장애가 나면 지정 채널로 알림), 온콜 대응(새벽에도 사람이 일어나 조치)입니다. 가장 흔한 오해가 1층만 받고 3층까지 된다고 생각하는 거예요. 대시보드가 있어도 새벽에 보는 사람이 없으면 장애는 아침에 발견됩니다. 견적서에 모니터링 포함이라고 적혀 있으면 알림은 누구에게 가고 새벽에는 누가 대응하는지 물어보세요.
옵저버빌리티는 지표(CPU·응답시간·에러율), 로그(무슨 일이 있었나), 추적(요청이 어느 단계에서 느려졌나) 세 가지로 나뉩니다. 여기에 알림과 온콜 로테이션이 붙어야 사람이 자다가도 깨서 고치는 체계가 완성돼요. 백업은 잃은 데이터를 되살리는 사후 장치이고 테스트는 배포 전 안전망이라, 둘 다 지금 서비스가 건강한지는 말해주지 않습니다.
개발비와 별개로 매달 나갑니다. 로그는 수집량과 보관 기간, 지표는 호스트 수, 알림 도구는 사용자 수, 합성 모니터링은 체크 수와 주기로 과금돼요. 구체적 단가는 요금제가 자주 바뀌니 각 도구의 가격 페이지에서 확인하세요. 비용을 잡는 실무적 방법은 보관 기간을 먼저 정하는 것입니다.
여섯 가지를 잔금 조건에 묶으세요. 대시보드(발주사 계정), 알림 규칙과 채널 설정, 온콜 로테이션 표, 상위 5개 장애 런북, SLO 합의서, 합성 모니터링 시나리오입니다. 특히 대시보드가 외주사 개인 계정에 걸려 있으면 그들이 떠나는 순간 깜깜이가 되니 계정 명의를 반드시 확인하세요.
최소 30일은 외주사가 1차 온콜을 맡고 그 사이 발주사 팀에 로테이션을 인계하도록 명문화하는 게 안전해요. 누가 언제 당번이고 못 받으면 누구에게 에스컬레이션되는지 표로 정리돼 있어야 합니다. 31일 차부터 발주사만 받을지, 외주사가 시간당 단가로 비상 대응을 이을지도 함께 정하세요.
알림 피로를 막으려면 등급을 나누세요. P1은 즉시 전화, P2는 슬랙, P3는 아침 요약처럼 3단계로 구분합니다. 그리고 임계값을 구체적으로 정하세요. 에러율 5분간 2퍼센트 초과처럼 숫자로 적어야 합니다. 라우팅을 바꾼 다음에는 반드시 테스트 알림을 한 번 쏴서 실제로 도착하는지 확인하세요.
인계 단계별로 더 깊이 들여다보면 좋은 글들이에요.