내부 도구를 위한 SLO: 실용적인 간단한 신뢰성 목표

내부 도구에도 SLO가 필요한 이유 (사용자가 20명뿐이어도)

내부 도구는 사용자가 적어 보이지만 영향은 작지 않습니다. 운영 대시보드가 다운되면 주문이 멈추고, 지원 콘솔이 느리면 고객이 기다리고, 관리자 패널이 고장나면 수정이 쌓입니다.

명확한 신뢰성 목표가 없으면 모든 장애가 논쟁으로 이어집니다. 어떤 사람은 10분짜리 오류에 무덤덤하고, 또 다른 사람은 위기처럼 반응합니다. 시끄러운 채팅과 우선순위 혼선, 최악의 순간에 닥치는 갑작스런 작업에 시간을 뺏깁니다.

SLO는 측정 가능한 간단한 기대치를 설정해 이 문제를 해결합니다. 무엇이 작동해야 하는지, 사람들이 업무를 보기 위해 얼마나 잘 작동해야 하는지를 답합니다.

“대충 안정적으로 유지하자”의 숨은 비용은 빠르게 드러납니다. 도구가 복구될 때까지 업무가 멈춥니다. 누가 정상 상태인지 몰라서 지원 요청이 늘고, 엔지니어는 계획된 개선 대신 긴급 수정에 끌려갑니다. 제품 담당자는 시스템을 신뢰하지 못하고 수작업 백업을 요구하기 시작합니다. 작은 문제들이 명확한 기준을 넘지 않아서 오래 방치됩니다.

완전한 신뢰성 프로그램이 필요하지 않습니다. 소규모 팀은 ‘로그인 동작이 작동한다’나 ‘검색 결과가 빠르게 로드된다’ 같은 일부 사용자 중심 목표와 실제 조치로 연결된 소수의 경고로 시작할 수 있습니다.

이 원칙은 도구가 어떻게 만들어졌든 적용됩니다. 만약 AppMaster (appmaster.io)를 사용해 내부 앱을 만든다면, 사람들이 의존하는 동작을 고르고 가동률과 응답 시간을 측정한 뒤 실제 업무에 영향을 줄 때만 경고를 띄우세요.

SLO, SLI, SLA를 쉽게 설명하면

비슷해 보이는 세 용어지만 서로 다른 성격의 신뢰성 언어입니다. 섞어 쓰면 혼란이 자주 생깁니다.

SLI(Service Level Indicator)는 측정치입니다. 예: “성공한 요청의 비율” 또는 “페이지 로드에 걸린 시간”. 신뢰성 있게 측정할 수 없다면 좋은 SLI가 아닙니다.

SLO(Service Level Objective)는 그 측정치의 목표입니다. 대부분의 시간 동안 사용자에게 충분한 수준이 어느 정도인지 답해 줍니다. SLO는 무엇을 먼저 고쳐야 할지, 무엇을 미뤄야 할지 결정하는 데 도움을 줍니다.

SLA(Service Level Agreement)는 보통 문서화된 약속이며, 결과가 따르는 경우가 많습니다. 많은 내부 도구에는 SLA가 필요하지 않으며, 대신 명확한 목표가 필요합니다.

짧은 예:

• SLI(가용성): 도구에 접근 가능한 분의 비율.
• SLO(가용성 목표): 월간 99.9% 가용성.
• SLI(지연): 대시보드의 p95 페이지 로드 시간.
• SLO(지연 목표): 업무 시간 동안 p95 2초 이하.

여기서 빠진 것은 “절대 다운되지 않음”이나 “항상 빠름” 같은 완벽함입니다. SLO는 완벽을 추구하는 대신 트레이드오프를 가시화해 소규모 팀이 기능, 신뢰성 작업, 불필요한 수고 중 무엇을 선택할지 결정할 수 있게 합니다.

실용 규칙: 목표를 지키기 위해 영웅담이 필요하다면 그것은 SLO가 아니라 희망사항입니다. 팀이 차분히 유지할 수 있는 수준으로 시작하고, 사용자 불편이 계속된다면 점진적으로 강화하세요.

정말 중요한 사용자 동작 몇 가지를 골라라

내부 도구의 실패는 구체적입니다: 관리자 패널은 로드되지만 레코드 저장이 무한 로딩 상태가 된다거나, 운영 대시보드는 열리지만 차트가 갱신되지 않는다거나, 직원 포털은 작동하지만 업데이트 후 로그인이 깨지는 식입니다. 매일 사람들이 의존하는 동작에 집중하면 가장 큰 가치를 얻습니다. 모든 페이지와 버튼을 다루려 하지 마세요.

