사고는 ‘변경’이 아니라 기본값에서 난다: 가정이 굳는 순간을 다루는 법
마이그레이션 날 아침, 슬랙이 조용했다.
대부분의 실패는 그 조용함으로 시작한다. 에러 폭발이 아니라, “가끔”이 먼저 온다.
“로그인만 가끔 튕겨요.”
“특정 경로만, 어떤 브라우저에서만요.”
누군가는 습관적으로 말한다. “원래 그랬던 거 아닌가요?”
그리고 그 질문이 나온 순간부터, 우리는 기술이 아니라 기억력과 싸우게 된다.
무슨 규칙이 있었는지. 왜 그 규칙이 생겼는지. 그 규칙이 ‘기본값’으로 굳은 게 언제부터였는지.
사고는 새로운 기능에서 자주 나지 않는다. 사고는 기본값이 몰래 고정해둔 가정에서 난다.
기본값은 일을 줄여준다. 대신 가정을 숨긴다. 숨겨진 가정은 변화(마이그레이션/리디자인/검증) 앞에서 가장 먼저 깨진다.
기본값은 “설정”이 아니라 “해석”이다
우리는 기본값을 흔히 ‘설정 안 하면 이렇게 된다’ 정도로 취급한다.
하지만 실무에서 더 자주 부딪히는 기본값은 ‘해석 규칙’이다.
예를 들어 라우팅 레이어에서 “이 정도면 prefix겠지”라고 믿었던 규칙이, 실제 구현에서는 다른 방식으로 매칭되고 있었던 경우. 정규식 옵션 하나가 생각보다 넓게 영향을 주고, 케이스 처리 같은 디테일이 어느 날부터 정책처럼 굳어버리는 경우. Kubernetes Ingress-NGINX 마이그레이션 글이 “이사 가기 전에 꼭 알고 가야 한다”는 포인트로 다루는 것도 결국 이런 종류의 조용한 해석들이다. (참고자료)
UI도 다르지 않다. Vercel이 대시보드 네비게이션을 새 기본값으로 바꿨다는 공지를 보면, 겉으로는 메뉴 재배치다. 그런데 팀 입장에선 ‘자주 쓰던 길의 시작점’이 바뀌는 일이고, 그 길 위에서만 돌아가던 일들이 한번에 흔들린다. (참고자료)
그리고 보안 인프라처럼 더 깊은 곳으로 내려가면 기본값은 더 무섭다. 인증서 체계처럼 ‘기반’이 바뀌는 변화는, 결국 우리가 당연하다고 믿던 입력/출력의 모양을 바꾸는 사건이다. (참고자료)
기본값은 결국 “우리는 세상을 이렇게 생겼다고 가정한다”를 시스템에 박아두는 일이다.
검증은 ‘정답 찾기’가 아니라 ‘가정 드러내기’로 시작한다
사고가 나면 팀은 그럴듯한 가설을 빨리 채택하고 싶어한다. 하지만 가설은 “증거가 생기기 전까진 가설”로 남겨야 한다. (참고자료)
프로덕션에서의 “그럴듯함”도 같다.
- 로그가 말하는 것 같고
- 모니터링 그래프가 그럴듯하고
- 사람의 경험담이 그럴듯한데
정작 ‘기본값이 고정한 가정’이 무엇인지가 기록에 없다.
그래서 나는 장애 대응이든 변경이든, 검증의 첫 질문을 이렇게 둔다.
“우리가 지금까지 ‘당연히 그럴 것’이라고 믿었던 해석 규칙이 뭐지?”
이걸 찾기 전에는 원인 분석도, 재발 방지도, 다음 마이그레이션도 똑같은 지뢰밭이 된다.
실무 메모: 기본값이 만든 가정을 ‘말로’ 끌어내는 방법
나는 이걸 체크리스트로 만들어 놓으면 다들 형식만 채우고 지나가서, 회의에서 던지는 문장으로 적어둔다.
“가끔” 버그가 나왔을 때 - “이게 새로 생긴 현상인지, 원래 있던 게 커진 건지”를 먼저 갈라본다. - “원래 그렇다”는 말이 나오면, 그 원래를 코드나 설정이 아니라 ‘해석 규칙’으로 적어본다(예: 어떤 경로가 먼저 매칭되는지, 어떤 입력이 허용되는지). 예: “정규식이 언제부터 켜져 있었지?”, “trailing slash가 어디서 먹히지?”, “대소문자 구분이 어느 레이어 기준이지?”
마이그레이션이나 리디자인을 앞두고 - “사람이 자주 밟는 길이 어디인지”를 한 번만이라도 화면/호출 흐름으로 찍어둔다. 변경 후에 그 길이 끊기면, 기능이 살아 있어도 사건이 된다. - “이 해석 규칙은 환경이 바뀌면 달라질 수 있다”는 지점을 일부러 골라 테스트로 박아둔다. 새 기능 테스트가 아니라 ‘당연한 동작’ 테스트.
검증(리뷰/실험/조사)을 할 때 - 그럴듯한 답을 빨리 채택하지 않게 만든다. 대신 “이 결론이 틀렸을 때 어떤 피해가 나는지”를 한 문장으로 적게 한다. - 증거가 부족하면 ‘더 파고들기’보다 ‘해석 규칙을 더 좁히기’를 한다. 범위를 좁히면, 다음날 회의가 짧아진다.
결정 기준: 지금은 기능을 더 붙일 때가 아니라 ‘기본값을 고백’할 때인지
아래 중 두 개만 걸려도, 기능 얘기는 잠깐 멈추는 게 낫다.
- “가끔”이 늘었는데, 누구도 같은 말로 재현을 설명하지 못한다.
- 같은 변경을 두고 팀마다 “원래”의 정의가 다르다.
- UI나 라우팅 같은 ‘길’이 바뀌었는데, 사용자/지원/온콜의 말이 서로 어긋난다.
- 검증이 그럴듯한 결론으로 끝나고, 다음번엔 똑같이 다시 논쟁이 시작된다.
규모가 커질수록 변경은 더 자주 오고, 동시에 더 많은 사람이 영향을 받는다. 그래서 기본값이 만든 가정은 더더욱 조용히 두면 안 된다. (참고자료)
사고를 줄이는 가장 빠른 방법은 “새 기능”이 아니라, 기본값이 고정한 해석을 팀의 언어로 끌어내는 것이다.
참고자료
- Kubernetes Blog — Before You Migrate: Five Surprising Ingress-NGINX Behaviors You Need to Know
- https://kubernetes.io/blog/2026/02/27/ingress-nginx-before-you-migrate/
- Vercel Changelog — New dashboard redesign is now the default
- https://vercel.com/changelog/dashboard-navigation-redesign-rollout
- Ars Technica — Google quantum-proofs HTTPS by squeezing 15kB of data into 700-byte space
- https://arstechnica.com/security/2026/02/google-is-using-clever-math-to-quantum-proof-https-certificates/
- Ars Technica — In puzzling outbreak, officials look to cold beer, gross ice, and ChatGPT
- https://arstechnica.com/health/2026/02/did-chatgpt-help-health-officials-solve-a-weird-outbreak-maybe/
- OpenAI — Scaling AI for everyone
- https://openai.com/index/scaling-ai-for-everyone
실전 적용
기본값이 만든 가정은 “알고 있겠지”라고 넘기는 순간부터 숨어버립니다. 그래서 변경(마이그레이션/리디자인/정책 반영)을 하기 전날이 아니라, 변경을 “생각하기 시작한 날”에 작은 장치를 걸어두는 편이 낫습니다. 아래는 내가 실제로 팀 채널에서 던져보는 문장들입니다. 문서로 멋지게 정리하는 대신, 당장 다음 배포/이관에서 누구든 같은 질문을 하게 만드는 용도예요.
- 변경 전에 “안 바뀌어야 하는 것”을 한 줄로 적는다: 경로 매칭/권한 처리/만료 동작 같은 핵심 해석 규칙.
- 자주 깨지는 입력을 일부러 하나 고른다: trailing slash, 대소문자, 리다이렉트 체인처럼 사람들 기억이 엇갈리는 것.
- 테스트는 새 기능이 아니라 “옛 동작 보존”부터 만든다(한 케이스만이라도). 실패하면 바로 알림이 오게.
- 관측은 에러 로그가 아니라 “왜 이 선택이 됐는지”를 남긴다: 어떤 규칙이 적용됐고 어떤 분기가 선택됐는지.
- 지원/온콜이 쓸 수 있는 짧은 안내 문장을 준비한다: 원인 설명이 아니라 “지금 사용자가 할 다음 행동” 중심.
- 변경 범위를 잘게 쪼갠다: 전면 전환 말고, 특정 경로/특정 테넌트/특정 사용자군부터.
흔한 함정은 두 가지입니다. 둘 다 “열심히 했는데도” 터집니다.
- 함정 1) 재현이 어려운 “가끔”을 개인 경험담으로 덮어버리기: 결국 다음 변경에서 더 크게 터지고, 그땐 기억이 더 없다.
- 함정 2) 규칙을 문장으로만 합의하고 실행 위치를 못 박지 않기: 위키엔 맞는데 시스템은 다르게 굴러서, 팀마다 ‘원래’가 갈라진다.
댓글
댓글 쓰기