설정 변경이 코드 배포보다 위험한 이유 — 설정도 코드처럼

코드는 리뷰를 거치고, 테스트를 통과하고, 단계적으로 배포돼요. 그런데 설정은 콘솔에서 값 하나 바꾸면 즉시 전체에 반영돼요.

어느 날 타임아웃 값을 하나 바꿨는데 서비스가 무너졌어요. 코드는 한 줄도 안 바뀌었고, 배포도 안 했어요.

되돌리려는데 이전 값이 뭐였는지 아무도 몰라요. 기록이 없거든요. 콘솔에는 지금 값만 있고, 어제 무엇이었는지는 안 남아요.

회고에는 "아무것도 안 바꿨는데 장애가 났다"고 적혔어요. 사실은 바꿨는데 그게 기록되는 곳이 없었을 뿐이에요.

설정은 코드보다 훨씬 쉽게 바뀌는데 영향은 같거나 더 큽니다. 그런데 대부분의 팀이 설정에는 코드의 절반도 안 되는 안전장치를 둡니다.

왜 그런가

설정 변경이 위험한 이유가 몇 가지 있어요.

먼저 즉시 전면 반영돼요. 코드 배포는 인스턴스를 하나씩 바꾸면서 문제를 조기에 발견할 기회를 주는데, 설정은 대개 모든 인스턴스가 동시에 새 값을 읽어요. 문제가 있으면 전면적으로 나타나요.

그리고 검토가 없어요. 코드는 리뷰를 받지만 설정은 콘솔에서 바로 바꿔요. 오타 하나, 자릿수 하나가 그대로 반영됩니다.

기록도 남지 않는 경우가 많아요. 누가 언제 무엇을 어떤 값에서 어떤 값으로 바꿨는지가 없으면, 장애 원인을 찾을 때 설정 변경은 아예 후보에 오르지 않아요. "아무것도 안 바꿨는데 장애가 났다"는 회고가 여기서 나옵니다.

되돌리기도 어려워요. 이전 값을 모르니까요.

그리고 설정의 범위가 생각보다 넓어요. 타임아웃, 풀 크기, 재시도 횟수, 기능 플래그, 요금제, 권한, 라우팅 규칙, 로그 수준까지 전부 설정이에요. 이 책에서 본 거의 모든 장치가 설정값으로 조절돼요. 앞 편들에서 "이 값을 조정하세요"라고 한 것들이 전부 여기에 해당합니다.

그래서 역설이 생겨요. 장애를 막으려고 넣은 장치들이 정작 그 값이 잘못 바뀌면 장애의 원인이 돼요. 안전장치일수록 그 설정을 더 조심스럽게 다뤄야 하는 이유예요.

코드로 보면

설정도 코드처럼 다룬다:

✕ 콘솔에서 값 변경 → 즉시 전체 반영 → 기록 없음

· 1) 설정을 저장소에 두고 코드처럼 리뷰한다
✓ 변경이 커밋으로 남는다 → 누가·언제·무엇을·왜
✓ 되돌리기가 되돌리기 커밋이 된다

· 2) 단계적으로 반영한다
✓ 일부 인스턴스 → 전체
✓ 또는 일부 사용자 → 전체

· 3) 값의 범위를 검증한다
✕ timeout = 30      (초인가 밀리초인가?)
✓ 허용 범위를 코드에서 검사하고 벗어나면 거부

· 4) 위험한 설정에는 확인 절차를 둔다
✓ 어떤 값은 콘솔에서 못 바꾸게 한다

✕ 문제 지점 · ✓ 해법 · 그대로 돌려 보기 전에 자기 환경에 맞게 고쳐 주세요.

실전에서는

핵심은 설정을 코드와 같은 수준으로 다루는 것이에요.

