알고가자! 모바일 서비스 개발

글. 김상용 차장(코스콤 정보사업부)

스마트폰 대중화로 모바일 서비스가 사업 성패의 핵심요소로 자리잡은 시대가 되었다. 모바일 서비스를 어떠한 방향으로 구현할 지에 대한 설계, 그 자체가 사업 기획의 전부라 해도 과언이 아니다. 모바일 서비스를 구현하는 여러 가지 방법에 대해 알아보자.

1. 모바일 웹
스마트폰에서 브라우저를 열고, 주소를 입력해서 페이지를 확인하는 방법이다. PC용도로 만들어진 웹 화면을 모바일로 보게 되면, 화면이 작아서 글씨와 이미지 등이 매우 작게 보인다.

그래서, PC용 웹서비스와 모바일용 웹서비스를 구별하여 개발한다. 대표적인 모바일 웹서비스로는 네이버와 다음이 있다. 스마트폰 브라우저 주소창에 ‘www.naver.com’을 입력하면, 자동으로 ‘m.naver.com’이라는 모바일 웹서비스 주소로 재조회(Redirect)하도록 구성되어 있다. 웹서버에서 사용자의 브라우저가 PC 용도인지, 모바일 용도인지 구분할 수 있다.

반응형 웹이라고 해서 같은 웹 화면을 PC에서는 PC에 맞게, 모바일에서는 모바일에 맞게 자동으로 반응해서 디스플레이하는 방법도 있다.

똑같은 콘텐츠의 배열이 다르게 나타남을 확인할 수 있다. 하나의 웹 화면으로 PC와 모바일을 동시에 커버할 수 있다는 장점이 있지만, 콘텐츠가 복잡해지면 오히려 유지보수의 부담이 커지는 문제가 있어서 간단한 블로그형 웹페이지가 아니면 많이 쓰는 방식은 아니다.

모바일 웹 방식은 사용자가 브라우저에서 URL을 직접 입력해야 되는 불편함이 있고, 스마트폰 고유의 기능(카메라, 문자 등 기타 앱과의 연동)을 사용하지 못한다는 단점이 있다. 스마트폰 고급사용자라면, 자주 방문하는 사이트를 [홈화면에 추가하기]와 같은 스마트폰의 기능을 통해 단축 아이콘을 생성해서 앱처럼 사용할 수도 있지만, 대다수의 일반 스마트폰 사용자에게 이러한 방식을 강제하는 것은 쉬운 일이 아니다.

PWA(Progressive Web App)라고 해서 웹에서 직접 모바일 기능을 일부 사용할 수 있고, 앱아이콘과 동일한 단축아이콘도 자동 생성되는 방식의 모바일 웹 기술이 빠른 속도로 발전하고 있다. 아직 과도기적인 기술이고, 레퍼런스가 많지 않아서, PWA 방식으로 개발해야 할 필요가 있는 서비스의 경우, 아래에 있는 하이브리드 방식을 많이 선택하고 있다.

필요기술
모바일에 맞게 디자인하기 위해 모바일 전문 디자이너와 모바일에 맞게 웹 화면을 구성할 수 있는 모바일 전문 퍼블리셔가 필요. 반응형 웹 화면을 만들기 위해서 반응형 웹 화면 개발 경험이 있는 퍼블리셔도 별도로 필요하다. 그 외 프론트(화면 개발)와 백엔드(서버 개발) 기술은 PC 웹 개발과 다르지 않다. WEB, WAS, DB, 기타 인터페이스 등 개발구성이 필요하다.

2. 네이티브 앱
안드로이드 OS 전용 프로그램, iOS 전용 프로그램을 개발하는 방식이다. 당연히 모바일 웹 뿐만 아니라, 모바일 앱 중에서도 가장 높은 성능을 나타낸다. 그리고, 모바일의 모든 기능을 이용할 수 있다는 장점이 있다.
안드로이드 OS의 경우, 예전에는 Java를 많이 썼으나 오라클 라이센스 문제로 최근에는 Java와 거의 유사한 Kotlin이라는 언어를 사용해서 개발을 많이 하고 있다. iOS의 경우, 예전에는 Objective-C를 사용했으나, 최근에는 Swift라는 언어로 거의 대체되었다고 보면 된다.

성능, 기능 면에서 우월한 장점이 있음에도 불구하고, OS별로 개발을 해야 된다는 치명적인 단점이 있다. 안드로이드 OS 용도로만 만들어도 개발 및 유지보수에 상당한 자원이 소모되는데, iOS 용도로도 같은 자원을 투입해야 하니, 자원투입 면에서 부담이 아닐 수 없다. 그리고, 앱이 자주 변경되어야 한다면 매번 검수 후 배포를 해야 하고, 사용자는 매번 업데이트를 해야 하는 불편함도 있다. 당장 급하게 써야 되는데, ‘이 앱은 왜 접속할 때마다 업데이트를 하지?’라고 불편해한 경험이 한번쯤 있으실 거다. 배포정책에 대한 신중한 고려가 필요하다.

