소규모 팀을 위한 오류 예산: 현실적인 SLO와 실천 루틴

왜 소규모 팀에 초반부터 에러 예산이 필요한가요

소규모 팀은 빨리 출시해야 하므로 속도로 문제를 해결합니다. 큰 사고 하나가 위험인 경우는 드뭅니다. 반복되는 작은 실패들이 문제입니다: 가입이 가끔 불안정하다던가, 결제가 간헐적으로 실패한다던가, 배포가 가끔 한 화면을 깨뜨리는 식입니다. 이런 문제 하나하나가 수시간을 빼앗고 신뢰를 갉아먹으며 릴리스를 동전 던지기처럼 만듭니다.

에러 예산은 소규모 팀이 “신뢰성은 저절로 생기지 않는다”는 체념 대신 빠르게 움직이되 위험을 관리할 수 있게 해줍니다.

SLO(서비스 수준 목표)는 사용자 경험에 대한 명확한 약속으로, 시간 창에 걸쳐 숫자로 표현됩니다. 예: “지난 7일간 성공적인 결제 비율이 최소 99.5%.” 에러 예산은 그 약속 안에서 허용되는 ‘나쁜 것’의 양입니다. SLO가 99.5%면 주간 예산은 0.5%의 실패한 결제입니다.

이건 완벽이나 가식적인 가동시간 쇼가 아닙니다. 무거운 프로세스나 끝없는 회의, 아무도 업데이트하지 않는 스프레드시트가 아니라 ‘충분히 좋음’이 무엇인지 합의하고, 표류를 감지하며, 다음에 무엇을 할지 차분히 결정하는 방법입니다.

작게 시작하세요: 가장 중요한 여정 1~3개에 연결된 사용자 대상 SLO를 고르고, 이미 가지고 있는 신호(에러, 지연, 실패한 결제 등)로 측정하세요. 그리고 주 1회 짧은 검토를 해서 예산 소진을 보고 따라야 할 행동 하나를 정하세요. 도구보다 습관이 더 중요합니다.

SLO, SLI, 에러 예산을 쉬운 말로

신뢰성을 다이어트 계획처럼 생각하세요. 완벽한 날이 필요하지 않습니다. 목표가 필요하고, 그것을 측정할 방법과 현실을 위한 허용치가 필요합니다.

SLI(서비스 수준 지표)는 당신이 보는 숫자입니다. 예: “성공한 요청 비율” 또는 “p95 페이지 로드 시간 2초 이하” 같은 것. SLO는 그 숫자의 목표치입니다. 예: “요청의 99.9%가 성공한다.” 에러 예산은 SLO에서 벗어날 수 있는 허용치입니다.

예: SLO가 가용성 99.9%라면 예산은 0.1%의 다운타임입니다. 일주일(10,080분) 기준으로 0.1%는 약 10분입니다. 이 10분을 일부러 ‘사용’하려는 뜻은 아닙니다. 대신 그 시간을 쓸 때는 속도나 실험, 기능 작업과 안정성을 의식적으로 바꾸는 결정이라는 의미입니다.

핵심은: 신뢰성을 보고용 지표가 아니라 의사결정 도구로 바꾼다는 점입니다. 수요일에 예산을 대부분 소진했다면 위험한 변경을 멈추고 고치는 쪽으로 전환합니다. 거의 소진이 없다면 더 자신 있게 배포할 수 있습니다.

모든 것에 동일한 SLO가 필요한 건 아닙니다. 공개 고객용 앱은 99.9%가 필요한 반면 내부 관리자용 도구는 관찰자가 적고 영향이 작아 더 느슨하게 설정할 수 있습니다.

무엇을 보호할지 고르기: 사용자가 눈치채는 몇 가지 여정

처음부터 모든 것을 측정하려 들지 마세요. 사용자가 제품이 작동한다고 판단하는 순간들을 보호하는 것부터 시작하세요.

신뢰를 좌우하는 여정 1~3개를 고르세요. 그 부분들이 안정적이면 대부분 다른 문제는 덜 심각하게 느껴집니다. 좋은 후보는 첫 접점(가입/로그인), 돈이 오가는 순간(결제/업그레이드), 핵심 동작(게시, 생성, 전송, 업로드 또는 중요한 API 호출)입니다.

