별자리 서비스 정량 평가 벤치마크 시스템

Executive Summary

기준값(ground truth)이 우리 제품이 아니라 표준 경계일표다 — 별자리 캐논 3~4장에서 WebSearch로 교차검증한 트로피컬 조디악 표준 경계일 표(sunsign.mjs)를 순수 함수로 구현해 기준선으로 쓴다.
6개 지표로 콘텐츠 품질을 잰다 — 사주 벤치마크의 7개 지표에서 "개인화" 지표를 처음부터 빼고(사주 쪽 벤치마크에서 이미 폐기 결정이 난 것과 같은 이유), 대신 ⑥ groundedAccuracySunSign으로 "그 서비스가 명시한 태양별자리가 실제로 맞는지"를 직접 검증한다.
서비스 4곳 중 진짜 "계산"을 하는 곳은 1곳뿐이다 — 아이돌사주·포춘에이드(오늘의 운세)는 사용자가 별자리를 직접 골라 들어가는 구조라 생년월일→별자리 계산 자체가 없다. 포춘에이드의 "나의 점성술 차트"만 유일하게 생년월일·시각·출생지로 진짜 네이탈차트(천체 10개×하우스×별자리·도수, 트랜짓까지)를 계산해준다.
컵스프(별자리 경계일) 케이스에서 실제로 흥미로운 결과가 나왔다 — §5 참고. 표준 경계일표와 실제 정밀 계산 엔진이 갈리는 사례를 직접 관측했다.
2026-07-24 업데이트: 우리 꽉이 말투 샘플을 추가해 4곳 비교로 확장했다. 기존 룰베이스 패턴(오늘의 운세 시드 유틸 + SOUL_NUMBER_INFO류 사전)만으로 만든 데모이며, 비교 과정에서 조사 오류·근거제시 지표 0점 등 실제 결함을 찾아 고쳤다 — 자세한 내용은 비교 리포트 §7 참고.

1. 왜 사주와 다른 구도인가

사주 벤치마크는 "우리 엔진(src/manseryeok.js, 이미 3중 검증 완료)을 기준선 삼아 경쟁사와 대조"하는 구도였다. 이 프로젝트엔 아직 별자리 제품 기능이 없어서 같은 구도를 쓸 수 없다 — 대신 별자리 캐논 제작 과정에서 WebSearch로 교차검증해둔 표준 트로피컬 조디악 경계일표를 순수 계산 함수(sunsign.mjs)로 구현해 기준선으로 쓴다. 이건 "우리 제품이 얼마나 정확한지"가 아니라 "실제 서비스들이 표준적인 천문 계산과 얼마나 맞아떨어지는지, 그리고 콘텐츠 품질은 어떤지"를 보는 순수 경쟁 조사 벤치마크다.

2. 6개 평가 지표 — 무엇을, 왜, 어떻게

Exhibit 1. 평가 지표 전체

#	지표	왜 중요한가	측정 방법
①	콘텐츠 밀도 `volumeMetrics`	"짧고 뻔한 얘기"와 "깊이 파고든 얘기"를 가르는 가장 기초적인 신호.	카테고리별 글자수(공백 제외)와 카테고리 개수.
②	구체성 `specificityScore`	"좋은 일이 생길 거예요" 같은 뜬구름 문장과 콕 집은 문장은 체감 품질이 다르다.	"20XX년"·"OO세"·"O월"·"N%" 같은 구체적 숫자 표현의 등장 횟수를 글자수 대비 밀도로 정규화.
③	근거 제시 `groundednessScore`	결과가 "그냥 그렇대요"가 아니라 점성술 이론에 근거하는지.	원소·모달리티·하우스·어스펙트·트랜짓 등 별자리 캐논 용어 사전과 대조해 등장 횟수 카운트.
④	정직성 신호 `honestySignal`	"재미로만 봐" 같은 불확실성 인정 표현이 있으면 오히려 신뢰할 만하다 — 별자리 캐논 11장(통념 검증)의 정직성 원칙과 같은 맥락.	불확실성 인정 표현 6종의 등장 여부(있으면 가점, 페널티 아님).
⑤	쉬운 설명 `explainabilityScore`	전문용어를 아는 것과 그걸 쉽게 설명해주는 것은 다른 축이다.	점성술 용어가 등장할 때 그 주변 60자 안에 비유·풀이 표현이 같이 나오는 비율.
⑥	근본 정확성 `groundedAccuracySunSign`	"그 서비스가 명시한 태양별자리가 실제로 맞는지"를 직접 검증 — 사주 벤치마크의 `groundedAccuracyDayMaster`와 동일한 발상.	어댑터가 직접 파싱한 태양별자리(claimedSign)를 `sunsign.mjs` 기준값과 대조. 단, 생년월일 계산 없이 사용자가 별자리를 직접 고르는 서비스는 이 검증이 애초에 트리비얼하다(§4 참고).

