전체 요약

제품 그룹 요약 — 사람이 오는 것(유입)과 남는 것(잔존)과 드는 것(비용)을 한 화면에. 각 칸의 자세한 값은 해당 탭에 있다.
⚠️ 유입과 잔존은 대응이 정반대다 — 유입 O·잔존 X 는 제품을 고치는 일이고, 유입 X·잔존 O 는 마케팅을 넣는 일이다. 그래서 떼어 놓지 않는다.

한눈에 — Render 서비스 · Oracle 인스턴스 · 무료 티어 용량 · 수집 크론을 같은 임계값으로 판정한 것이다. 값 자체는 각각 인프라 · 용량 · 유입 탭이 이미 갖고 있고, 여기서는 줄 세우기만 한다 (같은 값을 두 곳에서 계산하면 두 화면이 서로 다른 말을 하게 된다).
⚠️ "정상" 은 "확인했다" 가 아니다. Render 의 live 는 기동 성공일 뿐이라 /health 를 못 보면 확인 불가로 따로 센다. 못 잼 칸이 그 자리다 — 0 으로 세면 없는 안심이 생긴다.

Render Web Service 로 옮긴 상시 작업(수집기·크롤러)의 상태. 배포는 정상이어도 앱 루프가 죽어있을 수 있어(OOM 등) Render 배포 상태와 서비스 자체 /health 를 같이 본다. CPU/메모리는 Render Metrics API 값(최근 1시간, 5분 해상도)을 10분 크론이 적재한 것이라 실시간은 아니다 — 한도(limit) 대비 최대치 %로 여유를 본다.
이름 옆 배지가 어느 Render 계정인지다(render1·render2). 무료 750h/월이 워크스페이스 단위이고 워크스페이스는 계정당 5개가 상한이라 neomeo 크롤러가 두 계정에 나뉘어 있다(render1 4대 · render2 5대 = 9대). ⚠️ API 키는 계정 단위라 키가 없는 계정의 서비스는 이 목록에 아예 안 나온다 — 에러가 아니라서 "9대 중 4대만 보이는" 걸 눈치챌 수 없다. 대수가 모자라면 RENDER2_API_KEY 시크릿부터 확인할 것.

OVH 익명 LLM — 호스트별 성적
OVH 는 IP × 모델로 제한해서 서비스마다 버킷이 따로다. 그런데 번역 행에는 호스트가 안 적혀 DB 집계로는 어느 리전이 실제로 먹히는지 알 수 없다 — 각 호스트가 DB(ovh_host_stats)에 직접 적은 값이다. 이름 옆 배지가 어디서 나간 호출인지다: Render(리전 = egress IP) · Oracle VM(인스턴스 · 공인 IP) · Supabase Edge. Oracle 이 두 행인 건 VM 이 둘이라서가 아니라 한 VM 에 공인 IP 가 둘(primary · 10.0.1.236)이라서다 — OVH 제한의 단위가 IP 라 IP 마다 따로 센다. 성공률이 낮다고 고장난 게 아니다(정상일 때도 2~19%). 쓰임새는 절대값이 아니라 호스트 간 비교다. 429 는 제공처가 막은 것이고 오류는 우리가 깨진 것이라 대응이 다르다.
⚠️ 누적 기준은 "오늘"이 아니라 각 행의 '집계 시작'이다 — 집계 파일이 /tmp라 배포·재시작하면 리셋된다. 배포 직후의 0 을 "죽었다"로 읽지 말 것.

