Mealio

초기 레시피 검색은 필터를 먼저 걸고 의미를 나중에 보는 구조라, 재료·분위기 같은 고차원 질의에서 품질이 떨어졌습니다.

검색을 Semantic-first로 재배치해 재료명 해석(exact → embedding ANN)과 의미 검색을 앞에 두고, 가중치·top-K 정책으로 순위를 조정합니다. 이력서의 Precision@K 약 2배 개선은 별도 평가셋 로그가 코드에 없어, 포트폴리오에서는 정책 파일·핸들러 단계로 품질 통제를 설명합니다.

챗봇은 Tool Call로 Vector DB를 조회하고 Redis Stream·SSE로 토큰을 스트리밍해 체감 응답을 유지합니다.

재료 추가·좋아요 같은 mutation은 이벤트 기반 비동기 command로 처리되어, refetch 직후에도 조회가 lagged 할 수 있었습니다.

예측 가능한 삭제·토글 등은 onMutate에서 setQueryData로 Optimistic update를 넣고 onError에서 롤백합니다. 서버 정합은 이후 invalidate/refetch로 맞춥니다.

상세 LCP는 고해상도 원본 이미지가 지배합니다. ingestion persist의 recipe-image-rehost가 식약처 이미지를 받아 sharp로 480×270 cover · WebP quality 80으로 압축한 뒤 S3/CDN에 재호스팅합니다(soft-fail).

라이브 카드가 .webp CDN URL을 쓰는 점이 결과 증거입니다. 이력서의 평균 5MB→10KB·LCP 15초→5초는 Lighthouse before/after가 코드에 없어, 고정 리사이즈·WebP로 LCP를 개선했다는 서술로 포트폴리오에 맞춰 두었습니다.

개인 프로젝트에서 동기 LLM 호출과 EC2 Public IP가 부담이었습니다. OpenAIBatchService가 JSONL을 Files API에 올리고 batches.create로 parse·embed를 비동기화합니다(약 50%는 Batch 공식 할인·설계 추정치).

배포 문서는 APP(public) 1대 + private INFRA가 APP NAT(ip_forward/MASQUERADE)로 나가도록 해 Public IPv4를 하나로 묶는 비용 설계를 명시합니다.

viewCount/likeCount는 RecipeStats로 본문과 분리되고, 읽기 API는 Cache-Aside를 탑니다.

상세 recipe:{id} TTL 900초(15분), 목록·검색 TTL 300초(5분)입니다. 코드 TODO에 Write Behind 검토가 있어, 실시간 카운터 정확도보다 응답 속도를 우선한 현재 선택임을 드러냅니다.

실시간 HTTP와 긴 LLM·ETL 작업을 분리하기 위해 NestJS API와 Kafka consumer, Redis Stream SSE, ETL 워커로 역할을 나눴습니다.

클라이언트가 챗봇에 요청하면 API가 Kafka 메시지를 만들고, Consumer가 OpenAI·Vector DB Tool Call 후 Redis Stream으로 청크를 흘리면 API가 SSE로 전달합니다.