jeonggu.kim 님의 블로그

이번에 Django + React 기반의 회원 관리 시스템을 개발에 앞서, 기존 방식 대신 Vite를 선택하게 된 이유를 정리해보려 합니다.리액트를 처음 배울 때 npx create-react-app을 입력했던 기억, 다들 있으시죠? 그런데 요즘은 많은 개발자들이 Vite(비트)로 넘어가고 있어요. 왜 그런지, 어떻게 다른지 쉽게 풀어볼게요.먼저, "번들러"가 뭔지 알아야 해요리액트로 개발하면 수십, 수백 개의 자바스크립트 파일을 만들게 됩니다. 브라우저가 이걸 하나하나 읽으면 너무 오래 걸리겠죠? 그래서 이 파일들을 하나(혹은 몇 개)로 합쳐주는 도구가 필요해요. 이걸 번들러라고 합니다.항목CRA (Create React App)Vite번들러Webpack오래되고 검증된 번들러개발: ESM / 빌드: R..

개발하다 보면 이런 경험 한 번쯤 있다. Hello?Hello파일을 읽었을 뿐인데 앞에 이상한 문자가 붙는다.이게 바로 BOM(Byte Order Mark) 때문이다.오늘은 이걸 개념 + 원인 + 실무 해결 방법까지 한 번에 정리해본다.1. BOM이란?**BOM(Byte Order Mark)**은파일 맨 앞에 붙는 특수 바이트다.쉽게 말하면:“이 파일은 어떤 인코딩이다” 라고 알려주는 표시제 모습UTF-8-SIG 파일의 경우:EF BB BF + 실제 데이터 하지만 우리가 보면:Hello 문제는 잘못 읽으면 이렇게 된다:Hello?HelloUTF-8 vs UTF-8-SIG 차이구분UTF-8UTF-8-SIGBOM 포함❌ 없음✅ 있음표준 여부✅ 표준❌ 확장주요 사용처서버, DB, APIExcel, ..

이커머스 서비스를 운영하다 보면 반드시 마주하게 되는 문제가 있습니다.바로 재고 처리와 데이터베이스 Lock 문제입니다.처음에는 단순하게 생각할 수 있습니다.상품을 주문하면 재고를 하나 줄이면 됩니다.하지만 실제 서비스 환경에서는 수천 명, 수만 명의 사용자가 동시에 주문을 합니다.이때 데이터베이스에서 제대로 설계하지 않으면 재고가 틀어지거나 서비스가 느려지는 문제가 발생합니다.이 글에서는 실제 이커머스 환경에서 발생하는 문제를 중심으로 재고 처리 방식과 해결 방법을 정리해보겠습니다.데이터베이스 Lock이 필요한 이유먼저 Lock이 무엇인지 이해해야 합니다.데이터베이스에서 Lock은 같은 데이터를 동시에 수정하지 못하도록 잠그는 기능입니다.예를 들어 어떤 상품의 재고가 다음과 같다고 가정해보겠습니다.재고..