번역 품질 — 무엇이 나왔나 (neomeo). 위 표가 "어느 호스트가 호출했나" 라면 이건 그 결과물이다. 게이트는 LLM 감사가 아니라 결정론적 결함 검사다 (cjk 한자 유입 · kana 가나 · broken_word 깨진 단어 · collapse 반복 붕괴) — 무료·전수라서 쓸 수 있다. 감사(LLM)는 게이트가 아니라 추세 계기판이다: OVH 가 모델당 2 RPM 이라 하루 40건 표본이 한계고, 판정자도 번역자와 같은 급의 무료 모델이라 오판이 섞인다.
재번역 세 칸을 이렇게 읽는다 — 대기는 결함인데 아직 안 돌린 것(미번역 백로그가 먼저라 그 뒤에 처리된다. 많다고 고장이 아니다), 포기는 상한까지 돌렸는데 안 나아서 더 시도하지 않는 것, 성공은 돌려서 나은 누적이다. ⚠️ 성공은 2026-09-10 부터 센다 — 그전엔 "나으면 카운터가 0 으로 리셋" 되는 구조라 (상한을 되돌려 주려고 일부러 그렇게 했다) 성공을 셀 방법이 아예 없었다.
대기 시간이 두 칸인 이유: 끝난 것이 걸린 시간과 지금 기다리는 것이 이미 기다린 시간은 다른 수다. 백로그 4,000건이 1시간 기다린 것과 3일 기다린 것은 전혀 다른 상황이고, 후자는 그동안 앱에 영어로 뜬다는 뜻이다 — 제품 가치가 번역이라 이게 곧 제품 지표다. 번역 속도에는 재번역이 섞여 있어 백로그 순감소보다 낙관적이다.
⚠️ 정본 배지를 볼 것. 집계를 뜬 DB 다(컷오버 전 supabase → 후 oracle). 옆의 시각은 그 DB 가 본 마지막 변경이라, 멈춰 있으면 값이 오래된 것이다.

A1(ARM) 인스턴스 사냥 — Oracle Always Free ARM(2 OCPU·12GB)이 하나 더 나오길 노리는 배치. us-ashburn-1 은 경쟁이 심해 Out of host capacity 가 정상이고, 시도가 많다고 고장난 게 아니다. "용량부족"은 기다리는 것 말고 답이 없지만 "한도벽"(LimitExceeded)은 다른 사냥과 경합 중이란 뜻이라 원인을 없앨 수 있다. 확보되면 captured_at 이 채워지고 그 즉시 keepalive 가 자동으로 붙는다 (cloud-init) — 이 표가 비어 있으면(마지막 시도가 오래전) 사냥 자체가 안 도는 것이니 확인이 필요하다.

Oracle Always Free 인스턴스 전부 — OCI Monitoring(oci_computeagent) 값을 10분 크론이 적재한 캐시라 실시간은 아니다. Orient VM 은 자체 /v1/metrics 도 있어 부하 1/5/15분·디스크가 더 붙는다.
회수 기준(Oracle 문서): 7일 동안 CPU 95퍼센타일 < 20% 이고 네트워크 < 20% 이고 (A1 shape 만) 메모리 < 20% 이면 idle 로 보고 회수할 수 있다. 전부 미만이어야 idle 이라 하나라도 넘으면 안전이다. 95퍼센타일은 5분 평균으로 근사하고 네트워크 분모는 shape 대역폭(E2.1.Micro 480 Mbps)이다 — 둘 다 Oracle 이 어떻게 재는지는 문서에 없어 확실하지 않음. 표본이 168시간을 못 채우면(새 인스턴스) 7일 기준이 아직 아니다.

수집 → 정본 → 투영 → 앱 이 실제로 흐르고 있나. 끊길 수 있는 지점이 셋이고 신호가 각각 다르다 — 크롤러(회차 실패) · 동기화(타이머 침묵) · 번역(백로그 증가).
⚠️ 동기화 행은 성공했을 때만 갱신된다. 그래서 마지막 성공이 오래됐다 = 실패 중이다.

벽이 어디에 있나 — 전부 무료 티어라 돈이 아니라 한도가 벽이다. 막대는 각 자원의 한도 대비 비율이고 한도는 저마다 다르다. ⚠️ Supabase 는 사용량을 API 로 안 줘서(대시보드 전용) 이 값은 동기화가 DB 안에서 직접 잰 것이다.

양쪽에 뭐가 들어 있나 — 행 수는 거의 같은데 용량이 몇 배 차이다. 그 차이가 전부 영어 원문이다(앱은 한국어 번역만 읽는다).

얼마나 처리하나 — 번역이 이 제품의 값이고 그걸 굽는 건 무료 LLM 한도다. 호스트별 성적은 인프라 탭에 있다.

크롤러 9대 — 누가 무엇을 쓰나
제공처 한도는 계정 단위다. 같은 키를 여러 대에 넣으면 총량은 그대로고 429 만 는다 — 그래서 어느 인스턴스가 어떤 키를 갖고 있나가 곧 배치 설계다. 이 배지는 문서가 아니라 Render 환경변수를 실제로 읽은 값이다 (키 이름만 읽는다 — 값은 읽지 않는다).
⚠️ OVH 는 IP × 모델 제한이라 인스턴스마다 버킷이 따로고, 그래서 호스트별 실사용을 잴 수 있는 유일한 제공처다. 나머지(OpenRouter·Cloudflare· Gemini)는 행에 호스트가 안 적혀 인스턴스별 사용량을 알 수 없다 — 가진 키와 계정 총량으로만 읽는다.

