한빛출판네트워크

웹 앱과 웹 사이트는 무엇이 다른것일까? 제작 도구나 전달되는 방식의 차이를 이야기 하는것이 아니다. 개발 문화와 순서에 대해 이야기 하는것이다. 웹 개발은 상당히 머리아플 정도로 복잡하지만, 이것들은 웹 앱 VS 웹 사이트의 토론에서 자주 나오는 내용들이다.

1.  MVC VS HCJ

루비 온 레일즈가 서버에서의 사용법을 보여준 이후로, Mode-View-Controller는 웹개발에서 한 자리를 차지해왔다. 레일즈의 MVC는 꽤 체계적이지는 않다. 하지만 대략적인 모델은 데이터베이스의 데이터를 반영하고, 뷰 (그리고 에셋)는 사용자가 보내온 데이터들을 가지고 있고, 컨트롤러는 연결방법을 제공한다.

MVC에 점점 친숙해 질수록, 그리고 웹 브라우저가 점점 강력해 질수록 MVC는 클라이언트에서 점점 더 많이 사용된다. MVC 기반의 서버에서 MVC 기반의 클라이언트를 만든다는 사람의 이야기를 처음 들었을때, 나는 꽤 놀랐다. 하지만 Angular는 확실하게 정리한 것 처럼, 몇몇 버전의 MVC는 상당히 오랜 기간동안 클라이언트위에 존재할 것이다.

웹은 비록 MVC위에서 만들어지지 않았다. 웹은 HTML(마크업으로 구성된 컨텐츠), CSS(스타일), JavaScript(동작)으로 만들어 졌다. 이걸 바라본다면, HTML을 모델에, CSS를 뷰에 그리고 JavaScript를 컨트롤러에 묘사할 수 있다. HCJ는 이쁜 줄임말이 아니고, 구글에 검색해도 쉽게 나오지 않는다. 하지만 이것은 벌써 이십년 넘게 웹을 지탱한 기반이 되어왔다. 특히나 CSS의 집합은 웹 사이트를 관리 할 수 있을 것이라는 기대를 하게 해 주었다.

웹 앱에 대한 이야기를 들을땐, 주기적으로 MVC에 대한 이야기도 들려왔다. 비록 웹 사이트들은 HCJ에 작별인사를 할 생각이 없지만, 이러한 논쟁을 불러일으키기에 충분했다. MVC와 HCJ는 같은 도구를 이용하지만, 접근 방식은 매우 다르다.

2. 액티비티 VS 콘텐츠

앱들은 어떠한 작업을 수행하는 경향이 있다. 반대로 웹 사이트는 무엇인가를 보여주고, 말하는 경향이 있다. 말처럼 간단한건 아니지만, 앱이나 웹 사이트는 두개의 경향이 섞여야 한다. 카탈로그 웹 사이트의 컨텐츠는 구매하기 위해 어떤 선택지가 있는지를 이야기해야 한다. 비슷하게 사용자가 소셜 미디어 엡에서 어떤 액션을 취할 것인지 결정하게 도와주는 사이트는 컨텐츠의 공급이 필요하다.

이렇게 섞는 것에는, 기본적인 질문이 숨어있다. 컨텐츠가 동작을 따라 구현되었는가? 혹은 동작이 컨텐츠에 따라 구현되었는가?

3. 인터페이스 VS 페이지

사이트나 앱의 내부에는 많은수의 개별적인 경험들이 들어있다. 이런 경험을 웹디자인이나 User Interface(UI) 디자인의 일부로 봐야할까? 아니면 User Experience(UX)로 봐야할까?

웹의 초창기에는 사이트들은 하나의 페이지만 존재했지만, 이제는 페이지들의 모음으로 커져왔다. 템플릿들이 나타나고, 이러한 모음속에서 반복되는 페이지를 돕기위해 CSS 설계는 이러한 경험들을 포함하며, 수많은 템플릿과 컨텐츠를 표현하는 방법을 제공한다. 개발자들은 모든 유저가 홈페이지로 접속하지 않는다는것을 배웠고, 어느 페이지로 접속하더라도 자유롭게 탐색 가능하게 만드는것이 사이트 개발에서의 유행이 되었다.

