이 글은 아래의 링크의
이전 포스팅 「웹 애플리케이션 아키텍처」의 다음 글로
이러한 「웹 애플리케이션 아키텍처의 유형」에 대해 이야기 해보고,
그 다음으로 개발자들이 흔히들 알고 있는
Django, Ruby On Rails, Spring이 실제 속해 있는
「웹 애플리케이션 서버 아키텍처」에 대해 알아보려고 한다.
우선 이번 글은 위에서 언급했다시피
「웹 애플리케이션 아키텍처의 유형」에 대한 글이다.
웹 애플리케이션 아키텍처는
웹 애플리케이션 서버 아키텍처(프레임 워크가 포함된)보다
좀 더 추상적인 아키텍처인데,
웹 애플리케이션 서버 아키텍처는
클라이언트 단과 서버단을 나누어 아키텍처를 그린다면,
웹 애플리케이션 아키텍처는 이 보다 좀 더 큰 틀로
서버와 페이지 간의 상호 작용을 나타낸다.
서버 측 HTML 웹 애플리케이션 아키텍처
(Server-Side HTML Web
Application Architecture)
서버 측(Server Side) HTML은
일반적인 웹 응용 애플리케이션 아키텍처이다.
이 아키텍처는 Web 1.0으로
불리우기도 하는데
서버에서 생성 한 HTML 문서를 통해 작동되며,
결과는 HTML 페이지로 구성된다.
이 아키텍처는 가장 오래된 아키텍처 중 하나로
특정 요구에 맞는 서버 언어 및 프레임 워크를 사용할 수 있다.
또한 서버의 특정 HTML 컨텐츠가 기본적으로
하나의 URL로 전송되므로 연결성이 뛰어나다고 할 수 있지만,
서버와 사용자간에 엄청난 양의 정보가 교환되기 때문에
성능면에서는 떨어 질 수 있다는 것을 고려해야 한다.
일반적으로 클라이언트는
전체 페이지 대신에 일부를 다시 로드 할 것이다.
이런 성능에 문제가 있는 한,
모바일 환경에서는 사용하지 않는 것이 좋다.
또한 즉각적인 데이터 업데이트를 보내거나,
실시간으로 변경하는 기능은 없으며
AJAX나 WebSockets을 적용하는 서버 및 사용자 업데이트만 가능하다.
서버 측은 보안을 제공 하며
컨텐츠가 일정하므로 프론트 엔드(Front - end)단에서
테스트를 위한 JavaScript 도구가 필요하지 않다.
결과적으로 이런 아키텍처를 사용하게 된다면
가장 쉽게 웹 애플리케이션을 구현할 수 있으나,
서버와 클라이언트 간에
엄청난 양의 데이터 교환이 필요하므로
비교적 성능면에서는 떨어지며
모바일에서 데스크톱 애플리케이션 혹은
데스크톱 애플리케이션에서 모바일 애플리케이션으로의 변환
즉, 웹/앱 환경을 구축하기 힘들다.
따라서 단일 웹 애플리케이션으로 사용하기에는
적합한 아키텍처라고 볼 수 없을 것이다.
JS 생성 위젯(AJAX)
(JS generation widgets)
서버 측(Server Side) HTML 애플리케이션 아키텍처에서 진화된 아키텍처로서,
AJAX(Asynchronous JavaScript and XML)는 서버 측 접근 방식이다.
차이점은 표시된 페이지가 위젯(Widgets)으로 구성되어 있다는 것
이다.
JSON 또는 AJAX 쿼리를 사용하여 위젯에 정보를 업로드 할 수 있다.
위젯의 장점은 클라이언트 측에서
웹 애플리케이션을 사용할 필요가 없기 때문에
HTML 데이터(HTML of chunks)를 업로드 할 때 속도를 높일 수 있다.
또한 모든 위젯이 개별적으로 작동해
페이지 자체에 영향을 주지 않고,
요청된 페이지 부분에만 영향을 준다는 점이다.
따라서 전송 된 데이터의 양이 적으며 응답 속도도 빠르다.
이 아키텍처는 데이터를 JSON으로 전송이 가능한 등의 성능을 향상 시킬 수 있다.
다만, 이 아키텍처는 서버 측(Server Side) 웹 서비스의 기술과
클라이언트 측(Client Side) JavaScript 프레임 워크를 사용해야만 하며,
[1]Hash-Bang과 같이
각 요소를 연결 해주는 기능에는 특정 매커니즘이 필요하다.
즉 이 아키텍처를 사용한다면
독립적으로 움직이는 위젯으로부터
부분적으로 응답(Request) 및 반응(Response)을 처리할 수 있게 되어
서버 측(Server Side) HTML 애플리케이션 아키텍처보다
뛰어난 성능을 기대할 수 있다.
하지만, 위젯이 포함된 페이지를 처음 실행될 때 다소 느릴 수 있고,
JavaScript 관련 개발 도구들을 알고
Hash Bang 이라는 매커니즘을 알고 있어야 한다.
이에 따라 개발 속도는 더뎌질 것이다.
또한 서버 측(Server Side) HTML 애플리케이션 아키텍처와 동일하게
웹/앱의 전환은 크게 기대할 수 없다.
따라서 단일 웹 애플리케이션으로 사용하기에는
적합한 아키텍처라고 볼 수 없을 것이다.
서비스 지향 단일 페이지 애플리케이션
(Service-oriented
single-page Web Apps)
SPA(Single Page Application)은 서버에서
새로운 페이지를 로드하지 않고,
기존 페이지 내의 업데이트 된 데이터만
상호작용 하는 동적 프레임 워크이다.
이러한 아키텍처를 기반으로 둔 애플리케이션은
필요한 컨텐츠의 세부 정보만 요청 한다.
SPA를 사용하면 새로운 요소가 업데이트되는 동안
페이지와 계속해서 상호 작용을 하기 때문에
페이지를 다시 불러오는 것과 같이
페이지와 사용자간의 빠른 상호 작용이 가능하다.
이 아키텍처를 사용하면 알림, 데이터 스트리밍을 구현 할 수 있다.
일반적으로 서버 쿼리는 JSON, Ehsms, HTML 형식을 사용하여
다양한 유형의 데이터를 전달 할 수 있다.
즉, 이 아키텍처를 사용한다면
업데이트를 포함한 기타 서버와
클라이언트간의 상호 작용을 최소화 할 수 있는 것을 포함해
웹 로직이 대게 클라이언트 측에 있기 때문에
서버 측은 중요한 비지니스 로직만 처리해주면 된다.
이에 따라 확장성 또한 훌륭하고 할 수 있을 것이다.
또한 웹/앱의 전환도 유연하다.
성능 면으로만 보면
위의 2개의 아키텍처에 비해 가장 뛰어나다고 할 수 있지만,
개발 속도가 느리며, 클라이언트 단이 무겁기 때문에
그 만큼 클라이언트 쪽에서 리소스가 쏠리며,
클라이언트에서 실행되어야 하므로
소스를 포함한 데이터들이 공개되기 때문에 보안이 가장 취약하다.
이에 포함되어 있는 것이 쿠키와 관련된 기술들이다.
따라서 이를 해결한 보안 아키텍처가 별도로 필요하다.
그렇다면 어떤 아키텍처를 사용해야할까?
그렇다면 어떤 아키텍처를 사용하는 것이 적절할까?
물론 이에 대한 해답을 바라는 사람들에게는
매우 안타까운 소식이겠지만,
상황에 따라 다르다.
하지만, 현재(2020년 기준) 대부분의 웹 애플리케이션에서
SPA(Single Page Application) 아키텍처를 사용하고 있기 때문에
대세에 따르는 것도 한 가지 방법일 수도 있다.
하지만,
꼭 그것이 모든 경우의 솔루션이 될 수 는 없다.
왜냐하면 진정한 솔루션이라는 것은 선택지 중에서
최고의 효율성을 제시할 수 있어야 되기 때문이다.
하지만 3개 종류의 선택지가 있다고
꼭 3개 중 하나 만을 선택하라는 법은 없다.
경우에 따라서는 아키텍처의 장점만을 살려서
시스템을 통합하는 것으로도 훌륭한 솔루션이 될 수 있다.
따라서 어떤 것 아키텍처를 사용해야될지에 대한 해답은
엔지니어 혹은 아키텍처들에게 물어보고 듣는 것이 빠를 것이다.
[1] Hash-Bang :
SheBang이라고도 불리우는 메커니즘으로
URL에 붙는 #! 같은 것들을 말한다.
여기서 Hash는 #를 뜻하고 Bang은 !를 뜻하는데
Hash(#)가 포함된 URL을 브라우저가 받으면
Hash 앞에 일부만 페이지 요청으로 처리하고,
Hash 뒷 부분은 페이지를 관련 위치로 이동하기 위해 보관 된다.
이력 :
2020.08.10 내용 대폭 개선 및 Web Framework의 역사 추가
2020.09.17 내용 다듬기 및 Web Framework의 역사 이동
아이콘 출처:
