[BE] 기술 스택 선정 - 100-hours-a-week/6-nemo-wiki GitHub Wiki

자세한 내용은 하단의 노션 페이지 참고해주세요!

기술 스택 선정 노션 바로가기

기술 스택 목록

분류 기술 스택
Language Java 21
Framework Spring framework 6.2.6 + Spring Boot 3.4.4
Build Gradle (Kotlin DSL)
Web Server Spring MVC (+ Spring WebFlux)
Database, ORM, DB Query 확장 MySQL, Spring Data JPA + MyBatis, QueryDSL
Caching Spring Cache + Redis
Messaging/Event Kafka + Redis Pub/Sub, Stream
Auth & Security Spring Security + JWT (jjwt)
Monitoring & Observability Spring Boot Actuator + Prometheus + Grafana
Test JUnit5 + Spring Boot Starter Test + Mockito + H2
Library 공통 사항

JAVA 21 사용

1. Virtual Threads

1.1 개념 요약

  • JVM 내부의 경량 쓰레드 사용 → 매우 저렴하고 빠름.
  • Reactive 스타일의 높은 처리량 + MVC 스타일의 높은 코드 이해도를 동시에 보장한다.

1.2 특징

  • Virtual Thread는 직접 OS Thread를 갖지 않음.
  • 필요할 때만 Platform Thread 위에 올라가 작업하고, blocking이 발생하면 바로 JVM 스케줄러로 반납.
  • JVM이 필요한 순간에만 Virtual Thread ↔ Platform Thread를 바인딩한다.

🔥 (그림 이해 정리)

1.3 Blocking I/O 방식으로 대용량 처리 가능

기존 JAVA 17에서는 대용량 처리를 하려면 Non-Blocking 방식인 WebFlux를 사용해야했다.

항목 설명
개발 생산성 WebFlux는 대용량 처리엔 뛰어나지만 Reactive 체이닝, 스케줄링 학습 필요 → 생산성 저하 위험
blocking 기반 API 대응 JPA, 외부 API, Redis 등 Blocking 기반 API와의 궁합이 Virtual Thread가 훨씬 좋음
코드 가독성 MVC 스타일 동기 코드 유지 가능

비동기는 함수 호출하고 바로 결과를 못 받는다. → "결과가 오면 이거 해줘" 라고 콜백/체이닝을 걸어야 한다. | | 운영 복잡성 감소 | Reactive Context 관리, stack trace 추적 어려움 없이 운영 가능 |

1.4 우리 서비스에서 필요한 이유

  • 대규모 알림 처리
    • 일정 생성 알림톡
    • 일정 예정 알림톡
    • → 외부 API 호출(알림톡 전송) & DB 저장 등 Blocking I/O가 많음.

결론:

Virtual Thread로 전환함으로써

기존 개발 흐름을 유지하면서 대규모 알림 처리를 고성능 + 저비용으로 수행할 수 있다.

2. Pattern Matching (Java 21 기능)

2.1 개념 요약

  • Java 21에서는 switch나 instanceof 구문에서 타입 판별 + 변수 바인딩 + 구조 분해를 한 번에 할 수 있게 됐다.

2.2 왜 좋은가?

항목 설명
가독성 향상 타입 검사 + 캐스팅 + 변수 추출을 한 번에 처리
코드 중복 제거 if-else, instanceof, 캐스팅 반복 제거
유지보수성 향상 Event 기반 처리 시, 분기 처리 코드가 간결하고 명확해짐

2.3 우리 서비스에 적용 포인트

  • 알림별 분기처리 로직
    • 알림 타입 (일정 생성, 일정 취소, 모임 생성, 모임 해체 등)에 따라 서로 다른 핸들링 필요
    • Pattern Matching을 사용하면 분기 + 타입 안전성 + 가독성을 동시에 잡을 수 있다.

3. Spring Boot 3.5.x 와의 호환성

3.1 출시 일정

  • 2025-05-22 릴리즈 예정

3.2 3.4.x와의 주요 차이

항목 3.4.x 3.5.x
Java 지원 버전 Java 17 기본 Java 21 완전 대응 (Virtual Thread 최적화)
Virtual Thread 지원 일부 가능 (Spring 자체적으로 제한 있음)
개발자가 직접 Bean 등록해야함 공식 최적화 지원 (Spring MVC에 TaskExecutor 개선)

