JH's Notes

안녕하세요.
|
백엔드 개발자 김정현입니다.

복합 인덱스는 언제 필요할까?New

복합 인덱스는 여러 컬럼을 묶어 추가하면 조회 성능이 좋아지는 기능이라고 생각하기 쉽다. 하지만 실제로는 컬럼의 개수보다 애플리케이션이 데이터를 어떤 조건으로 찾고, 어떤 순서로 정렬하며, 어떤 단위로 나누어 반환하는지가 더 중요하다. 예를 들어 다음과 같은 조회가 있다고 가정해보자. 특정 상태()의 데이터만 조회한다. 기본 키()를 기준으로 최신순 정렬한다. 페이지 단위로 결과를 반환한다. 데이터가 적을 때는 단일 인덱스만으로도 큰 문제가 발생하지 않을 수 있다. 하지만 데이터가 쌓이고 호출량이 증가하면, 데이터베이스는 인덱스를 사용하고도 최종 결과보다 훨씬 많은 데이터를 읽거나 별도의 정렬 작업을 수행하게 된다. 그렇다면 복합 인덱스는 어떤 상황에서 필요하고, 어떤 기준으로 설계해야 할까? 처음부터 모든 조회 조건을 복합 인덱스로 만들 필요는 없다. 우선 운영 환경에서 실제로 느린 요청을 찾고, 해당 요청이 어떤 방식으로 …

Backend
3 min0 2026.08.09
복합 인덱스는 언제 필요할까?

Conductor에서 Supersets로 정착한 이유

최근 내 개발 환경에서 가장 크게 바뀐 부분은 AI Agent를 사용하는 위치다. 이전에는 IDE 안에서 터미널을 열고, 그 안에서 Codex나 Claude Code를 실행하며 작업을 진행했다. 코드를 확인하는 화면, 명령을 실행하는 화면, AI Agent와 대화하는 화면이 모두 하나의 IDE 안에 있었다. 처음에는 이 방식이 자연스러웠다. 내가 보고 있는 파일을 기준으로 바로 명령을 실행할 수 있고, 결과도 곧바로 확인할 수 있었기 때문이다. 하지만 AI Agent에게 맡기는 작업의 단위가 커지고, 동시에 여러 방향을 실험하는 일이 늘어나면서 이 방식은 점점 답답해졌다. 한 작업을 맡기는 동안 다른 시도를 병렬로 진행하기 어렵다. AI Agent가 제안하는 여러 변경을 동시에 검토하기 번거롭다. AI Agent가 만든 변경을 내가 직접 읽고 판단하는 흐름이 IDE 작업과 섞인다. 그래서 최근에는 작업 방식을 조금 바꿨다. 코드 확인과 최종 판단은 IDE에서 진…

AI
5 min0 2026.06.21
Conductor에서 Supersets로 정착한 이유

Map에 드디어 생긴 getOrInsert: “없으면 넣고, 있으면 꺼내기”

Map을 쓰다 보면 “키가 없으면 기본값을 넣고, 그 값을 바로 사용한다”는 패턴을 끝없이 반복하게 된다. 이 패턴은 간단하지만 코드가 지저분해지고, 팀마다 구현 방식이 달라지면서 가독성이 더 떨어진다. Map.prototype.getOrInsert() / getOrInsertComputed() 는 이 반복을 표준 API로 정리한다. 이 기능은 ECMAScript 2026 스펙에 포함될 예정이며, 이제 출시를 앞둔 시점이다. 오래 기다렸던 만큼 사용법과 주의점, 그리고 안전하게 도입하는 요령을 정리해두려 한다. “없으면 넣고 꺼내기”는 사소한 개선처럼 보이지만, 서비스 코드에서는 가장 자주 등장하는 반복 중 하나다. 대부분의 코드베이스에서 Map을 쓰는 이유는 명확하다. “키 → 값” 관계를 빠르게 조회하고 싶기 때문이다. 문제는 값이 없는 경우다. 예를 들어, 그룹핑(카테고리별로 리스트 만들기)을 구현하…

JavaScript
4 min0 2026.02.15
Map에 드디어 생긴 getOrInsert: “없으면 넣고, 있으면 꺼내기”

이벤트 소싱을 적용하기 전에 반드시 고민해봤어야 할 것들

우리 서비스의 주문 도메인에는 조금 특이한 특징이 하나 있다. 일반적인 상품 주문과 달리 SNS 마케팅 주문은 하나의 주문이 여러 개의 실행 단위로 쪼개진다. 예를 들어 “좋아요” 주문이 들어오면 시스템 내부에서는 다음과 같은 일들이 순차적으로 발생한다. 주문이 생성된다 결제 및 포인트 차감이 이루어진다 주문 상태가 “진행중”으로 변경된다 좋아요 작업이 여러 번에 나뉘어 실행된다 각 실행 결과가 개별 로그로 기록된다 모든 작업이 끝나면 주문 상태가 “완료”로 변경된다 이 과정에서 우리는 주문 하나를 처리하기 위해 수백, 많게는 수천 건의 실행 로그를 쌓고 있었다. 또한, 이 로그들은 단순한 디버깅 용도가 아니었다. 운영에서는 이 로그를 기준으로 주문 진행 상황을 판단했고 CS 대응에서도 “어디까지 실행되었는지” 를 설명하는 근거로 사용되고 있었다. 이 지점에서 이런 생각이 들기 시작했다. 이미 우리는 “무엇이 언제 일어났는지”를 이벤트처럼 기록하고 있지 않은가?…

Backend
4 min0 2026.01.06
이벤트 소싱을 적용하기 전에 반드시 고민해봤어야 할 것들