[인터뷰] 금융권 모바일 장애, APM만으로 해결되지 않는 이유

안녕하세요! AI 네이티브 옵저버빌리티 플랫폼, 와탭랩스입니다.

시작하기 전에, 본 글의 용어 사용 원칙 - RUM(Real User Monitoring) 은 실제 사용자가 앱·웹을 이용할 때 발생하는 성능·에러 데이터를 단말 측에서 직접 수집 및 분석하는 모니터링 방식입니다. 본문에서는 동일 개념을 사용자 경험 모니터링, 모바일 모니터링 등으로 혼용하며, 특히 금융권에서 비중이 높은 모바일 영역을 중심으로 다룹니다.

‍

모바일 중심의 전환, 필연적 흐름입니다

한국은행이 발표한 「국내 지급결제 동향」¹에 따르면, 2025년 모바일 기기를 통한 카드 결제 비중은 54.3% 로 실물 카드를 넘어섰습니다. 같은 자료에서 국내 은행의 인터넷뱅킹(모바일뱅킹 포함) 하루 평균 이용 규모는 2,829만 건, 90조 1천억 원으로 집계되었으며, 전년 대비 각각 10.9%, 3.4% 증가했습니다. 이처럼 모바일 중심 전환은 금융 서비스에서 필연적인 흐름으로 볼 수 있습니다.

이 흐름 속에서 모바일 앱 서비스의 안정적 운영은 금융권의 기본 과제가 되었습니다. 다만, 최근 금융권 IT 담당자를 만나보면 동일한 이야기가 반복됩니다. "서버는 정상인데, 고객은 불편하다고 합니다." 시스템 지표와 고객 경험 사이의 이른바 '모니터링 사각지대'가 핵심 과제로 부상한 상황이며, 와탭으로 문의를 주시는 사례 또한 점차 늘고 있습니다.

본 인터뷰에서는 이 사각지대를 진단하기 위해 금융권에서 반드시 확인하는 네 가지를 다룹니다.

• 하이브리드 앱 웹뷰 내부의 자바스크립트 에러와 API 트레이싱
• 상용 난독화·보안 솔루션과 충돌 없는 코드 레벨 데이터 확보
• 구형 단말기·OS 커버리지 (Android 5.0, iOS 11 수준)
• 프론트엔드부터 백엔드 DB까지 APM과 연계되는 단일 타임라인

오늘은 이러한 문제를 현장에서 직접 다뤄온 와탭의 APM/RUM 제품 개발 팀장 고지훈님과 인터뷰를 진행했습니다. 금융권에서 빈번하게 제기되는 질문을 중심으로 구성했으며, 추가로 궁금한 점이 있으시다면 본문 하단의 의견 폼을 통해 자유롭게 남겨주세요.

‍

인터뷰 구성

1. 금융권 사용자 경험 모니터링(RUM) 수요가 급증한 3가지 구조적 원인
2. 금융 환경에서 안정적으로 동작하는가 (하이브리드 앱·난독화·구형 단말기)
3. 거래 단위 추적과 특정 고객 경험 역추적 - RUM이 확보하는 데이터
4. 금융권 RUM 도입 시 반드시 확인할 3가지 체크포인트

‍

1. 금융권 RUM 수요가 급증한 3가지 구조적 원인

‍

Q. 안녕하세요 지훈님, 간단히 본인 소개 부탁드립니다.

안녕하세요. 시중은행, 카드사, 증권사, 이커머스 등 다양한 고객사를 대상으로 모바일·웹 성능 모니터링 도입 프로젝트를 수행해온 와탭의 APM/RUM 제품 개발 팀장 고지훈입니다.

기술 컨설팅부터 PoC까지 전 과정을 직접 주도해왔으며, 금융권 차세대 프로젝트, 보안 심의 대응, 하이브리드 앱 성능 이슈 등 업계 특유의 까다로운 요구사항을 현장에서 깊이 있게 다뤄왔습니다.

‍

Q. 금융권에서 사용자 경험 모니터링(RUM) 수요가 증가하고 있습니다. 구조적인 원인이 있을까요?

