장애대응은 복구가 아니라 리허설이다: 브라우저 자동화가 가르치는 실패 설계의 원리

May 11, 2026

6 min read

2 views

68%

멈추지 않는 시스템은 존재하지 않는다

진짜 질문은 이것이다. 시스템이 장애를 겪느냐 마느냐가 아니라, 장애를 어떻게 다루도록 설계했느냐이다. 많은 팀은 “더 안정적으로 만들자”라는 말로 문제를 시작하지만, 실제 운영의 세계에서는 어떤 서비스도 완벽히 멈추지 않는 상태에 도달하지 않는다. 대신 차이가 나는 지점은 하나다. 장애가 왔을 때, 그 시스템이 무너지는가, 아니면 절차적으로 수습되는가.

이 관점은 소프트웨어 운영과 브라우저 자동화를 묘하게 같은 축 위에 올려놓는다. 브라우저 자동화는 웹 서비스를 사람이 아닌 코드가 반복해서 다루는 일이다. 즉, 클릭, 입력, 렌더링, 네트워크 지연, 창 전환 같은 불안정한 행위를 예측 가능한 절차로 바꾸는 작업이다. 장애대응도 본질은 비슷하다. 예외적인 상황을 감정이나 즉흥이 아니라 반복 가능한 시나리오로 바꾸는 일이다.

여기서 중요한 통찰이 생긴다. 좋은 장애대응은 사고 후의 응급처치가 아니라, 평소에 만들어 둔 자동화된 행동의 질에 달려 있다. 브라우저 자동화가 잘된 팀은 UI가 조금 바뀌어도 복구 경로를 설계해 둔다. 장애대응이 잘된 팀은 서비스가 흔들려도 책임과 판단의 경로를 미리 설계해 둔다. 둘 다 “문제가 없게 만드는 기술”이 아니라, 문제가 생겨도 망가지지 않는 기술이다.

장애는 버그가 아니라 인터랙션이다

우리가 흔히 장애를 생각할 때 떠올리는 이미지는 깨진 서버, 죽은 프로세스, 실패한 배포다. 하지만 현장에서 장애는 대개 단일 원인이 아니라 서로 기대고 있는 요소들의 상호작용으로 나타난다. 재시도 로직이 트래픽을 더 키우고, 느린 응답이 타임아웃을 부르고, 타임아웃이 큐를 밀어 올리고, 큐가 다시 장애를 확대한다. 하나의 결함이 아니라 증폭 고리가 생기는 것이다.

브라우저 자동화도 마찬가지다. UI가 바뀌면 단순히 한 줄의 셀렉터가 깨지는 것으로 끝나지 않는다. 자동화 스크립트는 화면 상태, 로딩 타이밍, 포커스, 네트워크 응답, 팝업, 권한 요청 같은 여러 층의 상호작용 위에 서 있다. 즉, 자동화가 실패하는 이유는 종종 코드가 틀려서가 아니라 전제가 깨졌기 때문이다.

이 둘을 함께 보면, 훨씬 중요한 질문이 보인다. 우리는 문제를 “고장난 부품”으로 보고 있는가, 아니면 “깨진 상호작용”으로 보고 있는가. 전자로만 보면 패치와 교체가 최선이다. 후자로 보면 관찰, 격리, 완화, 우회, 재시도가 더 중요해진다. 장애대응의 품질은 이 전환에서 갈린다.

예를 들어보자. 로그인 API가 느려졌다고 하자. 단순한 해결책은 더 빠른 서버를 붙이는 것이다. 하지만 상호작용 관점에서는 다르게 본다. 인증 실패율은 얼마나 오르는가, 재시도는 중복 요청을 만드는가, 클라이언트는 얼마나 기다리는가, 사용자에게는 어떤 대체 경로를 제공할 것인가. 이 질문들은 “서버가 고장났는가”보다 훨씬 운영적이다. 동시에 브라우저 자동화에서도 같은 질문이 통한다. 버튼이 안 눌린다고 코드를 고치는 것만으로는 부족하다. 어떤 상태에서 버튼이 비활성화되는지, 무엇이 UI를 가리는지, 실패 시 어떤 복구 시퀀스를 실행할지까지 설계해야 한다.

장애를 부품의 고장으로만 보면, 우리는 수리한다. 장애를 상호작용의 붕괴로 보면, 우리는 시스템을 다시 춤추게 만든다.

자동화의 진짜 목적은 반복이 아니라 신뢰다

브라우저 자동화는 자칫하면 “사람이 하던 일을 코드로 옮기는 것”처럼 보인다. 하지만 더 깊이 들어가면 목적은 반복 자체가 아니다. 목적은 신뢰할 수 있는 재현성이다. 사람이 하면 자주 놓치는 절차를 정확히 수행하는 것, 환경이 조금 달라져도 의도한 결과를 얻는 것, 실패해도 어디서 왜 실패했는지 남기는 것. 자동화는 결국 행동의 표준화다.

