All

🤖 Claude Code란? Claude Code는 Anthropic이 공식으로 제공하는 CLI(Command Line Interface) 기반의 AI 코딩 어시스턴트다. 터미널에서 직접 실행하여 코드베이스를 이해하고, 파일을 편집하고, 명령어를 실행하며, 복잡한 소프트웨어 엔지니어링 작업을 자연어로 수행할 수 있다. 기존의 채팅 기반 AI 도우미와 달리, Claude Code는 로컬 환경에서 직접 동작하며 파일 시스템, Git, 쉘 명령어 등에 접근할 수 있어 실질적인 개발 작업을 수행할 수 있다는 점이 가장 큰 차별점이다. ⚡ 주요 특징 1. 터미널 네이티브 IDE 플러그인이 아닌 터미널에서 직접 실행되므로, 어떤 개발 환경에서든 사용할 수 있다. VS Code, JetBrains, Vim 등 에디터에 종속되지 않는다. 2. 코드베이스 전체 이해 프로젝트의 파일 구조를 탐색하고, 코드를 읽고, 의존성 관계를 파악한다. 단순히 열려 있는 파일만 보는 것이 아니라 프로젝트 전체 컨

Kubernetes + Jenkins + ArgoCD로 검색엔진을 포함한 블로그 CI/CD 파이프라인 구축기 지금 이 글을 보고 있는 이 블로그는 온프레미스 Kubernetes 클러스터 위에서 돌아가고 있다. 사실 블로그 하나 띄우는 데 Kubernetes까지 필요하냐고 물으면, 솔직히 필요 없다. Vercel에 올리면 5분이면 끝난다. 근데 나는 이 블로그를 인프라 놀이터로 쓰고 싶었다. 코드를 push하면 이미지 빌드부터 배포, 검색 색인 갱신까지 자동으로 돌아가는 파이프라인을 직접 만들어보고 싶었고, 실제로 만들었다. 이 글에서는 이 파이프라인이 어떤 아키텍처로 구성되어 있고, 각 설계 결정에 어떤 이유가 있었는지를 실제 매니페스트와 함께 다뤄보려 한다. 전체 아키텍처 먼저 전체 그림을 보자. 핵심은 두 개의 Git 저장소가 역할을 분리한다는 것이다: - blog-new: 애플리케이션 소스코드. Next.js 앱, 마크다운 콘텐츠, Jenkinsfile, ES 색인 스크립트가

엘라스틱서치 데이터 핸들링

카프카 설치하기 🔍 카프카 스터디 시리즈 - Chap1. 카프카 시작하기 - Chap2. 카프카 설정하기 ⭐️ 이번 2장의 제목은 '카프카 설치하기' 이지만, 설치 방법에 대해서는 따로 다룰 가치를 느끼지 못하겠으므로 카프카 컨트롤러 노드, 메타데이터 관리, 브로커 및 컨슈머 설정 등에 대해 다루도록 하겠습니다. Zookeeper vs KRaft 앞서 에서는 Kafka가 Zookeeper 방식과 KRaft 방식으로 동작한다고 KIP-500에 대한 이야기를 포함하여 설명하였습니다. 이번 절에서는 Zookeeper, KRaft가 필요한 이유와 왜 카프카 커뮤니티가 KRaft라는 대안을 선택하게 되었는지에 대해 간략하게 알아보고자 합니다. Kafka 메타데이터 관리의 중요성 Kafka는 단순한 메시지 큐가 아닙니다. Kafka의 본질은 분산 로그 시스템이고, 분산 시스템에서 사장 어려운 문제는 데이터가 아니라 상태(state)입니다. Kafka에서 말하는 메타데이터는 source o

