이번 글에서 다룰 부분은 AWS(Amazon Web Service)에서의 Python 설치를 다루도록 하겠습니다.

사실 AWS에서 Python을 설치하는 것은 자습서 상에서 매우 잘 나타나 있지만, 여러 페이지를 옮겨다니면서 확인해야 하기 때문에 번거로움이 있었습니다.

이에 따라, 제 블로그에서는 옮겨다니는 번거로움을 줄이는 대신, 연재글의 형태로 순서대로 진행할 수 있도록 할 예정이니 참고하시기 바랍니다.


※ AWS의 VPC 네트워크 구축, IAM 서비스, S3 Storage 서비스 구축 부분은 생략하겠습니다.

※ AWS Console 수행을 위한 계정은 이미 보유하고 있어야 하며, VPC, S3는 이미 구축이 사전에 되어 있어야 하니 참고하시기 바랍니다.

※ PUTTYXMING 미리 설치해주시기 바랍니다. (설치 링크는 왼쪽의 글자를 누르면 됩니다)


이전 글: 

2018/05/12 - [Onik Lab./AWS Python] - AWS EC2 (Ubuntu) 구축 및 접속

2018/05/19 - [Onik Lab./AWS Python] - AWS CLI, AWS EB CLI 설치

2018/05/19 - [Onik Lab./AWS Python] - AWS Python Django Application 환경설정



10. Elastic Beanstalk 배포를 위한 구성

이전 글에서 수행했던 명령에 바로 이어서 한다면 가상환경이 이미 활성화되어 있는 상태일 것입니다.

하지만 가상환경에 들어오지 않았다면 가상환경을 먼저 들어가도록 합니다.

(eb-virt) ~/ebdjango$ source ~/eb-virt/bin/activate


그 다음에는 전에 실행했던 pip freeze를 실행합니다. 하지만 이번에는 실행 결과를 requirements.txt에 저장합니다.

(eb-virt) ~/ebdjango$ pip freeze > requirements.txt

이 부분은 매우 중요합니다. Elastic Beanstalk에서 애플리케이션을 실행할 때 어떤 패키지를 설치할 것인지를 결정하는데, 이 때 requirements.txt 파일을 참조하기 때문입니다. 


다음은 .ebextensions을 새로 생성한 후, django.config 파일을 생성해서 애플리케이션을 시작하는 데 사용되는 WSGI 스크립트 위치를 지정합니다.
(eb-virt) ~/ebdjango$ mkdir .ebextensions
(eb-virt) ~/ebdjango$ vi .ebextensions/django.config
django.config는 없는 파일이므로 새로 생성해야 하며, 다음의 내용을 넣도록 합니다.

option_settings:
  aws:elasticbeanstalk:container:python:
    WSGIPath: ebdjango/wsgi.py


다음은 가상환경을 비활성화 합니다.
(eb-virt) ~/ebdjango$ deactivate

(그러나 제가 테스트한 결과, 가상환경을 비활성화 하지 않고 다음 작업을 진행해도 문제는 없었습니다. 다만, 가상환경 활성화가 애플리케이션에 패키지를 추가하거나 로컬에서 실행할 때 활성화를 한다는 점에 비추어 봤을 때에는 주 용도로 사용될 때에만 가상환경을 활성화하는 것을 권장합니다.)


11. Elastic Beanstalk 배포

개인적으로 이 부분에서 시간을 많이 소모한 것 같습니다.

세팅을 똑같이 했는데도 에러메시지가 매번 다르게 나타났지 싶었습니다.

사실 정확한 원인을 찾아내는 데에는 어려움이 있었지만, 어떤 유형의 오류가 있었는지도 소개하도록 하겠습니다.


참고문서: https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/create-deploy-python-django.html



먼저 Elastic Beanstalk(이하 EB) Repository를 초기화하고, Application을 생성해 줍니다.

~/ebdjango$ eb init -p python-2.7 django-tutorial
Application django-tutorial has been created.

