데이터

콘텐츠 검색은 제목·설명·slug·lesson 본문에서 ILIKE '%검색어%'를 사용한다. 검색어를 escape하고 길이를 제한하는 것은 안전성 계약이고, wildcard 앞뒤 때문에 일반 B-tree 인덱스는 이 쿼리를 충분히 돕지 못한다.

파일 업로드와 검색 가능은 같은 상태가 아닙니다. 파싱·임베딩·저장이 끝나고 processed = TRUE가 된 검색 사본만 사용자 답변의 근거가 될 수 있습니다.

묶음 결과는 행 하나가 아니라 같은 batch key에 속한 기대 멤버 전체로 판정해야 합니다. 일부 행만 존재하는 상태를 완료로 오인하지 않는 읽기·쓰기 계약을 설명합니다.

운영 DB는 새로 만들 때처럼 한 번에 바꿀 수 없습니다. 기존 행을 보존하면서 여러 번 실행해도 같은 상태에 수렴하고, 실패 시 원인을 남긴 채 안전하게 재시도해야 합니다.

콘텐츠 (마크다운·JSON·CSV 등) 를 시드 로 DB 에 넣는 프로젝트에서, 그 시드 파일을 어디에 둘 것인가 는 의외로 큰 결정입니다. 직관적으로 "그 콘텐츠를 쓰는 앱 폴더 안 (frontend/myapp/content/)" 에 두기 쉽지만, 장기적으로는 모노레포 루트 에 두는 편이 거의 항상 옳습니다.

Supabase 노트에서 Storage 는 한 문단으로만 다뤘습니다. 이 노트는 그 자리만 깊게 봅니다 — 버킷 설계 · 업로드/삭제 코드 · 파일 단위 권한(RLS) · S3 호환 API · 서명 URL. 이미지를 어디에 두고, 누구에게 보이게 할지의 실무.

Kafka 를 "쓸지 말지" 는 다른 노트에서 다뤘습니다. 이번 노트는 그 다음 — 토픽을 어떻게 이름 짓고, 파티션·키를 어떻게 잡고, Producer·Consumer 코드를 어떻게 쓰는가입니다. 개념은 한 번 잡으면 끝나지만, 토픽 설계는 한 번 잘못 잡으면 운영 내내 따라옵니다.

관리 콘솔이나 백오피스는 한 프로세스에서 콘텐츠·카탈로그·운영 로그처럼 서로 다른 DB에 접근해야 할 수 있습니다. HTTP 경유 대신 풀 직접 접속을 선택할 때는 연결 수, 권한, 장애 격리를 함께 설계해야 합니다.

모바일·웹에서 사용자가 앱을 열고 있지 않아도 메시지를 보내려면 운영체제·브라우저가 제공하는 푸시 채널을 통과해야 합니다. iOS 는 APNs, Android 는 FCM, 웹은 Web Push 표준이 그 자리에 있습니다.

Redis 는 인메모리 키-값 저장소로 시작했지만 오늘날에는 캐시·세션·큐·랭킹·분산 락·pub/sub 같은 여러 자리를 한꺼번에 맡습니다.

외부 데이터를 다루는 시스템은 어디든 비슷한 단계로 환원됩니다. 데이터를 가져오고, 다듬고, 저장하고, 노출합니다.

Kafka 는 흔히 "큐" 로 불리지만 정확히 말하면 분산 커밋 로그입니다. 강점은 큐 이상의 자리에서 드러납니다. 동시에 단순한 작업 큐에는 과한 도구이기도 합니다.

PostgreSQL 을 오래 쓸수록 한 번쯤 마주치는 개념들이 있습니다. MVCC · 인덱스 · EXPLAIN · 격리 수준 · VACUUM · 파티셔닝.

캐시는 한 곳에만 있는 일이 드뭅니다. 보통 여러 층으로 쌓입니다. 클라이언트 가까이에 두면 빠르고 DB 가까이에 두면 정확합니다.

데이터를 만드는 것이 백업이 아닙니다. 되살려 봐야 백업입니다. 그 차이는 사고 후에야 드러납니다. PostgreSQL 의 도구·정책·리허설을 정리합니다.

Supabase 는 Firebase 의 대안을 표방하며 등장한 오픈소스 백엔드 묶음입니다. 핵심에 PostgreSQL 을 두고 인증·스토리지·실시간·서버리스 함수를 그 주위에 쌓았습니다.

이미지를 다루는 코드는 자주 등장합니다. 업로드 받은 사진의 크기를 줄이고, 형식을 변환하고, 썸네일을 만듭니다.

데이터를 저장할 도구를 고르는 일은 자주 부담입니다. NoSQL · 분산 SQL · 그래프 DB · 시계열 DB 가 줄지어 있습니다. 그러나 많은 프로젝트가 처음 한참 동안 PostgreSQL 한 가지로 충분합니다.

대규모 언어 모델 응답을 외부 지식과 결합하려는 흐름이 RAG (Retrieval-Augmented Generation) 라는 이름으로 자리 잡았습니다. 그 안에서 벡터 유사도 검색이 핵심 부품이고, PostgreSQL 의 pgvector extension 이 가장 가까운 자리에 있습니다.

PostgreSQL · MySQL · SQLite · SQL Server · Oracle 모두 핵심 문법은 비슷합니다. 한 번 배우면 평생 쓰는 도구가 됩니다.