프롬 메시지 웹 버전은 안나오나요?

들어가며

“웹 하나로 모든 플랫폼을 커버할 수 있다면?” 많은 팀이 한 번쯤 품어본 생각이실 겁니다. 저희 팀도 마찬가지였습니다. Kotlin과 Swift로 각각 개발된 네이티브 채팅 앱을 웹 버전으로 출시하고, 기존 앱에는 웹뷰를 씌우면 개발 리소스를 절반으로 줄일 수 있지 않을까 하는 기대로 PoC를 시작했습니다.

결론부터 말씀드리면, 프롬 메시지의 웹 전환을 진행하지 않기로 했습니다.

흥미로운 점은, PoC를 시작하기 전에는 “성능이 가장 큰 걸림돌이 되지 않을까”라고 예상했다는 것입니다. 웹뷰 위에서 채팅 서비스를 돌리면 네이티브 대비 체감될 만큼 느리지 않을까 우려했는데, 막상 테스트를 진행해 보니 일반적인 사용 흐름에서의 반응성은 예상보다 준수했습니다. 메시지 송수신, 단건 렌더링 등 기본적인 동작은 네이티브와 비교해도 실사용에 지장이 없는 수준이었습니다. 다만, 대량의 메시지를 빠르게 탐색하는 상황에서는 웹 플랫폼의 렌더링 한계가 드러났고, 이는 뒤에서 다룰 스크롤 가상화 문제와 직결됩니다. 그리고 성능 외에도 예상치 못한 곳에서 문제들이 나타났습니다.

이 글에서는 PoC 과정에서 마주친 문제들과 각각에 대해 검토한 해결 방안, 그리고 최종적으로 진행하지 않기로 결정한 이유를 공유하겠습니다.

---

1. 백그라운드 방치 시 메시지 손실

현상

앱을 열어둔 채로 약 30분간 백그라운드 상태를 유지한 뒤 복귀하는 테스트를 진행했습니다. Android와 iOS 모두 브라우저(웹뷰) 자체가 종료되지는 않았습니다. 문제는 그 이후였습니다.

백그라운드로 내려간 시점에 채팅 서버와의 네트워크 연결이 끊기는 경우가 있었고, 웹뷰로 복귀한 뒤 재연결이 완료되기까지의 사이에 수신되어야 할 메시지가 유실되었습니다.

핵심 난제

메시지 손실이 정확히 언제부터 발생했는지 클라이언트 입장에서 알 수 없다는 점이 가장 큰 문제였습니다. 연결이 끊긴 시점을 정확히 특정하기 어렵기 때문에, 복구 전략은 “마지막으로 확인된 메시지 이후의 모든 메시지를 서버에서 다시 가져오는” 방식이 될 수밖에 없었습니다.

네이티브 앱에서는 OS 레벨의 백그라운드 처리(Background Fetch, FCM/APNs 등)를 활용하여 연결 유지 또는 빠른 복구가 가능하지만, 웹뷰 환경에서는 이러한 메커니즘을 직접 활용할 수 없다는 근본적인 한계가 있었습니다.

어느 방식이든 “연결이 끊긴 동안의 메시지를 사후에 복구한다”는 접근이기 때문에, 네이티브처럼 백그라운드에서도 연결을 유지하는 것과는 근본적인 차이가 있고 구현 방식에 따라 데이터가 오염될 여지가 있었습니다.

메시지 손실 대응 프로세스

---

2. iOS 키보드와 웹뷰 영역 충돌

현상

iOS에서만 발생한 이슈입니다. 채팅 입력을 위해 키보드가 올라오면, 키보드 높이만큼 웹뷰 영역 전체가 위로 밀려 올라가면서 상단 콘텐츠가 화면 밖으로 사라지는 현상이 발생했습니다.

네이티브 앱에서는 키보드 이벤트를 직접 구독하여 레이아웃을 정밀하게 제어할 수 있지만, 웹뷰에서는 브라우저가 키보드 처리를 자체적으로 수행하기 때문에 제어가 까다롭습니다.

검토한 해결 방안

Native Bridge를 통해 키보드의 높이값을 웹뷰로 전달받아 CSS 또는 JavaScript에서 뷰포트 높이를 재계산하는 방식을 검토했습니다. 이론적으로는 해결 가능하지만, 키보드 등장/퇴장 애니메이션과 웹뷰의 리사이즈 타이밍을 정확히 동기화하는 것이 쉽지 않을 것으로 예상되었습니다.

---

