본문 바로가기
강의/웹 프로그래밍(풀스택)

부스트코스 웹 프로그래밍(풀스택) - 1. 웹 프로그래밍 기초 - 7 강의 정리

by 리드민 2022. 3. 21.
반응형

[1] 강의

웹 프로그래밍(풀스택)

1. 웹 프로그래밍 기초

7) WAS

 

[2] 강의 정리

   웹 프로그래밍을 공부하기 전에 몇 가지 중요 용어에 대한 이해가 필요하다. 이번 강의에서는 몇 가지 중요한 용어에 대한 설명과 WAS가 등장하게 된 배경과 WAS가 하는 중요한 일에 대해서 설명해보도록 하겠다. 클라이언트와 서버이다. 중요한 용어중에 하나이다. 이제 여러분들이 웹 프로그래밍을 하다 보면 계속 나오게 되는 용어이다. 서비스를 제공하는 것을 서버라고 한다. 서버에게 서비스를 요청해서 그 결과를 보여주는 것을 클라이언트라고 한다. 웹 서버와 웹 브라우저가 대표적으로 서버와 클라이언트의 관계라고 말할 수 있다.

  다음은 DBMS와 클라이언트에 대해서 살펴보도록 하겠다. DBMS는 데이터베이스를 관리하는 시스템을 이야기한다. DBMS가 등장하기 이전에는 개발자들이 파일의 데이터를 저장하고 읽어들이는 기능을 모두 구현해야 됐다. 이러한 불편함을 해결하기 위한 여러 가지 노력의 결과로 DBMS라는 소프트웨어가 등장하게 되었다. DBMS에 대한 최초의 걔념은 IBM에서 논문으로 나오게 됐었다. 최초의 구현은 Oracle에서 하였다. DBMS는 굉장히 다양한 제품들이 존재한다. 대표적으로 MySQL, MariaDB, PostgreSQL 등이 있다. DBMS가 등장하면서 개발자들은 상대적으로 쉽게 데이터를 관리할 수 있게 되었다. 마치 메모장에다가 데이터를 막 관리하다가 MX Excel 같은 것을 이용하게 된 심정이라고 해야 될까요? DBMS는 보통 서버 형태로 서비스를 제공하기 때문에 이러한 DBMS에 접속해서 동작하는 클라이언트 프로그램이 한때 많이 만들어졌다. 그런데 이러한 방식의 문제점은 클라이언트의 로직이 많아지고 클라이언트의 프로그램의 크기가 커진다는 문제가 있었다. 프로그램 로직이 변경이 되면 클라이언트가 매번 배포되어야 한다는 문제가 있었다. 대부분의 로직이 클라이언트에 포함되어 배포가 되기 때문에 보안이 나쁘다는 이런 문제들을 가지고 있었다. 그래서 등장했던 것이 미들웨어 DBMS를 직접 클라이언트가 연결되어 동작하는 방식이 여러 가지 단점이 있었음을 알게 되었다.

  이러한 문제점을 해결하기 위해 등장한 것이 미들웨어라는 개념이다. 클라이언트와 DBMS 사이에 이 그림과 같이 또 다른 서버를 두는 이런 방식이다. 클라이언트는 단순히 요청만 중앙에 있는 서버에게 보내고. 중앙에 있는 서버인 미들웨어가 대부분의 로직을 수행한다. 이때, 데이터를 조작할 일이 있으면 DBMS에게 부탁한다. 그리고 그 결과를 클라이언트에게 전송하면 클라이언트는 그 결과를 화면에 보여주게 된다. 클라이언트는 복잡한 로직이 사라지고 단순히 화면에 그 결과만 보여주면 되기 때문에 사용자로부터 입력만 받아서 미들웨어에게만 보내는 역활만 수행하면 되기 때문에 크기가 매우 작아지게 된다. 프로그램 로직이 변경이 된다 하더라도 모든 클라이언트를 다시 배포할 필요가 없이 중앙의 미들웨어만 변경하면 되는 장점을 가지게 된다.

  다음은 WAS에 대해서 살펴보겠다. 최초의 웹이 등장했을 때는 웹 브라우저는 정적인 데이터만 보여주었다. 웹이 널리 사용되면서 사용자들의 요구 사항은 점점 커지게 됬다. 웹에서 데이터가 입력하고 조회하는 등의 동적인 기능을 요구하게 되었다. 동적인 기능은 프로그래밍을 통해서 가능했다. 웹 서버에서 프로그래밍 기능이 들어가는 방식을 CGI라고 불렀었다. CGI는 단순한 프로그래밍에서는 사용 시 별문제가 없었다. 웹은 점점 복잡해졌고 점점 복잡한 프로그래밍적인 기능을 요구하게 되었다. 보통 이러한 기능들은 DBMS와 연관된 경우가 굉장히 많았다. 브라우저를 클라이언트로 본다면 브라우저와 DBMS 사이에서 동작하는 미들웨어가 필요가게 된 것이다.

  WAS가 가지는 중요한 기본 기능이 세 가지가 있다. 첫번째는 프로그램 실행 환경과 데이터베이스 접속 기능을 제공한다. 여러 개의 트랜잭션을 관리한다. 마지막으로는 업무를 처리하는 비즈니스 로직을 수행한다. 트랜잭션은 논리적인 작업 단위라고 할 수 있다. 뒤에서 데이터베이스 프로그래밍을 설명할 때 좀 더 자세히 설명할 예정이다. 이 외에도 WAS는 다양한 기능을 제공한다. 웹 서버의 기능도 기본적으로 제공한다. 그래서 여러분 이번에 우리가 과정을 진행할 때 웹 서버 따로 WAS 따로 이렇게 진행하지 않고 톰캣이라는 WAS만 하나 설치하고 이용이 가능한 이유는 이 WAS, 톰캣이 가지고 있는 웹 서버가 충분한 기능을 하고 있기 때문에 굳이 따로 Apache같은 웹 서버를 같이 설치하지 않고 톰캣만 설치해서 사용하는 것이다. 그렇지만 현업에서는 다음과 같은 이런 형태로 구성을 하는 경우가 굉장히 많다. 웹 서버는 보통 정적인 콘텐츠를 웹 브라우저에게 전송하는 역활을 한다. WAS는 프로그램의 동적인 결과를 웹 브라우저에게 전송하는 역활을 담당한다. 프로그램이 동작해서 얻은 결과를 보통 동적인 콘텐츠라고 말하기도 한다. 앞에서 WAS가 제공하는 웹 서버의 기능도 웹 서버가 제공하는 기능에 비해서 성능이 떨어지지 않다고 했다.

  그렇다면 웹 서버가 없어도 될까? 사실 웹 서버 없이 WAS만 있어도 정적인 콘텐츠와 동적인 콘텐츠를 모두 제공할 수 있다. WAS 등장이 초창기였을때는 WAS에 내장된 웹 서버가 성능이 좀 떨어졌었다. 그랬었기 때문에 초창기에는 웹 애플리케이션을 실행할 때, Apache와 톰캣을 같이 설치해서 실행을 했어야 됐었다. 그런데 이게 계속 발전하면서 웹 서버의 역할도 충분히 해주고 있기 때문에 웹 서버를 따로 설치하지 않아도 충분히 동작하는 경우들이 굉장히 많아졌다고 생각을 하면 된다.

  그럼에도 불구하고 웹 서버가 WAS 앞단에 있으면 좋은 이유가 있다. 웹 서버는 상대적으로 WAS보다 간단한 구조로 만들어져 있다. 사람들이 많이 접속하는 대용량 웹 애플리케이션의 경우에는 서버의 수가 여러 대일 수 있다. 여러분이 사용하는 프로그램도 가끔 문제가 있어서 종료가 되는 경우를 본 적 있을것이다. WAS에서 동작하도록 개발자가 만든 프로그램이 오작동이 발생해서 WAS 자체에 문제가 발생하는 경우도 있다. 이 경우, WAS를 재시작해야 되는 경우가 생긴다. 문제가 있는 WAS를 재시작할 때, 앞단의 웹 서버에서 먼저 해당 WAS를 이용하지 못하도록 하고. WAS를 재시작한다면 해당 웹 애플리케이션을 사용하는 사람은 WAS의 문제가 발생하였는지를 모르고 이용할 수 있는 것이다. 이러한 처리를 장애 극복 기능이라고 한다. 대용량 웹 애플리케이션에는 무중단으로 운영하기 위해서 상당히 중요한 기능이다. 이러한 기능 때문에 보통 웹 서버가 WAS 앞단에서 동작하도록 하는 경우가 많다.

반응형