4편: 룰 엔진과 AI 해석의 하이브리드 — 두 마리 토끼를 잡다

반응형

 

시리즈: AI 협업 개발기: 사주명리 프로젝트
키워드: 하이브리드 아키텍처, 프롬프트 엔지니어링, Claude API, 룰 엔진, 스트리밍


데이터는 있다, 해석은 누가 하는가

사주 네 기둥이 계산되고, 오행 비율이 나오고, 십신 관계가 분석되고, 용신이 판단되었다. 합충형파해도 검출되었고, 12운성도 배치되었다. 이제 이 "구조화된 분석 데이터"를 사람이 읽을 수 있는 말로 바꿔야 한다.

타로 프로젝트에서는 이 부분이 간단했다. 카드마다 미리 작성된 해석 텍스트를 보여주면 끝이었다. 사주에서는 이 접근이 불가능하다. 네 기둥의 조합은 사실상 무한하고, 같은 일주라도 월주와 시주가 다르면 해석이 달라진다.

이것이 처음부터 "하이브리드"를 선택한 이유였다.

AI에만 맡기면 안 되는 이유

프로젝트 초기에 실험을 했다. 생년월일시를 Claude에게 직접 넘기고 "이 사람의 사주를 풀어줘"라고 요청한 것이다.

결과는 그럴듯했다. 하지만 심각한 문제가 두 가지 있었다.

첫째, 사주 계산의 정확성을 보장할 수 없었다. AI가 내부적으로 사주 기둥을 계산하는 과정은 블랙박스다. 절기 기반 월주 판정, 진태양시 보정 같은 것을 정확히 처리하는지 확인할 방법이 없다. 실제로 같은 생년월일을 여러 번 물어봤을 때 일주가 다르게 나오는 경우가 있었다.

둘째, 해석의 근거가 불투명했다. "편재가 강하므로 사업 적성이 있습니다"라고 AI가 말했을 때, 실제로 편재가 몇 개인지, 어느 기둥에 있는지, 용신과의 관계는 어떤지를 확인할 수 없다. 사주 해석은 "왜 그런 결론이 나왔는지"를 보여줄 수 있어야 신뢰가 생긴다.

하이브리드 방식은 이 두 문제를 해결한다. 계산은 룰 기반 엔진이 정확하게 수행하고, 그 결과를 구조화된 데이터로 AI에 전달한다. AI는 이미 검증된 데이터를 "해석"하는 역할만 한다. 계산의 정확성과 해석의 자연스러움, 두 마리 토끼를 모두 잡는 것이다.

분석 데이터에서 프롬프트로

룰 기반 엔진의 출력은 JSON 형태의 구조화된 분석 데이터다. 이것을 AI에 넘기려면 "프롬프트"로 변환해야 한다. 이 변환이 하이브리드 아키텍처의 핵심이다.

원칙은 하나. AI에게는 "계산"을 시키지 않고 "해석"만 시킨다. 오행 비율이 木 30%, 火 20%, 土 15%, 金 25%, 水 10%라는 것은 이미 계산된 결과로 넘기고, AI에게는 "이 비율의 의미를 설명해달라"고 요청한다.

프롬프트에 포함되는 정보는 사주 네 기둥의 천간과 지지, 일간이 누구인지, 각 위치의 십신 관계, 오행 비율, 판단된 용신과 그 근거, 주요 합충형파해, 12운성 배치, 성별이다.

시스템 프롬프트에서 AI의 역할을 "40년 경력의 명리학 전문가"로 설정했다. 전통 이론에 정통하면서 현대인이 이해할 수 있는 언어로 설명하는 역할이다. 여기에 중요한 제약 조건을 추가했다. 제공된 분석 데이터를 기반으로만 해석할 것, 데이터에 없는 내용을 추론하지 말 것, 운명론적 단정이 아닌 경향과 가능성으로 설명할 것.

"운명론적 단정을 피하라"는 지침은 윤리적 판단이다. "당신은 평생 재물운이 없습니다"가 아니라 "편재가 약하므로 안정적인 자산 관리에 더 신경 쓰면 좋겠습니다"로 표현하도록 유도했다.

궁통보감의 마법

해석 품질을 극적으로 올린 것은 궁통보감(窮通寶鑑) 데이터를 프롬프트에 참조 데이터로 제공한 것이었다. 궁통보감은 일간 10개와 월지 12개의 120가지 조합별로 "이 계절에 이 일간은 어떤 오행이 필요한가"를 정의한 명리학 고전이다.

이 데이터 없이는 "목(木)이 강하니 성격이 곧습니다" 수준의 일반적인 해석이 나온다. 데이터가 있으면 "겨울에 태어난 갑목(甲木)은 얼어붙은 나무와 같으니, 화(火)의 따뜻함을 가진 사람이나 환경이 당신에게 활력을 줍니다" 같은, 계절과 일간에 맞는 맥락 있는 해석이 나온다.