도구 유형을 먼저 적어보면 중요 경로가 보입니다. 관리자 패널은 “안전하게 변경하기”에 집중하고, 운영 대시보드는 “지금 무슨 일이 일어나고 있는지 보기”에, 포털은 “들어가서 정보 찾고 요청 제출하기”에 초점을 맞춥니다.

그다음 상위 사용자 여정을 평이한 언어로 적으세요. 시작하기 좋은 목록:

• 로그인해서 홈 화면에 도달하기
• 검색하거나 필터해서 결과 얻기
• 폼 제출(생성/수정) 후 성공 메시지 보기
• 최신 데이터로 메인 대시보드 뷰 로드하기
• 일상 업무에 쓰는 리포트 내보내기 또는 다운로드하기

각 여정에 대해 실패로 간주할 조건을 정의하세요. 엄격하고 측정 가능해야 합니다: 500 오류는 실패고, 타임아웃이나 페이지가 끝없이 로드되는 것도 실패이며, 데이터가 없는 상태로 성공 응답을 반환하는 것도 실패입니다.

초반에는 범위를 작게 유지하세요. 실제 고통과 위험에 맞는 1~3개 여정을 고르세요. 대체로 호출 당번 페이지가 “아무도 로그인 못함”과 “저장 버튼이 멈춤”이라면 로그인과 폼 제출부터 시작하고, 측정과 경고를 신뢰하게 되면 검색을 추가하세요.

실제로 측정 가능한 SLI 선택하기

좋은 SLI는 심심합니다. 이미 가지고 있는 데이터에서 나오고, 사용자가 도구가 작동하거나 실패할 때 느끼는 것과 일치합니다. 측정만을 위해 완전히 새로운 모니터링을 구축해야 한다면 더 단순한 SLI를 고르세요.

사람들이 이해하는 방식으로 접근성을 먼저 측정하세요: 도구를 열 수 있는가, 작업을 완료할 수 있는가? 많은 내부 도구는 두 가지 SLI로 대부분의 문제를 덮습니다:

• 도구의 가동률(접근 가능하고 응답하는지)
• 1~3개의 핵심 동작에 대한 성공률(로그인, 검색, 저장/승인 등)

그다음 지연을 추가하되 범위를 좁게 유지하세요. 사용자 불만이 나오는 화면이나 엔드포인트 1~2개를 선택하세요(예: 대시보드 로드, 폼 제출). 모든 것을 측정하면 잡음과 논쟁이 생깁니다.

측정 창(window)을 미리 정하세요. 안정된 도구에는 30일 롤링이 흔하고, 자주 릴리스하고 빠른 피드백이 필요하면 주간이 효과적입니다. 무엇을 선택하든 일관되게 유지해 트렌드가 의미를 가지게 하세요.

마지막으로 SLI별로 한 가지 진실의 출처(source of truth)를 정하고 문서화하세요:

• 합성 체크(봇이 헬스체크를 치거나 단순 흐름을 실행)
• 서버 메트릭(요청 수, 오류, 백엔드 지연)
• 로그(특정 동작의 "성공" vs "실패" 이벤트 집계)

예: 내부 앱을 AppMaster로 만들었다면 합성 핑으로 가동률을 측정하고, API 응답으로 성공률을, 백엔드 요청 타이밍으로 지연을 측정할 수 있습니다. 핵심은 완벽이 아니라 일관성입니다.

현실적인 가동률과 지연 SLO 설정하기

먼저 나쁜 주에도 방어할 수 있는 가동률 숫자를 고르세요. 많은 내부 도구에 대해 99.5%는 좋은 초깃값입니다. 높게 들리지만 정상적인 변경 작업을 위해 여유를 둡니다. 바로 99.9%로 가면 보통 야간 호출이 늘고 배포 속도가 느려집니다.

가동률을 현실적으로 느끼게 하려면 시간을 환산하세요. 30일(약 43,200분) 기준:

• 99.5%는 월 약 216분의 다운타임 허용
• 99.9%는 월 약 43분의 다운타임 허용

그 허용된 다운타임이 오류 예산(error budget)입니다. 초반에 예산을 빨리 소진하면 위험한 변경을 멈추고 안정화에 집중합니다.

지연에 대해서는 평균을 피하세요. 평균은 사용자가 기억하는 느린 순간을 숨깁니다. 백분위(보통 p95)를 사용하고 실제 행동에 연결된 명확한 임계값을 정하세요. 예: "대시보드 p95 로드 < 2초" 또는 "저장 p95 < 800ms".

