웹에서 Alert.alert는 빈 함수로, 앱의 모든 확인 버튼이 작동하지 않았습니다.

(dev.to)
Dev.to WebDev개발자 도구
웹에서 Alert.alert는 빈 함수로, 앱의 모든 확인 버튼이 작동하지 않았습니다.

Expo 기반 크로스 플랫폼 앱 개발 중 웹 환경에서 Alert.alert가 아무런 경고 없이 빈 함수로 동작하는 '침묵하는 버그'를 발견하고, 이를 해결하기 위한 커스텀 다이얼로그 구현 및 iOS 모달 계층 관리와 비동기 상태 정합성 유지 전략을 다룹니다.

이 글의 핵심 포인트

  • 1React Native Web의 Alert.alert는 경고나 에러 없이 아무 동작도 하지 않는 빈 함수(no-op)로 구현되어 있음
  • 2iOS의 UIKit 특성상 이미 모달이 떠 있는 상태에서 루트 뷰 컨트롤러를 통해 새로운 모달을 호출하면 호출이 거부됨
  • 3이를 해결하기 위해 각 모달 화면마다 별도의 다이록 호스트를 등록하고 가장 최근의 호스트만 렌더링하는 '호스트 레지스트리' 방식 도입
  • 4await confirm()과 같은 비동기 API 사용 시, 백드롭 클릭, 하드웨어 뒤로가기, 화면 언마운트 등 모든 종료 경로에서 Promise가 반드시 종료(settle)되도록 설계해야 함
  • 5새로운 다이얼로그가 나타나 기존 다이얼로그를 대체(Eviction)할 때도 기존 호출자의 Promise를 해제해야 앱의 상태가 멈추는 것을 방지할 수 있음

이 글에 대한 공공지능 분석

왜 중요한가?

에러 로그나 스택 트레이스조차 남지 않는 '침묵하는 실패(Silent Failure)'는 디버깅을 불가능하게 만들며, 사용자가 버튼을 눌러도 아무런 반응이 없는 상태를 초래해 서비스 신뢰도를 치명적으로 훼손하기 때문입니다.

어떤 배경과 맥락이 있나?

하나의 코드베이스로 iOS, Android, Web을 동시에 지원하는 Expo/React Native 환경에서는 플랫폼별 API 구현 차이로 인해 특정 환경에서만 기능이 마비되는 '플랫폼 불일치' 문제가 발생할 수 있습니다.

업계에 어떤 영향을 주나?

크로스 플랫폼 개발 시 라이브러리의 추상화된 API가 각 플랫폼에서 어떻게 구현되어 있는지(No-op 여부 등)를 이해하는 것이 필수적이며, UI 컴포넌트 설계 시 플랫폼 간 동작의 일관성을 보장하기 위한 추가적인 인프라 구축이 필요함을 시사합니다.

한국 시장의 시사점?

빠른 시장 진입을 위해 크로스 플랫폼 기술을 적극 채택하는 국내 스타트업들은, 코드 재사용성이라는 이점 뒤에 숨겨진 '플랫폼별 동작 불일치' 리스크를 반드시 통합 테스트 단계에서 검증해야 합니다.

이 글에 대한 큐레이터 의견

개발자에게 가장 공포스러운 상황은 에러 로그가 뜨는 것이 아니라, 에러 없이 기능이 작동하지 않는 상태입니다. 이번 사례는 추상화된 라이브러리가 특정 환경에서 경고 없이 빈 함수로 동작할 때, 로그아웃이나 계정 삭제 같은 핵심 기능이 얼마나 쉽게 무력화될 수 있는지를 보여줍니다. 창업자는 기술적 부채가 단순한 성능 저하를 넘어, 사용자가 인지하지 못하는 사이에 서비스의 핵심 로직을 마비시키는 '보이지 않는 버그'로 이어질 수 있음을 경계해야 합니다.

물론, 모든 플랫폼의 동작을 완벽하게 일치시키기 위해 커스텀 다이얼로그와 복잡한 호스트 레지스트리 시스템을 구축하는 것은 개발 비용과 코드 복잡성을 증가시키는 트레이드오프를 수반합니다. 하지만 '작동하지 않는 기능'을 방치하는 것보다는, 시스템의 복잡도를 감수하더라도 예측 가능한 UI 상태와 비동기 흐름을 보장하는 설계가 장기적인 제품의 안정성과 사용자 경험 측면에서 훨씬 가치 있는 투자입니다.

원문 보기 →

관련 뉴스

댓글

아직 댓글이 없습니다. 첫 댓글을 남겨보세요.

관련 토픽Dev.to