실제 운영 환경과 미래 확장을 고려한 기술 선택
목차
- 선택의 배경
- 문제의식과 기술적 판단
- 선택 이후의 이점과 확장
- 최종 결론
📌 선택의 배경
이전 프로젝트에서는 Spring Data Elasticsearch 방식을 사용했으며,
대부분의 팀원들이 JPA에 익숙했던 만큼 Spring 방식이 익숙하고 적용도 쉬웠습니다.
Spring Data는 Spring 생태계에 최적화된 방식으로,
Repository 인터페이스만 정의하면 쿼리를 선언적으로 작성할 수 있어 빠른 개발이 가능합니다.
하지만 빠른 개발이라는 장점만을 보고 선택하기에는
저희의 프로젝트는 복잡한 도메인 로직, 다양한 검색 조건, 버전 관리, 보안 정책 등
현실적인 운영 환경 요구사항이 생각보다 많았습니다.
그래서 저는 단순한 접근보다,운영 환경에서 얼마나 유연하고 확장 가능한가? 라는 질문을 던지며 기술 선택을 재고하게 되었습니다.
📌 문제의식과 기술적 판단
1. 실무 환경에서의 제약
- Elasticsearch 버전 호환 이슈 Spring Data는 추상화가 많아, ES 버전 업그레이드 시 새로운 쿼리나 필드 문법을 바로 반영하지 못하는 경우가 잦습니다. 예: ES 8.x에서
type필드가 제거되었지만, Spring Data에서는 여전히 해당 구조를 필요로 할 수 있습니다.
- 보안/인증/통신 설정에 대한 유연성 부족 실제 운영에서는 HTTPS, API Key, JWT 인증, 사용자/역할 기반 인증 등 복잡한 보안 요구 사항이 많습니다. 하지만 Spring Data는 이런 설정을 내부에 감추고 있어 커스터마이징이 어렵습니다
2. 기술적 유연성 부족
- 복잡한 쿼리를 자유롭게 구성하기 어려움
match_phrase_prefix,nested,bool,range,aggregation등 고급 쿼리는 Spring 방식에서는 불편하거나 제한적으로만 사용할 수 있습니다.
- 쿼리 변경·디버깅이 불편함 쿼리 구조가 메서드명 혹은
@Query에 숨어 있어 유지보수, 디버깅, 조건 추가/변경 시 생산성이 저하됩니다.
📌 선택 이후의 이점과 확장성
저는 결국 공식 Elasticsearch Java API Client (Low-level)를 선택했고,
그 결과 다음과 같은 구조적/기술적 이점을 확보할 수 있었습니다.
1. 쿼리 구조를 명확하게 코드로 표현
- 쿼리를 Java 객체 형태로 직접 구성함으로써
- 조건 변경 시 수정이 용이
- 테스트 및 디버깅이 직관적
match,bool,nested,aggregation,prefix등 복잡한 검색 요구 사항도 정확하게 반영 가능
💡 반면 Spring Data는 메서드명에 숨겨져 있거나 문자열로 쿼리를 정의해야 하므로 변경/추적이 불편함
2. 최신 Elasticsearch 기능 대응이 빠름
- 공식 Java Client는 ES 릴리즈와 함께 관리되어 최신 문법 및 기능을 즉시 활용 가능합니다.
- 예:
match_bool_prefix,wildcard,normalizer,search_as_you_type도입 등 ES 버전 업그레이드에도 즉각적인 대응이 가능합니다.
3. 도메인 기반 검색 전략 분리
- 도메인마다 쿼리 전략을 분리해 설계 가능
- 검색어 기반 ai 추천
- 자동완성 & 연관 검색어
- 전략 패턴이나 추상화 클래스 적용이 쉬워 추후 유지보수성과 가독성 모두 확보
4. Spring 없이도 유연하게 사용 가능
- Low-level 방식은 Spring과 무관하게 작동
-
AWS Lambda, Kafka Consumer, Batch 환경에서도 독립적으로 사용 가능합니다.
→ 검색 전용 모듈로 분리하거나 서버리스 환경으로 확장하기에 매우 유리
-
5. 정리
| 구분 | Spring Data Elasticsearch (High-level) | Elasticsearch Java API Client (Low-level) |
|---|---|---|
| 추상화 수준 | 매우 높음 (JPA처럼 사용) | 낮음 (QueryDSL처럼 세밀 제어) |
| 사용법 | Repository 인터페이스 기반 자동 처리 | Java 객체 기반 직접 쿼리 구성 |
| 장점 | 빠른 개발, 선언적 사용, 익숙한 Spring 스타일 | 최신 ES 기능 대응, 정밀 제어, 가독성 |
| 단점 | 버전 호환성 문제, 커스터마이징 어려움 | 코드량 증가, 러닝커브 약간 존재 |
| 실무 적합도 | 프로토타입, 단순 검색 중심 | 실무, 복잡한 검색, 성능 최적화 중심 |
📌 최종 결론
Elasticsearch Java API Client는 정밀한 제어, 유연한 확장성, 최신 기능 대응력을 모두 충족하며,
실무 환경과 장기적인 서비스 운영에 최적화된 선택이었습니다.
Spring Data Elasticsearch가 JPA처럼 자동화된 개발에 적합하다면, Java API Client는 QueryDSL처럼 직접 제어 가능한 실전형 도구입니다.
그래서 "지금의 편의성"보다 "장기적인 안정성과 확장성"을 고려하여,
쿼리 로직을 커스터마이징 하여 이를 통해 정밀한 쿼리 제어, 유연한 확장성, 최신 기능 대응력을 모두 충족하여, 다양한 환경에 맞춰 유연하게 확장할 수 있는 실제 운영 및 확장성 측면에서 매우 유용한 Java API Client 방식으로 구현했습니다.
따라서 저는 단기적인 "개발의 편의성"보다 "운영의 신뢰성과 유연성"을 우선하여 ****Elasticsearch Java API Client를 선택하였으며, 이 선택은 프로젝트의 현재와 미래 모두를 고려한 전략적인 판단이라고 생각됩니다.
