"정답이 여러 개인 도메인" — 기존 사주 앱 벤치마킹

같은 생년월일시를 넣었는데, 앱마다 사주 결과가 다르다. 시주가 다르고, 월주가 다르고, 심지어 일주까지 다른 경우가 있다. 도대체 뭐가 맞는 걸까? 이 글은 사주명리 프로젝트를 시작하기 전에 기존 앱들을 벤치마킹하면서 발견한 충격적인 현실과, 그로부터 도출한 설계 원칙의 이야기다.

벤치마킹의 출발점

프로젝트를 시작하기 전에 먼저 기존 서비스를 파악하는 것은 당연한 수순이다. 타로 프로젝트 때도 그랬다. 기존 타로 앱을 몇 개 써보고, 좋은 점과 아쉬운 점을 파악한 후 방향을 잡았다.

사주에서도 같은 접근을 했다. 구글 플레이와 앱스토어에서 인기 있는 사주 앱 몇 개를 설치하고, 웹 기반 만세력 사이트도 여러 곳을 찾았다. 그리고 동일한 생년월일시를 입력해서 결과를 비교했다.

여기서 문제가 시작됐다.

앱마다 결과가 다르다

같은 사람의 생년월일시를 넣었는데 사주 팔자 자체가 다르게 나온다. 처음에는 내가 입력을 잘못한 줄 알았다. 다시 확인하고, 다시 넣어봤다. 결과는 똑같았다. 앱 A와 앱 B의 시주가 달랐다. 앱 C는 월주까지 달랐다.

사주명리에서 "팔자"는 연주, 월주, 일주, 시주 네 개의 기둥이다. 각 기둥은 천간과 지지 한 쌍으로 이루어진다. 이 여덟 글자가 사주 분석의 모든 출발점이다. 그런데 이 출발점 자체가 앱마다 다르다니? 이건 단순한 UI 차이가 아니라 근본적인 계산 차이다.

개발자로서 이 현상이 당혹스러우면서도 흥미로웠다. 같은 입력에 같은 출력이 나와야 하는 것은 프로그래밍의 기본 전제 아닌가. 그런데 사주 도메인에서는 그 전제가 성립하지 않는 것처럼 보였다.

차이의 원인: 진태양시 보정

가장 큰 차이를 만드는 요소는 진태양시 보정이었다. 사주에서 "시(時)"를 결정할 때, 우리가 일상적으로 사용하는 시계 시간과 실제 태양의 위치가 다르다는 문제가 있다.

한국 표준시는 동경 135도를 기준으로 한다. 하지만 서울의 실제 경도는 약 127도다. 이 경도 차이 때문에 서울의 실제 태양 시간은 표준시보다 약 30분 느리다. 여기에 지구 공전 궤도의 타원형과 자전축 기울기에 의한 균시차까지 고려하면, 실제 태양 시간과 시계 시간의 차이는 날마다 달라진다.

이 차이가 왜 중요한가. 사주에서 시주를 결정하는 기준은 2시간 단위다. 자시(23:00~01:00), 축시(01:00~03:00) 같은 식이다. 30분의 차이가 시주를 바꿀 수 있고, 시주가 바뀌면 사주 팔자의 네 기둥 중 하나가 완전히 달라진다.

진태양시를 보정하는 앱과 보정하지 않는 앱. 이것이 시주 차이의 가장 큰 원인이었다.

차이의 원인: 야자시 처리

두 번째로 큰 차이는 야자시 처리였다. 자시는 밤 11시부터 새벽 1시까지인데, 여기서 문제가 생긴다. 밤 11시는 전날인가 다음 날인가?

야자시란 밤 11시에서 자정까지의 시간을 말한다. 이 시간에 태어난 사람의 일주를 어떻게 정할 것인가에 대해 학파마다 견해가 다르다.

