네이티브 앱과 웹서비스를 함께 운영하려면 어떻게 할까?

웹사이트를 앱으로 만드는 방법을 앞에서 정리했다면, 이번에는 반대 방향입니다. 앱은 Swift나 Kotlin으로 만든 네이티브 앱을 중심에 두고, 같은 서비스를 웹 브라우저에서도 쓸 수 있게 하고 싶을 때가 많습니다. 이 글에서 언급하는 오픈소스 도구의 원본 주소와 라이선스는 글 끝에 모아 두었습니다.

방법은 크게 네 가지입니다. 서버만 함께 쓰고 화면은 따로 만드는 방법, 네이티브 앱 안에 웹 화면을 섞는 방법, 처음부터 코드 하나로 앱과 웹을 함께 만드는 방법, 그리고 링크로 앱과 웹을 이어 주는 방법입니다. 각각 무엇을 함께 쓰고 무엇을 따로 만드는지, 어떤 서비스에 맞는지 차례로 정리합니다.

핵심 요약

• 가장 흔한 구조는 서버 API 하나에 iOS 앱, 안드로이드 앱, 웹사이트를 각각 붙이는 방식입니다. 품질은 가장 좋지만 화면을 세 번 만들어야 합니다.
• 자주 바뀌는 화면만 웹으로 만들어 앱 안에 띄우면, 앱스토어 심사 없이 고치면서 웹사이트에서도 같은 화면을 쓸 수 있습니다.
• React Native와 Expo, Flutter로는 코드 하나로 앱과 웹을 함께 만들 수 있습니다. 어떤 방법이든 유니버설 링크·앱 링크로 앱과 웹을 이어 두는 것이 좋습니다.

무엇을 하나로 두느냐에 따라 방법이 갈립니다

그림 1

앱과 웹을 함께 운영할 때 핵심 질문은 무엇을 공유하고 무엇을 따로 만들 것인가입니다. 데이터와 로직만 공유할 수도 있고, 화면 일부를 공유할 수도 있고, 화면과 로직을 통째로 공유할 수도 있습니다.

공유하는 범위가 넓을수록 개발 비용은 줄고, 대신 각 플랫폼에 꼭 맞춘 화면을 만들기는 어려워집니다. 아래 네 가지 방법은 이 사이의 어느 지점을 고르느냐의 차이입니다.

서버 API를 함께 쓰고 화면은 따로 만드는 방식이 가장 흔합니다

회원, 주문, 게시글 같은 데이터와 처리 규칙을 서버 API(앱과 웹이 데이터를 주고받는 창구) 한 곳에 두고, 그 위에 iOS 앱, 안드로이드 앱, 웹사이트를 각각 만드는 방식입니다. 은행, 쇼핑, SNS처럼 규모가 큰 서비스 대부분이 이 구조를 씁니다.

장점은 각 화면을 플랫폼에 가장 잘 맞게 만들 수 있다는 것입니다. 앱은 휴대폰 기능을 마음껏 쓰고, 웹은 검색 노출과 큰 화면에 맞춰 만들 수 있습니다. 대신 같은 기능을 세 번 만들고 관리해야 하므로 인력과 시간이 많이 듭니다. 처음부터 API를 앱 전용이 아니라 여러 화면이 함께 쓸 수 있게 설계해 두면, 나중에 웹을 붙이기가 훨씬 쉬워집니다.

자주 바뀌는 화면은 웹으로 만들어 앱 안에 띄울 수 있습니다

앱의 뼈대와 자주 쓰는 핵심 화면은 네이티브로 만들고, 이벤트, 공지, 약관, 고객센터처럼 자주 바뀌는 화면은 웹페이지를 웹뷰로 띄우는 방식입니다. 이 웹페이지는 웹사이트에서도 그대로 쓸 수 있으므로 한 번 만들어 두 곳에서 씁니다. 국내 대형 앱들도 이벤트 페이지 같은 곳에 이 방식을 많이 씁니다.

가장 큰 장점은 웹 화면은 앱스토어 심사 없이 서버에서 바로 고칠 수 있다는 것입니다. 웹 화면이 로그인 정보를 받거나 공유하기 같은 앱 기능을 부르려면, iOS의 WKWebView나 안드로이드의 WebView에 브리지(웹 코드와 앱 코드가 서로 함수를 부를 수 있게 하는 통로)를 직접 만들어야 합니다. 이때 브리지가 열린 웹뷰에는 내 서비스의 주소만 열리도록 막아 두어야 안전합니다.

코드 하나로 앱과 웹을 함께 만들 수도 있습니다