"잘 써달라"는 지시보다 "이 데이터를 참고해서 써달라"는 지시가 훨씬 효과적이라는 것을 이 과정에서 체감했다. AI의 성능을 올리는 가장 효과적인 방법은 더 좋은 참조 데이터를 제공하는 것이다.

카테고리 분리와 비용 최적화

종합 해석 하나로 모든 것을 담으면 결과가 너무 길다. 총 7개의 카테고리를 정의했다. 타고난 성격, 직업 적성, 재물운, 건강, 대인관계, 대운별 시기, 종합 해석.

사용자에게는 종합 해석을 먼저 보여주고, 관심 있는 분야를 탭으로 선택하면 상세 해석을 on-demand로 호출한다. 모든 카테고리를 한꺼번에 생성하면 API 비용도 비싸고 대기 시간도 길다.

비용 최적화를 위한 모델 분기도 적용했다. 종합 해석에는 Claude Sonnet을, 개별 카테고리에는 Claude Haiku를 사용한다. 같은 사주의 해석은 로컬 스토리지에 캐시해서 동일 조회 시 API 호출을 줄인다.

스트리밍도 핵심이었다. Claude API의 스트리밍 기능으로 텍스트가 토큰 단위로 실시간 표시된다. "로딩 스피너를 10초 바라보는 것"과 "해석이 한 문장씩 나타나는 것"은 체감이 완전히 다르다.

UI: 동양 미학과 모던 디자인의 균형

분석 엔진과 해석 엔진이 완성되자 UI를 입혔다. 사주 앱의 시각적 정체성을 결정짓는 것은 오행 색상 시스템이다. 木은 녹색, 火는 적색, 土는 황색, 金은 은색, 水는 청색. 이 다섯 색상이 명식표, 오행 차트, 십신 라벨, 대운 타임라인까지 앱 전체를 관통한다.

명식표(命式表)는 네 기둥이 나란히 서 있고, 각 기둥에 천간, 지지, 지장간, 십신이 표시된다. 글래스모피즘 스타일의 반투명 배경 위에, 각 글자의 오행 색상이 은은하게 깔린다. 사용자가 앱을 쓰면서 자연스럽게 "녹색은 목이구나"라고 학습하게 되는 효과를 노렸다.

전체 흐름은 세 단계다. 입력 폼(생년월일시, 성별, 양/음력) → 룰 기반 분석 결과(명식표, 오행 차트 — 즉시 표시) → AI 해석(스트리밍, 카테고리 탭). 두 번째 화면이 즉시 나온다는 것이 핵심이다. AI 해석을 기다리는 동안 사용자는 명식표를 먼저 살펴볼 수 있다.

배경은 타로의 "별이 흐르는 밤하늘"과 달리, CSS gradient와 noise 패턴으로 한지(韓紙)를 연상시키는 질감을 만들었다. 마이크로 인터랙션은 절제했다. 사주 앱에서는 화려한 애니메이션보다 "정보의 정확한 전달"이 우선이다.

AI가 UI 구현에서 특히 잘한 것은 오행 색상 시스템의 일관된 적용이었다. 색상 상수를 먼저 정의하고 "이 시스템으로 명식표 컴포넌트를 만들어줘"라고 하면, 일관성이 자동으로 보장된다. 다만 AI가 생성한 초기 UI는 "기능적으로 완전하지만 감각적으로는 조정이 필요한" 상태였다. 여백, 글꼴 크기의 위계, 색상 대비의 미세 조정은 사람의 눈이 필요했다.

이 과정에서 배운 것

첫째, 하이브리드 아키텍처의 핵심은 "AI에게 무엇을 시키고 무엇을 시키지 않는가"의 경계 설정이다. 계산은 코드로, 해석은 AI로.

둘째, 프롬프트에 도메인 지식을 참조 데이터로 제공하면 해석 품질이 극적으로 향상된다. AI의 성능을 올리는 가장 효과적인 방법은 더 좋은 참조 데이터를 주는 것이다.

셋째, "즉시 보여줄 수 있는 것"과 "기다려야 하는 것"을 분리하면 UX가 극적으로 개선된다.

넷째, 도메인 고유의 색상 시스템이 있다면 이것을 UI의 뼈대로 삼으면 디자인의 일관성과 의미 전달이 동시에 해결된다.

다음 편 예고

설계 문서, 도메인 모델, 계산 엔진, AI 해석, UI까지 모든 것이 갖춰졌다. 마지막 5편에서는 프로젝트 전체를 돌아본다. 타로와 사주 두 프로젝트를 거치면서 진화한 AI 협업 방법론, 복잡한 도메인에서 사람만이 할 수 있는 것의 경계를 정리한다.


이 글은 "AI 협업 개발기: 사주명리 프로젝트" 시리즈의 4편입니다.

반응형