AI로 사주 서비스를 만든다면, AI에게만 맡기면 안 된다

"AI로 사주 서비스를 만든다"고 하면 보통 이렇게 생각합니다 — GPT한테 생년월일 주고 "사주 봐줘" 하면 되는 거 아냐? 저희도 처음엔 비슷하게 봤습니다. 그런데 'GPT한테만' 맡기면 품질이 금세 불안정해집니다. (역설적이게도, 구조화된 데이터를 제대로 먹이면 최신 모델은 생각보다 일관적입니다 — 핵심은 바로 거기에 있어요.) 사주J를 만들고 운영하며 부딪힌 것들을 적어봅니다. — 정답이라기보다, 저희가 도달한 생각입니다.

AI에게 '판단'을 안 맡기고, 엔진을 정교하게 만들었다

가장 크게 깨달은 건, 사실 판단을 AI에게 맡기면 안 된다는 것이었습니다. 사주의 명식(命式) 계산은 정답이 있는 영역입니다 — 일간을 세우고, 글자를 배치하고, 오행을 세는 건 계산이라 맞고 틀리고가 분명하죠. 다만 솔직히, 그 위의 '해석'은 결정론이 아닙니다. 용신·격국·신강의 정도·대운 풀이는 명리학자·학파마다 갈립니다. 그래서 저희 엔진이 하는 일은 "객관적 진리를 안다"가 아니라, 계산은 못 박고, 해석이 갈리는 부분은 하나의 일관된 명리 관점(교재 기반)으로 고정하는 것입니다. 핵심은 '진리'가 아니라 일관성과 근거예요 — 같은 사주엔 늘 같은 판정이 나오고, 거기엔 명리적 근거가 있다는 것.

이걸 LLM에 통째로 맡기면? 같은 사주를 물어도 매번 다른 소리를 하고, 못 박은 명식조차 무시하고 그럴듯하게 지어냈습니다(실측). 신강을 신약이라 하고요. 그래서 구조를 뒤집었습니다. 그리고 한 가지 더 — 엔진은 명식 '계산'에서 멈추지 않습니다. 신강·신약 판정, 용신·기신 방향, 격국, 성격·직업 키워드, 조후까지 명리 규칙대로 '1차 해석'을 구조화해 확정합니다. LLM에게 남기는 건 그 확정된 구조를 사람이 읽을 따뜻한 말로 풀어쓰고 공감하는 일뿐이고요. 해석조차 상당 부분 엔진이 구조화하고 AI의 몫을 좁힐수록, 환각은 줄고 일관성은 올라갑니다. 오해는 마세요 — 모델이 나빠서가 아닙니다. 구조 없이 "알아서 보라"면 흔들리고, 엔진이 구조를 먹이면 같은 모델도 꽤 일관됩니다. 우리가 한 건 모델을 불신한 게 아니라, 모델이 잘하도록 판을 깔아준 것입니다.

그리고 이 엔진을 정말 정교하게 만들었습니다. 명리 교재의 규칙을 단순 점수표가 아니라 요인 단위로 충실히 구현했고, 특히 궁합은 실제 전문가의 판정과 맞아떨어질 때까지 케이스로 반복 검증하며 다듬었습니다 — 일지(배우자궁)를 따로 보고, 천간합·오행 상극을 교재대로 반영하고, 약자를 깎는 식으로요. "그럴듯한 점수"가 아니라 "명리적으로 설명 가능한 판정"이 나오도록 한 거죠. 이 정밀함이 없으면, 그 위에 무슨 AI를 얹어도 토대가 모래입니다.

다양한 프롬프트로 'AI 상담 전문가'를 빚었다

엔진이 사실을 확정하면, 다음은 '어떻게 말하게 하느냐'입니다. 여기서 핵심은 만능 프롬프트 하나가 아니라, 풀이 영역마다 전용 프롬프트를 따로, 정교하게 설계한 것이었습니다. 타고난 성격, 재물운, 애정운, 올해의 흐름, 궁합 — 주제마다 어떤 관점으로·어떤 어조로·무엇을 짚어야 하는지를 다르게 줬습니다. 그리고 매 프롬프트에 엔진이 계산한 명식과 명리적 근거를 함께 넣어, AI가 막연한 챗봇이 아니라 그 주제를 아는 상담사처럼 말하게 했습니다.

그 결과, 같은 모델이라도 우리 서비스 안에서는 "사주 좀 아는 일반 AI"가 아니라 "명식을 정확히 읽고 그 분야를 깊이 풀어주는 전문가"에 가깝게 동작합니다. 모델이 똑똑해서가 아니라, 정확한 입력(엔진) + 정교한 지시(프롬프트)를 줬기 때문입니다. 물론 프롬프트만의 일은 아닙니다 — 엔진이 주는 구조화된 입력, 좋은 예시, "무엇이 좋은 답인가"를 가리는 평가 기준까지, 프롬프트는 그 여러 지렛대 중 하나예요. 공통점은 하나입니다: 전문성은 모델에 내장돼 있다기보다, 우리가 입력·예시·기준으로 빚어낸다는 것.

