[Note] 워크그룹과 도메인

마이크로소프트의 Windows 뿐만이 아니라 다른 벤더의 OS도 마찬가지고, 회사 내부의 인트라넷 어플리케이션, 우리가 사용하는 E-mail서버 등, 수많은 어플리케이션이 디렉터리를 요구한다. 이러한 디렉터리를 보다 효율적으로 사용하기 위한 노력이 존재하고 마이크로소프트 역시 효율적인 디렉터리 관리를 위해서 상당한 노력을 기울이고 있다. 디렉터리가 어떻게 관리되는지에 따라서 네트워크 관리모델을 결정할 수가 있게 된다. 마이크로소프트는 관리모델로써 Workgroup과 Domain이라고 하는 두가지 모델을 제공한다.

 

두 모델의 가장 큰 차이점이라면 디렉터리 데이터베이스의 위치라고 할 수 있다. 먼저 첫번째 그림을 보자. 네트워크에 Windows 2000 server, professional, NT4.0 Server, Workstation 의 서로 다른 4개의 컴퓨터가 있고, 각각의 시스템이 고유한 디렉터리 데이터 베이스를 유지하고 있는 모델이다. 

< 그림13-3. Workgroup 모델 >

 

이러한 형태로 네트워크를 운영할 때 어떤 일이 발생할 것인지를 생각해 보자.

 

‘홍길동’이라는 사용자가 특정 서버의 공유자원에 접속을 원한다면 해당 서버의 디렉터리 데이터베이스에 사용자 계정이 존재해야 한다. 만일 홍길동이 4대의 서버에 각각 접속을 원한다면 홍길동은 4대의 서버마다 자신의 사용자 계정을 가지고 있어야 하고 또한 그 계정과 각각의 암호를 기억하고 있어야 전체 서버의 자원을 이용할 수 있게 될 것이다.

 

서버 입장에서는 어떤가? 만일 홍길동이 자신의 공유자원에 접속하기를 원한다면 서버의 관리자는 홍길동을 위해 공유자원에 대한 접근허가를 주기 위해서 자신의 디렉터리 데이터베이스 안에 홍길동이 사용할 계정을 생성해 주어야 한다. 서버가 추가된다면 역시 홍길동의 계정은 추가된 서버의 디렉터리 데이터베이스에 새롭게 생성이 되어야만 한다.

 

결과적으로는 하나의 사용자가 서버들의 자원에 접근하도록 하기 위해서 각 서버에는 사용자 계정이 생성되어야 하는 번거로움을 감수해야 할 것이다. 이들 4대의 서버를 관리하는 관리자도 마찬가지이다. 관리자 역시 각각의 서버를 관리하기 위해서는 각 서버에서 관리권한을 가진 사용자 계정과 암호를 알고 있어야만 관리가 가능해 지는 것이다. Workgroup을 사용하는데 있어서 불편한 점을 정리해 보면 다음과 같다.

 

  ① 한 사용자가 자원을 가진 서버마다 별도의 사용자 계정을 가지고 있어야 한다.

  ② 하나의 사용자를 위해서 서버마다 계정을 만들어야 하는 번거로움

  ③ 중앙집중적인 관리의 어려움

 

서버의 수도 많아지고 사용자의 숫자도 증가하여 네트워크에서 관리해야 할 자원들이 늘어간다면 워크그룹 모델은 분명히 한계가 있다. 제대로 관리를 한다는 것은 너무나 많은 노력을 필요로 하는 일이다.

 

이것을 해결할 방법은 없는가? 마이크로소프트는 도메인이라는 모델을 제시하고 있다. 생각을 조금만 바꾸면 된다. 회사에 있는 모든 서버들이 자신의 디렉터리 데이터베이스에 사용자 계정을 각각 관리할 것이 아니라, 하나의 마스터 디렉터리 데이터베이스를 두고 모든 서버들은 그 디렉터리 데이터베이스에 접근하여 사용자 계정을 공유한다면 될 것이 아닌가?

 

이것을 가능하도록 하기 위하여 마이크로소프트는 네트워크 환경에서 특별한 서버를 지정하여 마스터 디렉터리 데이터베이스를 관리하도록 하였고, 이 서버를 도메인 컨트롤러 (Domain Controller, DC)라고 부른다. 그리고 이 도메인 컨트롤러의 마스터 디렉터리를 사용할 수 있는 서버나 클라이언트들을 묶어서 '도메인(Domain)'이라는 논리적인 관리단위를 만들었다. 정리하자면 워크그룹이 가졌던 단점을 해결하고자 한다면 도메인이라는 그룹을 만들고 모든 서버들을 이 도메인의 멤버로 만들고, 클라이언트 역시 도메인으로 로그온하도록 구성을 하면 되는 것이다. 그렇게 하면 도메인의 모든 멤버들은 디렉터리 서비스에 적용을 받고 각각의 계정이 아니라 도메인의 마스터 디렉터리 계정으로서 자원관리를 할 수가 있게 된다.

 

아래의 그림에서는 디렉터리 데이터베이스가 DC에 집중되어 있는 것을 볼 수 있다.

<그림13-4. 도메인 모델>

 

도메인 환경에서는 앞에서 홍길동의 계정이 서버마다 생성될 필요가 없다. 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에서 한번만 생성이 되면 그뿐이다. 다른 모든 멤버서버들은 도메인 컨트롤러에 접근하여 마스터 디렉터리 데이터베이스에 저장된 홍길동에게 직접 자원에 대한 접근허가를 줄 수 있다.

 

사용자 입장에서도 자원에 접근하기가 수월해졌다. 자원을 가진 모든 서버마다 별도의 사용자계정과 암호를 기억할 필요가 없이 도메인 컨트롤러의 마스터 디렉터리 데이터베이스에 저장된 사용자 계정과 암호만 기억한다면 그 정보를 이용해서 모든 서버에 접근을 할 수 있다.

 

도메인 환경에서 새로운 서버가 추가되고 그 서버의 자원에 모든 사용자들이 접근할 수 있게 하려면? 간단해 진다. 새로운 서버를 도메인의 멤버서버로 설정하기만 하면 된다. 그러면 그 서버는 기존에 이미 존재하는 도메인의 디렉터리 데이터베이스에 접근하여 사용자 정보를 사용하는 것이 가능해 지기 때문이다.

 

관리적인 측면으로 본다면 워크그룹모델은 컴퓨터와 컴퓨터 즉, 자원과 자원간에 아무런 연관성이 없는 개별적인 관리모델이고, 도메인 모델은 도메인에 참여하여 도메인을 구성하고 있는 서버 및 PC들이 도메인이라는 범위내에서 관리정책, 보안정책 등을 서로간에 공유할 수 있는 모델을 말한다.

도메인 모델의 장점을 굳이 언급할 필요는 없다. 워크그룹 모델을 사용하는데 불편했던 점들을 고려한다면 그것들 중의 대부분은 도메인 모델을 채택함으로써 해결될 수 있는 단점이 될 것이다.