python 2.7을 사용할 것이므로 언어는 다음과 같이 사용하도록 합니다.


※ 제가 이 부분과 관련해서 eb init 만 입력하고 여러 가지 테스트를 많이 해봤습니다만, 위와 같이 사용 언어(python-2.7) 및 애플리케이션 이름(django-tutorial)을 다 입력하는 것이 가장 안정적입니다. 물론 애플리케이션 이름은 어떤 것을 써도 문제는 전혀 없습니다.


참고문서에서는 SSH를 통해 실행할 때 Pair Key를 입력하는 방법도 추가로 나와있지만, 이 게시물에서는 생략합니다.

(실제로 생략해도 문제 없습니다)


이제 실제로 애플리케이션을 생성하도록 합니다.

/ebdjango$ eb create django-env

※ 이 부분 역시 'eb create'만 실행한 후 환경 이름을 직접 입력하는 방법도 해봤지만, 처음부터 환경이름을 명령어 뒤에 붙여주고 실행하는 것이 안정적입니다. 오히려 별도로 여러가지 입력을 하다가 에러가 발생하는 상황이 더욱 많이 발생합니다.


이 부분에서 시간이 거의 5분정도 소요 되니, 그 사이에 다른 준비를 하셔도 무방합니다.


생성이 완료되었으면 실제 가동을 하도록 합니다.

~/ebdjango$ eb open

테스트 결과는 다음과 같습니다.


먼저 django-env2라는 개발 환경에서 실행한 결과입니다.


다음은 django-env3라는 개발 환경에서 실행한 결과입니다.


모두 예상했듯이, django-env3 의 결과처럼 나오는 것이 정상이고, django-env2의 결과처럼 나오는 것이 비정상입니다.

놀랍게도 두 개의 환경은 모두 같은 환경설정에 같은 운영체제, 같은 설정값을 한 웹 애플리케이션입니다.


그런데도 이렇게 정반대의 결과가가 나온 이유는 저도 사실 파악을 하지는 못했습니다만,

한 가지 추정되는 것은 django-env2 가 제대로 나오지 않고, S3 Storage의 미사용 중인 Bucket을 삭제한 이후로 올바르게 나타난 것으로 보아 EB에 배포할 때 사용되던 이름 문제인 것으로 추정됩니다. (다만 정확한 원인은 좀 더 알아보겠습니다)


다음은 ebdjango/ebdjango/setting.py 에서 TIME ZONE을 수정합니다.


위와 같이 'ROK'라고 입력했는데, 이는 Republic of Korea의 줄임말로 군대에서 많이 듣던 용어였을 것입니다.

AWS의 Timezone은 한국을 ROK로 공식 표기하므로 이를 참고하시면 됩니다.


다음은 애플리케이션을 EB 환경에 배포합니다.

~/ebdjango/$ eb deploy


여기까지가 실제 Application을 배포하는 부분입니다.

참고자료에는 관리자 페이지 설정 및 배포 부분도 같이 나와있는데, 해당 부분은 블로그에서 언급하기보다는 직접 자료를 보시면서 실습하는 것이 더욱 유익할 것으로 생각됩니다.


이상 Python Django Application 배포를 마치도록 하며, 추후 실제 실습을 통해서 더욱 좋은 글로 찾아뵙겠습니다.


WRITTEN BY
鬼風
생각이 깨어있지 않다면 살아갈 이유도 없다

트랙백  0 , 댓글  2개가 달렸습니다.
  1. 안녕하세요 여기까지 잘 따라왔습니다.
    ~/ebdjango$ eb init -p python-2.7 django-tutorial

    이 명령어를 실행시키니
    You have not yet set up your credentials or your credentials are incorrect
    You must provide your credentials.
    (aws-access-id) :

    라고 나왔습니다.
    일단 저는 따로 IAM을 만들지 않고 계속해서 root권한을 가진 계정으로 작업을 해왔습니다
    여기서 id는 어떤 id를 입력해야 하는 건가요?
    • 먼저 댓글 감사드립니다!
      AWS계정 아이디는 당연히 아닙니다.
      Management Console에 로그인 하시면 로그인한 사용자 아이콘이 우측상단에 나오고 이걸 클릭하시면 “내 자격증명”인가 하는 메뉴가 나옵니다. 거기로 들어가시면 accessid와 password를 발급받을 수 있습니다. 거기서 발급받은 내용을 입력해주시면 됩니다.
