타사 서비스 연동의 딜레마 : 우리는 사용자 경험을 어디까지 통제해야할까?

들어가기

타사 서비스를 앱 안에 연동할 때, 상대 화면을 그대로 가져와 띄울지, 데이터만 받아 우리 화면을 새로 그릴지 하는 선택을 해야할 때가 있습니다. 어떤 방식을 택하든 결국 도메인이 다른 두 서비스 사이에서 사용자를 로그인 상태로 유지하는 방법과 다시 만납니다. 이번 글에서는 기획 단계에서 마주하는 개발 상식의 딜레마부터, 이를 해결하기 위한 설계 디테일까지 실무 관점에서 짚어보려 합니다. 

---

1. 기획의 첫번째 갈림길 : 웹뷰 또는 API 연동

상대 서비스의 기능을 우리 앱에 가져올 때 주로 두 가지 방식을 취하게 됩니다.

 

1. 웹뷰 방식

상대 서비스가 이미 만들어둔 웹페이지를 우리 앱 안의 창에 그대로 띄우는 방식입니다. 화면을 새로 만들지 않아 개발 속도가 빠르고, 상대가 화면을 바꾸면 우리 쪽 수정 없이 자동으로 반영됩니다. 다만 화면의 디자인·인터랙션을 우리 마음대로 바꿀 수 없고, 로딩이나 오류 상태를 우리 쪽에서 세밀하게 제어하기 어렵습니다.

 

2. API 연동 방식

화면 없이 데이터(JSON 등)만 받아와 우리 디자인 시스템대로 화면을 직접 그리는 방식입니다. 브랜드 일관성과 세밀한 UX 제어가 가능하지만, 상대 서비스의 기능이 바뀔 때마다 우리도 개발을 따라가야 해서 유지보수 비용이 더 듭니다.

 

예시

러닝 기록 앱을 만들고 있다고 가정해 봅시다. 사용자가 뛰기 전에 날씨를 볼 수 있게 기상청 날씨 정보를 연동하려고 합니다. 이 때 두 가지 선택지가 생깁니다.

 

선택 1. "상대 화면을 그대로 가져와 띄우자."

• 어떻게 띄우나 : 앱 하단에 '날씨 보기' 버튼을 누르면, 기상청 모바일 웹페이지 주소를 통째로 앱 안에 띄웁니다.
• UX 체감 : 사용자는 러닝 앱을 쓰다가 갑자기 기상청 날씨 화면을 보게 됩니다. 폰트, 광고 모두 그대로 노출됩니다.
• 장단점 : 개발자는 URL 링크만 연결하면 되니 10분 만에 퇴근할 수 있지만, 디자인적으로는 우리 앱의 통일성이 깨집니다.

선택 2. "데이터만 받아 우리 화면을 새로 그리자."

• 어떻게 띄우나 : 기상청 서버에 "오늘 서울 날씨 어때?"라고 요청(API)하면, 기상청이 화면은 안 주고 {"온도": 25도, "상태": "맑음"}이라는 데이터만 우리 개발자에게 줍니다.
• UX 체감 : 기획자와 디자이너가 우리 러닝 앱에 딱 맞는 세련되고 스포티한 폰트와 햇님 ☀️ 아이콘을 새로 디자인합니다. 그리고 기상청에서 받아온 '25'라는 숫자만 그 디자인 위에 얹어줍니다.
• 장단점 : 우리 앱의 브랜드 일관성이 완벽하게 유지되어 사용자는 "이 앱 정말 예쁘다"라고 느끼지만, 디자이너와 개발자가 화면을 처음부터 다 그려야 하니 공수비용이 듭니다.

실무 적용 문제

지금까지 읽으신 내용을 바탕으로 실무 퀴즈를 하나 풀어보겠습니다.

 

토스 앱에서 내 '카카오뱅크 계좌 잔액'을 조회하는 화면입니다. 카카오뱅크 특유의 노란 UI나 고유의 폰트는 보이지 않고, 토스만의 UI로 잔액이 표시됩니다. 그렇다면 토스는 타행 계좌를 연동할 때 '웹뷰'를 썼을까요, 아니면 'API 연동'을 썼을까요?

 

 

✔️ 정답은 'API 연동'입니다.

토스는 신한은행의 웹페이지 화면을 가져와 앱 안에 띄우는 대신, 금융망(마이데이터/오픈뱅킹 API)을 통해 {"잔액": 0원}이라는 순수한 데이터(JSON)만 받아옵니다.

 