“성공”이 무엇인지 평이한 용어로 적으세요. 사용자가 개발자가 아니라면 “200 OK” 같은 기술적 표현은 피하세요.

적용 가능한 예시들:

• 가입: 사용자가 폼을 제출하고 X초 내에 앱에 진입하며 오류를 보지 않음.
• 결제: 결제가 완료되고 확인 화면이 표시되며 중복 청구가 없음.
• 게시/작업 실행/API 호출: 동작이 완료되고 사용자가 예상 결과를 봄.

변경 속도에 맞는 측정 윈도우를 고르세요. 매일 배포하고 빠른 피드백을 원하면 7일 창이 적절합니다. 릴리스가 덜 자주 이뤄지거나 데이터가 시끄러우면 28일 창이 더 안정적입니다.

초기 제품은 제약이 있습니다: 트래픽이 적을 수 있고(하나의 잘못된 배포가 숫자를 왜곡할 수 있음), 흐름이 빠르게 바뀌며 텔레메트리가 빈약한 경우가 많습니다. 괜찮습니다. 시도 대비 성공 같은 단순한 집계로 시작하세요. 여정 자체가 안정화된 뒤 정의를 좁히면 됩니다.

초기 제품에 현실적인 SLO 설정하기

오늘 배포하는 것에서 시작하세요. 일주일이나 이주일 동안 각 핵심 여정의 기준선을 캡처하세요: 성공 빈도와 실패 빈도. 실제 트래픽이 있으면 그걸 쓰세요. 없으면 자체 테스트와 지원 티켓, 로그를 사용하세요. ‘정상’의 대강 그림을 만드는 겁니다.

첫 SLO는 대부분의 주에 달성 가능하면서도 여전히 배포를 할 수 있는 수준이어야 합니다. 기준선 성공률이 98.5%면 99.9%를 설정하고 바라기보다 98%나 98.5%로 시작하세요.

지연(latency)은 유혹적이지만 초기에는 주의를 산만하게 할 수 있습니다. 많은 팀은 먼저 성공률 SLO(요청이 에러 없이 끝나는 비율)에서 더 큰 가치를 얻습니다. 사용자가 명확히 체감할 때와 데이터가 충분히 안정화됐을 때 지연을 추가하세요.

유용한 형식은 여정마다 한 줄: 대상, 무엇을, 목표, 시간 창.

• 신규 사용자 가입: 7일 롤링 기준 가입 시도 중 98.5% 성공.
• 결제 사용자 체크아웃: 30일 롤링 기준 결제 성공 99.0%.
• 활성 사용자가 메인 페이지 로드: 7일 롤링 기준 페이지 로드 성공 99.0%.

청구나 인증처럼 신뢰가 중요한 순간은 창을 길게, 일상 흐름은 짧게 유지하세요. SLO를 쉽게 달성하면 조금씩 높여가면 됩니다.

어떤 인시던트를 중요하게 볼지 결정하기

소규모 팀은 모든 사소한 문제를 긴급상황으로 만들며 많은 시간을 잃습니다. 목표는 단순합니다: 사용자에게 눈에 띄는 고통만 예산을 소진하게 하고, 나머지는 평상시 작업으로 처리하세요.

필요한 인시던트 유형은 적습니다: 전체 장애, 부분 장애(핵심 흐름 하나가 깨짐), 성능 저하(작동은 하지만 느림), 잘못된 배포, 데이터 문제(잘못되거나 누락되거나 중복).

포스트잇 한 장에 들어갈 정도의 심각도 척도

척도를 작게 유지하고 매번 동일하게 사용하세요.

• Sev1: 많은 사용자가 핵심 여정을 못 쓰거나 데이터가 위험한 상태. 모든 것을 중단.
• Sev2: 일부 사용자가 차단되었거나 핵심 여정이 불안정함. 오늘 안에 고치거나 다음 영업일에 일정 잡음.
• Sev3: 경미한 고장이나 내부 불편. 기록해 두고 진행.