secret

이번 글에서 다룰 부분은 AWS(Amazon Web Service)에서의 Python 설치를 다루도록 하겠습니다.

사실 AWS에서 Python을 설치하는 것은 자습서 상에서 매우 잘 나타나 있지만, 여러 페이지를 옮겨다니면서 확인해야 하기 때문에 번거로움이 있었습니다.

이에 따라, 제 블로그에서는 옮겨다니는 번거로움을 줄이는 대신, 연재글의 형태로 순서대로 진행할 수 있도록 할 예정이니 참고하시기 바랍니다.


※ AWS의 VPC 네트워크 구축, IAM 서비스, S3 Storage 서비스 구축 부분은 생략하겠습니다.

※ AWS Console 수행을 위한 계정은 이미 보유하고 있어야 하며, VPC, S3는 이미 구축이 사전에 되어 있어야 하니 참고하시기 바랍니다.

※ PUTTYXMING 미리 설치해주시기 바랍니다. (설치 링크는 왼쪽의 글자를 누르면 됩니다)


이전 글: 

2018/05/12 - [Onik Lab./AWS Python] - AWS EC2 (Ubuntu) 구축 및 접속

2018/05/19 - [Onik Lab./AWS Python] - AWS CLI, AWS EB CLI 설치



6. VirtualEnv 설치 및 가상환경 설정

이 부분은 Django Application을 Python 2.7로 실행된 Elastic Beanstalk 환경에  배포하는 방법을 나타내는 부분입니다.

이를 위해서는 먼저 가상환경을 설정한 후, 가상환경에 Django를 설치한 후, 실제 배포를 하는 순서로 이루어집니다.


참고문서: https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/create-deploy-python-django.html


가상환경 설정을 위해서는 virtualenv가 설치되어 있어야 합니다.

하지만, 이전 게시물을 통해서는 virtualenv가 설치되어있지 않으므로, 먼저 설치를 진행합니다.


$ pip install --user virtualenv

설치는 pip를 통해서 진행하도록 합니다.


설치가 완료되었으면, 이제 가상환경을 실제로 구현하도록 합니다.

이 글은 Ubuntu 기반이므로, 타 운영체제에서의 실행방법은 AWS 내의 문서를 참조해주시기 바랍니다.


이름이 eb-virt인 가상 환경을 만듭니다.

~$ virtualenv ~/eb-virt

가상 환경을 활성화합니다.

~$ source ~/eb-virt/bin/activate (eb-virt) ~$

pip를 사용하여 Django를 설치합니다.

(eb-virt)~$ pip install django==1.9.12

Django가 설치되었는지 확인하려면 다음을 입력합니다.

(eb-virt)~$ pip freeze


사실 이 바로 위부분은 AWS의 기술문서와 같은 내용입니다만, 특별히 제가 설명할 부분이 없는 관계로 그대로 붙여넣었으니 참고바랍니다.

다만, 실제 이를 실행했을 때의 결과는 다음과 같이 나타낼 수 있습니다(이건 당연히 제가 직접 한 내용입니다).



7. Django Project 생성

이제 Django 설치까지 끝났으면, 이제 애플리케이션을 생성하도록 합니다.

바로 상기에서 설치까지 모두 끝난 상태이기 때문에 가상환경 유지는 계속 되어 있을 것입니다.

하지만, 가상환경 유지가 되어있지 않을 경우도 있을 수 있으니, 이를 위해서 가상환경에 있는지를 확인해 봅니다.