그리고 그 데이터를 토스팀의 디자인 시스템(네이티브 UI)에 맞춰 화면에 직접 새로 그리는 엄청난 수고를 감수합니다. 개발 및 유지보수 비용이 천문학적으로 들지만, 사용자가 타사 서비스에 접속했다는 이질감을 1%도 느끼지 못하게 만들어 ‘역시 토스가 제일 편해’라는 압도적인 UX를 보여주고 있는 좋은 API 연동 사례입니다.

---

2. 완벽한 타협점 : 하이브리드 UX

웹뷰의 '빠른 유지보수'와 API의 '안정적인 사용성'을 모두 잡기 위해 실무에서 가장 많이 쓰는 패턴이 바로 '하이브리드 앱'입니다.

1. 샌드위치 UX
   상단 헤더와 하단 바 같은 껍데기는 네이티브로 고정해 두고, 그사이 빈 공간에만 웹뷰라는 알맹이를 끼워 넣는 방식입니다.
2. 바텀시트/팝업 웹뷰
   화면 전체나 본문 영역뿐만 아니라, 기존 네이티브 화면 위에 스르륵 올라오는 '바텀시트'나 중앙 '팝업'만 단독으로 웹뷰로 띄우는 방식도 실무에서 아주 흔하게 쓰입니다.
   • 실무 예시: 앱에서 주소를 입력할 때 뜨는 '우편번호 검색' 바텀시트나, 수시로 내용이 바뀌는 '이벤트 약관 동의' 팝업 등을 웹뷰로 띄워, 앱 업데이트(심사) 없이도 빠르게 내용을 수정할 수 있습니다.
3. 풀 웹뷰
   최소한의 네이티브 껍데기(GNB, 뒤로 가기, 닫기 버튼 등)만 남겨둔 채 메인 화면 전체를 웹뷰로 채우는 방식입니다. 신규 서비스 MVP를 빠르게 검증하거나 인앱 서비스를 제공할 때 등, 웹 비중을 극대화한 방식입니다.

기획자가 하이브리드 UX를 만드는 목적

• 전환율(CVR) 극대화 : 결제나 예약 같은 핵심 버튼은 네이티브 하단 바에 박아두어 네트워크 상태와 무관하게 0.1초 만에 누를 수 있게 합니다.
• 레이어 꼬임 방지 : TOP 버튼 등을 네이티브로 띄우면, 안쪽 웹페이지가 아무리 바뀌어도 가려지거나 버벅거리지 않고 화면 최상단에 안정적으로 떠 있게 됩니다.
  

실무 적용 문제

화면을 보고 네이티브 레이어 찾아내기

우리가 방금 배운 '샌드위치 UX' 개념을 실전에 적용해 볼까요?

 

카카오톡 앱 안에서 열린 '푸드위크 코리아 예약 상세 페이지' 입니다. 이 화면은 겉은 카카오톡 앱(네이티브)이고 속은 상세 페이지(웹뷰)인 전형적인 하이브리드 구조입니다.

그렇다면 절대 화면에서 사라지거나 덜컹거리지 않고 꽉 고정되어 있는 '네이티브 레이어'는 무엇일까요?

1 - 상단 네비게이션 바
2 - 컨텐츠 영역
3 - 하단 고정 바
4 - FAB 버튼
5 - 바텀시트
6 - 토스트 팝업

 

✔️ 정답은 2번을 제외한 모든 영역 입니다.

• 1번 [네이티브] : 홈, 타이틀, 검색이 있는 영역입니다. 웹이 서버 에러로 하얗게 뻗더라도 사용자가 안전하게 탈출할 수 있도록 네이티브로 고정합니다.
• 2번 [웹뷰] : 전시회 이미지, 티켓 옵션, 상세 안내 등 수시로 내용이 바뀌는 알맹이 영역입니다.
• 3번 [네이티브] : 사용자가 스크롤을 아무리 내리더라도 구매 전환율을 높이기 위해 노란색 '예약하기' 버튼을 최상단 레이어에 빠르게 누를 수 있게 박아둡니다.
• 4번 [네이티브] : 우측 하단의 위로 가기 버튼입니다. 웹 페이지 내용물에 가려지지 않고 항상 위로 스크롤할 수 있도록 네이티브 뷰 위에 띄워둡니다.
• 5번 [네이티브] : '공유하기' 클릭 시스마트폰 OS의 자원(카카오톡 공유, URL 복사)을 쓰기 위해 웹뷰가 네이티브에게 브릿지 신호를 보내 호출한 네이티브 바텀시트입니다.
• 6번 [네이티브] : 필수값을 입력하지 않고 예약 버튼을 눌렀을 때 뜨는 ‘수량을 선택해주세요’ 안내 팝업입니다. 예외 상황 발생 시 사용자에게 확실한 피드백을 주기 위해 네이티브 UI로 띄웁니다.

