slo-implementation

slo-implementation 스킬 개요

slo-implementation 스킬은 막연한 신뢰성 목표를 구체적인 Service Level Indicators(SLI), Service Level Objectives(SLO), error budget, 그리고 알림 로직으로 바꾸는 데 도움을 줍니다. 이 스킬은 “어느 정도면 서비스 상태가 충분히 좋다고 볼 수 있는지”를 반복 가능하게 정의해야 하는 SRE, 플랫폼 팀, 백엔드 엔지니어, 그리고 신뢰성을 중시하는 프로덕트 오너에게 특히 잘 맞습니다.

slo-implementation 스킬은 이런 용도에 적합합니다

다음이 필요할 때 slo-implementation 스킬을 사용하세요:

• 서비스에 대한 측정 가능한 신뢰성 목표를 정의할 때
• availability, latency 같은 적절한 SLI 유형을 선택할 때
• 비즈니스 영향에 맞는 SLO 목표값을 설정할 때
• 그 목표값으로부터 error budget을 도출할 때
• burn rate 또는 SLO 소진율 기준의 알림을 설계할 때

이 스킬은 단순히 “SLO 하나 작성해줘” 같은 일반 프롬프트보다 더 유용합니다. SLI에서 SLO, SLA로 이어지는 구조를 체계적으로 제시하고, 측정 윈도우나 PromQL 스타일 쿼리 같은 구현 세부사항까지 작업을 연결해 주기 때문입니다.

누가 설치하면 좋은가

slo-implementation skill은 이미 telemetry가 있거나 곧 확보할 수 있는 팀에 특히 잘 맞습니다. Prometheus 스타일 메트릭을 사용하고 있고, 프레임워크를 처음부터 직접 만들지 않으면서도 SRE에 맞는 신뢰성 운영 방식을 도입하고 싶은 팀이라면 특히 유용합니다.

다음과 같은 경우에는 활용도가 떨어질 수 있습니다:

• 아직 의미 있는 서비스 메트릭이 전혀 없는 경우
• 핵심 문제는 신뢰성 목표 설계가 아니라 incident response인 경우
• 법무용 또는 고객-facing SLA 문서만 필요한 경우

도입 전에 사용자가 가장 궁금해하는 점

slo-implementation install을 검토하는 대부분의 사용자는 다음을 확인하고 싶어 합니다:

1. 이론 설명이 아니라 실제로 실행 가능한 SLO 설계 도움을 주는지
2. 쿼리나 알림 같은 구현 세부사항까지 지원하는지
3. 보여주기식 uptime 목표 같은 나쁜 SLO를 피하는 데 도움이 되는지
4. 실제 워크플로에 넣어 쓸 만큼 간결한지

이 기준에서 보면 이 스킬은 실용적인 편입니다. 일반적인 SLI 유형, 목표값 설정 예시, objective와 error budget의 관계까지 다룹니다.

핵심 강점과 트레이드오프

slo-implementation의 가장 큰 차별점은 일반적인 observability 조언으로 퍼지지 않고, 신뢰성 측정과 정책 설계에 집중한다는 점입니다. 이 집중력 덕분에 호출 의도를 분명히 하기도 쉽습니다.

반면 이 스킬의 품질은 사용자가 제공하는 서비스 맥락에 크게 좌우됩니다. 사용자 여정, 트래픽 패턴, 의존성, 임계값, 메트릭 이름을 구체적으로 주지 않으면 결과는 그럴듯해 보여도 실제 운영에 옮기기 어려워질 수 있습니다.

slo-implementation 스킬 사용 방법

slo-implementation 스킬 설치 맥락

에이전트가 custom skills에 접근할 수 있는 환경에 이 스킬을 설치하세요. 일반적인 패턴은 다음과 같습니다:

1. 소스 저장소를 skills 설정에 추가합니다
2. slo-implementation 스킬을 활성화합니다
3. SLI, SLO, error budget, 또는 SLO 기반 알림을 정의하거나 수정하는 작업에서 호출합니다

