개요

톰캣이 뭐임? 톰과 제리의 그거임?

 얘를 말하기 전에 아파치 소프트웨어 재단에서 만든 아파치 HTTP 서버에 대해서 짚고 가야할 게 있음

HTTP가 뭐임?

 HTTP는 다들 알다시피 링크 앞에 붙는 그거다! 당장 이 블로그의 도메인이 laylia.tistory.com 이지만, 이러한 도메인명 만으로는 해당 장소를 어떤 방식으로 접근해야할지 프로그램 입장에서는 제대로 눈치를 못 깐다. 도메인명은 IP의 대명사같은 친구고... 그럼 이걸 영어(FTP?)로 대화할지 한국어(HTTP?)로 대화할지 일본어(TCP?)로 대화할지는 별개의 문제니까...

 그래서 인터넷 브라우저를 통해 전국의 웹 페이지를 보려면 당연히 전국적으로 프로토콜을 통일해서 사용해야했고, 그렇게 쓰기로 한 프로토콜의 이름이 HTTP(하이퍼텍스트 트랜스퍼 프로토콜이었나...)이다. 그래서 도메인 앞에 http나 https가 붙는 것! 만약 ftp나 다른 프로토콜을 쓴다면 앞의 프로토콜 이름을 바꿔서 사용할 필요가 있다. 그러므로 웹페이지의 주소는 laylia.tistory.com 라기보다는 https://laylia.tistory.com/ 가 좀 더 올바른거임~

 아무튼 그래서 이 프로토콜을 통해서 해당 서버로부터 문서를 내려받을 수 있다. HTTP는 텍스트, 즉 문서를 여럿이서 보기 위한 목적으로 짜여졌기 때문! 이렇게 HTTP로 문서를 내려받을 땐 문서의 크기가 크지 않으므로 TCP를 활용하게 되며, 하이퍼텍스트라는 이름답게 다른 하이퍼링크를 통하게 되면 UDP나 FTP도 적절히 사용하게 된다. 요약하자면 이런 느낌이다.

 HTTP: 주소에 맞는 문서 좀 주세요~ 하고 편지를 보내는 용도
 TCP: 그렇게 해당되는 문서 파일을 받는 정도의 용도 (밑의 두 프로토콜에 비해 체크하는 게 많아서 좀 느림)
 UDP: 파일이 좀 큰데 불완전해도 괜찮음 (동영상 같은 거)
 FTP: 파일이 좀 큰데 완벽해야함! (압축 파일 같은 거)

 그런데 이걸 그냥 txt 파일로 나눠쓰기에는 아무래도 가독성이 떨어졌으므로, 워드의 docs 확장자나 한글의 hwp 확장자처럼 http 브라우저로도 문서를 표현하기 위한 확장자를 만들어서 이쁘게 만들 수 있게 해두었다. 그게 html 확장자임! html은 안을 살펴보면 그냥 텍스트 파일이지만, 컴퓨터 언어처럼 구성되어 브라우저가 처리할 수 있게 구조가 짜여져있다. 그래서 우리는 예쁘게 가공된 웹 페이지를 볼 수 있는 거시다.

 문서를 공유한다는 목적의 프로토콜과 브라우저가 생긴 것은 좋았으나, 문서를 공유할 수 있는 서버를 만드는 게 아무래도 컴퓨터 비전문가들에게는 어려운 노릇이었다. 나는 그냥 자작 소설을 담은 문서를 공유하고 싶은데, 그거 하나를 위해서 위해서 서버 동작 원리와 어려운 컴퓨터 언어, 거기에 다른 모듈까지 전부 배워야 한다고 생각하면 얼마나 끔찍하겠는가? 그런 불편함이 예전부터 있어왔기에, 여러 재단에서 웹 서버를 만들게 된다.

 이번에 다루는 건 그 중 하나인 아파치 소프트웨어 재단에서 만든 아파치 HTTP 서버다!

