- 웹 애플리케이션이란 무엇인가?
- www란 무엇인가?
- www 3대 요소 (HTML, HTTP, URI)
- 웹 서버와 웹 클라이언트. 왜 클라이언트와 서버로 역할을 나누는가?
- CGI의 필요성과 개념
- 서블릿의 등장과 개념
- JSP의 등장과 개념
웹 애플리케이션(web application)이란 무엇인가?
웹 서버를 통해 간접적으로 실행시키는 프로그램
웹 세계를 탐험하기 전, 웹 애플리케이션이 무엇인지부터 알아보자.
일단 애플리케이션(application)은 '응용 프로그램'을 의미한다. 그 앞에 웹(web)이 있다. 즉 말 그대로 웹 브라우저에서 실행되는 소프트웨어인 것이다. 어라? 그러면 웹 브라우저에서 구동된다는 건 무슨 의미일까?
일단 우리 컴퓨터에 저장된 소프트웨어를 생각해보자. 무엇이 있는가? 기본적으로 문서 작업을 위한 '워드 프로세서', '엑셀' 같은 프로그램이 있을 것이다. 우린 이들도 응용 프로그램이라고 부른다. 기본적으로 우리 컴퓨터 내부에 설치되어 실행되는 응용 프로그램들을 데스크톱 애플리케이션으로 지칭한다. 데스크톱 애플리케이션의 특징을 살펴보자. 일단 해당 애플리케이션을 PC에 설치해야 한다. 마이크로소프트 홈페이지에서 다운을 받던지, CD나 USB로 설치 파일을 가져와 인스톨을 해야 한다. 자, 설치된 프로그램을 실행시켜 사용하면 우리의 운영체제가 컴퓨터 내부에서 처리된 로직을 화면에 출력시켜준다. 결국 데스크톱 애플리케이션은 사용자 컴퓨터의 내부 자원을 이용해 요청을 수행하고 결과를 출력한다. 따라서 설치한 애플리케이션은 설치된 컴퓨터에서만 작동한다. 당연한 이야기!
반면 웹 애플리케이션은 사용자가 구입하거나 직접 설치할 필요가 없다. 어떻게 가능하나고? 웹 애플리케이션이 구동되는 위치가 사용자의 컴퓨터가 아니라 서버라고 불리우는 컴퓨터에서 이뤄지기 때문이다. 이미 우리는 웹 애플리케이션을 익숙하게 사용하고 있다. 대부분 사용자가 네이버란 애플리케이션을 다운 및 설치하지 않고도 인터넷에 www.naver.com을 입력하는 것만으로 네이버가 제공하는 다양한 서비스를 즐길 수 있다.
웹 애플리케이션의 목적은 사용자의 능동적인 활용에 있다. 이미 정해진 콘텐츠를 단순 소비하는 것이 아니라, 사용자의 의도에 따라서 매번 다른 로직이 수행되고 결과도 바뀌는 성격을 가진다. 예를 들어 네이버 지도를 보자. 네이버 지도를 실행할 때마다 매번 똑같은 위치 정보만 나온다면 매우 제한된 사용을 초래한다. 진정한 지도 앱이라면 출발지와 목적지를 사용자가 입력하고, 시간 및 상황에 따라서 최적 경로와 예상 도착 시간이 출력되어야 한다. 과거의 인터넷은 이러한 복잡하고 다이나믹한 수행은 처리할 수 없었다. 데스크톱 애플리케이션에서만 가능했다. 하지만 오늘날은 인터넷을 통해 사용자의 의도와 목적에 따라 동적인 결과를 도출할 수 있다. 그리고 이를 가능케 하는 존재를 웹 애플리케이션이라고 한다.
| 데스트톱 애플리케이션 | 웹 애플리케이션 | |
| 로직 처리 주체 | 사용자 PC | 서버 PC |
| 화면 표시 | 운영체제상에서 표시 | 웹 브라우저에서 표시 |
| 설치 | 필요 | 불필요 |
WWW 이란 무엇인가?
초기 인터넷은 1969년 탄생했다. 하지만 워낙 컴퓨터와 네트워크 자원이 고가였고, 이용 용도가 이메일 및 파일 공유와 같은 단순한 정보 교환이었기 때문에 범용성이 떨어졌다. 아직 웹(web)이 등장하기 이전이었다.
이로부터 20년 뒤, 인터넷의 보급은 유럽 원자핵 연구 기관(CREN)의 '버너스 리' 박사의 한 가지 발명으로부터 시작됐다. 버너스 리 박사는 연구 성과를 다른 연구자와 쉽게 공유할 수 있는 방법을 찾았고 그 결실이 WWW 였다.
World Wide Web이란, 네트워크 상에서 링크된 하이퍼링크의 연결이 마치 거미집처럼 보인다는 의미이다. 즉 하이퍼링크가 전 세계에 거미집처럼 퍼져 있다는 재미있는 뜻을 담고 있다.
어? 그러면 하이퍼링크란 무엇인가? 그건 곧 알아보자.
World Wide Web 3대 요소
버너스 리에 의해 정보 공유를 위한 3가지 기술이 개발됐다.
HTML (Hyper Text Markup Language)
웹 페이지를 만들기 위한 마크업 언어
연구 성과를 표현하려면 문장뿐 아니라 도표, 참고 문헌 등이 필요하다. 이를 문자만으로 구성된 텍스트 파일만으로 표현할 수 있도록 통일된 형식이 HTML이다.
HTML의 앞 부분 '하이퍼텍스트'는 문서 간의 참조가 하이퍼링크(Hyper Link)라는 형식으로 작성돼 있어 참조하는 곳의 문서를 순식간에 열람할 수 있는 커다란 장점을 가진다. 과거에는 참고 문헌이나 관련 논문 등을 수작업으로 참조해야 했기 때문이다.
HTTP (Hyper Text Transfer Protocol)
웹 서버와 웹 클라이언트가 통신하기 위한 공통된 통신 프로토콜
다른 사람과 의사소통을 하기 위해선 일종의 규칙이 필요하다. 평소 우리 언어도 마찬가지다. 단어(정보)를 주어, 동사, 목적어에 맞춰 전달해야 상대방이 알아 듣는다. 배운 적 없는 태국어, 베트남어, 아일래드어를 들으면 이해가 하나도 안되는 것도 우리가 해당 단어와 문법을 모르기 때문이다.
컴퓨터도 마찬가지이다. 각기 다른 운영체제, 웹 브라우저가 서로 자신만의 언어로 의사소통을 하려고 고집한다면 컴퓨터끼리의 대화는 불가능하다. 모든 컴퓨터의 언어를 배워야 한다 치더라도 비용이 엄청날 것이다. 인간도 전 세계의 언어를 다 배우는 건 비효율적이라서 '영어'란 공용어를 이용해 국제무대에서 의사소통을 하지 않는가.
이처럼 컴퓨터끼리 HTML이란 정보를 교환하기 위해 통일한 약속이 필요했다. 그 결실이 HTTP이다. 일반적으로 약속을 프로토콜(protocol)이라고 한다. '하이퍼텍스트를 전송하기 위한 약속'이란 뜻의 HTTP는 요청을 보내는 컴퓨터와 요청을 받는 컴퓨터 사이에 의사소통을 가능하게 만들었다.
URI (Uniform Resource Identifier)
인터넷 상의 자원을 식별하는 식별자
오케이! 그러면 컴퓨터는 HTTP를 통해 HTML이란 문서 주고 받으며 정보를 교환한다는 사실을 알았다. 그런데 어떤 HTML문서를 요청을 받는 컴퓨터(서버)는 요청한 컴퓨터(클라이언트)에게 줘야 할까? 상대방이 필요없는 물건을 주면 선물이 아니라 쓰레기가 될 뿐이다.
서버 컴퓨터는 궁예가 아니기 때문에 상대방이 무엇을 원하는지 알 수 없다. 클라이언트 컴퓨터가 직접 친절히 원하는 정보를 알려줘야 한다.
당연히 여기에도 통일된 화법이 필요하다. 서로의 언어를 모르는 직원이 외국인 손님을 응대할 때 그가 어떤 음료를 주문하는지 알 수 없다(바디 랭귀지가 없다는 가정하에...). 그래서 클라이언트는 서버가 이해할 수 있는 방식으로 '정확하게' 자신이 원하는 자원(정보)를 요청해야만 한다.
URI는 인터넷상의 자원(정보)을 고유하게 지정하기 위한 식별자이다. 고유의 식별자란 의미가 중요하다. 회사에서 업무에 바쁜 내가 신입 사원에게 서류를 요청해야 하는 상황을 생각해보자.
나: 계약서 복사본 가져와 주세요~
신입사원: ?? (어디에 있는 어떤 계약서를 말하는거지?)
아무것도 모르는 신입사원에게 정확하게 자원의 위치와 해당 자원을 식별할 수 있는 정보를 한번에 알려줘야 한다.
나: 사무실 101호 왼쪽 책상 위에서 두 번째 서랍 속에 있는 '무한상사 계약서' 가져와 주세요~
신입사원: 넵!!
이처럼 서버 컴퓨터(신입사원)이 찾아야 하는 위치와 자원의 정보를 지정하는 통일된 기술 방법이 URI이다.
웹 서버(web server)와 웹 클라이언트(web client) 역할을 나누는 이유
불특정 다수가 가장 효율적으로 자원에 접근하고, 다수의 자원의 관리를 용이하도록 하기 위해 역할을 분담
WWW에서는 웹 서버가 하이퍼텍스트(HTML)를 가지고 있다가 웹 클라이언트의 요청에 따라 필요한 HTML 파일을 건네주는 구조로 되어 있다. 웹 클라이언트의 요청(request)에 웹 서버가 응답(response)하는 것이다.
흠... 그런데 왜 클라이언트와 서버로 나눌까?
그 이유는 간단하다. WWW와 같이 다양한 콘텐츠를 불특정 다수에게 공개하려면 되도록 콘텐츠를 한 곳에 정리하는 게 관리에 용이하다. 만약 같은 콘텐츠를 여러 곳에 분산 저장해 놓으면 수정 및 삭제 등이 어려워진다. 모든 콘텐츠를 동시에 갱신해야 하기 때문이다. 따라서 WWW를 구현하려면 웹 서버와 같이 컴퓨터 하나에 정보를 모아 두는 편이 좋다.
또한 많은 사람들이 자유롭게 콘텐츠를 열람할 수 있어야 하는데, 사용자가 해당 콘텐츠를 열람하기 위해서 그 콘텐츠를 보관하는 웹 서버를 직접 조작하는 것을 비현실적이다.
사용자 PC를 웹 클라이언트로 하고, 멀리 떨어져 있는 웹 서버와 인터넷으로 연결함으로써 서로의 역할을 분담한 최적의 방법을 찾았다.
CGI (Common Gateway Interface) 의 등장
웹 서버와 프로그램 사이에서 요청과 응답을 주고받기 위한 규약(인터페이스)
기존의 웹은 '이미 작성된 문서(콘텐츠)'를 공유하는 것이 목적이었다. 웹 서버가 하는 일은 클라이언트가 요청한 URI에 해당하는 리소스(파일)를 전달하는 것뿐이다. 다시 말해 서버 컴퓨터의 디렉토리 내 '정적인 페이지'를 찾아서 있는 그대로 클라이언트에게 넘겨주는 것이다.
하지만 매번 동일한 콘텐츠만 제공되니 새로운 욕구가 생겼다.
"흠, 시간에 따라서 페이지에 문구가 달리 나왔으면 좋겠는걸?"
"현재 방문자 수가 표시되면 좋겠다"
사이트에 역동성을 주기 위해선 항상 새로운 콘텐츠를 제공해야만 했다. 하지만 사람이 매번 콘텐츠를 갱신하기는 불가능했기에 컴퓨터가 자동으로 갱신해주도록 변화가 시작됐다. 웹 서버에서 동작하는 프로그램을 만들어 사람 대신 콘텐츠를 생성하면 어떨까란 아이디어가 떠올랐고, 이와 같은 프로그램이 생성한 HTML 등의 콘텐츠를 동적 콘텐츠라고 불렀다.
자, 동적 콘텐츠를 만들려면 웹 서버와 프로그램을 연동시켜야 한다. 웹 서버가 프로그램에게 '동적 콘텐츠' 생성을 요청하고 만들어진 HTML을 받아서 클라이언트로 보내야 하기 때문이다. 그래서 고안한 것이 CGI(Common Gateway Interface)라는 구조이다.
CGI는 웹 서버가 받은 클라이언트의 요청을 웹 서버상에서 작동하는 프로그램에 보낸다. 프로그램은 요청을 참조해 HTML을 생성한 다음 웹 서버에 돌려보낸다. 그러면 웹 서버는 프로그램으로부터 받은 HTML을 마치 미리 준비돼 있었다는 듯이 클라이언트에게 주는 메커니즘이다.
서블릿 (Servlet) 의 등장
자바로 만들어진 CGI 프로그램
늘어나는 웹에 대한 관심과 수요... CGI는 웹에 각종 서비스를 제공하거나 광고를 싣을 수 있게 만들었다. 이제 전 세계 사람들이 이용하는 거대한 미디어로 성장했다.
그러나 CGI를 이용한 웹 애플리케이션에 대한 문제점이 하나씩 발견됐다.
먼저 CGI의 프로그램은 펄(Perl)이라는 프로그래밍 언어로 구현됐는데, 웹 애플리케이션에 요구되는 기능의 규모가 커지고 복잡해지면서 텍스트 처리에 강점이 있는 언어였던 펄의 한계가 드러났다. 또한 펄은 객체지향 프로그래밍도 지원하지 않았다.
그리고 웹 브라우저에서 요청이 도착할 때마다 CGI를 통해 콘텐츠를 생성하는 프로그램의 프로세스를 기동했다. 접속 수가 수만, 수십만으로 늘어나면서 프로그램의 기동 처리가 많아지면 요청을 따라집지 못하게 되는 성능상의 이슈도 문제였다.
이러한 문제의 해결책으로 자바(Java)로 만들어진 서블릿(Servlet)이다.
(자바로 만들어진 CGI 프로그램이라고 보면 된다)
서블릿은 HTML 등의 웹 콘텐츠를 생성하기 위한 프로그램으로 CGI와 동일한 개념이지만, 객체지향을 지원함으로써 대규모 애플리케이션 개발에 적합하다는 점과 웹 서버와 같은 프로세스 속에서 콘텐츠를 생성하는 프로그램이 작동하기 때문에 CGI처럼 새로운 프로세스를 매번 기동할 필요가 없다는 장점을 가졌다.
앞서 CGI가 요청마다 프로세스를 만들어서 처리하는 것이 약점이라고 하지 않았나. 서블릿은 각 요청에 대해 프로세스를 생성하지 않는다. 프로세스는 단 한 개만 존재하고, 내부에 스레드 풀이라는 스레드들을 관리하는 공간을 만들어 멀티스레드로 처리한다.
JSP (Java Server Pages) 의 등장
HTML 코드와 자바 코드를 조합하여 동적인 웹 페이지를 생성하는데 사용하는 자바 기반의 프로그램
대규모 개발에 적합한 서블릿이 보급됨에 따라 새로운 문제가 대두됐다.
서블릿은 화면에 보여지는 부분을 프로그래밍 언어 속에 넣었다. 즉 출력 내용을 서블릿 내부에서 결정하는 것이다. 이것이 문제가 됐다. 화면을 디자인하는 사람이 HTML 코드를 수정하다가 프로그램을 망가트릴수 있고, 또 작업 효율도 좋지 못하다. 또한 서블릿을 통해 출력되는 HTML을 상상하기도 어렵다.
이러한 문제를 해결하기 위해 발상의 전환을 이뤘다.
JSP에서는 동적으로 출력하고 싶은 부분을 <%, %>로 묶고 그 안에 자바 프로그램을 기술할 수 있다. 보통 동적 콘텐츠라면 페이지의 일부분만 변경할텐데, 페이지를 구성하는 HTML을 기본으로 삼고 변경되는 부분만 자바로 작성하는 JSP는 서블릿의 한계를 극복했다.
참고자료
- 프로가 되기 위한 웹기술 입문 책
- https://hyena.oopy.io/3945fc1a-8b1d-420b-9711-c666f9f90899