크로스플랫폼 도구 중에는 웹까지 함께 지원하는 것이 있습니다. React Native는 Expo와 react-native-web을 쓰면 같은 코드로 iOS, 안드로이드, 웹을 함께 만들 수 있고, Flutter도 하나의 코드로 세 플랫폼을 빌드합니다. 엄밀히 말하면 순수 네이티브는 아니지만, 앱을 중심에 두고 웹도 함께 제공한다는 목적에는 잘 맞습니다.

주의할 점은 웹 결과물의 성격입니다. 이렇게 만든 웹은 문서형 웹사이트보다는 앱처럼 동작하는 웹에 가깝습니다. 특히 Flutter 웹은 첫 로딩이 무겁고 검색 노출에 불리하므로, 회원 전용 서비스나 관리 도구처럼 검색이 중요하지 않은 곳에 맞습니다. 화면까지 공유하기 부담스럽다면 Kotlin Multiplatform처럼 데이터 처리 같은 로직만 공유하고 화면은 플랫폼마다 만드는 방법도 있습니다.

링크 하나로 앱과 웹 사용자를 모두 받습니다

그림 2

어떤 방법을 고르든 함께 쓰면 좋은 것이 유니버설 링크(iOS)와 앱 링크(안드로이드)입니다. 같은 웹 주소를 눌렀을 때 앱이 설치된 사람은 앱의 해당 화면으로, 설치하지 않은 사람은 웹사이트의 같은 페이지로 보내 줍니다.

설정은 웹사이트에 확인 파일을 하나 올리는 것에서 시작합니다. iOS는 apple-app-site-association, 안드로이드는 assetlinks.json 파일을 웹사이트의 /.well-known/ 경로에 두고, 앱에도 같은 도메인을 등록합니다. 그러면 휴대폰이 이 파일을 확인해 앱이 그 주소를 열어도 되는지 판단합니다. 앱과 웹이 같은 주소 체계를 쓰면 공유, 검색, 광고 링크를 한 번만 만들면 됩니다.

구분	내용	시사점
API 공유, 화면 따로	서버 하나에 iOS·안드로이드·웹을 각각 개발	품질은 가장 좋지만 비용이 가장 큽니다
네이티브 + 웹뷰	핵심 화면은 네이티브, 자주 바뀌는 화면은 웹	웹 화면은 심사 없이 고치고 웹사이트에서도 씁니다
코드 하나로 앱·웹	React Native + Expo, Flutter, Kotlin Multiplatform	작은 팀에 유리하지만 웹의 검색 노출은 약합니다
링크 연결	유니버설 링크·앱 링크로 같은 주소를 앱 또는 웹으로	다른 방법에 덧붙여 쓰는 기본 장치입니다

정리하며

네이티브 앱과 웹서비스를 함께 운영하는 방법은 무엇을 공유하느냐에 따라 나뉩니다. 데이터만 공유하고 화면을 따로 만들면 품질이 가장 좋고, 웹 화면을 앱 안에 섞으면 수정이 빨라지며, 코드 하나로 만들면 개발 비용이 가장 적게 듭니다.

처음 시작한다면 API를 여러 화면이 함께 쓸 수 있게 설계하고, 주소 체계를 앱과 웹이 같게 맞춰 두는 것부터 챙기는 것이 좋습니다. 이 두 가지만 지켜 두면 나중에 어떤 방법으로 웹을 붙이든 바꾸기 쉽습니다.

원본과 라이선스

• React Native · Meta에서 시작 · MIT · github.com/react/react-native
• Expo · Expo · MIT · github.com/expo/expo
• react-native-web · Nicolas Gallagher · MIT · github.com/necolas/react-native-web
• Flutter · Google · BSD-3-Clause · github.com/flutter/flutter
• Kotlin Multiplatform · JetBrains · Apache-2.0 · github.com/JetBrains/kotlin

라이선스는 2026년 10월 26일 기준 각 GitHub 저장소에서 확인했습니다.

한마디로 정리하면

음식점에 비유하면 중앙 주방 하나로 매장 영업과 배달을 함께 하는 것입니다. 주방(서버 API)에서 같은 요리가 나오고, 손님은 매장(앱)에 오거나 배달(웹)로 받아 봅니다.

매장과 배달 포장을 각각 따로 정성껏 꾸미면 가장 보기 좋지만 손이 많이 갑니다. 매장 안에 배달용 메뉴판 일부를 그대로 걸어 두면 메뉴가 바뀔 때 한 번만 고치면 됩니다. 처음부터 매장과 배달에 함께 쓰는 공용 포장을 만들면 가장 간편하지만, 어느 한쪽에 꼭 맞지는 않습니다.

그리고 어느 방식이든 주문 번호(주소)를 같게 맞춰 두면, 손님이 매장으로 오든 배달로 받든 같은 주문을 찾아 줄 수 있습니다.