구현: scripts/astrology-benchmark/metrics.mjs — 전부 순수 함수. 사주 벤치마크의 "개인화" 지표(폐기됨)는 처음부터 만들지 않았다 — "같은 별자리=같은 결과가 정답"인 도메인에서 서로 다른 별자리 리포트가 다르다는 게 품질 지표가 아니라는 걸 사주 쪽에서 이미 배웠기 때문.

3. 시스템 구조 — 어댑터 패턴

scripts/astrology-benchmark/
  test-cases.mjs         표본 15건(12별자리 전부 + 컵스프 3건)
  sunsign.mjs             표준 경계일표 순수 계산 함수(기준값)
  metrics.mjs              6개 지표 (순수 함수)
  adapters/
    ours.mjs                브라우저 불필요 — sunsign.mjs 직접 호출(기준값)
    idolsaju.mjs             fetch만 사용(Playwright 불필요) — 완전 서버렌더링
    fortunade-daily.mjs       fetch만 사용 — 12별자리 전체가 한 페이지에 이미 존재
    fortunade-natal.mjs       Playwright 필요 — 진짜 네이탈차트 계산 서비스
  run-benchmark.mjs        오케스트레이터 — 어댑터×표본을 돌리고 지표 계산, JSON 저장

모든 어댑터는 같은 모양의 결과를 반환한다: { serviceId, sunSign, categories: [{name, text}], meta }. 새 서비스를 추가하려면 이 인터페이스를 구현하는 파일 하나만 adapters/에 넣고 오케스트레이터에 등록하면 된다.

4. 서비스별 자동화 현황

Exhibit 2. 2026-07-24 기준 서비스 커버리지(4곳 자동화, 조사만 한 후보는 README 참고)

서비스	상태	비고
기준값(ours)	완전 자동화	브라우저 불필요 — 표준 경계일표 직접 계산
아이돌사주(idolsaju)	완전 자동화	fetch만 사용, 완전 서버렌더링. 생년월일→별자리 계산이 없다(사용자가 URL로 별자리를 직접 고름) — groundedAccuracy는 트리비얼하게 항상 일치, 콘텐츠 품질 지표가 핵심
포춘에이드 오늘의 운세(fortunade-daily)	완전 자동화	fetch만 사용, 12별자리 전체가 한 페이지 HTML에 이미 존재(CSS로 11개 숨김). idolsaju와 마찬가지로 계산 없음
포춘에이드 나의 점성술 차트(fortunade-natal)	완전 자동화	Playwright 필요. 이 벤치마크에서 유일하게 진짜 계산을 하는 서비스 — 생년월일·시각·출생지(시/도)를 받아 천체 10개×하우스×별자리·도수(네이탈+트랜짓)를 산출. 처음엔 "운세보기" 클릭이 결과화면 대신 카테고리 메뉴로 튕겨나가는 것처럼 보였으나, 원인은 광고 게이트가 아니라 모바일 뷰포트에서 제출 버튼이 "visible" 판정을 못 받아 클릭이 실패한 것이었다 — 폼을 직접 제출(`form.submit()`)하니 정상 도달함(자세한 경위는 파일 주석 참고)

조사만 하고 자동화하지 않은 후보(점신 별자리 탭, Funsoft, 네이트 운세 등)와 자동화 자체가 불가능한 서비스(헬로우봇=앱 전용, 포스텔러=유료 상품)는 scripts/astrology-benchmark/README.md에 근거와 함께 기록해뒀다.

