튜토리얼
64개의 포스트
'지난달 글'은 누가 계산하나 — 시간 표현과 검색, 계산하게 할 것인가 고르게 할 것인가 (한국어 검색 스택 11편)
8편에서 '2026년 4월에 올라온 RAG 글'은 정규식 몇 줄로 풀렸습니다. 날짜가 숫자로 적혀 있었기 때문입니다. 그런데 사람은 그렇게 묻지 않습니다. '지난달 RAG 글', '올봄에 쓴 보안 글', '도커 첫걸음 시리즈가 나온 다음에 쓴 Git 글'. 이 글은 오늘을 2026년 10월 14일로 고정하고 이런 질문 38개로, 시간 표현을 날짜 범위로 바꾸는 일을 누구에게 맡겨야 하는지 쟀습니다. 정규식은 하나도 읽지 못했습니다. 로컬 LLM은 날짜를 직접 계산해 nDCG@10 0.735까지 올렸지만 '두 달 전'을 하루짜리 날짜로 읽어 결과가 텅 빈 질문을 만들었습니다. Jev에게 글마다 날짜를 판정시키면 '지난달'은 완벽했지만 '지난 분기'는 56%였습니다. 같은 Jev가 코드가 펼쳐 준 기간 후보 20개 중에서 고르게 하자 26개를 전부 맞혔고, 사건 기준 질문은 검색이 기준 글을 찾게 한 설계가 0.832로 상한선(0.851)에 다가갔습니다. 계산은 코드가, 판단은 Jev가, 찾기는 검색이. Jev 2,627회 호출에 0.06달러. 인터랙티브 4개와 삽화 7장.
조건이 둘, 셋이 되면 — 질문을 쪼개는 검색과 Jev의 조건별 판정, 한국어 실측 (한국어 검색 스택 10편)
8편이 풀지 못한 숙제가 있었습니다. 'AWS 보안 글', 'Claude Code에서 MCP를 쓰는 글'처럼 두 주제를 모두 만족해야 하는 질문입니다. 이 글은 조건 1개·2개·3개짜리 한국어 질문 52개와 조건 순서만 바꾼 쌍둥이 질문 40개로, 조건이 늘 때 검색이 어떻게 무너지는지와 그것을 어떻게 막는지를 쟀습니다. 질문을 한 번에 임베딩하면 nDCG@10이 조건 1개 0.940에서 2개 0.519, 3개 0.387로 떨어졌습니다. 질문을 조건별로 쪼개 따로 찾고 합치기만 해도 3개에서 0.592로 버텼고, 그 후보를 Jev가 판정하면 2개와 3개 모두 0.725였습니다. Jev는 한 호출에 질문을 여러 개 받으므로 조건마다 따로 물어도 조건 하나당 토큰 90개, 지연 2ms만 늘었고, 어느 조건이 빠졌는지까지 알려 줬습니다. 의외의 발견도 있었습니다. 판정할 문장 자체가 바뀌는 탓에 'Jev 한 질문'이 조건 순서에 가장 민감했고, 조건별로 묻자 그 흔들림이 사라졌습니다. Jev 9,544회 호출에 0.27달러. 인터랙티브 4개와 삽화 7장.
'빼고'를 공짜로 고칠 수 있나 — 임베딩 트릭 대 Jev, 한국어 제외 질문 50개 실측 (한국어 검색 스택 9편)
8편에서 '쿠버네티스는 빼고 도커만'이라고 물으면 임베딩이 상위 10개의 절반을 쿠버네티스 글로 채운다는 것을 봤고, Jev가 그것을 고쳤습니다. 그런데 8월과 9월에 나온 두 논문(EXCISE, E-SENS)은 학습도 큰 모델도 없이 이 문제를 줄이는 방법을 내놓았습니다. 이 글은 한국어 제외 질문 50개(표지어가 분명한 30개, 돌려 말한 10개, 두 가지를 동시에 빼는 10개)로 그 공짜 방법들과 Jev를 정면으로 비교했습니다. 가장 큰 한 걸음은 놀랍도록 단순했습니다. 질문에서 빼라는 말을 떼어 내기만 해도 nDCG@10이 0.245에서 0.555로 뛰었습니다. 빼라는 단어가 든 글을 아래로 내리는 공짜 규칙은 0.676으로 8편의 Jev 방식(0.672)과 같은 자리까지 올라왔습니다. 하지만 그 규칙은 평범한 질문을 제외 질문으로 오인했을 때 정답을 100위로 보내는 위험도 있었습니다. 글자 강등으로 정리한 상위 20개만 Jev가 판정하는 조합이 0.790으로 가장 높았지만 강등의 위험을 그대로 물려받았고, 원래 질문과 뗀 질문의 후보를 합쳐 Jev에 주면(0.759) 평범한 질문을 하나도 해치지 않았습니다. Jev 3,405회 호출에 0.1달러. 인터랙티브 5개와 삽화 7장.
도구는 넷, 자리는 넷 — BM25·임베딩·Jev·코드를 적재적소에 쓰는 한국어 검색 실측 (한국어 검색 스택 8편)
6편에서 Jev는 리랭커로 강했고, 7편에서는 환각 검문소로 강했습니다. 그렇다면 검색의 모든 단계를 Jev에 맡기면 될까요? 이 글은 한국어 질문 134개를 다섯 가족(키워드·의미·제외 조건·두 주제·날짜·카테고리)으로 나눠 BM25, 임베딩 둘, 하이브리드, Jev, 그리고 정규식 몇 줄짜리 코드 필터를 열세 가지 방식으로 조합해 실측했습니다. 질문의 종류가 바뀌면 이기는 도구가 바뀌었습니다. '쿠버네티스는 빼고'라고 하면 임베딩과 BM25는 쿠버네티스 글을 상위 10개의 절반쯤 가져왔고 Jev가 그것을 19%로 줄였습니다. 날짜 질문에서는 Jev가 날짜 판정 807쌍을 전부 맞혔는데도 코드 필터에 졌습니다. 판정이 아니라 후보가 문제였기 때문입니다. 각 도구를 제자리에 둔 설계는 모든 질문에 Jev를 쓰는 방식보다 점수가 높으면서 Jev 호출은 40%였습니다. Jev 9,521회 호출에 0.26달러. 인터랙티브 5개와 삽화 7장.
임베딩은 '아니다'를 못 읽는다 — Jev를 RAG 환각 검문소에 세우다 (한국어 검색 스택 7편)
임베딩 모델은 '매출이 30% 늘었다'와 '매출이 30% 줄었다'를 거의 같은 문장으로 봅니다. 검색에는 맞는 판단이지만, RAG 답변의 마지막 관문에서는 치명적입니다. 이 글은 6편에 이어 TypeSafe의 Jev를 한국어 검색 파이프라인의 새 자리, 답변 뒤의 '환각 검문소'에 세웁니다. 이 블로그 문단 87개로 참 주장 257개와 숫자·방향·주체를 바꾸거나 없는 사실을 덧붙인 거짓 주장 344개를 만들고, 임베딩 둘·크로스 인코더·NLI 모델·로컬 LLM 둘·Jev에게 같은 601쌍을 판정시켰습니다. 참 주장의 90%를 통과시키는 임계값에서 BGE-M3 코사인은 숫자를 바꾼 거짓의 3%만 잡았고, Jev는 100%를 잡았습니다(AUROC 0.995). 0.3B NLI 모델이 의외의 복병이었고(0.959), 숫자를 1만 바꿔도 잡던 Jev는 문서의 숫자로 계산해야 하는 주장에서 약해졌습니다. 601번 검문에 0.021달러. 인터랙티브 7개와 삽화 8장.
임베딩 다섯과 판정 모델 하나 — TypeSafe Jev를 한국어 검색 파이프라인에 세워 보다 (한국어 검색 스택 6편)
지난 특집에서 TypeSafe의 Jev를 '글자를 포기한 모델'이라고 소개했습니다. 벡터도 문장도 내놓지 않고, 상태와 질문을 받아 확률이 붙은 결정만 돌려주는 모델입니다. 그렇다면 임베딩 모델과 비교할 수 있을까요? 같은 자리에 놓으면 안 됩니다. 임베딩은 '문서 100만 개 중 어디를 볼까'를 정하고, Jev는 '이 열 장 중 어느 것이 답인가'를 판정합니다. 이 글은 그 자리를 정확히 나눈 뒤, 1~5편의 한국어 코퍼스(589건, 질문 85개)로 Jev를 검색 파이프라인의 세 자리에 세워 실측했습니다. 리랭커로는 8B 임베딩의 상위 10개를 0.889에서 0.929로 올렸고(같은 자리에서 568M 크로스 인코더는 0.864로 떨어뜨렸습니다), 한국어 지시문이 영어보다 조금 더 좋았고, 확률은 대체로 보정돼 있었고, 4,213번 호출에 0.16달러가 들었습니다. 반면 카테고리 분류에서는 임베딩 이웃 투표가 이겼습니다. 인터랙티브 5개와 삽화 10장.
BM25는 한국어를 어떻게 쪼개나 — 조사·복합명사·영한 혼용, 토크나이저가 검색을 결정한다 (한국어 검색 스택 5편)
2편에서 BM25는 '약한 고리'였습니다. 왜 약했을까요. 이 글은 그 질문을 파고듭니다. 같은 문서, 같은 질문, 같은 BM25 공식에 토크나이저만 여덟 가지로 바꿔 보니 nDCG@10이 0.42에서 0.62까지 벌어졌습니다. 띄어쓰기로 자르면 '청년취업을'과 '청년취업'이 다른 단어가 되고, 형태소 분석기로 조사를 떼면 같은 단어가 되며, 글자 2-gram을 겹쳐 색인하면 사전에 없는 말까지 받아 줍니다. 한국어에서 어휘 검색이 어려운 세 가지 이유(교착어의 조사와 어미, 복합명사, 영한 혼용)를 예시 문장의 실제 토큰으로 보여 주고, 엘라스틱서치 nori의 decompound 모드와 불용 품사 기본값, Kiwi의 사용자 사전, BM25의 k1·b 다이얼을 실측으로 짚습니다. 결론은 BM25 자체가 약한 것이 아니라 한국어를 잘못 쪼갠 BM25가 약하다는 것입니다. 인터랙티브 4개와 삽화 8장.
4096차원에 HNSW가 필요한 이유 — 전수 비교의 벽, 차원의 저주, 그리고 그래프를 걸어서 찾는 법 (한국어 검색 스택 4편)
1편에서 가장 좋았던 Qwen3-Embedding-8B는 문장 하나를 4,096개 숫자로 바꿉니다. 문서 589건이면 질문 하나에 589번 내적하면 되니 1초도 안 걸립니다. 그런데 문서가 5,000만 건이면? 같은 방식으로는 질문 하나에 2,000억 번 곱셈이고, 서버가 아무리 좋아도 초 단위입니다. 벡터 DB가 HNSW라는 인덱스를 쓰는 이유가 여기 있습니다. 이 글은 왜 고차원에서는 트리 인덱스가 소용없는지(차원의 저주), HNSW가 어떻게 스킵 리스트와 작은 세상 그래프를 합쳐 로그 시간에 근사 최근접을 찾는지, M·ef_construction·ef_search 세 손잡이가 무엇을 바꾸는지를 그림과 장난감 시뮬레이터로 풀고, 4,096차원 벡터 1만·10만·30만 개로 전수 비교와 hnswlib을 직접 재서 비교합니다. 10만 개에서 전수 비교 56ms 대 HNSW 1.3ms(재현율 0.98). 그리고 4,096차원의 진짜 병목은 그래프가 아니라 벡터 자체라는 것, 그래서 3편의 마트료시카 절단과 양자화가 HNSW와 곱해진다는 것을 메모리 계산기로 보입니다. 인터랙티브 4개와 삽화 8장.
2026년 백엔드 실전 팁 9가지 — 브라우저에서 재현하는 장애와 해법
입문서를 떼고 운영을 시작하면 만나는 장애 아홉 가지를, 여러분의 브라우저 안에서 직접 재현해 봅니다. 재시도가 장애를 키우는 재시도 폭풍, 결제 버튼 두 번, 목록 하나에 쿼리 51번(N+1), UUIDv4 기본키가 키우는 인덱스, 서버리스가 터뜨리는 커넥션 풀, 캐시가 한꺼번에 만료되는 스탬피드, DB 저장과 메시지 발행 사이에서 사라지는 이벤트, 자정을 넘나드는 시간대 버그, 그리고 로그 바다에서 원인 찾기. 세 개의 데모는 PGlite로 브라우저 안에 진짜 PostgreSQL 18을 띄워 실제 SQL과 실행 계획을 보여 주고, 나머지는 가정을 밝힌 시뮬레이터입니다. 2025년 10월 AWS us-east-1 장애와 11월 Cloudflare 장애의 사후 분석에서 교훈을 가져왔고, 해법 코드는 FastAPI(파이썬)와 Node(타입스크립트)로 나란히 실었습니다.
2026년 프론트엔드 실전 팁 9가지 — 직접 재현해 보는 함정과 해법
라이브러리 고르는 법을 다룬 지난 글에 이어, 이번에는 매일 코드를 쓰는 사람이 알아야 할 습관 아홉 가지를 정리했습니다. 보안 패치는 기능 업데이트가 아니라는 것(React2Shell, Next.js 8월·9월 보안 릴리스), npm 공급망 공격에 대비해 새 버전을 하루 늦게 받는 법, React Compiler 시대의 '렌더는 순수하게' 규칙과 useEffectEvent, React 19.3과 Next.js 16.3의 변화, INP를 지키는 작업 쪼개기, 라이브러리 전에 확인할 브라우저 기본 기능, 한글 입력 중 Enter 두 번 전송 버그, keep-all·대체 글꼴·Intl로 다듬는 한국어 화면, 그리고 AI가 짠 코드를 브라우저에서 확인하는 습관. 각 팁에는 여러분의 브라우저에서 직접 재현하고 측정하는 데모 6개를 붙였습니다.
마트료시카 임베딩 — 벡터를 앞에서부터 잘라도 되는 이유와, 잘랐을 때 실제로 남는 것 (한국어 검색 스택 3편)
Qwen3-Embedding-8B의 벡터는 숫자 4,096개입니다. 5,000만 청크를 float32로 저장하면 벡터만 819GB입니다. 그런데 이 벡터의 앞 256개만 남기고 나머지를 버려도 검색 품질의 93%가 남는다면? 그것이 마트료시카 임베딩입니다. 2022년 논문 「Matryoshka Representation Learning」이 제안하고 OpenAI text-embedding-3, Nomic v2, Qwen3 Embedding이 채택한 이 기법은 '중요한 정보를 벡터의 앞쪽에 몰아넣도록' 학습해, 러시아 인형처럼 큰 벡터 안에 작은 벡터가 들어 있게 만듭니다. 이 글은 원리를 장난감 모형으로 손에 잡히게 설명하고, 같은 한국어 코퍼스로 Qwen3 4B·8B와 Nomic v2를 32차원까지 잘라 가며 잰 실측 곡선, 저장 비용 계산기, 그리고 '짧게 걸러서 길게 고르는' 두 단계 적응형 검색이 전체 차원의 품질을 얼마나 되찾는지를 보여 줍니다. 인터랙티브 4개와 삽화 7장.
Postgres 하나로 어디까지 ① 작업 큐 — SKIP LOCKED로 Redis·RabbitMQ 없이 시작하기
메일 발송·썸네일 생성·외부 API 호출처럼 '나중에 해도 되는 일'을 맡길 큐가 필요할 때, Redis나 RabbitMQ를 새로 띄우기 전에 이미 쓰고 있는 PostgreSQL로 충분한지 따져 봅니다. 큐 테이블 하나와 쿼리 세 개로 시작해 SKIP LOCKED로 여러 워커가 겹치지 않게 일을 나누고, 리스(lease)로 죽은 워커의 일을 되살리고, 재시도·백오프·데드레터를 붙이고, LISTEN/NOTIFY로 즉시 깨우는 법까지. 큐 테이블이 부푸는 MVCC의 함정과 파티션으로 피하는 법, 언어별 라이브러리, 그리고 언제 전용 브로커로 떠나야 하는지도 다룹니다. 데모 두 개는 여러분의 브라우저 안에서 진짜 PostgreSQL 18을 띄워 실행됩니다.