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

조용히 비어버린 값 하나에서 시작한 ORM 메이저 업그레이드 검증 전략New

최근 사내 패키지 업데이트와 더불어 NestJS 12+ / MikroORM v7+ 로 버전 업데이트를 진행했다. 대부분은 타입 에러를 지우고 변경된 API를 따라가는, 예상 범위 안의 작업이었다. 그 과정에서 유독 오래 붙잡고 있었던 문제가 하나 있었다. MikroORM 업데이트 중, 임베디드 값 객체(Value Object)로 매핑한 필드가 특정 조회 경로에서만 조용히 비어버리는 현상이었다. 에러도 불분명했고, 타입 에러조차 나지 않았다. 컴파일은 통과하고 런타임에서만 값이 사라지는 형태라, e2e 시나리오가 아니었다면 아마 조용히 배포되어 운영에서 마주쳤을 문제였다. 이와 더불어 자연스럽게 따라온 질문이 있었다. 다른 지점에서도 같은 성격의 이슈가 더 있지 않을까? 그래서 e2e 시나리오의 검증 축을 옮겼다. 단순히 “응답이 같은가”를 확인하는 것에 더불어, “발행되는 쿼리가 같은가” 에 포커스를 맞추는 방향으로. 이번 포스팅은 그 판단의 과정과, 그래서 만…

Backend
6 min0 2026.09.18
조용히 비어버린 값 하나에서 시작한 ORM 메이저 업그레이드 검증 전략

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

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

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: “없으면 넣고, 있으면 꺼내기”