이 시리즈를 시작하며
사내 인프라를 구성할 때 “사용자 인증을 어떻게 통합할 것인가”는 생각보다 훨씬 근본적인 질문입니다.
NAS 접근 권한, 파일 서버 공유, 그룹웨어 로그인, 내부 서비스 SSO — 이 모든 것이 결국 하나의 질문으로 수렴합니다.
“사용자 정보를 어디에, 어떻게 저장하고 관리할 것인가?”
이 시리즈는 그 질문에 대한 실제 선택과 구현 과정을 기록한 것입니다.
Docker 기반 OpenLDAP 설치부터 커스텀 HR 스키마 설계, Synology NAS·Samba·그룹웨어 연동, 백업과 운영 자동화까지 — 실제로 운영 중인 시스템을 바탕으로 씁니다.
MS Active Directory를 선택하지 않은 이유
비용 구조가 다르다
Microsoft Active Directory를 도입하려면 세 가지 비용이 발생합니다.
| 항목 | 내용 |
|---|---|
| Windows Server 라이선스 | Standard 또는 Datacenter 에디션 필요 |
| CAL (Client Access License) | 사용자 또는 디바이스 단위 과금 |
| 유지보수·갱신 비용 | Software Assurance 또는 연간 구독 |
중소 규모 조직(30~100명)에서 Windows Server Standard + User CAL 50개를 구성하면 초기 비용만 수백만 원이 넘고, 사용자가 늘수록 선형으로 증가합니다. 클라우드(Azure AD P1/P2)로 가면 사용자당 월 과금으로 전환되지만 장기 운영 비용은 더 커지는 경우가 많습니다.
반면 OpenLDAP은 완전한 오픈소스입니다. 서버 비용(하드웨어 또는 클라우드 인스턴스)만 있으면 사용자 수에 관계없이 무료입니다.
이것이 가장 직관적이고 명확한 이유였습니다.
그 외의 차이점
비용 외에도 여러 기준으로 비교했습니다.
| 항목 | MS Active Directory | OpenLDAP |
|---|---|---|
| 라이선스 | 유료 (서버 + CAL) | 무료 오픈소스 |
| 운영 OS | Windows Server 필수 | Linux 권장 (크로스 플랫폼) |
| 관리 UI | ADUC, ADAC (GUI 풍부) | phpLDAPadmin 등 서드파티 |
| 표준 준수 | LDAP v3 + 독자 확장 | RFC 표준 LDAP v3 |
| 스키마 자유도 | 제한적 | 매우 높음 |
| GPO 지원 | 있음 | 없음 |
| Kerberos 통합 | 기본 포함 | 별도 구성 필요 |
| Microsoft 생태계 | 완벽 통합 | 부분 지원 |
| 비 Windows 연동 | 제한적 | 유연함 |
| 기술 지원 | MS 공식 지원 | 커뮤니티 의존 |
| 학습 곡선 | 완만 (GUI 중심) | 가파름 (CLI·설정 파일) |
MS AD가 압도적으로 유리한 환경이 있습니다. Microsoft 제품 중심의 조직, Windows PC가 주력이고 Office 365를 쓰며 GPO로 정책을 관리해야 한다면 AD가 훨씬 나은 선택입니다. 그 생태계 안에서는 AD가 당연한 표준이고 통합 비용이 오히려 낮습니다.
하지만 우리 환경은 달랐습니다.
우리가 OpenLDAP을 선택한 실제 이유
1. 비용
앞서 설명한 대로입니다. 중소 규모에서 사용자 수가 늘수록 AD CAL 비용이 부담이 됩니다. 동일한 예산을 서버 인프라나 개발에 쓰는 편이 훨씬 가치 있었습니다.
2. 중소 규모 SSO의 핵심 요구사항
필요한 것은 단순했습니다.
- 사내 백오피스(그룹웨어, 내부 서비스)에 단일 계정으로 로그인
- Synology NAS, Samba 파일 서버에 동일 인증 정보 사용
- HR 정보(부서, 직책, 재직 상태)를 계정에 담아 권한에 연결
이 세 가지는 Microsoft 생태계 없이도 OpenLDAP과 표준 LDAP 프로토콜로 충분히 구현됩니다. Synology DSM, Samba, 대부분의 오픈소스 그룹웨어가 LDAP 클라이언트를 기본 지원하기 때문입니다.
3. HR 관리를 디렉토리에 통합
일반적인 LDAP 구성은 UID·비밀번호·소속 그룹 정도만 다룹니다.
우리는 여기에 HR 속성을 추가했습니다 — 부서 코드, 재직 상태(재직/휴직/퇴직), 고용 형태(정규/계약/프리랜서) 등.
이렇게 하면 계정 관리가 곧 인사 관리가 됩니다. 신규 입사자 계정을 만들면 자동으로 해당 부서 그룹에 들어가고, 퇴직 처리를 하면 모든 서비스 접근이 차단됩니다. 별도의 HR 시스템과 계정 시스템을 이중으로 관리하지 않아도 됩니다.
OpenLDAP의 커스텀 스키마 기능이 이것을 가능하게 합니다. MS AD에서도 커스텀 속성 확장이 가능하지만 절차가 복잡하고 운영 환경에 미치는 영향이 큽니다.
OpenLDAP의 자유도: 장점이자 함정
OpenLDAP을 쓰면서 가장 처음 느끼는 것은 “뭐든 할 수 있다”는 자유입니다.
그리고 두 번째로 느끼는 것은 “뭐든 할 수 있다는 게 문제”라는 것입니다.
자유도의 장점
- 조직에 맞는 속성을 스키마로 자유롭게 정의
- 표준 objectClass 외에 AUXILIARY 클래스로 확장 가능
- 디렉토리 트리 구조를 원하는 대로 설계
자유도의 함정
LDAP은 표준(RFC)으로 정의된 프로토콜이지만, OpenLDAP은 그 표준을 얼마나 따를지를 전적으로 사용자에게 맡깁니다.
실제로 겪은 문제를 예로 들면:
- 초기에는 ou(organizational unit) 구조를 직관적으로 쌓다 보니 계층이 깊어졌습니다. 나중에 Synology가 특정 깊이 이상을 탐색하지 못하거나, 그룹웨어의 LDAP 검색 필터가 예상과 다르게 동작했습니다.
groupOfNames와posixGroup을 동시에 쓰려다 STRUCTURAL 클래스 충돌로 막혔습니다. RFC 표준을 벗어난 방식으로 해결하려다가 결국 AUXILIARY 클래스를 새로 정의하는 올바른 방법으로 돌아왔습니다.- 커스텀 속성을 마구 추가하다 보면 외부 시스템과 연동할 때 그 속성을 어디서 찾아야 할지 상대방이 알 수가 없습니다.
자유도가 높다는 것은 표준에서 벗어날 여지도 그만큼 많다는 뜻입니다.
결국 표준이 답이었다
여러 시행착오를 거친 결론은 명확합니다.
LDAP 표준을 최대한 지키는 것이 연동 유연성을 극대화한다.
구체적으로 말하면 이런 항목들을 표준에 맞게 설계하는 것입니다.
| 설계 요소 | 의미 |
|---|---|
| Base DN | 디렉토리 트리의 최상위 루트 |
| User Base DN | 사용자 검색의 시작점 (ou=people,...) |
| Group Base DN | 그룹 검색의 시작점 (ou=Groups,...) |
| Root OU | 최상위 조직 단위 구조 |
| 검색 범위(Scope) | sub(하위 전체) / one(직계 하위) / base(현재만) |
| 최대 계층 깊이 | 연동 시스템이 탐색할 수 있는 깊이 한계 |
이 여섯 가지를 명확하게 설계하고 나니, 연동이 달라졌습니다.
- 완성된 플랫폼 연동: Synology NAS DSM, Samba SMB — 설정 화면에서 Base DN과 검색 필터 몇 줄만 입력하면 끝났습니다.
- 직접 개발한 그룹웨어 연동: LDAP 표준을 따르니 개발자가 ldapsearch 한 번으로 구조를 파악하고 바로 연동 코드를 작성할 수 있었습니다.
표준 LDAP 구조는 범용 언어와 같습니다. 표준을 지키면 상대방이 누구든 대화가 통합니다.
이 시리즈의 구성
| 편 | 주제 |
|---|---|
| 00 | 왜 OpenLDAP인가 (이 글) |
| 01 | LDAP 트리 설계 원칙: Base DN부터 계층 깊이까지 |
| 02 | Rootless Docker로 OpenLDAP 설치하기 |
| 03 | TLS 인증서 발급과 초기 디렉토리 구성 |
| 04 | 커스텀 스키마 설계: groupPosixAux로 표준 충돌 해결하기 |
| 05 | 사용자·그룹 관리와 Samba 연동 (NT 해시 문제 포함) |
| 06 | Synology NAS LDAP 연동 |
| 07 | 백업·로그·운영 자동화 |
다음 편에서는 실제 디렉토리 트리를 어떻게 설계했는지, 그 결정 근거를 하나하나 짚어보겠습니다.