제가 이 일을 시작했을 당시만 해도, 금융권에서 모바일 모니터링 이야기를 꺼내면 "있으면 좋지만, 우선순위는 아니다"라는 반응이 대부분이었습니다. 그러나 최근 2~3년 사이 분위기가 빠르게 전환되었으며, 다음 세 가지 구조적 변화가 동시에 작용한 결과로 보입니다.

첫째, 차세대 통합 프로젝트의 영향입니다.

은행 앱 하나에 대출, 카드, 보험, 자산관리까지 모두 들어가는 '슈퍼 앱'이 보편화되면서 앱이 눈에 띄게 무거워졌습니다. 차세대 오픈 직후 '앱이 느려졌다'는 사용자 문의가 급증하는 패턴이 여러 차례 확인되었습니다. 코드 양과 인증 단계가 늘고, 웹뷰가 섞이면서 성능 저하 지점을 특정하기 어려운 구조로 변화한 것입니다.

둘째, 사용자 기대 수준의 변화입니다.

예전에는 앱이 한 번 종료되어도 '그럴 수 있다'는 분위기였습니다. 그러나 지금은 다릅니다. 송금 지연이나 결제 실패 같은 이슈는 즉시 커뮤니티와 SNS를 통해 확산됩니다. 금융사 입장에서는 앱 성능과 안정성이 곧 브랜드 신뢰와 직결되는 구조로 변화했습니다.

셋째, 금융감독 환경의 변화입니다.

2024년 이후 IT 감사 기조가 사후 대응에서 상시 모니터링 및 자율 시정 체계로 강화되는 추세입니다. 이에 따라 장애 발생 시 '어느 단말기, 어느 OS, 어느 버전에서 몇 명이 영향을 받았는지'를 데이터로 제시할 필요가 있습니다. 기존 서버 로그만으로는 이러한 요구에 대응하는 데 제약이 있습니다.

이 세 가지 변화가 맞물리면서 사용자 경험 모니터링(RUM)의 수요가 증가한 것으로 볼 수 있습니다.

‍

Q. 그런데 이미 APM은 많이 도입되어 있습니다. APM으로는 잡히지 않는 영역이 많은 편인가요?

네, 적지 않습니다. 자주 인용하는 예시가 있습니다. 월급날 오전 9시. 서버 대시보드는 정상입니다. CPU 30%, DB 응답 시간은 평소와 동일하고, 에러율도 0.01% 미만입니다. 그런데 고객센터에는 "앱이 안 됩니다", "로그인이 안 됩니다", "화면이 하얗게 떠요"와 같은 문의가 쏟아집니다.

원인은 요청 자체가 서버까지 도달하지 않기 때문입니다.

대표적인 사례는 다음과 같습니다.

• 특정 안드로이드 버전에서 보안 모듈과 OS 패치가 충돌해 스플래시 화면에서 멈추는 경우
• 웹뷰 내부에서 CDN 리소스 로드가 실패하는 경우
• 생체인증 SDK가 특정 기기에서 3초씩 지연되는 경우
• 인증서 갱신 시점에 SSL 핸드셰이크가 실패하는 경우

서버 입장에서는 요청 자체가 들어오지 않기 때문에 로그에도 흔적이 남지 않습니다. 이른바 모니터링 사각지대입니다. 사용자 경험 모니터링(RUM)은 APM을 대체하는 개념이 아니라, APM이 보지 못하는 영역을 보완하는 관계입니다. 양쪽을 함께 운영해야 비로소 전 구간에 대한 가시성이 확보됩니다.

‍

2. 금융 환경에서 안정적으로 동작하는가 (하이브리드 앱·난독화·구형 단말기)

‍

Q. 금융 앱 대부분은 하이브리드 구조입니다. 웹뷰 안에서 발생하는 일은 어떻게 확인하나요?

금융권 담당자께서 가장 자주 하시는 질문 중 하나입니다.

