JSJ_Study

배치(Batch)란?배치는 대량의 데이터를 한 번에 일괄 처리하는 방식을 말한다.실시간으로 요청이 들어올 때마다 처리하는 게 아니라, 데이터를 모아뒀다가 한꺼번에 처리하는 것이다.대표적인 사용 사례는 아래와 같다.일매출 집계 — 하루치 거래 데이터를 새벽에 한 번에 집계구독 메일 발송 — 정해진 시간에 구독자 전체에게 메일 일괄 전송데이터 백업 — 트래픽이 적은 새벽 시간대에 DB 백업Batch vs Scheduler여기서 헷갈릴 수 있는 게 Batch와 Scheduler의 차이다.구분 역할Batch대량 데이터를 일괄 처리하는 것Scheduler정해진 시간에 작업을 실행시키는 것배치는 "대량 처리"를 의미하는 것이지, 주기적으로 실행된다는 뜻이 아니다.Spring Batch는 Quartz 같은 스케줄러와..

팀장을 맡으면서이번 프로젝트는 초급 때와 결이 달랐다. 기능 구현 자체는 어렵지 않았지만 작업 순서, 초기 설정이 훨씬 힘들었다.팀에서 기능 구현 후 테스트 코드를 작성하기로 합의했는데, 이 결정을 지키지 않는 팀원이 생기면서 균열이 시작됐다. 테스트 코드가 없으면 통합 테스트 일정이 밀리게 되고, 중간 작업 시간이 붕 뜨게 되면서 불만을 표출하셨다 ㅠㅠ 그 여파로 팀 분위기가 눈에 띄게 가라앉았다. 한 팀원은 이후 프로젝트 참여 자체에 소극적이 되어버렸다.팀장으로서 이걸 직접 꺼내서 풀어야 할지, 아니면 내버려두고 프로젝트를 끝내야 할지 판단이 서지 않았다. 강사님은 "이걸 터뜨리고 갈지 말지를 팀장이 결정해야 한다" 고 하셨는데, 그 말이 생각보다 어렵게 다가왔었다 ㅠㅠ기술적으로 아쉬웠던 것들기능이..

1. Amazon S3란?S3(Simple Storage Service)는 AWS가 제공하는 객체 스토리지 서비스다.파일을 버킷(Bucket) 단위로 관리하고, 개별 파일은 객체(Object) 형태로 저장된다.핵심 수치객체 하나의 최대 크기는 5TB이며, 저장 가능한 객체 수에는 제한이 없다.내구성은 99.999999999% (11 9s) — 3개의 가용 영역(AZ)에 중복 저장하기 때문이다.주요 특징항목 설명무제한 저장 용량페타바이트(PB) 이상도 문제 없음높은 내구성11 9's, 3개 AZ 중복 저장다양한 접근 방식HTTP(S), CLI, SDK, API정적 웹 호스팅HTML 정적 웹사이트 직접 서빙 가능자동 백업/복원버전 관리 및 수명 주기 정책 지원버킷 이름 규칙버킷 이름은 전 세계에서 고유해야 ..

1. 레지스트리 / 리포지터리 / 이미지 태그도커 레지스트리란?도커 플랫폼은 소프트웨어 배포 기능을 내장하고 있어서, 로컬에 이미지가 없어도 자동으로 다운로드해준다. 이때 이미지가 저장되는 서버를 레지스트리(Registry) 라고 한다.도커 허브(Docker Hub) 는 도커 레지스트리 중 가장 유명한 레지스트리로, 수십만 종 이상의 이미지를 제공하며 도커 엔진에 기본으로 설정되어 있다.도커 이미지 참조 구조docker.io / diamol / golang : latest │ │ │ │ 레지스트리 계정이름 리포지터리 태그구성요소 설명 ..