카프카 시작하기 🔍 카프카 스터디 시리즈 - Chap1. 카프카 시작하기 - Chap2. 카프카 설정하기 개요 카프카에 대해 제대로 공부해보고자 스터디를 시작했습니다. 이번 포스팅 시리즈에서는 서적 "카프카 핵심 가이드" 를 완독하고 카프카의 구조 및 생태계에 대한 전반적인 학습 및 각 기능의 POC를 실제로 수행하는 것을 목표로 합니다. 책의 서문에서, 유명한 과학자인 닐 디그래스 타이슨의 말을 인용합니다. "과학자들이 서로 동의하지 않는 상황이 벌어진다면, 그것은 데이터가 불충분하기 때문이다. 그리고 어떠한 데이터를 얻을 것인지를 합의하고 데이터를 얻을 수 있다면 문제는 해결된다. 내가 올든 상대방이 옳든, 아니면 둘 다 틀리든 말이다. 그제서야 우리는 그 다음으로 진행해 갈 수 있다." - 닐 디그래스 타이슨 모든 기업은 데이터로 움직이며, 우리는 이런 데이터를 얻고, 분석하고, 가공하여 단순한 데이터 이상의 것을 결과물로 산출해야만 합니다. 데이터의 모든 부분은 의미가 있

Spring Batch 성능 개선기 - N+1 문제 1. 서론 본 문서에서 다루는 배치 애플리케이션(추천 전처리 시스템)은 단순한 통계 집계가 아닌, 실제 서비스에서 사용자의 시청 이력에 기반한 개인화 푸시 알림을 빠르게 발송하기 위한 전처리 역할을 합니다. 서비스 입장에서는 수십만 명의 사용자에게 5분 이내로 추천 알림을 보내야 하고, 알림을 받은 사용자가 앱을 열었을 때 곧바로 추천 콘텐츠를 확인할 수 있어야 합니다. 하지만 알림 발송 시점마다 추천 로직을 실시간으로 실행한다면 문제가 생깁니다. 데이터베이스 I/O와 연산 비용으로 대규모 트래픽을 감당하기 어렵고, 지연도 불가피해집니다. 운영 환경에서는 마케터나 관리자들이 캠페인을 구성한 후, 특정 시간 예약 발송이나 즉시 발송을 유동적으로 선택합니다. 발송 요청 시점에야 "어느 사용자의 추천 데이터가 필요한지"가 드러나므로, 사전 계산 전략만으로는 부족합니다. 따라서 예약/즉시 여부와 무관하게 언제든 빠른 알림을 위해, 매일 자

JPA saveAll이 느린 이유와 개선 방향 💡 “JPA를 포함한 ORM은 은총알이 될 수 없습니다.” 우리는 종종 ORM을 사용하면 SQL과 트랜잭션의 복잡함에서 해방될 거라 믿습니다. ORM은 데이터를 객체로 다루는 자유를 주지만, 동시에 성능과 제어의 일부를 포기하는 대가를 요구합니다. Hibernate의 은 한 줄의 코드로 모든 걸 해결할 수 있을 것처럼 보입니다. 그러나 그 한 줄 뒤에서 ORM은 수십, 수백 개의 INSERT를 순차적으로 실행하며 JDBC의 배치 성능을 스스로 봉인하고 있습니다. 기존 은 엔티티 단위로 INSERT가 반복되어 네트워크 라운드트립과 엔티티 라이프사이클 오버헤드가 컸습니다. 로 전환하고 드라이버 배치 리라이트를 켜서 한 번의 배치로 밀어 넣으니 60초 → 7.3초로 단축됐습니다. 다대다 테이블을 매핑하는 가상의 TableMapper 엔티티의 예시를 통해 아래에 원인, 설정, 로그 차이, 주의사항을 정리하겠습니다. 배경: 기존 코드 vs 개선

MySQL Prepared Statement란? Prepared Statement의 등장 배경 초창기 SQL 인터페이스에서는 모든 쿼리를 문자열로 조합해 실행했습니다. 예를 들어 같은 방식입니다. 이런 구조는 다음과 같은 문제를 가지고 있었습니다: 1. SQL Injection 취약성 2. 매번 쿼리를 파싱하고 최적화해야 하는 성능 문제 3. 타입 안전성 부족 이러한 문제를 해결하기 위해 Prepared Statement(준비된 쿼리) 개념이 등장했습니다. 미리 SQL 구조를 컴파일하고, 실행 시점에는 파라미터만 바인딩하는 방식입니다. Prepared Statement의 역사와 JDBC/Hibernate와의 관계 MySQL에서 Prepared Statement는 MySQL 4.1 (2004년) 버전부터 도입되었습니다. 이는 MySQL 서버가 처음으로 바이너리 프로토콜(Binary Protocol) 기반의 서버사이드 Prepared Statement를 지원하기 시작한 시점입니다.

