코드 땜장이

단위 테스트와 통합 테스트, 무엇을 어디까지 검증해야 할까 빠른 답 단위 테스트는 한 함수, 클래스, 정책 객체처럼 작은 책임을 빠르게 검증하고 외부 의존성은 보통 테스트 대역으로 분리한다. 통합 테스트는 DB, HTTP API, 파일 시스템, 메시지 브로커처럼 실제 연결 지점이 함께 동작하는지 확인한다. 슬라이스 테스트는 웹 계층이나 저장소 계층처럼 일부 구성만 로드해 단위 테스트보다 현실적이고 전체 통합 테스트보다 가볍게 검증한다. CI에서는 빠른 테스트를 먼저 실행하고, 통합·E2E·스모크 테스트는 변경 위험과 배포 단계에 맞춰 품질 게이트로 나누는 편이 관리하기 쉽다. 목차 한눈에 비교 왜 경계가 헷갈리기 쉬운가 선택 기준 매트릭스 테스트 범위 정하는 흐름 스택 중립 예시로 보는 테스트 경계 슬라이스 테스트를 둘 위치 CI 품질 게이트 나누기 실패 출력으로 원인 좁히기 테스트 대역과 실제 환경의 균형 운영 검증까지 이어지는 테스트 전략 한눈에 비교 검증 범위 단위 테스트는 작은 책임 단위, 슬라이스 테스트는 특정 계층, 통합 테스트는 여러 구성 요소의 연결을 본다. 실행 비용 단위 테스트는 빠르고 자주 돌리기 좋으며, 통합 테스트는 환경 준비와 I/O 때문에 상대적으로 느리다. 실패 원인 단위 테스트는 실패 지점이 좁고, 통합 테스트는 설정, 데이터, 네트워크, 트랜잭션까지 원인 후보가 넓어진다. 의존성 처리 단위 테스트는 대역 객체를 자주 쓰고, 통합 테스트는 실제 DB나 컨테이너, 테스트용 외부 API 서버를 사용한다. 신뢰도 성격 단위 테스트는 로직 회귀를 빠르게 잡고, 통합 테스트는 배포 후 연결 문제를 줄이는 데 도움이 된다. 왜 경계가 헷갈리기 쉬운가 테스트 이름은 단순하지만 실제 코드에서는 경계가 자주 흐려진다. 예를 들어 OrderService 하나만 테스트한다고 해도 그 안에서 재고 조회, 결제 요청, 주문 저장이 모두 일어나면 클래스 하나를 테스트한다는 사실만으로 단위 테스트라고 부르기 어렵다. 테스트가 묻는 질문...

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이 되느냐”만 보면 작아 보인다. 하지...

로그와 메트릭의 차이: 운영 중인 서비스를 어떻게 관찰할 것인가 빠른 답 로그는 개별 사건의 맥락을 남기고, 메트릭은 시간에 따른 상태 변화를 숫자로 요약한다. 이상 징후 감지와 알림은 메트릭이 빠르고, 원인 분석은 로그가 더 깊은 단서를 준다. System.out.println 만으로는 로그 레벨, 포맷, 필터링, 수집 연동, 마스킹을 안정적으로 관리하기 어렵다. 운영 품질은 로그와 메트릭을 따로 도입했는지가 아니라, 탐지부터 분석과 재발 방지까지 이어지는지로 판단하는 편이 좋다. 목차 한눈에 비교 시간 흐름으로 이해하기 왜 운영 품질의 기준선인가 로그와 메트릭이 헷갈리는 이유 스택 중립 기준선 장애 대응에서 함께 쓰는 방식 설정 예시 운영 확인 예시 실제로 막히는 지점 테스트와 품질 게이트 운영 점검 순서 한눈에 비교 목적 로그는 “무슨 일이 있었는가”를 설명하고, 메트릭은 “상태가 얼마나 변했는가”를 보여준다. 단위 로그는 요청, 예외, 결제 실패 같은 개별 이벤트 단위이고, 메트릭은 요청 수, 오류율, 지연 시간 같은 집계 단위다. 형태 로그는 문자열이나 구조화된 이벤트 기록이고, 메트릭은 이름, 숫자 값, 라벨, 시계열로 구성된다. 강점 로그는 요청 맥락과 예외 추적에 유리하고, 메트릭은 추세 파악, 임계치 알림, 대시보드 구성에 유리하다. 비용 로그는 상세할수록 저장량과 검색 비용이 커지고, 메트릭은 라벨 조합이 늘어날수록 시계열 수가 급격히 증가한다. 사용 시점 메트릭은 “지금 이상한가”를 먼저 알려주고, 로그는 “왜 이상한가”를 좁힐 때 쓰인다. 시간 흐름으로 이해하기 첫 요청 발생 애플리케이션은 요청 ID, 경로, 사용자 범주, 처리 시작 시각 같은 로그 맥락을 만든다. → 요청 처리 누적 성공 수, 실패 수, 응답 시간, 큐 적체량 같은 값이 메트릭으로 쌓인다. → 관찰 윈도우 계산 모니터링 시스템은 1분, 5분 같은 구간으로 오류율, 평균, 백분위 지연 시간을 계산한다. → 임계치 도달 오류율이나 지연 시간이 기준을 넘으...

