실무에서 마주한 LDAP

실무에서 마주한 LDAP

• 웹 개발을 공부하면서 로그인 기능을 개발할 때는 블로그나 강의를 참고하며 세션 방식, JWT 방식, 소셜 로그인(OAuth2) 등을 중심으로 공부하고 적용해왔다.

• 그동안은 이 세 가지 방식이면 대부분의 서비스에 대응할 수 있다고 생각했다. 그러나 실제 실무에서는 전혀 다른 방식의 인증 흐름을 경험하게 되었다.

---

내가 경험한 기존 로그인 방식들

1. 세션 기반 로그인

가장 익숙했던 방식은 서버 세션을 이용한 인증 처리다.
다음과 같은 흐름이었다:

1. 사용자가 로그인 폼에서 ID/PW 입력
2. 서버에서 해당 사용자를 DB에서 조회
3. 저장된 해시된 비밀번호(BCrypt)와 비교
4. 인증 성공 시, HttpSession 생성
5. 클라이언트는 JSESSIONID를 쿠키로 받아, 이후 요청에 포함

서버는 인증된 사용자의 상태를 메모리 또는 Redis 세션 저장소에 유지했고, 요청이 들어올 때마다 세션 ID를 통해 인증 여부를 판단했다.

2. 토큰 기반 로그인 (JWT)

클라이언트와 서버가 분리된 SPA 환경에서는 JWT 방식이 더 적합했다.
이 방식은 서버가 사용자 인증 상태를 기억하지 않는 무상태(stateless) 구조를 만든다.

흐름은 다음과 같았다:

1. 사용자 로그인 → 서버가 인증 처리
2. 사용자 정보를 바탕으로 JWT 생성
   (예: userId, role, exp 등의 Claim 포함)
3. 클라이언트에 JWT 반환
4. 이후 모든 요청은 Authorization: Bearer <token> 헤더로 인증 처리

JWT는 서명된 문자열이기 때문에, 서버는 서명 검증만으로 사용자의 진위를 확인할 수 있다.
물론 토큰 만료, 탈취 등 보안 이슈를 고려하여 Refresh Token 전략도 함께 사용해야 했다.

3. 소셜 로그인 (OAuth2)

OAuth2는 인증을 외부에 위임하는 구조다.
예를 들어 Google, Naver, Kakao 등의 인증 시스템을 활용해 사용자 인증을 처리한다.

흐름은 다음과 같았다:

1. 사용자가 외부 서비스에 로그인
2. 인증 성공 후 Access Token을 받아옴
3. 해당 토큰으로 사용자 정보 조회
4. 우리 시스템에 연동된 계정이 있는지 확인 → 세션 or 토큰 생성

OAuth2는 비밀번호를 관리하지 않아도 되고, 신뢰성 있는 외부 인증을 사용할 수 있다는 점에서 장점이 많다.
하지만 결국은 자체 서비스의 인증 시스템(세션 or JWT)과 결합되어야 했고, 사용자 식별에 필요한 로직도 따로 구현해야 했다.

---

LDAP 인증 방식과 그 배경

실제 업무에서는 사용자 정보 자체를 외부에서 통합 관리하는 LDAP 기반의 로그인 방식을 사용했다.

HR 시스템과 LDAP의 관계

고객사는 사내에서 HR 시스템을 운영하고 있었다.
HR 시스템은 직원의 입사, 퇴사, 부서 이동, 직책 변경, 근무 상태 등 모든 인사 정보를 관리하는 시스템이다. 그리고 이 HR 시스템은 주기적으로 LDAP 서버와 연동(동기화)되어 있었다.

💡 즉, 고객사의 LDAP은 단순한 인증 도구가 아니라, HR 시스템의 사용자 정보를 디렉토리 구조로 제공하고 인증까지 처리하는 핵심 시스템이었다.

우리 회사 입장에서는 고객사 직원의 정보를 알 수 없고, 저장할 권한도 없었다.
그렇기 때문에 고객사의 LDAP 서버에 인증을 위임하는 방식을 사용했다

---

LDAP 로그인 흐름

LDAP 로그인 로직의 흐름은 다음과 같았다:

1. 사용자 ID/PW 입력
2. 서버에서 사용자의 LDAP DN(Distinguished Name)을 구성
   예: uid=hongkd,ou=users,dc=customer,dc=com
3. 해당 DN과 입력한 PW로 LDAP bind 요청
4. LDAP 서버가 인증 결과 반환
5. 인증 성공 시, 내부적으로 세션 생성 또는 JWT 발급

LDAP은 여기서 비밀번호 검증의 책임만 담당하고, 로그인 이후의 세션 관리나 권한 부여는 기존 방식과 동일하게 처리할 수 있었다.

---

실무에서 겪은 LDAP 인증 이슈

실제 운영 중 LDAP 인증은 성공했지만, 그 이후 애플리케이션에서 NullPointerException이 발생한 적이 있었다.
로그인 자체는 정상적으로 처리됐지만, LDAP 서버에서 전달받은 사용자 정보 중 일부 필수 속성(displayName)이 누락되어 있었기 때문이었다.

시스템은 이 속성들이 항상 존재한다고 전제하고 설계되어 있었고,
그 결과 특정 속성이 누락되었을 때 바로 예외가 발생해버리는 구조였다.

• ( 이후에 전달받은 내용이지만 고객사의 LDAP 서버가 업데이되며 해당 데이터가 누락되었다. )

문제 해결을 위해 진행한 조치

1.웹 로그를 확인해본 결과 누락된 displayName이 email에서 사용하는 @ 앞부분과 완전히 일치했다.
2.displayName (사용자 이름) 정보가 없다는 이유로 유저들이 당장 로그인을 할 수 없는 건 업무에 큰 지장을 준다.
3.email 정보의 @ 앞부분을 split 하여 해당 데이터가 누락된 경우 이 정보를 사용할 수 있도록 패치

정리하며

지금까지는 인증을 단순히 "세션이냐, 토큰이냐"라는 기술적 선택의 문제로만 접근했었다.
그러나 이번 LDAP 기반 인증 경험을 통해, 이제는 다음과 같은 질문을 먼저 고민하게 되었다:

• 사용자의 신원은 어디서 오는가?
• 비밀번호 검증은 누가 책임지는가?
• 시스템은 외부 인증 시스템과 어떻게 연동되어야 하는가?
• 사용자 정보 누락, 구조 변경 시 내 시스템은 어떻게 대응할 것인가?

LDAP은 단순한 기술이라기보다는,
조직과 시스템이 함께 움직이는 엔터프라이즈급 인증 구조라는 것을 실제로 겪으며 배울 수 있었다.

실무란 결국, 문서로만 배우지 못하는 현장감과 불완전함을 직접 마주하고 해결하는 과정이라는 것을 이번 프로젝트를 통해 깊이 느낄 수 있었다.