노트

NotebookLM 은 Google 의 자료 우선 (source-grounded) AI 노트북. 사용자가 업로드한 PDF·구글 문서·웹사이트·YouTube·오디오에서만 답변을 합성하므로 hallucination 이 일반 챗봇보다 적음. 04-gemini-api 가 raw API, 08-google-ai-studio 가…

19회 조회

SQLite 는 단일 파일에 SQL 데이터베이스를 담는 임베디드 DB 입니다. 데스크탑·모바일 앱의 로컬 저장소로 가장 자주 쓰이는 선택지 중 하나입니다.

13회 조회

LLM 시장의 지형은 빠르게 바뀝니다. 폐쇄형 API 와 오픈 가중치, 영어 중심과 다국어, 클라우드와 자체호스팅, 한국어에 특화된 모델이 함께 자리 잡고 있습니다.

12회 조회

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

11회 조회

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

11회 조회

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

Tauri의 output: export 빌드는 Next.js 서버 route와 redirect를 포함하지 않는다. 웹과 같은 코드를 공유한다는 사실이 같은 실행 능력을 보장하지 않는다.

콘텐츠 서비스는 같은 화면을 두 가지 데이터 공급 경계에서 제공할 수 있다. Docker SSR은 PostgreSQL을 읽고, 정적 호스트는 배포 시점의 /api/export snapshot을 읽어 페이지를 만든다. 둘을 억지로 하나의 runtime으로 합치면 static build가 DB 자격 증명을 요구하거나, SS…

브라우저가 보내는 MIME과 확장자는 신뢰할 수 있는 파일 형식 증명이 아닙니다. 특히 공개 bind mount에 저장하는 CMS 이미지는 저장 전에 최소한의 실제 바이트 검사와 원자성 보장이 필요합니다.

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

통합 테스트가 스키마를 만들지 못했는데도 entity 테스트를 계속하면 실패가 지연되어 원인을 잃는다. 마이그레이션 디렉터리 누락, SQL 파일 0개, 파일 읽기 실패, 개별 SQL 오류는 모두 테스트 bootstrap 실패다.

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

스케줄러 작업이 예외를 던지지 않았다는 사실은 성공을 뜻하지 않는다. 내부에서 오류를 잡고 None, error, 처리 수, partial을 반환하는 작업이 섞이면 관제는 정상·빈 결과·부분 실패를 구분하지 못한다.

이미지가 만들어졌다는 사실은 사용자가 정상 경로를 사용할 수 있다는 증거가 아닙니다. 검사한 commit과 실행 image를 묶고, health 뒤에 실제 DB를 읽는 smoke를 실행해야 합니다.

콘텐츠 DB 초기화는 테이블 생성·스키마 보정·정적 시드·notes/courses 업서를 순서대로 묶습니다. 운영자가 버튼을 두 번 누르거나 console replica가 겹치면, 각 단계가 멱등이어도 두 파이프라인이 중간 상태를 서로 읽을 수 있습니다.

Java API와 Python 음성 엔진은 서로 다른 프로세스이므로, 문자열 기반 내부 호출보다 protobuf 계약이 변경과 장애를 더 분명하게 만든다. voice/v1/voice.proto는 음성 합성·voice catalog·capability를 하나의 버전 경계로 묶고, Java client는 요청 deadlin…

컨테이너가 running이어도 DB 연결·필수 테이블·내부 의존성이 준비되지 않았을 수 있습니다. readiness는 사용자 요청을 받을 수 있는 상태를, liveness는 프로세스가 살아 있는지를 나타내야 합니다.

프로세스가 살아 있다는 사실, 핵심 검색 요청을 처리할 준비가 됐다는 사실, 선택 기능이 모두 정상이라는 사실은 서로 다릅니다. 하나의 ready 값에 전부 넣으면 선택 모델 장애가 전체 재시작으로 이어지고, 핵심 DB 장애를 liveness가 가립니다.

WebRTC는 Java API가 미디어를 전달하지 않아도 브라우저 간 연결·NAT·릴레이 설정이 필요하다. 그래서 예시 서비스는 텍스트 방을 원본으로 유지하고, 음성 리뷰는 opt-in 가능한 P2P 보조 경로로만 구현한다.

관측성은 데이터를 많이 쌓는 일이 아니라 장애 질문에 답하는 일입니다. Rate·Errors·Duration을 route template로 수집하고 request context로 로그·비동기 작업과 연결합니다.

HTTP 요청은 응답을 돌려주고 끝나지만 Kafka 작업은 나중에 처리됩니다. 이 둘을 같은 업무 payload로 억지로 묶지 않고, 별도의 correlation header를 전달하면 JSON 계약을 보존하면서 한 요청의 흐름을 따라갈 수 있습니다.

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

기능 구현과 완료 판정은 다릅니다. 기획·디자인·개발·사용자·운영 관점의 질문을 각각 테스트나 기록으로 연결해야 다음 사람이 같은 결론을 재현할 수 있습니다.

목록이 풍부해질수록 사용자는 원하는 글을 다시 찾기 어려워집니다. 검색과 카테고리는 새 글을 발견하는 길이고, 최근 기록은 이미 읽던 글로 돌아오는 길입니다. 둘은 서로 대체하지 않습니다.

대시보드는 서비스가 가진 도메인의 거울 입니다. 도메인이 5 개인데 위젯이 3 개면 사용자는 "나머지 2 개 도메인은 미완성인가" 를 본능적으로 의심합니다. 통일성은 디자인 감수성의 문제가 아니라 기능 인지 의 문제입니다.