Happy Collin

MyBatis @Param 애노테이션은 언제 필요한가?

MyBatis DAO 인터페이스에서 @Param을 사용하는 경우와 그렇지 않은 경우가 있어서 차이점을 정리한다. 결론 : 파라미터가 2개 이상일 때 @Param이 필요하다. 이유 MyBatis는 파라미터가 1개인 경우 XML mapper에서 어떤 이름으로든 참조할 수 있다.하지만 파라미터가 2개 이상이면 어떤 값이 어떤 이름에 해당하는지 알 수 없다.@Param을 붙이지 않으면 MyBatis가 내부적으로 param1, param2, ... 로 처리하기 때문에,XML에서 #{aaaa}, #{bbbb} 같은 이름으로 참조하면 런타임 오류가 발생한다. 예시 // 파라미터 1개 → @Param 불필요List getCardList(Card card); // 파라미터 2개 → @Param 필수List getCar..

MySQL에서 (name, regdate)와 같은 복합 기본키(Composite Primary Key)를 사용하는 것은 특정 비즈니스 요구사항에서는 유용할 수 있지만, 시스템이 커질수록 여러 잠재적 위험 요소와 성능 저하를 유발할 수 있습니다.왜 복합 PK를 지양하고 대체로 자동 증가하는 정수형 ID(Auto-Increment ID)를 권장하는지, 장단점과 위험 요소를 나누어 명확히 정리해 드리겠습니다.1. 잠재적 위험 요소 및 지양해야 하는 배경① 인덱스 비대화와 메모리 낭비 (가장 큰 이유)MySQL의 InnoDB 스토리지 엔진은 클러스터형 인덱스(Clustered Index) 구조를 사용합니다. 즉, 실제 데이터 레코드가 PK 순서대로 정렬되어 저장됩니다.더 큰 문제는 두 번째 인덱스(Seconda..

자바에서 객체를 생성하고 데이터를 다루는 방식은 크게 Builder 패턴과 **Record(레코드)**로 나뉩니다. 두 기능은 목적과 사용 사례가 다르기 때문에 상황에 맞춰 선택하는 것이 중요합니다.1. Builder 패턴 (Lombok @Builder)Builder 패턴은 복잡한 객체를 안전하고 편리하게 생성하기 위해 사용됩니다. 주로 계층이 있고 필드가 많은 클래스에 적합합니다.특징가독성: 필드가 많을 때 어떤 값이 어떤 필드에 들어가는지 명확히 알 수 있습니다.선택적 매개변수: 모든 필드를 채울 필요 없이 필요한 값만 세팅할 수 있습니다.불변성 유지: 객체 생성 후 값을 바꿀 수 없도록(Setter 없음) 설계하기 좋습니다.코드 예시 Java@Builder@Getterpublic class User..

Spring Boot에서 클라이언트의 요청이 비즈니스 로직(Service)에 도달하기까지의 흐름은 계층별로 명확히 구분됩니다. 요청은 외곽(Servlet Container)에서 시작하여 중심(AOP)으로 들어가는 구조입니다.1. 요청 처리 흐름 도식화클라이언트의 요청이 들어오고 나가는 전체적인 흐름은 아래와 같습니다.순서구성 요소소속 레이어특징1Filter (필터)Web ContainerDispatcherServlet 도달 전/후 동작2Interceptor (인터셉터)Spring ContextDispatcherServlet과 Controller 사이 동작3AOP (Aspect)Spring ContextProxy를 통해 비즈니스 로직 전/후 동작2. 단계별 상세 비교 표각 기술이 실행되는 시점과 주요 목적..

산소 미포함(Oxygen Not Included)에서 씨근풀 냉각 효율산소 미포함에서 초중반 온도 관리는 생존에 직결되는 중요한 요소입니다.그중 **씨근풀(Weezewort)**은 전력 없이 작동하는 식물형 냉각 장치로, 많은 플레이어들이 애용합니다.그런데 왜 씨근풀은 수소 환경에서 가장 효율적일까요? 그 이유는 바로 **비열(Specific Heat Capacity)**에 있습니다.🔧 씨근풀의 냉각 메커니즘씨근풀은 아래 칸의 기체 1000g을 흡입한 뒤,그 기체를 정확히 5℃ 낮춰서 위 칸으로 배출합니다.따라서 어떤 기체를 흡입하느냐에 따라 **냉각되는 열량(Heat Deletion)**이 달라집니다.🌡️ 비열(Specific Heat Capacity)란?비열은 물질 1kg의 온도를 1℃ 올리는 데..

JPA를 사용하다 보면 로그에 실제 전달한 리스트는 152개인데, SQL 바인딩 시점에는 255개(혹은 256개)까지 늘어나 마지막 값이 반복해서 들어가는 현상을 볼 수 있습니다. 이는 `type.descriptor.sql.BasicBinder`가 수행하는 IN Clause Parameter Padding 때문입니다. 이 현상의 원인과 해결 방법을 정리합니다. --- 1. 왜 255개까지 늘어나는 걸까? (원인) Hibernate는 성능 최적화를 위해 IN 절에 전달된 인자의 개수를 2의 거듭제곱(2, 4, 8, 16 ... 256) 단위로 맞추는 패딩 전략을 사용합니다. * 이유: DB의 Execution Plan(실행 계획) 재사용성 때문입니다. * 상세: 인자 개수가 152개일 때와 153개일 때..

@Transactional(rollbackFor = Exception.class)🔹 기본 동작@Transactional은 기본적으로 RuntimeException과 Error가 발생하면 롤백합니다.즉, 체크 예외(Exception의 하위 클래스지만 RuntimeException이 아닌 것들)는 기본적으로 롤백 대상이 아닙니다.🔹 rollbackFor 옵션의 의미rollbackFor = Exception.class라고 지정하면, 체크 예외까지 포함해서 모든 예외가 발생하면 롤백하도록 강제합니다.기본값이 "모든 예외 롤백"이 아니라 "런타임 예외만 롤백"이기 때문에, 위처럼 명시적으로 지정하는 경우가 많습니다.🔹 왜 이렇게 쓰는가?비즈니스 로직에서 IOException, SQLException 같은 체..

📝 면접 질문"Java 웹 애플리케이션에서 대규모 트래픽을 효율적으로 처리하기 위해 어떤 아키텍처적 접근과 기술을 사용할 수 있나요?"💡 모범 답변스케일 아웃(Scale-out) 구조단일 서버 성능 향상보다 로드 밸런싱을 통한 서버 확장 방식을 선호합니다.Nginx, HAProxy 같은 로드 밸런서를 활용해 트래픽을 분산합니다.비동기 처리와 메시지 큐대량 요청을 동기적으로 처리하면 병목이 발생합니다.Kafka, RabbitMQ 같은 메시지 큐를 사용해 비동기 이벤트 기반 아키텍처를 구축합니다.캐싱 전략DB 부하를 줄이기 위해 Redis, Memcached 같은 인메모리 캐시를 적극 활용합니다.정적 리소스는 CDN을 통해 제공하여 서버 부담을 줄입니다.데이터베이스 최적화읽기/쓰기 분리(Replicati..

SLOW SQL 튜닝 시 가장 중요한 고려사항은 실행계획 분석, 인덱스 활용, SELECT 범위 최소화입니다. 이 세 가지가 성능 개선의 핵심이며, 그 외에도 조인 방식, 정렬/집계 처리, 통계 정보 최신화 등이 중요합니다.🚀 SLOW SQL 튜닝 핵심 고려사항 (중요도 순)1️⃣ 실행계획(Execution Plan) 분석가장 중요한 첫 단계: DB가 쿼리를 어떻게 수행하는지 확인확인 항목: 인덱스 사용 여부, 테이블 스캔 방식, 조인 순서, 예상 비용(Cost)도구: EXPLAIN, AUTOTRACE, SQL PLAN 등2️⃣ 인덱스 활용 여부WHERE 절, JOIN 조건에 인덱스 컬럼 사용 여부 확인주의: 함수 사용, 형 변환, OR 조건 등은 인덱스를 무효화할 수 있음대응: 인덱스 설계 최적화, ..

자바에서 Call by Value(값에 의한 호출)와 Call by Reference(참조에 의한 호출)의 차이는 '무엇이 전달되는가'에 있습니다. 자바는 기본적으로 Call by Value만 지원합니다.🔍 핵심 차이 요약항목 Call by Value (값에 의한 호출) Call by Reference (참조에 의한 호출)전달 방식변수의 값을 복사해서 전달변수의 *주소(참조)*를 전달원본 데이터 영향메서드 내에서 변경해도 원본에 영향 없음메서드 내에서 변경 시 원본 데이터도 변경됨자바에서의 지원✅ 기본형(primitive type)에 적용됨❌ 자바는 엄밀히 말해 Call by Reference를 지원하지 않음객체 전달 시객체의 참조값이 복사되어 전달됨 → 객체 내부는 변경 가능참조 자체를 바꾸는 건 불..