하단과 같이 (eb-virt)라고 prompt 앞에 나타나 있으면 가상환경에 있는 상태이고, 그렇지 않을 때에는 가상환경이 아니니 참고바랍니다.


가상환경이 아닐 때에는 다음 명령어를 실행하면 됩니다.

~$ source ~/eb-virt/bin/activate
(eb-virt) ~$


이제 프로젝트를 생성합니다. 프로젝트명은 ebdjango로 합니다 (즉 다른 이름으로 해도 됩니다).

(eb-virt)~$ django-admin startproject ebdjango


사실 더 자세한 내용은 위 참고문서에 나타나 있지만, 제 블로그에서는 명령어 실행과 결과 위주로 순서대로 나열할 계획이므로, 세부 설명이나 부가 문서가 필요하다면 상단 참고문서를 참조바랍니다.


프로젝트가 생성되었으면, 기본 Django 웹 문서가 생성되었을 것이며, 이를 웹에서 조회할 수 있습니다.

웹에서 조회하는 방법은 로컬 서버를 manage.py를 실행해서 나타내는 것이며, 이에 따른 실행 결과는 다음과 같이 조회됩니다.

(eb-virt) ~$ cd ebdjango
(eb-virt) ~/ebdjango$ python manage.py runserver


그런데 솔직히 생각을 해봅시다.

이전 문서에서와 같이, Ubuntu 기반으로 AWS 환경구축을 하고,

Putty를 접속해서 커맨드 창에서 명령어를 실행해서 환경구축을 한 것이 대부분입니다.

그런데 위 예제는 Django 프로젝트 구현에 따른 웹 조회를 localhost에서 하도록 되어 있습니다.


그렇다면 위 웹브라우저는 어떻게 띄운 것일까요.

그것은 바로 이전 글 중 첫 번째 글인 Putty 설정의 X11을 통한 GUI 설정과 관련되어 있습니다.

다시 링크를 걸어드리니 참고바랍니다.

2018/05/12 - [Onik Lab./AWS Python] - AWS EC2 (Ubuntu) 구축 및 접속


8. XMING을 활용한 Firefox 구동

Putty에서의 X11 세팅은 상단 링크를 참고하시면 되며,

Firefox와 같은 GUI Program을 실행하기 위해서는 먼저, Putty를 실행했을 때 XMING도 실행해야 합니다.

(단, XMING이 아닌 XMING 설치 시 동시에 깔린 XLaunch를 실행시켜줘야 합니다.)


XMING을 설치하셨던 분들은 다른 블로그 등의 설치 방법을 보면서 파악하셨겠지만,

XLaunch를 실행했을 때 별다른 세팅을 하지 않습니다.

그저 작업 표시줄에 XLaunch가 있으면 됩니다.


그리고 나서, Ubuntu에서도 Firefox를 설치해야 합니다. (가상환경 여부는 상관없습니다)

$ sudo apt-get update
$ sudo apt-get install firefox

이게 apt-get을 Update해주지 않으면 에러가 나더라고요.

그래서 업데이트도 하게 되었습니다.


9. Django 웹페이지 Localhost 호출

Firefox 설치까지 끝났으면 실제 호출을 해보도록 합니다.

먼저 파이어폭스를 백그라운드로 실행시킨 후, Django 사이트를 로컬에서 실행시킵니다.

(사실 위에 있었던 명령어와 동일합니다. 가상환경에서 실행시켜주시기 바랍니다)


$ firefox &
$ python manage.py runserver


그런데 막상 실행하면 에러메시지가 납니다. 위에 써진대로 실행시켜줍니다.

$ python manage.py migrate



그리고 다시 실행.


이제 다음은 Django Application을 AWS Elastic Beanstalk에 배포하는 것을 다루도록 하겠습니다.






WRITTEN BY
鬼風
생각이 깨어있지 않다면 살아갈 이유도 없다

트랙백  0 , 댓글  0개가 달렸습니다.
secret