이 점에서 장애대응은 놀랍도록 비슷하다. 장애대응도 누군가의 영웅적 즉흥성을 기대하는 것이 아니라, 반복 가능한 절차와 역할을 준비하는 일이다. 어떤 로그를 먼저 볼지, 누구에게 알릴지, 어떤 기준으로 롤백할지, 언제 외부 공지를 내보낼지. 즉, 혼란을 인간의 재능으로 메우는 것이 아니라 혼란을 견디는 루틴으로 바꾸는 것이다.

여기서 한 단계 더 나아가면, 자동화와 장애대응 모두 사실상 같은 원리를 따른다는 것을 알 수 있다. 둘 다 사람의 인지 부하를 줄이는 기술이다. 사람이 실시간으로 모든 분기를 판단하면 실수한다. 그래서 자동화는 절차를 코드로 옮기고, 장애대응은 판단의 순서를 문서와 플레이북으로 옮긴다. 둘의 차이는 대상이 웹 UI냐, 운영 상황이냐 정도다.

이 관점에서 중요한 질문은 “무엇을 자동화할 것인가”가 아니라, **“무엇을 신뢰 가능한 형태로 바꿀 것인가”**이다. 예를 들어 E2E 테스트 자동화에서 가장 큰 가치는 테스트를 많이 돌리는 데 있지 않다. 복잡한 사용자 여정을 안정적으로 재현해서, 어떤 수정이 어떤 경로를 깨뜨렸는지 드러내는 데 있다. 장애대응 문서도 마찬가지다. 페이지 수가 많은 것이 아니라, 실제로 압박 상황에서 사용 가능한 순서와 판단 기준이 있는가가 핵심이다.

브라우저 자동화가 실패하기 쉬운 이유도 여기에 있다. 많은 팀이 자동화를 “한 번 작성하면 끝”이라고 생각하지만, 자동화는 현실의 변화를 흡수해야 한다. 장애대응도 마찬가지로 “한 번 만들어 두면 끝”이 아니다. 시스템이 성장하고 팀이 바뀌고 의존성이 늘어나면, 대응 절차 역시 계속 갱신되어야 한다. 결국 둘 다 정적 문서가 아니라 살아 있는 운영 능력이다.

가장 강한 시스템은 실패를 숨기지 않고 분해한다

좋은 장애대응을 가르는 기준은, 장애를 없앨 수 있느냐가 아니다. 장애를 어떻게 분해해서 다룰 수 있느냐다. 시스템은 종종 한 번에 무너지지 않는다. 경고가 먼저 오고, 지연이 늘고, 특정 기능만 느려지고, 일부 사용자만 영향을 받고, 마지막에 전체가 흔들린다. 이때 훌륭한 대응은 전체를 한 덩어리로 보지 않고, 분해해서 보고, 분해해서 멈추고, 분해해서 복구한다.

브라우저 자동화도 분해의 기술에 가깝다. 좋은 자동화는 “로그인부터 결제까지 한 번에”를 목표로 하지 않는다. 그보다 먼저, 어떤 단계에서 어떤 상태가 보장되어야 하는지를 명시한다. 예를 들면 로그인 성공 후 쿠키가 저장되었는지, 특정 요소가 보이는지, 네트워크 응답이 예상 범위에 들어왔는지. 이렇게 해야 실패 지점이 선명해지고, 문제가 생겼을 때 원인을 좁힐 수 있다.

운영에서도 같은 원리가 작동한다. 예를 들어 사용자 신고가 폭증했다면, “서비스 전체가 이상하다”는 말보다 “결제 실패인지, 알림 미수신인지, 조회 지연인지”를 분리해야 한다. 그래야 대응도 분해된다. 결제는 우회 경로를 열고, 알림은 재전송 큐를 점검하고, 조회는 캐시를 조정할 수 있다. 분해되지 않은 문제는 대응되지 않는다.

이 지점에서 우리는 더 실용적인 프레임을 만들 수 있다. 장애와 자동화를 모두 관통하는 핵심은 상태 전이 관리다. 시스템이 어떤 상태에 있고, 다음에 어떤 상태로 넘어가며, 실패 시 어디로 되돌아가야 하는지. 브라우저 자동화에서 이 개념은 특히 분명하다. 페이지 로딩 중, 인증 완료, 모달 표시, 권한 요청, 제출 완료 같은 상태를 관리하지 않으면 스크립트는 금방 흔들린다. 장애대응에서도 마찬가지다. 정상, 성능 저하, 부분 장애, 전체 장애, 복구 중 같은 상태를 명확히 정의하지 않으면 팀은 매번 같은 토론을 반복한다.