도구가 직접 스킬 설치를 지원한다면, 다음 저장소 경로에 대해 평소 쓰는 skill loader를 사용하면 됩니다:
https://github.com/wshobson/agents/tree/main/plugins/observability-monitoring/skills/slo-implementation

저장소 기준으로 이 스킬에는 SKILL.md만 확인되므로, 별도 helper script나 추가 참고자료를 기대하기보다 먼저 그 파일부터 읽는 것이 좋습니다.

먼저 읽어야 할 파일

다음 파일부터 시작하세요:

• plugins/observability-monitoring/skills/slo-implementation/SKILL.md

이 파일에 slo-implementation guide의 핵심 내용이 들어 있습니다. 목적, 사용 시점, SLI/SLO/SLA 계층, 대표적인 SLI 유형, 목표값 예시, 구현 패턴까지 실제 내용이 이 파일에 담겨 있습니다.

유의미한 결과를 위해 필요한 입력

품질 높은 slo-implementation usage를 원한다면, 에이전트에 다음 정보를 주세요:

• 서비스 이름과 사용자가 그 서비스로 무엇을 하는지
• 가장 중요한 user-facing 여정
• 현재 사용 가능한 메트릭과 라벨
• 기존 대시보드, 알림, 또는 PromQL이 있다면 그 내용
• 트래픽 규모와 계절성
• 비즈니스 중요도와 장애 비용
• endpoint 또는 operation별 latency 기대치
• 알려진 failure mode
• 내부용 SLO가 필요한지, 외부 SLA 정렬도 필요한지, 혹은 둘 다 필요한지

이 정보가 없어도 스킬이 SLO 초안을 만들 수는 있지만, 대개는 일반적인 availability 목표와 단순한 request 기반 SLI로 수렴하게 됩니다.

막연한 목표를 좋은 프롬프트로 바꾸는 법

약한 프롬프트:

• “Create SLOs for my API.”

더 나은 프롬프트:

• “Use the slo-implementation skill to define SLIs and SLOs for a multi-tenant payments API. Our critical user journeys are charge creation and webhook delivery. We use Prometheus. Available metrics include http_requests_total, http_request_duration_seconds_bucket, and queue retry counters. Propose 2 to 3 SLIs, recommend SLO targets, calculate monthly error budgets, and suggest burn-rate alerts. Exclude admin endpoints and health checks.”

이 프롬프트가 잘 작동하는 이유:

• 서비스 경계를 분명히 정합니다
• 실제 메트릭을 지정합니다
• 의미 있는 user journey로 범위를 제한합니다
• 스킬이 잘 만들어낼 수 있는 산출물을 명확히 요청합니다

처음 쓸 때 가장 좋은 워크플로

실용적인 slo-implementation usage 흐름은 다음과 같습니다:

1. 플랫폼 전체가 아니라 서비스 하나를 고릅니다
2. 핵심 user journey를 1~3개 정합니다
3. 각 여정을 기존 signal에 매핑합니다
4. 스킬에 candidate SLI를 요청합니다
5. 그 SLI가 단순한 시스템 내부 지표가 아니라 실제 사용자 경험을 반영하는지 검토합니다
6. 초기 SLO 목표값과 error budget을 정합니다
7. 알림 로직 초안을 만듭니다
8. 실제 메트릭이 그 설계를 뒷받침하는지 검증합니다
9. rollout 전에 임계값과 exclusion을 조정합니다

이렇게 하면 한 번에 전사 차원의 신뢰성 정책을 정의하려다 실패하는 흔한 패턴을 피할 수 있습니다.

이 스킬이 특히 잘 내놓는 결과

slo-implementation skill이 강한 영역은 다음과 같습니다:

• availability, latency 같은 대표적인 SLI 패턴 제안
• SLI/SLO/SLA 관계 설명
• 신뢰성 목표를 측정 가능한 비율로 번역
• 목표값 범위와 error budget 관점 제안
• SLO 소진율 기반 알림 구조 제시

특히 빠르게 첫 운영 초안을 만들고 싶고, 그것이 표준적인 SRE 언어에 기반하길 원할 때 유용합니다.

