[미들웨어] 3-Tier와 N-Tier 정리

1. 2-Tier(Client/Server) 환경

 

인터넷이 발달하기 전에도 기업들은 컴퓨터를 이용해 업무를 처리했다.

당시 시스템들은 폐쇄된 네트워크에서 클라이언트/서버 (CS) 방식으로 구성되어 있었다.

클라이언트/서버 방식이란 보통 데이터베이스 서버에 GUI 방식의 클라이언트가 접속하여 업무를 처리하는 방식을 말한다.

[그림 1-1] 2-Tier 환경 구성도

클라이언트/서버 방식의 경우, 대부분의 비지니스에 대한 로직은 클라이언트 쪽에서 처리하며 데이터를 저장하거나 조회할 경우에만 데이터베이스를 이용했다. 

 

2-Tier의 단점

- 클라이언트에서 대부분의 비지니스 로직을 처리해야하기 때문에 클라이언트의 성능이 좋아야한다.

- 비지니스 로직이 변경될 경우, 모든 클라이언트 프로그램을 다시 재배포해야 하는데, 재배포에 필요한 작업 비용이 많이 든다.

 

2. 3-Tier 환경

3-Tier 환경이란 기존 클라이언트/서버 사이에 중간 단계를 하나 더 둔 것이다.

3-Tier 환경은 말 그래도 세 가지 계층으로 구성된 형태인데,

 - 첫 번째 계층은 (단순하게) 사용자로부터 입력을 받고 보여지는 것만을 담당하는 부분으로 "프레젠테이션 계층" 이라고 부른다.

 - 두 번째 계층은 프레젠테이션 계층에서 입력한 값을 받아들여 실제로 비지니스 로직을 처리하는 "애플리케이션 계층"을 말한다. 

 - 세 번째 계층은 데이터베이스 서버를 말하며 대량의 정보를 저장 및 조회하는 기능을 담당한다.

 

이러한 3-Tier의 예는 데이터베이스를 이용한 웹 환경이 대표적인 예라고 할 수 있다. 웹 환경의 브라우저는 3-Tier의 첫 번째에 해당하는 프레젠테이션을 담당하며, 웹 서버에서 동작하는 웹 프로그램은 비지니스 로직을 처리하는 부분이다.

 

[그림 1-2] 3-Tier 구조의 웹 환경 구성도

3-Tier 구조의 웹 환경에서는 클라이언트/서버 환경과는 다르게 비지니스 로직이 변경되어도 클라이언트를 모두 수정할 필요가 없으며 웹 서버에 있는 웹 프로그램만 수정해주면 된다는 장점이 있다.

또한, 클라리언트는 브라우저를 실행할 정도의 자원만 있으면 되기 때문에 많은 수의 클라리언트에 대한 비용 절감 효과도 있다.

그렇지만 3-Tier 환경에도 단점이 있는데, 웹 프로그램의 경우 데이터베이스에 접속 및 조회하고 사용자 클라이언트에게 전송하는 부분이 하나의 구조로 되어 있기 때문에 코드의 재사용이 어렵다.

 

"웹 환경에서의 장점은 앞에서 설명한 것 처럼 브라우저가 설치되어 있고 인터넷만 된다면 프로그램을 추가로 설치하지 않아도 작업할 수 있다는 점이다. 그렇지만 전문 클라이언트보다는 브라우저에서의 작업처리가 어렵다는 단점이 있다. 전문 클라이언트는 보통 윈도우 프로그램으로 작성되며, 윈도우의 다양한 컴포넌트를 이용해서 개발하기 때문에 사용자의 편의성이 매우 높기 때문이다.

따라서 웹 환경의 발달로 대부분의 프로그램을 웹 환경에 맞게 작성하지만, 사용자로부터 복잡한 데이터를 입력받아 처리하거나, 반대로 복잡한 형식의 데이터를 출력할 경우에는 전문 클라이언트를 이용하는 편이 더 효율적이다"

 

3. N-Tier 환경

3-Tier 환경에서 코드를 재사용하는 어려움을 극복하기 위해서 등장한 것이 N-Tier 환경이다.

N-Tier 환경은 3-Tier 환경에서 비지니스 로직을 담당하는 어플리케이션 계층의 확장을 좀 더 쉽게 구현한 구조이다.

[그림 1-3]과 같이 어플리케이션 계층 안에서 로직에 따라 여러 부분을 나눈 후, 통신하는 방법으로 처리하도록 구현한다는 의미이다.

 

[그림 1-3] N-Tier 환경 구성도

이러한 구조의 특징은 비지니스 로직이 변경될 경우, 변경된 해당 부분의 컴포넌트만을 수정하면 된다는 장점이 있다.

또한 컴포넌트를 호출해서 사용하는 방식이기 때문에 동일한 비지니스 로직인 경우, 로직을 새롭게 작성하지 않고 호출해서 사용만 하면 된다. (여기서 컴포넌트란 EJB를 뜻한다)

그렇지만 EJB 아키텍처를 이용할 경우 위와 같은 장점이 있다고 해서 무분별하게 EJB 컴포넌트를 이용하는 것은 바람직하지 않다. 간단한 프로그램의 경우에는 많은 자원이 필요치 않으며 EJB 아키텍처를 이용할 경우 EJB 컨테이너의 구입(WebLogic) 비용도 비싸며 개발 시간도 많이 소요되기 때문이다.

또한 EJB 아키텍처를 사용한다는 것은 프로그램의 속도를 향상시키기 위한 것이 아니라 코드의 재사용성을 높이고 복잡한 처리 작업의 신뢰성을 유지하며, 빠르게 개발하기 위해서 필요한 것이므로 프로그램의 수행 속도만을 생각한다면 EJB를 이용하는 것이 바람직하지 않을 수도 있다.

현재 잘 돌아가는 프로그램을 무조건 EJB로 변경하는 것도 많은 비용을 발생시킬 수 있기 때문에 권장하지는 않는다.

즉, EJB를 이용한 프로젝트는 신뢰성 있는 N-Tier 프로젝트를 쉽고 빠르게 개발하기 위함이다.