spring.threads.virtual.enabled=true 로 사용가능 | | GraalVM Native Image 지원 | 초기 버전 (부분적) | 최적화 버전 (메모리/시작속도 향상) | | Actuator 기능 | 기존 수준 | Quartz 작업 트리거링, 구조화된 스택 트레이스 추가 | | Spring Security | OAuth 2.0 중심 | OAuth 2.1 및 Passwordless Login(비밀번호 없는 로그인) 지원 |

3.3 우리 서비스에 적용 시 기대 효과

  • Java 21 기반의 Virtual Thread를 완벽하게 활용 가능
  • 대규모 알림 처리에 필요한 고성능 TaskExecutor 구성 가능
  • 향후 GraalVM Native Image 최적화 시 빠른 기동시간 확보 가능

Framework(Spring 6.2.6 + Spring Boot 3.4.4)

Spring Boot 3.4.4는 3.4.x 안정화 라인에서 가장 성숙하고 안정적인 버전이다.

Spring Framework 6.2.6

(2025.04.17 releas)

조건

  • JDK - Java 17 이상 필수
  • Jakarta EE
    • javax.* → jakarta.* 로 마이그레이션 필요
  • Spring Security 6
  • AOT 지원

    • AOT 의미

      Spring은 많은 리플렉션, 프록시, 런타임 DI 등을 사용해서 부팅 시간이 길고 메모리 사용량도 많았어.

      @Lazy, @ConditionalOnXxx, @Bean

      구분 설명
      ⚙️ JIT (Just-In-Time) 실행 중에 바이트코드를 네이티브 코드로 즉시 변환하여 실행
      🧪 AOT (Ahead-Of-Time) 컴파일 시점에 바이트코드를 미리 네이티브 코드로 변환해서 실행

      Spring 5에서는 없었던 이유

      Spring 5는 런타임 유연성과 리플렉션에 크게 의존했기 때문.

Spring Boot 3.4.x 개선된 점

1. Virtual Thread 환경 대응 강화

  • Java 21 대응 시작 (Virtual Thread를 현실적으로 쓸 수 있게 준비)
  • Executor 설정을 통해 Virtual Thread 기반 TaskExecutor 쉽게 등록 가능
  • @Async, Web 요청 처리 등 Virtual Thread 적용 안정화
  • (※ 3.5.x 가야 완전 최적화되지만, 3.4.x도 수동 설정으로 충분히 실사용 가능)

2. Observability (관측성) 기능 강화

  • Micrometer 1.12 / OpenTelemetry 1.30 연동 강화
  • Spring Boot Actuator에서 metrics, health, tracing 데이터 제공 강화
  • Prometheus, Zipkin 같은 시스템과의 연결이 훨씬 쉬워짐
  • 구조화된 Stack Trace 전달 지원 (디버깅/모니터링 용이)

3. Web Server (Tomcat, Netty) 성능 최적화

  • Tomcat, Netty 기반 서버 설정 최적화 (Throughput, 응답 지연 개선)
  • HTTP/2 기본 설정 개선
  • 기본 Keep-Alive, Connection Pool 튜닝 반영 (대용량 트래픽 대응성 강화)

4. Spring Data & ORM 통합 안정화

  • MongoDB, Redis, Cassandra, R2DBC 등 최신 Spring Data 모듈과 호환성 확보
  • Hibernate ORM 6.x 대응 강화
  • JPA, Querydsl, R2DBC 기반 프로젝트에서 버전 충돌 스트레스 감소

5. DevTools & Test 환경 개선

  • Spring DevTools 핫 리로드 시 ClassLoader 메모리 누수 문제 해결
  • 테스트 환경 부트 타임 단축 (특히 @DataJpaTest, @WebMvcTest 쪽)

6. Security, OAuth2 안정화

  • OAuth2 Resource Server의 JWT 토큰 인증 예외 처리 보완
  • Passwordless 로그인 대응 준비 (Spring Security 6.2 사전 준비 완료)

Build 도구 (Gradle - Kotlin DSL 사용)

필요성: 빌드 과정을 자동화 라이브러리를 다운로드해 컴파일하고, 테스트하고, 패키징하여 배포까지 자동으로 처리해준다.

Maven VS Gradle

