작은 SaaS의 SLO와 에러 버짓을 배포 판단으로 연결하는 법

작은 SaaS의 SLO는 거창한 대시보드가 아니라 ‘사용자가 핵심 작업을 성공했는가’를 측정하는 약속이어야 합니다. 먼저 한 달의 유효 요청 수와 실패 허용량을 정하고, 에러 버짓이 남아 있을 때는 변경을 진행하며 소진되면 안정화 작업을 우선합니다.

이 글의 결과물은 서비스별 SLO 한 장, 버짓 계산표, 배포 중단 조건입니다. Google의 SRE 설명처럼 SLO는 서비스 수준 목표와 실제 관측값의 차이를 운영 의사결정에 쓰는 장치이며, 숫자를 정한 뒤 어떤 행동을 할지까지 연결해야 합니다.공식 개념은 여기에서 확인할 수 있습니다.

무엇을 SLO로 삼을지 먼저 좁히기

모든 내부 지표를 SLO로 만들면 팀은 숫자를 관리하느라 사용자 문제를 놓칩니다. 로그인 성공, 결제 완료, 파일 다운로드처럼 사용자가 완료 여부를 분명히 판단하는 한두 개의 여정을 먼저 선택합니다. 요청 수가 적은 기능은 비율보다 성공 건수와 실패 원인을 함께 기록해 표본 부족을 드러냅니다.

좋은 지표에는 측정 경계가 있습니다. 예를 들어 결제 SLO에서 외부 결제사의 승인 지연을 우리 서비스 오류로 볼지, 승인 요청을 정상적으로 전달한 시점까지만 볼지 결정해야 합니다. 경계를 문서에 적지 않으면 같은 장애를 두 팀이 서로 다른 숫자로 보고합니다.

에러 버짓을 계산표로 고정하기

월간 유효 요청이 100,000건이고 가용성 SLO가 99.9%라면 허용 실패는 100건입니다. 버짓은 ‘장애가 나도 된다’는 허가가 아니라 신뢰성 투자와 변경 속도를 교환하는 회계 단위입니다. 봇·헬스체크·취소된 요청을 분모에서 제외한다면 제외 조건도 같은 표에 적습니다.

1. 기간과 분모를 정하고 성공·실패 이벤트의 이름을 고정합니다.

2. 목표에서 허용 실패량을 계산해 배포 기록에 남깁니다.

3. 버짓 소진 구간별로 관찰, 승인 필요, 변경 동결의 상태를 정합니다.

버짓 상태를 배포 정책으로 바꾸기

버짓이 75% 미만이면 계획된 변경을 진행하되 변경 후 측정 창을 남깁니다. 75~100%에서는 영향이 작은 변경만 승인자가 확인하도록 하고, 100%를 넘으면 새 기능보다 원인 제거와 용량·알림 개선을 우선합니다. 이 임계치는 권고값이므로 트래픽 변동과 팀의 복구 능력에 맞춰 재평가합니다.

에러 버짓은 누적값만 보지 말고 시간 창을 함께 봐야 합니다. 30일 중 하루에 실패가 몰렸다면 월말 평균이 정상처럼 보여도 최근 변경을 멈춰야 합니다. 대시보드에는 현재 버짓, 소진 속도, 마지막 배포 버전을 함께 표시하고 알림에는 판단할 담당자와 다음 행동을 넣습니다. 새벽 배포처럼 관찰 인력이 적은 시간대에는 같은 숫자라도 자동 동결을 선택할지, 온콜 승인 후 진행할지 정책의 예외를 기록합니다. 예외를 남기면 사후 회고에서 숫자와 사람의 판단을 구분할 수 있습니다.

예시: 3인 팀의 결제 API 배포

예시의 입력은 30일간 결제 시도 100,000건, 성공 99,880건, SLO 99.9%입니다. 결정은 실패 120건으로 버짓 100건을 20건 초과했으므로 새 결제 옵션 배포를 보류하고 지난 배포의 타임아웃을 조사하는 것입니다. 중간 산출물은 요청 ID별 실패 목록, 배포 버전별 오류율, 외부 승인 지연을 나눈 표입니다.

예상 결과는 원인이 네트워크 타임아웃으로 확인되고 제한 시간 조정과 재시도 상한을 적용한 뒤 같은 측정 창에서 실패율이 SLO 안으로 돌아오는 것입니다. 원인이 외부 결제사라면 우리 API의 전달 성공과 외부 승인 성공을 별도 지표로 분리해 잘못된 동결을 피합니다.

실패 경로와 재평가 경계

실패 사례는 지표 자체가 틀린 경우입니다. 캐시 적중을 성공으로 세고 실제 주문 생성 실패를 제외하면 버짓이 남은 것처럼 보입니다. 복구는 이벤트 정의를 수정하고 과거 원천 로그로 재계산한 뒤, 수정 전후 숫자를 배포 회의 기록에 함께 보존하는 순서입니다.

반대로 트래픽이 너무 적어 하루 한 건의 실패가 20%로 튀는 서비스에는 백분율만으로 자동 동결하지 않습니다. 최소 표본, 절대 실패 수, 고객 영향의 세 조건을 함께 요구하고, 어느 조건이 충족되면 사람이 검토할지 정합니다. 이 경계를 정하지 않으면 작은 SaaS의 불확실성이 정책을 흔듭니다.

완료 조건을 운영 기록에 남기기

설계 완료는 대시보드가 생긴 때가 아닙니다. 운영자가 SLO의 분모·성공 이벤트·기간을 읽고 버짓 잔여량을 재현하며, 초과 시 배포를 멈추고 담당자를 호출할 수 있어야 합니다. 첫 달에는 주간 회의에서 계산표와 실제 로그를 대조하고 임계치가 잘못된 신호를 만들었는지 기록하세요. 회의마다 한 건의 실제 요청을 골라 원천 이벤트에서 최종 숫자까지 손으로 추적하면 계측 누락을 일찍 발견할 수 있습니다.

최종 체크는 네 가지입니다. 최근 측정 창과 버짓 계산이 일치하고, 배포 승인 기록에 상태가 남고, 초과 시 실행할 안정화 작업이 소유자와 기한을 가지며, 샘플 장애에서 같은 판단이 재현됩니다. 네 항목의 링크와 확인 시각이 한 문서에 있으면 작은 팀도 SLO를 실제 운영 언어로 사용할 수 있습니다.