들어가며:
현재 업무 도중, 지속적으로 처리해야하는 운영 개선을 줄일 수 있는 방법은 없는지 Bro Log를 통해 토론을 진행하게 되었고,
다음과 같은 인사이트를 얻었습니다.
도입부: 운영을 하다 보면 “이 정도면 다 고민했다”고 생각해도 새로운 이슈가 계속 터집니다. 이 글에서는 그 현상을 ‘실패’가 아니라 ‘운영 시스템의 정상’으로 재정의하고, 반복되는 문제를 새 이슈가 아닌 같은 패턴으로 식별하기 위한 기준(지표/분류/RCA)을 정리해봅니다.
운영 개선이 끝나지 않는 건 이상이 아니라 정상입니다
제가 겪은 운영의 현실은 이렇습니다.
- 운영 중에는 새로운 사건이 계속 발생합니다.
- “처음에 고려를 안 한 게 아닌데도” 구조적 개선 과제가 튀어나옵니다.
- 특히 클라우드/매니지드 환경에서는 벤더 정책과 수명주기 변화가 ‘외부 변수’가 아니라 ‘시스템 요구사항’이 됩니다.
여기서 중요한 포인트는, 운영의 목표가 “이슈 제로”가 아니라 이슈를 다루는 비용을 예측 가능하게 만들고, 재발 반경을 줄이는 것이라는 점입니다. 즉, “개선이 끝나지 않는다”는 느낌은 많은 경우 다음 중 하나에서 옵니다.
- 재발(recurrence): 사실은 같은 패턴인데 매번 다른 이슈처럼 처리하고 있음
- 가정 붕괴(assumption break): 초기 설계의 가정이 운영에서 깨지고 있음 (트래픽/조직/정책/제약 변경)
이 둘을 구분하지 못하면, 매번 “새 문제”로 받아들이며 설계를 다시 쓰게 됩니다.
“새 이슈”가 아니라 “같은 패턴”으로 보려면: 먼저 기준부터 정합니다
반복 문제를 패턴으로 묶기 위해 가장 먼저 해야 할 일은 “원인 분석(RCA)을 잘하자”가 아니라, 어떤 축으로 사건을 기록하고 분류할지를 합의하는 것입니다. 저는 아래 3가지를 최소 기준으로 잡는 편이 실무적으로 잘 굴러갔습니다.
1) 지표(Impact) 기준: 횟수보다 “영향도”를 함께 기록합니다
단순히 “3번 발생하면 구조 개선” 같은 룰은 출발점으로 좋지만, 운영에선 횟수만으로는 부족합니다. 같은 1회라도 고객 영향이 크면 즉시 구조 개선이 필요할 수 있기 때문입니다.
- 고객 영향: 에러율, 실패 요청 수, SLO 위반 여부
- 시간 영향: MTTR(복구 시간), 장애 지속 시간
- 비용 영향: 인프라 비용 급증, 운영자 투입 시간(Man-hour)
- 위험도: 데이터 유실 가능성, 보안 사고 가능성, 롤백 불가 여부
추천은 **“횟수 + 영향도”**를 같이 트리거로 두는 것입니다.
- 예: “같은 패턴 3회” 또는 “1회라도 SLO 위반이면 구조 개선”
2) 분류(Taxonomy) 기준: ‘증상’ 말고 ‘깨진 가정’으로 묶습니다
운영에서 반복되는 문제를 “같은 패턴”으로 묶으려면, 장애 증상(예: 502, 노드 부족, 배포 실패)으로만 묶으면 한계가 있습니다. 대신 저는 “무슨 가정이 깨졌는가?”로 분류하는 게 훨씬 강력하다고 느꼈습니다.
예시 분류(운영에서 자주 깨지는 가정들):
- 변경/수명주기 가정: “이 버전은 오래 간다”, “업그레이드는 가끔 한다”
- 환경 유사성 가정: “Dev에서 되면 Prod에서도 된다”
- 용량/부하 가정: “피크 트래픽은 이 정도”
- 의존성 가정: “이 애드온/외부 연동은 안정적”
- 조직/운영 가정: “운영 인력/온콜 역량은 이 수준”
이 방식의 장점은, 겉으로 다른 이슈들이 실제로는 같은 뿌리(가정 붕괴)에서 나온다는 걸 빨리 보게 해준다는 점입니다.
3) RCA 방식: ‘사후 보고서’가 아니라 ‘의사결정 개선 도구’로 씁니다
RCA는 “누가 뭘 잘못했나”를 찾는 문서가 되면 무조건 실패합니다. 운영에서 유효한 RCA는 아래 질문에 답해야 합니다.
- 탐지: 왜 더 빨리 못 봤나? (관측성/알람/런북)
- 완화: 왜 더 빨리 줄이지 못했나? (롤백/트래픽 전환/격리)
- 재발 방지: 같은 유형이 또 오면 무엇이 자동으로 막아주나? (가드레일/정책/자동화)
- 의사결정 개선: 다음엔 어떤 조건이면 A를 택하고, 어떤 조건이면 B를 택할 건가?
즉, RCA의 산출물은 “원인”만이 아니라 다음 선택을 단순하게 만드는 규칙이어야 합니다.
사례: EKS 업그레이드가 “운영 개선이 끝없다”를 체감하게 만든 이유
대화에서 가장 현실적이었던 예시는 EKS 업그레이드였습니다.
- EKS는 업그레이드가 사실상 **정기 작업(예: 1년 1회)**로 들어옵니다.
- In-place 업그레이드는 리스크가 큽니다.
- 그래서 Blue/Green 방식으로 “전환 직전 검증”을 하고 싶어집니다.
- 그런데 “Dev에서 테스트해봤다”가 “Prod에서도 안전하다”로 이어지는지 확신하기 어렵습니다.
여기서 중요한 인사이트는 이겁니다.
- 이 문제는 “처음 설계가 미흡했다”라기보다
**‘AWS 정책/수명주기를 시스템 요구사항으로 편입했는가’**의 문제입니다. - 그리고 “Dev 통과 = Prod 안전”이라는 가정이 깨질 수 있다는 불안은,
단순 테스트 부족이 아니라 환경 간 차이를 어떻게 대표시키느냐의 문제입니다.
Blue/Green이 주는 ‘안심’의 정체
제가 느낀 Blue/Green의 장점은 단순히 안정성이 아니라, 불확실성을 옮기는 것입니다.
- 운영 중 변경(In-place) → 전환 직전 검증(Blue/Green)
- 실패하더라도 롤백 가능성이 높아 **가역성(reversible)**이 커집니다.
다만 Blue/Green도 “안전해 보이는 선택”이지 “무조건 정답”은 아닙니다.
- 비용: 리소스 이중화
- 복잡도: 배포/절체/데이터 호환성
- 새로운 운영부채: 전환 절차가 복잡해지면 또 다른 장애 요인이 됨
결국 “Blue/Green이냐 In-place냐”보다 더 본질적인 질문은,
우리가 무엇을 의사결정의 트리거로 삼고, 어떤 안전장치로 실패를 ‘허용 가능한 비용’으로 만들 것인가입니다.
“어차피 다시 수정될 거면 빨리 실패가 낫지 않나?”에 대한 제 결론
저도 같은 고민을 했습니다. 설계 결정이 계속 뒤집히면, “정성 들여 만들기보다 빨리 실패하고 다시 쓰는 게 낫지 않나?”라는 생각이 듭니다.
하지만 대화하면서 정리된 결론은 조금 달랐습니다.
- 빠른 실패가 유리한 건, 실패 반경이 작고(고객 영향/데이터 손상 제한)
학습이 다음 시도에 즉시 반영될 때입니다. - 설계 결정 중에서도 특히 **비가역(irreversible)**인 축(네트워크/아이덴티티/데이터/계정 구조 등)은
“빨리 실패” 전략이 아니라 초기 가드레일이 더 싸게 먹힐 때가 많습니다.
제가 실제로 뼈저리게 느낀 건, 경험이 부족할수록 비가역 결정을 너무 일찍 크게 고정하게 되고, 그 결과 “수정”이 아니라 “재구축”이 합리적으로 보이는 순간이 온다는 점입니다.
그래서 제 운영 원칙은 이렇게 바뀌었습니다.
- 비가역 축은 보수적으로: 나중에 바꾸기 어려운 결정은 더 많은 근거/제약을 모아 신중히
- 가역 축은 실험적으로: 바꿔도 되는 결정은 빠르게 시도하고, 배움이 남게 시스템화
운영 개선을 “끝내는” 대신 “돌리는” 루프로 바꿔보기
“개선이 끝이 없다”는 감정을 줄이려면, 개선을 프로젝트가 아니라 루프로 정의하는 게 도움이 됩니다.
제가 추천하는 최소 루프는 다음입니다.
- 사건 기록: 영향도(지표) + 분류(깨진 가정) + 조치(완화/재발방지)
- 패턴 식별: 같은 가정이 반복해서 깨지는지 월/분기 단위로 리뷰
- 의사결정 룰 업데이트: “어떤 조건이면 Blue/Green”, “어떤 조건이면 In-place” 같이 트리거를 문서화
- 운영 자산에 투자: 테스트 자동화/관측성/롤백/런북처럼 변경이 와도 가치가 누적되는 영역을 강화
이렇게 하면 “새 이슈”의 숫자가 줄지 않더라도, 체감상으로는 “매번 새로 만드는 느낌”이 확실히 줄어듭니다.
마무리
운영에서 이슈가 계속 생기는 건 피할 수 없지만, 그 이슈를 패턴으로 묶고(분류), 영향도로 우선순위를 정하고(지표), **다음 선택을 단순하게 만드는 규칙(RCA의 산출물)**을 만들면 “끝없는 개선”이 “예측 가능한 개선”으로 바뀝니다. 저도 EKS 업그레이드 같은 경험을 통해, 운영은 문제를 없애는 일이 아니라 문제를 다루는 구조를 만드는 일임을 더 분명히 배우고 있습니다.