항목 Maven Gradle
스크립트 자유도 낮음 (XML 선언형) 높음 (Groovy/Kotlin 기반 DSL)
빌드 흐름 커스터마이징 제한적 (Profile, Plugin 필요) 자유롭게 task 조립 가능
새로운 작업 추가 플러그인 필요 코드 한 줄로 가능
빌드 조건부 분기 매우 불편함 if/else, when 바로 사용 가능
대규모 멀티모듈 관리 상대적으로 간단함 유연하지만 설계가 필요

Maven의 단점 → 빌드 속도가 느리고 유연성이 부족하다.

  • 고정된 생명 주기
    • validate → compile → test → package → verify → install → deploy 과정이 고정되고, 단계 사이에 커스텀 로직을 끼워넣기 불편하다.
  • 빌드 속도가 느리다.
    • 항상 전체 생명주기를 돌아야한다. (변경된 파일만 컴파일하는 최적화가 부족하다.)

Gradle은 빌드 과정에서 병렬 처리와 캐싱을 활용하여 Maven보다 10배~100배까지 향상된 성능을 구현할 수 있습니다. 

  • 빌드 흐름에 자유롭게 Task 추가 가능.
  • 모든 Task는 코드로 제어 가능

Groovy VS Kotlin

참고문헌: 우아한 기술 블로그

1. Gradle (Groovy)

  • 기존 Gradle 기본 스크립트 (build.gradle)
  • Groovy 기반이라 문법이 느슨하고 자유롭다
  • 함수/DSL 스타일이 자연스러움
  • 단점: IDE 자동완성(IntelliSense)이 약하다 → 오류 발견이 늦어질 수 있음

2. Gradle (Kotlin DSL)

  • .kts 확장자 (build.gradle.kts)
  • Kotlin 문법 기반 → 정적 타입 검사 가능
  • IntelliJ에서 완벽한 자동완성/에러 하이라이트 가능
  • 초기 세팅은 살짝 귀찮을 수 있음 (Strict함)

우리 서비스에 Gradle Kotlin DSL 을 사용해야하는 이유

1. 적응 시 빨라지는 개발 속도

  • 우리 서비스는 알림, 일정, 참여 관리 등 다양한 기능을 포함하고 있어, 기능 추가와 버그 수정이 짧은 주기로 반복될 가능성이 높다.
  • 빌드 스크립트 수정과 관리가 잦은 환경에서 IDE 자동 완성과 빠른 리팩토링은 개발 속도에 영향을 준다.

2. 모듈이 늘어났을 때 Kotlin의 이점

  • 오타를 잡아주어 관리가 편하다.
  • 자동완성 기능 (빌드 옵션 다르게 줄 때 자동완성 가능)

WEB SERVER

1. Spring MVC (Tomcat)

설명

  • Spring MVC는 전통적인 Servlet 기반 웹 프레임워크다.
  • Tomcat은 기본 내장 서버로서, HTTP 요청을 받고 서블릿 컨테이너로 동작한다.
  • 요청/응답이 Thread-Per-Request 모델로 처리된다.

Database & ORM

1. MySQL 8.0 사용

runtimeOnly 'com.mysql:mysql-connector-j'

Version - 9.1.0

  • MySQL 데이터베이스 드라이버.
  • JDBC를 통해 Java 애플리케이션이 MySQL과 통신할 수 있게 해줌.
  • runtimeOnly이기 때문에 빌드 시 포함되지 않고 실행할 때만 필요.

MySQL VS PostgreSQL

  1. 데이터 구조가 "복잡한 연산"을 필요로 하지 않는다
    • 저희 서비스는 CRUD 위주로 다룹니다. → 단순 쿼리 + 빠른 조회가 핵심입니다.
  2. 트랜잭션 복잡도가 비교적 낮습니다.
    • 모임 생성이 가입 등 모든 로직이 짧고 단순한 트랜잭션 범위 안에 있습니다.
  3. 대규모 복잡한 통계/분석 쿼리 존재 X
    • 사용자 수나 참여인원 등만 사용하여 분석 쿼리가 복잡하지 않습니다.
  4. 한정된 클라우드 자원
    • 팀프로젝트 특성상 한정된 자원에서 MySQL은 초기 인프라 구축, 운영 부담이 적습니다.

→ 다음 4가지의 이유로 현재 프로젝트에서 PostgreSQL는 오버스펙이라고 판단하였습니다.

