코드 땜장이

Spring 스테레오타입 애너테이션 차이: Component, Controller, Service, Repository를 언제 써야 할까 빠른 답 @Service , @Controller , @Repository 는 모두 @Component 기반이지만 계층 의미와 일부 런타임 동작이 다르다. Spring 6 이상, 현재 Spring Framework 7 기준에서는 @RequestMapping 만 붙은 @Component 가 MVC 핸들러로 등록되지 않는다. @Repository 는 데이터 접근 예외를 Spring의 DataAccessException 계층으로 변환하는 흐름과 연결된다. 계층별 애너테이션은 요청 처리, 트랜잭션, AOP, 테스트 범위를 읽는 기준이 된다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 모두 Bean인데 다르게 쓰는가 현재 버전 기준으로 달라진 부분 요청부터 응답까지의 코드 구조 설정과 디버깅 단서 계층별로 잘못 섞이기 쉬운 지점 공식 문서에서 확인할 지점 한눈에 비교 Bean 등록 네 애너테이션 모두 컴포넌트 스캔 대상이 될 수 있다. @Controller , @Service , @Repository 가 @Component 의 구체화된 스테레오타입이기 때문이다. 역할 표현 @Component 는 일반 Bean, @Controller 는 웹 요청 처리, @Service 는 비즈니스 흐름, @Repository 는 데이터 접근 계층을 나타낸다. 요청 매핑 현재 Spring MVC에서는 타입 레벨에 @Controller 또는 이를 포함한 @RestController 가 있어야 핸들러 후보로 인식된다. 예외 변환 @Repository 는 영속성 기술별 예외를 Spring의 데이터 접근 예외 계층으로 바꾸는 후처리와 맞물린다. 운영 단서 Actuator mappings, AOP 포인트컷, 슬라이스 테스트에서 계층별 애너테이션은 분류 기준으로 쓰인다. 네 애너테이션의 차이는 “Bean이 되느냐”만 보면 작아 보인다. 하지...

스프링에서 JPA를 쓰는 이유: DAO 반복 코드를 줄이고 데이터 접근을 더 안정적으로 설계하는 법 빠른 답 JPA는 반복 CRUD와 DAO 구현을 줄여 도메인 로직에 더 집중하게 해준다. Spring Data JPA를 쓰면 메서드 이름 쿼리, 페이징, 정렬, 감사 기능을 같은 리포지토리 모델로 다룰 수 있다. 변경 감지와 트랜잭션 관리 덕분에 업데이트 로직이 단순해진다. 다만 생성된 SQL을 믿고 넘기면 안 되고, 로그와 실행 계획으로 성능을 확인해야 한다. 목차 흐름으로 보기 왜 JPA가 필요한가 JPA와 Spring Data JPA가 줄여주는 반복 엔티티와 영속성 컨텍스트는 어떻게 움직이나 Spring Boot에서 먼저 켜야 할 최소 설정 메서드 이름 쿼리와 @Query를 고르는 기준 예제 쿼리와 결과를 먼저 읽어야 한다 생성된 SQL과 실행 계획은 반드시 확인해야 한다 인덱스와 성능 포인트를 같이 봐야 하는 이유 JPA를 어디까지 맡기고 어디서 SQL을 더 직접 봐야 하나 JPA를 쓸 때 자주 틀리는 지점 흐름으로 보기 JPA를 쓰는 핵심은 단순히 코드를 덜 쓰는 것이 아닙니다. 엔티티로 테이블 구조를 표현하고, 리포지토리로 조회 의도를 선언하고, 영속성 컨텍스트와 트랜잭션으로 변경을 반영하는 흐름을 일관되게 가져가는 데 있습니다. 그래서 JPA를 제대로 쓰려면 “코드가 짧아졌다”보다 “어떤 SQL이 언제 실행되는가”를 더 먼저 봐야 합니다. 왜 JPA가 필요한가 JDBC나 DAO 중심으로 데이터 접근 계층을 직접 쌓으면 처음에는 명확해 보입니다. 하지만 기능이 조금만 늘어나도 SQL 문자열, 파라미터 바인딩, 결과 매핑, 예외 처리, 트랜잭션 경계가 여러 곳에 반복됩니다. 조회 조건이 늘어나면 DAO 메서드는 금방 비대해지고, 서비스 계층은 비즈니스 규칙보다 데이터 접근 세부사항을 더 많이 신경 쓰게 됩니다. 예를 들어 주문 목록 하나만 생각해도 금방 복잡해집니다. 상태별 조회, 기간 조건, 정렬, 페이지네이션, 총 개수 조회,...