이처럼 하이브리드 앱 기획은 단순히 화면을 그리는 것을 넘어, 사용자의 핵심 경험(결제, 탈출, 팝업)은 네이티브에 두고, 자유롭게 바뀔 본문만 웹뷰에 맡기는 레이어 분리 작업이 핵심입니다.

---

하이브리드 난관 1 : 도메인의 벽을 넘는 인증 (쿠키 vs OAuth & 토큰)

타사 서비스를 연동할 대 가장 먼저 마주치는 벽은 ‘로그인 상태 유지’ 입니다.

• 쿠키(Cookie)
  같은 회사의 서브도메인끼리라면(예: kt.com과 spamfilter.mobile.kt.com처럼 TLD가 .kt.com으로 같은 경우), 쿠키의 Domain 속성을 TLD로 지정해 서브도메인 간에 로그인 세션을 공유할 수 있습니다. 구현이 비교적 간단하고 별도의 인증 서버 없이도 동작합니다.
• OAuth & 토큰(Token) 방식
  완전히 다른 도메인의 서비스를 연동할 때 씁니다. 브라우저 쿠키에 의존하지 않고, OAuth 표준 규격에 따라 발급된 암호화된 '디지털 출입증(토큰)'을 서버 간 명시적으로 주고받아 브라우저 보안 제약(제3자 쿠키 차단) 없이 로그인 상태를 안전하게 유지합니다.

💡 웹뷰(WebView) vs iframe

웹뷰 : 앱 안에 뚫어놓은 창문
: 네이티브 앱(iOS/Android) 화면 안에 웹페이지(HTML)를 띄워 보여주는 컴포넌트. (하이브리드 샌드위치 UX의 알맹이)

iframe : 웹 안에 뚫어놓은 창문
: 웹사이트 안에서 '또 다른 외부 웹페이지'를 가져와 액자처럼 삽입할 때 쓰는 HTML 태그. (예: 블로그 글 안의 유튜브 플레이어, 네이버 지도 화면)

OAuth 토큰 전달의 동작 원리 : 4단계 데이터 흐름

기획자나 디자이너 입장에서 OAuth 2.0, OpenID Connect 같은 개발 용어가 한 줄에 쏟아지면 이해하기 힘든 것이 당연합니다. 복잡한 개발 용어 대신, 우리 앱 안에서 사용자가 '제휴사 포인트몰 가기' 버튼을 눌렀을 때 뒤에서 벌어지는 데이터 흐름을 Step 0부터 Step 3까지 풀어보겠습니다.

• Step 0. 사전 세팅 (신뢰 관계 구축)
  우리 회사 서버 개발자와 타사 서버 개발자가 사전에 만나 비밀번호(Secret Key)와 식별자(Client ID)를 교환해 둡니다. ‘우리 앱에서 발급한 특정 디지털 서명이 들어간 유저는 이미 검증된 사람이니 바로 로그인시켜주자’라고 시스템적 계약을 맺는 단계입니다.
• Step 1. 자체 인증
  사용자가 우리 앱을 켜고 로그인을 마친 상태입니다. 우리 서버는 신원 인증을 완료하여 세션을 보유하고 있습니다.
  
  
• Step 2. 웹뷰 진입 시도 및 '토큰(Token)' 발급
  사용자가 버튼을 누르는 순간, 우리 서버가 OAuth 프로토콜에 따라 암호화된 일회성 출입증인 '토큰'을 발급합니다. 이 안에는 ‘이 사람 이름은 홍길동(인증)이고, ~을 이용할 권한(인가)이 있음’이라는 정보가 유효기간과 함께 담깁니다.
  
  
• Step 3. 토큰 전달 및 검증 (타사 로그인 완료)
  우리 앱이 웹뷰 창을 열면서 타사 URL을 호출할 때, 방금 만든 '토큰'을 헤더나 URL 파라미터로 안전하게 함께 던집니다. 타사 서버는 Step 0에서 약속한 비밀번호로 토큰의 암호를 풀어 검증한 뒤, 비밀번호를 다시 묻지 않고 곧바로 로그인이 완료된 맞춤 화면을 우리 웹뷰 창에 띄워줍니다.