한 쪽은 밤 11시가 넘으면 이미 다음 날의 기운이 시작된다고 본다. 따라서 일주도 다음 날 것을 사용해야 한다. 다른 한 쪽은 자정이 넘어야 날짜가 바뀐다고 본다. 밤 11시에서 자정까지는 아직 당일이므로 당일의 일주를 쓴다.

일주가 달라지면 십신 분석의 기준점인 일간이 달라지고, 십신 관계 전체가 바뀐다. 사주 해석의 근간이 흔들리는 것이다. 이것이 같은 생년월일시를 넣어도 앱마다 전혀 다른 해석이 나올 수 있는 핵심 이유 중 하나였다.

차이의 원인: 서머타임

1950년대와 1960년대 한국에서는 서머타임(일광절약시간)을 시행한 적이 있다. 이 기간에 태어난 사람의 출생 시간은 서머타임이 적용된 시간이다. 진짜 태양 시간으로 사주를 보려면, 서머타임을 역보정해야 한다.

문제는 서머타임 적용 기간과 보정 시간에 대한 정보가 앱마다 다르다는 것이다. 어떤 앱은 서머타임을 고려하고, 어떤 앱은 아예 무시한다. 고려하는 앱 중에서도 적용 기간이 미묘하게 다른 경우가 있다.

현재 시점에서 서머타임 영향을 받는 사용자는 1950~60년대 출생자로 제한되지만, "모든 사용자에게 정확한 결과를 제공한다"는 목표를 세운 이상 무시할 수 없는 요소였다.

차이의 원인: 학파별 해석 차이

팔자가 동일하더라도 해석이 다를 수 있다. 이것은 계산 오류가 아니라 학문적 관점의 차이다.

대표적인 예가 지장간 배속이다. 지지 안에 어떤 천간이 숨어 있는지에 대해 학파마다 견해가 다르다. 子(자) 안에 壬과 癸가 모두 있다고 보는 쪽이 있고, 癸만 있다고 보는 쪽이 있다. 12운성에서 음간의 순행/역행도 학파마다 다르다.

이런 차이들이 앱마다 다른 결과의 근본적인 원인이었다. 그리고 이것은 버그가 아니다. 사주명리 자체가 하나의 통일된 체계가 아니라 여러 학파의 해석이 공존하는 도메인이기 때문이다.

KASI 데이터의 중요성

벤치마킹 과정에서 특히 주목한 것이 한국천문연구원(KASI) 데이터를 사용하는지 여부였다. 사주에서 월주를 결정하는 기준은 음력 날짜가 아니라 절기다. 입춘이 지나야 새해이고, 경칩이 지나야 2월이다.

절기의 정확한 시각은 천문학적 계산으로 결정된다. KASI는 이 절기 데이터를 분 단위까지 제공한다. 절기 시각이 정확해야 월주가 정확하고, 월주가 정확해야 사주 전체가 정확하다.

벤치마킹해본 앱들 중 KASI 데이터를 사용한다고 명시한 앱과 그렇지 않은 앱의 정확도 차이는 분명했다. 특히 절기 경계에 해당하는 날짜, 예를 들어 입춘 당일에 태어난 사람의 경우 차이가 두드러졌다. KASI 데이터를 쓰는 앱은 입춘의 정확한 시각을 기준으로 월주를 결정하고, 그렇지 않은 앱은 대략적인 날짜를 기준으로 판단했다.

원광디지털대학교의 사례

벤치마킹 과정에서 흥미로운 사례를 발견했다. 원광디지털대학교 동양학과에서 학술 검증을 거친 사주 분석 앱이 있다는 것이다. 학술 기관의 검증을 거쳤다는 것은, 최소한 해당 학파의 이론 체계 내에서 계산의 정확성이 검증됐다는 의미다.