그런데 — 사용자가 원하는 건 '계산'이 아니라 해석

한 번 더 솔직해지면, 사용자는 "당신은 신강입니다"를 듣고 싶은 게 아닙니다. "그래서 나는 어떤 사람이고, 올해 뭘 조심해야 하나"를 알고 싶어 합니다. 가치의 대부분은 계산이 아니라 해석에서 나오죠. 그래서 엔진(정확함)과 프롬프트(전문가 해석)가 둘 다 정교해야 합니다 — 엔진은 틀리지 않게 받쳐주는 바닥, 프롬프트는 그 위에서 사람을 위로하는 말. 저희가 길게 모으는 데이터도 '명식'이 아니라 '좋은 서술'인 이유입니다.

수십 개의 풀이를, 싸게

사주 한 명에게 보여줄 풀이는 수십 개입니다(성격·직업·재물·애정·올해운·대운…). 매번 모델에 새로 물으면 요금이 폭발하죠. 그래서 비용을 "어떤 모델을 쓰느냐"가 아니라 "어떻게 안 부르느냐의 설계 문제"로 봤습니다. 공통으로 들어가는 명식 정보를 프롬프트 앞쪽에 모아 반복 비용을 줄이고, 같은 사람·같은 명식·같은 기간의 풀이는 결과를 재사용했습니다. 안 바뀌는 풀이(성격)는 영구히, 시간에 묶인 풀이(올해운)는 기간 단위로 캐시했고요. 절감의 대부분은 더 싼 모델이 아니라 "안 불러도 되는 호출을 안 부른" 설계에서 나왔습니다.

자체 모델? — 종착지가 아니라 선택지

"데이터 쌓이면 우리 모델 만든다", 저희도 하는 말입니다. 다만 정직하게, 정해진 종착지는 아닙니다. 범용 모델이 계속 좋아지고 싸지기 때문에, 많은 경우 "좋은 프롬프트 + 좋은 데이터 + 최신 범용 모델"이 자체 모델보다 더 싸고 좋습니다(실제로 많은 팀이 자체 모델을 시도하다 접습니다). 그래서 자체 모델은 "사주라는 좁은 영역에서 특화 모델이 범용보다 확실히 싸지는 순간"에만 가는 선택지입니다. 어느 쪽이든 좋은 해석 데이터를 모으는 일은 똑같이 남습니다 — 자체 모델의 연료든, 최신 범용 모델에 줄 예시든요. 오해를 막자면, 요즘 공개 모델(Qwen·Llama·DeepSeek 등)도 충분히 강합니다 — 문제는 모델이 아니라 "엔진·데이터 없이 모델만 갈아끼우면 된다"는 기대였어요. 구조와 데이터를 안 주면, 공개든 최전선이든 어떤 모델도 우리 명식을 무시합니다.

정리 — 결국, 엔진을 잘 만들어야 한다

역설적이지만, AI 사주를 만들며 핵심은 'AI'가 아니었습니다. 정확한 명리 엔진(틀리지 않는 바닥) + 영역별 정교한 프롬프트(전문가 화법) + 좋은 해석 데이터 — 이 토대가 전부였습니다. 토대가 부실하면, 아무리 똑똑한 모델을 얹어도 그럴듯한 헛소리가 나옵니다.

그래서 결론은 단순합니다 — 좋은 AI 서비스는 잘 만든 엔진 위에서만 섭니다. 모델은 내일 더 좋은 걸로 갈아끼우면 되지만, 정확하게 계산하고 일관되게 판정하는 엔진, 그리고 그 위에서 전문가처럼 말하게 하는 프롬프트 설계는 우리가 직접 정교하게 만들어야 합니다. 사주처럼 정확함과 공감이 동시에 필요한 도메인일수록, 그 차이가 더 분명해지더군요.

그리고 이건 사주만의 이야기가 아닙니다. 법률·세무·부동산·투자·의료 — 어떤 AI 서비스든, 사용자는 결국 GPT를 사는 게 아니라 그 회사가 만든 도메인 엔진·데이터·워크플로·전문지식을 삽니다. 모델은 누구나 같은 걸 쓰니까요. 좋은 AI 서비스의 해자는 모델이 아니라, 그 위에 우리가 쌓은 것에 있습니다.

---

이 원칙으로 정교하게 만든 게 사주J (sajuj.com)입니다. — 로동(lodong.co.kr)