이번 글에서 다룰 부분은 AWS(Amazon Web Service)에서의 Python 설치를 다루도록 하겠습니다.

사실 AWS에서 Python을 설치하는 것은 자습서 상에서 매우 잘 나타나 있지만, 여러 페이지를 옮겨다니면서 확인해야 하기 때문에 번거로움이 있었습니다.

이에 따라, 제 블로그에서는 옮겨다니는 번거로움을 줄이는 대신, 연재글의 형태로 순서대로 진행할 수 있도록 할 예정이니 참고하시기 바랍니다.


※ AWS의 VPC 네트워크 구축, IAM 서비스, S3 Storage 서비스 구축 부분은 생략하겠습니다.

※ AWS Console 수행을 위한 계정은 이미 보유하고 있어야 하며, VPC, S3는 이미 구축이 사전에 되어 있어야 하니 참고하시기 바랍니다.

※ PUTTYXMING 미리 설치해주시기 바랍니다. (설치 링크는 왼쪽의 글자를 누르면 됩니다)


이전 글: 2018/05/12 - [Onik Lab./AWS Python] - AWS EC2 (Ubuntu) 구축 및 접속


3. AWS CLI 설치

이번에는 AWS CLI (Command Line Interface)를 설치하도록 하겠습니다.

CLI를 설치해야 하는 이유는 다음과 같습니다. 

AWS EC2 서버에서 다른 서비스를 이용하고 연계를 하는 데 있어서는 Command 창을 통해서 명령어를 입력해야 하는 상황이 다수 발생하는데, 이를 위해서는 CLI가 설치되어있어야 하기 때문입니다.

물론 더욱 자세한 이유는 AWS 전문가나 홈페이지 등을 통해서 나타나 있긴 하지만, 일단 기본적인 이유는 이와 같다는 점을 참고하시면 됩니다.


참고자료: https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/awscli-install-linux.html


AWS CLI는 Python 언어로 구성되어 있기 때문에, Python이 설치되어 있어야 합니다. 

그래서 pip, python, python3이 설치되어있는 지를 확인합니다.


확인하는 방법은 

$ pip --version
$ python --version
$ python3 --version

이렇게 하면 됩니다.


확인 결과 pip, python은 설치되지 않은 반면, python3은 설치가 되어 있습니다.

이제 pip를 설치하겠습니다.

$ curl -O https://bootstrap.pypa.io/get-pip.py

여기서 주의할 점은 -O가 알파벳 대문자 'O'입니다. 숫자 0이 아닙니다.

물론 Copy & Paste 하셔도 됩니다.



다음은 python을 설치하겠습니다.
python3 설치는 이미 되어 있지만, python은 설치가 되어 있지 않으며,
향후 python 웹 개발 시에는 python2.7 기반의 django application을 개발할 예정이므로, 이 역시 반드시 설치가 이루어져야 합니다.

python 설치는 다음과 같습니다.


$ sudo apt install python


python 설치가 끝났으면, 다음 명령어를 실행해 봅니다.

$ python get-pip.py --user


AWS의 참고자료에서는 PATH 추가가 되었는지를 확인하라고 나오는데, 이미 추가 되어 있습니다.

만약 pip 명령이 실행이 안되면 아래 참고자료를 참조해주시기 바랍니다.

참고자료: https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/awscli-install-linux.html


이제 python 설치까지 모두 끝났으면, pip 버전을 확인해줍니다.

다음은 pip를 사용하여 AWS CLI를 설치합니다.

$ pip install awscli --upgrade --user

AWS CLI가 올바르게 설치되었는지 확인합니다.

$ aws --version


특별한 이상이 없다면 설치가 매우 양호하게 된 것을 확인할 수 있을 것입니다.


4. AWS EB CLI 설치

AWS CLI 설치에 이어서 이번에는 AWS EB CLI도 설치하도록 하겠습니다.

AWS EB CLI 설치를 하는 이유는 Elastic Beanstalk 사용을 위한 Command Interface를 설치하는 것이 되겠습니다.


