웹 기술

seongmin·2022년 10월 3일

web

Java

목록 보기

23/30

웹

인터넷에서 제공되는 하이퍼텍스트 시스템

하이퍼텍스트: 문서안에 다른 문서의 위치정보 등을 포함하여 문서 간의 정보를 서로 연관 지어 참조 할 수 있는 문서.

최초에는 문자정보 전달에만 초점이 맞춰져 있었으나, 웹은 오늘날 게임, 동영상 서비스, 전자상거래, 거대 소셜미디어 서비스 등 다양한 용도로 활용되고 있다.

클라이언트-서버 아키텍처

웹에서 제공되는 서비스는 주로 서비스를 이용하는 클라이언트와 서비스 제공(서버)으로 나뉜다. 이러한 구조를 클라이언트-서버 아키텍처 라고 부른다.

Case : 쇼핑몰 앱

상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트-서버 아키텍처라고 부른다.

리소스를 사용하는 앱이 바로 클라이언트, 리소스를 제공(serve)하는 곳은 서버 라고 부른다.

상품 정보는 서버에서 다루고, 클라이언트는 단지 상품 정보를 조회할 뿐이다.

클라이언트와 서버는 요청과 응답을 주고받는 관계다. 클라이언트-서버 아키텍처에서는 요청이 선행되고 그 후에 응답이 온다. 요청하지도 않았는데 응답이 오는 경우는 없다.

일반적으로 서버는 리소스를 전달해 주는 역할만 담당한다. 리소스를 저장하는 공간을 별도로 마련해 두는데 이 공간을 데이터베이스 라고 부른다. 데이터베이스는 창고와 같은 역할을 한다.

이처럼 기존 2티어 아키텍처에 데이터베이스가 추가된 형태를 3티어 아키텍처 라고 부른다.

서버는 무엇을 하느냐에 따라 종류가 달라진다. `파일 서버` 는 파일을 제공하는 앱, `웹 서버` 는 웹사이트에서 필요로 하는 정보들을 제공하는 앱, `메일 서버` 는 메일을 주고받을 수 있도록 도와주는 앱이다.

데이터베이스도 데이터 제공자로서 일하므로 일종의 서버라고 볼 수 있다.

웹 애플리케이션 아키텍처

웹 애플리케이션은 아래와 같은 특징이 있다.

데스크탑 애플리케이션처럼 상호작용 가능하다.
특정 기능을 가지고 있다(정보 검색 등).
정보나 자료 등의 콘텐츠 관리 시스템과 함께 작동한다.

웹 개발 영역에서 website라고 하면 일반적으로 정적 페이지들의 집합체를 의미한다. 웹사이트가 정적 페이지들 뿐 아니라 동적 페이지를 포함하게 된다면 이미 web application 이 되게 된다.

오늘날 만들어지는 대부분의 웹사이트들은 사실 엄밀하게 이야기 하면 웹 애플리케이션들이다.

유저가 웹브라우저 에서 요청을 하면 애플리케이션의 다양한 요소들(브라우저, 유저 인터페이스, 미들웨어, 서버, 데이터베이스)이 상호작용을 한다. 웹 애플리케이션 아키텍처는 이러한 요소들이 상호작용을 유지할 수 있도록 서로를 결부시키는 뼈대라고 할 수 있다.

웹 애플리케이션은 인터넷에 공개되는 순간부터 글로벌 네트워크의 막대한 트래픽에 노출 될 수 있기 때문에 아래와 같은 요소를 고려해야 한다.

신뢰성(reliability)
확장성(scalability)
보안성(security)
견고성(robustness)

웹 애플리케이션의 요청흐름

특정 사이트 (ex. naver.com )에 접속할 시

브라우저에 naver.com 를 입력한다.

브라우저는 URL을 입력 받으면 서버의 주소를 찾기 위해 DNS 서버에 요청을 보낸다.

IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보낸다. 이미 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져온다.

웹서버에 요청이 도착한다.

웹서버는 저장소에 요청을 보내 페이지 관련 데이터들을 가져온다.

정보들은 가져오는 중에 비지니스 로직이 작용한다.

비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있다.

로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답한다.

요청들이 브라우저에 응답으로 돌아왔을 때, web page 화면에서 출력된다.

모든 애플리케이션은 client-side 와 server-side로 작동한다. 유저가 요청을 하면 크게는 두 프로그램이 작동을 한다.

유저의 입력에 따라 브라우저에서 작동하는 프로그램
HTTP 요청에 따라 서버에서 요청 처리하는 프로그램

Client-side 는 주로 HTML, CSS, and JavaScript 의 언어를 조합해 사용하여 개발을 진행한다. 개발되는 코드는 브라우저에 의해 분석되어 처리된다. 그리고 서버와의 소통은 HTTP 요청을 통해 이루어진다.