2. JPA (+ MyBatis)

1. JPA 장점

  1. CRUD 자동 처리
  2. 영속성 컨텍스트 관리 자동
  3. 연관관계 매핑 관리 쉬움
  4. SQL 노출이 없어 비즈니스 로직에 집중 가능
  5. 1차 캐시가 있어 트랜잭션 내에서 중복 쿼리 방지

2. 우리 서비스에 MyBatis를 도입해야하는 이유 (JPA의 한계)

대용량 처리/배치에 유리

  1. 한 번에 1만 건, 5만 건을 Insert/Update/Delete 해야하는 경우
  2. 이벤트 공지를 위해 모든 사용자에게 알림을 보내야하는 경우
  3. 알림톡 전송 성공/실패 결과를 받아서 상태 업데이트

→ 이런 건 단순 JPA로 하면 느리고,

3. 왜 JPA로 하면 위험한가?

  1. 1차 캐시 저장 기능
    • JPA는 조회한 Entity를 1차 캐시에 저장해두는데, 수만 건 가져오면 메모리 터진다. GC도 위험하다.
  2. Flush 비용 증가
    • JPA는 트랜잭션 commit 전에 변경사항을 다 Flush 해야 해서 대량 데이터일 때 비용 폭발
  3. 트랜잭션 시간 증가
    • JPA 트랜잭션이 길어지면 락 경쟁 위험

4. MyBatis는 대용량 처리에 강한 이유?

  1. MyBatis는 바로 JDBC를 건드리기 때문
  2. 영속성 컨텍스트가 없다 → 그냥 받아서 바로 객체로 매핑
  3. batch executor를 통해 대량 INSERT, UPDATE 가능

→ 초기 MVP에서는 대용량 처리가 없으므로 JPA로 구현하나 추후 대용량 처리가 필요할 때 MyBatis 사용 에정

JPA

implementation 'org.springframework.boot:spring-boot-starter-data-jpa’

Version - 3.4.5

  • JPA (Java Persistence API) ORM 기능을 사용하기 위한 라이브러리.
  • 엔티티 기반으로 RDBMS(MySQL, PostgreSQL 등)와 자동 연동할 수 있음.
  • Hibernate가 기본 구현체로 내부적으로 동작.

3. QueryDSL

→ 복잡한 검색 쿼리를 코드처럼 안전하게 짜게 도와주는 도구

우리 서비스에 필요한 이유?

  1. 동적 조건 검색 필요
    1. 모임을 검색할 때 카테고리별 나누거나 검색창 기능도 있어 다양한 조건에 맞는 검색 필요
    2. 사용자의 입력이 필수가 아닌 선택인 경우 (들어오는 조건을 if문으로 걸렀을 때 JPA+JPQL은 코드가 지저분해진다.)

implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'

Version - 5.1.0

  • 즉, 타입 안전한 JPQL 쿼리를 자바 코드로 짤 수 있게 만들어준다.

annotationProcessor "com.querydsl:querydsl-apt:${dependencyManagement.importedProperties['querydsl.version']}:jakarta"

Version - 5.1.0

  • Querydsl 코드 생성기
  • 없으면 Q클래스가 아예 안 만들어진다.

annotationProcessor "jakarta.annotation:jakarta.annotation-api"

Version - 2.1.1

  • 기본 Jakarta 어노테이션 지원용
  • Q클래스 생성 과정 중 필요한 어노테이션들을 인식할 수 있게 해주는 역할

annotationProcessor "jakarta.persistence:jakarta.persistence-api"

Version - 3.1.0

  • JPA 표준 어노테이션 지원용
  • APT가 이 어노테이션들을 해석할 수 있어야 Q클래스를 정확히 생성할 수 있음

Spring Cache & Redis

1. Spring Cache

implementation 'org.springframework.boot:spring-boot-starter-cache'

Version - 3.4.5

  • Spring의 캐시(Cache) 기능을 쉽게 쓸 수 있게 해주는 라이브러리.
  • @Cacheable, @CachePut, @CacheEvict같은 어노테이션을 써서 데이터를 메모리나 Redis 등에 캐싱
  • 기본은 메모리(SimpleCacheManager) 기반이지만, Redis를 캐시 저장소로 연결하여 Redis 캐시로 동작

