현대의 프론트엔드 애플리케이션은 기본적인 데이터 불러오기 외에도 매우 많은 부분을 클라우드 서비스에 의존한다. 인증, 검색, 파일 업로드, 기능 플래그, 알림, 분석은 보이지 않는 곳에서 실행되는 API와 관리형 서비스에 의존하는 경우가 많다. 이로 인해 프론트엔드 팀이 인프라를 직접 소유하지 않은 경우에도 프론트엔드의 신뢰성은 클라우드의 신뢰성과 밀접하게 연결된다.

프론트엔드 엔지니어에게는 이 부분에서 사고방식의 대대적인 전환이 필요하다. 장애라고 하면 흔히 전체 사이트가 다운되는 완전한 서비스 중단으로 생각하지만, 실제로 대부분의 사용자가 경험하는 장애는 그렇지 않다. 대개는 인터페이스가 부분적으로 작동하지 않는 수준이다. 즉, 대시보드는 로드되지만 패널 하나가 빈 상태이거나, 양식은 저장되지만 확인 메시지가 표시되지 않거나, 페이지의 나머지 부분은 계속 정상으로 보이지만 파일 업로드가 작동하지 않는 경우 등이다.

이런 이유로 필자는 일상적인 엔지니어링 논의에서 프론트엔드 회복탄력성에 더 관심을 기울여야 한다고 생각한다. 목표는 모든 클라우드 문제를 방지하는 것이 아니다. 그건 현실적이지도 않다. 더 현실적인 목표는 클라우드 서비스나 기타 종속성에 문제가 발생하더라도 계속 사용 가능한 상태를 유지하는 인터페이스를 구축하는 것이다. 여기서 주요 클라우드 플랫폼의 신뢰성 가이드가 유용하다. 이런 가이드에서 규정하는 신뢰성을 위해서는 이상적인 조건에서 가용성을 유지하는 데 그치지 않고, 장기간에 걸쳐 워크로드가 올바르게 실행되고 장애에서 복구하는 능력도 갖춰야 하기 때문이다. 이와 같은 신뢰성 설계 원칙은 프론트엔드 관련 의사결정을 위한 정보를 제공할 수 있는 더 폭넓은 클라우드 관점을 제공한다.

클라우드 장애가 프론트엔드 엔지니어에게 중요한 이유

클라우드 플랫폼은 확장성과 가용성을 중심으로 설계되지만 여전히 많은 부분을 유동적인 요소에 의존한다. 일시적인 네트워크 불안정, 느린 다운스트림 서비스, 만료된 자격 증명, 속도 제한 또는 단기적인 인프라 문제로 인해 요청이 실패할 수 있다. 기본 API의 문제가 아닌 경우도 종종 있다. 사용자가 직접 볼 수 없는 스토리지, ID, 메시징 또는 기타 지원 서비스의 문제일 수도 있다.

프론트엔드 관점에서 새겨야 할 중요한 사실은 많은 경우 장애는 절대적인 것이 아니라 부분적이라는 점이다. 추천 기능에 장애가 발생해도 제품 목록은 올바르게 로드될 수 있다. 사용자 기본 설정이 작동하지 않더라도 로그인은 작동할 수 있다. 검색 결과는 반환되지만 분석 이벤트는 누락될 수 있다. 모든 종속성이 다 함께 성공하거나 실패한다고 전제하면 응답 하나가 잘못됐다는 이유로 빈 화면을 표시하는, 취약한 인터페이스를 만들게 된다.

회복탄력성이 있는 프론트엔드 시스템은 많은 경우 다음과 같은 단순한 질문에서 시작된다. ‘하나의 종속성을 사용할 수 없게 될 때 이 화면의 사용 가능한 최소한의 버전은 무엇인가?’ 로딩 상태, 구성요소 경계, 복구 동작을 설계하는 방법이 이 질문에 의해 좌우된다. 또한 프론트엔드는 완벽한 데모가 아닌 현실의 운영 조건에 맞춰 설계되므로 프론트엔드와 백엔드 팀 간의 더 솔직한 관계도 필요하다.

실제 제품에서 부분 장애를 매끄럽게 처리하는 설계

프론트엔드 시스템에서 실용적인 신뢰성 습관 중 하나는 핵심 기능과 비핵심 기능을 분리하는 것이다. 핵심 기능은 사용자가 주 작업을 완료하는 데 필요한 부분이다. 비핵심 기능은 풍부함, 맥락 또는 편의성을 더해주지만 단기간 그 기능이 없어도 제품이 제공하는 가치에는 지장이 없는 요소들이다. 계정 페이지라면 프로필 정보와 보안 설정은 핵심적인 기능일 것이다. 반면 최근 활동 패널이나 개인화된 추천은 유용하겠지만 그 순간에 필수적인 요소는 아니다.

이렇게 구분하면 어느 곳에 더 강력한 폴백 동작을 투자할지 결정하는 데 도움이 된다. 비핵심 기능에 장애가 발생하면 인터페이스는 해당 섹션을 숨기거나 캐시된 데이터를 보여주거나 더 간단한 기본 상태로 대체할 수 있다. 핵심 기능이 실패하면 사용자에게 훨씬 더 명확한 복구 경로가 필요하다. 저장되지 않은 입력을 보존하거나 가시적인 재시도 동작을 제공하거나 UI를 불확실한 상태로 두는 대신 서버에서 확인된 상태로 되돌리는 등의 작업이 여기에 해당된다.