첫 숫자를 정하는 쉬운 방법은 실제 트래픽 일주일을 관찰한 뒤 오늘보다 약간 나은 값을 목표로 삼는 것입니다. p95가 이미 1.9초라면 2.0초 SLO는 안전하고 유용합니다. 500ms 목표는 소음만 만들 확률이 높습니다.

SLO는 지원 역량에 맞게 설정하세요. 소규모 팀이라면 많은 엄격한 목표보다 달성 가능한 몇 개의 목표를 선호해야 합니다. 아무도 한 시간 내에 응답할 수 없다면, 그 시간을 전제로 하는 목표를 세우지 마세요.

트레이드오프를 가시화하기: 비용, 위험, 오류 예산

더 엄격한 SLO는 안심이 되지만 대가가 있습니다. 가동률을 99.5%에서 99.9%로 올리면 허용되는 나쁜 시간이 훨씬 줄어들고, 보통 더 잦은 페이지와 신뢰성 작업 증가를 수반합니다.

이를 현실로 느끼게 하는 가장 쉬운 방법은 오류 예산으로 말하는 것입니다. 월 99.5%이면 30일 기준 약 3.6시간을 “소비”할 수 있고, 99.9%이면 약 43분밖에 없습니다. 이 차이는 기능 작업을 멈추고 신뢰성에 집중해야 하는 빈도에 직접적인 영향을 줍니다.

또한 도구를 실제로 사용하는 시간에 기대를 맞추세요. 도구가 업무 시간에만 중요하면 업무 시간에는 엄격하게, 비업무 시간에는 느슨하게 SLO를 설정해 팀이 잠을 잘 수 있게 하세요.

계획된 유지보수는 사전에 알리고 범위를 정한다면 실패로 계산하지 마세요. 사후에 경보를 무시하는 대신 명시적 예외(유지보수 윈도우)로 처리하세요.

모두가 트레이드오프를 볼 수 있게 기본을 적어 두세요:

• SLO 숫자와 놓치면 사용자가 잃는 것
• 월별 오류 예산(분 또는 시간)
• 페이징 규칙(누구, 언제, 무엇에 대해)
• 업무 시간 대 24/7 기대치 차이(있다면)
• 계획된 유지보수의 범위

실제 데이터 4~6주 후 목표를 검토하세요. 오류 예산을 전혀 쓰지 않았다면 SLO가 너무 느슨한 것이고, 빠르게 소진되어 기능이 멈춘다면 너무 빡빡한 것입니다.

SLO를 팀이 감당할 수 있는 경고로 연결하기

경고는 SLO 자체가 아닙니다. 경고는 SLO를 보호하기 위한 “지금 무언가 잘못되고 있다” 신호입니다. 간단한 규칙: 각 SLO마다 중요한 하나의 경고를 만들고, 증거 없이는 더 추가하지 마세요.

실용적인 방법은 빠른 SLO 소진(오류 예산 소진 속도)에 대해 경고를 걸거나 사용자 불편과 일치하는 명확한 임계값에 대해 알리는 것입니다. 예: 지연 SLO가 "p95 < 800ms"라면 모든 느린 스파이크에 페이지를 걸지 마세요. 지속적일 때만 페이지하세요.

노이즈를 줄이는 간단한 분류:

• 긴급 페이지: 도구가 사실상 작동 불가일 때, 즉시 행동 필요
• 비긴급 티켓: 악화 중이지만 업무 시간 내에 처리해도 되는 경우

구체적 임계값(트래픽에 맞게 조정): 가동률 SLO가 월 99.5%라면 가용성이 5분 동안 99% 미만으로 떨어지면 페이지(명백한 장애). 6시간 동안 99.4% 미만이면 티켓(서서히 악화). 지연의 경우 p95가 15분 동안 1.5초 초과면 페이지, 2시간 동안 1.0초 초과면 티켓 등으로 나눌 수 있습니다.

소유권을 명확히 하세요. 누구가 온콜인지(예: “이번 주 한 명”), 확인(acknowledge)이 무엇을 의미하는지(예: 10분 내), 첫 번째 행동이 무엇인지 정하세요. AppMaster로 내부 앱을 운영하는 소규모 팀이라면 첫 단계는 최근 배포 확인, API 오류 확인, 필요 시 롤백 또는 재배포일 수 있습니다.

실제 경고 후에는 항상 한 가지 작은 후속 조치를 하세요: 원인을 고치거나 경고를 조정해 실제 사용자 영향을 잡으면서 페이지 빈도를 줄입니다.

경보 피로를 만드는 흔한 실수