MTS(모바일 트레이딩 시스템)처럼 실시간 데이터를 안정적으로 수신해서 화면에 디스플레이 하거나 게임과 같이 극강의 사용자 경험이 필요한 앱의 경우 네이티브 앱으로 개발하는 것이 적당하다. 일부 콘텐츠(고객센터, 도움말처럼 변경이 잦은 화면 등)는 웹으로 구현할 수도 있다.
규모가 되는 앱의 경우에는 빠른 성능, 높은 사용자 경험을 위해서 대부분 네이티브 앱으로 개발하는 것이 보통이지만, 익히 알고 있는 앱 중에서 적당한 성능으로도 충분히 사용자 경험을 만족시킬 수 있고, 배포를 자주 해야 되는 업무 특성 등을 고려해서 아래의 다른 방법으로 개발하기도 한다.

필요기술
네이티브 앱은 웹처럼 화면·기능 수정이 용이하지 않기 때문에 특히 화면설계가 포함된 정교한 기획이 중요하다. 개발 전에 기획을 얼마나 꼼꼼히 하느냐가 전체 개발공수를 좌우하게 된다.
안드로이드와 iOS가 기본적으로 제공하는 UI컴포넌트가 다르기 때문에 일반적으로 OS별 디자이너가 필요하다(게임과 같이 OS가 제공하는 컴포넌트를 사용하지 않고, 모두 자체 제작하거나 별도 툴을 사용하는 경우, 안드로이드와 iOS에서 동일한 UI를 제공하는 경우 등은 예외).
웹과 달리 앱에서는 별도 퍼블리셔가 없다. 규모가 있는 개발회사의 경우에는 화면 개발자와 기능 개발자의 역할을 분담하기도 하지만, 대부분 프론트 개발자가 화면과 기능을 함께 개발한다. 화면개발이 웹처럼 용이하지 않기 때문에 단위화면 당 개발공수가 많이 든다. 이 부분이 네이티브 앱 개발 비용 증가의 가장 중요한 원인이 된다. 디자인을 코드로 변환해주는 솔루션 도입을 검토할 수 있으나 OS, 개발환경 등의 변화속도를 솔루션이 쫓아가지 못하는 경우가 많고, 솔루션이 제공하지 않는 UI/UX 구현이 어려울 수도 있다. 그래서, 솔루션 도입은 신중하게 결정해야 한다.
백엔드는 WEB API 방식, TCP서버 방식 등 여러 가지 구성이 가능하다. 앱 개발 역량에 맞춰 결정해야 한다. 안드로이드는 Kotlin, iOS는 Swift 개발자를 추천한다.

3. 하이브리드 앱
일부는 웹, 일부는 네이티브 앱으로 개발하는 방식이다. 하이브리드 앱과 네이티브 앱의 구분이 모호할 경우가 있는데, 주요 비즈니스가 웹에서 일어난다면 하이브리드, 앱에서 일어난다면 네이티브로 구분한다.

앱의 틀만 네이티브 앱으로 개발하고, 콘텐츠는 모두 웹으로 개발한다(네이티브 앱에서도 일부 콘텐츠를 웹으로 구현 가능). 개발 및 유지보수 작업에서 네이티브 앱의 비중이 매우 적기 때문에 하나의 웹 개발로 여러 OS 콘텐츠를 함께 커버할 수 있고, 웹 화면 변경은 배포가 필요하지 않다는 장점이 있다. 앱 화면 개발보다 웹 화면 개발이 용이한 부분이 많기 때문에 고성능이 반드시 필요한 경우가 아니라면, 개발 및 유지보수 비용 절감이라는 측면에서 많이 선택되는 개발 방식이다.

앱과 웹을 연결하는 브릿지라는 기능을 통해 WEB과 APP 상호간 데이터를 교환해서 모바일의 기능을 사용할 수 있다. 웹의 사용자 경험/성능 등이 갈수록 진화하고 있기 때문에, 사용자는 이 앱이 하이브리드 방식인지, 네이티브 방식인지 느끼지 못할 정도로 잘 만들어진 앱들이 많이 있다. 다만, MTS(모바일 증권거래 앱)와 같이 실시간 데이터를 많이 수신해서 디스플레이 해야 되는 서비스의 경우 브릿지 상의 데이터 교환 시 웹부분에서 병목현상이 발생할 수도 있다.

