사주다이소
1인 개발자가 직접 만든 사주 만세력 엔진 — 사주다이소 개발기
사이드프로젝트로 사주 서비스를 만들었어요. 사주다이소(sajudaiso.com) — 1,000원에 4,000자 분량의 AI 사주풀이를 받을 수 있는 서비스입니다.
만들면서 가장 막막했던 게 만세력 엔진이었습니다. 라이브러리 쓸까 직접 만들까 고민하다 결국 직접 만들었고, 1개월 안에 완성했어요. 이 글은 그 한 달 동안 가장 고생했던 — 정확성 검증 이야기입니다.
왜 만세력 엔진을 직접 만들었나
사주 서비스를 만들 때 가장 큰 갈림길이 만세력입니다. 만세력은 사주의 토대가 되는 천문 계산표인데, 1900~2100년 사이 매일의 천간·지지, 절기, 음력 정보를 다 담고 있어야 해요.
선택지는 두 가지였습니다.
기존 npm 라이브러리 사용 — manseryeok-js, lunarjs 등
직접 엔진 구현 — 천문학 알고리즘부터 새로 짜기
1인 창업하면서 시간이 없으니 당연히 1번을 시도했어요. 근데 막상 라이브러리로 사주풀이를 돌려보니 결과가 미묘하게 어긋났습니다.
[디테일 1: 라이브러리 결과 어긋난 본인 또는 지인의 실제 사례를 1~2문장으로 — 가짜 사례 만들지 마세요]
사주는 1년 차이가 인생을 통째로 바꿉니다. 갑술년생과 을해년생은 완전히 다른 사주예요. 라이브러리에 맡길 수 없는 영역이라고 판단했습니다.
1개월 안에 만든 14개 컴포넌트
1. 양력 → 음력 변환 (한국천문연구원 API + Fallback)
2. 24절기 계산 (태양황경 기반)
3. 년주 (입춘 기준)
4. 월주 (절기 기준 12개월 + 월간 천간)
5. 일주 (60갑자 카운팅, 1985.01.01 기준점)
6. 시주 (진태양시 보정 + 야자시)
7. 대운 (순행·역행 + 절기 기반 시작 나이)
8. 세운 (연도별 60갑자)
9. 신살 (역마·도화·화개 등 30+ 종)
10. 귀인 (천을·문창·학당 등 15+ 종)
11. 합충형파해 관계
12. 격국 판단
13. 신강·신약
14. 용신·기신·희신
처음 짤 때는 "한 달이면 충분하지" 싶었습니다. 코드 자체는 3주 만에 끝났어요. 남은 일주일이 지옥이었습니다 .
검증 단계 1: 교차검증 대상 찾기
내가 만든 엔진을 뭐와 비교할 것인가. 다른 만세력 사이트는 API를 안 열어줘서 자동 비교가 불가능했습니다. 결국 npm에서 만세력 라이브러리 4~5개를 깔고 동시 실행 환경을 만들었어요.
처음 돌렸을 때 60+ 케이스 중 12개가 불일치했습니다.
검증 단계 2: 누가 맞나
여기서 진짜 함정이 있어요. 불일치 = 내가 틀렸다가 아닙니다. 라이브러리가 틀린 경우도 있어요.
12개 불일치 케이스를 하나씩 분석했습니다. 분류해보니
6개: 내가 틀림 → 코드 수정
3개: 라이브러리가 틀림 → 무시
3개: 명리학계 의견 갈림 → 결정 필요
3개의 명리학 의견 갈림이 가장 어려웠어요.
예를 들어 야자시(夜子時) 처리. KST 23시 이후 출생자의 일주를 다음 날로 처리할 것인가? 명리학 책마다 다릅니다. 삼명통회는 적용, 현대 만세력 중 일부는 미적용. 결정해야 했어요.
이런 결정 하나하나가 — 누군가의 사주 결과를 바꿉니다.
검증 단계 3: 가장 큰 함정 3개
검증하면서 진짜로 등골이 서늘했던 함정 3개를 풀어볼게요.
함정 1 — 일주 기준점
일주는 60갑자가 끝없이 반복되는 구조입니다. 어느 한 날짜를 기준으로 잡고 거기서부터 ±N일을 계산해서 갑자를 매기는데, 처음 만들 때 1985년 1월 1일을 辛丑(인덱스 37)으로 설정했어요. 근데 4개 라이브러리 다 같은 날을 庚子(인덱스 36)로 계산했습니다. 1일 차이.
이 1일 차이가 누군가의 일간을 통째로 바꿉니다. 갑목 일간이 을목 일간이 되면 그 사람의 본질이 완전히 달라져요. 수정한 코드에 검증 로직을 박아뒀습니다 — 두 번 다시 이런 실수 안 하려고
함정 2 — 절기 경계
월주는 양력 월이 아니라 절기 기준입니다. 입춘(2월 4일 전후)이 지나야 인월(寅月)이 시작돼요. 입춘 절입 시각이 2월 4일 오전 11시면, 그날 오전 10시에 태어난 사람은 아직 축월(丑月)입니다.
처음엔 고정 테이블(입춘=2월 4일)을 썼다가, 검증 단계에서 1900~2100년 사이 ±1일씩 오차가 누적되는 걸 발견했어요. 결국 태양황경 기반 동적 계산으로 다시 짰습니다.
함정 3 — 진태양시 보정
한국 표준시(KST)는 동경 135° 기준이지만, 한국의 실제 경도는 약 127°입니다. 약 32분의 차이가 있어요.
명리학에서는 출생 시각을 실제 태양의 위치 기준으로 계산합니다. KST 23시 30분에 태어난 사람은 실제로는 22시 58분 기준 — 시지(時支)가 자시(子時)가 아니라 해시(亥時)예요. 이 32분 차이를 안 박았으면 — 23시 출생자의 시지가 전부 틀렸을 겁니다.
1개월 후, 23개 항목 audit
마지막 주에 자체 audit를 했어요. 23개 항목 점검 결과
정확: 19개 — 4기둥 사주, 24절기, 음력 변환, 60갑자, 30+ 신살, 15+ 귀인
한계 인정: 4개 — 신강·신약 월령 가중치 단순화, 대운 시작 나이 시간 정밀도, 계절별 조후용신 미적용, 백호살 정의(전통 7개 한정)
한계를 명시한 이유는 — 검증의 핵심이 "내가 모르는 것을 명시하는 것"이기 때문입니다.
오히려 하지 않아야 할것들을 하지 않는것이 용기더라구요.
사이드프로젝트 하는 분들께 — 검증 단계 줄이는 법
이 글을 읽는 분이 1인 창업하거나 사이드프로젝트 하고 있다면, 가장 도움될 한 가지만 말하자면 — 검증 자동화는 처음부터 박으세요.
제가 1개월에 끝낼 수 있었던 이유는 3주차에 검증 스크립트를 만들었기 때문입니다. 4주차에 검증하려고 했다면 — 12개 불일치 케이스를 수동으로 찾는 데만 일주일 더 걸렸을 거예요.
코드 한 줄 바꿀 때마다 npm run verify. 60+ 케이스가 1초 안에 돌아갑니다. 새 코드가 기존 케이스를 깨면 즉시 알 수 있어요.
도메인이 무엇이든 코드가 정확한지 자동으로 확인하는 스크립트부터 만드세요. 기능 추가보다 우선입니다.
마치며
만세력 엔진을 직접 만든게 사주다이소가 다른 AI 사주 서비스와 가진 거의 유일한 차별점입니다. 라이브러리에 의존하면 절대 못 가지는 강점.
다음 글에서는 — Claude API로 4,000자 사주풀이를 어떻게 생성하는지, 1,000원 가격에 맞춰 비용을 어떻게 최적화했는지 다뤄볼 예정입니다. 사이드프로젝트로 LLM 활용하는 분들이 가장 궁금해할 부분.
피드백 환영합니다. 사주다이소: https://sajudaiso.com