🧪 Spring Batch JpaCursorItemReader에 대하여 Spring Batch에서 대량 데이터 처리를 다뤄본 개발자라면 한 번쯤 고민했을 것입니다. “JPA 기반으로 커서(Cursor)처럼 데이터를 읽을 수 있을까?” 오늘은 그 핵심 컴포넌트인 의 역사와, 왜 가 사라졌는지, 그리고 MySQL과 PostgreSQL의 커서 동작 차이까지 실제 실험 데이터와 함께 정리해보겠습니다. 1. JpaCursorItemReader의 역사 1.1 등장 배경 는 Spring Batch 4.3 (2020년경) 에 도입된 컴포넌트입니다. 그 이전까지는 JPA 환경에서 커서 기반 배치를 구현하려면 Hibernate의 를 직접 사용하거나, PagingItemReader를 우회적으로 이용해야 했습니다. 하지만 Paging 방식은 offset 기반 페이징 쿼리 특성상 큰 데이터셋에서는 성능이 급격히 저하되는 문제가 있었습니다. 그래서 Spring 팀은 “JPA 환경에서도 커서

Spring Batch에서 도중 종료시 BATCHJOBEXECUTION의 STATUS가 업데이트 되지 않는 문제 이 문서는 Spring Batch 애플리케이션에서 (안전한 종료)을 시도했음에도 불구하고, 테이블의 가 로 변경되지 않고 상태로 남아 재시작이 불가능한 문제에 대해 실제로 진행했던 트러블슈팅 과정을 중심으로 설명합니다. 1. 문제 상황 발생 배치 Job이 실행 중일 때 을 시도했습니다. 예상대로라면 테이블의 컬럼이 로 변경되어야 하지만, 실제로는 상태로 남아 있었습니다. - 예상 결과: = - 실제 결과: = 이 상태에서 동일한 파라미터로 Job을 재실행하면 Spring Batch는 해당 Job Instance가 이미 실행 중()이라고 판단하여 예외를 발생시키며 실패합니다. 2. 문제 상황 재현 = true로 하여, 애플리케이션이 실행될때 처리하도록 하려 했습니다. 이는 k8s에서 Job 파드로 처리하기 위함이었는데요, 문제는 요청 시점에 의 상태가

Spring Boot에서 LocalStack + Testcontainers로 AWS 통합 테스트 구축하기 현대의 많은 애플리케이션 컴포넌트가 클라우드로 이전하면서, 테스트 과정에서 테스트만을 위한 별도의 클라우드 인프라를 구성하는 것은 큰 부담으로 다가올 수 있습니다. LocalStack은 이러한 문제를 해결하기 위해 등장했습니다. 이번 포스트에서는 LocalStack을 활용하여 클라우드 인프라 의존적인 테스트 코드를 걷어내고 Testcontainers와 통합하여 어떻게 안전하고 신뢰성 있는 테스트를 할 수 있는지 정리하겠습니다. 💡 다음 선행 지식이 필요하다: - JUnit 5 - Testcontainers ⚠️ 사전 준비: Docker가 설치/실행되어 있어야 한다. (Testcontainers와 LocalStack은 Docker 컨테이너를 사용한다) LocalStack이란 무엇인가요? LocalStack은 로컬 환경에서 AWS 클라우드 서비스를 시뮬레이션 할 수