금융 환경의 앱은 네이티브 껍데기 안에 웹뷰가 상당 부분 포함된 구조입니다. 이벤트 페이지, 상품 안내, 약관, 일부 업무 화면은 빠른 변경이 필요해 웹으로 구성되는 경우가 많습니다. 다만, 웹뷰 내부에서 발생하는 자바스크립트 에러는 네이티브 크래시 리포트에 잡히지 않습니다. Firebase Crashlytics를 사용 중인 고객사 중에서도 이 점을 인지하지 못한 사례가 적지 않습니다.

‍

Q. 그렇다면 와탭 RUM은 이 영역을 어떻게 확인하나요?

와탭은 네이티브 영역은 모바일 에이전트가, 웹뷰 내부는 브라우저 에이전트가 각각 측정하고, 동일 세션 ID로 연결되는 방식입니다.

더 나아가 웹뷰에서 발생한 HTTP 요청을 백엔드 APM 트랜잭션과 연결할 수 있습니다. 사용자의 '버튼 클릭 → 웹뷰에서 API 호출 → 서버에서 특정 SQL이 3초 소요'까지 전체 흐름이 하나의 타임라인으로 구성됩니다.

또한 지역, 통신사, 네트워크 타입 기준의 성능 분석도 가능해 '부산 지역 LTE 환경에서 특정 API가 유독 느리다'와 같은 구체적인 인사이트를 도출할 수 있습니다.

이 연결이 확보되는 순간 '프론트 문제인지, 서버 문제인지'를 두고 벌어지던 부서 간 책임 논쟁이 데이터 기반의 논의로 전환됩니다. 금융권 현장에서 가장 크게 체감되는 변화입니다.

‍

Q. 난독화 이슈는 빠뜨릴 수 없습니다. 금융 앱은 ProGuard가 아닌 상용 난독화 솔루션이 기본이며, 여기에 보안 솔루션까지 추가로 적용됩니다. 크래시 발생 시 로그가 a.b.c로 찍히는데, 이것이 실제로 복호화가 되나요?

이 부분이 해결되지 않으면 RUM 도입 효과가 제한될 수 있습니다.

ProGuard/R8 기반 난독화는 저희가 매핑 파일(mapping.txt)을 기반으로 표준 복호화를 지원합니다. 빌드 시 생성되는 매핑 파일을 와탭에 업로드하면, 난독화된 스택을 원래 클래스·메서드·라인 넘버로 되돌려 보여줍니다.

a.b.c(Unknown Source)가 아니라 LoginViewModel.validateUser(LoginViewModel.kt:87)로 표시됩니다. MTTR(장애 대응 시간)이 이 지점에서 크게 낮아집니다.

다만, 외산 제품을 사용하는 경우 상용 난독화 솔루션을 적용한 금융권 앱의 특성상 복호화 지원을 받기 어려울 수 있습니다. 와탭은 고객사가 복호화 모듈을 제공하는 경우, ProGuard 외 다른 난독화 방식도 복호화할 수 있도록 지원합니다. 또한 주요 국내 보안 솔루션과의 연동 경험이 축적되어 있어, 프로젝트 진입 시점에 적용된 보안 솔루션을 가장 먼저 확인합니다. PoC 이전 필수 점검 항목입니다.

‍

Q. 최신 단말기부터 구형 단말기까지 모두 모니터링이 가능한가요?

금융 앱에 모바일 모니터링을 도입할 때는 난독화·보안 솔루션 호환성과 함께 구형 단말기 지원 여부도 반드시 확인해야 합니다. 금융 앱은 고령층 사용자 대응을 위해 Android 5.0, iOS 11 수준까지 지원하는 경우가 많기 때문입니다. 일부 외산 모니터링 제품은 지원 OS 기준이 높아 PoC 단계에서 제외되는 사례도 있습니다.

와탭은 Android minSdkVersion 21, iOS 11 이상을 공식 지원하며, 구형 단말기에서도 SDK 오버헤드를 최소화하기 위한 샘플링 전략과 배치 전송 주기 조절 옵션을 제공합니다.

‍

3. 거래 단위 추적과 특정 고객 경험 역추적 - RUM이 확보하는 데이터

‍

Q. 금융 환경에서는 '거래 단위' 추적이 중요합니다. 송금 한 건, 대출 신청 한 건이 정상 처리되었는지, 클레임 발생 시 해당 고객의 경험을 역추적할 수 있는지가 관건입니다. 이 부분이 가능한가요?