이 사례가 중요한 이유는, "어떤 학파의 이론을 따르는가"를 명시하고 그 이론 내에서의 정확성을 추구하는 것이 사주 도메인에서의 올바른 접근이라는 점을 보여주기 때문이다. "절대적으로 맞는 사주"는 없다. 하지만 "이 이론 체계 내에서 정확하게 계산된 사주"는 있을 수 있다.

"정답이 하나가 아닌 도메인"에서의 설계 원칙

벤치마킹의 결론은 명확했다. 사주명리는 정답이 하나가 아닌 도메인이다. 진태양시 보정 여부, 야자시 처리 방식, 학파별 해석 차이에 따라 같은 입력에 다른 결과가 나올 수 있고, 어느 쪽이 "틀렸다"고 단정할 수 없다.

이 현실에서 프로젝트의 설계 원칙을 세웠다.

첫째, 합리적인 기본값을 설정한다. 진태양시 보정은 적용하고, 야자시는 당일로 처리하되, 절기는 KASI 데이터를 사용한다. 현대 명리학에서 가장 많이 채택하는 방식을 기본값으로 삼는다.

둘째, 유연한 구조를 만든다. 기본값은 있지만, 사용자가 옵션으로 변경할 수 있는 구조로 설계한다. 야자시를 다음 날로 처리하고 싶은 사용자도, 진태양시를 보정하지 않고 싶은 사용자도 수용할 수 있어야 한다.

셋째, 어떤 기준을 따르고 있는지 명시한다. "이 결과는 진태양시 보정을 적용하고, 야자시를 당일로 처리한 결과입니다"라는 설명이 필요하다. 투명성이 신뢰를 만든다.

이 원칙은 이후 모든 설계 결정의 기준이 됐다.

벤치마킹이 설계를 바꿨다

만약 벤치마킹 없이 바로 개발에 들어갔다면, 아마 "사주에는 정답이 하나"라는 전제로 설계했을 것이다. 그랬다면 나중에 학파 차이를 발견했을 때 구조를 크게 뜯어고쳐야 했을 것이다.

벤치마킹을 통해 도메인의 본질적 특성을 프로젝트 초반에 파악한 것이 큰 행운이었다. "정답이 여러 개"라는 전제 위에 설계를 시작했기 때문에, 이후의 모든 구현이 유연성을 기본으로 갖추게 됐다.

타로 프로젝트에서는 이런 수준의 벤치마킹이 필요 없었다. 타로는 카드 78장, 해석 텍스트, 리딩 방식이라는 비교적 단순한 구조이고, 앱마다 크게 다르지 않았다. 사주의 복잡도는 벤치마킹 단계에서부터 이미 다른 차원이었다.

이 과정에서 배운 것

첫째, 벤치마킹은 "경쟁 분석"이 아니라 "도메인의 본질적 특성을 발견하는 과정"이다. 기존 앱들의 결과가 다르다는 사실 자체가, 이 도메인의 핵심 특성을 보여줬다.

둘째, "정답이 하나가 아닌 도메인"에서는 유연한 구조가 정확한 계산보다 더 중요할 수 있다. 기본값은 최선의 판단으로 정하되, 다른 선택도 수용할 수 있는 구조를 만드는 것.

셋째, 사주 프로그램의 품질을 결정하는 것은 UI나 해석 텍스트가 아니라, 만세력 계산의 정확도와 보정 로직의 치밀함이다. 겉으로 보이지 않는 엔진의 정밀함이 결과의 신뢰도를 결정한다.

다음 편 예고

도메인의 지형도도 그렸고, 벤치마킹으로 설계 원칙도 세웠다. 이제 본격적으로 개발을 시작해야 할 때다. 그런데 타로 때처럼 바로 코드를 쓰기 시작하지 않았다. 이번에는 코드 한 줄 쓰기 전에 설계 문서를 먼저 작성했다. 35페이지짜리 도메인 모델 문서를 포함해서. 왜 그랬는지, 그리고 그 결정이 AI 협업의 판도를 어떻게 바꿨는지, 3편에서 이어진다.