---
term: '크로스 플랫폼 개발'
seoTitle: '크로스 플랫폼 개발이란? 프레임워크, 네이티브 vs. 공유 백엔드'
headline: '크로스 플랫폼 개발이란?'
slug: cross-platform-development
category: frontend-web
shortDefinition: '크로스 플랫폼 개발은 하나의 공유 코드베이스로 iOS, Android, 웹, 데스크톱 등 여러 플랫폼에서 실행되는 앱을 만드는 방식입니다.'
relatedTerms:
  - backend-sdk
  - progressive-web-app-pwa
  - baas-vs-custom-backend
  - api
contrastsWith:
  - progressive-web-app-pwa
aboutTerms:
  - 'Native vs. Cross-Platform'
  - 'Compiled vs. Bridge vs. WebView'
  - 'Shared Backend'
faq:
  - question: '크로스 플랫폼 개발이란 무엇입니까?'
    answer: '플랫폼마다 별도의 코드를 작성하는 대신, 하나의 공유 코드베이스로 iOS와 Android, 그리고 점점 더 웹과 데스크톱까지 여러 플랫폼에서 실행되는 애플리케이션을 만드는 것입니다. 지향하는 구호는 "한 번 작성하면 어디서나 실행된다(write once, run anywhere)"이고, 현실주의자의 각주는 "한 번 작성하고 어디서나 디버깅한다"입니다.'
  - question: '크로스 플랫폼과 네이티브의 차이는 무엇입니까?'
    answer: '네이티브는 하나의 운영체제를 그 고유의 언어와 도구(iOS는 Swift, Android는 Kotlin)로 겨냥해 최고의 성능과 가장 깊은 기기 접근을 얻습니다. 크로스 플랫폼은 하나의 코드베이스를 여러 운영체제에서 재사용해 비용을 낮추고 출시를 앞당기며, 그 대가로 약간의 성능과 새 OS 기능에 대한 즉각적인 접근을 내줍니다.'
  - question: '주요 크로스 플랫폼 프레임워크에는 무엇이 있습니까?'
    answer: '두 가지가 선두에 있습니다. 하나는 브리지를 통해 실제 네이티브 UI 컴포넌트를 렌더링하는 JavaScript 프레임워크이고, 다른 하나는 자체 렌더링 엔진을 탑재하고 네이티브 코드로 컴파일되는 프레임워크입니다. 그 밖에 네이티브 UI를 유지하면서 비즈니스 로직만 공유하는 방식이나 웹 앱을 네이티브 컨테이너로 감싸는 방식도 있습니다. 이들의 주된 차이는 화면을 그리는 방법입니다.'
  - question: '하이브리드와 크로스 플랫폼의 차이는 무엇입니까?'
    answer: '크로스 플랫폼 프레임워크는 네이티브 코드로 컴파일되거나 네이티브 컴포넌트를 렌더링합니다. 하이브리드 앱은 네이티브 웹뷰 래퍼 안에서 웹 앱을 실행합니다. 하이브리드는 웹 팀에게 가장 빠른 경로이지만 성능은 가장 약하며, 크로스 플랫폼은 하이브리드와 완전한 네이티브 사이에 위치합니다. 일부 분류 체계는 하이브리드를 크로스 플랫폼의 하위 범주로 취급합니다.'
  - question: '크로스 플랫폼은 네이티브만큼 빠릅니까?'
    answer: '최신 프레임워크는 네이티브 성능의 약 90–95%에 도달하며, 대부분의 앱에는 충분합니다. 그래픽 집약적인 게임, AR과 VR, 무거운 실시간 처리처럼 마지막 몇 퍼센트와 하드웨어 직접 접근이 중요한 영역에서는 여전히 네이티브가 우위입니다.'
  - question: '코드를 얼마나 재사용할 수 있고, 얼마나 절약됩니까?'
    answer: '프론트엔드는 프레임워크와 플랫폼별 UI나 로직의 양에 따라 보통 약 90%를 재사용합니다. 업계에서 보고되는 수치는 별도의 네이티브 앱을 만드는 경우보다 비용이 30–40% 적고 출시가 30–40% 빠르다는 쪽에 모여 있습니다. 하지만 더 크고 더 확실한 재사용 이득은 백엔드입니다. 백엔드는 네이티브든 크로스 플랫폼이든 모든 클라이언트에서 100% 공유됩니다.'
  - question: '언제 네이티브 대신 크로스 플랫폼을 선택해야 합니까?'
    answer: '예산과 일정이 빠듯할 때, MVP, 일반적인 비즈니스 및 콘텐츠 앱, 여러 플랫폼 동시 출시에는 크로스 플랫폼이 맞습니다. 성능이 핵심이거나 하드웨어를 많이 쓰거나 플랫폼을 대표하는 쇼케이스 앱에는 네이티브가 맞습니다. 어느 쪽이든 백엔드는 공유되므로, 이 결정은 사실상 프론트엔드에 관한 것입니다.'
  - question: '크로스 플랫폼은 프론트엔드만의 문제입니까?'
    answer: '아닙니다. 그리고 대부분의 가이드가 놓치는 부분이 바로 이것입니다. 프론트엔드 프레임워크 선택은 UX와 성능 사이의 트레이드오프이지만, 가장 큰 코드 재사용 이득은 공유 백엔드, 즉 iOS, Android, 웹, 데스크톱을 모두 서비스하는 하나의 API입니다. 완전한 네이티브 앱 두 개라도 백엔드를 공유한다면 백엔드 계층에서는 크로스 플랫폼입니다.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Write once, run anywhere — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Write_once,_run_anywhere'
  - name: 'Cross-platform software — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Cross-platform_software'
  - name: 'React Native — open-source framework'
    url: 'https://reactnative.dev/'
  - name: 'Stack Overflow Developer Survey'
    url: 'https://survey.stackoverflow.co/'