무엇을 예산에 포함할지 정하세요. 사용자에게 보이는 실패를 예산 소진으로 취급합니다: 깨진 가입이나 결제, 사용자가 체감하는 타임아웃, 여정을 멈추는 5xx 급증 등. 사전에 공지한 계획된 유지보수는 해당 창 동안 앱이 예상대로 동작했다면 예산에서 제외합니다.

논쟁을 끝내는 한 가지 규칙: 실제 외부 사용자가 알아차려서 보호된 여정을 완료할 수 없다면 예산에 포함합니다. 그렇지 않으면 포함하지 않습니다.

이 규칙은 흔한 애매한 경우도 다룹니다: 서드파티 장애는 그것이 사용자 여정을 망가뜨릴 때만 포함되고, 트래픽이 적은 시간대라도 사용자가 영향을 받으면 포함되며, 내부 전용 테스터는 도그푸딩이 주요 사용이라면 포함됩니다.

가벼운 신호로 예산 소진 추적하기

목표는 완벽한 측정이 아닙니다. 신뢰성 비용이 커질 때를 알려주는 공유 가능한, 반복 가능한 신호를 만드는 것입니다.

각 SLO마다 하나의 신뢰할 수 있는 출처를 고르고 그것을 계속 사용하세요: 모니터링 대시보드, 앱 로그, 한 지점을 치는 합성 검사, 혹은 분당 성공한 체크아웃 같은 단일 메트릭. 나중에 측정 방식을 바꾸면 날짜를 적어 두고 리셋으로 취급해 사과와 배를 비교하지 않도록 하세요.

알림은 예산 소진을 반영해야지 모든 작은 이상을 반영해선 안 됩니다. 짧은 급증이 성가실 수는 있지만 한 달 예산에 거의 영향이 없다면 사람을 깨우면 안 됩니다. 간단한 패턴 하나가 잘 작동합니다: “빠른 소진”(한 달 예산을 하루 만에 소진할 기세)에 알림, “느린 소진”(일주일 내 소진 기세)에 약한 알림.

작은 신뢰성 로그를 유지해 기억에 의존하지 마세요. 인시던트당 한 줄이면 충분합니다: 날짜와 지속시간, 사용자 영향, 추정 원인, 변경한 사항, 그리고 후속 담당자와 기한.

예: 두 명으로 운영하는 팀이 모바일 앱용 새 API를 출시했습니다. 그들의 SLO는 “성공 요청 99.5%”이고 한 카운터로 측정합니다. 잘못된 배포로 성공률이 20분 동안 97%로 떨어졌습니다. 빠른 소진 알림이 울리고 그들은 롤백했으며 후속 조치로 “배포 전 카나리 체크 추가”를 정했습니다.

주간 안정성 루틴: 20분, 같은 시간, 같은 노트

큰 프로세스가 필요한 게 아닙니다. 빌드 시간을 빼앗지 않으면서 안정성을 보이게 하는 작은 습관이 필요합니다. 20분 점검은 모든 것을 한 질문으로 압축합니다: 우리가 계획한 것보다 더 빠르게 신뢰성을 소진하고 있는가?

매주 같은 시간 슬롯을 사용하세요. 덧붙이는(shared) 노트를 하나 유지하고 계속 덧붙이세요(다시 쓰지 마세요). 일관성이 세부사항보다 중요합니다.

간단한 의제:

• 예산 한눈 보기: 각 SLO의 남은 예산과 소진의 주요 원인
• 새 인시던트: 한 줄씩(무슨 일이었나, 언제였나, 사용자 영향)
• 후속 조치: 실제로 끝낼 1–3개 선택
• 약속: 담당자와 기한 지정, 정해진 시간에 끝내기

후속 조치와 약속 사이에서 그 주의 배포 규칙을 정하고 단순하게 유지하세요:

• Normal: 계획대로 배포
• Cautious: 배포는 하되 영향을 받은 영역에서 위험한 변경은 피함
• Freeze: 상위 이슈가 해결될 때까지 한 영역에서 변경 중단

가입 흐름이 두 번의 짧은 장애로 예산을 대부분 소진했다면 가입 관련 변경만 중단하고 다른 작업은 계속할 수 있습니다.

예산을 드라마 없이 로드맵 결정으로 바꾸기

