9.0 9부 소개: 운영, 신뢰성, 관측 가능성
소프트웨어를 만드는 일은 일의 절반일 뿐입니다. 잘 돌아가게 유지하는 것이 나머지 절반이며, 대부분의 조직에서 그것은 끝나지 않는 절반입니다. 이 부는 프로덕션에서 시스템을 운영하는 것에 관한 것입니다. “충분히 믿을 만하다”가 무엇을 뜻하는지 정의하고 그쪽으로 엔지니어링할 것입니다. 예상치 못한 것을 디버깅할 수 있을 만큼 복잡한 시스템의 속을 들여다보고, 일이 깨질 때 일관되게 대응하고, 이 모두를 돈을 낭비하거나 탄소를 태우지 않고 하는 법을 배울 것입니다. 이것들은 시연에서 동작하는 시스템을 사람들이 여러 해 의존할 수 있는 서비스로 바꾸는 규율입니다.
큰 팀에게 이런 관심사는 배경 활동이기를 멈추고 그 자체로 하나의 시스템이 됩니다. 현대 플랫폼은 수백 개의 서비스, 많은 팀, 여러 리전, 제3자 의존성에 걸쳐 있으며, 아무도 전체를 머릿속에 담지 못합니다. 규모는 신뢰성의 가치와 그것을 잘못했을 때의 비용을 모두 올립니다. 한 시간의 다운타임은 잃은 매출과 침식된 신뢰가 됩니다. 모호한 알림 하나가 수천 건의 호출이 됩니다. 클라우드 낭비 몇 퍼센트가 수백만 달러가 됩니다. 이 규모의 운영에는 아무도 완전히 소유하지 않는 시스템에서 많은 사람이 일관되게 행동할 수 있도록 공유된 언어, 공유된 텔레메트리, 공유된 구조가 필요합니다.
기업과 정부 맥락은 모든 판돈을 올립니다. 규제 산업은 법적 가용성 약속, 감사 요건, 의무적 장애 보고를 집니다. 시민 대면 서비스는 공표된 성능 목표를 충족함을 입증해야 하며 그냥 꺼질 수 없습니다. 공공 부문 예산은 커지는 지속가능성과 탄소 중립 의무 아래 납세자의 돈을 씁니다. 이런 환경에서 운영, 신뢰성, 관측 가능성(외부 출력으로부터 시스템의 내부 상태를 이해하는 것)은 단순한 운영 위생 이상입니다. 책무, 보안, 제도적 신뢰의 도구입니다.
이 부의 장
9.1 사이트 신뢰성 엔지니어링: SLI(서비스 수준 지표), SLO(서비스 수준 목표), SLA(서비스 수준 협약)로 신뢰성을 정의하고, 오류 예산(완벽한 신뢰성에서 허용되는 부족분)으로 속도와 안정성의 균형을 잡고, 자동화로 고역(반복적이고 자동화 가능한 수동 운영 작업)을 끈질기게 줄이고, 규모가 놀람이 되지 않도록 용량을 예측함으로써 소프트웨어 엔지니어링을 운영에 적용하는 것.
9.2 관측 가능성과 텔레메트리: 알려진 실패를 모니터링하는 것을 넘어, 시스템이 내보내는 텔레메트리(공유 식별자로 상관되는 지표, 로그, 트레이스, 이벤트) 위에 세워진 진정한 관측 가능성으로, 벤더 중립적인 OpenTelemetry(텔레메트리를 생성하고 수집하는 개방형 표준)로 표준화하고, 행동 가능하고 사용자에게 보이는 문제에 대해서만 사람을 호출하는 알림을 설계하는 것.
9.3 인시던트 관리: 지속 가능한 온콜 순환, 정의된 역할과 심각도 수준이 있는 분명한 인시던트 지휘 구조(대응을 조율하는 정의된 위계), 정직한 이해관계자 소통, 개인의 잘못이 아니라 체계적 원인을 겨냥해 시정 조치를 끝까지 이끄는 비난 없는 사후 검토로 중단을 탐지하고, 조율하고, 해결하고, 거기서 배우는 것.
9.4 비용, 지속가능성, 그린 소프트웨어: FinOps(클라우드 지출을 위한 재무 운영)의 가시성과 최적화, 탄소 인식(전기가 더 깨끗한 때와 곳에 맞춰 작업을 스케줄) 및 에너지 효율적 설계, 지속적 크기 조정, 비용, 성능, 신뢰성 삼각형 전반의 의도적 트레이드오프로 프로덕션에 재무적, 환경적 책무를 가져오는 것.
9.5 재해 복구와 사업 연속성: 비즈니스 영향 분석에서 복구 시간 및 복구 시점 목표를 정하고, 테스트되고 불변인 백업을 유지하고, 비용과 속도의 스펙트럼 전반에서 복구 전략을 고르고, 복구가 희망이 아니라 입증되도록 장애 조치를 예행연습함으로써 나쁜 날을 살아남을 준비를 하는 것.
9.6 카오스 엔지니어링과 복원력 테스트: 정상 상태를 정의하고, 가설을 세우고, 피해 범위를 통제한 채 현실적인 결함을 주입함으로써 시스템이 격동하는 조건을 견딘다는 확신을 쌓고, 게임 데이에서 지속적이고 자동화된 복원력 검증으로 자라는 것.
9.7 용량 계획과 수요 예측: 의도적인 여유와 함께 컴퓨트, 저장, 네트워크의 공급을 예측된 수요에 맞추고, 부하 테스트와 대기열 이론의 추론을 써서 포화 근처에서 지연이 폭발하지 않게 하고, 비용을 신뢰성과 맞바꾸는 것.
9.8 온콜과 운영 준비도: 서비스를 운영하는 사람들이 소진되지 않고 성공하도록 준비되게, 행동 가능한 알림, 분명한 에스컬레이션, 프로덕션 준비 리뷰와 런북이 있는 인간적이고 지속 가능한 온콜을 설계하는 것.
이 장들이 서로 맞물리는 방식
이 네 장은 팽팽한 운영 루프를 이룹니다. 사이트 신뢰성 엔지니어링(9.1장)이 목표를 정합니다. SLI와 SLO가 신뢰할 수 있다는 것의 뜻을 정의하고, 오류 예산이 언제 속도를 늦출지 정합니다. 관측 가능성(9.2장)은 그 목표를 측정하고 방어하는 방법입니다. SLO 소진율 알림은 잘 구조화된 텔레메트리가 있어야만 동작하고, 대응자가 실패 뒤의 “왜”를 찾는 방법이기도 하기 때문입니다. 인시던트 관리(9.3장)는 계획보다 빨리 오류 예산을 쓸 때 일어나는 일입니다. 9.2장의 알림이 발동하고, 지휘 구조가 작동하고, 결과적인 비난 없는 사후 검토가 신뢰성과 계측 작업에 지속적 개선을 되먹입니다. 비용과 지속가능성(9.4장)이 루프를 닫습니다. 모든 곳을 도금하는 대신 9.1장에서 정의한 SLO에 맞춰 신뢰성과 성능을 프로비저닝하라고 주장하여, 비용, 성능, 신뢰성의 삼각형이 두려움이 아니라 의도적으로 균형을 이루게 합니다.
연결은 이 부를 훨씬 넘어 닿습니다. 여기의 신뢰성 소유권은 1.2장의 팀 토폴로지에 의해 형성되고, 안전하고 빈번한 배포가 규모에서 운영하기 위한 전제 조건이므로 8.1장과 8.4장의 파이프라인과 플랫폼 엔지니어링을 통해 전달됩니다. 사고 대응을 정직하게 만드는 비난 없고 학습 지향적인 문화는 1.1장에서 시작하고, 이 실천들 밑의 신뢰성과 복원력 패턴은 3.3장과 3.5장의 아키텍처에 근거합니다. 마지막으로 이 규율들이 생산하는 증거, 곧 감사에 준비된 텔레메트리에서 사후 검토, 비용 귀속까지가 10.2장과 11.3장의 위험, 보증, 거버넌스 작업에 직접 공급됩니다. 잘 운영되면 이 부의 시스템은 코드가 쓰인 한참 뒤에도 조직이 약속을 지키게 해 주는 것입니다.