Flyway로 Testcontainer에서 기본데이터 구축하기 테스트를 진행할때 Mock데이터나 fixture를 준비하는 과정은 다소 번거롭습니다. Testcontainer를 사용하여 테스트 환경의 DB를 격리할 수 있으나, API 레이어를 경유하는 E2E 통합 테스트(예: @SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOMPORT)와 TestRestTemplate이나 WebClient를 활용한 실제 HTTP 요청 시나리오)에서는 트랜잭션 경계가 모호해져 @Transactional 롤백 처리가 불완전하거나 예상치 못한 동작을 보일 수 있기 때문에 또 다른 고려 사항이 필요합니다. 이는 MockMvc처럼 서버를 모킹하는 통합 테스트에서는 @Transactional로 충분히 효과적인 롤백을 지원하지만, E2E에서는 실제 네트워크 레이어(포트 바인딩, HTTP 헤더 처리, 보안 필터 등)를 포함해 전체 스택을 검증해

JVM Compressed OOPs Compressed OOPs란 무엇인가? OOPs(Ordinary Object Pointers)는 JVM 내부에서 힙 객체의 참조 주소를 가리키는 포인터를 뜻합니다. 자바 코드에서 로 생성된 객체의 메모리 주소를 가리키는 내부 포인터입니다. Compressed OOPs는 이름에서 알 수 있듯 "압축된 포인터"로 이해할 수 있는데요. 32비트 시스템과 64비트 시스템을 중심으로 이에 대해 알아봅시다. 32비트 vs 64비트 32비트 시스템 - 32비트 주소 버스와 64비트 데이터 버스를 가지는 Pentium - 32비트 CPU는 주소 버스(Address Bus) 폭이 32비트입니다. (레지스터 폭과 주소 버스 폭이 다른 CPU 아키텍처도 존재하나 예외로 생각하겠습니다.) 즉, 한 번에 32개의 비트를 사용해 메모리의 주소를 지정할 수 있습니다. 2^32 = 4,294,967,296 byte = 4GB 이 말은 CPU가 직접 접근할 수 있는 물리적 메

CAP 정리 CAP 정리, 왜 중요한가? 분산 시스템은 여러 대의 서버가 협력하여 하나의 데이터를 관리하는 환경입니다. 이러한 환경에서는 언제든지 장애나 네트워크 분할이 발생할 수 있습니다. CAP 이론은 이러한 불안정한 환경에서 무엇을 포기하고 무엇을 지킬 것인가를 판단하는 기준이 됩니다. 즉, 완벽한 시스템을 설계하는 것이 아니라, 현실적 제약 속에서 균형을 선택하는 철학을 제공합니다. 💡 CAP Theory(이론)는 이론으로 시작하여 증명이 완료되어 현재는 '정리'(Theorem)으로 불립니다. 해당 이론은 Eric Brewer의 추측 증명으로 검증되었으며, 논문은 다음 링크에서 확인하실 수 있습니다. 논문명: “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition‑Tolerant Web Services” (Seth Gilbert & Nancy Lynch, 2002) CAP 정리란?

엘라스틱서치 인덱스 설계 2 🔍 엘라스틱서치 스터디 시리즈 - Chap1. 엘라스틱서치 기본 동작 및 구조 - Chap2. 엘라스틱서치 인덱스 설계 1 - Chap3. 엘라스틱서치 인덱스 설계 2 - Chap4. 엘라스틱서치 데이터 핸들링 애널라이저와 토크나이저 필드의 데이터는 애널라이저를 통해 분석돼 여러 텀(term)으로 쪼개져 색인됩니다. 애널라이저는 다음과 같은 요소로 구성됩니다. - 0개 이상의 캐릭터 필터: 문자열을 변형시킨다. - 1개의 토크나이저: 여러 토큰으로 쪼갠다. - 0개 이상의 토큰 필터: 후처리(변형)한다. 각각에 대해 알아봅시다. analyze API 엘라스틱서치는 애널라이저와 각 구성 요소의 동작을 간편하게 테스트해볼 수 있는 API를 제공합니다. 가장 기본적인 애널라이저의 분석 결과를 확인해봅시다. 요청 예시 응답 예시 1. 캐릭터 필터 캐릭터 필터는 를 캐릭터의 스트림으로 받아서 특정한 문자를 추가, 변경, 삭제합니다. 애널라이저에는 0개 이상