여기서 Elastic Beanstalk라 함은, AWS에서 제공하는 서비스 중 하나로, 애플리케이션을 배포 및 관리를 하기 위한 서비스입니다.

AWS에서도 Python 애플리케이션을 개발 및 배포를 하기 위해서는 Elastic Beanstalk를 통한 배포가 필요하므로, 이 점을 참고하시면 됩니다.


EB CLI 참고문서: https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/eb-cli3-install.html


EB CLI 설치는 다음과 같습니다.

$ pip install awsebcli --upgrade --user


eb cli가 올바르게 설치되었는 지를 다음과 같이 확인합니다.


eb cli 설치까지 이루어졌으면 이제 AWS Elastic Beanstalk를 사용할 준비까지 모두 마쳤으므로, 다음은 AWS Python 가상환경 구축을 해보도록 하겠습니다.




WRITTEN BY
鬼風
생각이 깨어있지 않다면 살아갈 이유도 없다

트랙백  0 , 댓글  0개가 달렸습니다.
secret

사진출처: 조선일보

 

기사출처: http://news.chosun.com/site/data/html_dir/2017/06/02/2017060201874.html

 

현재 Google Android Version이 Nougat(7.0)이죠.
안드로이드 업데이트가 알파벳 순서대로 이루어졌다는 점을 감안했을때 (M버전은 '마쉬멜로우', N버전이 '누가'인것처럼),
다음에 나오는 버전은 Android O가 될텐데요 (아직 약어는 정해지지 않았습니다).

이번에 Google에서는 안드로이드O 버전 출시 시 모든 안드로이드 개발자 및 개발업체에서 인스턴트 앱(instant App)을 만들어서 서비스할 수 있도록 할 예정이라고 밝혔습니다.

(인스턴트앱 데모 사진은 위 사진 참조하시면 됩니다)

 

인스턴트앱은 무엇이냐.

간단히 말하자면, Application을 설치하여 실행하는 서비스가 아닌, 웹 브라우저에서 앱과 같이 즉시 사용할 수 있도록 하는 것을 뜻합니다.

 

인스턴트앱은 Google Assistant (구글 비서)에도 동일하게 적용할 예정이라고도 하였습니다.

 

기사는 여기까지입니다.

 

전 이 기능이 굉장히 편리한 기능이 될 것이라고 많은 기대를 하고 있습니다.

휴대폰 저장용량이 어느 정도일까요.  16GB, 32GB, 64GB 정도 됩니다.
그리고 SD메모리칩을 추가하고, 사진이나 동영상을 그쪽으로 모두 이동을 시키기도 합니다.

그러나 스마트폰을 사용하는 사람들이 많아지고 요구하는 서비스가 다양해지면서 부득이하게 앱을 설치해야 하는 경우도 많아졌습니다.

앱을 설치하면 통상적으로는 내부 저장소로 들어가게 되고요.
내부 저장소 용량이 부족해서 SD카드로 옮긴다고 하더라도, 앱 설치파일만 SD카드로 들어가고 추가 데이터 다운로드는 내부 저장소로 저장됩니다.

제가 해당 부분은(스마트폰이 삼성폰인 관계로) 삼성전자 A/S센터에 직접 문의를 해보았는데,
이것은 단말 자체의 문제는 아닌 앱 제조사에서 데이터 저장을 로컬로 저장하도록 구성해서 된 것이라 추가적으로 조치할 부분이 없다고 하였습니다.

임의로 데이터를 SD카드로 옮기게 된다면 앱이 손상을 입는 경우도 당연히 생기겠지요.

 

앱을 사용한다는 것이 생각 이상으로 굉장히 불편합니다.

인터넷을 하다가 어떤 서비스를 이용하고 싶을 때, 앱으로 들어가서 추가적으로 실행을 해야 하는 경우도 있고.
또는 앱 상에서 어떤 기능을 하다가 또 다른 앱으로 연결해서 실행해야 하는 경우도 있고.
하나의 은행에서는 다양한 혜택을 주는 서비스를 제공하고자 무려 비슷한 앱만 5~6개를 제공하는 경우도 있습니다.

 

 

