Shift-Left 신뢰성
Source: Dev.to
위에 제공된 링크에 있는 전체 텍스트를 여기 복사해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록이나 URL은 그대로 유지됩니다.)
역설
우리는 사고 대응에 매우 능숙해졌습니다. 현대 팀은 서비스를 신속히 복구하고, 신중한 사후 분석을 수행하며, 시정 조치를 통해 스스로에게 책임을 묻습니다.
그럼에도 불구하고…
한 팀이 모든 테스트를 통과하고 필요한 모든 승인을 받은 변경을 배포했지만, 47 분 동안 체크아웃을 중단시켰습니다. 사후 분석 결론은? “배포하기 전에 우리 지연 SLO가 이미 94 %였다는 것을 알았어야 했다.”
많은 사후 분석이 동일한 근본 원인을 지적합니다: 우리가 직접 도입한 변경. 하드웨어 고장이 아니라. 무작위 장애도 아니라. 단지 소프트웨어가 우리가 명령한 대로 정확히 동작했을 뿐입니다.
우리는 여전히 신뢰성을 변경이 이미 라이브된 후에 평가해야 할 대상으로 취급합니다. 이는 도구나 프로세스의 실패가 아니라, 시스템이 준비되었는지를 언제 판단하느냐에 대한 문제입니다.
오늘 실제로 신뢰성 결정이 이루어지는 곳
나는 여러 팀이 동일한 기술 스택을 사용하면서도 전혀 다른 SLO, 메트릭, 알림을 운영하는 모습을 보았다. 무엇을 구현해야 하는지, 베스트 프랙티스가 무엇인지, 알림을 어떻게 조정해야 하는지에 대한 안내가 전혀 없었다. 그들은 좋은 신뢰성 시민이 되고 싶어하지만, 핸드북에 적힌 이론을 실제로 적용하는 과정은 간단하지 않다.
- 서비스가 프로덕션에 배포될 때 SLO가 몇 달 뒤에—또는 전혀—작성된다.
- 대시보드가 없거나, 부족하거나, 일관성이 없다.
- PR 리뷰 시 “괜찮아 보이네” 라는 의견만 있다.
- 팀마다 서로 다른 수준의 트리벌 지식과 이해도가 존재한다.
신뢰성은 근본적으로 맞춤형이며 관리되지 않는다. 이것이 핵심 문제다.
누락된 레이어
GitHub은 코드에 대한 버전 관리를 제공했습니다. Terraform은 인프라에 대한 버전 관리를 제공했습니다. 보안은 shift‑left 접근 방식으로 변모했습니다—배포 후가 아니라 코드가 작성되는 즉시 결함을 찾는 방식입니다.
우리는 아직 신뢰성에 대한 버전 관리가 부족합니다.
다음과 같은 사양이 필요합니다:
- 요구사항을 정의합니다.
- 현실과 대조하여 검증합니다.
- 대시보드, SLO, 알림, 에스컬레이션 정책과 같은 산출물을 생성합니다.
사양이 검증되고 산출물이 생성되면, 동일한 도구가 실시간으로 서비스가 위반 상태인지 확인하고 CI/CD에서 고위험 배포를 차단할 수 있습니다.
실제로 shift‑left 신뢰성이 의미하는 것
Shift‑left 신뢰성은 더 많은 알림, 더 많은 대시보드, 더 많은 사후 분석, 혹은 더 많은 인원이 방에 있다는 뜻이 아닙니다. 의미하는 바는 다음과 같습니다:
- Spec – 프로덕션 배포 전에 신뢰성 요구사항을 코드로 정의합니다.
- Validate – 그 요구사항을 실제와 비교해 테스트합니다.
- Enforce – CI/CD를 통해 배포를 게이트합니다.
엔지니어는 PromQL이나 Grafana JSON을 작성하지 않습니다—그들은 의도를 선언하고, 신뢰성은 결정론적으로 변합니다. 결과는 예측 가능하고, 일관되며, 투명하고, 모범 사례를 따릅니다.
실행 가능한 신뢰성 계약
간단하게 유지하세요. 팀은 신뢰성 의도를 담은 service.yaml 파일을 생성합니다:
name: payment-api
tier: critical
type: api
team: payments
dependencies:
- postgresql
- redis전체 service.yaml 예시는 여기에서 확인할 수 있습니다.
도구는 메트릭, SLO, 오류 예산을 검증하고 이러한 산출물을 자동으로 생성합니다. 이것은 NthLayer라는 오픈‑소스 프로젝트를 통해 탐색하고 있는 접근 방식입니다.
NthLayer는 GitHub Actions, ArgoCD, Jenkins, Tekton, GitLab CI 등 모든 CI/CD 파이프라인에서 실행됩니다. 목표는 경직된 차단기가 되는 것이 아니라 위험을 가시화하고 의사결정을 명확히 하는 것입니다. 의도적이고 기록되며 담당자가 있는 경우에는 오버라이드가 허용됩니다.
배포가 시도될 때, 사양은 실제와 비교되어 평가됩니다:
$ nthlayer check-deploy -service payment-api
ERROR: Deployment blocked
- availability SLO at 99.2 % (target: 99.95 %)
- error budget exhausted: -47 minutes remaining
- 3 P1 incidents in last 7 days
exit code: 2 (BLOCKED)왜 지금인가?
SLO는 8년 이상 동안 성숙해 왔으며 Google SRE Handbook에서 주류 실무로 옮겨졌습니다. GitOps는 선언형 구성을 표준화했습니다. Platform Engineering은 하나의 학문 분야로 자리 잡았습니다. 개념은 준비돼 있지만 도구는 뒤처져 있었습니다.
이는 접근 방식을 의도적으로 전환한 것입니다. 신뢰성은 이제 사고 발생 시 논쟁거리가 아닙니다. 서비스마다 결정론적 기준을 가진 명확한 소유자가 있습니다. 새로운 서비스를 온보딩할 때마다 신뢰성 휠을 다시 만들 필요가 없습니다. 요구사항이 바뀌면 service.yaml을 업데이트하고 NthLayer를 실행하면 모든 서비스가 새로운 기준의 혜택을 받게 됩니다.
이것이 대체하지 않는 것
NthLayer는 서비스 카탈로그, 개발자 포털, 가시성 플랫폼, 혹은 인시던트 관리 시스템을 대체하지 않습니다. 또한 장애를 예측하거나 인간의 판단을 없애지는 못합니다. 이 도구는 이러한 모든 시스템의 업스트림에 위치합니다.
목표: 신뢰성 사양, 자동화된 배포 게이트, 그리고 모범 사례 구현에 필요한 인지 부하 감소.
Open questions
모든 답을 가지고 있는 것은 아니지만, 제가 계속 되돌아보는 두 가지 질문이 있습니다:
- Contract Drift: 사양은 99.95 %라고 하지만 실제는 몇 달 동안 99.5 %였을 때는 어떻게 되나요? 계약이 잘못된 건가요, 아니면 서비스가 고장난 건가요?
- Emergency Overrides: 배포를 진행해야 하는 긴급 상황에서 신뢰성 검사가 실패했음에도 불구하고 어떻게 처리해야 할까요?
신뢰성을 좌측으로 이동시키는 것을 실질적인 현실로 만들기 위해 생각, 경험, 혹은 제안을 자유롭게 공유해 주세요.
어떻게 작동해야 할까요? 누가 승인하나요? 기본값이 되는 것을 어떻게 방지하나요?
타이밍 문제
조직에서 신뢰성 결정은 실제로 어디서 이루어지나요?
배포 전에 준비 상태를 결정한다면 어떻게 될까요?
자동으로 적용하고 싶은 신뢰성 규칙은 무엇인가요?
타이밍 문제는 사라지지 않습니다. 유일한 질문은 배포 전에 이를 해결하느냐, 아니면 사후 검토에서 나중에 알게 되느냐입니다.
NthLayer – 오픈 소스, 초기 채택자 모집
신뢰성이 사후 생각이 되는 것이 지겹다면:
pip install nthlayer
nthlayer init
nthlayer check-deploy --service your-service→ github.com/rsionnach/nthlayer
레포를 별표하고, 이슈를 열거나, 제가 틀렸다고 알려 주세요. 여러분 조직에서 신뢰성 결정이 어떻게 이루어지는지 듣고 싶습니다.
Rob Fox는 플랫폼 및 신뢰성 도구에 집중하는 수석 사이트 신뢰성 엔지니어입니다. 그는 신뢰성 엔지니어링을 소프트웨어 전달 라이프사이클의 초기 단계로 이동시키는 방법을 탐구하고 있습니다. GitHub에서 그를 찾아보세요.