2026.02.17 - [개발] - 사주 앱 개발 4편 - 룰 엔진 + AI 해석 하이브리드 설계
사주 룰 + AI 해석 하이브리드 설계과정에 대한 좀 상세한 분석이다
프롬프트를 잘 쓰는 것보다 프롬프트에 무엇을 넣을 것인가가 더 중요하다.
이 프로젝트에서 해석 품질이 가장 크게 올라간 순간은 표현을 다듬었을 때가 아니었다. 궁통보감 데이터를 참조 데이터로 주입했을 때였다. "잘 써달라"는 지시 백 번보다 "이 데이터를 참고해서 써달라"는 지시 한 번이 강했다.
프롬프트 설계 전체를 공개한다.
시스템 프롬프트: 역할과 제약
시스템 프롬프트는 두 부분으로 구성했다. AI의 역할 정의, 그리고 명시적 제약.
당신은 40년 경력의 명리학 전문가입니다.
사주 원리에 정통하며, 현대인이 실생활에서 이해하고 활용할 수 있는
언어로 설명하는 것을 중요하게 생각합니다.
[제약 조건]
1. 제공된 분석 데이터를 기반으로만 해석할 것
2. 데이터에 없는 오행, 십신, 합충을 임의로 언급하지 말 것
3. 운명론적 단정("당신은 ~입니다") 대신 경향과 가능성("~하는 경향이 있습니다")으로 표현
4. 수치가 제공된 경우 해당 수치를 해석에 인용할 것
5. 부정적 내용은 개선 방향과 함께 제시할 것
역할 정의에서 "40년 경력"을 명시한 이유가 있다. 단순히 "명리학 전문가"보다 구체적인 배경이 있을 때 해석 문체와 깊이가 달라진다. AI가 특정 페르소나를 유지하는 데 구체성이 도움이 된다.
제약 2번이 핵심이다. 이것 하나로 2편에서 다룬 "근거 없는 십신 해석" 문제의 대부분이 해결됐다. AI가 프롬프트에 없는 데이터를 임의로 끌어들이는 걸 구조적으로 막는다.
유저 프롬프트: 데이터 패키지 구조
룰 엔진 출력을 AI에게 넘기는 유저 프롬프트 구조다.
다음은 [이름 또는 익명]님의 사주 분석 데이터입니다.
이 데이터를 기반으로 [카테고리] 해석을 작성해주세요.
## 사주 기본 정보
- 성별: 남성
- 사주 기둥: 년(甲子) 월(丙寅) 일(庚午) 시(甲子)
- 일간: 庚金
## 오행 분포
木: 30% / 火: 25% / 土: 10% / 金: 20% / 水: 15%
(金이 평균 이하, 火가 강한 구조)
## 십신 배치
- 년간 甲: 편재
- 년지 子: 상관
- 월간 丙: 편관
- 월지 寅: 편재
- 일지 午: 정관
- 시간 甲: 편재
- 시지 子: 상관
## 용신 판단
- 용신: 土 (억부법 기준, 金을 생하는 土 필요)
- 희신: 金
- 기신: 木, 火
## 합충형파해
- 子午 충 (년지-일지): 감정과 현실 사이의 긴장
- 寅午 반합 (월지-일지): 火 에너지 강화
## 12운성
- 일간 庚의 월지 寅: 절(絶) — 새로운 시작의 에너지
## 궁통보감 참조 (庚金, 寅月)
[여기에 해당 일간-월지 조합의 궁통보감 데이터 주입]
데이터 패키지에서 중요한 것이 두 가지다.
첫째, 오행 분포에 해석 힌트를 함께 넣었다. (金이 평균 이하, 火가 강한 구조) 이 한 줄이 있고 없고의 차이가 크다. AI가 어디에 집중해서 해석해야 하는지 방향을 준다.
둘째, 합충 항목에 간략한 해석 방향을 붙였다. 子午 충: 감정과 현실 사이의 긴장 이건 룰 엔진이 계산한 게 아니라 내가 미리 정의한 해석 프레임이다. 이렇게 프레임을 제공하면 AI 해석이 이 방향으로 수렴한다. 해석의 일관성을 유지하는 방법이다.
궁통보감 데이터 주입
이 부분이 품질을 결정했다.
궁통보감은 일간 10개 × 월지 12개 = 120가지 조합에 대해 "이 계절에 이 일간은 어떤 오행이 필요한가, 왜 필요한가"를 정리한 고전이다. 이 데이터를 프롬프트에 직접 주입하면 해석이 계절과 일간의 특성을 반영한다.
庚金 寅月(2월) 조합의 예시:
## 궁통보감 참조 — 庚金 寅月
寅月의 庚金은 아직 봄의 기운이 시작되는 시기의 쇠붙이다.
木의 기운이 강하게 자라는 계절이라 庚金이 剋을 받는 구조다.
이 시기의 庚金에게는 戊土가 가장 필요하다.
戊土가 있으면 金을 생하고 木을 억제하여 균형을 맞춘다.
丙火는 庚金을 제련하여 유용한 그릇으로 만들지만,
火가 과다하면 金이 녹아내리므로 土의 중재가 중요하다.
이 텍스트가 있을 때와 없을 때 AI 해석의 차이:
없을 때: "庚金은 강인하고 결단력 있는 성격을 가집니다. 추진력이 강하며..."
있을 때: "봄에 태어난 庚金은 강하게 자라는 木의 기운 속에서 자신의 자리를 만들어가야 하는 구조입니다. 土의 성질을 가진 사람이나 환경이 당신에게 든든한 버팀목이 됩니다. 관계에서 안정감을 주는 사람을 곁에 두는 것이 중요한 이유가 여기 있습니다."
같은 일간인데 해석의 깊이와 구체성이 다르다. AI는 참조 데이터가 있으면 그것을 기반으로 해석한다. 없으면 학습 데이터에서 일반적인 패턴을 가져온다. 일반적인 패턴은 얕다.
카테고리별 프롬프트 분기
7개 카테고리마다 동일한 데이터 패키지를 넘기되, 마지막 지시문만 바꾼다.
const categoryPrompts: Record<string, string> = {
personality: `
위 데이터를 바탕으로 이 사람의 타고난 성격과 기질을 해석해주세요.
일간의 특성, 강한 오행, 두드러진 십신을 중심으로 설명하되
장점과 함께 주의할 점도 균형 있게 다뤄주세요.
분량: 300-400자
`,
career: `
위 데이터를 바탕으로 직업 적성과 일하는 방식을 해석해주세요.
용신과 희신 오행의 특성, 강한 십신(식신/상관/재성/관성)을 기반으로
적합한 직업 유형과 업무 환경을 구체적으로 제시해주세요.
분량: 300-400자
`,
wealth: `...`,
health: `...`,
relationship: `...`,
luck: `...`,
overall: `
위 데이터를 바탕으로 종합적인 사주 해석을 작성해주세요.
이 사람의 핵심 특성, 삶의 방향성, 현재 시기의 의미를 통합하여
실용적이고 긍정적인 방향의 메시지로 마무리해주세요.
분량: 500-600자
`
}
분량 지정이 의외로 중요하다. 지정하지 않으면 AI가 과도하게 길거나 짧게 생성한다. 카테고리별 탭 UI에서 각 탭의 내용이 비슷한 길이여야 UI가 안정적이다.
스트리밍 처리
Claude API 스트리밍으로 텍스트를 토큰 단위로 받아 실시간 표시한다.
const response = await anthropic.messages.stream({
model: 'claude-haiku-4-5',
max_tokens: 1024,
system: systemPrompt,
messages: [{ role: 'user', content: userPrompt }]
})
for await (const chunk of response) {
if (
chunk.type === 'content_block_delta' &&
chunk.delta.type === 'text_delta'
) {
onChunk(chunk.delta.text) // 콜백으로 UI에 전달
}
}
"로딩 스피너 10초"와 "텍스트가 한 문장씩 나타나는 것"은 체감이 완전히 다르다. 실제 대기 시간이 같아도 스트리밍이 있으면 사용자가 기다리는 느낌이 덜하다.
종합 해석은 claude-sonnet-4-5, 개별 카테고리는 claude-haiku-4-5로 모델을 분기했다. Haiku가 빠르고 저렴하며 짧은 카테고리 해석에서 품질 차이가 크지 않다.
프롬프트 설계 요약
| 시스템 프롬프트 | 역할 + 명시적 제약 | 할루시네이션 방어, 문체 일관성 |
| 데이터 패키지 | 구조화 JSON + 해석 힌트 | 해석 방향 수렴 |
| 궁통보감 주입 | 일간-월지 조합별 참조 텍스트 | 해석 깊이와 구체성 |
| 카테고리 지시문 | 분량 + 초점 명시 | UI 안정성, 일관된 분량 |
| 스트리밍 | 토큰 단위 실시간 출력 | UX 체감 개선 |
프롬프트 엔지니어링의 핵심은 AI가 잘하는 것만 하도록 환경을 만드는 것이다. 계산은 이미 됐고, 근거는 이미 있고, 방향도 이미 정해졌다. AI는 그것을 사람의 언어로 바꾸는 일만 한다.
다음 편에서는 비용과 품질의 균형을 다룬다. 실제 API 호출 비용, 캐싱 전략, 어느 카테고리에 어떤 모델을 쓸 것인지 — 운영 관점에서의 최적화 기록.
'개발 > AI' 카테고리의 다른 글
| 사주 룰 + AI 해석 하이브리드: 실전 트러블슈팅 — 하이브리드가 삐걱거릴 때 (0) | 2026.03.04 |
|---|---|
| 사주 룰 + AI 해석 하이브리드: 비용과 품질의 균형점 찾기 (0) | 2026.03.04 |
| 사주 룰 + AI 해석 하이브리드: 어디서 나눌 것인가 — 경계 설계 (0) | 2026.03.04 |
| 사주 룰 + AI 해석 하이브리드: AI 단독 해석이 실패하는 지점 (0) | 2026.03.04 |
| 사주 룰 + AI 해석 하이브리드: 왜 룰 엔진만으로는 안 되는가 (0) | 2026.03.04 |
