대응 비용
5분이면 끝나는 대응이라도 월 20회면 상당한 시간입니다. 야간이면 다음 날 생산성까지 깎입니다.
이 파트에서 다루는 내용
세 번 나면 상태임시 조치 대장우선순위왜 안 고쳐지나못 고칠 때
01
같은 장애가 세 번 나면 사고가 아니라 상태입니다
한 번은 사고입니다. 두 번은 우연일 수도 있습니다. 세 번째부터는 그게 이 시스템의 정상 동작이라고 봐야 합니다.
문제는 반복될수록 대응이 익숙해진다는 것입니다. 재기동하면 된다는 것을 알고 있으니 5분이면 끝납니다. 그래서 아무도 근본 원인을 보지 않게 됩니다.
이 상태가 이어지면 두 가지가 쌓입니다. 임시 조치와 대응하는 사람의 소모입니다. 둘 다 눈에 잘 안 보이지만 실제 비용입니다.
신뢰 손실
사용자는 횟수를 기억합니다. "또 그러네"가 나오기 시작하면 시스템 전체에 대한 평가가 바뀝니다.
익숙함의 함정
빨리 복구할수록 근본 원인을 볼 동기가 줄어듭니다. 대응이 능숙해지는 것이 오히려 문제를 고착시킵니다.
02
임시 조치 대장을 만듭니다
Part 2에서 임시 조치에 재검토 기한과 복원 방법을 함께 남기라고 했습니다. 그 기록들을 한곳에 모으면 그것이 이 시스템의 운영 부채 목록이 됩니다.
협업·성장 코스의 기술 부채는 코드 품질에서 나온 부채를 다룹니다. 여기서 다루는 것은 장애 이력에서 나온 부채입니다. 성격이 다릅니다. 코드는 멀쩡한데 설정과 우회 조치로 버티고 있는 상태입니다.
- 여러 임시 조치가 같은 원인을 가리키면 그것이 최우선 과제입니다. 하나를 고치면 여러 개가 정리됩니다.
- 기한이 지난 항목은 재검토하거나 기한을 다시 잡습니다. 방치하면 대장 자체가 형식이 됩니다.
- 되돌리는 방법이 적혀 있지 않은 항목은 지금 채웁니다. 나중에는 아무도 기억 못 합니다.
- 이 대장을 팀 회의나 분기 점검에 올립니다. 혼자 보면 우선순위를 못 얻습니다.
임시 조치 대장text
[임시 조치 대장 · 2026-07 기준]
번호 조치 내용 적용일 재검토 기한 상태
------------------------------------------------------------------
T-01 WAS 힙 4GB → 8GB 상향 2026-03-12 2026-03-26 기한 초과
원인 미규명 상태의 OOM 대응. 누수 여부 확인 필요.
되돌리기: setenv.sh -Xmx 4g 복원 후 재기동
T-02 매일 04:00 WAS 자동 재기동 2026-04-02 2026-04-16 기한 초과
메모리 증가로 인한 야간 장애 회피. T-01과 동일 원인 추정.
되돌리기: crontab 항목 제거
T-03 결제 연동 재시도 5회 → 1회 2026-06-20 2026-07-04 기한 초과
상대 시스템 지연 시 스레드 고갈 회피. 근본 대응은 타임아웃 설정.
되돌리기: PaymentClient 재시도 설정 복원
T-04 주문 목록 조회 건수 100 제한 2026-07-15 2026-08-15 기한 내
대량 조회 OOM 회피. 페이징 적용이 근본 대응.
되돌리기: OrderController 상수 복원이 표를 만들면 대개 놀랍니다. 기한이 지난 항목이 대부분이고, 여러 항목이 같은 근본 원인을 가리키는 경우가 많습니다. 위 예시에서 T-01과 T-02는 사실 하나의 메모리 누수 문제입니다.
03
무엇부터 고칠지 정합니다
반복 장애가 여럿이면 전부 고칠 수는 없습니다. 순서를 정해야 하는데, 기준이 없으면 가장 최근에 시끄러웠던 것부터 하게 됩니다. 그건 좋은 기준이 아닙니다.
빈도
월 몇 회 발생하는가. 드물어도 영향이 크면 우선순위가 올라갑니다.
영향
몇 명이 얼마 동안 못 쓰는가. Part 9에서 수치로 적어 두라고 한 것이 여기서 쓰입니다.
대응 비용
한 번 대응에 사람 시간이 얼마나 드는가. 야간이면 가중치를 더 줍니다. 이걸 빼면 자주 나는 소규모 장애가 계속 밀립니다.
고치는 비용
근본 해결에 드는 공수입니다. 작은 노력으로 큰 반복을 없앨 수 있는 것이 1순위입니다.
자주 밀리는 유형
"자주 나지만 5분이면 끝나는" 장애가 가장 자주 밀립니다. 개별로 보면 사소하기 때문입니다. 하지만 월 20회면 그 시간이 상당하고, 무엇보다 담당자가 계속 소모됩니다. 대응 비용을 계산에 넣으면 이런 항목의 순위가 제대로 올라갑니다.
04
왜 알면서도 안 고쳐지는가
원인을 알고 해결책도 아는데 몇 달째 그대로인 경우가 있습니다. 게으름이 아니라 구조적인 이유가 있습니다. 그 이유를 짚어야 실제로 움직입니다.
- 장애 대응에 쓰는 시간을 측정해 드러냅니다. "이 장애로 지난 분기에 32시간을 썼습니다"는 문장이 일정 확보의 근거가 됩니다.
- 재발 방지 과제를 개발 일감과 같은 목록에 올립니다. 별도 목록에 있으면 우선순위 경쟁에서 항상 집니다.
- 담당이 애매한 문제는 조율할 사람을 명시적으로 지정합니다. 협업·성장 코스의 시니어·PL 트랙에서 다루는 역할입니다.
- 큰 해결이 부담되면 쪼갭니다. 완전한 해결이 아니어도 빈도를 절반으로 줄이는 조치부터 합니다.
복구가 급해서
장애 때는 복구가 최우선이라 근본 원인까지 갈 시간이 없습니다. 복구되면 다시 평상 업무로 돌아갑니다.
일정에 없어서
근본 해결은 대개 며칠 이상 걸리는데 그 시간이 일정에 잡혀 있지 않습니다. 기능 개발 일정만 있으면 영원히 밀립니다.
담당이 애매해서
인프라와 애플리케이션 경계에 있는 문제, 외부 연동 문제가 특히 그렇습니다. 아무도 자기 일이라고 생각하지 않습니다.
위험해 보여서
돌아가고 있는 것을 건드리는 부담입니다. 특히 원인이 오래된 코드에 있으면 손대기를 꺼립니다.
05
고칠 수 없는 것도 있습니다
근본 원인이 우리 통제 밖에 있는 경우가 있습니다. 외부 시스템의 구조적 문제이거나, 고객사가 교체를 거부하는 레거시이거나, 재작성 규모가 현실적으로 불가능한 경우입니다.
이때 근본 해결만 답이라고 고집하면 아무 진전 없이 계속 당하게 됩니다. 방향을 바꿔 대응 비용을 낮추는 것도 정당한 선택입니다.
자동 복구
감지되면 자동으로 조치하게 만듭니다. 사람이 새벽에 깨는 일이 없어지는 것만으로 큰 개선입니다.
조기 감지
Part 10의 방법으로 더 빨리 알아챕니다. 못 막아도 영향 시간은 줄어듭니다.
영향 격리
외부 연동 장애가 전체로 번지지 않게 막습니다. Part 9의 예시처럼 타임아웃과 기능 축소 동작이 여기 해당합니다.
대응 절차 문서화
누가 대응해도 같은 속도로 처리되게 합니다. 특정 사람만 아는 상태가 가장 위험합니다.
기록해 두기
고치지 않기로 한 것도 결정입니다. 왜 그렇게 판단했는지 남깁니다. 상황이 바뀌면 다시 볼 수 있어야 합니다.
코스 마무리
여기까지가 장애 대응 코스입니다. 연락을 받고 영향을 파악하고, 증거를 남기며 복구하고, 증상으로 후보를 좁히고, 로그와 덤프로 원인을 찾고, 보고서를 남기고, 다음을 대비하는 흐름이었습니다. 관통하는 원칙이 하나 있습니다. 장애 상황에서 할 수 있는 일의 대부분은 평상시에 준비해 둔 것뿐이라는 점입니다. 요청 식별자, 증거 수집 스크립트, 한계값 표, 임시 조치 대장. 이 코스를 읽고 하나라도 만들어 두면 다음 장애의 대응 시간이 실제로 줄어듭니다.
체크