데이터

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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