필요기술
모바일 웹서비스 개발과 같은 인력구성이 필요하다. 그리고, SNS로그인, 이미지 업로드 등 모바일 기능을 써야 되는 상황이 항상 발생하기 때문에 앱을 관리할 수 있는 앱 개발자도 필요하다. 웹 개발자와 앱 개발자는 웹-앱 간의 브릿지 구현에 대한 경험이 필요한데, 안드로이드는 Kotlin, iOS는 Swift 개발자를 추천한다. 대부분의 콘텐츠/기능 변경이 웹 화면에서 일어나기 때문에, 배포 사이클을 효율적으로 관리할 수 있다.

4. 크로스플랫폼 앱
네이티브 앱의 경우 OS 별로 별도의 프로그램을 개발하고 운용해야 한다는 것은, 자원 투입면에서 상당한 부담이 아닐 수 없다. 스타트업 뿐만 아니라, 일정 규모의 매출이 발생하는 회사에서도 부담스럽기는 마찬가지다. 크로스플랫폼 앱은, 성능은 네이티브 앱과 비슷하게 유지하면서, 하나의 코드로 개발하고 컴파일만 OS별로 다르게 하여 배포하는 방식이다.

OS에 특화된 API, UI 등을 사용해야 하는 경우에는, OS별로 네이티브 모듈을 개발해서 프로젝트에 삽입하고 컴파일만 다르게 진행할 수도 있다.
Facebook이 개발을 주도하는 React Native와 Google이 개발을 주도하는 Flutter가 양대 산맥을 이루고 있다. 네이티브 앱처럼 모바일OS가 제공하는 기능을 100% 사용하기에는 아직 부족한 부분이 많지만, 플러그인들이 지속적으로 개발되고 있다.

React Native와 Flutter의 작동방식에는 상당한 차이가 있다.

React Native는 모든 OS와의 통신을 브릿지를 통해 처리하기 때문에 빠른 응답이 필요한 UI/UX 측면에서 성능이슈가 발생할 수 있다. 반면 Flutter는 UI의 경우 Skia라는 그래픽 라이브러리를 통해 직접 렌더링하기 때문에 네이티브 앱과 거의 비슷한 수준의 성능을 낼 수 있다.

필요기술
기술적으로 두 프레임워크의 장단점에 대해 비교할 내용이 많지만, 지면 관계상 생략한다. 다만, React JS 개발자가 있고, Legacy시스템이 React Native로 개발되어 있는 경우가 아니라면, Flutter를 추천한다.
화면개발이 웹만큼 용이하지는 않지만, 네이티브 앱보다는 많이 개선되고 있는 과도기적 상태다. 생산성은 네이티브 앱보다 훨씬 높다는 이야기가 현장에서 나오고 있다. React Native로 개발하려면, 자바스크립트 및 React Js 고급 개발자가 필요하다. Flutter로 개발하려면, 아직 레퍼런스가 많이 없다는 단점이 있기 때문에, Dart언어 및 Flutter 프레임워크 개발 경험이 있거나 Dart 언어가 Java 최신 버전과 문법이 많이 유사하기 때문에 Java 고급 개발자가 반드시 필요하다.

5. 결론
각각의 개발방식 마다 장단점이 있다. 모바일 웹 만으로 서비스하는 것은 추천하지 않는다. 보조수단으로 서비스할 수는 있지만, 앱의 형태로 배포되지 않으면 사용자 접근성이 너무 떨어지기 때문이다.
웹 개발자가 많이 확보된 상태라면, 최대한 하이브리드 앱 형태로 개발하는 것을 추천한다. 모바일 개발자를 최소한으로 확보해서 MVP(Most Viable Product: 생존가능한 최소한의 제품)를 오픈해보고, 피드백을 받으면서 사업가능성을 살펴본 후에, 보다 높은 성능이 요구된다면, 크로스플랫폼이나 네이티브 앱으로 전환하는 것이 사업 리스크를 최대한 줄이는 방법이라 할 것이다.

신규로 팀을 꾸리는 단계라면, 크로스플랫폼으로 MVP를 만들어볼 것을 추천합니다. 게임과 같은 극강의 성능을 요구하는 앱이 아니라면, Flutter나 React Native로 충분히 기대한 성능의 앱을 만들 수 있다. 개발 생산성 측면에서는 크로스플랫폼이 네이티브 앱보다 훨씬 낫다는 의견이 지배적이다.
모바일이 작기 때문에 개발 비용도 적게 들고, 쉬울 거라 생각하는 이들이 있다. 하지만 모바일 개발은 비용이 많이 든다. 다른 서비스 개발도 마찬가지지만, 서비스의 방향을 쉽게 바꿀 수도 없다. 최대한 기획을 구체적으로 진행해야 된다. 화면설계, 사용자의 동선, 기능 등이 충분히 반영된 기획이 완료되면, 최소한의 인력으로 MVP를 개발해서 피드백을 받아봐야 한다. 이후, 사업성이 증명되었다면, 그때 인력을 충원해도 늦지 않다.