컷오버 진행도 — 2026-09-11 에 DB 를 정본·투영으로 나눈 작업. ⑤ 가 되돌릴 수 없는 지점이었다. ⚠️ 박아 둔 체크가 아니라 살아 있는 값으로 판정한다 — 문서에 "완료" 라고 적어 두면 되돌아가도 화면은 계속 완료라고 말한다.

두 제품을 같은 축에 놓고 글로 본다. 각 탭의 도식은 그 제품 안에서만 읽히는데, 둘은 같은 부품(OVH 체인 · Oracle · Supabase · Render)을 쓰면서 흐르는 방향이 반대다 — 그 대조는 도식 둘을 번갈아 봐서는 안 보인다.

해외 식품안전 당국 18곳의 리콜을 긁어 한국어로 파싱하고, 국내 수입업체 8만여 건과 대조해 걸리는 것만 알린다.
⚠️ 이 제품의 사고는 거의 전부 “에러가 안 보여서” 생겼다 — Render OOM 은 커널이 죽여 예외가 안 돌고, 껍데기 응답은 parsed_at 이 찍혀 재시도 대상에서 영구히 빠진다. 그래서 이 탭은 성공 건수가 아니라 멈춘 자리를 본다.

파싱 품질·백로그 — 미파싱은 이번 시간 시도 소진 과 나눠 본다. 대응이 다르다(기다린다 vs 고친다). ⚠️ "소진" 은 영구 포기가 아니다 — parse_attempts 는 매시 :02 에 리셋되므로 이 숫자는 이번 시간치다. 부하가 있으면 시간 끝 무렵에 정상적으로 오르고 :02 에 저절로 0 이 된다. 매 시간 차 있을 때만 고칠 일이다.

LLM 호출 성적 — OVH(무인증) → Cloudflare → OpenRouter 순 (희소한 축을 마지막에). 호출 위치가 곧 OVH 버킷이다 — OVH 는 IP × 모델 로 제한해서 IP 가 다르면 한도가 하나 더 생긴다. ⚠️ 반대로 Cloudflare·OpenRouter 는 계정 단위라 호출 위치를 늘려도 총량이 안 는다. (2026-09-11 확인: 이 셋은 neomeo 와 다른 계정이다 — 종전에 여기 "같은 계정을 공유한다" 고 적혀 있었는데 틀렸다. 값을 대조해 확인했다.)

용량 — ⚠️ 이 Supabase 프로젝트는 공유 호스트다. Canary 말고도 여러 앱이 같은 500MB 를 나눠 쓴다.

전부 무료 티어라 돈이 아니라 한도가 벽이다. 여유가 적은 순으로 정렬한다.
⚠️ Supabase 는 사용량을 API 로 안 준다(대시보드 전용) — 그래서 이 값은 프로젝트마다 db_size_snapshot() 을 두고 DB 안에서 직접 잰 것이다. 함수가 없는 프로젝트는 목록에서 조용히 빠진다.

못 재는 것 — 없는 값을 빈칸으로 두면 0 으로 읽힌다. 어디서 봐야 하는지 적는다.

Supabase — 어느 앱이 어느 프로젝트에 얹혀 있나
무료 500MB 는 프로젝트 단위다. 한 프로젝트에 여러 앱이 있으면 그 앱들이 같은 500MB 를 나눠 쓴다 — 하나가 커지면 나머지가 같이 위험해진다.

Render — 서비스가 어느 계정·리전에 있나
무료 750h/월은 워크스페이스 단위이고 워크스페이스는 계정당 5개가 상한이다.
⚠️ 어느 앱 것인지는 API 가 말해주지 않는다 — 이름으로 추정한다. 매칭이 안 되면 “미분류”로 남긴다(틀린 귀속보다 낫다).

Oracle — 인스턴스
⚠️ 지표 API 는 이름을 주지 않는다(OCID·shape·AD 뿐). 사람이 읽는 이름은 수동 라벨이라 여기서는 OCID 꼬리로 낸다 — 지어내지 않는다.