💬 풀스택 6회차 11주차 회고

 

모든 회고 방식은 5F 방식으로 작성하였습니다.

 

5F는 다음과 같은 키워드에 따라 순서대로 회고를 진행합니다.

---

• Fact: 사실, 무슨 일이 있었나?
• Feeling: 느낌, 어떤 느낌이 들었나?
• Finding: 배운 점, 어떤 인사이트를 얻었나?
• Future action: 향후 행동, 앞으로 무엇을 해야 할까?
• Feedback: 피드백, 앞서 정한 향후 행동을 실천해 본 뒤, 이에 대한 어떤 피드백을 받았나?

 

[제가 구현한 PBL 구현 미션 결과물입니다.] (*https://github.com/solmoonkang/spring-notice-board)

GitHub - solmoonkang/spring-notice-board: [구름 ☁️ PBL] 스프링을 이용해 게시판 구현 미션을 구현하는 저

 

👀 1. FACT, 무슨 일이 있었나?

---

• 이번 주는 풀스택 과정의 커리큘럼을 따라서 스프링 DB와 JPA 학습을 진행했습니다.
• PBL 게시판 구현 미션을 진행했습니다.
• 알고리즘과 CS 스터디를 진행했습니다.
  • 데이터베이스 CS에서 JOIN과 SQL Injection에 대해 학습했습니다.

 

🔥 2. FEELING, 어떤 느낌이 들었나?

---

이번 한 주는 JPA에 대한 기초를 다질 수 있었고 이해도가 한층 더 깊어진 한 주였다고 생각한다.

그동안 JPA에 대해 정확히 알지 못했던 모호하거나 부정확했던 지식들을 되돌아볼 수 있었고 아직 배워야 할 것들이 많다는 것을 알 수 있는 시간이었다.

그래서 미션을 진행하면서 처음 스프링과 JPA를 배우고 구현한다고 생각하면서 차근차근 나아가려고 했다.

미션의 요구사항으로 N+1 문제나 성능 향상을 위한 문제 해결을 위해 처음 접하는 QueryDSL이나 DB Index 같은 주제들을 따로 학습하면서 미션을 진행했다.

이 과정이 낯설고 어려웠지만, 그래도 구현을 할 때가 제일 재미를 느낄 수 있었고 다 구현을 했을 때의 뿌듯한 감정은 이루 말할 수 없는 것 같다.

특히, 이번 게시판 구현 미션에서 JPQL도 사용하면서 현재 데이터베이스 CS 스터디가 얼마나 도움이 되고 있는지를 실감했던 것 같다.

그동안 데이터베이스 공부를 소홀히 했던 탓에 미션 진행에서 살짝의 어려움이 있었지만, 그래도 스터디를 통해 데이터베이스를 학습하는 시간이 정말 좋은 타이밍이라고 생각한다.

그래서 이번 주는 내가 어디에 부족함을 느끼고 있는지를 명확하게 알 수 있는 시간이었던 것 같다.

더 중요한 건, 내가 부족한 점을 인지하고, 아직 배우지 못해 어려웠던 것임을 깨닫게 되어서 더욱 성장할 수 있다는 사실을 알게 되었다는 점이다.

이번 경험은 내가 앞으로 개발자로서 성장해 나가는 과정에서 동기부여가 되었고, 발전할 수 있는 가능성을 확인할 수 있는 시간이었다.

 

🔎 3. FINDING, 어떤 인사이트를 얻었나?

---

 

[ N+1 문제와 해결 방안 ]

JPA에서 N+1 문제는 주로 데이터를 조회하는 로직에서 발생한다.

N+1은 "일대다” 또는 “다대일” 관계의 엔티티 조회 시, JPA가 데이터를 가져오는 방식 때문에 발생한다.

 

N+1 문제는 처음에 1번의 쿼리로 N개의 결과를 가져온 후, 각 결과에 대해 추가적인 쿼리를 N번 더 실행하여 관련된 데이터를 가져오는 문제를 말한다.

이로 인해 예상보다 훨씬 많은 수의 쿼리가 데이터베이스에 전송되며, 이는 성능 저하로 이어질 수 있다.

 

예를 들어, 게시글과 댓글이 “일대다” 관계로 매핑되어 있고, 여러 게시글을 조회할 때 각 게시글의 댓글도 함께 조회하고 싶다고 가정해 보자.

• 게시글을 조회하는 쿼리는 1번으로 시작하지만,
• 각 게시글의 댓글을 가져오기 위한 추가 쿼리가 N번 실행되어 총 N+1번의 쿼리가 발생한다.

이러한 N+1 문제를 해결하기 위한 방법들은 다음과 같다.

---

Fetch Join:

• JPQL에서 제공하는 Fetch Join을 사용하여 관련된 엔티티를 한 번의 쿼리로 가져올 수 있다.
• 해당 방법은 관련된 엔티티를 처음부터 함께 로드하여 N+1 문제를 해결한다.

Batch Size 설정:

• @BatchSize 사용 혹은 글로벌 설정을 통해 한 번에 로드할 관련 엔티티의 수를 조정할 수 있다.
• 이는 N+1 문제를 완전히 해결하지는 않지만, 성능을 개선할 수 있다.

Entity Graph:

• 조회 시점에 특정 엔티티의 어떤 속성을 함께 로드할지 정의할 수 있다.
• 이를 통해 필요한 데이터만 선택적으로 로드하여 성능을 최적화할 수 있다.

 

또 다른 방법으로 QueryDSL을 사용하면 JPQL이나 Criteria API보다 훨씬 더 유연하고 타입 안전성이 보장된다.

 

QueryDSL을 사용하여 N+1 문제를 해결하는 주요 방법은 다음과 같다:

---

Fetch Join(조인):

• QueryDSL에서는 join( ), leftJoin( ), fetchJoin( ) 등의 메서드를 사용해
• 명시적으로 조인을 수행하여 연관된 엔티티를 한 번의 쿼리로 가져올 수 있다.
  • *fetchJoin( )*은 특히 연관된 엔티티를 함께 조회하도록 하여 N+1 문제를 해결한다.

프로젝션과 DTO:

• QueryDSL은 결과를 엔티티가 아닌 DTO로 직접 조회할 수 있다.
• 프로젝션 기능을 사용하여 필요한 필드만 선택하여 조회하면, 불필요한 데이터 로드를 방지하고,
• 이로 인한 추가적인 쿼리 실행을 줄일 수 있다.

벌크 연산:

• 때로는 데이터를 조회한 후 애플리케이션에서 로직을 수행하기보다
• 데이터베이스에서 바로 벌크 연산을 수행하는 것이 더 효율적일 수 있다.
• QueryDSL은 벌크 연산을 쉽게 작성할 수 있도록 지원한다.
• 이를 통해 데이터를 처리하는 과정에서 발생할 수 있는 N+1 문제를 회피할 수 있다.

---

 

[ 페이징 기능 구현 ]

스프링과 JPA를 사용할 때 페이징 기능 구현에는 offset 기반 페이징과 cursor 기반 페이징이 있다.

 

먼저 offset 기반 페이징은 가장 일반적인 페이징 방식이다.

이 방식에서는 전체 데이터 세트 중에서 어느 지점부터 데이터를 가져올지(offset)와 한 번에 몇 개의 데이터를 가져올지(limit)를 지정한다.

 

예를 들어, 한 페이지에 10개의 아이템을 보여주고 싶다면, 첫 페이지는 offset 0에서 시작해 10개의 아이템(limit)을 가져오고,

두 번째 페이지는 offset 10에서 시작해 다음 10개의 아이템을 가져오는 형식이다.

스프링 데이터 JPA에서는 Pageable 인터페이스를 통해 이런 방식의 페이징을 구현할 수 있다.

 

반면, cursor 기반 페이징은 데이터의 연속성을 기준으로 페이징을 처리하는 방식이다.

이 방식에서는 마지막으로 조회한 데이터의 위치(cursor)를 기억해 두고, 그다음 데이터부터 조회를 시작한다.

cursor 기반 페이징의 장점은 데이터가 추가되거나 삭제되어도 페이징에 영향을 덜 받는다는 것이다.

 

예를 들어, 어떤 데이터가 추가되었을 때 offset 기반 페이징에서는 페이지의 내용이 달라질 수 있지만, cursor 기반에서는 영향이 없다.

이 방식은 주로 실시간성이 중요하거나 데이터의 변동성이 큰 경우에 유용하다.

스프링 데이터 JPA에서는 직접 구현을 해야 하지만, Pageable과 유사한 개념을 사용하여 구현할 수 있다.

 

📊 4. FUTURE ACTION, 앞으로 무엇을 해야 할까?

---

• 이론 공부에만 그치지 말고, 실제로 코드를 작성하면서 배운 내용을 적용해 보자.
• 일정하고 규칙적인 생활 패턴을 유지하자.
• 매일 하나씩, 알고리즘 문제를 풀어보자.

 

✍️ 5. FEEDBACK, 앞서 정한 향후 행동을 실천해 본 뒤, 이에 대한 어떤 피드백을 받았나?

---

12주 차 회고 때 앞서 정한 향후 계획을 제대로 실천했는지에 대해서 피드백을 작성할 예정이다.