IT · 업무
AD, ADDS, LDAP
먼저 큰 그림: AD는 제품 이름이 아니라 디렉터리 환경을 가리키는 말입니다
회사에서 새 직원이 입사하면 계정 하나를 만들고, 노트북을 조직의 관리 범위에 넣고, 부서별 공유 폴더와 프린터 사용 권한을 정합니다. 이런 정보를 컴퓨터마다 따로 적어 두면 사람의 이동과 장비 교체가 잦을수록 관리가 무너집니다. 이때 사람, 컴퓨터, 그룹, 프린터, 서버 같은 대상을 한곳에서 찾고 연결하기 위한 체계를 디렉터리 서비스라고 부릅니다. 현장에서 말하는 AD는 대개 마이크로소프트의 Active Directory를 줄여 부르는 표현이며, 윈도우 기반 조직에서 신원과 자원을 다루는 중심 목록이라는 뜻으로 쓰입니다.
AD라는 말만 들으면 단일 프로그램처럼 느껴질 수 있지만 실제로는 여러 기능과 구성 요소가 함께 움직이는 생태계입니다. 도메인에 로그인할 때 누구인지 확인하는 일, 그룹 정책으로 보안 설정을 배포하는 일, 조직도에 맞춰 계정과 컴퓨터를 묶는 일, 다른 시스템이 직원 정보를 찾아가는 일이 서로 연결됩니다. 따라서 질문을 받을 때는 AD가 무엇인지와 지금 어떤 기능을 가리키는지를 분리해서 보는 편이 좋습니다. 어떤 문서는 전체 디렉터리 환경을 AD라고 부르고, 어떤 문서는 그중 도메인 서비스를 정확히 지칭하려고 AD DS라는 이름을 씁니다.
디렉터리에 저장되는 대상은 단순한 이름표가 아닙니다. 사용자 항목에는 로그인 이름, 표시 이름, 부서, 메일 주소, 그룹 소속 같은 속성이 붙고, 컴퓨터 항목에는 장비 이름과 도메인 가입 상태가 붙습니다. 그룹은 권한을 사람별로 반복 부여하지 않도록 묶어 주며, 조직 단위는 부서나 관리 책임에 따라 대상을 나누는 컨테이너 역할을 합니다. 이런 구조 덕분에 관리자는 한 번의 변경을 정책과 권한 규칙으로 확장할 수 있고, 사용자는 자신의 계정으로 허가된 자원에 일관되게 접근할 수 있습니다.
AD DS는 도메인 로그인과 정책 관리를 실제로 수행하는 핵심 역할입니다
AD DS는 Active Directory Domain Services의 약자로, 윈도우 서버에서 도메인 기반 디렉터리와 인증을 제공하는 서버 역할입니다. 조직 안의 PC가 도메인에 가입하면 그 PC는 로컬 계정만 바라보지 않고 도메인 컨트롤러에 사용자와 컴퓨터 정보를 확인합니다. 직원이 사무실 PC를 바꾸더라도 같은 도메인 계정으로 로그인할 수 있는 배경에는 AD DS가 유지하는 계정과 정책 정보가 있습니다. 도메인 컨트롤러는 이 역할을 맡은 서버를 뜻하며, 중요한 인증 데이터를 보유하므로 운영 중단과 보안 사고를 모두 대비해야 하는 인프라입니다.
AD DS의 강점은 중앙 통제와 위임을 함께 제공한다는 점입니다. 예를 들어 본사 IT팀은 전체 암호 정책과 기본 보안 설정을 관리하고, 지점 관리자는 자신에게 맡겨진 조직 단위 안에서 계정을 만들거나 컴퓨터를 옮길 수 있습니다. 그룹 정책을 사용하면 화면 잠금 시간, 업데이트 방식, 특정 프로그램 설정, 드라이브 연결 같은 구성을 여러 장비에 배포할 수 있습니다. 이때 조직 단위를 부서도처럼 과도하게 복제하기보다 정책 적용과 관리 책임이 달라지는 경계를 기준으로 설계해야 나중에 구조를 바꾸기 쉽습니다.
도메인 환경에서는 복제도 중요합니다. 규모가 있는 조직은 도메인 컨트롤러를 둘 이상 두어 한 서버가 점검 중이거나 장애가 나도 로그인과 조회가 계속되도록 구성합니다. 각 서버는 디렉터리 변경 내용을 서로 복제하므로, 계정 생성과 그룹 수정이 어느 지점에서 일어났는지, 사이트와 네트워크 연결이 어떤지까지 운영 설계에 영향을 줍니다. 백업 역시 일반 파일 백업처럼 생각하면 안 됩니다. 시스템 상태와 복구 절차를 정기적으로 검증해야 잘못된 삭제나 랜섬웨어 상황에서도 디렉터리의 신뢰 관계를 지킬 수 있습니다.
LDAP는 디렉터리를 조회하고 수정하기 위한 표준 언어에 가깝습니다
LDAP는 Lightweight Directory Access Protocol의 약자이며, 디렉터리 서버와 클라이언트가 정보를 주고받는 규칙입니다. AD DS가 윈도우 도메인 기능을 제공하는 서비스라면 LDAP는 그 안의 항목을 검색하거나 읽고 수정할 때 사용할 수 있는 통신 프로토콜이라고 이해하면 정확합니다. 애플리케이션이 사내 사용자 이름이나 부서 정보를 가져오고 싶을 때 LDAP로 디렉터리에 연결해 조건을 전달하고, 서버는 일치하는 항목과 속성을 돌려줍니다. 즉 LDAP는 목록 그 자체도 아니고 도메인 컨트롤러라는 장비 이름도 아닙니다.
LDAP 조회는 보통 어디에서 찾을지 정하는 기준 위치와, 무엇을 찾을지 정하는 필터로 구성됩니다. 예를 들어 회사의 디렉터리 루트 아래에서 특정 부서에 속한 활성 사용자만 찾고, 그 결과 중 표시 이름과 전자우편 주소만 가져오도록 요청할 수 있습니다. 디렉터리는 트리 구조를 쓰기 때문에 항목의 위치를 구분하는 이름 체계가 중요하며, 조직 단위 이동이나 이름 변경이 외부 연동에 영향을 줄 수 있습니다. 개발자는 검색 범위와 필요한 속성을 최소화하고, 운영자는 연동 계정이 불필요하게 넓은 읽기 권한을 갖지 않도록 제한해야 합니다.
보안 연결도 빼놓을 수 없습니다. LDAP 통신을 평문으로 열어 두면 인증 정보와 조직 데이터가 노출될 위험이 있으므로, 환경에 맞게 TLS를 적용한 LDAPS 또는 StartTLS를 검토해야 합니다. 인증서의 신뢰 체인, 서버 이름, 포트, 방화벽 규칙이 어긋나면 애플리케이션은 단순히 연결 실패로 보이는 오류를 낼 수 있습니다. 처음 연동할 때는 서비스 계정의 권한, 검색 기준 위치, 암호 만료 정책, 연결 암호화 여부를 문서로 남겨 두면 담당자가 바뀌어도 장애 원인을 훨씬 빨리 좁힐 수 있습니다.
AD, AD DS, LDAP의 관계를 업무 흐름으로 구분해 보세요
세 용어를 구분하는 가장 실용적인 방법은 질문의 주어를 바꾸는 것입니다. 조직 전체의 계정·컴퓨터·그룹·정책 체계를 말한다면 AD라는 넓은 표현이 어울립니다. 직원이 도메인 계정으로 로그인하고, 도메인 컨트롤러가 인증하며, 그룹 정책이 내려가는 기능을 말한다면 AD DS가 정확합니다. 반대로 사내 포털이나 인사 시스템이 사용자 목록을 검색하고 특정 속성을 읽는 연결 방식을 설명한다면 LDAP가 맞습니다. 같은 장면에 세 단어가 함께 등장할 수 있지만, 각각이 답하는 질문은 다릅니다.
가령 신규 인사 시스템이 직원 부서 정보를 표시해야 한다고 해 보겠습니다. 시스템은 LDAP를 이용해 AD DS가 제공하는 디렉터리에서 사용자 항목을 검색할 수 있습니다. 이때 AD는 그 서비스와 조직 구조를 포함한 전체 환경을 가리키는 이름으로 사용됩니다. 또 다른 예로, 사용자가 회사 PC에 로그인하지 못한다면 LDAP 검색 문법보다 도메인 컨트롤러의 상태, DNS, 시간 동기화, 계정 잠금, 신뢰 관계처럼 AD DS 운영 영역을 먼저 점검하는 편이 합리적입니다.
이 구분은 문서와 협업에서도 효과가 큽니다. 요청서에 단순히 AD 연동이라고 쓰면 인증인지 사용자 조회인지 그룹 동기화인지 알기 어렵습니다. 연동 목적, 인증 방식, 필요한 속성, 검색 범위, 서비스 계정, 암호화 조건을 함께 적으면 개발팀과 인프라팀이 같은 그림을 보게 됩니다. 특히 외부 SaaS와 연결할 때는 LDAP를 지원하는지, SAML이나 OIDC 같은 별도 인증 방식을 요구하는지 확인해야 합니다. 디렉터리 조회와 싱글사인온은 연관은 있어도 동일한 기능이 아닙니다.
도메인 설계에서 자주 놓치는 DNS, 시간, 권한의 기본 원칙
AD DS 운영에서 DNS는 부가 기능이 아니라 핵심 의존성입니다. 클라이언트와 서버는 도메인 컨트롤러를 찾고 각종 서비스를 발견하기 위해 DNS 레코드를 사용합니다. 인터넷용 공개 DNS를 우선으로 지정하거나, 내부 DNS 전달 규칙을 잘못 구성하면 로그인 지연과 도메인 가입 실패처럼 원인이 모호한 문제가 생길 수 있습니다. 도메인 구성원은 일반적으로 내부 AD DNS를 우선 참조하도록 설계하고, 외부 이름 해석은 전달자나 별도 규칙으로 처리합니다. 장애 대응 문서에는 사용 중인 도메인 이름, DNS 서버, 사이트별 네트워크 정보도 포함하는 것이 좋습니다.
시간 동기화 역시 인증 신뢰와 직결됩니다. 케르베로스 기반 인증은 시간 차이가 과도하면 티켓을 거부할 수 있으므로, 기준 시간 원본과 각 장비의 동기화 경로를 명확하게 정해야 합니다. 가상화 환경에서는 호스트와 게스트의 시간 동기화가 서로 충돌하지 않는지도 살펴야 합니다. 사용자는 비밀번호가 틀렸다고 느끼지만 실제로는 시간이 어긋난 경우가 있기 때문에, 계정 문제를 조사할 때 이벤트 로그와 시간 상태를 함께 확인하는 습관이 필요합니다.
권한은 최소 권한 원칙으로 나누어야 합니다. 모든 작업을 도메인 관리자 계정으로 처리하면 빠르게 보일 수 있지만, 실수와 탈취의 영향 범위가 지나치게 커집니다. 계정 생성, 비밀번호 재설정, 특정 조직 단위 관리, 서버 운영, 스키마 변경처럼 업무를 구분하고 필요한 권한만 위임하는 편이 안전합니다. 외부 애플리케이션이 LDAP로 읽기만 하면 되는 경우에도 전용 서비스 계정을 만들고, 대화형 로그인을 막고, 비밀번호 교체 절차를 마련해야 합니다. 관리 계정에는 다중 인증과 별도 관리자용 단말 같은 추가 통제를 검토할 가치가 있습니다.
LDAP 연동을 구현할 때 확인할 체크포인트
첫 단계는 연동 목적을 구체화하는 일입니다. 단순 사용자 검색인지, 로그인 검증인지, 그룹 멤버십을 애플리케이션 권한으로 변환하는지에 따라 필요한 설정이 달라집니다. 사용자 검색만 필요한데 모든 속성과 모든 조직 단위를 대상으로 잡으면 성능과 개인정보 측면에서 불리합니다. 필요한 사용자 집합을 정의하고, 검색 기준 위치를 정하고, 반환할 속성을 목록으로 만들면 구현과 검증이 쉬워집니다. 사번이나 메일 주소처럼 변경 가능성이 있는 값을 고유 식별자로 쓸 때는 변경 시나리오도 함께 설계해야 합니다.
둘째는 서비스 계정과 바인드 방식을 점검하는 일입니다. 많은 연동은 먼저 제한된 서비스 계정으로 서버에 연결한 뒤, 사용자가 입력한 식별자로 해당 사용자를 찾습니다. 이후 인증이 필요하면 그 사용자 자격 증명을 별도로 확인하거나, 제품이 지원하는 안전한 인증 흐름을 사용합니다. 애플리케이션 설정 파일에 평문 비밀번호를 오래 두지 말고 비밀 관리 도구나 보호된 환경 변수 등 적절한 저장 방법을 선택해야 합니다. 계정 잠금과 암호 변경이 서비스 중단으로 이어지지 않도록 만료 알림과 교체 절차도 마련합니다.
마지막은 실패를 관찰 가능하게 만드는 일입니다. 연결 오류, 인증서 오류, 검색 결과 없음, 권한 거부, 시간 초과는 사용자 화면에서 비슷하게 보일 수 있습니다. 그러나 운영 로그에는 서버 주소나 비밀값을 노출하지 않는 범위에서 오류 종류, 요청 식별자, 대상 조직 단위, 응답 시간 같은 단서를 남겨야 합니다. 테스트 환경과 운영 환경의 디렉터리 구조가 다르다면 검색 기준 위치를 하드코딩하지 말고 환경별 설정으로 분리합니다. 실제 사용자 계정 대신 최소 권한의 테스트 계정으로 성공·실패·잠금·만료 상황을 점검하면 배포 전 위험을 줄일 수 있습니다.
장애가 났을 때는 증상보다 인증 경로를 따라가면 빠릅니다
도메인 로그인 실패를 만났을 때는 사용자의 화면 메시지만 보고 결론을 내리지 않는 것이 좋습니다. 먼저 문제 범위가 한 명인지, 한 대의 PC인지, 특정 지점 전체인지 확인합니다. 범위가 넓다면 도메인 컨트롤러 가용성, DNS 질의, 네트워크 경로, 시간 동기화, 복제 상태 같은 공통 기반을 의심할 수 있습니다. 한 계정만 문제라면 잠금, 비활성화, 암호 만료, 그룹 정책 적용, 권한 변경을 살펴봅니다. 한 장비만 문제라면 도메인 가입 상태와 보안 채널, 로컬 DNS 설정, 최근 업데이트를 확인하는 흐름이 유용합니다.
LDAP 연동 장애는 연결 단계와 검색 단계를 분리해 기록해야 합니다. 서버에 접속하지 못하는지, TLS 검증이 실패하는지, 서비스 계정 바인드가 거부되는지, 검색 필터가 결과를 만들지 못하는지에 따라 담당자와 조치가 달라집니다. 단순히 포트가 열렸다는 사실만으로 안전한 연동이 보장되지는 않습니다. 인증서 이름과 만료일, 암호화 강제 여부, 방화벽 경로, 서비스 계정의 읽기 권한을 하나씩 확인해야 합니다. 운영 환경에서 임의의 관리자 계정으로 시험하는 방식은 감사와 보안 측면에서 피해야 합니다.
복구와 재발 방지도 함께 남겨야 합니다. 장애를 해결한 뒤에는 어떤 이름 해석이 잘못됐는지, 어떤 인증서가 누락됐는지, 어떤 권한 위임이 과했는지를 짧은 기록으로 정리합니다. 같은 문제를 막기 위한 모니터링 항목도 추가합니다. 예를 들어 도메인 컨트롤러의 복제 실패, 인증서 만료 예정, 서비스 계정 암호 교체 예정, LDAP 연결 오류율은 미리 경보로 잡을 수 있습니다. 디렉터리 서비스는 눈에 잘 보이지 않지만 많은 업무 시스템의 출발점이므로, 정상일 때 점검 기준을 만들수록 실제 장애 시간은 짧아집니다.
핵심 요약: 이름을 외우기보다 역할과 연결 지점을 구분하세요
AD는 조직의 디렉터리 환경을 넓게 부르는 말이고, AD DS는 그 환경에서 도메인 인증과 디렉터리 관리를 수행하는 핵심 서버 역할이며, LDAP는 디렉터리 정보를 다루기 위한 표준 프로토콜입니다. 이 세 가지를 한 문장으로 섞어 쓰면 익숙한 사람끼리는 통할 수 있어도 설계와 장애 대응에서는 오해가 생깁니다. 따라서 문서에는 누가 무엇을 제공하고, 어떤 애플리케이션이 어떤 계정으로, 어떤 경로와 암호화 방식으로 연결하는지를 분명히 적는 편이 좋습니다.
처음 도메인 환경을 운영한다면 거대한 구조부터 복잡하게 만들 필요는 없습니다. 신뢰할 수 있는 DNS와 시간 동기화, 이중화된 도메인 컨트롤러, 최소 권한의 관리자 체계, 검증된 백업과 복구 절차를 먼저 갖추는 것이 우선입니다. LDAP 연동은 필요한 범위와 속성만 열고 TLS를 적용하며 서비스 계정을 분리하는 원칙에서 시작하면 됩니다. 작은 기본을 지키면 계정 수와 연동 시스템이 늘어나도 관리 품질을 유지하기 쉬워집니다.
결국 좋은 디렉터리 운영은 기술 용어를 많이 아는 데서 끝나지 않습니다. 입사·이동·퇴사 같은 사람의 변화가 계정과 권한에 어떻게 반영되는지, 장애 시 어떤 팀이 어떤 순서로 확인하는지, 외부 시스템이 어떤 데이터를 왜 읽는지까지 연결해야 합니다. AD DS와 LDAP는 이 과정을 받쳐 주는 기반입니다. 역할을 구분해 설계하고 변화 기록을 남기면, 인증과 사용자 관리는 복잡한 예외의 집합이 아니라 예측 가능한 운영 체계가 됩니다. 정기 점검표에는 복제 상태, DNS 응답, 백업 복구 시험, 만료 예정 인증서, 관리자 권한 변경, 서비스 계정 사용 현황을 함께 넣어야 합니다. 평소에 작은 이상 징후를 기록하면 대규모 로그인 장애가 발생했을 때도 추측 대신 근거를 가지고 대응할 수 있습니다. 또한 변경 작업 전후에는 영향받는 사용자 범위와 되돌림 방법을 확인하고, 중요한 변경은 동료 검토와 작업 승인 기록을 남기는 절차를 운영해야 합니다.