사주 룰 + AI 해석 하이브리드: AI 단독 해석이 실패하는 지점

2026.02.17 - [개발] - 사주 앱 개발 4편 - 룰 엔진 + AI 해석 하이브리드 설계

 

사주 룰 + AI 해석 하이브리드 설계과정에  대한 좀 상세한 분석이다

 

 

 

AI가 생성한 사주 해석을 처음 봤을 때, 솔직히 꽤 그럴듯했다.

문장은 자연스럽고, 명리학 용어도 적절히 섞였고, 읽는 사람 입장에서 거부감이 없었다. "이걸로 가도 되겠는데?"라고 생각한 게 30분이었다. 그 다음 30분 동안 같은 생년월일을 다섯 번 더 넣어봤다.

결과가 매번 조금씩 달랐다.

---

실패 유형 1: 계산 오류를 해석처럼 포장한다

가장 심각한 유형이다. AI가 사주 계산을 내부적으로 처리할 때 오류가 나도, 해석 문장은 자신감 있게 나온다.

절기 경계 날짜가 대표적이다. 입춘(立春)은 매년 2월 4일 전후인데, 정확한 시각은 해마다 다르다. 2월 4일 오전 11시 14분이 입춘이라면 그 전에 태어난 사람은 월지가 丑(소), 이후는 寅(호랑이)이 된다. 월지가 바뀌면 십신 배치가 통째로 달라진다.

같은 생년월일을 반복 입력했을 때 일주가 다르게 나온 케이스가 바로 이 절기 경계 근처였다. AI는 절기 시각을 분 단위로 정확히 알지 못하거나, 매 호출마다 다르게 처리한다. 그런데 출력 문장은 "당신의 일주는 甲子로, 지혜롭고 창의적인 성향을 가집니다"처럼 단호하게 나온다.

틀렸는데 확신에 차 있다. 이게 사주에서 할루시네이션이 위험한 이유다.

---

실패 유형 2: 근거 없는 십신 해석

"편재가 강하므로 재물 감각이 뛰어납니다"라는 문장이 나왔다. 실제로 그 사주에 편재가 몇 개인지 확인해봤다. 편재가 없었다. 식신과 상관이 강한 구조였는데, AI가 재물 관련 해석을 자연스럽게 붙이면서 편재를 끌어들인 것이다.

명리학에서 십신은 일간 기준의 상대적 관계다. 이걸 정확히 계산하려면 각 기둥의 천간과 지지를 일간과 음양오행 관계로 대조해야 한다. AI는 이 계산을 내부에서 하는 척하지만, 검증할 방법이 없다.

더 문제인 건 해석 문장이 그럴듯하다 보니 사용자가 틀린 줄 모른다는 것이다. "편재가 강하다"는 말을 듣고 "맞아, 나 돈에 관심 많잖아"라고 자기 확증을 하게 된다. 틀린 데이터 위에 맞는 감정이 덮인다.

---

실패 유형 3: 재현성 없는 해석

같은 사주를 두 번 물었을 때 해석의 방향이 달라지는 경우가 있다. 한 번은 "리더십이 강한 편관 구조"로 해석했다가, 다음번엔 "안정을 추구하는 인성 중심"으로 나오는 식이다.

둘 다 틀리지 않을 수 있다. 사주 해석은 보는 각도에 따라 달라지기도 하니까. 문제는 서비스 신뢰성이다. 같은 사람이 오늘 본 결과와 내일 본 결과가 다르면, 사용자 입장에서 이 서비스를 어떻게 믿겠는가.

룰 엔진 없이 AI 단독으로 가면 이 문제를 해결할 수 없다. 계산 결과가 매번 고정되지 않으니 해석도 흔들린다.

---

실패 유형 4: 운명론적 단정

초기 실험에서 나온 문장 중에 이런 게 있었다.

"당신은 평생 재물운이 약합니다. 사업보다는 직장 생활이 맞습니다."

명리학 전통에서 이런 식의 단정은 윤리적으로도 문제가 있고, 현대 서비스에서 법적 리스크가 될 수도 있다. 지시를 명확히 주지 않으면 AI는 독자가 강한 확신을 원한다고 판단하고 단정적인 문장을 생성한다.

시스템 프롬프트에 "운명론적 단정이 아닌 경향과 가능성으로 설명할 것"을 명시하고 나서야 이 문제가 잡혔다. 단, 지시가 없으면 언제든 돌아온다. 방어 설계가 필요하다.

---

그래서 어떻게 막았는가

AI 단독 해석의 실패 유형들은 공통된 원인에서 나온다. AI가 계산과 해석을 동시에 하려 할 때 문제가 생긴다.

하이브리드 구조에서는 이 책임을 분리한다.

 

 

룰 엔진 → 계산된 구조 데이터 (JSON)
         ↓
AI      → 데이터를 받아서 "해석"만 수행

AI에게 넘기는 프롬프트에는 이미 검증된 결과만 들어간다.

 

 

json

{
  "pillars": {
    "year":  { "stem": "甲", "branch": "子" },
    "month": { "stem": "丙", "branch": "寅" },
    "day":   { "stem": "庚", "branch": "午" },
    "hour":  { "stem": "甲", "branch": "子" }
  },
  "dayMaster": "庚",
  "tenGods": {
    "year_stem": "편재",
    "month_stem": "관성",
    "hour_stem": "편재"
  },
  "elementRatio": {
    "木": 30, "火": 25, "土": 10, "金": 20, "水": 15
  },
  "yongsin": "火",
  "conflicts": ["午子 충"]
}

시스템 프롬프트의 핵심 제약:

 

 

- 제공된 분석 데이터를 기반으로만 해석할 것
- 데이터에 없는 내용을 추론하거나 추가하지 말 것
- 운명론적 단정이 아닌 경향과 가능성으로 표현할 것
- 수치와 배치는 이미 계산된 값을 그대로 인용할 것

이 구조에서 AI는 "편재가 강하다"고 임의로 판단할 수 없다. 프롬프트에 편재 개수와 위치가 이미 명시되어 있고, AI는 그것을 해석하는 역할만 한다. 할루시네이션이 파고들 공간이 좁아진다.

완전히 막을 수는 없다. AI는 여전히 해석 과정에서 과장하거나 없는 연결고리를 만들 수 있다. 하지만 계산 단계의 오류는 구조적으로 차단된다.

---

정리

실패 유형원인하이브리드 방어

절기 계산 오류	AI 내부 계산 불확실	룰 엔진이 계산, 결과만 전달
근거 없는 십신 해석	십신 배치를 AI가 임의 판단	십신 배치를 데이터로 명시
재현성 없는 해석	매 호출마다 다른 계산 결과	계산 결과 고정, 해석만 생성
운명론적 단정	지시 없으면 단정 문장 생성	시스템 프롬프트에 명시적 제약

AI를 쓸 때 "잘 써달라"는 지시보다 "이것만 해달라"는 제약이 더 효과적인 이유가 여기 있다.

---

다음 편에서는 경계 설계를 구체적으로 다룬다. 계산과 해석의 경계가 모호한 케이스들 — 용신 판단은 룰인가 AI인가, 합충의 강도 판단은 누가 하는가 — 실제 설계에서 어떻게 결론을 냈는지.