가장 자주 받는 질문이며, 명확하게 답변드릴 수 있는 영역입니다. 크게 세 가지 레이어로 설명드립니다.

첫째, 물리적인 화면 단위로 성능을 관측하는 ScreenGroup입니다.

최근 금융 앱은 한 화면에 표현되는 데이터가 매우 많습니다. 화면을 물리적으로 살펴보면, 하나의 네이티브 뷰 안에 하위 뷰들과 웹뷰가 동시에 존재하는 구조를 흔히 볼 수 있습니다. 이때 각 요소를 물리적인 단위로만 측정하면, 개별 컴포넌트는 빠르게 로드된 것으로 보일 수 있습니다. 그러나 사용자가 체감하는 최종 화면 로딩 시간은 다를 수 있습니다.

와탭은 이러한 한계를 보완하기 위해 ScreenGroup이라는 단위를 활용합니다. 물리적인 측정값이 아닌, 사용자가 실제로 체감하는 화면 로딩 시간을 기준으로 성능을 측정하고 문제를 식별하는 방식입니다.

‍

둘째, 사용자의 화면 이동 흐름을 거래로 묶는 UserScreenGroup입니다.

수백 개에 달하는 앱 화면을 '로그인', '계좌조회', '송금', '대출신청' 같은 업무 단위로 묶는 개념입니다. 이를 통해 '앱이 느리다'는 추상적인 문제를 '대출신청 흐름의 3번째 스텝이 느리다'로 구체화할 수 있습니다. 단순해 보이지만, 있고 없고의 차이가 현장에서 매우 큽니다. 장애 원인을 찾는 시간이 확연히 짧아집니다.

와탭은 이를 ChainView로 구현합니다. 예를 들어 로그인 Activity에서 startGroup("LoginFlow")로 시작하고, 메인 화면 진입 시 endGroup("LoginFlow")로 종료하면, 그 사이에 발생한 모든 이벤트(화면 전환 시간, API 호출, 에러, 리소스 로드)가 하나의 흐름으로 묶입니다.

금융 거래는 중간 단계에서 끊기는 것이 치명적입니다. 예를 들어, 송금 버튼을 누른 후 2초 뒤 앱이 종료되는 경우입니다. ChainView로 묶어두면 '이체 프로세스 5단계 중 4단계에서 몇 명이 이탈했는지'까지 확인할 수 있어, 개선 우선순위를 수립하는 데에도 도움이 됩니다.

참고로 앱 시작 속도도 동일한 맥락에서 관리합니다. 콜드 스타트, 웜 스타트, 핫 스타트를 각각 측정하며, 특히 금융 앱에서 가장 자주 모니터링하게 되는 '로그인 성공 후 메인 대시보드 로딩 시간'도 ChainView로 묶어 별도 관리하시길 권장합니다. 이 구간이 체감 성능에 가장 큰 영향을 미칩니다.

셋째, 특정 고객의 경험을 역추적하는 기능입니다.

사용자 식별자(회원번호 해시값, UUID 등)를 세션에 태깅해두면 고객 클레임 발생 시 해당 고객이 언제, 어느 화면에서, 어떤 에러를 경험했는지를 세션 단위로 재구성할 수 있습니다. 예를 들어 'A 고객이 어제 15시에 송금 시도 중 본인인증 단계에서 멈췄으며, 당시 네트워크는 LTE, OS는 Android 12였다'는 수준까지 시계열로 확인할 수 있습니다.

‍

Q. Firebase Crashlytics를 이미 사용 중인 경우, 해당 무료 도구로 대체할 수 있지 않나요?

Firebase Crashlytics는 크래시 분석 도구로서 완성도가 높습니다. 다만, 금융권 엔터프라이즈 요구사항 관점에서는 다음과 같은 제약이 있을 수 있습니다.

• 데이터 주권: 구글 클라우드 기반으로 금융권 보안 기준 충족에 제약
• 실시간성: 사후 분석에 최적화되어 있어 장애 대응 골든타임 확보에 제약
• 전 구간 연계: 앱 내부만 관측하므로 백엔드 DB까지의 트레이싱 불가
• 난독화 복호화: ProGuard 외 상용 난독화 솔루션 복호화 지원 부족