트랜잭셔널 아웃박스 패턴(Transaction Outbox Pattern) 정리마이크로서비스 구조나 이벤트 기반 시스템을 설계하다 보면 다음과 같은 상황을 자주 만나게 됩니다.예를 들어 쇼핑몰 주문 서비스를 만든다고 가정해보겠습니다.사용자가 주문을 생성하면 보통 다음과 같은 작업이 필요합니다.주문 데이터를 데이터베이스에 저장합니다.주문 생성 이벤트를 메시지 시스템(Kafka 또는 RabbitMQ)에 전달합니다.코드로 표현하면 다음과 같은 형태가 됩니다.@Transactionalpublic void createOrder() { Order order = new Order(userId, price); orderRepository.save(order); kafkaProducer.send("order-create..

Fail2Ban → 분산 공격 → URL 세션 문제까지 겪은 실전 삽질 기록 1. 최초 상황 — Grafana가 먼저 알아챘다Grafana Node Exporter 대시보드를 보다가 심상치 않은 걸 발견했습니다.CPU Busy User: 평소 20~30% → 40~65%로 치솟음Apache Process 수: 평소 대비 600개 근접하는 스파이크Memory: 급격한 변동Uptime: 41.3주 — 재부팅 없이 운영 중인 서버"왜?"라는 물음을 안고 로그를 열었습니다. 2. 로그 분석 — 트래픽 규모 파악아파치 액세스 로그 두 구간을 분석했습니다.시간대분당최대 요청 수20:39 ~ 20:53최대 2,277 req/min21:26 ~ 21:45최대 2,215 req/min분당 1,000~2,200건이 지속적..

UPDATE는 정말 INSERT 후 DELETE일까?commit 전 내부 동작에 대한 오해 정리 (공식 문서 기반)DB를 다루다 보면 한 번쯤 이런 말을 들어본 적이 있다.“UPDATE는 내부적으로수정된 row를 INSERT 하고기존 row를 DELETE한 다음 commit 된다”겉으로 보기엔 그럴듯하지만,이 설명은 대부분의 RDBMS에서 정확하지 않다.이 글에서는 공식 문서를 근거로이 주장이 언제 맞고, 언제 틀린지를 명확히 정리한다.결론부터 요약일반 컬럼 UPDATE는 INSERT + DELETE가 아니다commit 전이라서 INSERT/DELETE가 발생하는 구조도 아니다이 설명이 부분적으로 맞는 경우는 PostgreSQL의 MVCC 구현뿐이다AUTO_INCREMENT / IDENTITY와는 아무 ..

웹 서버와 WAS는 비슷해 보일 수 있지만 실제로는 역할이 조금 다릅니다.저도 처음에는 그냥 다 서버니까 같은 거 아니야? 라는 생각을 했습니다. 그런데 프로젝트를 하다 보면 이 둘이 나뉘어 있는 이유를 자연스럽게 알게 됩니다.웹 서버는 흔히 보는 HTML, CSS, JS 같은 정적 파일을 클라이언트에게 전달하는 역할을 합니다. 이미지나 폰트 같은 리소스도 포함됩니다. 예를 들어 누군가가 서버에 접속해서 index.html을 요청하면 그 파일을 그대로 보내주는 것이 웹 서버입니다. 대표적인 웹 서버로는 Nginx와 Apache가 있습니다.하지만 요즘 웹 서비스는 정적인 내용만으로는 부족합니다 로그인도 해야 하고 데이터도 왔다 갔다 해야 합니다 이런 작업은 단순한 파일 전송만으로는 처리할 수 없습니다 여기..

개발을 하다 보면 특정한 상황에서 자동으로 어떤 작업이 실행되었으면 할 때가 종종 있습니다 예를 들어 데이터베이스에 새로운 데이터가 들어왔을 때 무언가를 처리하거나 사용자가 버튼을 눌렀을 때 UI를 바꾸는 상황 등이 그렇습니다 이런 동작을 흔히 트리거라고 부릅니다트리거는 말 그대로 어떤 행동을 유발하는 신호라고 보시면 됩니다 총의 방아쇠처럼 특정 조건이 충족되면 작동하는 메커니즘이라고 생각하면 이해하기 쉽습니다제가 처음 트리거를 접한 건 백엔드 작업 중이었습니다 데이터베이스에 특정 값이 저장될 때마다 알림을 보내는 기능이 필요했는데 처음에는 조건문으로 처리했습니다 하지만 코드가 점점 지저분해지고 다른 기능과 얽히다 보니 디버깅도 어려워졌습니다 그러다 트리거라는 기능을 알게 되었습니다.데이터베이스 트리거는..

서버 사이드 렌더링(SSR) 은 서버 측에서 렌더링하는 방식입니다. 클라이언트가 서버에 컨텐츠를 요청하면, 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입하고, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JS 코드를 응답합니다. 브라우저에서는 JS 코드를 다운로드하고, HTML에 JS를 연결합니다.이처럼 모든 데이터가 이미 HTML에 담긴 채로 브라우저에 전달되기 때문에 SEO에 유리합니다. 또한 JS 코드를 다운로드 받고 실행하기 전에 사용자가 이미 렌더링된 HTML을 볼 수 있으므로, JS 다운로드를 기다려야 하는 CSR에 비해 초기 구동 속도가 빠릅니다.클라이언트 사이드 렌더링(CSR) 은 클라이언트 측에서 렌더링하는 방식입니다. 클라이언트가 서버에 컨텐츠를 요청하면, 서버는 빈 ..

요즘 개발 공부를 하다 보면 "Base64"라는 단어를 자주 보게 됩니다. JWT 토큰, 이미지 업로드, HTTP 인증, 이메일 전송 등 곳곳에서 마주치게 되죠. 처음엔 단순히 "문자열이 왜 이렇게 길고 이상하게 생겼지?" 정도로 생각할 수 있지만, 그 배경을 이해하면 이 기술이 왜 중요한지 자연스럽게 와닿습니다.이번 글에서는 신입 개발자라면 꼭 한 번은 짚고 넘어가야 할 Base64 인코딩에 대해 이야기해보려 합니다.Base64 인코딩Base64는 바이너리 데이터를 텍스트로 변환하는 인코딩 방식입니다.쉽게 말해, 이미지나 파일처럼 0과 1로 이루어진 데이터를 이메일이나 HTTP 같은 텍스트 기반 환경에서도 안전하게 전달할 수 있도록 바꿔주는 기술이에요.📌 예: 바이너리 데이터를 텍스트로 바꾸면 SGV..