2. Redis

implementation 'org.springframework.boot:spring-boot-starter-data-redis'

Version - 3.4.5

  • Spring Boot가 Redis랑 통신할 수 있게 해주는 기본 라이브러리.
  • Redis에 데이터를 저장하거나 Redis를 캐시나 pub/sub로 쓸 수 있는 기능을 사용 가능.

implementation 'org.springframework.session:spring-session-data-redis'

Version - 3.4.3

  • Spring Session을 Redis에 저장하게 해주는 라이브러리.
  • 보통 기본 Spring Boot는 HTTP 세션을 서버 메모리에 저장.
  • 이걸 Redis에 저장하면 서버가 여러 대여도 세션 공유가 가능하고, 서버가 죽어도 세션이 살아있고, 로그인 유지가 가능
  • 이 라이브러리를 추가하면, 자동으로 사용자의 세션(HttpSession)을 Redis에 저장하고 관리해줌.
  • 주로 로그인 상태 유지, 서버 간 세션 공유(분산 시스템) 에서 필수로 사용

Redis Pub/Sub, Stream

구분 Redis Pub/Sub (알림) Redis Stream (알림톡)
목적 사용자에게 실시간 알림 PUSH 예약된 시간에 알림톡 발송 작업 관리
데이터 저장 ❌ 저장 안 함 (실시간 브로드캐스트) ✅ 메시지 저장 (이력 남김)
소비자 유무 관계 수신자가 없으면 소멸 없어도 메시지가 Stream에 남아있음
실패 대응 ❌ 실패 시 재전송 힘듦 ✅ 실패 시 다시 읽고 재처리 가능
적합한 경우 페이지 실시간 알림, 즉시 반영 알림 대량 예약 발송, 알림톡 실패 재시도

1-1. Pub/Sub 사용 이유

  1. 추후 멀티 서버 환경에서 SSE를 사용하기 위해
    1. 모임이나 일정 참여 인원이 실시간으로 증감하는 것이 보임
    2. 서비스 내의 알림이 실시간으로 옴
  2. 서비스 내의 즉시성 알림
    1. 일정 시작 1시간 전입니다와 같은 즉시성 알림

1-2. Stream 사용 이유

  1. 알림톡
    1. 예약된 시간에 알림톡 발송 작업 관리
    2. 메세지 저장해야함
    3. 실패 시 다시 읽고 재처리 해야함.

즉!!

Redis Pub/Sub은 메시지를 실시간으로 브로드캐스트하는 데 적합하고,

Redis Stream은 메시지를 저장하고 이후에 읽거나 재처리할 수 있으므로 대기열 관리나 예약 작업 같은 신뢰성이 필요한 작업에 적합합니다.

2. 알림에는 Kafka를 사용하지 않는 이유 (kafka를 꼭!! 사용하는 경우)

사용하는 경우 우리 서비스에 해당 여부
하루에 메세지 수억 건 X
마이크로서비스 수십-수백개 X
데이터 유실이 절대 용납되지 않는 경우 (ex- 주문, 결제) X

kafka를 사용하면 kafka 브로커 서버와 zookeper 서버가 따로 필요하므로 비용과 복잡성이 큼.

현재 알림에 kafka를 사용하기에는 너무 오버스펙이라고 판단하였습니다.

추후 복잡한 파이프라인 구축시 Kafka 사용

메시지 브로커 (Kafka)

implementation 'org.springframework.kafka:spring-kafka'

Version - 3.1.2 (Spring Kafka 버전, Spring Boot 3.4.5와 호환)

  • Kafka와 Spring 통합을 위한 기본 라이브러리.
  • Kafka Producer/Consumer 쉽게 구현 가능.
  • 메시지 주고받기, 이벤트 기반 아키텍처 구축에 필수.
  • 대규모 이벤트 스트리밍이나 비동기 처리를 위해 사용.

Spring Kafka Listener(@KafkaListener)로 Kafka 메시지 구독 가능.

Retry, ACK 관리, Consumer Group 제어 등 고급 기능도 지원.

Auth & Security

implementation 'io.jsonwebtoken:jjwt-api:0.11.5'

runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'

runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.5'

implementation 'org.springframework.boot:spring-boot-starter-security'

Version - 3.4.5

testImplementation 'org.springframework.security:spring-security-test'