솔직히 이것 엄청 불편하지 않나요???
전 너무 불편하던데요.

사실 은행사 잘못으로 보기는 어렵습니다.
우리나라의 경우는 웹 상에서 특정 페이지를 가거나 무언가를 하기 위해서는 그것에 맞는 보안 모듈을 추가로 요구를 할 수도 있으니까요.

다시 말하자면,
어떤 서비스를 제공을 해야 합니다.
그런데 모바일 웹 상에서는 쉽게 구현하기 어렵습니다.
그래서 모바일 앱 상에서 구현한 후 소비자들에게 앱을 설치하여 사용하도록 권장합니다.

그리고 회사 사정 상(기술적 문제나 구조적 문제 등으로 인하여), 모바일 앱도 한 개가 아니라 여러 개를 개발하고 각각 제공하도록 하는 것입니다.

(이런 식으로 웹 화면에 들어가면 앱 설치를 권장할 수밖에 없는 구조입니다.)

 

인스턴트 앱은 모바일 앱의 활성화로 인한 부작용을 해소할 수 있는 가장 좋은 방법이 될 수 있습니다.

굳이 앱을 일일히 실행하지 않고도, 웹 브라우저 상에서 '즐겨찾기'만 가지고도 원하는 페이지로 갈 수 있고,
해당 페이지에서 원하는 기능을 수행할 수 있기 때문입니다.

 

이것은 스마트폰을 사용하는 유저들한테는 엄청난 편의를 제공하는 것으로 볼 수 있습니다.

 

스마트폰이 처음 등장했습니다.
모바일 App과 모바일 Web 개발이 대두가 되었습니다.
솔직히 속도나 편의성은 Web이 더 좋으나, 기능 면에서는 App이 더 좋습니다.

그러나 더욱 많은 기능이 개선되면서 Web보다는 App을 사용할 수밖에 없는 환경입니다.
사용자들이 좋든 싫든간에.

그것은 Web으로 구현할 수 있는 기능이 한정되어있기 때문입니다.

그런 면에서 Instant Web은 스마트폰을 사용했던 사용자들이 겪었던 일련의 문제를 해소할 수 있는 가장 좋은 방법이 될 것입니다.

 

많은 기대가 됩니다.
어찌되고보면 Android O 버전은 안드로이드 개발에 있어서 획기적인 변화를 가져다줄 수 있지 않을까.

한번 지켜보겠습니다.

 

사진출처: androidcommunity.com

 


WRITTEN BY
鬼風
생각이 깨어있지 않다면 살아갈 이유도 없다

트랙백  0 , 댓글  3개가 달렸습니다.
  1. 장점은 용량문제가 없어지고 웹으로도 이용가능하다는건데 불편한건 인터넷이 안되거나 하면 힘든거 정도일려나요 용량문제가 없어지는건 좋은거같아요
    • 좋은 댓글 감사합니다.
      모바일 웹 기술 발전은 스마트폰을 이용하는 유저들의 가장 큰 불편을 해소할 수 있는 계기는 될 것 같습니다.
      인터넷이 안될경우 아무것도 할수없는것을 지적하셨는데, 매우 좋은 지적이라고 생각합니다. 그런 점에서 인터넷이 되어야만 사용 가능한 서비스라면 인스턴트 앱으로 대체하도록 하고, 인터넷 상관없이 일부 기능이 이용 가능하다면 기존 앱으로 개발하여 편의성을 두루 제공한다면 어느 정도 보완은 될 것 같습니다.
    • 하하 그렇겠죠. 일부기능이라도 사용가능하다면 대체가 가능하긴할텐데 진짜 지금 어플리케이션들도 마찬가지지만 인터넷이 연결되지않으면 못쓰는게 너무많으니
secret