들어가며Spring으로 목록 API를 만들다 보면 Pageable, Page, Slice를 자연스럽게 쓰게 된다. 근데 막상 "이게 내부적으로 어떻게 동작해?"라고 물어보면 설명을 잘 못했었다. 이 글에서는 페이징이 왜 필요한지부터 OFFSET 방식의 한계, 커서 기반 페이징의 원리까지 차근차근 정리해보자!왜 페이징이 필요할까?SELECT * FROM users;데이터가 100만 건이면 이 쿼리 한 방에 전부 가져온다. 메모리가 터지고 응답도 한없이 느려진다. 잘라서 가져오는 것이 페이징이다.OFFSET 기반 페이징원리DB에서 페이징을 구현하는 가장 기본적인 방법은 LIMIT과 OFFSET을 쓰는 것이다.SELECT * FROM users ORDER BY id LIMIT 10 OFFSET 0; -- ..

문제 상황BaseEntity에서 @Setter를 제거했더니 MapStruct Mapper에서 컴파일 오류가 발생했다.error: Property "id" has no write accessor in User for target name "user.id". ReadStatus toEntity(ReadStatusCreateRequest request);error: Property "id" has no write accessor in Channel for target name "channel.id". ReadStatus toEntity(ReadStatusCreateRequest request);처음엔 단순히 Setter가 없어서 생긴 오류라고 생각했다.ignore = true를 붙이거나 Setter..

1. Dirty Checking이란영속성 컨텍스트는 엔티티를 처음 조회하거나 persist할 때 해당 시점의 스냅샷을 내부에 보관합니다. 트랜잭션 커밋 시점에 flush가 호출되면서 현재 엔티티 상태와 스냅샷을 필드 단위로 비교해, 변경이 있으면 자동으로 UPDATE SQL을 생성합니다. 이것이 Dirty Checking입니다.트랜잭션 커밋 ↓entity manager의 flush 자동 호출 ↓dirty checking (현재 상태 vs 스냅샷 비교) ↓변경 감지 → UPDATE SQL 생성 → DB 전송 ↓JDBC commit (영구 반영)따라서 같은 트랜잭션 내에서 엔티티를 조회하고 수정하면, save() 호출 없이도 트랜잭션 커밋 시 UPDATE가 자동으로 발생합니다.@Tran..

1. JPA vs Spring Data JPA둘을 혼용해서 쓰는 경우가 많지만 역할이 다릅니다.**JPA (Java Persistence API)**는 자바 ORM 표준 명세입니다. 인터페이스만 정의하고, 실제 구현체는 Hibernate가 담당합니다.Spring Data JPA는 JPA 위에 얹힌 추상화 레이어입니다. JpaRepository를 상속하는 것만으로 findById(), save(), delete() 같은 기본 CRUD를 자동으로 제공합니다.Spring Data JPA ↓ JPA (인터페이스) ↓ Hibernate (구현체) ↓ JDBC ↓ DB즉, 우리가 userRepository.save(user)를 호출하면 내부적으로 Hibernat..

협업 시 브랜치 동기화, merge, rebase 어떤 순서로 해야할지 헷갈려 정리해보았다!1. 상황 설정공용 브랜치는 develop나는 feature/login 브랜치에서 작업 중작업하는 동안 팀원이 feature/payment를 develop에 먼저 머지한 상태develop: A --- B --- C --- D (팀원 커밋) \feature/login: X --- Y --- Z (내 커밋)이 상태에서 PR을 올리면 develop과 feature/login 사이에 격차가 생겨 컨플릿이 발생할 수 있습니다.2. 전체 흐름 한눈에 보기① local develop pull ↓② feature rebase develop ↓③ f..

1. Merge Conflict란?Git은 두 브랜치를 병합할 때 변경 사항을 자동으로 합친다.그러나 같은 파일의 같은 라인을 두 브랜치가 서로 다르게 수정했다면, Git은 어느 쪽이 맞는지 판단할 수 없다. 이 상태가 바로 Merge Conflict이다.참고 — Git이 자동으로 합칠 수 있는 경우(서로 다른 파일 수정, 같은 파일의 다른 라인 수정)는 컨플릿 없이 머지됩니다. 컨플릿은 정말로 충돌이 일어났을 때만 발생한다.2. 발생 원인Merge Conflict의 근본 원인은 두 브랜치가 서로의 변경 사항을 모르는 채로 같은 라인을 수정했을 때다. 반대로, 한 브랜치가 다른 브랜치의 커밋 이력을 포함하고 있다면 Git은 충돌 없이 머지할 수 있다.시나리오 1 — 동일 파일, 동일 라인 수정가장 흔한 ..