노트

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

7회 조회

RAG (Retrieval-Augmented Generation) 는 LLM 의 한정된 학습 시점·메모리 한계를 외부 지식으로 보완하려는 방식입니다. 검색·생성을 분리하면 모델을 다시 학습시키지 않고도 새로운 자료를 다룰 수 있습니다.

4회 조회

AI 가 브라우저 안으로 들어오는 흐름이 2023~2025 년에 빠르게 진행됐습니다. 사이드바 보조에서 시작해 페이지 요약·번역·드래프트, 그리고 에이전트가 사용자 대신 페이지를 다루는 자리까지 펼쳐졌습니다.

3회 조회

공공기관·외부 사업자가 제공하는 OpenAPI 를 프론트엔드에서 직접 호출 하면 첫 화면은 빠르게 만들 수 있습니다. 그러나 운영을 며칠 굴려 보면 같은 자리에서 같은 종류의 사고가 반복됩니다 — 키 노출, 응답 코드 해석, 프로토콜 미스매치. 그래서 외부 API 는 우리쪽 BFF 한 겹 을 사이에 두는 게 거의 항상…

2회 조회

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

2회 조회

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

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

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

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

horoscopes는 날짜·종류·sign 하나가 아니라 한 날짜와 종류의 기대 sign 집합이 제품 결과다. 한 sign만 존재한다고 전체가 준비된 것은 아니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

공공기관·외부 사업자가 제공하는 OpenAPI 를 프론트엔드에서 직접 호출 하면 첫 화면은 빠르게 만들 수 있습니다. 그러나 운영을 며칠 굴려 보면 같은 자리에서 같은 종류의 사고가 반복됩니다 — 키 노출, 응답 코드 해석, 프로토콜 미스매치. 그래서 외부 API 는 우리쪽 BFF 한 겹 을 사이에 두는 게 거의 항상…