cta:
  title: '백엔드는 한 번만 작성하세요'
  text: 'Back4app은 하나의 API 위에 Flutter, React Native, iOS, Android, JavaScript용 SDK를 제공합니다. 플랫폼마다 어떤 프론트엔드를 쓰든 데이터, 인증, 규칙은 한 번만 작성하면 됩니다.'
  linkText: '무료로 시작하기'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-11-03'
translationKey: cross-platform-development
---

**크로스 플랫폼 개발은 하나의 공유 코드베이스로 iOS, Android, 웹, 데스크톱 등 여러 플랫폼에서 실행되는 앱을 만드는 방식입니다.** 구호는 "한 번 작성하면 어디서나 실행된다(write once, run anywhere)"이고, 현실은 "한 번 작성하고 어디서나 디버깅한다"를 덧붙입니다. 그런데 상위에 노출되는 모든 가이드는 크로스 플랫폼을 *프론트엔드* 문제, 즉 어떤 UI 프레임워크를 고를 것인가의 문제로만 다룹니다. 이 글은 그들이 모두 건너뛰는 부분을 더합니다. **가장 크고 가장 확실한 코드 재사용 이득은 UI가 아니라 공유 백엔드에 있으며**, 이 이득은 완전한 네이티브 앱에도 똑같이 주어집니다.

## 핵심 요약

| 질문 | 답변 |
| --- | --- |
| 개념 | OS마다 하나씩이 아니라, 하나의 코드베이스 → 여러 플랫폼 |
| 프론트엔드 접근 방식 | 컴파일형(자체 렌더러) · 네이티브 브리지 · 웹뷰 래퍼 |
| 네이티브와의 비교 | 도달 범위 + 속도 + 공유 코드 ↔ 최고 성능 + 네이티브 UX |
| 잘 언급되지 않는 이득 | **백엔드는 100% 공유**됩니다. 네이티브든 크로스 플랫폼이든 |
| 메커니즘 | [SDK](/glossary/ko/backend-sdk/) + 모든 클라이언트가 사용하는 REST/GraphQL [API](/glossary/ko/api/) |

## 같은 백엔드, 모든 프론트엔드

**JavaScript:**

```javascript
// JavaScript / React Native / web — Back4app JS SDK
// The SAME backend call, whatever the frontend framework
const query = new Parse.Query('Task');
query.equalTo('done', false);
const tasks = await query.find();
// This exact query runs from React Native, a web SPA, or Node —
// because the backend is written ONCE and every client shares it.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Same data, same auth, same rules — a different frontend framework
final tasks = await QueryBuilder<ParseObject>(ParseObject('Task'))
    .whereEqualTo('done', false)
    .query();
// The Flutter app and the native iOS app can differ entirely on the frontend
// and still share ONE backend — the cross-platform win nobody talks about.
```

**Swift:**

```swift
// iOS / Swift (native) — Back4app Swift SDK
// A fully NATIVE iOS app — still cross-platform at the backend layer
let tasks = try await Task_.query("done" == false).find()
// Native iOS + native Android + web can each pick their own UI stack
// and share the identical backend API — write the backend once.
```

**Kotlin:**

```kotlin
// Android / Kotlin (native) — Back4app Android SDK
// A fully NATIVE Android app — still cross-platform at the backend layer
val tasks = ParseQuery.getQuery<ParseObject>("Task")
    .whereEqualTo("done", false)
    .find()
// Native iOS + native Android + web can each pick their own UI stack
// and share the identical backend API — write the backend once.
```