팀이 보통 막히는 지점

도입이 멈추는 이유는 보통 다음 중 하나입니다:

• 팀이 user-facing 서비스 경계에 합의하지 못함
• 사용자 여정 메트릭은 없고 인프라 메트릭만 존재함
• latency histogram이 없어서 임계값 기반 SLI가 약함
• 메트릭에 bot 트래픽, 내부 작업, health check가 섞여 분자와 분모가 왜곡됨
• 목표값이 리스크와 비용이 아니라 정치적으로 정해짐

이 스킬은 대화를 구조화하는 데는 도움이 되지만, telemetry가 없는데도 신뢰할 수 있는 측정을 만들어내지는 못합니다.

결과 품질을 높이는 실전 프롬프트 패턴

스킬에게 의사결정에 바로 쓸 수 있는 형식으로 결과를 내달라고 요청하세요. 예를 들면:

• “List candidate SLIs with rationale and tradeoffs.”
• “Recommend one primary SLO and one secondary guardrail SLO.”
• “Show PromQL-style formulas for each SLI.”
• “Identify exclusions that should not count against the SLO.”
• “Suggest alerting windows for fast and slow burn.”

이런 프롬프트 패턴은 추상적인 신뢰성 조언이 아니라 구현 가능한 수준의 결과를 끌어내는 데 도움이 됩니다.

Reliability 업무에서 slo-implementation을 쓰는 방법

slo-implementation for Reliability는 다음 시점에 특히 유용합니다:

• 새 서비스를 출시하기 전
• observability 개선 작업 중일 때
• 반복되는 incident를 통해 현재 알림이 noisy하다는 점이 드러났을 때
• 리더십이 고객 영향과 연결된 신뢰성 목표를 요구할 때
• 엔지니어링 속도와 error budget 정책을 연결해야 할 때

이 스킬의 가치는 팀이 “일단 전부 모니터링하자”에서 “사용자에게 중요한 것을 측정하자”로 넘어갈 때 가장 크게 드러납니다.

slo-implementation 스킬 FAQ

slo-implementation은 일반 프롬프트보다 더 나은가요?

네, 작업이 SLI/SLO 설계에 명확히 맞춰져 있다면 그렇습니다. 일반 프롬프트로도 그럴듯한 정의는 만들 수 있지만, slo-implementation은 계층 구조를 더 잘 유지하고, 측정 가능한 공식과 목표값- error budget-알림 간 연결까지 포함할 가능성이 더 높습니다.

slo-implementation 스킬은 초보자도 쓰기 쉬운가요?

어느 정도는 그렇습니다. 초보자도 사용할 수 있지만, 기본적인 SRE 개념과 약간의 telemetry 맥락을 알고 있을수록 결과가 훨씬 좋아집니다. SLO가 처음이라면 우선 서비스 하나에만 적용해 보고, 제안된 각 메트릭을 하나씩 검토한 뒤 채택하는 것이 좋습니다.

Prometheus가 꼭 필요한가요?

아니요. 다만 스킬 내용은 분명 Prometheus와 PromQL 스타일 사고방식에 잘 맞춰져 있습니다. Datadog, CloudWatch, Grafana, 또는 다른 스택을 쓰더라도 동일한 논리를 적용한 뒤 메트릭 표현만 해당 플랫폼에 맞게 옮기면 됩니다.

언제 slo-implementation을 쓰지 말아야 하나요?

다음과 같은 경우에는 slo-implementation을 주 도구로 삼지 않는 것이 좋습니다:

• 법적 효력이 있는 SLA 문구가 필요한 경우
• 사용할 만한 서비스 telemetry가 전혀 없는 경우
• 실제 문제는 측정이 아니라 ownership인 경우
• 서비스가 아직 너무 초기 단계라 안정적인 user journey를 정의하기 어려운 경우

이런 상황이라면 먼저 계측을 하거나, 운영 모델 문제를 해결한 뒤에 SLO를 공식화하는 편이 낫습니다.

알림 설계에도 도움이 되나요?

