사주 개선 2편: 시간대와 절기 경계에서 결과가 바뀌는 이유

사주 계산에서 “몇 시에 태어났는가”는 시주만 결정하지 않는다. 입력 지역의 시간대와 경도, 절기가 바뀌는 시점, 자시를 어느 날짜로 볼지까지 함께 연결된다. 시계에 적힌 숫자만 받아 결과를 단정하면 경계에 있는 사용자의 결과를 설명하기 어렵다.

이번 개선에서는 경계값을 없애려고 하지 않았다. 경계가 존재한다는 사실을 계산 결과와 함께 보여 주는 방향을 택했다.

시간대는 문자열이 아니라 계산 기준이다

화면에서 시간대를 선택하도록 한 이유는 지역 이름을 예쁘게 보여 주기 위해서가 아니다. 서버가 ZoneId를 기준으로 입력 시각의 UTC 오프셋을 계산해야 하기 때문이다.

현재 화면은 다음 시간대를 제공한다.

서버는 문자열을 바로 신뢰하지 않고 ZoneId.of로 검증한다. 잘못된 값은 계산 라이브러리까지 내려보내지 않고 400 응답으로 끝낸다. 시간대가 바뀌면 같은 시계 시각이라도 지역 태양시 보정과 절기 비교의 기준이 달라질 수 있다.

절입 시각은 날짜 한 칸으로 표현할 수 없다

월주는 단순히 양력 월의 첫날에 바뀌는 값이 아니다. 절기가 들어오는 절입 시각을 기준으로 달라질 수 있기 때문에, 절입 직전과 직후의 입력은 같은 날짜라도 다른 월주를 만들 수 있다.

woosday는 Tyme4j에서 계산한 현재 절기와 보정된 출생 시각의 차이를 비교한다. 그 간격이 30분 이내면 월주를 틀렸다고 단정하는 대신 다음 경고를 표시한다.

double termGapDays = Math.abs(
    solarTime.getJulianDay().subtract(solarTerm.getJulianDay())
);
if (termGapDays <= 30.0 / 1440.0) {
    warnings.add("절입 시각 30분 이내 출생입니다. 월주·절기 기준이 계산 방식에 따라 달라질 수 있습니다.");
}

30분은 전통 해석의 정답을 뜻하는 임계값이 아니다. 사용자가 결과를 다시 확인해야 하는 구간을 서비스에서 일관되게 표시하기 위한 운영 기준이다.

자시는 날짜 경계로 취급하기

현재 서비스는 23시부터 00시 59분까지를 자시 경계로 표시한다. 이 구간은 날짜를 전날 밤으로 볼지, 다음 날의 시작으로 볼지 해석 전통에 따라 차이가 생길 수 있다.

따라서 다음 두 작업을 함께 한다.

1. 지역 태양시 보정 후 실제 계산 시각을 기준으로 네 기둥을 계산한다.
2. 입력 시각이 자시라면 날짜 기준의 유파 차이가 있음을 경고한다.

결과를 하나로 반환하는 것은 화면 사용성을 위한 선택이다. 그 결과를 유일한 정답처럼 포장하지 않도록 경계 문구를 고정해 두었다.

경계값 테스트를 시나리오로 만들기

시간대와 절기는 일반적인 입력보다 경계 입력에서 문제가 드러난다. 서비스 테스트를 다음 시나리오로 나눴다.

테스트의 목적은 결과 문자열을 외우는 것이 아니다. 입력이 경계에 들어왔을 때 서비스가 침묵하지 않는지, 그리고 계산 기준이 화면 설명과 같은지 확인하는 것이다.

참고한 계산 계층

Tyme4j는 양력·음력·절기·간지와 팔자를 계산하는 라이브러리다. 서비스는 라이브러리의 결과를 그대로 해석 문장으로 바꾸지 않고, 먼저 지역 태양시 보정과 경계 경고를 적용한 뒤 필요한 값을 화면에 전달한다. 전통 개념의 설명은 한국민족문화대백과사전의 간지·사주 관련 항목을 참고하되, 계산 결과를 과학적 예측으로 표현하지 않는다.

• Tyme4j 공식 저장소
• 한국민족문화대백과사전 사주 항목

다음 글

시간을 정확히 모르는 사용자를 입력 단계에서 제외하면 실제 사용성이 크게 떨어진다. 다음 글에서는 오시 같은 대표 시간대를 선택했을 때 가능한 시주를 어떻게 보여 주고, 어디까지 해석해야 하는지 정리한다.

• 사주 개선 1편: 입력 날짜와 보정 날짜가 달라질 때 계산 기준 세우기
• 사주 개선 3편: 태어난 시간을 모를 때 단정하지 않는 리포트 만들기
• woosday 사주 풀이 기능을 만든 과정