Engineering Note

Native Query로 작성한 코드를 QueryDsl로 리팩토링하는 과정에서 테스트코드를 작성하고 성능 측정하는 상황에서 N+1문제 상황을 발견하여 문제를 해결한 과정을 정리하려고 한다. 문제 상황을 먼저 소개하면 사용자가 주문내역을 조회 하는 코드에서 여러 테이블을 조인하고 있었고 이 과정에서 쿼리가 예상보다 많이 요청되는 JPA의 N+1문제가 발생해서 코드를 개선한 과정을 정리하였습니다. N+1문제를 통한 현재의 직접적인 성능의 문제는 없었지만, 데이터가 늘어나면 결국 Disk I/O로 인한 성능 저하 문제가 발생할 것으로 예상하여 코드를 개선하기로 결정하였습니다. 목차1. 문제 상황2. N+1 문제 발생 원인3. 1차 해결 시도(실패)4. 최종 해결 방법5. 성능 테스트 1. 문제 상황1.1 요구..

상황 설명OrderDto주문을 위해 상품 id와 상품 주문 수량 count값을 담는 DTO 클래스@Getter @Setter@AllArgsConstructor@NoArgsConstructorpublic class OrderDto { @NotNull(message = "상품 아이디는 필수 입력 값입니다.") private Long itemId; @Min(value = 1 ,message = "최소 주문 수량은 1개입니다.") @Max(value = 999, message = "최대 주문 수량은 999개입니다.") private int count;} OrderItem Entity- Order Entity와 Item Entity의 릴레이션 테이블이면서 주문 상품 정보를 담는 Ent..

들어가며장바구니에 담긴 OrderItem을 주문으로 처리하는 코드를 리팩토링하면서 겪은 여정을 공유합니다. 단순히 코드를 깔끔하게 만들려던 시도가 N+1 문제 발견과 성능 개선으로 이어진 과정을 담았습니다. 문제의 시작: forEach의 한계초기 코드는 stream().forEach()를 사용해 주문 정보를 처리했습니다. 문제의 시작: forEach의 한계초기 코드는 stream().forEach()를 사용해 주문 정보를 처리했습니다.public Long orders(List orderDtoList, String email) { // 1. 회원 조회 (1st Query) Member member = memberRepository.findByEmail(email); ..

이 글은 게시판의 댓글 좋아요 기능의 DB를 설계하면서 UNIQUE 제약조건을 알게 된 과정을 정리한 글입니다. 요구사항댓글 좋아요 기능에 필요한 요구사항은 다음과 같았습니다.로그인한 유저만 좋아요 가능중복 좋아요 방지 (한 댓글에 한 번만 좋아요 가능)특정 댓글의 좋아요 수 조회특정 유저의 좋아요 목록 조회 테이블 설계 과정기존 테이블 구조Member (회원)Board (게시글)Comment (댓글)고민: 좋아요 데이터를 어디에 저장할까?처음엔 Comment 테이블에 like_count 같은 컬럼만 추가하면 되지 않을까 생각했습니다.하지만 문제가 있었습니다:누가 좋아요를 눌렀는지 알 수 없음로그인 후 "내가 좋아요 누른 댓글"을 표시할 수 없음좋아요 취소 기능을 만들 수 없음 해결: Like 테이블 분..

이커머스 쇼핑몰 서비스 프로젝트를 하면서 도메인 모델을 설계한 경험을 공유합니다. 단순히 "이렇게 만들었다"가 아닌, 왜 이런 선택을 했는지에 초점을 맞춰 설명합니다. 전체 도메인 모델 개요 Member (회원) ↓ 1:1Cart (장바구니) ← N:1 → CartItem (장바구니상품) → N:1 → Item (상품) Member (회원) ↓ 1:NOrder (주문) ← N:1 → OrderItem (주문상품) → N:1 → Item (상품) 핵심 엔티티:Member: 회원 정보Item: 상품 정보Cart / CartItem: 장바구니 (주문 전 임시 보관)Order / OrderItem: 주문 (구매 확정) 1. Item 엔티티: 기본 설계 결정설계 의도상품은 쇼핑몰의 핵심 엔티티로, 독..

Spring Boot 프로젝트에서 수동 배포의 번거로움을 해결하고 개발 생산성을 높이기 위한 완전 자동화 CI/CD 파이프라인을 구축하는 실용적 가이드이자 개발 과정에서 실제 적용한 방법을 기록하고 공유하기 위한 글입니다. 수동 배포의 한계점반복적인 수작업: SSH 접속 → 코드 pull → 빌드 → 실행의 반복배포 시간 소요: 매번 7분 이상의 수동 작업 필요휴먼 에러: 수동 과정에서 발생하는 실수개발 집중도 저하: 배포 과정에 신경 써야 하는 부담 목표 설정PR 병합 시 자동 배포 실현배포 시간 대폭 단축100% 자동화로 휴먼 에러 제거개발자가 기능 개발에만 집중할 수 있는 환경 구축 전체 아키텍처 플로우:개발자가 PR 생성 및 병합GitHub Actions가 자동 빌드 시작Docker 이미지 생..

프로젝트를 하면서 발생한 에러를 중심으로 JavaScript(이하 JS) Stack Trace 읽는 법을 정리하려고 한다. JS뿐만 아니라 모든 언어에도 적용 가능하다. 발생한 에러Uncaught TypeError: Cannot read properties of undefined (reading 'message') at Object.error (cart:163:50) at c (jquery-3.5.1.min.js:2:28294) at Object.fireWith [as rejectWith] (jquery-3.5.1.min.js:2:29039) at l (jquery-3.5.1.min.js:2:79825) at XMLHttpRequest. (jquery-3.5.1.min.js:2..

이어 지는 글구체적인 사례로 보는 JS 에러 메세지 읽는 법(https://techbook11.tistory.com/713)장바구니 주문 기능을 개발하던 중 발생한 흔한 실수와 그 해결 과정을 공유합니다. 프론트엔드와 백엔드 간의 데이터 타입 불일치로 인해 발생한 문제로, 많은 개발자가 겪을 수 있는 사례입니다. 문제 상황사용자가 장바구니에서 주문 버튼을 클릭했을 때 다음과 같은 현상이 발생했습니다. 사용자 관점의 문제:- 주문버튼을 눌렀지만 아무런 반응이 없음- 에러메세지가 표시되지 않아 무엇이 잘못되었는지 알 수 없음 시스템 관점의 문제:- HTTP 400 Bad Request 응답- Javascript TypeError 발생 에러 분석1단계 : 프론트엔드 에러 확인브라우저 개발자 도구에서 다음 에러..