본문

1. 보안측면에서 유리해 진다.

제대로 된 2티어 방식에서는 보안을 위해서, 해당 DB에서 사용자마다 DB 접속 계정을 만들고 DB 객체(Table, 저장프록)
참조에 대한 권한을 일일이 설정해야 하지만, 이렇게 하면 너무 사용자 관리가 복잡해지고, 프로그램 변경도 어렵게 된다.
이 때문에 2티어에서 주로 많이 취하는 방식은, DB에 커넥션할 때 admin(MSSQL인 경우 sa계정) 계정으로 접속하고,
사용자 정보 테이블을 DB에 만들어 두고 단순히 계정과 암호를 보관하는 용도로 사용한다.
이렇게 함으로 인해서 프로그램은 편해질지 몰라도, 실행 파일 내부에 admin 계정에 대한 정보가 고스란히 존재하여,
해커들이 쉽게 admin 계정을 알 수 있게 된다. 특히 폼에 놓여진 데이타베이스 연결 콤포넌트 속성 일부로
admin 계정 정보를 저장했다면, 정말 치명적이다. 해커들은 아주 쉽사리 폼에 대한 정보를 얻을 수 있기 때문이다.
3티어 방식은 DB 연결에 대한 어떤 정보도 클라이언트 보관한 필요가 없다. 따라서 보안 측면에서 훨씬 좋다.
2티어는 성격상 외부에서의 DB연결을 허용해야 하지만, 3티어는 DB 직접 연결을 허용하지 않는다. 

2. 3티어 대용량 서비스에서 2티어에 비해서 유리하다.

이는, 2티어 방식에서는 한 사용자당 한 커넥션을 가져야 하며, 그 사용자가 프로그램을 종료하기 전까지는
그 커넥션을 계속 가지고 있어야 하기 때문이다. 반면 3티어에서는 대부분 connectless 방식을 취한다.
즉 웹서버 같이 서비스 요청/응답 후 즉시 연결을 차단하는 방식을 사용하기 때문에, 커넥션 수가 제한될 때 월등히 유리하다.
DB 커넥션은 대부분의 RDB에서는 별도로 부과되는 라이센스 비용이기 때문에, 적은 수의 커넥션으로
많은 사용자들에게 서비스할 수 있다는 점은 경비적으로 3티어가 2티어에 비해서 좋은 점이다.
물론 2티어에서도 순수 코딩으로 3 티어같이 connectionless방식을 구현할 수도 있을 것이다. 그러나 이렇게 할 경우 잦은 connect,
disconnect는 프로그램 속도를 느리게 하고, 서버에 도리어 부담을 줄 수도 있다. 반면 3티어는 커넥션 풀링 등의 개념을 사용하여
이런 부담을 줄일 수 있다.

3. 클라이언트 배포가 단순해 진다.

3티어 방식에서 클라이언트는 실행파일만 배포하면 될 뿐, ADO, ODBC, BDE같은 DB 연결 라이브러리 설치가 전혀 필요없다.
이는 어플 서버만 디비에 직접 연결할 뿐, 클라이언트는 DB 가 무엇인지 전혀 알 필요가 없기 때문이다.
2티어의 경우 클라이언트가 100대이고, 연결방식이 BDE라고 가정했을 때,
이 100대에 대해서 BDE를 업데이트해야할 필요성이 발생했다면, 얼마나 끔직한 일인가?
BDE 업데이트를 하려면 단순 파일들의 덮어쓰기 말고도 레지스트리 정보도 수정해 줘야 하므로,
자동 업데이트 프로그램을 만들기도 쉽지 않다.
그러나 3티어에서는 클라이언트 실행 파일만 자동 업데이트하는 로직을 구현해 주면 된다. 대부분의 경우 이는 매우 쉽다.

4. SQL 문장이 클라이언트 프로그램에 있을 필요가 없다.

3티어 방식에서 DB에 요청을 하는 것은 어플 서버만 담당하므로, 클라이언트는 전혀 SQL문장을 사용할 필요가 없다.
3항에서 언급했듯이 클라이언트는 어플 서버하고만 통신할 뿐, 디비 서버와는 전혀 통신하지 않는다.
따라서 모든 요청은 어플 서버에 대한 원격 함수 호출만 존재할 뿐, 어플 서버 쪽으로
직접 SQL 문을 날리는 경우는 보안적인 이유로 지극히 제한된다.
보통 2티어인 경우, 클라이언트 프로그램 내부에 수많은 SQL문들이 존재하고 이를 디비 서버로 전송할 것이다.
실행 파일 내부에 SQL 문이 존재한다는 것은, 해킹과 크랙의 가능성을 높여주고, 디비 구조를 추정해볼 수 있는 힌트가 된다.

5. 다중 DB 사용이 용이하다.

기존 프로그램이 MS SQL 서버를 사용해서 만들었다고 가정하자. 이를 오라클에서도 동작할 수 있도록 변경하려면,
2티어 방식에서는 클라이언트 모든 프로그램을 수정해야 할 것이다. 3티어는 어플 서버 쪽으로 모든 SQL 문이 집중되어 있으므로,
비교적 디비 전환이 슆다(물론 거저 먹기씩으로 아주 간단하다는 말은 절대 아니다).
오라클, MSSQL은 각자 자기만의 특수한 SQL구문이 있을 수가 있는데, 각 디비마다 이런 최적화를 어플 서버에 집중할 수 있으므로,
특정 디비에 대한 고유한 기능을 살리면서, 클라이언트에는 별다른 영향을 주지 않게 할 수 있다.
이와 비슷한 경우로, 실제 테이블의 필드명이 CUST_NO이지만, 클라이언트에서는 CustID라는 필드명을 사용하고 싶을때도
마찬가지다. 어플 서버가 실제 필드명과 클라이언트 필드명을 매핑하는 역할을 할 수 있다.