Computer Engineering/네트워크(Network)

[Web] 웹 애플리케이션 아키텍처 개념 정리 및 구현, 기술

잇트루 2022. 10. 4. 06:00
반응형

웹 애플리케이션 아키텍처란?

웹 애플리케이션의 구조를 간단하게 도식화하면 위 이미지로 나타낼 수 있다.

웹 브라우저를 통해 클라이언트의 요청에 따라 웹 서버에 도달하게 되고, 애플리케이션 서버와 데이터베이스를 거쳐 필요한 리소스를 받아 클라이언트로 응답한다. 이때 클라이언트는 결과를 화면에 표시하게 된다.

 

웹사이트 vs 웹 애플리케이션

웹사이트(Website)와 웹 애플리케이션(Web application)은 일상에서 혼용하여 사용하기도 한다. 하지만, 엄밀히 말하면 이 둘은 서로 다른 개념이다.

 

웹 개발 영역에서 웹사이트(Website)는 일반적으로 정적 페이지들의 집합체를 의미한다.

만약, 웹사이트에서 동적 페이지를 포함하게 되면 이는 웹 애플리케이션(Web application)이 된다.

 

웹 애플리케이션의 특징

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

 

그렇다면 네이버(naver.com)와 페이스북(facebook.com)은 웹사이트일까? 웹 애플리케이션일까?

정답은 네이버와 페이스북 모두 웹 애플리케이션이다. 오늘날 만들어지는 대부분의 웹 서비스들은 엄밀히 말하면 웹 애플리케이션들이다.

 

웹 애플리케이션 아키텍처

웹 애플리케이션 아키텍처는 클라이언트-서버 간의 연결에 대한 설명 방법이다. 즉, 웹 애플리케이션 아키텍처는 애플리케이션 내부의 요소들이 상호 간에 어떻게 소통하는지를 설명한다.

 

사용자가 웹 브라우저에서 요청을 하면, 애플리케이션의 다양한 요소(브라우저, 인터페이스, 서버, 데이터베이스 등)들이 상호작용을 하게 된다.

웹 애플리케이션 아키텍처는 이러한 요소들이 상호작용을 유지할 수 있도록 서로를 연관 짓는 뼈대라고 할 수 있다.

 

웹 애플리케이션은 사용자의 수 많은 요청에 알맞은 응답을 할 수 있어야 한다. 따라서 웹 애플리케이션 서버는 요소와 외부 애플리케이션을 서로 공유하여 설계하게 된다.

 

또한, 인터넷에 공개되는 순간부터 글로벌 네트워크의 막대한 트래픽에 노출될 수 있기 때문에 신뢰성, 확장성, 보안성, 견고성에 대해 고려하면서 설계해야 한다.

 

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

