[배운 점 & 회고] 7월 17일

작업 개요

• 프로젝트/업무명 : 안티드론성능평가시스템/백엔드
• 기간 : 2025.03.02 ~
• 주요 기술 스택 : Java, MySQL, Spring Boot

---

배운 점

• Service와 RepositoryService로 계층을 분리한 구조에서는, 수정/삭제 작업 전에 반드시 엔티티를 Service 계층에서 명시적으로 조회해야 한다.
• JPA에서는 @Transactional 범위 내에서 영속 상태의 엔티티의 필드만 변경해도 DB에 반영되며, save() 호출은 필수가 아니다.
• 엔티티  수정은 Entity 내부에 updeteFromeDTO() 같은 메소드를 두면 응집력 있고 안전한 구조가 된다.
• 삭제 작업 시에도 단순히 deleteById() 를 호출하기 보다, 대상이 현재 로그인 사용자의 데이터인지 검증 후 삭제하는 것이 안전하다.
• 로직은 짧아졌어도, 그 코드가 동일한 대상에 대해 동일한 방식으로 동작하는지를 항상 먼저 검토해야한다.
• 데이터 삭제나 수정과 같은 영향도가 큰 작업일수록 트랜잭션 범위와 검증 절차가 중요하다.

---

회고

이번 학습은 계층형 구조 안에서 엔티티를 어디서 조회하고, 누가 수정/삭제 책임을 져야 하는가에 대해 고민하면서 시작되었습니다.

처음에는 RepositoryService에서 DTO만 받아 처리하거나, 삭제 시 deleteById()를 호출하는 단순한 방식으로도 충분할 것이라 생각했습니다.

그러나 이러한 구조는 점점 비즈니스 로직이 퍼지고, 검증 책임이 모호해지는 문제를 낳았습니다. 반복문을 줄이는 리팩토링보다는, 그 코드가 수행하던 "검증, 책임, 흐름"을 유지하고 있는지가 더 중요하다는 것을 다시금 깨달았습니다.

앞으로는 기능을 구현하거나 개선할 때

• 이 책임은 어느 계층이 가져가야 할까?
• 기존 코드가 하던 일을 놓치지 않았는가?
• 이 로직은 데이터 보안 측면에서도 안전한가?

이 세 가지 질문을 먼저 던지고 시작하는 습관을 들이려고 합니다.