재시도는 이 그림의 한 부분이지만 신중하게 사용해야 한다. 일반적인 클라우드 신뢰성 가이드는 공격적인 요청 반복보다는 통제된 재시도, 지수 백오프 및 지터를 강조한다. 이는 프론트엔드 측면에서 필자의 경험과도 일치한다. 짧은 지연 후 읽기 요청을 재시도하면 일시적인 장애를 매끄럽게 처리할 수 있다. 쓰기 작업을 안전장치 없이 재시도하면 중복 제출, 상태 충돌 또는 사용자 혼란을 초래할 수 있다. 프론트엔드는 재시도를 반사적인 동작이 아닌 의도를 기반으로 한 복구 툴로 다뤄야 한다.

사용자 경험도 재시도 정책 못지않게 중요하다. 애플리케이션이 백그라운드에서 복구를 시도하고 있다면 인터페이스에서 이를 알려야 한다. 끝없이 돌아가는 대기 아이콘이 사용자를 안심시키는 경우는 거의 없다. “최근 활동을 불러오는 중” 또는 “요청을 재시도하는 중”과 같은 명확한 메시지는 사용자가 체감하는 시스템의 투명성을 높여준다. 또한 이런 메시지를 표시하면 사용자는 동작이 멈췄다고 성급히 결론을 내리지 않고 좀더 기다릴 수 있다.

부분 렌더링이 효과를 발휘하는 부분이기도 하다. 인터페이스는 장애를 확산하는 것이 아니라 격리할 때 더 높은 회복탄력성을 갖는 경우가 많다. 위젯 하나가 실패해도 대시보드의 나머지 부분은 정상적으로 렌더링해야 하며 하나의 보조 API를 사용할 수 없는 경우에도 페이지에 주요 콘텐츠를 로드해야 한다. 회복탄력성을 갖춘 프론트엔드는 백엔드 종속성 중 일부가 실패하더라도 유용한 내용을 표시해야 한다. 많은 경우 이 설계 선택이 개별적인 복구 전술보다 더 중요하다.

실제 환경에서 회복탄력적인 장애 상태

효과적인 장애 처리는 기술만으로 되는 것이 아니다. 의사소통 역시 중요하다. 사용자는 문제에 직면한 경우 무엇이 실패했는지, 무엇이 여전히 작동하는지, 그리고 다음 단계로 무엇을 할 수 있는지 알아야 한다. “문제가 발생했습니다”와 같은 보편적인 메시지는 대개 이 3가지 부분에서 모두 실패한다. 이 메시지는 모호하며, 사용자의 조바심을 누그러뜨리지 못하고 복구를 지원하지도 않는다.

좋은 메시지는 너무 기술적이지 않으면서 구체적인 메시지다. 예를 들어 “지금은 최근 활동을 불러올 수 없습니다. 계정 세부 정보는 여전히 볼 수 있습니다. 몇 분 후에 다시 시도하십시오” 같은 메시지다. 이와 같은 메시지는 제품 전체에 장애가 발생한 것은 아니라는 점을 알려 사용자를 안심시키고 실용적인 다음 단계를 제시한다. 또한 이 메시지는 ‘장애는 통제, 설명, 복구 가능해야 한다’는 더 성숙한 제품 사고방식을 반영하기도 한다.

이 요소의 중요성이 큰 분야 중 하나는 입력 양식이 많은 워크플로우다. 입력 양식 제출이 실패하면서 입력한 모든 내용이 손실되면 프론트엔드 시스템에 대한 사용자 신뢰는 빠르게 약화된다. 사용자 입력 보존은 핵심 흐름의 기준선이 되어야 한다. 기초적인 브라우저 기능과 웹 API도 더 나은 장애 처리를 지원할 수 있다. 예를 들어 Fetch API와 AbortController는 요청 수명 주기를 관리하고 오래된 요청을 취소하고 인터페이스가 오래된 로딩 상태에 갇히는 문제를 피할 수 있게 해주는 더 깔끔한 방법을 프론트엔드 팀에 제공한다. 구현상의 소소한 부분이지만, 비정상적인 상황에서 사용자가 제품에 대해 신뢰성을 느끼는지 여부를 좌우하는 경우가 많다.

폴백 데이터에도 동일한 원칙이 적용된다. 경우에 따라서는 캐시된 정보 또는 마지막으로 알려진 정보를 보여주는 것이 아무것도 보여주지 않는 것보다 더 도움이 되기도 하고, 종속성이 복구될 때까지 필수적이지 않은 섹션을 숨기는 것이 더 나은 경우도 있다. 즉, 모든 경우에 통하는 하나의 보편적인 패턴은 없다. 중요한 것은 사용자의 의도에 맞는 장애 상태를 선택하는 것이다. 사용자가 작업을 완료하려고 시도한다면 작업 완료를 지원하고, 사용자에게 맥락이 필요하다면 신뢰할 수 있는 맥락을 최대한 보존하라.

성숙한 환경이라도 해도 클라우드 장애는 계속 발생할 수밖에 없다. 프론트엔드 엔지니어에게 회복탄력성이란 대대적인 재해 처리보다는 장애 격리, 사용자 작업 보호, 재시도 통제, 콘텐츠 부분 렌더링, 명확한 복구 메시지 등 초기에 내린 소소한 설계 의사결정에 관한 문제다. 이런 의사결정이 적절히 이뤄지면 사용자는 배후에서 무엇이 실패했는지 알 수 없다. 단지 애플리케이션이 비정상적인 상황에서도 사용 가능하고 이해하기 쉬우며 안정적인 동작을 유지했음을 인지할 뿐이다.
dl-itworldkorea@foundryco.com