에러 예산은 다음 주에 당신이 무엇을 할지 바꿀 때만 의미가 있습니다. 목표는 완벽한 가동시간이 아닙니다. 다음을 결정하는 명확한 방법입니다: 기능을 배포할까, 신뢰성 빚을 갚을까?

소리 내어 말할 수 있는 정책:

• 예산이 건강하면 계속 배포하고 이미 알고 있는 최악의 신뢰성 문제 하나를 고칩니다.
• 예산이 빠르게 소진되면 영향이 없는 기능 작업을 멈추고 주요 실패 모드를 제거합니다.
• 예산이 바닥나면 다시 범위 내로 돌아올 때까지 안정성 작업을 로드맵으로 둡니다.

이건 처벌이 아닙니다. 사용자에게 비용을 떠넘기지 않기 위한 공개적 거래입니다.

속도를 늦출 때는 “안정성 향상” 같은 모호한 작업을 피하세요. 다음 결과를 바꿀 구체적 변경을 선택하세요: 가드레일 추가(타임아웃, 입력 검증, 속도 제한), 버그를 잡을 테스트 개선, 롤백을 쉽게 만들기, 최상위 오류 원인 고치기, 혹은 사용자 여정에 연결된 한 개의 알림 추가 등.

보고는 비난과 분리하세요. 상세하지 못해도 빠른 인시던트 기록을 장려하세요. 진짜 나쁜 인시던트 보고서는 늦게 올라와서 누가 무엇을 바꿨는지 아무도 기억하지 못하는 경우뿐입니다.

소규모 팀이 빠지기 쉬운 함정

자주 보이는 함정은 첫날부터 최고 등급의 SLO(예: 99.99%)를 설정하고 현실에 부딪히면 조용히 무시하는 것입니다. 스타터 SLO는 현재 인력과 도구로 대부분의 주에 달성할 수 있어야 합니다. 그렇지 않으면 배경 소음이 됩니다.

또 다른 실수는 잘못된 것을 측정하는 것입니다. 팀이 여러 서비스와 DB 그래프를 보면서도 사용자가 실제로 느끼는 여정(가입, 결제, 저장 등)을 놓치는 경우가 있습니다. 사용자 관점에서 한 문장으로 SLO를 설명할 수 없다면 내부 지표일 가능성이 큽니다.

알람 피로는 운영을 고칠 수 있는 유일한 사람을 탈진시킵니다. 작은 급증마다 호출이 가면 호출이 ‘정상’이 되고 진짜 화재를 놓칩니다. 사용자 영향에 따라 페이징하세요. 나머지는 일일 점검으로 보냅니다.

조용한 함정은 일관되지 않은 집계입니다. 한 주는 2분 지연을 인시던트로 치고 다음 주는 치지 않으면 예산이 토론거리가 되어 신호가 사라집니다. 규칙을 한번 적어 두고 일관되게 적용하세요.

도움이 되는 가드레일:

• 핵심 사용자 여정당 하나의 SLO로 시작하세요, 컴포넌트별로 하지 마세요.
• 대부분의 주에 달성할 수 있는 SLO로 시작하고 점차 엄격하게 만드세요.
• 사용자 영향이 있을 때만 페이징하세요.
• 간단한 인시던트 정의를 만들어 항상 동일하게 적용하세요.
• 사후조사는 ‘무엇이 이를 가능하게 했나’에 초점을 맞추세요, ‘누가 원인인가’가 아니라.

배포가 로그인 기능을 3분간 망가뜨렸다면 그게 빠르게 고쳐졌더라도 매번 카운트하세요. 일관성이 예산을 유용하게 만듭니다.

10분 안에 할 수 있는 빠른 체크리스트

10분 타이머를 맞추고 공유 문서를 열어 이 다섯 가지 질문에 답하세요:

• 절대 깨뜨릴 수 없는 1~3개의 사용자 여정은 무엇인가?
• 각 여정에 대해 시간 창을 포함한 한 줄짜리 SLO 문장을 쓸 수 있나?
• 인시던트로 무엇을 볼지 합의했고 누가 24시간 내에 기록하나?
• 지난 7일을 보았고 영향 기반으로 1~3개의 후속 조치를 골랐나?
• 예산이 낮으면 단순한 배포 규칙이 있는가?