저장소에 두는 게 첫 단계예요. 그러면 변경이 커밋으로 남아요. 누가 언제 무엇을 왜 바꿨는지가 자동으로 기록되고, 리뷰를 붙일 수 있고, 되돌리기가 되돌리기 커밋이 돼요. 장애 조사에서 "직전에 무엇이 바뀌었나"에 답할 수 있게 됩니다.

다만 저장소에 두면 반영이 느려져요. 배포를 거쳐야 하니까요. 그래서 실시간으로 바꿔야 하는 값(기능 플래그, 부하 조절)은 별도 시스템에 두되, 그쪽에도 이력과 검토를 남기는 게 좋아요.

단계적 반영도 중요해요. 코드처럼 일부에만 먼저 적용하고 관찰하는 거죠. 많은 설정 시스템이 이 기능을 지원하는데 안 쓰는 경우가 많아요.

값 검증도 필요해요. 단위 혼동이 실전에서 자주 사고를 냅니다. 30 이 초인지 밀리초인지, 크기가 바이트인지 메가바이트인지요. 코드에서 허용 범위를 검사하고 벗어나면 거부하면 이 사고가 사라져요. 앞 편에서 본 영향 범위 제한과 같은 발상이에요.

그리고 위험한 설정과 안전한 설정을 구분해야 해요. 로그 수준을 바꾸는 건 안전하지만 타임아웃이나 풀 크기를 바꾸는 건 위험해요. 위험한 것에는 추가 확인이나 승인을 두는 게 맞습니다.

마지막으로 설정 변경을 배포 이력과 같은 곳에 기록하세요. 장애가 났을 때 "직전 30분 동안 무엇이 바뀌었나"를 한 화면에서 볼 수 있어야 원인을 빨리 찾습니다.

처방

1. 설정을 저장소에 두고 코드처럼 리뷰하세요. 변경이 커밋으로 남는 게 가장 큰 이득입니다.
2. 실시간으로 바꿔야 하는 값은 별도 시스템에 두되 이력과 검토를 남기세요.
3. 단계적으로 반영하세요. 일부에 먼저 적용하고 관찰하세요.
4. 값의 허용 범위를 코드에서 검증하세요. 단위 혼동이 실전 사고의 큰 축입니다.
5. 위험한 설정과 안전한 설정을 구분하고 절차를 다르게 하세요.
6. 설정 변경을 배포 이력과 같은 곳에 기록하세요. 장애 조사에서 한 화면에 보여야 합니다.
7. 이전 값을 항상 남기세요. 되돌릴 수 있어야 합니다.
8. 장애 조사 절차의 첫 질문을 "직전에 무엇이 바뀌었나"로 만드세요. 코드만이 아니라 설정도요.
9. 저장소 밖에 남은 설정을 세어 보세요. 환경 변수·클라우드 콘솔·LB 규칙·DNS·DB 파라미터도 전부 설정입니다.
10. 설정 시스템이 죽었을 때 쓸 안전한 기본값을 코드에 두세요. 안 정해 두면 그 순간 예상 못 한 동작을 합니다.

지금 확인해 보세요

설정이 코드만큼 관리되는가:

· 변경 이력이 있는가
✓ 누가 · 언제 · 무엇을 · 어떤 값에서 어떤 값으로 · 왜
✕ 없으면 장애 조사에서 설정은 후보에도 못 오른다

· 저장소 밖에 남은 설정을 세어 본다
✓ 환경 변수 · 클라우드 콘솔 · LB 규칙 · DNS
✓ 방화벽 · DB 파라미터

· 값 검증이 있는가
✕ timeout=30 이 초인지 밀리초인지 코드가 아는가

· 설정 시스템이 죽었을 때의 기본값
✕ 정해 두지 않으면 그 순간 예상 못 한 동작을 한다

· 배포 이력과 설정 이력이 한 화면에 보이는가
✓ 장애 조사 첫 질문은 '직전에 무엇이 바뀌었나' 다

핵심 한 줄설정은 코드보다 쉽게 바뀌는데 영향은 같거나 더 크다.