- 겪어 본 사람은 무엇을 다르게 읽는가
- 프로덕션은 코드가 아니라 상태입니다
- 100퍼센트는 옳은 목표가 아닙니다
- 관측, 롤백, 점진 배포는 도구가 아닙니다
- 속도와 안정성을 맞바꾼다는 오해
- 겪지 않고 배우는 세 가지
- 직접 해보기
- 이어서 읽기
- 참고 자료
겪어 본 사람은 무엇을 다르게 읽는가
같은 설계 문서를 두 사람이 읽습니다. 한 사람은 이 기능이 어떻게 동작하는지를 읽습니다. 다른 사람은 같은 문서에서 다른 것을 읽습니다. 이게 새벽 세 시에 깨지면 무슨 로그가 남는가, 되돌리는 데 몇 분이 걸리는가, 되돌린 뒤에 이미 들어간 데이터는 어떻게 되는가.
두 번째 사람이 더 똑똑한 것은 아닙니다. 한 번 당해 본 것입니다. 그리고 이 차이는 지식으로 나타나지 않고 기본값으로 나타납니다. 아는지 모르는지가 아니라, 묻지 않아도 먼저 확인하는지 아닌지의 차이입니다. 그래서 프로덕션 감각은 시험으로 재기 어렵고, 설계 리뷰 30분이면 드러납니다.
프로덕션은 코드가 아니라 상태입니다
코드는 저장소에 있고 판본이 하나입니다. 프로덕션은 상태이고 판본이 여럿입니다. 지금 돌고 있는 이미지, 지금 걸려 있는 설정, 지난달에 누가 손으로 바꿔 놓고 어디에도 안 적은 값, 3년 동안 쌓여 실제로는 문서와 다른 모양이 된 데이터, 지금 열려 있는 연결의 개수. 이 중에서 저장소가 아는 것은 첫 번째뿐입니다.
그래서 내 컴퓨터에서는 된다는 말은 농담이 아니라 정확한 진술입니다. 다른 상태에서 돌렸으니 다른 결과가 나온 것이고, 이 차이를 좁히는 것이 운영의 대부분입니다.
여기서 3편의 결론이 다시 나옵니다. 돌고 있는 시스템은 자기 자신에 대한 가장 최신 문서입니다. 프로덕션 감각의 절반은 그 문서를 읽는 습관이고, 나머지 절반은 그것이 코드와 다를 수 있다는 사실을 항상 계산에 넣는 습관입니다.
100퍼센트는 옳은 목표가 아닙니다
Google의 SRE 책에서 위험을 다루는 장은 이렇게 말합니다. 100퍼센트는 아마 절대로 옳은 신뢰성 목표가 아니라는 것입니다. 달성이 불가능하기도 하지만, 그보다 사용자가 원하거나 알아차리는 것보다 더 높은 신뢰성이기 때문입니다.
같은 장은 값을 함께 적습니다. 안정성을 최대화하면 새 기능을 만드는 속도가 제한되고 제품이 사용자에게 닿는 속도가 느려지며 비용이 크게 오릅니다. 그리고 그 비용은 선형으로 늘지 않아서, 신뢰성을 한 칸 더 올리는 데 앞 칸의 100배가 들 수 있다고 적혀 있습니다.
여기서 나오는 장치가 에러 예산입니다. 목표와 100퍼센트 사이의 차이를 이번 기간에 남은 불안정성의 예산으로 다룹니다. 이 장치의 진짜 값어치는 계산이 아니라 대화에 있습니다. 얼마나 안정적이어야 하는가가 취향 싸움에서 숫자 문제로 바뀝니다. 그리고 숫자 문제가 되면 개발과 운영이 서로 반대편에 서지 않게 됩니다.
관측, 롤백, 점진 배포는 도구가 아닙니다
이 세 가지는 대개 도구 이름과 함께 소개되지만, 실제로 사람을 가르는 지점은 도구가 아닙니다.
관측은 무엇을 깔았느냐가 아니라, 배포하기 전에 이게 잘못되면 어디를 보면 되는지에 답이 있느냐입니다. 대시보드가 스무 개여도 그 질문에 답이 없으면 관측은 없는 것입니다.
롤백은 명령이 있느냐가 아니라 되돌릴 수 있는 상태로 만들었느냐입니다. 스키마를 이전 판본이 못 읽는 형태로 바꿔 놓았다면 롤백 명령은 있어도 롤백은 없습니다. 되돌릴 수 있게 만드는 일은 배포 순간이 아니라 설계 순간에 결정됩니다.
점진 배포는 비율을 나누는 기능이 아니라 멈출 기준을 미리 정하는 일입니다. 5퍼센트에 넣고 지켜보자는 계획에는 무엇을 보면 멈출지가 빠져 있고, 그게 없으면 사람들은 지켜보다가 그냥 전체로 갑니다.
예시 — 배포 전에 미리 채워 두는 네 줄
나빠졌다고 판단하는 기준: 어떤 지표가 어떤 값을 넘으면
어디서 보이나: 그 지표를 볼 대시보드나 로그 질의
멈추는 시점: 몇 분 관찰하고, 어떤 값이면 중단
되돌리면 데이터는: 되돌릴 수 있는가, 없다면 무엇이 남는가
네 줄을 못 채운 채 배포하는 것이 반드시 나쁜 것은 아닙니다. 다만 그때는 배포가 아니라 실험을 하고 있다는 것을 알고 하는 편이 낫습니다.
속도와 안정성을 맞바꾼다는 오해
흔한 전제가 하나 있습니다. 자주 배포할수록 위험해지므로 안정성을 원하면 천천히 가야 한다는 것입니다.
DORA가 공개한 지표 안내는 반대 방향을 말합니다. 배포 빈도, 변경 리드 타임, 실패한 배포의 복구 시간, 변경 실패율, 배포 재작업률 다섯 개를 놓고 보면 대부분의 팀에서 지표들이 서로 상관되어 있고, 잘하는 팀은 다섯 개 전부에서 잘하며 못하는 팀은 전부에서 못한다는 것입니다. 같은 문서는 속도와 안정성이 맞바꿈 관계가 아니라고 명시합니다.
이 관찰을 인과로 읽으면 안 됩니다. 상관은 방향을 말해 주지 않고, 조직의 다른 요인이 다섯 개를 동시에 밀어 올렸을 수도 있습니다. 다만 구조적으로 읽을 수 있는 것은 있습니다. 안전하게 만드는 장치와 빠르게 만드는 장치가 대체로 같은 장치라는 점입니다. 되돌릴 수 있으면 더 자주 낼 수 있고, 자주 내면 한 번에 들어가는 변경이 작아지고, 변경이 작으면 깨졌을 때 원인 후보가 좁습니다.
겪지 않고 배우는 세 가지
프로덕션 감각을 얻는 가장 확실한 길은 큰 장애를 겪는 것이고, 그건 추천할 만한 학습 계획이 아닙니다. 대신 쓸 수 있는 것이 세 가지 있습니다.
첫째는 남의 사고 보고서를 읽는 것입니다. 그냥 읽으면 남의 이야기로 끝나므로 순서를 바꿉니다. 시간순 기록만 먼저 읽고, 그 시점에 자기가 무엇을 했을지 정한 다음, 나머지를 읽습니다. 자기 답과 실제가 갈리는 지점이 배울 곳입니다.
둘째는 온콜에 들어가는 것입니다. 알림을 받아 본 사람은 알림을 다르게 설계합니다. 온콜을 한 번도 안 서 본 사람이 만든 알림은 대개 너무 많고, 많으면 무시되고, 무시되면 없는 것과 같습니다.
셋째는 일부러 깨뜨려 보는 것입니다. 시간을 잡고 의존하는 것 하나를 중단시킨 뒤 팀이 얼마나 빨리 알아차리는지 봅니다. 여기서 보통 놀라는 것은 복구 시간이 아닙니다. 아무도 알아차리지 못했다는 사실입니다.
직접 해보기
이번 주에 나가는 배포 하나를 골라 위 네 줄을 배포 전에 적어 두세요. 5분이면 됩니다. 네 줄 중 하나라도 안 써지면, 그 줄이 이번 배포에서 가장 위험한 부분입니다.
- SLO와 에러 예산 계산기 — 가용성 목표를 허용 다운타임과 예산으로 바꿔 보면, 지금 구조로 그 목표가 애초에 가능한지가 계산으로 나옵니다. 의존성 가용성이 곱해진다는 사실이 특히 아프게 드러납니다.
- 리눅스 터미널 시뮬레이터 — 돌고 있는 시스템의 상태를 손으로 확인하는 조작을 안전하게 반복할 수 있습니다. 관측은 도구를 사는 일이기 전에 보는 습관입니다.
안 통하는 경우도 적어 둡니다. 아직 사용자가 없는 제품이나 내부에서만 쓰는 도구에서는, 배포 절차를 두껍게 깔수록 배우는 속도가 느려집니다. 이 단계에서 네 줄 중 실제로 값어치가 있는 것은 마지막 줄 하나입니다. 데이터를 되돌릴 수 있는가. 나머지는 사용자가 생긴 다음에 붙여도 늦지 않습니다.
이어서 읽기
- 이 블로그의 관련 글: 인시던트 커뮤니케이션: 장애 상황의 대화법
비싸게 남는 기술 시리즈
참고 자료
- Embracing Risk — Google SRE Book — 100퍼센트는 아마 절대로 옳은 신뢰성 목표가 아니며 사용자가 원하거나 알아차리는 것보다 높다는 문장, 극단적 신뢰성이 개발 속도를 제한하고 비용을 크게 올린다는 논거, 신뢰성 한 칸을 더 올리는 데 앞 칸의 100배가 들 수 있다는 서술, 그리고 에러 예산의 정의가 여기서 나옵니다. 2026-08-15 확인.
- DORA metrics: the four keys — dora.dev — 다섯 개 지표의 정의와, 속도와 안정성이 맞바꿈 관계가 아니며 대부분의 팀에서 지표들이 상관되어 있다는 서술이 여기서 나옵니다. 2026-08-15 확인.
- 배포 전 네 줄과 겪지 않고 배우는 세 가지 방법은 위 자료에 나오는 것이 아니라 이 글에서 정리한 것입니다.
현재 단락 (1/36)
같은 설계 문서를 두 사람이 읽습니다. 한 사람은 이 기능이 어떻게 동작하는지를 읽습니다. 다른 사람은 같은 문서에서 다른 것을 읽습니다. 이게 새벽 세 시에 깨지면 무슨 로그가 ...