3. 중복 로그인 문제

현상

기존에는 네이티브 앱에서만 로그인이 가능했기에 중복 로그인 자체가 구조적으로 불가능했습니다. 웹 버전이 추가되면 동일 계정으로 앱과 웹에 동시 접근이 가능해지면서 두 가지 문제가 발생했습니다.

첫째, 전송 횟수 제한 우회입니다. MQTT를 통한 메시지 전송 시 클라이언트 단위로 걸려 있던 최대 전송 횟수 제한을, 두 클라이언트가 각각 소진하여 사실상 제한을 초과할 수 있었습니다. 이 부분은 백엔드에서 유저 단위로 제한을 거는 방식으로 해결 가능했습니다.

둘째, MQTT clientId 충돌입니다. 동일한 clientId로 두 곳에서 MQTT 연결을 시도하면, 서로 연결을 빼앗기 위한 경쟁(connection flapping)이 발생하여 메시지가 어느 쪽으로 전달될지 예측할 수 없었습니다. 유저별로 서로 다른 clientId를 부여하는 방식을 검토했으나, 기존 메시징 로직 전반에 미치는 영향을 확인하기 위한 추가 검토가 필요했습니다.

검토한 해결 방안

방안	설명	한계
세션 기반 clientId 분리	userId + deviceType 조합으로 clientId를 생성하여 앱과 웹이 서로 다른 MQTT 세션을 유지	기존에 “하나의 유저 = 하나의 clientId”를 전제로 설계된 메시징 로직 전반을 검토해야 하며, 메시지 라우팅, 읽음 처리, 상태 동기화 등에 영향 범위가 넓음
후순위 세션 강제 종료	새로운 접속이 발생하면 기존 세션을 끊는 방식으로 동시 접속 자체를 차단	사용자 경험 측면에서 불편하며, 웹 버전을 출시하는 의미가 반감됨

전송 횟수 제한은 비교적 간단히 해결할 수 있었지만, clientId 충돌 문제는 기존 아키텍처에 미치는 영향이 커서 단순한 수정으로는 해소하기 어려웠습니다.

서비스 운영 관점

기술적 이슈 외에도, 웹 버전 출시로 접근 경로가 다양해지면서 동일 계정의 동시 접속을 어떻게 관리할 것인가라는 서비스 정책 차원의 고민이 추가로 필요했습니다. 기존에는 앱이라는 단일 채널만 존재했기에 고려하지 않아도 되었던 부분이, 웹이라는 채널이 열리는 순간 세션 관리 정책, 이용 약관, 과금 구조 등 여러 영역에 영향을 미치게 됩니다.

---

4. 클라이언트 캐시의 불안정성

현상

네이티브 앱에서는 SQLite 등 기기의 로컬 DB에 데이터를 캐싱하여 앱 재시작 시에도 즉각적인 UI 렌더링이 가능했습니다. 반면 웹뷰 환경에서 사용할 수 있는 브라우저 저장소(IndexedDB, LocalStorage 등)는 OS에 의해 언제든 데이터가 삭제될 수 있습니다. 특히 iOS Safari의 WebView에서는 저장소 관리 정책이 엄격하여 이 문제가 더욱 두드러졌습니다.

검토한 해결 방안

방안	장점	단점
모든 데이터를 API로 전달	캐시 의존성 제거	초기 로딩 속도 대폭 하락, 검색/번역 등 기존 오프라인 기능이 전부 API 호출로 전환 필요
네이티브 캐시 + Bridge 전달	기존 캐싱 로직 유지 가능	Bridge 전송 용량 제한에 걸릴 수 있음

어느 쪽이든 네이티브 대비 사용자 경험의 저하가 불가피했습니다.

---

5. 스크롤 가상화의 한계 — 가장 결정적인 이유

채팅 서비스의 핵심 UX 중 하나는 대량의 메시지 목록을 자연스럽게 스크롤하는 것입니다. 수천, 수만 건의 메시지를 모두 DOM에 올릴 수 없으므로 가상화(virtualization)는 필수적이었습니다. 그런데 이 가상화가 웹 환경에서 채팅 UX와 근본적으로 충돌했습니다.

가상화 미적용 시

빠르게 스크롤하면 렌더링이 스크롤 속도를 따라잡지 못해 빈 화면이 그대로 노출되었습니다.

가상화 미적용 — 빠른 스크롤 시 빈 화면 노출

가상화 적용 — 실시간 높이 계산