앱은 미리 정의된 하나의 시작점이 있는것으로 간주된다. 비록 시작점의 모양세는 매번 바뀔수 있지만 앱의 전체 부분과 연결되어 있다. 하나의 사이트를 위한 앱의 동작방식은 마치 Single-Page-App(SPA)패턴으로 만들어진 하나의 HTML페이지 처럼 보인다. 사실 애플과 구글 스토어의 앱에서 많은수가 SPA를 네이티브 코드로 랩핑한 앱들이다.

사이트가 더 많은 URL을 통해 접근할 수 있게 만들어지는 동시에, 실제로는 수많은 SPA에 접근하도록 바뀌고 있다. 웹이 비슷한 경험을 제공해야 한다는 요구사항은, 무한한 수의 디바이스들 위에서 페이지에 대한 개념 자체를 바꾸어 놓았다. Ethan Marcotte이 지적했던 것처럼, 디바이스-불가지(device-agnostic) 디자인은 페이지를 생성하기 보다는, 패턴을 생성하는 것을 의미한다.

지난 몇년동안, 반응형 디자인에 대한 논쟁은 미묘하게 변화했다. 페이지를 디자인하는것이 아니라, 패턴을 디자인 하는것에 집중하게 되었다. 작고, 재사용 가능한 요소들이 큰 시스템을 구성한다는 사실을 이해했다. 나는  내 디자인에 대한 생각이 모던 웹을 위한 매우 좋은 방식이라는 것을 알아냈다.

수많은 앱 프레임워크속의 컴포넌트 모델처럼, 이 개념은 W3C버전 혹은 다른 버전의 웹 컴포넌트의 시대로 이끌것이다.

4.  프레임워크 VS 라이브러리

몇년전 나는 전혀 비난같지 않은 헛소리를 들어본적이 있다.

jQuery는 프레임워크가 아냐. 그건 그냥 라이브러리지.

아마 그는 구글 클로져나 도조 툴킷을 프레임워크로 생각하고 있었던듯 하다. 내가 이 두가지에 대해 흥미를 가지는 동안, 그것들이 멀리 갈 수 있을것 같지는 않았다. 그래서 나는 그것이 왜 흥미로운지 확신할 수 없었다. 비록 그는 미래를 지목하고 있었지만, 프로그래머들의 좀더 타이트한 관리를 받는. 그 미래는 아마 “초인적인” Angular이나 “모호한” Ember 혹은 그들의 사촌쯤 될꺼다.

한편 jQuery는 좀더 적은 제어를 필요로 하며, 예외를 기반으로 브라우저가 웹 페이지를 만들도록 한다. jQuery는 $(document).read()가 되는순간 바빠지기 시작한다. 앱 개발자들이 반드시 사용하는 것에 비해, jQuery는 만들어진 문서를 수정하고 꾸미는데 특화되어있지, 맨땅에 해딩하며 문서 전체를 만들도록 되어있지는 않다. 이건 사이트 개발자들에게 완벽한 궁합이지, 좀더 많은 기능이 필요한 앱 개발자들에게는 그다지 좋은 선택은 아니다.

Angular와 Ember는 다시 나아가기 시작한다. 하지만 React-인터페이스를 위한 자바스크립트 라이브러리-는 라이브러리의 기본으로 돌아왔다. React는 Angular이나 Ember처럼 많은것을 하려 하지 않는다. 오히려 jQuery처럼 Document Object Model(DOM)을 다루기 위한 것들을 추상화 시킨다.

(한가지 첨언하자면, 라이브러리와 프레임워크에 대한 의존을 피하고 자신의 일에 집중하는 것도 좋을것이다)

5. 제어 VS 탄력성

웹에 있어서 가장 중요한 것은 웹은 인터넷에 연결된 모든 플랫폼에서 사용된다는 것이다. 수많은 스크린 사이즈는 물론이고 텍스트만 나오는 브라우저, 오디오만 나오는 브라우저, 그리고 새로워 보이기 위해 자신들만의 기술을 이용한 브라우저 까지.