시스템을 안정적으로 만드는 것은 완벽한 제어가 아니라, 상태 전이를 명확히 보는 눈이다.

리허설된 실패만이 진짜 복구를 만든다

많은 팀이 장애를 “예외 사건”으로 취급한다. 그래서 장애가 터지면 그 순간부터 급히 배운다. 하지만 이 방식은 비용이 크다. 이미 압박이 최대인 순간에 처음 보는 상황을 해석해야 하기 때문이다. 반면 강한 팀은 장애를 일종의 리허설로 바꾼다. 미리 시나리오를 만들고, 경로를 확인하고, 실패했을 때 다음 행동을 정해 둔다. 실패를 연습한 만큼 복구는 빨라진다.

브라우저 자동화의 가치도 바로 여기에 있다. 자동화는 사실 성공을 위한 도구처럼 보이지만, 더 정확히 말하면 실패를 연습하게 만드는 도구다. 어떤 버튼이 어느 조건에서 사라지는지, 어떤 대기 시간이 얼마나 위험한지, 어떤 네트워크 지연이 사용자 경험을 무너뜨리는지 반복해서 드러낸다. 즉, 자동화는 현실의 불안정성을 적나라하게 보여준다. 이 불안정성을 볼 수 있어야 운영도 강해진다.

여기서 조직이 가져야 할 태도는 분명하다. 장애를 부끄러운 사건으로 숨기지 말고, 자동화 실패를 귀찮은 테스트 노이즈로 무시하지 말아야 한다. 둘 다 시스템이 어디까지 준비되었는지를 알려주는 진단 신호다. 어떤 실패는 품질의 문제지만, 어떤 실패는 설계의 문제다. 그리고 설계의 문제는 반복될수록 커진다.

실전에서 유용한 생각법은 이렇다. “이 문제를 한 번 해결할 수 있는가”가 아니라, **“열 번 반복해도 같은 방식으로 해결 가능한가”**를 묻는 것이다. 장애대응 문서가 좋은지, 브라우저 자동화가 좋은지의 차이는 결국 이 질문에 답할 수 있는지에 달려 있다. 우발적 영웅주의는 한 번의 승리를 가져올 수 있다. 하지만 반복 가능한 절차만이 조직의 능력이 된다.

Key Takeaways

장애는 부품 고장이 아니라 상호작용의 붕괴로 보라. 원인을 한 곳에만 두지 말고, 재시도, 타임아웃, 큐, 사용자 행동까지 함께 관찰하라.
자동화의 목적은 반복이 아니라 신뢰다. 단순히 사람 일을 코드로 옮기는 것이 아니라, 실패 가능성이 있는 절차를 재현 가능하게 만드는 데 집중하라.
문제를 한 덩어리로 보지 말고 상태 전이로 분해하라. 정상, 지연, 부분 장애, 복구 중 같은 상태를 명확히 정의하면 대응이 빨라진다.
장애대응은 응급처치가 아니라 리허설이다. 자주 발생하는 실패 시나리오를 미리 연습하고, 다음 행동을 자동화된 절차로 만들어 두라.
좋은 문서는 읽기 쉬운 문서가 아니라 압박 상황에서 실행 가능한 문서다. 누가, 언제, 무엇을, 어떤 순서로 할지 명확해야 한다.

시스템은 완벽해지는 것이 아니라, 실패를 다루는 법을 배운다

우리는 종종 안정성을 “문제가 없는 상태”로 오해한다. 하지만 더 현실적인 정의는 다르다. 안정성은 문제가 생겨도 의미 있는 행동을 잃지 않는 능력이다. 브라우저 자동화는 이 능력을 코드 수준에서 훈련시킨다. 장애대응은 이를 조직 수준에서 훈련시킨다. 둘을 함께 보면 한 가지 결론에 도달한다. 진짜 성숙한 시스템은 실패를 피하는 시스템이 아니라, 실패를 처리하는 방식을 축적한 시스템이다.

이제부터 장애를 보면 “왜 또 터졌지”라고 묻기보다, “이 시스템은 실패를 어떤 절차로 바꾸고 있는가”라고 물어야 한다. 자동화를 보면 “얼마나 많이 돌리나”보다, “얼마나 안정적으로 상태를 재현하나”를 봐야 한다. 그 순간 우리는 기술을 단순한 효율화 도구가 아니라, 불확실성을 다루는 조직의 지능으로 이해하게 된다.

그리고 아마 이 질문이 가장 중요하다. 당신의 시스템은 성공을 얼마나 잘 수행하는가가 아니라, 실패를 얼마나 우아하게 수행하는가. 그 답이 결국 서비스의 품질이자, 팀의 성숙도이며, 다음 장애를 견디는 힘이다.