그래서 왜 쿠키 대신 OAuth(토큰)을 사용할까?

브라우저라는 창고에 데이터를 몰래 묻어두고 '알아서 꺼내 가겠지' 하는 쿠키방식은 브라우저의 강력한 보안 정책(제3자 쿠키 차단)에 막히기 십상입니다.

 

반면 OAuth(토큰)는 우리가 직접 안전하게 암호화된 출입증(토큰)을 쥐어주고 상대방 서버에 "이 사람 맞는지 확인해 줘!" 하고 명시적으로 쏘아 보내는 방식이기 때문에, 브라우저 정책에 구애받지 않고 도메인의 벽을 안전하게 넘을 수 있습니다.

 

대표 예시

우리가 매일 쓰는 OAuth 대표 예시 : 노션(Notion)

노션 앱에서 Google 로그인을 진행할 때 동작하는 실제 5단계 UX 흐름입니다.

1. 네이티브 보안 얼럿: 웹뷰 피싱 방지를 위해 OS 차원에서 "Google 인증 창으로 이동합니다" 안내
2. 시스템 브라우저 뷰 렌더링: 일반 웹뷰가 아닌 시스템 브라우저(ASWebAuthenticationSession)를 사용해 구글 생체인증/자동완성 안전하게 활용
3. 토큰 발급 및 앱 리다이렉트: 구글이 OAuth 토큰을 노션으로 전달 후, 딥링크를 통해 노션 앱으로 복귀
4. 토큰 검증 & 권한 동의: 노션 서버가 토큰을 검증하는 동안 푸시 알림 수신 동의 요청
5. 최종 랜딩: 인증 완료 후 개인 워크스페이스 메인 화면 랜딩

---

하이브리드 난관 2 : 네비게이션과 제스처 제어

앱과 웹뷰가 섞여 있다 보니, '뒤로 가기'를 눌렀을 때 앱이 닫혀야 할지, 웹페이지가 이전으로 가야 할지 충돌이 발생합니다. 뎁스가 깊은 웹뷰 화면에서 사용자가 무심코 스와이프를 하거나 기기의 '뒤로 가기' 물리 버튼을 눌렀을 때, 이전 페이지로 가지 않고 앱 자체가 튕기듯 종료되는 대참사가 종종 발생합니다.

 

예를 들어, 하이브리드 앱으로 만든 쇼핑몰에서 상품 상세 페이지의 링크를 타고 리뷰 화면까지 깊게 들어갔는데, 폰의 물리적 뒤로 가기 버튼을 누르는 순간 앱 메인 홈으로 튕겨버리는 현상입니다.

 

✔️ 어떻게 풀어야 할까?

앱과 웹뷰 사이의 네비게이션 위계를 어떻게 맞출지, 이를 위해 개발자와 '브릿지 통신'을 어떻게 설계해야 안전한 사용자 경험을 줄 수 있는지 명시해야 합니다.

---

하이브리드 난관 3 : 로딩과 에러 UX 통제하기

네트워크가 느려지거나 오류가 났을 때 사용자가 느끼는 경험의 차이가 극명하게 드러납니다. 네이티브는 사용자를 달래며 기다리게 할 수 있지만, 웹뷰는 순식간에 서비스의 '쌩얼'이 드러나 사용자에게 이질감을 주기 쉽습니다.

 

예를 들어, 제휴사 이벤트를 보려고 웹뷰 화면으로 진입했는데 상대방 서버가 느려 3초 동안 텅 빈 하얀 백지만 떠 있거나, 네트워크 오류가 났을 때 웹 브라우저 특유의 날것 그대로인 '404 Not Found' 에러 화면이 노출되는 현상입니다.

 

✔️ 어떻게 풀어야 할까?

웹뷰 영역의 로딩 상태와 에러 상황을 앱이 어디까지 가려주고 통제할지 기획서에 예외 처리 정책을 명시해야 합니다.

• 로딩 UX 방어 : 웹뷰의 HTML이 다 그려지기 전까지 앱 자체의 로딩 스피너나 스케일톤 UI를 덮어두고, 렌더링이 완료되는 시점에 자연스럽게 전환하는 브릿지 이벤트를 설계합니다.
• 에러 UX 방어 : 웹뷰에서 404/500 에러 상태 코드가 반환되면 웹 페이지의 날것 에러 화면을 노출하는 대신, 네이티브 전용 에러 팝업을 띄우고 ‘다시 시도’ 버튼을 제공하도록 예외 처리를 맞춰두어야 합니다.

