최소한의 IT언어

- NIST가 정의한 클라우드 컴퓨팅의 5가지 기본적 특성은 다음과 같다.
* 즉시적이고 자율적인 이용: 고객이 언제든 클라우드의 자원과 소프트 웨어를 이용할 수 있다. 예를 들어 Salesforce.com은 인터넷에 연결된 컴퓨터와 아이디, 비밀번호만 있으면 바로 사용 가능하다.
* 폭넓은 네트워크 접근: 고객이 다양한 플랫폼(태블릿, 스마트폰, 노트북등)으로 자원과 소프트웨어를 이용할 수 있다.
* 자원 병합: 클라우드에 속한 컴퓨터들이 서로 연계해서 다수의 사용 자를 지원하고, 단일한 컴퓨터로는 해결할 수 없는 복잡한 문제를 해 결한다.
* 신속하고 탄력적인 성능 조정: 클라우드에 속한 컴퓨터들이 네트워크 에서 서로 통신하므로, 그중 일부 컴퓨터에 과도한 트래픽이 몰리면 다른 컴퓨터들이 트래픽을 분담할 수 있다. 다시 말해 상황에 맞춰 신 속하게 성능을 상향하거나 하향한다.
* 종량제: 종래의 소프트웨어 모델은 고객이 일정한 금액을 지불하고 프로그램을 설치해서 사용하는 방식이다. 그래서 어떤 프로그램을 시 험 삼아 써보려는 사람도 그 프로그램을 지속적으로 사용하는 사람과 동일한 요금을 지불해야 했다. 하지만 이제는 저장 공간, 연산 능력, 트래픽, 대역폭 등을 기준으로 고객의 사용량을 측정할 수 있다. 사용 량에 따라 요금을 차등적으로 부과할 수 있어서 더 효율적인 시장이 형성된다.
-  다음은 NIST에서 정의한 클라우드 컴퓨팅의 3가지 서비스 모델이다.
* 서비스형 소프트웨어SaaS, Software as a Service: 드롭박스처럼 사용자가 브라우저로 이용할 수 있는 애플리케이션은 모두 SaaS (사스)에 해당 한다. SaaS는 6장에서 살펴볼 API와도 관련이 있다. SaaS는 클라우드로 제공되기 때문에 사용자의 컴퓨터에 애플리케이션을 설치할 필요가 없다. 그래서 멀티테넌트 아키텍처 multi-tenant architecture (테넌트, 즉 사용자들이 애플리케이션을 각자 실행하지 않고 한 번 실행한 것을 다 수가 함께 사용하는 구조-옮긴이)라고 할 수 있다.
* 서비스형 플랫폼PaaS, Platform as a Service: 헤로쿠 같은 프래그래밍 용 클라우드 플랫폼을 이용해본 사람이라면 익숙한 개념일 것이다. PaaS(패스)는 사용자가 소프트웨어를 빌드(소스코드를 실행 가능한 형 태로 변환하는 것-옮긴이)할 수 있는 환경을 제공한다. 예를 들면 웹 애플리케이션을 빌드할 수 있는 웹 서버를 제공한다.
* 서비스형 인프라 IaaS, Infrastructure as a Service: 클라우드가 급속도로 성장하면서 클라우드에서 웹사이트를 호스팅하는 클라우드 인프라 사업이 부상했다. IaaS(이아스)를 이용하면 웹사이트를 훨씬 효율적으로 운영할 수 있다.
예를 들어 웹사이트에서 이벤트를 실시하면 갑작스럽게 트래픽이 많이 발생한다. 그러면 예전에는 접속자가 최고로 몰릴 때를 대비 해서 서버를 증설해야 했다. 하지만 접속자가 다시 평소 수준으로 줄어들면 증설한 서버가 노는데 운용 비용은 계속 나간다. 이 문제의 해법이 클라우드다. 클라우드를 이용하면 필요에 따라 쉽게 서버 사용량을 늘리거나 줄일 수 있기 때문에 사용한 만큼만 비용을 지불하면 된다.
- 자바스크립트
HTML과 CSS만 써서 만든 웹사이트는 보기에는 좋아도 상호작용성이 부족하다. 그래서 드롭다운 메뉴(화면에 표시된 주 메뉴를 선택하 면 아래에 하위 메뉴가 펼쳐지는 형태의 메뉴-옮긴이), 마우스 커서를 대면 나오는 설명문을 비롯해 많은 요소를 조작할 수 있게 해주는 자 바스크립트 JavaScript가 필요하다. 객체 지향 스크립트 언어 (3장)인 자 바스크립트는 HTML 문서 안에 존재하고 브라우저(사이트에 접속하 는 '클라이언트)에 의해 렌더링된다. 즉, 클라이언트 사이드client-side에 서 처리된다. 그래서 다른 스크립트 언어들과 달리 백엔드가 아닌 프 런트엔드로 취급된다. 서버에서 실행되지 않는 것이다.
- 어떤 작업을 구성하는 일련의 요청을 트랜잭션 transaction이라고 한다. 예를 들면 사용자와 반려동물을 등록하기 위해 필요한 요청들이 트랜잭 션이 될 수 있다. 트랜잭션에는 중요한 성질이 몇 가지 있는데 관계 형 시스템에만 국한된 내용은 아니지만 여기서 간단히 설명하고 넘 어가겠다. 첫째, 트랜잭션은 '원자성'이 있다. 처음부터 끝까지 완전 히 수행되지 않으면 무효화된다는 뜻이다. 예를 들어 사용자가 완전 히 등록되지 않으면 데이터베이스에는 아무 변화가 생기지 않는다. 그래서 어떤 프로세스가 어떤 이유로든 도중에 중단돼도 불완전한 행이 생기거나 레코드가 일부만 갱신되는 식으로 테이블이 변질되지 않는다. 둘째, 트랜잭션은 '지속성'이 있다. 트랜잭션이 완료되는 즉시 데이터베이스에 변화가 생기고 그 변화의 결과가 지속된다는 의미다. 만일 트랜잭션이 데이터베이스에 반영될 때 시간이 지연된 다면 UX에 악영향을 미칠 것이다. 간단한 예로 페이스북에서 친구 를 추가할 때마다 친구 목록이 갱신되기까지 일주일이 걸린다면 어 떻겠는가? 셋째, 트랜잭션은 '독립성'이 있다. DBMS에서 각각의 트 랜잭션이 별개로 취급된다는 뜻이다. 이런 성질을 모두 갖춘 데이터 베이스를 설계하기가 쉽진 않지만, 지금 설명한 내용을 잘 알아두면 DBMS가 요청을 취급하는 방식을 더 쉽게 이해할 수 있다.
마지막으로 설명할 용어는 정규화normalization다. 정규화는 데이 터베이스에서 중복을 없애는 것이다. 다시 사용자 테이블과 반려동 물 테이블을 생각해보자. 만약 개발자가 반려동물 테이블에 주인 주 소라는 열을 만든다면 어떻게 될까? 그것은 이미 사용자 테이블에 저장돼 있는 정보가 아닌가? 그렇다면 주인 주소 열은 중복되는 정 보로 공간을 낭비하는 셈이다. 정규화는 데이터베이스가 사용하는 메모리를 절약하는 효과가 있지만, 질의의 결과가 도출되는 시간을 늘리는 부작용을 낳을 수도 있다. 앞에서 비단뱀을 키우는 사람들의 주소를 묻는 질문을 예로 들었는데(JOIN 사용) 만일 그 질문을 자주 해야 한다면 또 상황이 달라질 것이다. JOIN 명령어로는 DBMS가 두 테이블을 합친 후 정보를 찾아야 하기 때문에 테이블의 크기에 따 라서 시간이 많이 소요되기도 한다. 그래서 차라리 중복되는 열을 만 드는 것이 더 간편하고 경제적일 수 있다. 이런 사안을 두고 결정을 내리는 주체는 데이터베이스에서 요청이 어떻게 처리되는지를 정확 히 이해하는 데이터베이스 관리자 DBA, DataBase Administrator다.
- 분산 시스템의 대표적인 특징은 로컬 자율성(각 서버가 독립돼 있다), 중앙 서버의 부재, 로컬 독립성(사용자는 데이터가 어디에 저장되는지 알 필요가 없다)이다. 그 외에도 많은 특성이 사용자에게 중앙집 중식 시스템과 똑같이 작동한다는 느낌을 준다.
IT업계에서 '분산'이라는 말이 인기인 데서 짐작할 수 있듯이 분산 데이터베이스도 인기가 많다. 다음과 같은 장점 때문이다.
* 우월한 합리성 : 대부분의 조직에서는 이미 데이터가 각 지역 사무소나 각 부서에 논리적으로 분산돼 있다. 그러니까 그 밖의 장점들도 매력적이라면 분산 데이터베이스를 굳이 거부할 이유가 있을까? 분산 데이터베이스를 구축하면 번거롭게 모든 데이터를 중앙 서버에 집중 할 필요가 없으며 각 집단이 자신들의 데이터만 잘 관리하면 된다. 예 를 들어 펩시 아시아에서는 일부 데이터를 아시아에 보관하는 것이 합리적이다.
* 효율과 성능 향상: 그냥 생각해봐도, 어떤 요청이 들어왔을 때 되도록 가까운 곳에서 데이터를 처리하는 게 효율이 좋다. 그래서 데이터는 그것을 가장 많이 사용하는 사람들과 가까운 장소에 보관돼야 한다. 분산 데이터베이스를 구축하면 전 조직의 데이터를 가장 효율적으로 분배할 수 있다. 그리고 질의가 여러 기기에 분산돼서 처리되기 때문에 속도가 빨라진다.
* 안정성 향상: 정보가 여러 컴퓨터에 저장되기 때문에(사본이 여러 개 만들어질 수도 있다) 중앙집중식에 비해 시스템이 일제히 다운될 확률이 훨씬 낮다.
* 탄력적 확장: 분산 데이터베이스는 수평 확장성이 있다. 즉, 데이터베 이스에 컴퓨터를 추가하기 쉽다. 예를 들어 현재 마이애폴리가 컴퓨 터 다섯 대에 정보를 저장한다고 해보자. 그중 한 대에 메모리를 추가 하는 등의 수직 확장보다는 컴퓨터를 한 대 늘리는 수평 확장이 훨씬 수월하다. AWS (2장) 같은 서비스는 고객이 그때그때 필요에 따라 서 버를 늘리고 줄이므로 엄청난 인기를 끈다. 그렇게 탄력적으로 서버 의 수를 조절하면 더 효율적으로 자원을 활용할 수 있다. 반대로 어쩌 다 한 번씩 서버 사용량이 급증하는 예외적 상황(예: 웹사이트 이벤트기간)에 대비해서 서버를 대량 구입하는 것은 비효율적이다.
- 분산 데이터베이스라고 단점이 전혀 없진 않다. 첫째, 데이터가 여러 곳에 저장되기 때문에 질의를 처리하기 위해 곳곳의 데이터를 종합해야 할 때는 시간이 더 걸릴 수 있다. 둘째, DBMS가 제공하는 다양한 기능(보안, 동시성 관리 등)을 사용하려면 중앙집중식에 비해 복잡한 기술이 필요하다.
- 당신이 방대하고 다양성이 큰 데이터를 보유했다고 해보자. 이 데이터를 그냥 보는 것만으로 뭔가 의미 있는 시사점을 얻을 확률 은 희박하다. 데이터에서 어떤 명백한 패턴이 보이지 않는다면 더 욱 그렇다. 당신이 빅데이터를 취급하다 보면 자연스럽게 접하게 되 는 용어가 하둡 Hadoop이다. 하둡은 어떤 질문의 답을 얻기 위해 데이 터를 테스트하게 해주는 소프트웨어 프레임워크(특정한 작업을 용이 하게 하는 요소들을 모아놓은 것옮긴이)다. 앞에서도 말했지만 방대 한 정보를 저장하고 처리할 때는 분산 시스템이 유용하다. 하둡은 다 수의 고성능 프로세서가 데이터를 분담해서 처리하도록 만든다. 하 둠에서 주로 사용되는 방식인 맵리듀스 MapReduce는 맵과 리듀스라는 두 단계로 구성된다. 당신이 데이터를 분석하여 어떤 질문의 답을 얻 기원하고, 그래서 엔지니어들이 이론상으로 봤을 때 정답을 구할 수 있을 것으로 보이는 함수를 작성한다고 가정해보자. '맵' 단계에서는 분석 작업이 여러 부분으로 분할돼 다수의 기계에 배정된다. 이어서 '리듀스' 단계에서는 각 기계에서 도출된 결과가 하나로 결합돼 분석 이 완료된다. 방대한 데이터를 기계 한 대로 분석하자면 오랜 시간이 걸리겠지만, 하둡은 분할정복 전략으로 시간을 단축한다. 하둡 외에 아파치 스파크Apache Spark도 인기를 끌고 있다.- 코드를 조직할 때 가장 흔하게 사용되는 구조는 다층 아키텍처다. 그중에서도 3계층 아키텍처3-tiered architecture가 제일 많이 쓰인다. 3계층 아키텍처는 3~5장의 내용에 부합한다. 3계층 중 한 층은 데이 터베이스와 관련된 부분을 처리하며 '모델'이라 불린다(5장), '컨트 롤러'라는 중간층은 백엔드, 즉 프로그램의 논리적 흐름을 처리한다 (3장). 그리고 사용자에게 표시되는 것을 담당하는 층을 '뷰' 또는 '프 레젠테이션'이라고 부른다(4장). 이 외에도 여러 가지 아키텍처가 존 재하지만 여기서는 각각의 차이점을 논하지 않고 애초에 그런 아키 텍처들이 왜 존재하는지를 설명하려고 한다.
아키텍처가 존재하는 이유는 첫째, 병렬 작업에 유리하기 때문 이다(이런 코드 설계 원리를 흔히 관심사 분리 separation of concerns라고 말 한다). 마이애폴리 팀에서 뷰, 컨트롤러, 모델을 전담하는 엔지니어가 따로 있다고 해보자. 그러면 컨트롤러 엔지니어는 모델 엔지니어에 게 "방법은 아무래도 좋으니까 내가 사용자 이름만 받을 수 있게 해 줘”라고 말할 수 있다. 다시 말해 뷰 엔지니어와 컨트롤러 엔지니어 는 데이터베이스에 들어가서 이름을 가져오는 코드를 고민할 필요 없이, 당연히 이름을 가져올 방법이 존재하리라 가정하고 자신의 코 드를 작성할 수 있다. 그리고 모델 엔지니어는 두 엔지니어에게 간단 한 방법만 알려주면 된다. "사용자 이름이 필요하면 getUserName 함 수를 호출해 사용자의 위치가 필요하면 getUserLocation을 호출하 고.” 구체적으로 데이터베이스를 조작하는 코드는 모델 엔지니어가 자유롭게 작성하면 된다. 이렇게 애플리케이션을 구성하는 세 영역의 엔지니어들이 다른 영역의 코드에 신경을 안 써도 되면 각 영역을 비교적 독립적으로 개발할 수 있다.
아키텍처가 필요한 이유는 둘째, 유지보수에 유리하기 때문이 다. 예를 들어, 컨트롤러 엔지니어가 모델 엔지니어에게 사용자의 이 름, 주소, 우편번호가 필요하다고 말했다고 하자. 모델 엔지니어는 데이터베이스에서 각각의 정보를 가져오는 함수를 하나씩 만들어 컨트롤러 엔지니어에게 알려준다. 그러면 컨트롤러 엔지니어는 그 함수로 얻은 정보를 활용한 결과물을 뷰 엔지니어에게 보내서 화면 에 표시되게 한다. 석 달 후 엔지니어들은 데이터베이스에서 정보를 가져오는 모델 코드가 비효율적이라고 판단한다. 하지만 뷰 엔지니 어와 컨트롤러 엔지니어는 아무것도 건드릴 필요가 없다. 모델 엔지 니어가 자신의 함수만 개선하면 된다. 이때 만일 명확한 아키텍처가 없다면 데이터베이스 코드가 아무 파일에나 들어갔을 수 있다. 그렇 다면 해당 코드를 찾아서 수정하기가 훨씬 어려울 것이다.
아키텍처의 존재 이유 중 세 번째는 코드 재사용에 유리하기 때문이다. 뷰 엔지니어가 모든 페이지에 사용자 이름을 표시하려 한다고 해보자. 만일 페이지마다 데이터베이스에서 이름을 가져오는 코 드가 따로 작성돼 있다면 일일이 다 수정하느라 애를 먹을 것이다. 하지만 이미 getUserName 함수가 존재하므로 그것을 쓰면 된다. 이 런 추상화를 통해 엔지니어들은 코드를 더 효율적이고 경제적으로 작성할 수 있다.
이 세 가지 장점이 합쳐져서 만들어내는 효과는 명확하다. 바로 개발 시간 단축이다. 제품의 개발과 보수에 들어가는 시간이 짧아지 면 그만큼 많은 시간을 더 수익성 좋은 활동에 투입할 수 있다.
- 자바스크립트 태깅
자바스크립트 태깅이 등장하면서 웹 애널리틱스의 성격이 바뀌었다. 앞에서 자바스크립트를 이용해 특정한 이벤트가 발생했을 때 정해진 코드를 실행할 수 있다고 했다. 예를 들면 사용자가 어떤 버튼을 클릭했을 때 팝업창을 띄우는 것이다. 마찬가지로 '페이지 로딩 완료' 이벤트가 발생했을 때 특정한 코드를 실행할 수 있다. 이 코드 로 사용자 정보, 시간, 웹페이지 설명을 수집한다면 자바스크립트를 애널리틱스 도구로 이용할 수 있을 것이다. 실제로 그렇다. 방법도 간단해서 페이지를 다 불러왔을 때 실행할 자바스크립트 코드만 넣 으면 끝이다. 혹시 캐시 페이지가 열린다고 해도 사용자에게 표시되 는 시점에 자바스크립트가 실행되므로 웹로그보다 좋다. 그리고 특 별한 태그를 넣은 자바스크립트 코드는 차후에 데이터를 필터링할 때 요긴하게 쓰인다.
이상이 간단한 설명이고 여기에 쿠키가 더해지면 이야기가 좀 더 복잡해진다. 웹사이트는 당신이 접속해서 무엇을 클릭했는지부터 시작해 당신과 관련된 정보를 브라우저에 저장하는데 이를 쿠키 cookie라고 부른다. 그래서 다음번에 다시 당신이 접속하면 웹사이트 는 브라우저에 쿠키가 있는지 확인한 후 쿠키가 있으면 당신이 이미 왔다갔던 사람임을 인지하고, 쿠키 내의 정보를 이용해 페이지를 당 신에게 맞춰 커스터마이징한다. 만일 쿠키에 당신이 알아보는 신발 에 대한 정보가 저장돼 있다면 다음번에 접속했을 때는 페이지 상단 에 그 신발이 표시될 수 있다. 다시 애널리틱스 이야기로 돌아가자면 자바스크립트 코드는 쿠키를 이용해서 사용자의 활동을 로그에 기 록한다. 브라우저에 쿠키를 저장한 후 코드의 나머지 부분이 다 실행 되면 그 정보를 서버에 보내서 저장한다. 이 서버는 웹사이트를 운영 하는 회사 혹은 별도의 애널리틱스 서비스 업체가 보유한 것이다.- 예전에는 사내의 IT 부서에서 애널리틱스를 전담했지만 요즘은 전문적인 애널리틱스 서비스가 존재한다. 이런 서비스에서 제공하 는 자바스크립트 코드만 웹사이트에 넣으면 나머지는 그쪽에서 다 알아서 한다. 애널리틱스 서비스에는 시각화 도구를 이용해 데이터 를 더 쉽게 이해하게 해준다는 장점도 있다. 대표적인 서비스가 구글 에서 무료로 제공하는 구글 애널리틱스Google Analytics다. 구글 애널 리틱스는 로그 파일에 데이터를 저장한다. 그리고 몇 시간마다 로그 파일을 분석해서 사용자가 볼 수 있는 데이터로 가공한다. 이 데이터 는 구글 애널리틱스 웹사이트에 접속해야 볼 수 있다.
이런 방식은 여러 가지 장점이 있는데 무엇보다 편의성이 좋다. 서비스 업체에서 제공하는 코드를 복사해 붙이기만 하면 바로 추적 및 시각화 시스템이 작동한다.
하지만 요즘은 자바스크립트를 차단하는 사용자들이 있기 때문 에 어느 정도는 데이터 손실을 감수해야 한다. 그리고 애널리틱스 서 비스를 이용하면, 다시 말해 직접 애널리틱스 정보를 수집해서 분석 하지 않으면 마이애폴리의 귀중한 데이터가 타인의 손에 들어간다 는 사실도 명심해야 한다.
- 패킷 스니핑
패킷 스니핑packet sniffing은 쉽게 말해 마이애폴리의 접속자와 마이애폴리를 호스팅하는 서버 사이에 중개인을 두는 것이다. 사용자가 마 이애폴리의 첫 화면을 요청하면 특수한 소프트웨어와 하드웨어의 결합체인 '패킷 스니퍼'를 거쳐서 요청이 전송된다. 패킷 스니퍼는 중간에서 사용자에 대한 정보를 저장한 후 다시 서버로 보낸다. 그리고 서버가 응답으로 보내는 웹페이지 파일도 패킷 스니퍼를 경유해 서 사용자에게 전달된다. 쉽게 말해 패킷 스니퍼는 사용자 데이터가 지나갈 때 그것을 저장하고 웹페이지 정보가 지나갈 때 또 그것을 저 장한다.
패킷 스니퍼의 장점은 웹사이트 소스코드에 별도의 코드를 추 가할 필요가 없고 서버에 전달되는 모든 요청을 가로채 웹사이트에 서 일어나는 활동 전반을 분석할 수 있다는 점이다. 하지만 초기에 설치하는 과정이 까다로울 수 있고 웹사이트의 캐시 버전으로 전달 되는 요청은 기록되지 않는다. 또 패킷 스니퍼는 사용자의 비밀번호 와 신용카드 번호 같은 민감한 데이터도 가로채므로 주의해야 한다. 이런 데이터를 취급할 때는 개인정보 보호에 각별히 신경써야 한다.
- 웹앱
모바일 웹 애플리케이션은 사용자가 사파리나 크롬 같은 웹브라우 저로 URL을 열어서 사용하는 웹 애플리케이션이기 때문에 세 유형 중에서 데스크톱 웹 애플리케이션과 가장 유사하다. 보통은 모바일 웹사이트라는 더 친숙한 이름으로 불린다. 그리고 많은 제품이 데스 크톱 웹 애플리케이션과 동일한 백엔드에 프런트엔드만 바꿔서 쓴 다. 아니면 아예 데스크톱과 모바일에서 모두 사용 가능한 반응형 웹 사이트를 만드는 경우도 있다. 반응형 웹사이트는 화면 크기에 따라 표시 방식이 달라지기 때문에 태블릿이나 가로로 돌린 화면에서도 잘 표시된다. 화면 크기에 맞춰 요소들이 자동으로 커지거나 줄어들고, 사라지고 이동함으로써 쾌적한 UX를 만든다.
- 모바일 웹사이트는 데스크톱 웹사이트를 토대로 비교적 쉽게 개발할 수 있지만 기기에서 바로 작동하지 않고 브라우저 안에서 작동하기 때문에 속도가 느리다. 더군다나 기기에 내장된 기능을 사용 하는데 제약이 있기 때문에 모바일 앱 특유의 강력한 기능을 구현하기 어렵다. 그래서 많은 기업이 독립된 모바일 애플리케이션을 개발 하는 쪽으로 방향을 전환했다.
- 네이티브 앱
네이티브 앱은 폰의 운영체제에서 바로 작동한다. 가장 많이 쓰이는 운영체제는 각각 구글과 애플이 개발하는 안드로이드와 iOS 다. 간혹 윈도우나 리눅스 기반 운영체제가 설치된 폰도 있지만 대다수는 안 드로이드 아니면 iOS다. 네이티브 애플리케이션은 대개 앱스토어에 서 다운받고 화면에 아이콘으로 표시된다. 굳이 브라우저를 거치지 않고 폰에서 바로 구동되기 때문에 모바일 웹 앱보다 속도가 빠르다. 개발자들이 네이티브 애플리케이션을 만드는 이유는 무엇보다 도 카메라와 GPS처럼 기기에 내장된 기능을 쉽게 활용할 수 있기 때 문이다. 이런 기능은 외부의 백엔드나 API와 달리 오프라인 상태에 서도 이용 가능하기 때문에 애플리케이션 역시 오프라인에서 구동된다. 네이티브 앱은 기기의 저장 공간에 전용 데이터베이스를 저장 해놓을 수 있다. 그러면 사용자의 상호작용을 추적하고 저장하며, 인 터넷에 접속하지 않아도 기기에 담긴 사진이나 메모 같은 콘텐츠를 제공할 수 있다. 갤러리 앱이나 음악 플레이어가 좋은 예다.
그리고 이런 로컬 데이터베이스는 개인 맞춤 콘텐츠를 제공할 때도 요긴하게 사용된다. 데스크톱 웹 애플리케이션도 개인화를 위 한 정보를 저장할 수 있지만 보통은 아이디를 기준으로 한다. 예를 들면 아이디에 구매 이력을 연결하는 식이다. 사람들이 브라우저나 컴퓨터를 하나만 쓰지 않기 때문에 어쩔 수 없는 조처다. 하지만 폰 은 보통 하나씩만 쓴다. 그러니까 모바일 애플리케이션은 번거로운 가입과 로그인 절차가 대부분 없다. 이는 신규 사용자를 유치하는 데 도움이 된다.
끝으로 네이티브 앱은 웹 앱보다 보안성이 강하다. 모바일 운영체제에서 모바일 웹사이트에는 제공하지 못하고 독립 앱에만 제공 할 수 있는 보안 기능을 갖추기 때문이다. 그리고 애초에 앱스토어에 등록되려면 심사를 거쳐야 하는 반면 모바일 웹사이트에는 그런 절 차가 없다." 하지만 또 한편으로는 네이티브 앱이 모바일 웹사이트 보다폰의 내장 기능을 더 많이 이용하기 때문에 공격자들에게 더욱 좋은 먹잇감이 될 수 있다. 물론 모바일 앱과 모바일 웹 앱 모두 해킹 의 위험성이 존재하므로 어느 쪽을 선택하든 보안에 각별히 신경써야 한다.
- 하이브리드 앱
모바일 애플리케이션의 마지막 유형은 네이티브 앱과 웹 앱을 혼합한 하이브리드 앱이다. 하이브리드 앱도 모바일 웹사이트처럼 웹브 라우저로 구동되지만 웹뷰web view를 통해 브라우저가 앱에 내장된 다는 차이점이 있다. 브라우저를 쓰기 때문에 네이티브 애플리케이 션만큼 빠르진 않아도 그와 비슷하게 카메라와 GPS 같은 내장 기능 을 사용할 수 있다. 그리고 앱스토어에 등록되고 폰 화면에 독립된 아이콘으로 표시된다. 하이브리드 앱은 데스크톱 웹 기술을 사용해 서 개발할 수도 있기 때문에 이미 데스크톱 웹 앱이 존재한다면 개발 이 용이하다.
이렇게 기기에 내장된 기능을 이용할 수 있고 개발이 수월하다 는 장점과 별개로 하이브리드 앱은 태생적 한계가 존재한다. 일단 웹 뷰를 이용하기 때문에 느리고 내장 기능을 전부 이용하진 못한다. 그리고 웹뷰가 웹 기술이기 때문에 기기 자체의 설계 원칙을 다 준수할 수도 없다. 설령 그 원칙을 모두 지키는 것이 가능하다고 해도 실천 하기는 어렵다. 그래서 많은 기업이 초기에 우선 가벼운 앱이라도 만 들기 위해 하이브리드 애플리케이션을 개발한 후 장기적으로 네이 티브 애플리케이션으로 전환하는 방식을 택한다. 그리고 웹 개발 경 험은 있지만 모바일 플랫폼 쪽으로는 전문성이 부족할 때나 속도를 좀 손해 봐도 되는 단순한 앱을 개발할 때도 하이브리드 앱이 좋은 선택이 될 수 있다.
- 크로스플랫폼 개발
완전한 네이티브 앱을 만들면 최고의 성능을 낼 수 있겠지만 안드로이드와 iOS 양 진영에 네이티브 앱을 내놓고 유지하려면 개발비가 꽤 많이 든다. 서로 개발 언어가 다르고 앱을 수정할 때마다 업데이 트와 테스트도 플랫폼별로 실시해야 하기 때문이다. 그래서 크로스 플랫폼 cross-platform 솔루션의 인기가 높아지고 있다. 크로스플랫폼 모바일 개발은 단일한 앱이 여러 모바일 운영체제에서 돌아가게 만 드는 것이다. 시중에 크로스플랫폼 모바일 개발을 지원하는 프레임 워크들이 나왔고 그중에는 자바스크립트 같은 웹 기술만으로 코드 를 작성할 수 있는 프레임워크도 많다. 이런 프레임워크를 이용해 네 이티브 앱이나 하이브리드 앱을 크로스플랫폼으로 만들 수 있다.
크로스플랫폼 네이티브 앱 개발을 위한 프레임워크를 사용하면 개발자는 프레임워크에서 제공하는 요소를 이용해 앱을 개발하고, 그 요소들은 다시 각 플랫폼의 네이티브 요소로 변환된다. 이방 면으로는 리액트 네이티브React Native, 플러터 Flutter, 자마린Xamarin 이 인기 있는 도구다. 각 프레임워크가 플랫폼 중립적인 코드를 네이티 브 코드로 변환하는 방식은 다르지만 그 결과물은 완전한 네이티브 앱에 필적할 만큼 빠르게 작동하는 모바일 앱이다. 단, 특정한 기능 을 구현하기 위해서는 각 플랫폼에 맞는 코드를 추가해야 할 수도 있 다. 그래도 코드베이스에서 플랫폼 중립적인 코드가 대부분을 차지 한다.
크로스플랫폼 하이브리드 앱 개발용 프레임워크로는 아이오닉Ionic, 아파치 코르도바 Apache Cordova, 온센UIonsen UI가 있다. 하이브리드 애플리케이션은 데스크톱 웹 애플리케이션의 개발 용이성과 네이티브 모바일 애플리케이션의 기능성을 겸비한다. 이 프레임워크들도 크로스플랫폼 네이티브 앱 개발용 프레임워크와 마 찬가지로 플랫폼 중립적인 코드를 하이브리드 코드로 전환한다. 그 리고 위에서 설명한 것처럼 기기의 내장 기능도 이용할 수 있다.
네이티브 개발과 비교해 크로스플랫폼 개발의 가장 큰 장점은 개발 효율이 극적으로 향상되는 것이다. 개발자가 단일한 코드베이 스만 작성하고 유지하면 되기 때문에 새 업데이트를 훨씬 빨리 내 놓을 수 있다. 웹 기술을 사용하는 것도 개발 시간을 단축하는 요인 이다. 네이티브 코드는 변경 사항이 있으면 다시 컴파일해야 하지만 웹 코드는 재시작 없이 바로 변경 사항이 적용된다(이를 '핫리로드hot reload'라고 한다). 네이티브 코드 컴파일에 수십 분이 아니라 단 몇 초 만 걸린다고 해도 장기적으로 보면 상당한 시간 손실이 발생한다. 
크로스플랫폼 개발은 웹 기술을 사용하기 때문에 개발자도 더 구하기 쉽다. 자바스크립트 같은 기본적인 웹 기술은 많은 개발자가 숙지하기 때문에 신규 개발자가 프로젝트에 빨리 적응할 수 있다. 그 리고 iOS와 안드로이드 전문가를 따로 영입할 필요도 없다.
끝으로 크로스플랫폼 개발은 사용자 유치에도 유리하다. 주력 플랫폼을 정할 필요 없이 처음부터 양 플랫폼 사용자를 동시에 공략할 수 있기 때문이다.
하지만 크로스플랫폼 개발도 단점이 있으므로 페이스북과 에어 비앤비처럼 유명한 기업이 크로스플랫폼에서 손을 뗀 사례도 많다. 크로스플랫폼 앱은 개발 속도가 빠른 대신 실행 속도가 떨어진다. 기 기에서 크로스플랫폼 코드를 네이티브 코드로 변환하는 시간이 필 요하기 때문이다. 그래서 분초가 중요할 만큼 실행 속도가 빨라야 하 는 앱이라면 UX가 나빠질 수 있다. 그리고 크로스플랫폼으로 개발 된 앱은 네이티브 코드 구조를 완전히 반영하지 못한다. 프레임워크 에서 대부분 알아서 처리한다고 해도 플랫폼의 특성을 모두 활용하 지는 못한다. 그래서 복잡한 제품을 개발할 때는 플랫폼 전용 코드가 적지 않게 필요해진다. 그러다 보면 결과적으로 두 개의 플랫폼이 아 니라 세 개의 플랫폼을 지원하는 격이 돼서 크로스플랫폼 개발의 장 점인 신속한 이터레이션이 어려워진다. 끝으로 크로스플랫폼 프레 임워크들의 역사가 아직 길지 않기 때문에 버그가 발생할 확률이 더 높다. 요컨대 크로스플랫폼 개발이 신생 앱을 개발할 때 요긴하긴 하지만 모바일 개발의 문제를 모두 해결해주는 만병통치약은 아니다.