GNIMS - 수락/거절 대기중인 일정 조회 API 최적화 일대기

포고자몽은 사실 포도 + 자몽의 오타입니다.

안녕하세요. 그님스 백앤드 이재헌입니다.

오늘도 저의 주된 업무는 쿼리 최적화입니다.

오늘은 목차 없이 편하게 써볼게요.

---

우선, 오늘로 제가 맡은 조회 API 쿼리 최적화 작업을 끝냈습니다.

와이어 프레임을 잘 못 해석한 탓에 수락 대기중인 스케줄 조회 API를 이상하게 만들었어요.

그럼에도 불구하고 잘 만들어주신 FE 동환님께 무수한 감사를 드립니다:)

뭐가 이상하냐구요? 와이어 프레임을 한 번 보시죠.

와이어 프레임을 보면 초대 받은 사람의 이름, 프로필을 딱히 내려줄 필요는 없었어요.

최적화 작업을 진행하는 김에 응답 API도 변경했습니다.

변경된 API 응답

---

별 일 아닌데 왜 글까지 쓰는거야?

언뜻 보면 Event, Schedule이 양방향 연관관계이기 때문에 Users 엔티티에 자유롭게 접근할 수 있는 것처럼 보입니다.

하지만 JPA는 @OneToMany 에서 Many 쪽으로 접근하면 그래프가 끊기게 됩니다. 그래서 엔티티로 반환 타입을 잡으면 추가 작업이 필요하고 그 과정에서 쿼리가 더 나가게 됩니다.

 

Event 엔티티는 BaseEntity를 상속 받고 있어서 createBy 를 가지고 있기는 하지만 우리가 원하는건 Event 엔티티의 createBy 를 가진 username입니다.

 

문제를 해결하기 위해 생각해본 방법들

1. createBy를 통해 userRepository에서 username을 가져오는 방법. 간편하지만 추가 쿼리가 나가게 됩니다.

2. Event와 User 연관관계를 맺기. 이 부분은 고려해야할 사항이 많을 것 같아 우선 제외했습니다.

3. 쿼리로 해결하자.

 

결국 쿼리로 해결하자 마음을 먹게 되었고 H2 콘솔을 켰습니다.

 

처음에는 jpql로 시도했는데 예외가 발생하더라구요. 원인을 파악해보려다 남은 작업들이 많아 nativeQuery를 사용했습니다. 나중에 기회가 되면 왜 오류가 발생하는지 찾아볼게요.

문제를 해결하고나서 보니 조금 찝찝하다는 생각이 들었어요. ORM 기술을 사용하는 naitveQuery를 쓰는게 맞을까? 문제를 회피한 것 같은 기분이 들기도하고 뭔가 제가 잘하고 있는건지 의문이 들었어요.

그 고민은 우연히 ORM의 사실과 오해글을 보고 조금 해소됐습니다. 사실 JPA 책을 저술하신 김영한님의 글이여서 더 믿을 수 있었던 것 같네요.