궁통보감의 마법 — 프롬프트 엔지니어링과 참조 데이터
"잘 써달라"는 통하지 않는다
룰 엔진이 완성되자, 구조화된 분석 데이터가 JSON 형태로 출력되기 시작했다. 오행 비율, 십신 관계, 용신, 합충형파해. 정확한 데이터다. 이제 이것을 AI에게 넘겨서 "사람이 읽을 수 있는 해석"으로 바꿔야 한다. 처음에는 단순하게 생각했다. 데이터를 넘기고 "잘 해석해줘"라고 하면 되지 않을까.
결과는 실망스러웠다. "목(木)이 강합니다. 성격이 곧고 직선적입니다." 틀린 말은 아니지만, 누구에게나 해당될 수 있는 일반적인 이야기였다. 사주 전문 앱에서 기대하는 깊이의 해석과는 거리가 멀었다.
분석 데이터에서 프롬프트로
첫 번째로 개선한 것은 프롬프트의 구조였다. AI에게 넘기는 정보를 체계적으로 정리했다.
프롬프트에 포함되는 핵심 정보는 다음과 같다. 사주 네 기둥의 천간과 지지 전체, 일간(日干)이 누구인지, 각 위치의 십신 관계, 지장간에 숨어 있는 오행과 십신, 오행 비율(퍼센트 단위), 판단된 용신과 그 근거, 주요 합충형파해 관계, 12운성 배치, 성별.
원칙은 하나였다. AI에게는 "계산"을 절대 시키지 않는다. 오행 비율이 木 30%, 火 20%, 土 15%, 金 25%, 水 10%라는 것은 이미 계산된 결과로 넘긴다. AI에게는 "이 비율이 이 사람의 삶에서 무엇을 의미하는지 설명해달라"고만 요청한다.
이렇게 구조화된 데이터를 넘기자 해석의 정확성이 올라갔다. "편재가 2개이고 정재가 1개, 용신이 금(金)"이라는 구체적 데이터가 있으니, AI도 "사업적 기질이 있지만 안정적 수입도 병행하는 것이 좋겠다"는 맥락 있는 해석을 내놓기 시작했다. 하지만 여전히 깊이가 부족했다.
시스템 프롬프트: 40년 경력의 전문가
두 번째로 개선한 것은 시스템 프롬프트다. AI의 "역할"을 명확하게 설정했다.
"당신은 40년 경력의 명리학 전문가입니다. 전통 사주 이론에 정통하면서도 현대인이 이해할 수 있는 쉬운 언어로 설명할 수 있습니다."
이 역할 설정만으로도 어투와 전문성이 눈에 띄게 달라졌다. "목이 강합니다"가 "일간 갑목(甲木)이 봄에 뿌리를 내린 형국입니다"로 바뀌었다. AI가 명리학 전문 용어를 자연스럽게 쓰되, 괄호 안에 설명을 덧붙이는 패턴이 생겼다.
시스템 프롬프트에는 역할 외에도 중요한 제약 조건들을 추가했다.
첫째, "제공된 분석 데이터를 기반으로만 해석할 것." AI가 데이터에 없는 내용을 지어내는 것(hallucination)을 방지하기 위한 장치다. 룰 엔진이 편재를 2개로 계산했는데 AI가 "편재가 3개로 매우 강합니다"라고 말하면 안 된다.
둘째, "운명론적 단정을 피하고, 경향과 가능성으로 설명할 것." 이 지침은 윤리적 판단이다. "당신은 평생 재물운이 없습니다"는 위험한 문장이다. 사주를 보고 인생의 중요한 결정을 내리는 사람이 실제로 있기 때문이다. "편재가 약한 편이므로, 투기보다는 안정적인 자산 관리에 더 신경 쓰면 좋겠습니다"가 우리가 원하는 톤이었다.
셋째, "분석 데이터에 없는 내용을 추론하거나 창작하지 말 것." 예를 들어 데이터에 대운(大運) 정보가 없는데 "40대에 큰 변화가 옵니다"라고 말하면 안 된다. 이 제약은 하이브리드 아키텍처의 신뢰성을 지키는 핵심 장치다.
궁통보감이 바꾼 것
여기까지 해서 해석이 "쓸 만한 수준"이 되었다. 하지만 전문 사주 앱들의 해석과 비교하면 여전히 무언가가 부족했다. "이 사주의 특수성"을 짚어내는 깊이가 없었다.
전환점은 궁통보감(窮通寶鑑) 데이터를 프롬프트에 참조 데이터로 제공하면서 찾아왔다.
궁통보감은 명리학의 고전 중 하나로, 일간 10개와 월지 12개의 120가지 조합별로 "이 계절에 태어난 이 일간은 어떤 오행이 필요하고, 어떤 특성을 보이는가"를 상세히 기술한 책이다. 조후법(調候法)의 핵심 참고서다.
이 데이터를 프롬프트에 넣기 전의 해석은 이랬다. "목(木)이 강하니 성격이 곧고 활동적입니다. 주변과 잘 어울리며 리더십이 있습니다." 교과서적이고, 누구에게나 맞을 것 같은 해석이다.
궁통보감 데이터를 넣은 후의 해석은 이렇게 바뀌었다. "겨울에 태어난 갑목(甲木)은 얼어붙은 대지 위에 서 있는 나무와 같습니다. 뿌리는 깊지만 기운이 위축되어 있어, 화(火)의 따뜻함이 절실합니다. 열정적이고 따뜻한 성격의 사람, 혹은 활기찬 환경이 당신에게 활력을 불어넣어 줄 것입니다."
차이가 느껴지는가. 같은 "갑목"이라도 여름에 태어났는지 겨울에 태어났는지에 따라 완전히 다른 해석이 나온다. 이것이 궁통보감의 핵심 가치이고, AI가 이 데이터를 참조함으로써 "계절과 일간의 조합"이라는 핵심 맥락을 반영한 해석을 생성할 수 있게 된 것이다.
"잘 써달라"는 지시보다 "이 데이터를 참고해서 써달라"는 지시가 훨씬 효과적이라는 것을 이 과정에서 체감했다. 프롬프트 엔지니어링의 본질은 지시의 정교함이 아니라 참조 데이터의 품질이다.
7개 카테고리 분리
해석 품질 문제가 해결되자, 다음 과제는 해석의 구조였다.
처음에는 하나의 프롬프트로 종합 해석을 요청했다. 결과가 너무 길었다. 2000자가 넘는 해석을 한꺼번에 읽는 사용자는 없다. 게다가 "성격은 궁금한데 건강은 안 궁금하다"는 사용자도 있을 것이다.
총 7개의 카테고리를 정의했다. 타고난 성격, 직업 적성, 재물운, 건강, 대인관계, 대운별 시기, 종합 해석. 각 카테고리는 독립된 프롬프트로 호출된다.
사용자에게는 종합 해석을 먼저 보여주고, 관심 있는 분야는 탭으로 선택하면 그때 해당 카테고리의 상세 해석을 on-demand로 호출한다. 모든 카테고리를 한꺼번에 생성하면 API 비용도 비싸고 초기 대기 시간도 길다. 사용자가 실제로 보지 않을 카테고리까지 미리 생성할 이유가 없다.
이 on-demand 방식은 UX와 비용 모두를 개선했다. 사용자는 원하는 정보를 빠르게 얻고, 서비스 운영자는 불필요한 API 호출을 줄인다.
비용 최적화: 모델 분기와 캐시
API 비용은 실서비스에서 무시할 수 없는 문제다. 특히 사주처럼 프롬프트가 긴(분석 데이터 + 궁통보감 참조 + 시스템 프롬프트) 서비스에서는 토큰 비용이 빠르게 쌓인다.
세 가지 최적화 전략을 적용했다.
첫째, 모델 분기다. 종합 해석처럼 깊이가 필요한 카테고리에는 고성능 모델(Sonnet급)을 사용하고, 개별 카테고리의 상세 해석에는 경량 모델(Haiku급)을 사용한다. 실제로 "성격 분석"이나 "재물운" 같은 개별 카테고리는 참조 데이터가 충분하면 경량 모델로도 만족할 만한 품질이 나왔다. 종합 해석은 여러 요소를 교차 분석해야 하므로 고성능 모델이 확실히 낫다.
둘째, 로컬 캐시다. 같은 사주(같은 생년월일시, 같은 성별)의 해석 결과를 브라우저의 로컬 스토리지에 캐시한다. 사용자가 같은 사주를 다시 조회하면 API를 호출하지 않고 캐시된 결과를 보여준다. "내 사주"를 반복해서 보는 사용자가 많기 때문에, 이 전략의 효과는 상당했다.
셋째, Cloudflare Workers를 통한 Groq API 활용이다. Groq은 LLaMA 기반 모델을 매우 빠른 추론 속도로 제공하며, 무료 티어가 있다. 직접 Claude API를 호출하는 대신 Groq을 프록시로 활용하면, 비용을 극적으로 줄이면서도 스트리밍 응답의 빠른 체감 속도를 얻을 수 있다.
이 세 가지 전략을 조합하면, 사주 한 건의 종합 해석에 드는 비용을 기존 대비 크게 낮출 수 있었다. 무료 서비스를 운영하면서도 API 비용이 부담되지 않는 수준이 되었다.
스트리밍이 만드는 체감 속도
비용과 함께 중요한 것이 대기 시간이다. AI 해석은 아무리 빨라도 수 초가 걸린다. 로딩 스피너를 보며 5초를 기다리는 것과, 해석이 한 문장씩 나타나는 것을 지켜보는 것은 체감이 완전히 다르다.
Groq API의 스트리밍 기능을 활용해서, 해석 텍스트가 토큰 단위로 실시간 표시되도록 구현했다. 기술적으로는 Server-Sent Events(SSE) 방식이다. Cloudflare Workers가 Groq API로부터 스트리밍 응답을 받아 그대로 클라이언트에 전달한다.
사용자 입장에서는 버튼을 누르면 거의 즉시 텍스트가 나타나기 시작한다. 첫 토큰까지의 시간(Time to First Token)이 매우 짧기 때문이다. 전체 해석이 완성될 때까지 기다리지 않아도 읽기 시작할 수 있다는 것이 핵심이다.
이 스트리밍 방식은 "대기 시간"의 개념 자체를 바꿨다. 사용자는 기다리는 것이 아니라 "해석이 펼쳐지는 과정을 지켜보는" 경험을 한다. 마치 전문가가 실시간으로 사주를 읽어주는 듯한 느낌. 기술적 구현이 UX의 본질적인 감정을 바꾼 사례였다.
이 과정에서 배운 것
프롬프트 엔지니어링에 대해 가장 크게 깨달은 것은 이것이다. AI의 출력 품질을 올리는 가장 효과적인 방법은 "더 잘 써달라"고 지시하는 것이 아니라, "더 좋은 참조 데이터를 제공하는 것"이다.
궁통보감 데이터가 그 증거다. 같은 시스템 프롬프트, 같은 분석 데이터, 같은 모델이라도 궁통보감 참조가 있고 없고의 차이는 극적이었다. 프롬프트의 지시문을 아무리 정교하게 다듬어도, 참조 데이터 하나가 가져온 품질 향상에는 미치지 못했다.
이 원칙은 사주 프로젝트를 넘어서 AI 활용 전반에 적용된다. 번역을 시킬 때 "자연스럽게 번역해줘"보다 "이 분야의 용어집을 참고해서 번역해줘"가 낫다. 코드를 작성시킬 때 "깔끔하게 짜줘"보다 "이 설계 문서를 참고해서 짜줘"가 낫다.
다음 편 예고
분석 엔진과 AI 해석이 완성되었다. 이제 이것을 사용자에게 보여줄 차례다. 다음 편에서는 오행 색상 시스템이 앱 전체의 시각적 언어가 되는 과정, 명식표의 시각적 설계, 그리고 "동양 미학과 모던 디자인의 균형"을 다룬다.
댓글
댓글 쓰기