SAP Commerce 개발자들이 FlexibleSearch의 타입 시스템 기반 쿼리 메커니즘과 성능 최적화 패턴을 이해함으로써 SQL 번역 계층의 동작 방식 숙련

Context

SAP Commerce 개발자들은 FlexibleSearch를 일상적으로 사용하지만 단순히 "중괄호가 있는 SQL"로만 취급하여 타입 시스템 기반의 동작, 쿼리 번역 메커니즘, 성능 트랩을 간과한다. 프로덕션 환경에서 쿼리 성능 저하와 "결과 없음" 버그가 빈번하게 발생하는 근본 원인이 된다.

Technical Solution

• 타입 시스템 기반 쿼리 작성: {Product}, {pk}, {code}와 같은 중괄호 문법으로 데이터베이스 테이블이 아닌 플랫폼의 타입 모델을 직접 참조하며, de.hybris.platform.persistence.flexiblesearch.TranslatedQuery가 실제 SQL로 변환
• 지역화 속성 처리: {name[en]} 문법을 사용하여 *lp 지역화 테이블과의 JOIN을 자동으로 생성하고 언어 코드 필터링 적용
• 카탈로그 버전 컨텍스트 관리: 세션 기반의 암묵적 카탈로그 버전 필터링을 활용하되, 명시적 WHERE 절에서도 정확히 지정하여 "no results" 버그 방지
• 파라미터화 및 캐싱 전략: ?param 문법으로 SQL Injection 방지 및 쿼리 캐싱 성능 향상, 안정적인 참조 데이터(자주 변경되지 않는 엔티티)에만 쿼리 캐싱 활성화
• 서브쿼리에서 JOIN으로 마이그레이션: 깊은 중첩 서브쿼리(3단계 이상)를 Product AS p JOIN CatalogVersion AS cv ON {p.catalogVersion} = {cv.pk} 구조로 변경하여 성능 향상
• 읽기 전용 쿼리 패턴: FlexibleSearch는 INSERT/UPDATE/DELETE를 지원하지 않으므로 모든 쓰기는 ModelService를 통해 처리하고, 페이지네이션은 Java API의 setStart(0), setCount(20)으로 제어

Key Takeaway

FlexibleSearch는 데이터베이스 테이블이 아닌 타입 시스템을 쿼리하는 추상화 계층이므로, 번역 메커니즘, 암묵적 필터링(카탈로그 버전), 중첩 구조의 성능 트레이드오프를 정확히 이해하는 것이 프로덕션 안정성과 쿼리 성능의 차이를 결정한다.