만약, 브라우저에서 구글(https://google.com)에 접속한다면 웹 애플리케이션은 다음과 같은 순서로 진행하게 된다.

  1. 브라우저에 구글 주소를 입력하여 접속한다.
  2. 브라우저는 URL을 입력받으면, 서버의 주소를 찾기 위해 DNS 서버에 요청을 보낸다.
  3. DNS 서버에서 IP주소를 찾으면 해당 주소에 HTTPS 요청을 보낸다. (만약, 이미 방문 기록이 캐시 메모리에 있으면 IP 주소를 캐시 메모리에서 가져온다.)
  4. 웹서버에 요청이 도착하여 웹 서버는 데이터베이스에 요청을 보내 페이지 관련 데이터들을 가져온다.
  5. 정보들을 가져오는 과정에서 비즈니스 로직이 작동한다.
  6. 로직들을 통해 요청받은 데이터들이 처리되고 브라우저에 응답한다.
  7. 요청들이 브라우저에 응답으로 돌아왔을 때, 웹 페이지 화면에 출력한다.

 

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

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

 

따라서 웹 애플리케이션을 개발하기 위해서는 브라우저의 기능 개발과 서버 기능 개발을 하게 된다.

브라우저의 기능 개발 영역을 front-end, 서버 기능 개발 영역을 back-end라고 한다.

이를 흔히 보이는 영역을 front-end, 보이지 않는 영역을 back-end라고도 한다.

 

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

 

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

 

웹 애플리케이션의 요소

웹 애플리케이션은 다양한 요소들로 이루어져 있다. 이러한 컴포넌트는 유저 인터페이스 요소와 구조 요소 두 가지 영역으로 나눌 수 있다.

 

유저 인터페이스 요소

유저 인터페이스와 유저 경험과 관련된 요소들이다. 화면 출력, 로그, 알림, 시스템 통계, 환경 설정 등 웹 애플리케이션의 기능적인 부분의 외적인 요소이다.

 

구조 요소

구조 요소는 웹 애플리케이션의 기능적인 부분으로 유저와의 상호작용, 제어, 데이터베이스 등에 관련된 요소들이다. 웹 애플리케이션의 전체적인 구조를 담당하며, 웹 브라우저나 클라이언트, 웹 애플리케이션 서버, 데이터베이스로 이루어져 있다.

 

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

웹 애플리케이션의 구조는 다양한 단계와 계층으로 나뉜다. 하지만 크게 3단계로 구분할 수 있다. 이를 웹 애플리케이션 3단계 계층 구조(Web Application Three Tier Architecture)라 한다.

Presentation Layer : 유저와 브라우저 등을 이용해 직접적으로 접촉을 하는 계층으로 웹 서버와 유저 인터페이스 요소들이 이 영역에 포함된다.

 

Application Layer : 비즈니스 계층, 비즈니스 로직 또는 도메인 로직이라고도 불리며 유저의 요청을 브라우저로부터 받아서 처리하는 계층이다. 애플리케이션 서버가 이 계층에 포함되며, 데이터 접근을 위한 경로를 규격화하는 등의 과정이 작성된다.

 

Data access Layer : Persistence Layer라고도 불리며 애플리케이션의 데이터 저장소에 접근하여 데이터를 불러오거나 저장을 담당하는 계층이다. Application Layer는 이 계층과 밀접한 연관을 가지고 있다. Application Layer의 로직들은 어느 데이터베이스에 접근해서 데이터를 회수하고 저장할지를 최적화할 수 있다.

 

Cross-cutting : 주로 보안, 통신, 운영 관리 등을 위한 요소들이다. Spring 프레임워크의 AOP 개념과 밀접한 연관이 있다.

 

Third-party integrations : 제3의 API 서비스를 이용하는 것을 의미한다. 예를 들면, OAuth 2.0을 이용한 소셜 로그인 API, PG 사를 이용한 결제 API 등이 속한다.

 

웹 애플리케이션의 구현

웹 애플리케이션을 구현하는 방식은 크게 싱글 페이지 애플리케이션, 마이크로서비스 아키텍처, 서버리스 아키텍처 세 가지 방식이 있다.

 

싱글 페이지 애플리케이션(Single Page Application)

오늘날 만들어지는 많은 웹 애플리케이션들은 싱글 페이지 애플리케이션으로 만들어진다. 위 이미지와 같이 직관적으로 알기 쉽고 상호작용 가능한 요소들을 이용해 유저 경험을 극대화한다.

 

싱글 페이지 애플리케이션은 유저의 입력과 요청에 의한 콘텐츠나 정보의 최신화가 페이지를 새로 불러오지 않고 현재 페이지에서 이루어진다.

따라서 필수적인 요소만을 요청하며 페이지가 새로 고침 되는 것을 방지하여 유저 경험을 극대화한다.

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

 

즉, 싱글 페이지 애플리케이션의 기능을 통해 유저는 페이지가 새로 고침 되지 않고, 요청한 응답을 기다리면서 페이지와 상호작용이 가능하다.

 

마이크로서비스 아키텍처(Microservice architecture)

마이크로서비스 아키텍처는 작고 가벼운 한 가지 기능에 집중한 웹 애플리케이션을 의미한다.

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

 

마이크로서비스 아키텍처는 개발자가 원하는 언어를 사용하여 기능 개발에 유연성을 더 갖게 되고, 개발 과정의 전반적인 속도와 생상성이 향상된다.

 

서버리스 아키텍처(Serverless Architecture)

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

 

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

서버리스 아키텍처의 기술에는 BaaS와 FaaS 등이 있다.

 

BaaS(Backend as a Service)는 애플리케이션 개발에 있어서 필요한 기능들을 API로 제공해 줌으로 개발자들의 서버 개발을 하지 않고서도 필요한 기능을 쉽고 빠르게 구현할 수 있도록 하는 기술이다. 해당 기술을 사용한 만큼 비용이 발생하지만, 서버의 이용자가 순식간에 늘어나더라도 알아서 확장된다.

 

FaaS(Function as a Service)는 프로젝트를 여러 개의 함수로 쪼개어 분산된 컴퓨팅 자원에 등록하여 함수들이 실행되는 횟수만큼 비용을 내는 방식이다.

 

웹 애플리케이션 구현 기술

HTTP

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

 

HTTP 요청을 할 때는 하고 싶은 처리의 종류를 나타내는 메서드의 이름과 처리 대상의 이름이 포함되며, HTTP 응답에는 요청에 대한 처리 결과를 나타내는 상태 코드와 헤더, 실제 처리 결과인 메시지가 포함된다.

 

HTTP는 문서뿐만 아니라 대용량의 이미지, 오디오, 영상, 파일 등 대부분의 데이터 전송을 처리한다.

 

쿠키(Cookie)와 세션(Session)

HTTP는 데이터를 요청하고 요청에 대한 응답을 전송하는 무상태성의 프로토콜이다. HTTP 프로토콜만을 가지고 웹의 모든 기능들을 처리하는 데에는 한계가 있다.

따라서 특정 상황에 대응하기 위해 쿠키와 세션을 사용한다.

 

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

 

세션은 서버에 Session-Id라는 고유 아이디를 할당하여 유저를 식별한다. 단순하고 유출이 되면 안되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭해서 저장하여 관리한다. 주로 세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적이다.

 

사용자 인증

사용자 인증은 사용자 식별용 아이디와 암호뿐만 아니라, 개인의 신원 등을 파악하는 다요소 인증(MFA) 등의 방식 모든 것을 뜻한다.

이러한 과정은 다른 사람이 컴퓨터나 시스템의 이용을 하지 못하도록 차단하기 위해 사용한다

웹 애플리케이션에 가입할 때 인증 번호, 통신사 전용 프로그램을 사용하는 추가 인증, 은행과 같은 높은 보안을 요구하는 서비스의 OTP 등도 사용자 인증에 포함된다.

반응형