그래서 웹 개발은 탄력성을 필요로 한다. Jem Simmons가 2014년 키노트에서 지적했던것 처럼, 개발자가 자바스크립트 중심으로 개발했을경우 웹은 멈춰버릴수 있다. 제대로 동작하는 작고 심플한것들로 채워나가는 진보적인 개발방법은 실패에 탄력적으로 견딜수 있는 웹을 지향하게 된다.

옛날 방식의 plain HTML이 훨씬 빨리 랜더링되고, 수많은 디바이스에서 문제없이 반응한다는 것을 기억해 냈을때 사이트 개발자들은 그 방식을 응원한다. 앱 개발자들은 컨퍼런스에서 나에게 몇번씩이나 묻곤 했다. 왜 그렇것에 신경쓰냐고.

수많은 개발자들은 어떤 제어를 할지 선택 할 수 있다. 코드를 직접 넣어서 사용 환경을 조사하고 개개인에게 딱 맞는 코드를 생성해 낼 수 있는 것이다. 때론 React 개발자들은 특정한 그들만의 접근 방식을 적용하는것 처럼 보인다. 그들은  프로그래머의 제어를 극대화 하기 위해 좀더 코드에 가까운 스타일 정보를 사용한다. 자바스크립트는 강력하니까.

이 방식이 언제나 먹히는건 아니다. 2011년에 일어난 자바 스크립트 사고는 어떤일이 일어날수 있는지에 대한 예고였다. 이 사고는 빈 페이지위에 자바스크립트로만 만들어진 사이트의 jQuery가 멀웨어로 오인되 차단되었고, 결과적으로 사용자들은 빈 페이지만 보고 있었다. 이후 SPA로 개발하는 몇몇 시스템은 자바 스크립트를 덜 사용하게 되었다.

하지만 기술의 발전은 제어와 탄력성, 이 둘의 차이를 덜 연관되게 만들것이다. 성능적인 이유와 비 협조적인 환경에서의 지원을 이유로 몇몇 개발자들은 “Isomorphic” 개발로 넘어간다. Isomorphic 개발은 서버에서 더 많은 HTML코드를 출력하는 방법이다. 이것은 기술적인 해결 방법이며, 아마도 이 방법을 가지고 큰 싸움이 일어 나지는 않을 것이다. 다른 방법을 추구하는 구글의 AMP 이니셔티브는 페이지 중심의 사람들을 (완전 제한적인) 앱 중심 개발 환경으로 유혹한다.

다른 한편 나는 진보적인 앱들을 보면서, 자바스크립트와 서비스워커를 혼합한 것이 기존의 서비스를 점차 개선해 나아가지 않을까 싶었다. 아마도 말이다. (또한 SPA들과 점진적 개선이 호환되지 않을지는 확실하지는 않다.)

다음은?

통합을 위한 이 두가지 방법. 나는 이 두가지 모두 좋아한다. 썩 좋은 책은 아니지만 내가 처음 쓴 책은 다이나믹 HTML을 기반으로 했다. 웹 앱을 가능하게 만든 첫번째 요소인 다이나믹 HTML. 그리고 나는 웹 앱과 웹 사이트 개발자들을 위한 컨퍼런스를 공동 주최할 것이다.

가까운 미래를 위한 나의 예측으로는 더 분리될 것이라는 거다. 앱 개발자들은 작지만 급속하게 성장하고, 대개 높은 보수를 받는 사람들이다. 반대로 사이트 개발자들은 차고 넘치며 하는 일의 대부분은 평범하고, 업무에서 가장 중요하기 보단 약간 덜 중요하게 여겨진다. 우리가 만들어가는 새로운 움직임이 두 개발자들을 하나로 뭉치게 만들지도 모른다. 하지만 지금 당장은 그런일이 일어나긴 힘들것이다. 

원문 : https://www.oreilly.com/ideas/5-ways-web-apps-and-sites-are-the-same-and-different