Server-side 는 주로 Java, Python, JavaScript, C#, PHP, Ruby on Rails 등 서버사이드에서 실행 가능하고 HTTP 요청에 응답할 수 있는 언어들이 사용된다.

웹 애플리케이션의 요소들

유저 인터페이스 요소 : 유저 인터페이스와 유저 경험과 관련된 요소들이다. 이 요소들은 화면 출력, 로그, 알림, 시스템 통계, 환경 설정 등 웹 애플리케이션의 기능적인 부분 외적인 요소들이다.
구조 요소 : 이 요소들은 웹 애플리케이션의 기능적인 부분을 담당한다. 유저와의 상호작용, 제어, 데이터베이스 등에 관련한 요소들이다. 웹 애플리케이션의 전체적인 구조를 담당하며, 구조 요소는 웹 브라우저나 클라이언트, 웹 애플리케이션 서버, 그리고 데이터베이스로 이루어져 있다.

웹 애플리케이션의 3단계 계층 구조

Presentation Layer : 이 계층은 유저와 브라우저 등을 이용해 직접적으로 접촉을 한다. Web Server가 이 영역에 포함되며, 유저 인터페이스 요소들을 포함한다.
Application Layer : Business Layer, Business Logic 혹은 Domain Logic 이라고 불리기도 하는 이 영역은 유저의 요청을 브라우저로부터 받아서 처리를 한다. Application Server가 이 계층에 포함되며 데이터 접근을 위한 경로를 규격화 하는 등의 과정이 이 계층에 작성이 된다.
Data access layer : Persistence layer 라고도 불리는 이 계층은 애플리케이선의 데이터 저장소에 접근하여 데이터를 불러 오거나 저장을 담당한다. Application Layer는 이 계층과 밀접한 연관을 가지고 있다. 이 단계를 통해 Application Layer의 로직들은 어느 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장할지를 더 최적화 할 수 있다.

주 3개 계층에 속하지 않은 웹어플리케이션 구조의 요소들

Cross-cutting : 이 요소들은 주로 보안, 통신, 운영 관리등을 위한 요소들이다.
Third-party integrations : 제 3의 API 서비스를 이용하는 것을 의미한다. 예를 들면, OAuth 2.0을 이용한 소셜 로그인, PG 사를 이용한 결재기능 등이 여기에 속한다.

웹 애플리케이션 구현

웹 애플리케이션을 구성하는 방식 3가지

Single Page Application

Single Page Application 에서는 유저의 입력과 요청에 의한 콘텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고 현재 페이지에서 이루어진다.

Single Page Application은 필수적인 요소만을 요청한다. 그리고 이러한 점은 페이지가 새로 고침 되는 것을 방지해 유저 경험을 극대화한다.

이러한 기능을 위해 AJAX, Asynchronous JavaScript, 그리고 XML 이 주로 사용된다.

이러한 Single Page Application의 기능을 통해 유저는 페이지가 새로 고침 되지 않고, 요청한 응답을 기다리면서 페이지와 상호작용이 가능하다.

Microservice architecture

작고 가벼운 특정한 한가지 기능에 집중한 웹 애플리케이션을 의미한다.

각 애플리케이션의 기능 요소들은 상호간에 의존적으로 설계되지 않는다. 따라서 개발단계에서도 그리고 개발 완성이후로도 같은 개발 언어를 사용할 필요가 없다.

개발자는 원하는 언어를 사용해 기능 개발에 유연성을 더 갖게 되고. 개발 과정의 전반적인 속도와 생산성이 향상 된다.

Serverless Architectures

Serverless Architecture는 개발자가 웹 애플리케이션의 서버와 기타 기반 기능들에 대해 외부의 3자인 클라우드 서비스 제공자에게 의탁하는 방식이다.

이 방식은 개발자가 기본적인 서버나 기반 기능들에 걱정할 필요 없이 특정기능의 개발에 집중 할 수 있게 한다.

웹 애플리케이션 구현 기술

HTTP

HTTP(HyperText Transfer Protocol) 는 웹 브라우저상에서 클라이언트와 서버간의 통신을 담당하는 무상태성의 프로토콜이다. HTTP는 클라이언트에서의 데이터 요청과 서버에서의 요청에 대한 응답을 반복하면서 웹 애플리케이션을 작동시킨다.

HTTP 요청을 할 때는 하고싶은 처리의 종류를 나타내는 메서드의 이름과 처리 대상의 이름이 포함된다.

HTTP 응답에는 요청에 대한 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리결과인 메시지가 포함된다.

처음에는 문서 전송에 주로 이용 되었지만, 오늘날 대용량의 이미지, 음성, 영상, 파일 데이터 등 거의 모든 방식의 데이터 전송을 HTTP를 이용해서 처리한다.

쿠키: 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 한다. 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 작동하게 도와준다.