아파치 HTTP 서버 (안 아픔)

 사실 이 이전에도 웹 서버는 있었다. CERN HTTPD나, NCSA HTTPD 같은 것이 예이다. 물론 우리가 지금 코볼, 알골, 포트란 같은 노쇠한(...) 언어를 배우지 않듯 앞의 웹 서버들도 시대의 흐름에 묻혀 잘 쓰이지 않는다.

 일단 웹 서버라는 것은 실행시키면 80번 포트(HTTP가 사용하는 포트, HTTPS의 경우 443번인데 둘 다 기억할 필요는 없을 듯)를 열어서 사용자들의 문서 요청을 받고, 거기에 해당하는 문서를 작성해서 보내주는 것을 목적으로 하고 있다.

 하지만 우리가 이 과정을 전부 컴퓨터 언어로 작성하기에는 인간의 한계라는 게 있으므로 불가능한 일... 이 웹 서버를 실행시키는 것으로 그런 귀찮은 일이 대부분 해소된다고 보면 된다.

 아파치 HTTP 서버를 실행시키는 것만으로도 충분히 html 파일의 송수신은 가능하다. 정말정말 쉽게 굴리고 싶고 나는 JSP나 ASP같은 것을 쓸 생각이 없다! 라고 생각한다면, Bitnami의 WAMP나 아파치의 XAMPP 등 아파치 HTTP 서버를 필두로한 일종의 패키지 상품이 마련되어 있으므로 그런 걸 다운로드 받아서 써보는 것도 좋다. 무려 exe 파일이 제공되므로 말 그대로 더블 클릭만 하면 본인 IP의 웹 서버를 열 수 있다!

 심지어 조금 능숙해진다면, 아파치 웹 서버 특유의 확장성을 활용한 다양한 모듈들을 붙여 여러가지 형태의 웹사이트를 꾸릴 수 있게 된다. 대표적으로 PHP와 DBMS가 있다. 이 둘만 알고 있어도 똑같은 웹 페이지의 구성물을 완전히 다르게 바꿔줄 수 있다!

 하지만 당시에는 PHP의 기능이 지금처럼 쓸모있지도 않았고, 개발자들은 좀 더 쉽게 웹 페이지를 관리할 수 없을지, 자신들이 임의로 만들어 둔 시스템에서 페이지를 가공한 다음 보여줄 수 있는 방법이 없을지 고민하게 됐다. 이 때 자바를 개발했던 썬 마이크로시스템즈라는 회사에서 그런 부분에 대해 인지하고 있었고, 얼마 지나지 않아 톰캣이라는 WAS(웹 어플리케이션 서버)를 공개한다.

 ※ 지금은 nginx(엔진엑스)의 위세도 꽤나 등등해져서 아파치 HTTP 서버만 고집할 일이 아니게 되었다...! 이 외에도 웹 서버는 마소에서 만든 IIS(인터넷 인포메이숀 스-비스), node.js 등 찾아보면 꽤 있다.

웹 어플리케이션 서버는 또 뭐임?

 기본적으로 사용자가 웹 페이지를 보고자 할 때 아래와 같은 과정을 거치게 된다.

 1. 사용자 -> 인터넷에 자신이 입력한 도메인(naver, daum...)에 해당하는 문서를 요청한다.
 2. 웹 서버 -> 해당 도메인을 가진 서버에서 요구하는 문서를 찾는다.
 3. 웹 서버 -> 내부 모듈이 있는 경우 실행하여 문서를 가공한다.
 4. 웹 서버 -> 가공된 문서를 사용자에게 보내준다.
 5. 사용자 -> 사용자는 좋아죽는다.

 이 때 3번 정도의 위치에서 문서를 가공하는 과정중에 WAS가 힘을 쓰게 된다. 일단 WAS는 아래과 같은 특징을 가진다.

 1. 웹 서버와 연결되어, 웹 서버 뒤에서 작동한다.
 2. 컴퓨터 프로그래밍 언어에 의해 컴파일되어 평소에 코딩하던 것과 똑같이 작동한다.
 3. 런타임 라이브러리를 가질 수 있다.
 4. DBMS와 연결하여 DBMS 앞에서 작동한다.

 그냥 웹 서버에 붙은 컴퓨터 프로그램이라도 봐도 되겠다. 아무튼... 웹 서버에서 넘겨받은 정보를 가지고서 WAS가 페이지를 새로 가공하게 되고, 이 때 직접 작성하고 컴파일된 컴퓨터 언어를 쓰게 되므로 해당 언어가 지원되는 외부 라이브러리나 DB, 다른 독립된 프로그램과의 교신을 할 수 있게 된다. 즉 페이지를 가공하는 가능성이 무한히 넓어지는 것이다.

 같은 페이지라도 사용자에 따라 완전히 다른 화면을 보여줄 수 있는데(로그인 성공, 실패라던지, 검색어에 따른 결과라던지) 심지어 평소 개발하던 느낌으로 개발할 수 있다? 심지어 웹 서버와 독립적으로 작동해서 보안도 향상되고 쓸데없이 프로그램이 무거워 질 일도 없다. 그렇기에 WAS는 동적으로 작동하는 웹사이트를 만들 때 필수인 물건이 되었다.