아직 측정할 수 없다면 빠르게 볼 수 있는 대리 지표로 시작하세요: 실패한 결제, 500 에러, 또는 “checkout” 태그가 붙은 지원 티켓 등. 추적이 나아지면 대리 지표를 대체하세요.

예: 두 명 팀이 이번 주에 ‘비밀번호 재설정 불가’ 메시지 세 건을 받았다면, 비밀번호 재설정이 보호된 여정이라면 그건 인시던트입니다. 그들은 한 줄짜리 노트(무슨 일이 있었나, 몇 명, 어떻게 대응했나)를 쓰고 후속 조치 하나를 정합니다: 재설정 실패에 대한 알림 추가 또는 재시도 로직 추가 등.

예시: 한 기능에 에러 예산을 적용한 두 명 스타트업 팀

Maya와 Jon은 두 명으로 구성된 스타트업으로 매주 금요일 출시합니다. 속도를 내지만 첫 유료 사용자는 한 가지를 중요하게 여깁니다: 프로젝트 생성하고 동료를 초대할 때 문제가 없어야 한다는 것.

지난주 실제 장애가 하나 있었습니다: 잘못된 마이그레이션으로 “프로젝트 생성”이 22분간 실패했습니다. 또한 8~12초 동안 로딩이 느려진 세 번의 구간이 있었습니다. 사용자는 불만을 냈지만 팀은 느림을 ‘다운’으로 볼지 논쟁했습니다.

그들은 하나의 여정을 골라 측정 가능하게 했습니다:

• 여정 SLO: 프로젝트 생성이 3초 이내에 성공하고 주간 기준 99%를 만족할 것.
• 인시던트 정의: 성공률이 10분 이상 97% 미만으로 떨어지거나 p95 지연이 15분 이상 5초를 넘으면 인시던트로 보고 짧은 노트를 작성.

월요일에 그들은 20분 루틴을 돌립니다. 같은 시간, 같은 문서에 모여 네 가지 질문에 답합니다: 무슨 일이 있었나, 얼마나 예산을 소진했나, 무엇이 반복되나, 반복을 막을 단 하나의 변화는 무엇인가.

결과는 분명해집니다: 장애와 느린 구간이 주간 예산을 대부분 소진했습니다. 그래서 다음 주의 ‘하나의 큰 기능’은 ‘DB 인덱스 추가, 마이그레이션 안전성 강화, 프로젝트 생성 실패에 대한 알림 추가’가 됩니다.

결과는 완벽한 신뢰성이 아니라 반복 문제 감소, 명확한 결정, 그리고 사전에 무엇이 ‘충분히 나쁜지’ 합의했기 때문에 늦은 밤 허둥지름이 줄어드는 것입니다.

다음 단계: 작게 시작하고 루프를 짧게 유지하세요

하나의 사용자 여정을 골라 간단한 안정성 약속을 만드세요. 에러 예산은 완벽이 아니라 지루하고 반복 가능한 상태일 때 가장 잘 작동합니다.

하나의 SLO와 하나의 주간 루틴으로 시작하세요. 한 달 후에도 너무 쉽다면 두 번째 SLO를 추가하세요. 부담스럽다면 더 줄이세요.

수학은 단순하게(주간 또는 월간), 목표는 현재 수준에 현실적으로 맞게 유지하세요. 한 페이지짜리 안정성 노트를 작성해 다음을 답하세요: SLO와 측정 방법, 인시던트로 간주하는 기준, 이번 주 담당자, 체크인 시간, 예산이 너무 빨리 소진될 때 기본적으로 하는 일.

플랫폼 예시: Koder.ai (koder.ai) 같은 플랫폼 위에서 빌드한다면 스냅샷과 롤백을 결합해 빠른 반복과 안전 습관을 함께 유지할 수 있습니다. ‘마지막 정상 상태로 되돌리기’가 정상적이고 자주 연습되는 동작이 되게 하세요.

루프를 단순하게 유지하세요: 하나의 SLO, 하나의 노트, 하나의 짧은 주간 점검. 목표는 인시던트를 없애는 것이 아니라, 초기에 알아채고 차분하게 결정하며 사용자가 실제로 느끼는 몇 가지를 보호하는 것입니다.