네. 이 스킬은 목표값 정의에만 머무르지 않고, error budget의 운영 측면과 SLO 기반 알림까지 함께 다룹니다. 그래서 단순히 퍼센트 목표값만 제시하고 끝나는 템플릿보다 실무적으로 더 유용합니다.

slo-implementation 스킬을 더 잘 활용하는 방법

기술 메트릭만이 아니라 비즈니스 맥락도 함께 주세요

slo-implementation 결과를 개선하려면, 신뢰성이 사업적으로 무엇을 의미하는지도 에이전트에 알려주세요:

• 어떤 워크플로가 저하되면 매출 손실로 이어지는가?
• 어떤 사용자가 premium이거나 latency에 민감한가?
• 어느 정도 기간의 영향까지 허용 가능한가?

이 정보가 있어야 스킬이 99.99% 같은 이상적인 숫자로 자동 수렴하지 않고, 현실적인 목표값을 고를 수 있습니다.

서비스 경계를 명시적으로 정의하세요

더 나은 slo-implementation guide 입력은 무엇을 포함하고 무엇을 제외하는지 분명히 적습니다. 예를 들면:

• public API write request는 포함
• /healthz, admin route, 내부 batch job은 제외
• 단순 request acceptance가 아니라 사용자에게 보이는 성공적 완료만 측정

경계가 명확한지는 SLO가 실제로 신뢰받을지 여부를 가르는 가장 큰 요인 중 하나입니다.

메트릭 이름과 샘플 쿼리를 제공하세요

실제 telemetry를 공유하면 이 스킬은 훨씬 더 실행 가능한 결과를 냅니다. 좋은 입력 예시는 다음과 같습니다:

• metric 이름
• label 차원
• histogram bucket
• 현재 alert query
• dashboard 링크 또는 복사한 snippet

이런 정보가 있어야 결과가 개념적인 SLO 설명에서 거의 바로 구현 가능한 정의로 넘어갈 수 있습니다.

보여주기식 SLI를 피하세요

흔한 실패 패턴 중 하나는 수집은 쉽지만 사용자 경험과는 연결이 약한 메트릭을 고르는 것입니다. 예를 들면:

• pod restart 횟수
• CPU saturation 단독 지표
• 서비스 영향 매핑 없이 dependency의 raw uptime만 보는 경우

각 SLI가 왜 사용자가 체감하는 신뢰성을 반영하는지 설명하라고 스킬에 요청하세요. 그 설명이 설득력 없으면 해당 SLI는 교체하는 편이 낫습니다.

첫 초안 이후 반드시 한 번 더 다듬으세요

slo-implementation의 첫 결과는 초안으로 보는 것이 맞습니다. 다음과 같은 질문으로 품질을 끌어올리세요:

• “Which SLI is most representative of user harm?”
• “What would make this SLO impossible to measure accurately?”
• “Which exclusions are risky or easy to abuse?”
• “How would this change for low-traffic services?”
• “What alerting would reduce noise while protecting the error budget?”

이 두 번째 패스는 첫 번째 목표 집합을 그대로 받아들이는 것보다 훨씬 더 나은 운영 설계를 만들어주는 경우가 많습니다.

과거 incident로 압박 테스트하세요

slo-implementation skill 결과를 개선하는 가장 좋은 방법 중 하나는, 제안된 SLI와 알림을 실제 incident와 대조해 보는 것입니다. 다음을 물어보세요:

• 이 SLO가 그 이슈를 실제로 감지했을까?
• 무해한 실패까지 과도하게 집계했을까?
• burn-rate 정책이 너무 이르게 혹은 너무 늦게 호출했을까?

이 검증 단계가 있어야 보기 좋은 문서가 실제로 팀이 운영할 수 있는 기준으로 바뀝니다.

한 번에 서비스 하나씩 적용하세요

결과가 지나치게 일반적으로 느껴진다면, 범위가 너무 넓을 가능성이 큽니다. 이 스킬은 서비스 하나 또는 user journey 하나에 집중할 때 가장 잘 작동합니다. 큰 시스템은 여러 번에 나눠 다룬 뒤, 나중에 패턴을 표준화하세요.