경보 피로는 보통 선의에서 시작합니다. 소규모 팀이 “몇 개만” 경고를 추가하고, 매주 하나씩 더 추가하다 보면 곧 알림을 믿지 않게 되고 실제 장애를 놓칩니다.

큰 함정 중 하나는 모든 스파이크에 경고를 거는 것입니다. 내부 도구는 버스트성 트래픽이 자주 있으므로(급여 처리, 월말 리포트 등) 2분짜리 일시적 변동에 경고가 울리면 팀은 무시하게 됩니다. 경고는 사용자 영향 신호에 연결하세요, 원시 메트릭 노이즈가 아니라.

또 다른 함정은 “많은 지표 = 더 안전”이라고 생각하는 것입니다. 실제로는 더 많은 페이지를 의미하는 경우가 더 많습니다. 로그인 실패, 페이지 느림, 핵심 작업 미완료 같은 사용자가 실제로 느끼는 소수의 신호에 집중하세요.

특히 소음을 만드는 실수:

• 사용자 영향(오류, 지연)이 아니라 증상(CPU, 메모리)에 페이징
• 경보에 소유자가 없어 튜닝이나 제거가 안 됨
• 런북이 없어 모든 경고가 추측 게임이 됨
• 대시보드를 경고 대신 사용(대시보드는 진단용, 경고는 행동 유도용)
• 시스템이 잘 계측되어 있지 않은데 임계값을 대충 정함

대시보드는 여전히 중요하지만, 경고가 울린 후 진단을 돕는 용도로 쓰고 경고를 대체해서는 안 됩니다.

측정이 아직 깨끗하지 않다면 있는 그대로 하지 마세요. 기본 계측(성공률, p95 지연, 사용자가 작업을 완료할 수 있는지 체크)을 먼저 추가한 뒤 1~2주 실제 데이터를 근거로 임계값을 정하세요.

경고를 켜기 전 빠른 점검 목록

경고를 활성화하기 전에 짧은 사전 점검을 하세요. 대부분의 경보 피로는 이 기본 중 하나를 건너뛰고 나중에 긴급히 고치려다 생깁니다.

소규모 팀을 위한 실용 체크리스트:

• 1~3개의 핵심 사용자 동작 확인(예: 대시보드 열기, 티켓 업데이트 저장, 리포트 내보내기).
• 오늘 측정할 수 있는 2~4개의 SLI로 제한(가용성/성공률, p95 지연, 핵심 엔드포인트 오류율).
• 도구당 총 2~4개의 경보로 제한.
• 측정 창과 “나쁨”의 정의 합의(빠른 탐지를 위해 최근 5분 또는 잡음을 줄이려면 30~60분).
• 소유자 지정(한 사람, “팀”이 아님).

다음으로, 경보가 실제로 조치 가능한지 확인하세요. 아무도 대응할 수 없는 시간에 울리는 경보는 무시되도록 학습됩니다.

첫 페이지 전 미리 정할 운영 세부사항:

• 페이징 시간대: 업무 시간만인가, 24/7인가
• 에스컬레이션 경로: 첫 응답자가 없을 때 누구에게 가는가
• 첫 행동: 영향 확인 및 롤백/완화 위한 한두 단계
• 월간 간단 리뷰 습관: 울린 경보, 누락된 사고, SLO이 도구 사용과 맞는지 15분 검토

도구를 만들거나 변경하면(예: AppMaster로 개발 시) 체크리스트를 다시 실행하세요. 재생성된 코드와 새 흐름은 지연과 오류 패턴을 바꿀 수 있으므로 경보도 따라가야 합니다.

예시: 두 개의 SLO와 세 개의 경고를 가진 작은 운영 대시보드

운영팀 18명이 내부 대시보드를 하루 종일 사용해 주문 상태를 확인하고, 실패한 알림을 재전송하고, 환불을 승인합니다. 다운되거나 느리면 업무가 금방 멈춥니다.

그들은 두 개의 SLO를 정했습니다:

• 가동률 SLO: 30일 동안 99.9%의 성공적 페이지 로드(월 약 43분의 허용 시간)
• 지연 SLO: 업무 시간 동안 p95 페이지 로드 시간 1.5초 미만

그다음 소규모 팀이 감당할 수 있는 세 가지 경고를 추가했습니다:

• 완전 다운 경고(페이지 로드 실패): 성공률이 5분 동안 98% 미만이면 발동. 첫 행동: 최근 배포 확인, 웹 앱 재시작, DB 상태 확인.
• 대시보드 느림 경고: p95 지연이 10분 동안 2.5초 초과하면 발동. 첫 행동: 느린 쿼리나 멈춘 백그라운드 작업 확인 후 무거운 리포트 일시 중지.
• 오류 예산 소진 경고: 향후 7일 내에 월별 오류 예산의 50%를 소진할 것으로 예상되면 발동. 첫 행동: 비필수 변경 중단해 안정화.

