영향 범위를 먼저 그린다

한 줄 요약

어떤 변경이든 하기 전에 누가·무엇이 영향을 받는지 종이에 그릴 수 있어야
합니다. 그릴 수 없다면 아직 그 변경을 할 준비가 안 된 것입니다.

왜 이게 필요했나

"설정 한 줄만 바꾸면 됩니다" 로 시작해 서비스가 멎는 일이 반복되는 이유는,
그 한 줄이 무엇에 닿는지 아무도 확인하지 않기 때문입니다. 낯선 시스템에서는
특히 그렇습니다 — 우리에겐 새 시스템이지만 고객에겐 10년 된 시스템이고,
그 사이에 아무도 기록하지 않은 의존이 쌓여 있습니다.

영향 범위를 그리는 네 가지 질문

1. 이 구성 요소를 누가 호출하는가 (상류)
설정 파일 하나를 고칠 때도, 그 프로세스에 요청을 보내는 쪽이 누구인지
알아야 합니다. 접근 로그의 소스 IP 분포, ss -tnp 의 연결 상대, 방화벽
규칙이 단서입니다.

2. 이것이 무엇을 호출하는가 (하류)
바꾼 결과로 하류에 부하가 몰릴 수 있습니다. 타임아웃을 늘리는 변경이
대표적입니다 — 우리는 여유를 줬다고 생각하지만 하류에서는 커넥션이
오래 잡혀 있게 됩니다.

3. 상태를 공유하는가
같은 DB, 같은 파일시스템, 같은 캐시를 쓰는 다른 시스템이 있는지.
공유 상태는 구성도에 잘 안 그려지는데 사고는 여기서 납니다.

4. 언제가 안전한가
배치가 도는 시간, 마감이 걸린 날, 정산일. 기술적으로 안전해도 시점이
틀리면 사고입니다. 이건 반드시 고객에게 물어야 알 수 있습니다.

되돌리기를 먼저 쓴다

변경 계획서의 첫 줄은 변경 내용이 아니라 되돌리는 방법이어야 합니다.

변경:   /etc/app/config.yml 의 pool_size 10 → 30백업:   cp config.yml config.yml.2026-08-20되돌림: cp config.yml.2026-08-20 config.yml && systemctl reload app확인:   curl -s localhost:8080/healthz 가 200, 에러율 5분간 관찰소요:   되돌림 2분

"되돌림: 2분" 이라고 적을 수 있으면 그 변경은 해도 됩니다. 못 적으면
아직입니다.

관찰 창을 정한다

변경 후 언제까지 지켜볼지 미리 정합니다. 5분 보고 자리를 뜨면, 10분 뒤에
터진 문제는 원인 후보에서 빠집니다. 반대로 무한정 붙어 있을 수도 없으니
"30분 관찰, 지표 세 개(에러율·지연·큐 길이)" 처럼 명시합니다.

현장에서 만나는 모습

• 타임아웃을 늘렸더니 하류 DB 커넥션이 고갈 → 하류를 안 봤다.
• 야간에 배포했는데 그 시각에 정산 배치가 돌고 있었다 → 시점을 안 물었다.
• 롤백하려니 원본 설정을 아무도 모른다 → 백업을 안 뜨고 고쳤다.

이어지는 실습에서 할 것

구성도도 위키도 없는 고객사 시스템을 받습니다. 설정 파일 둘, 접근 로그,
로테이션 설정, crontab — 이게 전부입니다.

여기서 상류·하류·공유 상태·배치 창을 직접 캐내고, 되돌리기를 먼저
쓴 변경 계획을 만듭니다. 채점기가 설정을 일부러 바꾼 뒤 여러분의
되돌리기 스크립트를 돌려 원본으로 돌아오는지 확인합니다.