Web App : 웹 개발자가 모바일 앱도 개발할 수 있을까?

 

🍎 목차

1. 웹(Web) 이란?
2. 웹 앱(Web App) 이란?
3. 웹 앱(Web App)의 장점에는 뭐가 있을까?
4. 웹 앱(Web App) 사용 시 단점은 없을까?
5. 웹 앱(Web App)을 사용하는 서비스에는 어디가 있을까?
6. 웹 앱(Web App)에 대한 나의 생각

 

1.  웹(Web) 이란?

웹(Web) 이란 기기에 상관없이 브라우저 내에서 HTTP(Hypertext Transfer Protocol)를 사용하여 정보를 전송하고, URL(Uniform Resource Locator)을 통해 서비스를 이용 가능하게 하는 정보 공간을 말합니다. 

 

 

2.  웹 앱(Web App) 이란?

• 웹 앱(Web App)은 모든 기기(컴퓨터, 휴대폰, 태블릿 등)의 웹 브라우저를 통해 앱과 유사한 화면을 보여주어 앱을 사용하는 것처럼 보이는 웹을 말합니다. 
• 웹 앱(Web App)은 SPA(single page application)을 사용합니다. 
  • SPA는 서버로부터 완전한 새로운 페이지를 불러오지 않고 현재의 페이지에서 필요한 부분만 동적으로 다시 작성함으로써 사용자와 소통하는 웹 애플리케이션을 말합니다. 
    • SPA는 CSR(client side rendering) 방식으로 동작하기 때문에 1. 필요한 부분만 업데이트 하여, 서버로부터 데이터를 효율적으로 로드 가능하고 2. 사용자 입력에 대한 응답이 빠르게 일어난다는 장점이 있습니다. 하지만 1. 초기 접속 시 웹 애플리케이션의 모든 리소스를 다운로드하고 처리해야 하기 때문에 초기 로딩 속도가 느리다는 단점이 있습니다. 

 

 

3.  웹 앱(Web App)의 장점에는 뭐가 있을까? 

1.  빠른 출시 속도

• 웹 앱은 모바일 앱보다 빠르게 만들어질 수 있기 때문에 앱 스토어에서의 승인을 기다릴 필요가 없습니다.

 

2.  비용 효율적인 개발

• 모든 운영 체제를 대상으로 하는 단일 버전을 만들 수 있기 때문에, 여러 버전을 만들 필요가 없어 모바일 앱보다 적은 개발 시간이 걸립니다. 

 

3.  좋은 접근성

• 브라우저를 통해 접근 가능하여 모든 운영체제의 사용자에게 서비스를 제공할 수 있습니다. 

 

4.  유지보수 용이성

• 업데이트를 서버에 바로 푸시 할 수 있어 코드 변경을 즉시 반영할 수 있습니다. 

 

5.  검색 엔진 노출도 높음

• 구글 및 다른 검색 엔진에서 검색 결과가 표시되어 찾기 쉽습니다. 

 

 

4.  웹 앱(Web App) 사용 시 단점은 없을까?

1.  오프라인 이용 불가

• 인터넷이 연결되어 있지 않은 경우 사용할 수 없습니다. 

 

2.  안정성 문제

• 웹 브라우저의 변화로 인해 가끔 웹 앱 실행에 어려움이 있을 수 있습니다. 

 

3.  모바일 기기 기능 제한

• 위치 정보나 카메라와 같은 기기의 네이티브 기능에 접근할 수 있는 능력이 제한됩니다. (하지만 서버와의 통신을 잘 이용한다면 위치 정보를 가져오는 기능은 구현 가능합니다. )

 

4.  사용자 인식 부족

• 앱 스토어에 등록되지 않고 특정 URL을 통해서 접근 가능하기 때문에 사용자들이 웹 앱을 알지 못할 수 있습니다.

 

 

5.  웹 앱(Web App)을 사용하는 서비스에는 어디가 있을까?

• 실제로 많은 유명 서비스에서 웹 앱을 사용하는 것을 글을 쓰면서 찾아볼 수 있었다. 
  1. Gmail
  2. Google Docs
  3. Netflix
  4. Basecamp
  5. Uber
  6. eBay
  7. Facebook
  8. Spotify

 

6.  웹 앱(Web App)에 대한 나의 생각

올 해(2023년) 두 번의 프로젝트(혼콕, 원데이히어로)를 완성 시켰는데 모두 웹 앱 방식으로 모바일 전용으로 설계하였다. 그 과정에 내가 느꼈던 웹 앱에 대한 생각을 정리해보려 한다. 

 

• 브라우저 프레임을 고려하자!
  • 디자인 작업을 프론트엔드 팀에서 전담하여했는데 초반에 브라우저 프레임을 고려하지 못하고 디자인을 한 탓에 한 번 수정한 일이 생각난다. 실제로 웹 앱을 보게 되면 URL 표시줄, 창 크기 조정 컨트롤, 책갈피 및 설정 버튼과 같은 웹 페이지 UI 프레임에 우리의 프로덕트가 둘러싸여 있다. 그래서 실제로 디자인 그대로 구현했음에도 불구하고 브라우저 프레임을 고려하지 않고 디자인했기 때문에 원래의 의도와 다르게 답답해 보였다. 그래서 헤더와 푸터의 사이즈를 줄였던 일이 생각난다. 그래서 원데이히어로 프로젝트의 디자인 작업 시작 전에는 브라우저 프레임을 염두에 두고 디자인을 했다!

 

• 뒤도 가기 버튼이 두개?
  • 이 또한 위의 맥락과 비슷하게 브라우저 프레임을 생각하지 못한 탓에 조금 당황했던 일이었다. 우리는 서비스를 구현할 때 모바일 사이즈를 주력으로 해 디자인 하고 기능 구현했기 때문에 당연히 뒤로 가기 버튼 또한 구현했다. 모바일 앱의 경우에는 브라우저 기본 기능인 뒤로 가기가 없었기 때문에 프로덕트 내의 뒤로 가기가 필히 필요하고 문제 될게 없지만 웹앱(Web App)으로 구현하게 되면 브라우저 기본 뒤로가기 버튼과 우리가 만든 프로덕트 안의 뒤로가기 버튼 이렇게 두 개의 뒤로 가기 버튼을 가지게 되므로 사용자 입장에서 조금 혼란스러울 수 도 있겠다 싶었다. 물론 UI/UX 문제뿐만 아니고 로그인이 풀리는 문제, 캐싱되는 문제도 예상되기 때문에 다음 프로젝트에서도 웹앱으로 구현하게 되면 미리 고려해야겠다고 생각했다.