application.yml 빠른 답 운영 환경에서는 보통 none 또는 validate만 두고 스키마 변경은 Flyway나 Liquibase로 관리합니다. update는 개발 속도를 높이지만 운영 DB에는 예측하기 어려운 변경을 만들 수 있어 신중해야 합니다. create와 create-drop은 기존 데이터를 지우므로 로컬 실험이나 테스트 환경 전용으로 보는 편이 안전합니다. 프로필별 설정을 분리하지 않으면 개발용 ddl-auto가 운영까지 들어가는 실수가 생길 수 있습니다. spring: jpa: open-in-view: false hibernate: ddl-auto: validate 목차 application-local.yml application-test.yml application-prod.yml 흔한 실수 application-local.yml spring: jpa: hibernate: ddl-auto: update application-test.yml spring: jpa: hibernate: ddl-auto: create-drop application-prod.yml spring: jpa: hibernate: ddl-auto: validate 이렇게 두면 프로필이 잘못 붙더라도 기본값이 최소한 안전한 쪽에 가깝습니다. 팀에 따라 운영은 `none`, 스테이징은 `validate`로 더 분리하기도 합니다. 중요한 것은 “명시적으로 적는다”는 점입니다. 기본값 추정에 기대면 임베디드 DB, Flyway 감지 여부, 테스트 환경 구성에 따라 생각과 다른 동작이 나올 수 있습니다. 엔티티 변경이 실제로 어떻게 보이는지는 짧은 예제가 가장 빠릅니다. java @Entity @Table(name = "member") public class Member { @Id @GeneratedValue(strategy = Ge...

JPA와 Hibernate, Spring Data JPA를 헷갈리지 않게 구분하는 방법 빠른 답 JPA는 표준 명세이고, Hibernate는 그 명세를 구현하는 ORM 엔진이다. Spring Data JPA는 JPA 위에 Repository 추상화를 얹어 반복 코드를 줄여준다. 현업의 흔한 조합은 Spring Data JPA + Hibernate이지만, 세 개는 같은 계층의 기술이 아니다. 성능이나 쿼리 문제를 볼 때는 Repository 이름보다 결국 Hibernate가 만든 SQL과 JPA 설정을 함께 봐야 한다. 초안을 발행용 본문으로 재구성하되, 버전 민감한 부분은 공식 문서 기준으로 먼저 확인하겠습니다. 이후 비교 축, 실행 흐름, 현재 기준 migration 포인트가 초반부터 보이도록 문단과 예시를 정리하겠습니다.# JPA와 Hibernate, Spring Data JPA를 헷갈리지 않게 구분하는 방법 목차 한눈에 비교 흐름으로 보기 왜 셋이 늘 한 묶음처럼 보일까 JPA는 명세이고, Hibernate는 구현체이고, Spring Data JPA는 추상화다 코드로 보는 역할 차이 실무에서는 어떤 조합으로 쓰게 될까 지금 기준에서 주의할 버전 포인트 Spring Data JPA를 써도 Hibernate를 알아야 하는 순간 언제 무엇을 기준으로 선택하면 될까 한눈에 비교 JPA: 무엇을 표준화하나가 핵심이다. EntityManager , 엔티티 매핑, JPQL, 영속성 컨텍스트, 엔티티 생명주기 같은 공통 규칙을 정의한다. Hibernate: 어떻게 실행하나가 핵심이다. JPA 규약을 받아 SQL을 만들고, DB dialect를 적용하고, 캐시와 배치, flush, proxy, lazy loading을 처리한다. Spring Data JPA: 어떻게 덜 쓰고 빨리 만들까가 핵심이다. JpaRepository , 메서드 이름 기반 쿼리, @Query , 페이지네이션, 정렬, Specification 같은 생산성 기능을 제공한다. ...