Skip to content
←

Split View: 프로덕션 감각 — 장애를 겪어 본 사람이 다르게 보는 것들

✨ Learn with Quiz
|

프로덕션 감각 — 장애를 겪어 본 사람이 다르게 보는 것들

겪어 본 사람은 무엇을 다르게 읽는가

같은 설계 문서를 두 사람이 읽습니다. 한 사람은 이 기능이 어떻게 동작하는지를 읽습니다. 다른 사람은 같은 문서에서 다른 것을 읽습니다. 이게 새벽 세 시에 깨지면 무슨 로그가 남는가, 되돌리는 데 몇 분이 걸리는가, 되돌린 뒤에 이미 들어간 데이터는 어떻게 되는가.

두 번째 사람이 더 똑똑한 것은 아닙니다. 한 번 당해 본 것입니다. 그리고 이 차이는 지식으로 나타나지 않고 기본값으로 나타납니다. 아는지 모르는지가 아니라, 묻지 않아도 먼저 확인하는지 아닌지의 차이입니다. 그래서 프로덕션 감각은 시험으로 재기 어렵고, 설계 리뷰 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 확인.
  • 배포 전 네 줄과 겪지 않고 배우는 세 가지 방법은 위 자료에 나오는 것이 아니라 이 글에서 정리한 것입니다.

A Sense for Production — What Looks Different After You Have Been Through an Outage

What Someone Who Has Been Through It Reads Differently

Two people read the same design doc. One reads how the feature works. The other reads something else in the same pages: what logs exist when this breaks at three in the morning, how many minutes a rollback takes, and what happens to the data that already landed once you roll back.

The second person is not smarter. They got burned once. And the difference does not show up as knowledge, it shows up as defaults — not whether they know, but whether they check before anyone asks. Which is why a sense for production is hard to test for and obvious within thirty minutes of a design review.

Production Is a State, Not a Codebase

Code lives in a repository and has one version. Production is a state and has many. The image currently running, the config currently applied, the value someone changed by hand last month and wrote down nowhere, three years of data that has drifted into a shape the docs no longer describe, the number of connections open right now. Of those, the repository knows the first one.

Which is why "it works on my machine" is not a joke but an accurate statement. It ran against a different state, so it produced a different result, and closing that gap is most of what operations is.

Here the conclusion from part 3 returns. A running system is the most current documentation of itself. Half of a production sense is the habit of reading that documentation; the other half is the habit of always keeping in your arithmetic that it may differ from the code.

100% Is Not the Right Target

The chapter on risk in Google's SRE book puts it plainly: 100% is probably never the right reliability target — not only is it impossible to achieve, it is typically more reliability than a service's users want or notice.

The same chapter attaches the price. Maximizing stability limits how fast new features can be developed and how quickly products reach users, and it dramatically increases cost. And that cost does not rise linearly: an incremental improvement in reliability may cost a hundred times more than the previous increment.

The device that comes out of this is the error budget. The gap between your target and 100% is treated as the budget of unreliability remaining for the period. The real value of the device is not the arithmetic, it is the conversation. How reliable this has to be stops being a contest of preferences and becomes a question with a number in it. And once it is a number, development and operations stop standing on opposite sides.

Observability, Rollback, and Gradual Rollout Are Not Tools

These three usually arrive attached to product names, but the thing that actually separates people is not the tooling.

Observability is not what you installed. It is whether, before deploying, you have an answer to where you would look if this goes wrong. Twenty dashboards with no answer to that question is no observability at all.

Rollback is not whether the command exists but whether you built a state you can return to. Change a schema into a shape the previous version cannot read and you have a rollback command with no rollback behind it. Being able to go back is decided at design time, not at deploy time.

Gradual rollout is not a percentage feature; it is deciding the stop rule in advance. "Put it on 5% and watch" is a plan with the stopping criterion missing, and without one, people watch for a while and then just go to a hundred.

Example — four lines filled in before the deploy

what counts as worse:  which metric crossing which value
where you would see it: the dashboard or log query for that metric
when you stop:          how long you watch, and at what value you abort
what rollback does to data: can it be reversed, and if not, what remains

Deploying without those four lines is not automatically wrong. It is just better to know that what you are doing is an experiment rather than a deploy.

The Misreading That Speed Trades Against Stability

One premise is common: deploying more often is riskier, so if you want stability you have to go slow.

DORA's guide to their metrics says the opposite. Across deployment frequency, change lead time, failed deployment recovery time, change fail rate, and deployment rework rate, the metrics are correlated for most teams — top performers do well on all of them and low performers do poorly on all of them. The same document states explicitly that speed and stability are not tradeoffs.

Do not read that observation as causation. Correlation does not give you a direction, and some other organizational factor may have lifted all five at once. What can be read structurally is this: the machinery that makes changes safe and the machinery that makes them fast is largely the same machinery. If you can roll back you can ship more often; if you ship often each change is smaller; if changes are small the list of suspects is short when something breaks.

Three Ways to Learn It Without the Outage

The surest route to a production sense is living through a big outage, which is not a study plan anyone should recommend. Three substitutes are available.

The first is reading other people's postmortems. Read straight through and it stays someone else's story, so change the order. Read only the timeline first, decide what you would have done at that moment, then read the rest. The point where your answer and theirs diverge is the part worth learning.

The second is going on call. People who have received the pages design pages differently. Alerts built by someone who has never been on call are usually too numerous, too many alerts get ignored, and ignored alerts are the same as no alerts.

The third is breaking things on purpose. Book the time, stop one thing you depend on, and watch how quickly the team notices. What usually surprises people is not the recovery time. It is that nobody noticed at all.

Try It This Week

Take one deploy going out this week and write the four lines above before it ships. Five minutes. If any of the four will not write, that line is the riskiest part of this deploy.

  • SLO & Error Budget Calculator — turn an availability target into allowed downtime and a budget and you find out by arithmetic whether the current architecture can reach it at all. That dependency availabilities multiply is the part that stings.
  • Linux Terminal Simulator — practice inspecting the state of a running system by hand, safely and repeatedly. Observability is a habit of looking before it is a thing you buy.

Where this does not apply: on a product with no users yet, or an internal-only tool, thicker deploy procedure means slower learning. At that stage only one of the four lines earns its keep — whether the data can be reversed. The rest can wait until you have users.

Further Reading

What Stays Expensive series

Sources

  • Embracing Risk — Google SRE Book — the statement that 100% is probably never the right reliability target and is more than users want or notice, the argument that extreme reliability limits development speed and dramatically increases cost, the note that an incremental reliability improvement may cost 100x the previous increment, and the definition of the error budget all come from here. Read 2026-08-15.
  • DORA metrics: the four keys — dora.dev — the definitions of the five metrics and the statement that speed and stability are not tradeoffs, with the metrics correlated for most teams, come from here. Read 2026-08-15.
  • The four pre-deploy lines and the three substitutes for living through an outage are not from those sources; they are what this post assembles.