서로 다른 네 개의 프론트엔드(JS 웹 앱, Flutter, 네이티브 Swift, 네이티브 Kotlin)와 하나의 쿼리입니다. 모두 같은 백엔드와 통신하기 때문입니다. 이것이 검색 결과 상위의 글들이 결코 그리지 않는 아키텍처입니다. **크로스 플랫폼 프론트엔드(또는 네이티브 프론트엔드들) + 하나의 공유 백엔드.** 프론트엔드 프레임워크는 실제 트레이드오프를 동반하는 실제 결정입니다. 반면 백엔드 재사용은 거의 공짜이고 거의 보편적입니다.

## 세 가지 프론트엔드 접근 방식

| 접근 방식 | UI를 그리는 방법 | 트레이드오프 |
| --- | --- | --- |
| 컴파일형 / 자체 렌더러 | 자체 엔진을 탑재하고 네이티브 코드로 컴파일 | 최고 성능, 플랫폼 간 픽셀 단위로 동일한 UI |
| 네이티브 브리지 | 브리지를 통해 *실제* 네이티브 컴포넌트를 렌더링 | 플랫폼별 네이티브 룩앤필, JS 생태계 |
| 웹뷰 / 하이브리드 | 네이티브 컨테이너 안의 웹 앱 | 웹 팀에게 가장 빠름, 성능과 UX는 가장 약함 |

대부분의 가이드가 흐리게 넘기는 분류입니다. **컴파일형** 프레임워크는 모든 픽셀을 스스로 그립니다(어디서나 일관되고 네이티브만큼 빠릅니다). **네이티브 브리지** 프레임워크는 OS에 자체 위젯을 그리라고 지시합니다(플랫폼마다 네이티브처럼 보입니다). **웹뷰/하이브리드** 앱은 래퍼 안에서 HTML을 렌더링합니다(앱의 옷을 입은 웹사이트입니다). "크로스 플랫폼"은 보통 앞의 두 가지를, "하이브리드"는 세 번째를 뜻합니다. 그 차이는 정확히 실제 네이티브 코드가 실행되느냐, 브라우저 엔진이 실행되느냐입니다.

```mermaid
flowchart LR
  accTitle: 하나의 공유 백엔드 위의 크로스 플랫폼 프론트엔드
  accDescr: 컴파일형 크로스 플랫폼 앱, 네이티브 브리지 앱, 네이티브 iOS 및 Android 앱, 웹 앱 등 여러 프론트엔드가 각자의 플랫폼에서 실행되지만, 모두 데이터, 인증, 비즈니스 로직을 제공하는 하나의 공유 백엔드 API와 통신합니다. 프론트엔드 프레임워크 선택은 공유 백엔드와 독립적입니다.
  F1["크로스 플랫폼 앱<br/>(컴파일형 / 브리지)"] --> API[("공유 백엔드 API<br/>데이터 · 인증 · 로직")]
  F2["네이티브 iOS"] --> API
  F3["네이티브 Android"] --> API
  F4["웹 / PWA"] --> API
  API -.->|"플랫폼별 SDK"| SDK["하나의 백엔드,<br/>한 번만 작성"]
```

## 네이티브 vs. 크로스 플랫폼, 솔직한 비교

| | 크로스 플랫폼 프론트엔드 | 네이티브 프론트엔드 |
| --- | --- | --- |
| 코드베이스 | 하나, 약 90% 공유 | OS마다 하나 |
| 시간과 비용 | 약 30–40% 절감 | 두 플랫폼이면 기준선 ×2 |
| 성능 | 네이티브의 약 90–95% | 100% |
| UX 충실도 | 매우 좋음, 예외 상황에서 차이가 드러남 | 플랫폼에 완벽히 맞음 |
| 새 OS 기능 | 프레임워크 지원을 기다려야 함 | 즉시 사용 |
| 적합한 경우 | 일반적인 앱, MVP, 도달 범위 | 그래픽, AR, 깊은 하드웨어 활용 |
| **백엔드** | **공유** | **공유** |

마지막 행이 이 글의 요점 전부입니다. 프론트엔드 선택은 의도적으로 내려야 하는 진짜 UX 대 성능의 트레이드오프입니다. 하지만 *어느* 쪽을 고르든 백엔드는 한 번 작성되어 모든 클라이언트가 공유합니다. 즉, 크로스 플랫폼 개발에서 가장 어렵고 가장 가치 있는 재사용은 아무도 크로스 플랫폼이라고 부르지 않는 바로 그 재사용입니다.

## 백엔드가 크로스 플랫폼이 되는 방식: SDK와 API