5. 컵스프 케이스 — 표준표와 실제 계산이 갈린 사례

표본 15건 중 3건(Z13·Z14·Z15)은 별자리 경계일(cusp) — 표준 경계일표로는 한쪽 별자리이지만 지구 공전주기가 365.25일이라 실제 경계 시각은 연도마다 최대 하루 정도 흔들린다는, 별자리 캐논 3~4장에서 이미 밝힌 현상을 실제로 관측할 수 있는지 보려고 의도적으로 넣은 케이스다.

Exhibit 3. 컵스프 케이스 실행 결과

케이스	날짜	표준표 기준값	아이돌사주/포춘에이드(계산없음)	포춘에이드 네이탈차트(진짜 계산)
Z13	1990-03-21	양자리	일치(자동)	양자리 — 일치
Z14	1990-07-22	게자리	일치(자동)	게자리 — 일치
Z15	1990-11-22	사수자리	일치(자동)	전갈자리 — 불일치

"아이돌사주/포춘에이드(계산없음)" 열이 "일치(자동)"인 이유는 이 두 서비스가 애초에 생년월일로 별자리를 계산하지 않고 우리가 고른 별자리를 그대로 보여주기 때문 — 이 열은 참고용일 뿐 실제 검증이 아니다.

이건 "서비스 오류"가 아니라 컵스프 현상의 실제 증거다. 표준 경계일표는 11/22를 사수자리 시작일로 잡지만, 진짜 정밀 계산 엔진(포춘에이드 네이탈차트, 실제 천체력 기반으로 추정)은 1990년 11월 22일 당시 태양이 아직 전갈자리 영역에 있었다고 계산했다 — 별자리 캐논이 이론으로만 서술했던 "경계 시각은 연도마다 최대 하루 흔들린다"는 걸 실측으로 확인한 사례다. 우리 표준표(sunsign.mjs)가 "틀렸다"기보다, 애초에 연도 보정 없는 근사치라는 한계가 정확히 이 지점에서 드러난 것으로 해석해야 한다.

6. 알려진 한계

표준 경계일표는 연도별 정밀 보정이 없다 — §5에서 확인했듯 컵스프 근처에서는 실제 계산과 갈릴 수 있다. 사주 벤치마크가 KASI 절기 데이터로 3중 검증한 것과 같은 수준의 정밀도는 아니다.
4곳 중 2곳은 애초에 "계산"을 안 한다 — 아이돌사주·포춘에이드(오늘의 운세)는 사용자가 별자리를 직접 고르는 구조라 groundedAccuracy 검증이 트리비얼하다. 콘텐츠 품질 지표(①~⑤)만 의미 있게 비교 가능하다.
표본 규모가 사주 벤치마크(29곳)보다 훨씬 작다 — 이 리포트는 사주 벤치마크가 4곳으로 시작해 29곳까지 확장된 것과 같은 "파일럿" 단계다. 자동화 후보 3곳(점신·Funsoft·네이트)이 README에 조사만 된 채 남아있다.
달별자리·어센던트 계산은 검증하지 않는다 — 포춘에이드 네이탈차트가 달별자리·상승궁까지 계산해주지만, 이 벤치마크는 태양별자리만 기준값과 대조한다. 정밀 천체력 라이브러리를 직접 구축하지 않는 이상 달·어센던트의 "정답"을 독립적으로 검증할 방법이 없기 때문이다.
"근거 제시"·"쉬운 설명" 지표는 프록시(proxy)다 — 사주 벤치마크와 동일한 한계. 특정 용어의 등장 여부만 카운트하며, 실제 논리적 타당성까지는 못 본다.

관련 자료
별자리 서비스 비교 결과(4곳 실측, 파일럿)
사주 서비스 벤치마크 방법론(같은 설계 원칙)
별자리 이론 캐논(기준값의 근거)
scripts/astrology-benchmark/ — 시스템 코드 및 README

🐥 별자리 서비스 정량 평가 벤치마크 시스템 — 무엇을, 왜 이렇게 측정하는가