인프런 커뮤니티 질문&답변
작성한 질문수
[위치 이름 기반으로 호텔을 조회하는 메서드] 코드 질문 드립니다.
해결된 질문
작성
·
22
·
수정됨
0
강의 마지막에 위치 이름 기반으로 호텔을 조회하는 메서드 관련하여 질문 드립니다.
참조 관계
강의에서 hotel, location 양쪽에서 서로를 참조하고 있습니다. 여기서는 location에서만 hotel을 참조하는 것이 맞지 않나요?? 우선 location을 생성할 때 hotel이 필요하고, location은 호텔을 위해 생성된 호텔에 종속적인 모델이기 때문에 location에 두는게 맞다고 생각합니다.
위치 기반 호텔 조회 메서드
1번에서 location에서 호텔을 참조한다면, 위치 기반 호텔 조회 메서드는 location에 있어야 한다고 생각합니다.
또한 지금 호텔을 전부 탐색하며 일치하는 모델을 찾고 있는데, 그냥 단순히 bruteforce 로직을 보여주시려고 하신걸까요?? 호텔과 location을 조인해서 가져오거나, 그냥 location에서 name 인덱싱을 걸고 호텔 id 값 찾아서 + 호텔 조회하는 그런 방식을 생각했는데 logic으로 적어주신 이후 최적화 과정이 빠진 것이 아쉽습니다. 이런 부분들을 어떻게 최적화 할 수 있는지 다양한 방법들을 배우고 싶습니다ㅠ
제가 맞다고 주장하는 것이 아니라 몰라서 질문 드립니다.
감사합니다 :)
답변 2
0
안녕하세요 :) 질문 정말 좋습니다.
1) Hotel ↔ Location 서로 참조 관계에 대해
결론부터 말씀드리면 둘 다 가능하지만, 실무에서는 보통 “단방향”을 더 많이 선택합니다.
Location이 “호텔을 위해 만들어진 종속 모델”이라면
말씀하신 것처럼 Location → Hotel 단방향도 논리적으로 말이 됩니다.다만 Booking 같은 도메인에서는 Location이 특정 Hotel만을 위해 존재한다기보다는
“주소/도시/지역” 같은 공통 개념(값 객체/별도 엔티티) 로 보는 경우가 많아서,
보통은 Hotel이 locationId(또는 Location)를 참조하는 단방향이 더 흔합니다.
강의에서 양쪽 참조처럼 보이게 둔 건, 관계를 직관적으로 보여주기 위한 교육용 표현이었고,
실무에서는 한쪽만 참조 + 조회는 별도 계층에서 처리하는 쪽이 유지보수성이 좋습니다.
2) 위치 기반 호텔 조회 메서드는 어디에 있어야 하나?
이 부분도 아주 좋은 질문이에요.
findHotelsByLocationName() 같은 기능은
Location “자기 자신”의 행위라기보다는 데이터 조회(Query) 성격이 강합니다.
그래서 OOD 관점에서는 보통
Location 엔티티 안에 넣기보다는
HotelRepository / SearchService / AvailabilityService같은 조회 전용 계층에 두는 게 더 자연스럽습니다.
이유는 간단합니다.
조회 로직에는 보통 인덱스/DB 조인/캐시/검색엔진 같은 인프라 최적화가 붙고,
그걸 Location 엔티티에 넣으면 오히려 엔티티가 “도메인 모델”이 아니라 “DB 접근 객체”처럼 변해버리는 문제가 생깁니다.
즉,
Location: 값/정보 모델로 단순하게 유지
조회: Service/Repository에서 처리
이 구조가 가장 깔끔하다고 할 수 있습니다.
3) bruteforce 탐색은 의도된 baseline 예시입니다
네, 질문하신 것처럼 강의의 전체 탐색 로직은 일단 동작하는 baseline(개념 검증용) 입니다.
좋은 피드백이에요. Object Oriented Design 설계 강의 이기 때문에 이 강의 단계에서는
코어 로직에 대한 최적화는 포함되지 않았습니다. 현재 오픈소스 강의 개선작업중이기 때문에
이 작업이 완료되면 OOD 강의 또한 주신 피드백을 반영해서 업데이트 될 예정입니다.
피드백 감사합니다.
4) 최적화 방향
최적화 방법들은 다음 시스템 디자인 강의 섹션에서 배우실 수 있습니다.
질문 주신 “조인/인덱싱/2-step 조회”가 실무에서 가장 흔한 방식입니다.
대표적인 최적화는 아래처럼 단계적으로 갑니다.
가장 정석: DB 인덱스 + 조인
Location(name)인덱스Hotel(location_id)인덱스WHERE location.name = ?로 조인해서 바로 조회
2-step 조회
locationName -> locationIdlocationId -> hotels조회
High Availability - 캐시/역인덱스
Redis에
locationName -> hotelIds저장상세는
hotelId로 조회
검색 요구가 커지면 Search 분리
자동완성/오타/동의어/필터까지 붙으면
OpenSearch/Elasticsearch로 분리하는 게 일반적입니다.
질문 감사합니다. 다른 질문 있으시면 언제든지 남겨주세요!
좋은 하루 되세요!
0
안녕하세요, 인프런 AI 인턴입니다.
임정현님, 질문 감사합니다. 강의에서 다루신 위치 기반 호텔 조회 메서드와 관련한 참조 관계와 최적화 방법에 대한 고민을 이해합니다. 이에 대한 몇 가지 방법을 제안 드리겠습니다.
참조 관계:
- 일반적으로
location이hotel을 참조하는 게 적합합니다. 이는location이hotel에 종속적이기 때문일 수 있습니다. 그러나, 구체적인 요구 사항이나 도메인 설계에 따라서 두 객체 간의 참조 방향은 달라질 수 있습니다. 각 케이스에 따라 서로를 참조할지, 단방향 참조할지 결정하는 것이 중요합니다.
- 일반적으로
위치 기반 호텔 조회 메서드:
- 현재 코드에서 모든 호텔을 탐색하는 방식이 비효율적이라 느껴지신 것 같습니다. 이는 단순히 강의에서 기본적인 부분을 설명하려는 의도가 있을 수 있습니다.
- 최적화를 위해서는 다음과 같은 방법을 고려해 볼 수 있습니다:
- 조인 사용: 데이터베이스 레벨에서
JOIN을 사용하여location과hotel을 결합해 필요한 데이터를 선별적으로 조회할 수 있습니다. Spring Data JPA에서는 @Query 어노테이션을 사용해 HQL 또는 SQL을 직접 작성할 수 있습니다.
- 인덱싱:
location의 이름이나 관련 필드에 인덱스를 설정하여 검색 성능을 향상시킬 수 있습니다.
- 캐싱: 자주 조회하는 데이터의 경우 캐싱을 통해 접근 속도를 높일 수 있습니다.
- 조인 사용: 데이터베이스 레벨에서
- 현재 코드에서 모든 호텔을 탐색하는 방식이 비효율적이라 느껴지신 것 같습니다. 이는 단순히 강의에서 기본적인 부분을 설명하려는 의도가 있을 수 있습니다.
각 방법은 상황에 따라 다르게 적용될 수 있으며 최적화에는 다양한 시도가 필요합니다. 최적화 과정에서 데이터베이스 튜닝이나 도메인 모델 설계를 같이 고려해보는 것이 도움이 될 것 같습니다.
혹시 더 궁금한 내용이 있다면 언제든지 질문해 주세요. 감사합니다!
Spring Data JPA Documentation에서 추가 정보를 확인하실 수 있습니다.