다음 주에 어떤 일이 일어나는지가 중요합니다. 오류 예산 경고가 두 번 울리면 팀은 명확한 결정을 내립니다: 새 기능을 미루고 이틀 동안 가장 큰 지연 원인(예: 인덱스 없는 테이블 스캔)을 고칩니다. AppMaster로 도구를 만들었다면 데이터 모델을 조정하고 코드를 재생성해 깔끔한 코드를 다시 배포할 수 있어 임시방편적 수정을 줄일 수 있습니다.

SLO를 장기 프로젝트로 만들지 않고 유지하는 법

SLO는 실제 업무와 연결되어 있을 때만 도움이 됩니다. 요령은 이것을 새로운 프로그램이 아니라 작은 습관으로 다루는 것입니다. 소규모 팀에 맞는 주기를 정하고 기존 회의에 붙이세요. 주간으로 빠르게 훑어보고, 월간으로 조정하면 실제 데이터가 쌓인 뒤 관리하기 쉽습니다.

유지하기 쉬운 경량 프로세스:

• 주간(10분): SLO 차트와 최근 경고를 확인해 조용히 악화되는 부분이 없는지 점검.
• 사고 후(15분): 원인 태그 지정 및 어떤 사용자 동작에 영향을 줬는지 기록(로그인, 검색, 저장, 내보내기).
• 월간(30분): 반복되는 사고 패턴 상위 항목 검토 후 다음 달에 고칠 한 가지 선택.
• 월간(10분): 시끄러운 경고 하나 제거 또는 튜닝.

작고 가시적인 개선만 하세요. 매주 월요일마다 “페이지 느림”이 세 번 보고되면 캐시 추가, 인덱스 추가, 무거운 작업 시간 변경 등 한 가지 구체적 변경을 하고 다음 주 SLI를 관찰하세요.

요청을 정중하고 명확히 거절할 때 SLO를 사용하세요. 가치 낮은 기능 요청이 오면 현재 오류 예산을 가리키며 “이 변경이 저장이나 승인 흐름을 위험에 빠뜨릴까요?”라고 물으세요. 이미 예산을 소진 중이라면 신뢰성이 우선입니다. 이건 차단이 아니라 우선순위 설정입니다.

문서는 최소로 유지하세요: 도구별 한 페이지에 핵심 사용자 동작, SLO 숫자, 연결된 소수의 경고, 그리고 소유자를 적으세요. 도구가 AppMaster로 만들어졌다면 로그/지표를 어디서 보는지, 누가 배포할 수 있는지도 적어 두고 끝내세요.

다음 단계: 작게 시작하고 하나씩 개선하기

신뢰성을 현실로 만드는 가장 쉬운 방법은 첫 설정을 아주 작게 유지하는 것입니다. 깨졌을 때 실제로 고통을 주는 내부 도구 하나를 골라 사람들이 매일 하는 몇 가지 동작 주위에 목표를 설정하세요.

대부분 팀이 따라 할 수 있는 최소한의 설정:

• 도구 1개와 핵심 사용자 동작 2개 선택(예: 대시보드 열기, 승인 제출).
• 지금 측정할 수 있는 SLI 2개 정의: 엔드포인트/페이지 가동률, 동작의 p95 지연.
• SLO 2개 설정(예: 월 99.5% 가동률, 업무 시간 p95 < 800ms).
• 총 2~3개의 경고 생성: 완전 다운용, 지속적 지연용, 빠른 오류 예산 소진용.
• 주 1회 10분 검토: 경고가 도움이 되었나, 아니면 소음이었나?

안정되면 천천히 확장하세요: 한 달에 하나의 동작이나 하나의 도구를 추가합니다. 누가 경보를 담당할지 말할 수 없다면 아직 경보를 만들지 마세요.

내부 도구를 새로 만들거나 재구성한다면 AppMaster가 유지 관리를 더 쉽게 만들 수 있습니다. 시각적으로 데이터 모델과 비즈니스 로직을 수정하고 클린 코드를 재생성해 배포함으로써 SLO를 도구의 실제 동작에 맞게 유지하기가 수월해집니다.

처음부터 기본 SLO를 넣어 하나의 내부 도구를 만들어 보세요. 기대치가 명확해지고, 놀라움이 줄며, 소규모 팀이 감당할 수 있는 경보를 갖게 될 것입니다.