핵심은 'Firebase 사용 여부'가 아니라 '금융권 엔터프라이즈 요구사항을 충족할 수 있는가'를 기준으로 판단해야 한다는 점입니다.

참고로, 기존 APM을 타 벤더 제품으로 사용 중인 경우 '모바일만 별도 도입할 수 있는가'에 대한 문의도 자주 있습니다. 와탭 모바일 모니터링은 독립적으로 운영 가능합니다. 다만 동일 벤더로 통합할 경우 전 구간 트레이싱이 훨씬 매끄러워지므로, 초기에 모바일만 도입한 다음 추후 APM까지 통합 확장하는 패턴이 많습니다.

‍

4. 금융권 RUM 도입 시 반드시 확인할 3가지 체크포인트

‍

Q. 마지막으로 금융사 담당자에게 도움이 될 만한 말씀이 있다면

현장에서 자주 드리는 말씀은 다음과 같습니다.

"모바일 장애는 서버 장애와 본질이 다릅니다. 고치면 되는 문제가 아니라, 애초에 보이지 않는 영역이 더 많습니다."

수천 종의 단말기, 수십 개의 OS 버전, 불안정한 네트워크, 중첩된 보안 솔루션. 이처럼 파편화된 환경을 사람이 일일이 관리하는 것은 현실적으로 어려우며, 결국 관측 가능한 체계(Observability)를 구축하고, 사람은 그 위에서 판단하는 구조로 가야 합니다.

금융권에서 사용자 경험 모니터링(RUM) 도입을 검토하실 때는 다음 세 가지를 기준으로 삼으시길 권장합니다.

1. 지원해야 하는 구형 단말기·OS까지 커버하는가 - 이 부분이 보장되지 않으면 도입 효과가 제한될 수 있습니다.
2. 앱에 적용된 난독화·보안 솔루션과 충돌 없이 실제 코드 레벨 데이터가 확보되는가 - PoC 초기 단계에서 반드시 검증해야 할 핵심 포인트입니다.
3. 프론트엔드부터 백엔드 DB까지 하나의 타임라인으로 연결되는가 - 이 연결이 확보되지 않으면 결국 부서 간 원인 소재 논쟁으로 이어질 가능성이 높습니다.

‍

마무리

오늘 와탭 APM/RUM 제품 개발 팀장 고지훈님으로부터 금융권 RUM에 관한 이야기를 들었습니다. 현장의 질문은 결국 하나로 수렴합니다. "서버는 정상인데, 왜 고객은 불편한가." 그 답은 서버 로그에 남지 않는 사각지대 즉, 디바이스·OS·네트워크·웹뷰 구간에 있습니다.

Observability는 장애를 막는 도구가 아니라, 장애 발생 시 '무슨 일이 일어났는지 설명할 수 있게' 해주는 도구입니다. 이 설명 가능성의 유무가 금융 서비스의 신뢰도를 좌우합니다.

모바일 모니터링 도입을 검토하고 계시다면, 와탭 금융권 전문 엔지니어와의 상담을 통해 자사 환경에 적합한 구성을 확인해 보시기 바랍니다.

‍

다음 단계가 필요하다면

• 자사 환경에 맞는 진단 - 차세대 이후의 성능 이슈, 하이브리드 앱 사각지대, 보안 솔루션 충돌 등을 점검받고 싶으신 경우
  👉 금융권 모바일 장애 진단 상담 신청
• 온디맨드 영상 보기 - 본문에서 소개한 ScreenGroup, 더 깊이 이해하고 싶으신 경우
  👉 고객이 체감하는 1초를 위한 프론트엔드 성능 측정의 새로운 기준

‍

본 콘텐츠에 대한 의견이나 추가로 다뤄주셨으면 하는 주제가 있으시다면 아래 폼으로 자유롭게 남겨주십시오. 👉 4월 호 의견 남기기

‍

각주

¹ 한국은행, 「2025년중 국내 지급결제 동향」, 2026년 3월 발표.