톰캣

 톰캣은 2005년부터 아파치 소프트웨어 재단에서 관리하여 아파치 톰캣이라고 불리고 있다. 썬 마이크로시스템즈에서 공개했을 때도 오픈 소스였고, 지금도 오픈소스라 자유롭게 사용하고 개발에 참여할 수 있다. 비슷한 자바 기반 WAS로는 Jetty나 Undertow, Jeus 같은 것이 있다. 다만 여기서는 톰캣만 다룰거임

 위에 설명했듯 톰캣은 자바를 사용하는 WAS이므로 아파치 HTTP 서버에 붙여 일반 자바 프로그램처럼 작동한다. 자바를 사용하지만 J2EE의 모든 기능을 다루지는 않기 때문에, J2EE의 모든 기능을 사용하고 싶다면 tomEE 라는 이름이 조금 다른 WAS를 쓰면 된다. 모든 기능을 제공하지는 않기 때문에 '서블릿 컨테이너나 그냥 '컨테이너'라고도 불린다.

 어떻게 어떻게 해서 톰캣(또는 다른 WAS) 서버를 실행하게 되면 기존 웹 서버는 다른 포트에서 서비스를 시작하게 되는데, 이 때 기존 웹 서버의 작동방식이 조금 달라진다.

 1. 사용자 -> 인터넷에 자신이 입력한 도메인(naver, daum...)에 해당하는 문서를 요청한다.
 2. 웹 서버 -> 해당 도메인을 가진 서버에서 이런 문서를 요청한다고 WAS에 알린다.
 3. WAS -> 웹 서버로부터 요청을 받았으니 내부에서 요청에 따라 문서를 찾거나, html 문서를 새로 제작하거나 한다.
 4. WAS -> 이후 만들어진 문서를 웹 서버에게 보내준다.
 4. 웹 서버 -> WAS에서 받은 문서를 사용자에게 보내준다.
 5. 사용자 -> 사용자는 좋아죽는다.

 톰캣의 경우 8080포트를 사용하는데, 이것은 원한다면 바꿀 수 있다. 아무튼 요청을 받으면 서블릿(Servlet)이나 JSP를 활용해 html 문서를 짜게 되며, 이 과정에서 DB를 쓰거나 다른 프로그램의 힘을 빌릴 수 있다. 과정이 길어질수록 사용자가 문서를 받기까지 걸리는 시간도 길어진다.

서블릿은 뭐고 JSP는 뭐임? 왜 맨날 두 개 같이 엮어서 말함?

 생김새는 다른데 역할은 비슷하거든...

 알다시피 html 문서는 뜯어보면 완전히 텍스트다. 메모장으로도 볼 수 있는 그런 것이므로, 자바의 기능을 사용해서 html 문서를 만드는 게 어려울 일이 아니었다. 그래서 96년, 썬 마이크로시스템즈에서 서블릿이라는 API를 발표했는데, 덕분에 System.out.println() 메소드를 사용해서 콘솔창에 텍스트를 띄우듯, html 문서를 처리하는 부분이 엄청나게 개선되었다. 각 서블릿은 요청이 있을 때마다 프로세스가 아닌 스레드를 생성해 병렬적으로 작동했으므로 별로 무겁지도 않았다!

 서블릿은 그 자체로 자바 웹 서버를 대표할만큼 중요하고 유용하다. 유일한 문제라면 사용자에게 건네 줄 html 문서의 크기가 지나치게 커지면 아주 골치아파진다는 부분에 있었다. 순수하게 자바의 기능만을 사용해서 html 문서를 작성하는 것이기에 그랬다. 만든 파일은 패키지명과 클래스명을 갖다가 web.xml 이라는 설정집에 따로 등록(매핑이라고 한다)도 해줘야했으니 어지간한 귀찮음도 있었을 것이다. 그래도 별다른 수가 없었으므로 사람들은 그냥 서블릿을 잘 사용했다.

 하지만 시대가 진화하면서 웹 디자인에 관한 중요성이 부각되었고, 웹 디자이너 측면에서는 백엔드에서 일궈놓은 서블릿의 그 해괴한 코드 덩어리를 이해할 수는 없는 노릇이었다. 서블릿 자체의 생산성에 관한 문제도 있었으므로, 서블릿 API가 공개된 지 3년 뒤인 1999년에 똑같이 썬 마이크로시스템즈에서 JSP를 내놓게 된다. 비슷한 구조를 띄는 PHP나 ASP에 비하면 좀 늦은 시기다.

 JSP는 html 문서 속에 자바 코드를 넣을 수 있는 구조였기에, html 문서의 생산성이 훨씬 향상되는 효과가 있었다. 귀찮은 매핑도 필요가 없었고, 하이퍼링크로 jsp 페이지 링크를 걸면 알아서 해당 jsp로 이동할 수 있었다. 문서 속에 자바 코드가 있으므로 문서를 만들다가도 수틀리면 리다이렉트를 통해 페이지를 옮기는 것도 가능하다.

 ...그렇다고 해서 JSP가 완전히 좋다는 것은 아니다. 디자인이 중요하거나 별다른 기능이 없을 때에는 JSP가 유리했고, 자바 코드를 많이 짜야 하는 경우라면 서블릿이 훨씬 낫다. JSP는 결국 서블릿의 파생일 뿐인 것도 있어서, 실행시 서블릿으로 변환된 뒤에 실행된다. 케바케니까 알아서 쓰면 되는 거임!