📚 이번주엔 뭘 배웠지?
- Spring 백엔드의 핵심이라고 할 수 있는 JPA의 동작 원리를 본격적으로 배웠다.
기존에는 단순히 CRUD 기능을 구현하는 데 집중했다면,
이번에는 스프링과 데이터베이스 사이의 내부 구조를 이해하는 데 초점이 맞춰졌다.
기억에 남는 학습 내용은 다음과 같다.
- Controller / Service / Repository 구조 복습과 역할 이해
- DTO를 사용하는 이유와 toEntity, fromEntity 변환 패턴
- @RestControllerAdvice를 이용한 전역 예외 처리
- JPA 설정과 ddl-auto 옵션 차이
- 영속성 컨텍스트 개념
변경 감지(Dirty Checking) 와 쓰기 지연 - @Transactional이 Service 계층에 필요한 이유
- 엔티티 간 연관관계 설정 (@ManyToOne, @OneToMany, LAZY 전략)
- JWT 기반 로그인 인증 흐름과 토큰 검증 원리
👊 어떤 문제점이 있었지?
- 가장 어려웠던 부분은 영속성 컨텍스트개념이었다.
코드를 직접 작성할 때는 문제가 없어 보였지만,
왜 save를 호출하지 않았는데 update 쿼리가 실행되는지 처음엔 이해가 되지 않았다.
Author author = dto.toEntity(passwordEncoder.encode(dto.getPassword()));
방법1) - 영속성 컨텍스트에 save가 포함된 트랜잭션이 끝나고 나서야 쿼리가 실행되므로 이게 가능하다. - Post에 같이 저장되는건 cascade.PERSIST 효과 Author authorDb = authorRepository.save(author); author.getPostList().add(Post.builder().title("안녕하세요").author(authorDb).build());
방법2) author에 cascade = PERSIST 가 있어서 이것도 가능하다. 영속성컨텍스트랑 상관 X author.getPostList().add(Post.builder().title("안녕하세요").author(author).build()); authorRepository.save(author);
- 또한 연관관계 매핑에서 어느 쪽이 주인인지
왜 mappedBy를 써야 하는지
이 부분이 헷갈려서 여러 번 다시 찾아보고 정리해야 했다.
Author 엔티티에서 설계 (부모)
@OneToMany(mappedBy = "author", fetch = FetchType.LAZY, cascade = CascadeType.PERSIST, orphanRemoval = true)
@Builder.Default
private List postList = new ArrayList<>();
Post 엔티티에서 설계 (자식)
@ManyToOne(fetch = FetchType.LAZY)
// name : 외래키 컬럼 이름
@JoinColumn(name = "author_id", foreignKey = @ForeignKey(ConstraintMode.CONSTRAINT), nullable = false)
private Author author;
- JWT 부분도 처음에는 구조가 낯설어서
“이게 왜 안전한 거지?” 라는 의문이 들었지만
서버의 secretKey로 서명을 다시 만들어 비교한다는 원리를 이해하고 나서야 흐름이 잡혔다.
🙏 무엇을 깨달았고, 어떤 생각이 들었지?
-
이번 주에 JPA를 배우면서 예전에 학교랑 직장에서 JDBC로 직접 DB를 다루던 경험이 떠올랐다.
그때는 Connection 열고, PreparedStatement 만들고,
ResultSet 꺼내서 하나하나 객체에 값을 넣어주던 게 당연한 과정이었다.
쿼리 한 줄 바뀌면 코드도 같이 고쳐야 했고,
그때는 그게 그냥 “DB 쓰는 방식”이라고 생각했는데,
이번에 JPA를 배우면서 객체 값으로 JPA가 알아서 SQL을 만들어서 실행해준다는 게 조금 신기하다. -
스프링을 배우면서 “프레임워크를 써야될수밖에 없구나”라는 생각이 들었다.
특히 인상 깊었던 건 의존성 주입(DI) 개념이었다.
지금은 스프링이 대신 만들어주고 연결까지 해준다.
덕분에 코드가 훨씬 느슨하게 연결되고,
테스트나 수정도 훨씬 수월해진다는 걸 느꼈다.
😄 결과적으로, 현재 나의 상태는?
예전에는 어노테이션이 많아질수록 더 헷갈렸는데,
“이건 스프링이 관리하겠다는 뜻이구나”
“여긴 빈으로 등록돼서 싱글톤으로 쓰이겠네”
같은 생각이 조금씩 들기 시작했다.
코드를 짤 때도
“이 로직은 서비스에 있어야 하나, 컨트롤러에 있어야 하나”
이런 고민이 먼저 나가야 개발자처럼 생각하는 것이라고 볼수 있을거 같다.
👨🚀 앞으로 어떻게 하는게 좋을까?
이제는 스프링을 “쓰는 단계”에서
“스프링이 왜 이렇게 설계됐는지 이해하는 단계”로 가야 할 것 같다.
