사주 룰 + AI 해석 하이브리드: 이 설계, 사주 말고 어디까지 쓸 수 있나

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

 

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

 

 

6편을 쓰면서 문득 이런 생각이 들었다.

이 구조가 사주라서 동작하는 건가, 아니면 사주이기 때문에 특히 잘 맞는 구조인가.

결론부터 말하면 후자다. "복잡한 도메인 지식 + 해석이 필요한 출력"이라는 조건만 맞으면 이 설계는 그대로 옮겨 쓸 수 있다. 사주는 그 조건이 극단적으로 잘 맞는 도메인이었을 뿐이다.

---

이 설계의 본질

6편에 걸쳐 구현한 것을 추상화하면 이렇다.

 

 

[도메인 특화 룰 엔진]
복잡한 계산, 규칙 기반 분류, 재현성이 필요한 모든 것
        ↓
[구조화된 컨텍스트]
AI에게 넘길 검증된 데이터 패키지
        ↓
[도메인 참조 데이터]
해석 품질을 올리는 전문 지식 (궁통보감 역할)
        ↓
[LLM 해석 레이어]
데이터를 사람의 언어로 변환

핵심은 AI가 계산하지 않는다는 것이다. AI는 이미 계산된 결과를 받아서 설명한다. 이 분리가 신뢰성과 해석 품질을 동시에 잡는다.

---

이 구조가 맞는 도메인들

법률 문서 검토

법률에는 명확한 규칙이 있다. 계약서에 특정 조항이 있는지 없는지, 위약금 조건이 어떻게 설정됐는지, 관련 법령이 무엇인지는 규칙 기반으로 추출 가능하다.

하지만 "이 계약서가 갑에게 불리한가"는 해석이다. 조항 간의 상호작용, 업계 관행과의 비교, 분쟁 발생 시 어떻게 읽힐지는 AI가 잘하는 영역이다.

 

 

룰 엔진: 조항 추출, 키워드 분류, 법령 매핑
참조 데이터: 판례, 업계 표준 계약 조건
AI: "이 계약은 어떤 위험이 있는가"

의료 증상 분석 보조

증상 조합에서 가능성 있는 진단 리스트를 뽑는 것은 규칙 기반으로 가능하다. ICD 코드 매핑, 약물 상호작용 체크, 금기 사항 확인도 룰 엔진이 할 수 있다.

AI가 "이 환자에게 어떻게 설명할 것인가"를 맡는다. 의학 용어를 일상 언어로, 복잡한 복약 지침을 이해하기 쉬운 문장으로.

물론 이 영역은 규제와 책임 문제가 크다. 진단 보조가 아닌 설명 생성 레이어로만 쓰는 것이 현실적이다.

 

 

룰 엔진: 증상-질환 매핑, 약물 상호작용, 금기 체크
참조 데이터: 진료 가이드라인, 설명 템플릿
AI: "환자가 이해할 수 있는 설명 생성"

금융 리포트 생성

주가, 재무제표, 밸류에이션 계산은 수치다. 계산 자체는 코드로 완벽히 처리된다. ROE, PER, 부채비율이 무엇인지는 숫자가 말한다.

"이 회사에 지금 투자해야 하는가"는 해석이다. 수치들의 조합이 무엇을 의미하는지, 업종 평균과 비교했을 때 어떤지, 리스크 요인은 무엇인지.

 

 

룰 엔진: 재무 지표 계산, 업종 평균 비교, 이상 수치 플래깅
참조 데이터: 업종별 벤치마크, 분석 프레임워크
AI: "이 수치가 의미하는 것은 무엇인가"

코드 리뷰 자동화

린트, 정적 분석, 테스트 커버리지, 복잡도 측정은 전부 룰 기반이다. 코드가 규칙을 위반했는지 아닌지는 도구가 이미 잘 잡는다.

"이 PR이 왜 문제인지, 어떻게 개선해야 하는지"를 팀원이 이해할 수 있는 언어로 설명하는 건 AI가 잘한다. 경고 코드를 뱉는 것과 "이 패턴이 런타임에서 왜 문제가 되는지"를 설명하는 건 다른 일이다.

 

 

룰 엔진: 정적 분석, 린트, 보안 취약점 스캔
참조 데이터: 팀 코딩 컨벤션, 자주 발생하는 패턴
AI: "개발자가 이해하고 수정할 수 있는 리뷰 코멘트 생성"

---

공통 패턴과 적용 조건

이 구조가 잘 맞는 도메인의 공통점:

1. 정답이 있는 계산 레이어가 존재한다 사주의 기둥 계산, 법률의 조항 추출, 재무의 지표 계산처럼 명확한 규칙이 있는 처리가 있어야 한다. 이게 없으면 AI 단독으로 가는 게 낫다.

2. 계산 결과만으로는 사람이 읽기 어렵다 오행 비율 木30% 火25% 土10% 金20% 水15%는 숫자지만 의미가 없다. 이걸 "어떤 환경이 이 사람에게 맞는가"로 바꾸는 게 AI의 역할이다. 데이터가 있어도 해석이 필요한 도메인이어야 한다.

3. 도메인 전문 지식이 참조 데이터로 정리 가능하다 궁통보감처럼 "이 조합에서는 이런 의미"를 정리한 전문 지식이 있으면 품질이 극적으로 올라간다. 이 데이터를 어떻게 구조화하고 주입하느냐가 설계의 핵심이 된다.

---

이 구조가 맞지 않는 경우

반대로 이 설계가 과한 경우도 있다.

계산 레이어가 단순하거나 없으면 굳이 룰 엔진을 만들 필요가 없다. 단순 Q&A, 창작, 요약은 AI 단독이 맞다. 반대로 해석보다 계산이 압도적으로 중요한 도메인 — 항공기 비행 경로 계산, 금융 파생상품 가격 산정 같은 것 — 은 AI를 해석 레이어로 쓰는 게 의미가 없다.

이 구조가 빛나는 건 "전문가가 데이터를 보고 말을 건네는" 과정을 자동화하고 싶을 때다.

---

7편을 마치며: 시리즈 전체 요약

7편에 걸쳐 다룬 것들을 한 줄씩 정리한다.

 

 

1편: 룰 엔진만으로는 조합 폭발 문제를 해결할 수 없다
2편: AI 단독은 계산 정확성과 재현성을 보장할 수 없다
3편: "재현성이 필요한가"로 경계를 나눈다
4편: 구조화된 데이터와 참조 지식이 프롬프트 품질을 결정한다
5편: 모델 분기와 캐싱으로 비용을 65% 줄일 수 있다
6편: 설계보다 운영이 항상 한 겹 더 깊다
7편: 이 구조는 "전문가의 해석"이 필요한 모든 도메인에 적용된다

사주를 선택한 건 우연이었다. 복잡한 도메인 지식, 명확한 계산 규칙, 그리고 그것을 사람의 언어로 바꾸는 해석의 필요성. 이 세 가지가 완벽하게 맞아떨어지는 도메인이 사주였다.

결국 이 시리즈는 사주 앱 개발기이면서, "AI를 어떻게 써야 잘 쓰는 건가"에 대한 기록이기도 하다.