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

1. 왜 정량화가 필요한가

앞서 진행한 신한라이프 비교는 무작위 10건을 손으로 골라 원문을 나란히 대조하는 방식이었다 — 결과는 신뢰할 만했지만, 표본을 바꾸거나 새 경쟁사를 추가할 때마다 처음부터 다시 해야 했다. 이번 시스템은 그 작업을 재사용 가능한 도구로 만드는 것이 목표다: 같은 표본 세트를 어떤 서비스에든 동일하게 돌리고, "낫다/못하다"를 사람의 인상이 아니라 측정 가능한 숫자로 뽑아낸다. 광고에 특정 서비스명을 못 쓰더라도("업계 평균 대비"처럼 실명 없는 비교는 가능), 내부적으로 "우리가 어디서 강하고 어디서 부족한지"를 계속 추적할 수 있어야 한다는 게 이 시스템의 존재 이유다.

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

①은 필요조건(틀리면 나머지가 무의미), ②~⑤는 콘텐츠 품질, ⑥~⑦은 신뢰 태도를 본다. 네 그룹으로 나눈 이유는 서비스마다 강점이 다를 수 있기 때문이다 — 예컨대 분량은 짧아도 구체성·근거제시가 높은 서비스가 있을 수 있고, 그런 경우 "한 줄 요약" 대신 4개 그룹별 점수를 따로 보여주는 게 정확하다.

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

서비스마다 입력 폼과 결과 페이지 구조가 전부 달라서, 공통 인터페이스 하나로 통일하고 서비스별 차이는 "어댑터" 파일 안에 가둔다.

scripts/saju-benchmark/
  test-cases.mjs        표본 10건(성별·시진·연대 분산 + 절기 경계일 케이스)
  metrics.mjs            7개 지표 (순수 함수)
  adapters/
    ours.mjs              브라우저 불필요 — 엔진 직접 호출
    shinhan.mjs            Playwright 자동화 (검증 완료)
    jeomsin.mjs             Playwright 자동화 (부분)
    sajuai.mjs               자동화 불가 스텁(로그인 벽)
  run-benchmark.mjs      오케스트레이터 — 어댑터×표본을 돌리고 지표 계산, JSON 저장

모든 어댑터는 같은 모양의 결과를 반환한다:

{ serviceId, pillars: {year,month,day,hour}, categories: [{name, text}], rawText, meta }

새 서비스를 추가하려면 이 인터페이스를 구현하는 파일 하나만 adapters/에 넣고 오케스트레이터에 등록하면 된다 — 지표 계산·교차검증·JSON 출력 로직은 손댈 필요 없다.

4. 서비스별 자동화 현황

5. 파일럿 실행 결과 — 시스템 검증

실제 다수 서비스 비교는 별도로 진행하기로 했지만("나중에 여러 사주들 비교"), 시스템 자체가 제대로 작동하는지는 최소 표본으로 확인해뒀다 — 1990-05-15 양력 남성 오시 케이스를 우리 엔진과 신한라이프 양쪽에 실제로 돌렸다.

이 결과는 기존 신한라이프 수작업 비교 리포트의 동일 케이스와도 일치한다 — 즉 이 자동화 시스템이 손으로 했던 검증을 정확히 재현한다는 것까지 확인됐다.

6. 알려진 한계