---

3. 실무자를 위한 웹뷰 정리

구분	일반 웹뷰	시스템 브라우저 뷰	외부 브라우저 뷰
개발 용어	WKWebView(iOS), WebView(AOS)	SFSafariViewController(iOS), Chrome Custom Tabs(AOS)	Safari, Chrome 앱 직접 호출
로그인	불가 (매번 새로 로그인 필요)	가능 (사파리/크롬 로그인 정보 공유)	가능 (원래 로그인 되어있음)
UX 체감	네이티브처럼 자연스럽게 녹아듦.	메인 브라우저의 분신. 앱 위에 팝업으로 스르륵 열림.	앱 닫히고 완전히 다른 앱이 켜짐.

웹뷰 감별은 어떻게 할까?

타사 앱을 벤치마킹할 때, 개발자에게 묻지 않고 스스로 화면의 정체를 판별해 내는 실무 팁 4가지 입니다.

1. 꾹 눌러보기 (Long Press)
   • 테스트: 텍스트나 이미지를 2~3초간 꾹 눌러봅니다.
   • 판별: 텍스트에 파란색 드래그 블록이 잡히며 브라우저 표준 복사 팝업이 뜨거나, 이미지 저장 팝업이 뜨면 웹뷰일 확률이 높습니다. (카카오 선물하기처럼 제스처가 차단된 고도화된 앱에서도 가장 확실하게 동작하는 방법입니다.)
2. 화면 끝까지 당겨보기 (Overscroll)
   • 테스트: 리스트 맨 위에서 한 번 더 밑으로 훅 당겨봅니다.
   • 판별: 상단 탭이나 검색창까지 화면 전체가 스프링처럼 한 덩어리로 당겨진다면 통짜 웹뷰입니다. 상단은 고정되어 있고 아래 리스트만 고무줄처럼 늘어나거나 새로고침 스피너가 돈다면 네이티브와 웹이 섞인 샌드위치 구조입니다.
   • 실무 팁: 카카오 선물하기 같은 고도화된 하이브리드 앱의 경우, 웹 느낌을 지우기 위해 CSS나 설정에서 웹 특유의 Overscroll과 새로고침 스피너를 아예 원천 차단해 화면이 고정되어 있는 경우도 있습니다.
3. 비행기 모드 켜보기
   • 테스트: 인터넷(Wi-Fi/데이터)을 끄고 화면을 진입하거나 내부 버튼을 눌러봅니다.
   • 판별: 화면 하단에는 ‘네트워크 연결이 끊겼습니다’라는 네이티브 토스트 팝업이 바로 뜨지만, 가운데 웹뷰 영역은 이 팝업과 별개로 반응이 전혀 없거나 화면 전환/데이터 업데이트가 전혀 일어나지 않은 채 이전 화면 상태에 멈춰있게 됩니다.
4. iOS 뒤로가기 스와이프 해보기(Swipe-to-back)
   • 테스트: 아이폰 환경에서 화면 왼쪽 끝을 잡고 오른쪽으로 살짝 밀어봅니다.
   • 판별: 화면 전체가 뒤로 밀리는 대신, 상단 헤더와 하단 버튼(네이티브 껍데기)은 제자리에 딱 고정된 채 가운데 본문 영역(웹뷰 알맹이)만 분리되어 스르륵 밀려 나간다면 100% 샌드위치 UX 하이브리드 구조입니다.

---

4. 마무리 : 우리가 얼마나 통제권을 가질 것인가

웹뷰는 빠르게 붙일 수 있지만 화면과 로그인 흐름을 세밀하게 제어하기 어렵고, API 연동은 자유도가 높은 대신 개발 비용이 더 듭니다. 인증도 마찬가지로, 같은 도메인이면 쿠키 공유로 해결되지만 다른 도메인이라면 OAuth가 필요합니다. 결국 두 선택 모두 ‘우리가 얼마나 통제권을 가질 것인가’라는 같은 질문으로 돌아갑니다.

 

기획자는 무조건 ‘API로 예쁘고 완벽하게 해주세요!’라고 요구하는 사람이 아닙니다. 상황에 따라 쿨하게 웹뷰를 수용하되, 결제 완료나 이탈 같은 '치명적인 순간'만큼은 API나 브릿지로 꼼꼼하게 통제하자는 타협안을 제시해야 합니다.

 

다음 글에서는 OAuth 연동 후 발생하는 로그아웃 동기화, 토큰 만료 처리 같은 후속 이슈를 다뤄보겠습니다.