각 메시지 아이템의 높이를 스크롤 도중에 실시간으로 계산하도록 구현했습니다. 그러나 높이 재계산이 일어날 때마다 스크롤 위치가 보정되면서, 스크롤이 지속적으로 끊기는 현상(jank)이 발생했습니다.

가상화 적용 — 스크롤 종료 시점 높이 계산

스크롤이 완전히 멈춘 후에 높이를 계산하도록 변경하자 스크롤 자체는 자연스러워졌습니다. 하지만 스크롤 도중에는 추정치 기반으로 레이아웃이 잡히기 때문에, 메시지가 서로 겹치거나 비정상적으로 큰 공백이 발생하는 현상이 나타났습니다.

스크롤 종료 시점 높이 계산 — 메시지 겹침 및 공백 현상

왜 네이티브에서는 문제가 없을까

네이티브의 LazyColumn(Android)이나 UICollectionView(iOS)는 OS 레벨의 렌더링 파이프라인과 긴밀하게 통합되어 있어 스크롤 중에도 매끄러운 아이템 재활용이 가능합니다. 웹의 가상 스크롤 라이브러리들은 DOM 조작과 브라우저 레이아웃 엔진 위에서 이를 흉내 내는 것이기 때문에, 특히 높이가 가변적인 채팅 메시지에서는 네이티브 수준의 스크롤 품질을 달성하기 극히 어렵습니다.

이 문제는 단순히 “최적화를 더 하면 해결되는” 수준이 아니라, 웹 플랫폼의 구조적 한계에 가까웠습니다.

---

결론

이슈	해결 가능성	네이티브 대비 UX 품질
백그라운드 메시지 손실	복구 로직으로 대응 가능	다소 부족
iOS 키보드 레이아웃	Bridge 활용으로 대응 가능	동기화 이슈 잔존, 추가 검토 필요
중복 로그인	백엔드 + 클라이언트 추가 개발 필요	서비스 정책 재설계 필요
클라이언트 캐시	대안 존재하나 트레이드오프 큼	확연히 부족
스크롤 가상화	구조적 한계	격차가 큼

개별 이슈는 각각 우회 방법이 있었지만, 이를 모두 합산했을 때 네이티브 대비 사용자 경험의 격차가 허용 가능한 수준을 넘어선다고 판단했습니다. 특히 스크롤 가상화 문제는 채팅 서비스의 핵심 경험을 직접적으로 훼손하는 것이었기에, 이를 감수하면서까지 웹 전환을 추진할 근거가 부족했습니다.

채팅처럼 실시간성과 대량 데이터 렌더링이 동시에 요구되는 서비스에서는, “하나의 코드베이스로 모든 플랫폼을 커버한다”는 이상이 현실의 벽에 부딪힐 수 있습니다. 물론 웹 기술은 빠르게 발전하고 있고, 미래에는 이야기가 달라질 수 있습니다. 하지만 지금 이 시점에서, 이 서비스에는 네이티브를 유지하는 것이 맞다는 결론을 내렸습니다.

만약 PoC 없이 본 개발에 착수했다면 어떻게 되었을까요. 웹뷰 전환이라는 방향을 확정하고, 설계를 마치고, 상당 부분 구현이 진행된 뒤에야 스크롤 품질이나 백그라운드 메시지 손실 같은 문제를 마주했을 것입니다. 그 시점에서는 이미 투입된 리소스가 크기 때문에 “여기서 멈추자”라는 판단을 내리기가 훨씬 어려워집니다. 문제를 알면서도 타협하며 끌고 가거나, 그동안의 작업을 전부 폐기해야 하는 상황 — 어느 쪽이든 팀에게는 큰 부담이 됩니다.

PoC는 실패가 아닙니다. 적은 비용으로 “하지 않아야 할 것”을 확인하는 것, 그것 자체가 의사결정입니다.

---

감사의 말

이번 PoC는 웹 팀 혼자서는 진행할 수 없었습니다. 백그라운드 동작 테스트, 키보드 이슈 재현, Native Bridge 연동 검토 등 거의 모든 과정에서 Android와 iOS 개발자분들이 적극적으로 함께해 주셨습니다. 네이티브 환경의 동작 원리를 설명해 주시고, 웹뷰 위에서 발생하는 이슈를 같이 디버깅하며, 때로는 직접 테스트 빌드를 만들어 주시기도 했습니다. 덕분에 짧은 기간 안에 의미 있는 검증 결과를 얻을 수 있었습니다. 이 자리를 빌려 감사드립니다.