분류 전체보기

1. 핵심 문제 — 왜 필요한가?컬럼을 함수로 가공하면 인덱스를 탈 수 없다.-- created_at에 인덱스가 있어도 풀스캔SELECT * FROM users WHERE MONTH(created_at) = 3;이를 해결하기 위해 표현식 자체를 인덱싱하는 두 가지 방법이 존재한다.2. Generated 컬럼특정 표현식으로 값이 자동 계산되는 컬럼. 사용자가 직접 값을 입력/수정 불가.Virtual vs Stored구분값 저장 위치계산 시점Virtual (기본값)디스크 저장 ❌, 읽을 때마다 계산레코드 읽기 전Stored디스크 저장 ✅INSERT/UPDATE 시PRIMARY KEY는 Stored 타입만 가능생성 문법ALTER TABLE usersADD COLUMN email_domain VARCHAR(10..

varchar와 text는 둘 다 문자열을 저장할 수 있는 가변 길이 타입이다.저장 가능한 크기는 이렇다.varchar: 최대 65,535byte (row 전체 제한 내에서)tinytext: 255bytetext: 65,535bytemediumtext: 16mblongtext: 4gb 그럼 varchar와 text는 어떤 차이가 있을까.db 엔진에서select user_name, title from posts where post_id > 100;를 한다고 했을 때, content 컬럼이 TEXT든 VARCHAR든 select 대상이 아니므로 접근하지 않는다. off-page에 저장돼 있더라도 마찬가지다. off-page 저장row가 너무 커서 한 page(16kb)에 못 들어가면 가변 길이 컬럼은 off..

varchar와 char는 둘 다 문자열을 저장한다는 공통점이 있다.이렇게 알고는 있었다.char는 고정적인 문자열일 때 사용하고, varchar는 가변적인 문자열에 사용한다고.varchar는 약 16,000글자, char는 최대 255글자를 저장할 수 있다.문자열 캐릭터 셋에 따라 글자당 몇 바이트를 할당할지 결정된다. 즉 MySQL에서 VARCHAR(100)은 캐릭터 셋에 상관없이 100글자를 저장할 수 있다는 것이다. char도 마찬가지다. 그러면 어떤 차이일까?char의 경우 디스크에 저장될 때 항상 최대 크기만큼 예약된 공간을 사용한다.varchar의 경우 실제 데이터 길이만큼만 공간을 사용한다.char(100) → 실제 글자가 30글자 → 100글자 분량의 공간 차지 (한글 기준 3 * 100..

최근 2026 주휴수당 계산기 'Salary Master' 를 만들어봤습니다.처음부터 끝까지 걸린 시간은 약 4시간. Opus, Gemini Pro3와 티키타카하며 만든 결과물인데, 생각보다 재밌는 경험이었어서 공유해봅니다.왜 만들었나?2026년 최저시급이 10,320원으로 확정되면서 "내 주휴수당은 얼마지?" 궁금해하는 사람들 많더라고요. 복잡한 계산 없이 시급과 근무시간만 입력하면 바로 확인할 수 있는 도구를 만들어봤습니다.기술 스택Next.js 14 (App Router)TypeScriptTailwind CSSLucide React빠른 프로토타이핑에 좋은 조합이었습니다.핵심 기능심플한 입력 방식 시급, 주 근무 시간, 주 근무 일수만 입력하면 끝. 실시간 계산 + URL 공유 입력값이 바뀌면 즉시 ..

1. 들어가며지난 글에서는 선착순 승인 시스템에서 발생한 Race Condition 문제를 분석했습니다. 정원 10명인 모임에서 20명이 동시에 승인되는 심각한 정합성 문제였습니다.원인은 명확했습니다:Check-Then-Act 패턴: 정원 검사와 승인 사이의 시간 차비원자적 연산: currentMembers++가 DB 수준에서 원자적이지 않음트랜잭션 격리 수준의 한계: 다른 트랜잭션의 변경을 읽지 못함오늘은 JPA의 비관적 락(Pessimistic Lock)을 적용하여 이 문제를 해결하는 과정을 공유합니다. 2. 비관적 락(Pessimistic Lock)이란?개념비관적 락은 "충돌이 발생할 것"이라고 비관적으로 가정하고, 데이터를 읽는 시점에 락을 거는 방식입니다.DB 수준에서 SELECT ... FOR..

1. 들어가며현재 개발 중인 지역 기반 소셜 커뮤니티의 "소 모임" 서비스에서 인원이 제한된 모임에 참가자를 승인하는 기능을 제공하고 있습니다.서비스의 핵심은 정해진 인원 내에서만 사용자를 승인해야 한다는 점이였습니다. 로컬 환경에서의 단일 요청 테스트는 문제가 없었지만, 실제 운영 환경과 유사한 동시성 테스트를 진행하던 중 정합성 문제를 발견했습니다.오늘은 선착순 승인 시스템에서 발생한 Race Condition(경쟁 상태) 문제와 이를 분석한 과정을 공유해 드리려고 합니다. 2. 문제 상황: 정원을 초과한 승인모임 서비스의 비즈니스 로직은 간단합니다. 현재 승인된 인원이 정원보다 적을 때만 모임 주최자가 승인을 수행합니다.하지만 부하 테스트 도중, 정원을 조과하여 승인이 이루어지는 현상을 목격했습니다..