지난 호에서 잠시 언급했듯이 LDAP은 그 뛰어난 성능에도 불구하고 많은 불편한 요소들을 내포하고 있다. 현재 디렉토리 서비스의 핵심 기술인 LDAP은 빠른 검색속도에 비해 업데이트 속도가 현저히 떨어
진다. 이는 분명히 데이터베이스와 비교할 경우에 관련되는 문제이고 따라서 디렉토리 서비스를 도입하려고 하는 회사나 기관, 또는 단체는 이 부분을 신중히 고려해야 할 것이다.
LDAP의 설계와 그 이용에 대한 툴(Tool)들이 개발되지 않았기 때문에 기술의 편이성에 비해 보편화가 더딘 문제점도 가지고 있다. LDAP을 쉽게 관리하기 위해서는 사용자에 따라 다양한 애플리케이션이 제공되어야 하고, 각각의 사용자에 대한 권한 지정이 용이하여야 하는 등 세심한 부분까지 관리자에 의해 통제되고 수립되어야 한다. 이는 관리자에게는 정말 힘든 일이 될 수밖에 없다. 기술적인 면에서 디렉토리 서비스는 저 수준의 API를 사용하기 때문에 커스터마이징(Customizing)시에 전문 프로그래머가 필요하게 된다. 또한 디렉토리 관리를 위한 전문 관리자도 필요하게 되므로 그에 따르는 상당한 인적 비용이 발생한다.
그러면 보다 자세한 문제점들을 언급해보자. 첫째로 LDAP은 가볍지만 힘들다. 다시 말해서, 프로토콜 자체의 메시지 구조가 아주 간결하고, 함축적으로 이루어져 있기 때문에 한편으로는 간결하지만, 사용하는 데에는 상당한 주위를 해야 한다는 것이다. LDAP에서 나오는 모든 지시자(Identifier)들은 모두 함축적 의미를 가지고 있기 때문에, 이 지시자들에 대한 이해를 잘 하고 있어야만 사용이 간편하다. 결국 말은 간결하고 명확하지만, 그만큼 배우기는 쉽지 않다는 뜻이다.
LDAP의 난제
DN을 예로 들어보자. 이는 실제 Distinguished Name으로 풀이가 되며, 또한 FQDN(Fully Qualification Domain Name)과 같이 Full DN을 의미할 때가 있다.
o=senex
…
…
…
ou=KyeungZik Kim
위의 예에서 dn은 o=senex이고, 또다른 dn은 ou= KyeungZik Kim이다. 그렇지만 ou=KyeungZik Kim의 FULLY-DN을 얘기하자면, “ou=KyeungZik Kim, o=senex”가 된다.
개발 과정에서 해당 DN을 명시할 때, 이의 구분을 명확히 해야만 할 것이다. 따라서 원문에서 인용되는 어떤 실제 명칭에 대해서 정확하게 파악을 하는 것이 좋다.
둘째로 정규화된 프로토콜의 규약을 들겠다. LDAP은 실제 이 자체만으로 동작을 하지 않는다. 이는 하나의 규약일 뿐이다. 다시 말해서 LDAP은 내부에 DB도 있는데, 이 자체는 데이터(Data)가 아닌 구조(Structure)라고 보는 것이 정확할 것이다. LDAP을 구축한다는 말은 데이터를 입력하는 작업이 아닌, 구조를 만들어 나가는 작업이라고 보면 좋을 것이다. 따라서 실제 데이터가 들어가기는 하지만, 이는 추후에 그냥 입력만 하면 되는 사항이고, 데이터를 입력하기 위한 준비작업이 그만큼 중요하고 어려워진다는 것이다.
셋째로 앞에서 언급한대로 LDAP은 프로토콜이며, 구조적인 형태이다. 따라서 이것을 관리자가 원하는 형태로 바꾸고 수정하고, 다른 프로그램들과 연관을 시키려면, 관계 시켜주는 프로그램들이 부수적으로 필요하게 된다. 그러한 프로그램들은 바로 아래와 같은 프로그램들이다.
ldapadd, ldapmodify, ldapsearch...
유의할 점은 위에서 언급한 프로그램들은 LDAP 프로토콜에 의거해 동작하는 아주 저 수준의 연결 프로그램이라는 점이다. 따라서 프로그램 사용시의 구문의 정형성, LDAP 제반 구성요소에 대한 이해, LDAP의 기능적 제한 요소 등 사용상에 상당히 어려운 점들을 가지고 있음을 알아야 한다.