Version - 6.4.5

  • Spring Security 기본 적용.
  • 사용자 로그인, 인증, 인가(Role, Authority) 처리 가능.
  • JWT 기반 인증 시스템, OAuth2 Client 연동할 때도 필요.

초기에는 모든 API가 보호되어서 설정 없으면 로그인 화면 튀어나올 수 있음.

(SecurityFilterChain 설정 필요)

Monitoring

implementation 'org.springframework.boot:spring-boot-starter-actuator’

Version - 3.4.5

implementation 'io.micrometer:micrometer-registry-prometheus’

Version - 1.14.6

Test

1. testImplementation 'org.springframework.boot:spring-boot-starter-test'

  • JUnit 5 (junit-jupiter) 기본 포함
  • Mockito 기본 포함
  • AssertJ, Hamcrest 등 다양한 테스트 도구 함께 포함
  • Spring TestContext Framework 지원 (ex. @SpringBootTest, @WebMvcTest, @DataJpaTest)

2. runtimeOnly 'com.h2database:h2'

  • H2 인메모리 데이터베이스를 테스트용으로 사용
  • application-test.yml에서 H2를 연결해서 테스트 환경에서는 가볍게 메모리 DB로 테스트 가능
  • DB가 따로 필요 없이 테스트할 때만 가볍게 실행됨.

implementation 'io.jsonwebtoken:jjwt-api:0.11.5'runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.5'

testImplementation 'org.mockito:mockito-core:5.7.0' // 최신 버전 확인testImplementation 'org.mockito:mockito-inline:5.2.0' // inline 모킹 활성화testRuntimeOnly 'org.junit.platform:junit-platform-launcher'

기타 Library

1. 기본 세팅 (Spring Boot Core)

implementation 'org.springframework.boot:spring-boot-starter'

Version - 3.4.5

  • Spring Boot의 기본 핵심 기능 모듈.
  • @SpringBootApplication, AutoConfiguration, 기본 Spring 컨테이너 등록 다 여기 있음.
  • 이걸 깔아야 Spring Boot 프로젝트가 정상 기동 가능.

2. Web (API 서버 + SSE 서버)

implementation 'org.springframework.boot:spring-boot-starter-web'

Version - 3.4.5

  • Spring MVC 기반 HTTP API 서버용 라이브러리.
  • REST API 만들 때 기본 컨트롤러 (@RestController, @RequestMapping) 지원.
  • Virtual Thread 기반 API 서버 만들 때 사용.
  • 내장 Tomcat 서블릿 컨테이너 포함.

implementation 'org.springframework.boot:spring-boot-starter-webflux'

Version - 3.4.5

  • Spring WebFlux 기반 비동기 논블로킹 서버용 라이브러리.
  • Flux, Mono 지원 (Reactive Streams)
  • SSE(Server-Sent Events) / WebSocket 같은 지속 연결 기능 구현에 필요.
  • 내장 Netty 서버 포함.

3. 입력 검증 (Validation)

implementation 'org.springframework.boot:spring-boot-starter-validation'

Version - 3.4.5

  • @Valid, @NotBlank, @Email 같은 입력 검증(Validation) 기능을 지원.
  • Spring Controller 단에서 DTO 요청 검증할 때 필수.

4. 개발 편의성

compileOnly 'org.projectlombok:lombok'

Version - 1.18.38

annotationProcessor 'org.projectlombok:lombok'

  • @Getter, @Setter, @Builder, @AllArgsConstructor 같은 코드 자동 생성 어노테이션 제공.
  • 코드 양을 획기적으로 줄일 수 있음 (특히 DTO, Entity 클래스 만들 때 유용).
  • compileOnly: 컴파일할 때만 사용.
  • annotationProcessor: 빌드 시 코드 생성에 사용.

단, 빌드 툴, IDE 모두 Lombok 플러그인 설치 필수.

5. Elastisearch

implementation 'org.springframework.boot:spring-boot-starter-data-elasticsearch’

Version - 3.4.5

Elasticsearch는 모임 검색의 키워드 기반 검색 및 검색어 유사도 기반 추천 기능을 지원하기 위해 도입하였으며 추후 대규모 데이터셋 대응, 다중 조건 필터링, 연관도 기반 정렬 등 검색 고도화에 대비하여 설계하였습니다.