메커니즘은 두 계층입니다. 백엔드는 [**플랫폼 중립적인 API**](/glossary/ko/api/)를 노출합니다. [REST와 GraphQL](/glossary/ko/rest-api/)은 무엇과도 JSON으로 대화합니다. 그리고 그 위에 API를 각 언어의 관용구로 감싸는 [**플랫폼별 SDK**](/glossary/ko/backend-sdk/)가 있습니다. iOS용 Swift SDK, Android용 Kotlin, 웹과 React Native용 JavaScript, Flutter용 Dart입니다. 모든 SDK는 같은 엔드포인트 위의 얇은 클라이언트이므로, *데이터 모델, 인증, 권한, 비즈니스 로직*은 서버에 한 번만 존재하고 모든 프론트엔드가 이를 물려받습니다. 이것이 [BaaS](/glossary/ko/baas-vs-custom-backend/)가 크로스 플랫폼 작업에 자연스러운 백엔드인 이유입니다. BaaS가 *곧* 공유 백엔드이고, SDK는 이미 작성되어 있습니다. [PWA](/glossary/ko/progressive-web-app-pwa/)는 또 하나의 크로스 플랫폼 전달 경로일 뿐입니다. 여러 플랫폼에 설치할 수 있는 하나의 웹 앱이 같은 백엔드와 통신합니다.

## 일반적인 사용 사례

- **스타트업과 MVP**: 하나의 팀과 하나의 일정으로 iOS와 Android를 모두 커버합니다.
- **콘텐츠 및 비즈니스 앱**: 90%의 코드 재사용이 그대로 절감으로 이어지는 일반적인 UI입니다.
- **멀티 플랫폼 제품군**: 하나의 백엔드 위에 모바일, 웹, 데스크톱 클라이언트를 둡니다.
- **백엔드를 공유하는 네이티브 앱**: 최고 성능의 프론트엔드, 그 뒤에는 하나의 API가 있습니다.
- **[PWA](/glossary/ko/progressive-web-app-pwa/)와 네이티브의 병행**: 웹의 도달 범위와 네이티브의 깊이를 같은 [백엔드](/glossary/ko/baas-vs-custom-backend/) 위에서 얻습니다.

## 크로스 플랫폼을 선택해야 할까? 결정 매트릭스

| 상황 | 권장 방향 |
| --- | --- |
| 예산/일정이 빠듯한 일반적인 앱 | 크로스 플랫폼 프론트엔드 |
| iOS와 Android 동시 출시 | 크로스 플랫폼 프론트엔드 |
| 그래픽, AR, 깊은 하드웨어 활용 | 네이티브 프론트엔드 |
| 플랫폼 쇼케이스 또는 최고 성능 | 네이티브 프론트엔드 |
| 위의 모든 경우 | **공유 백엔드**, 언제나 |
| 적은 예산으로 웹 도달 범위 확보 | 공유 백엔드 위의 [PWA](/glossary/ko/progressive-web-app-pwa/) |

## 한계와 트레이드오프

- **프론트엔드 프레임워크의 지연.** 새 OS 기능은 네이티브에 먼저 도착하고 크로스 플랫폼 프레임워크는 뒤따라옵니다. 출시 첫날부터 그 기능을 채택해야 하는 앱에는 실제 비용입니다.
- **마지막 몇 퍼센트의 성능.** 그래픽이 무겁거나 실시간성이 중요한 앱은 네이티브와의 격차를 체감합니다. 대부분의 앱은 결코 체감하지 않습니다.
- **UX 관례의 차이가 드러납니다.** 플랫폼별 제스처와 패턴은 "공유" UI 코드에서도 플랫폼마다 따로 신경 써야 합니다.
- **앱 크기와 의존성.** 크로스 플랫폼 런타임은 용량을 늘리고, 사용자가 통제할 수 없는 커뮤니티 유지보수 의존성을 더합니다.
- **이 중 어느 것도 백엔드에는 영향을 주지 않습니다.** 위의 모든 한계는 *프론트엔드*의 한계입니다. 공유 백엔드의 이득은 영향을 받지 않으며, 그래서 불확실한 프론트엔드 결정 속에서도 안전한 선택이 됩니다.

## Back4app에서의 크로스 플랫폼 개발

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이 글이 말하는 공유 백엔드를 그대로 구현한 것입니다. Back4app은 하나의 REST/GraphQL [API](/glossary/ko/api/) 위에 Flutter, React Native, iOS(Swift), Android(Kotlin), JavaScript용 [SDK](/glossary/ko/backend-sdk/)를 제공합니다. 그래서 코드 탭에서 본 것처럼 같은 쿼리, 같은 [인증](/glossary/ko/authentication-vs-authorization/), 같은 [ACL 규칙](/glossary/ko/access-control-lists-acl/)이 모든 클라이언트에 적용됩니다. 프론트엔드가 하나의 크로스 플랫폼 코드베이스이든 네 개의 별도 네이티브 코드베이스이든 마찬가지입니다. 프론트엔드 결정은 UX와 성능을 근거로 사용자가 내리면 됩니다. 백엔드는 어떤 경우든 한 번만 작성되며, 이것이 크로스 플랫폼에서 가장 가치 있으면서도 가장 덜 논의되는 이득입니다.