intro : 왜 매번 끝나고 나서야 부족한점이 보이고 아쉬울까?
어느덧 마지막 블로그 포스팅 한지 열흘이 지났다. 분명 이전 글에서 앞으로 블로그를 열심히 쓰겠다는 다짐을 했던 것 같은데 또 글을 쓰지 않고 있다니,,, 반성을 얼마나 더해야할까. 이전에는 하루하루 글 쓰는 재미로 살았었는데 요즘은 글 쓸 시간이 없어져서 일주일도 아닌 열흘만에 글을 쓸 시간이 난다. 그동안 뭐 헀더라? 생각을 해보니 무언가 한건 많은거 같은데 막상 적으려니 기억이 가물한거 같다.
기억을 되짚어보니, 일단 테스트 코드에 대한 깊은 통찰을 해본거 같다. 항상 개발 진행시에 테스트 코드를 제외하고 프로덕션 코드에만 집중했었는데 그 방식이 굉장히 잘못된 방식이라는 것을 최근에야 크게 느끼고 있다. 내가 작성한 코드가 제대로 작성된 코드라는 것을 검증하기 위해서 API를 POST-MAN과 같은 툴로 일일이 테스트 해본다거나, 로그인 페이지에서부터 내가 확인하고자 하는 기능이 존재하는 페이지까지 이동해서 검증하는… 그런 이상한 방식을 버릴수 있게 되었다. 다만 아직도 테스트 코드에 대한 경험이 부족해서 어디까지 테스트를 진행해야 하는가? 에 대한 의문은 아직도 결론을 내리지 못하고 있다. 조금 더 깊은 고민과 경험이 필요해 보인다고 느낀다.
최근에 팀원들과 진행되었던 미니프로젝트에서도 팀장으로서 팀원들에게 가이드라인을 줄 때 테스트 코드는 차후에 작성하고, 기능구현을 우선하자! 라는 말을 내가 내입으로 했는데, 지금 와서 다시생각해보면 정말 얼척없는 바보같은 오더였던것 같다. 양보단 질을 우선해서 질좋은 코드를 작성할수 있도록 테코도 겸해서 작업이 진행되었어야 했는데, 이건 반드시 피드백이 되어야 할 부분인 것 같다.
테스트 코드에 대한 통찰을 하면서, JPA에 대한 깊은 공부가 필요하다고 크게 느꼈다. 어느정도 JPA에 대해서 이해했다고 생각하고 프로젝트 진행을 했지만, 막상 엔티티 설계 및 JPQL 혹은 QUERY-DSL 작성시에 속도감 있는 작업이 진행되지는 않았다. 명확하게 알지 못하니, 돌다리 두드리듯이 확인을 하면서 진행을 해야만 했고. 수없이 돌다리를 두드리면서 했지만서도, 프로젝트가 끝나고 혼자 부검을 해보니 잘못된 부분이 수도없이도 많이 나왔다. 특히 내가 이번 미니프로젝트 발표시에 마지막 목차에 회고 부분이 존재하였는데 회고에 작성한 내용중 Fetch Join에 대한 Limit Query를 변경해야 할것 같음
에 대해서 어떠한 문제가 있었고, 이 문제의 원인이 무엇인지 부트캠프 인원들에게 설명하는 순간이 있었는데. 나중에 알고보니 제대로 내가 문제를 인지하지 못하고 있었고, 심지어 제대로 알지 못하는 상황에서 해당 내용에 대해 다른 분들에게 질문에 대한 답변을 했다는 사실이 부끄러웠다.
@Override
public List<Feed> findFeeds(Long lastFeedId, Pageable pageable) {
return jpaQueryFactory
.selectFrom(feed)
.leftJoin(feed.user).fetchJoin()
.leftJoin(feed.images).fetchJoin()
.where(
feed.status.eq(Status.ACTIVE).and(
(lastFeedId != null ? feed.id.lt(lastFeedId) : null)
)
) // if(닉네임 != null)
.orderBy(feed.id.desc())
.offset(pageable.getOffset())
.limit(pageable.getPageSize())
.fetch();
}
위 쿼리가 날 굉장히 부끄럽게 만든 쿼리였는데, 해당 쿼리는 실제로 log 확인시에 다음과 같이 실행된다.
무언가 잘못된게 보이는가? 일단 첫번째로 쿼리에 limit
와 offset
을 적용하였는데 쿼리 log에는 보이지 않는다. 이게 일단 1차적 문제이다. 또한 로그에서 hibernate
에서 warn
으로 친절히 문제를 알려주고 있다.
2025-05-25T13:55:28.550+09:00 WARN 14307 --- [eureka-gram-user] [nio-8081-exec-6] org.hibernate.orm.query : HHH90003004: firstResult/maxResults specified with collection fetch; applying in memory
의역하자면 fetch join에 대한 결과를 어플리케이션 레벨에서 페이징 처리하겠다. 즉 모든 쿼리결과를 메모리에 올린후에, limit offset을 적용하겠다. 라는 뜻이다. 굉장히 위험한 경고문구가 있었음에도 마지막날까지 해당 문제에 대해서 아무도 알지 못했었고, 우리는 프로젝트를 제출했다.
그래서 JPA에 대한 깊은 공부가 필요하다고 느꼈고, 금주 주말에는 나의 갓영한 선생님의 JPA 강의를 처음부터 다시 들었다. 그런데 이게 무슨일일까? 우리 영한선생님 강의에 나의 위 문제에 대한 내용이 포함된 강의 내용이 있었고, 영한 선생님은 반드시 OneToMany 관계에서의 FetchJoin 페이징에 대해서는 조심하고 일러주고 있었다. 심지어 이 문제를 해결하는 방법에 대해서도 여러방법에 대한 케이스를 장단점으로 나누어서 알려주고 계셨다. 그것도 지금으로부터 6년전의 영상임에도 불구하고 아직도 나에게 가르침을 주시고 계시는데, 이 얼마나 나의 모자람인지 다시 한번 반성하게 된다.
그렇게 이번주 JPA에 대한 강의를 전반적으로 다시한번 듣는 시간을 가졌고, 현재 진행형인 상황이다. 공부한 내용은 빠른시일내에 정리를 해야겠다. 또 정리안하면 금방 내 머리속에서 날라갈테니까?…
위 내용은 아마 차후에 트러블 슈팅 챕터를 하나 만들어서 정리해볼 생각이다. SVG 파일이 만들어지는데로 바로 첫 주제로 작성될 예정이다. (물론 그게 언제가 될지는 모르겠다. 아마 부캠 끝나기 전에는 하겠지?..)
하여튼 10일동안 미니프로젝트에 대한 부족함을 채우는 시간으로 활용하다보니, 시간이 금방 지나갔었고 이걸 따로 기록을 못해둔게 좀 아쉽다. 앞으로 있을 종합프로젝트와, 최종융합프로젝트는 매 순간 이슈에 대해 기록을 하는 습관을 가져보려고 한다. 다양한 이슈의 기록과 한계 돌파에 대한 시도는 굉장히 나에게 큰 자산이 될테니 반드시 필요하다고 느껴진다.
그나저나 다음 종합 프로젝트가 벌써 걱정되는데, 저번 기수 1등 작품의 수준을 보니 과연 내가 할 수 있을까? 라는 생각이 든다.
하여튼 다음주엔 종합프로젝트 준비로 눈코뜰새 없어서 다음주 diary도 결국 종합프로젝트 이야기만 잔뜩하겠지만 기대된다. 과연 어떤 결과물이 나올지? 어떤 팀원들과 하게될지? 어떤 주제로 하게될지? 어떤 기술스택을 사용하게될지? 두근두근…
일단 오늘 글은 여기서 마무리 해야겠다. 항상 마무리가 어렵다니까? 오늘은?