Case 쇼핑몰 : 장바구니에 담았던 물품을 저장하여 추후에 찾는 수고로움이 없이도 확인이 가능한 방식
세션: 세션의 경우 서버에 Session-Id 라는 고유 아이디를 할당해서 유저를 식별한다. 단순하고 유출이 되면 안되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭해서 저장해 관리한다. 주로 사용되는 방법은, 세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적이다.

사용자 인증

사용자 인증은 컴퓨터나 특정 시스템 을 사용할 때 유저를 식별할 수 있는 ID 값과 암호를 입력하는 개념이다.

최근에 새로운 웹 애플리케이션에 가입할 때 개인 휴대전화로 일회용 패스워드를 받는다든가, 혹은 통신사 전용 소프트웨어를 사용하는 등의 추가인증 절차를 경험해 보았을 것이다.

은행과 같이 더 높은 보안을 요구하는 서비스는 물리적 하드웨어 토큰에 OTP를 사용하는 것까지 있다.

가장 일상적으로 접하는 것은, urclass를 접속할때 사용하는 OAuth 방식 의 로그인이다. 이 방식은 서비스 자격증명 메커니즘을 다른 믿을만한 제3의 서비스에 위임해 인증하는 방식이다.

심화 References

Microservice architecture

Serverless architecture

SSR vs CSR

SSR 은 Server Side Rendering의 줄임말이다. SSR이 서버 측에서 Javascript가 페이지를 렌더링한다면 CSR은 클라이언트에서 Javascript가 페이지를 렌더링한다.

웹 개발에서 사용하는 대표적인 클라이언트는 웹 브라우저다. 브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에 보낸다. 이때 서버는 웹 페이지와 함께 JavaScript 파일을 보낸다.

클라이언트가 웹 페이지를 받으면, 웹 페이지와 함께 전달된 JavaScript 파일은 브라우저에서 웹 페이지를 완전히 렌더링 된 페이지로 바꾼다.

웹 페이지에 필요한 내용이 데이터베이스에 저장된 데이터인 경우

브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링을 해야 한다. 이를 위해 API가 사용된다. 웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 해소한다.

브라우저가 다른 경로로 이동하면

CSR에서는 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않는다. 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링한다. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일이다.

차이점

CSR과 SSR의 주요 차이점은 페이지가 렌더링되는 위치다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링한다. 브라우저는 사용자가 다른 경로를 요청할 때마다 페이지를 새로고침 하지 않고, 동적으로 라우팅을 관리한다.

SSR 사용하는 경우

SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용한다.
웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR이 적합하다. 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있다.

CSR 사용하는 경우

SEO가 우선순위가 아닌 경우, CSR을 이용할 수 있다.
사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공한다. 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있다.

SSR 단점

자원이용이 서버에 집중되기 때문에 애플리케이션 유지비용이 높다.
일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있다.

CSR 단점

느린 렌더링 속도로 사용자 경험이 안 좋아질 수 있다. 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 때문에 사용자에 따라서 경험이 달라질 수 있다.
위에서 설명했듯 search engine bots와 상성이 안좋다. Javascript가 렌더링해야 하는 정보들은 Google과 같은 search engine index에 포함이 안될 가능성이 매우 높다.

SSR 예시

네이버 블로그

네이버 블로그는 2020년에 SSR 방식을 도입했다. 대표적인 이유는 SSR이 검색엔진 최적화(Search Engine Optimization, SEO)에 유리한 이점이 있기 때문이다. 블로그 같은 경우는 특히 검색엔진에 최대한 노출되는 게 유리하고, 다른 웹사이트에 비해 사용자와 상호작용이 많지 않기 때문에 SSR이 합리적인 선택이 될 수 있다.

The NewYork Times

뉴욕 타임스 홈페이지도 SSR 방식을 사용하고 있다. SSR의 대표적인 단점인 많은 사용자가 클릭할 때마다 전체 웹사이트를 다시 서버에서 받아오기 때문에 발생하는 서버 과부하 이슈가 있음에도 불구하고, CSR에 비해 초기 로딩 속도가 빠르기 때문에 구독자가 신문기사를 빠르게 읽을 수 있다는 장점이 있다. 뿐만 아니라 해당 신문사의 기사가 검색엔진에 노출되는 것이 중요하기 때문에 SEO(Search Engine Optimization)에 유리한 SSR을 이용하고 있다.

CSR 예시

아고다

아고다뿐만 아니라 많은 예약 사이트들은 CSR을 사용하고 있다. SSR 에서는 서버에서 렌더링을 해야 하기 때문에 상호작용(interaction)이 많아질수록 서버에 부담이 많은 반면에, CSR 에서는 서버가 클라이언트에 필요한 데이터만 넘겨주기 때문에 부담이 적다. 그리고 SPA(Single Page Application) 를 기반으로 화면의 일부만 받아온 데이터로 변경해주기 때문에 빠른 렌더링으로 User Experience(사용자 경험)에 유리하다.

Reference