KASI 데이터와 절기 정밀도 — 분 단위가 사주를 바꾼다

 

절기의 "날짜"가 아니라 "시각"이 필요하다

6편에서 사주가 절기력이라는 독자적인 달력 체계를 사용한다는 것을 다뤘다. 이번에는 그 절기력의 핵심 재료인 절기 데이터를 어디서, 어떻게 확보했는지 이야기한다. 이 과정에서 "데이터의 출처가 곧 앱의 신뢰도"라는 교훈을 얻었다.

절기 데이터가 필요하다는 것은 처음부터 알고 있었다. 문제는 어떤 수준의 데이터가 필요한가였다. "입춘은 대략 2월 4일쯤"이라는 수준으로는 부족하다. 6편에서 봤듯이 입춘 당일 출생자의 연주를 판정하려면, "2024년 입춘은 2월 4일 16시 27분"이라는 분 단위 정밀도가 필요하다. 연간 12개 절기(절) 각각에 대해, 1920년부터 2050년까지 130년간의 정밀 시각이 필요하다는 계산이 나온다.

이 데이터를 어디서 가져올 것인가. 인터넷에 떠도는 절기 표를 복사해서 쓸 수도 있다. 하지만 1편에서 벤치마킹할 때 이미 확인한 사실이 있었다. 정확도에서 차별화되는 전문 앱들은 예외 없이 한국천문연구원(KASI) 데이터를 사용한다. 출처가 불분명한 데이터로 만든 앱은, 아무리 분석 로직이 정교해도 기반이 흔들리는 것이다.

한국천문연구원(KASI) 데이터를 선택한 이유

한국천문연구원(Korea Astronomy and Space Science Institute)은 대한민국의 공식 천문 기관이다. 절기 시각을 포함한 천문 데이터를 공공 데이터로 제공하고 있으며, 이 데이터의 정밀도는 천문학적 계산에 기반한다. 개인이 만든 만세력 테이블이나, 출처를 알 수 없는 인터넷 데이터와는 신뢰도의 차원이 다르다.

KASI 데이터를 선택한 결정적 이유는 세 가지였다. 첫째, 공신력이다. 정부 산하 연구 기관의 공식 데이터이므로, 앱의 정확도에 대한 신뢰 근거가 된다. 둘째, 정밀도다. 절기 시각을 분 단위까지 제공하므로 사주 계산에 필요한 수준을 충족한다. 셋째, 범위다. 과거 데이터부터 미래 예측 데이터까지 충분한 기간을 커버한다.

사주 앱에서 "이 앱의 절기 데이터는 한국천문연구원 기준입니다"라고 명시할 수 있다는 것은, 사용자 신뢰의 관점에서 큰 차이를 만든다. "어디서 가져온 건지 모르는 데이터"와 "국가 공인 기관의 데이터"는 같은 숫자라도 무게가 다르다.

빌드 타임 수집이라는 전략적 선택

KASI 데이터를 확보하는 방식에도 선택지가 있었다. 가장 단순한 방법은 사용자가 사주를 조회할 때마다 KASI API를 실시간으로 호출하는 것이다. 하지만 이 방식에는 치명적인 문제가 있다.

첫째, API 장애 시 앱이 동작하지 않는다. 공공 API는 서버 점검이나 트래픽 제한이 있을 수 있다. 사용자가 자기 사주를 보려고 앱을 열었는데 "서버 연결 실패"가 뜨면 신뢰가 무너진다. 둘째, 응답 속도가 느려진다. 네트워크 요청은 수백 밀리초에서 수 초가 걸릴 수 있다. 절기 시각을 조회하는 것만으로 대기 시간이 발생하는 것은 UX 관점에서 용납하기 어렵다. 셋째, 오프라인 환경에서 동작하지 않는다.

그래서 택한 전략이 빌드 타임 수집이다. 앱을 빌드하는 시점에 1920년부터 2050년까지 130년분의 절기 데이터를 일괄 수집하여 JSON 파일로 저장한다. 이 JSON은 앱 번들에 포함되므로, 런타임에는 네트워크 요청 없이 로컬 데이터를 즉시 조회한다.

130년분 24절기 데이터의 크기가 걱정될 수 있다. 실제로 계산해보면, 130년 x 24절기 = 3,120개의 날짜-시각 쌍이다. JSON으로 수십 KB 수준이다. 앱 번들 크기에 미치는 영향이 거의 없다. 이 작은 용량으로 오프라인 동작, API 장애 무관, 즉각적 응답이라는 세 가지 이점을 모두 얻을 수 있다.

수집 스크립트의 설계

빌드 타임 수집을 위해 Node.js 스크립트를 작성했다. 이 스크립트는 Vite의 빌드 과정에 플러그인으로 통합되어, 빌드할 때마다 최신 데이터를 확보한다. 하지만 실질적으로 절기 데이터는 천문학적 계산의 결과이므로 한 번 확보하면 바뀔 일이 없다. 스크립트의 주요 역할은 "최초 1회 수집 + 데이터 무결성 검증"에 가깝다.

수집된 데이터의 구조는 단순하다. 연도를 키로, 해당 연도의 24절기 배열을 값으로 갖는 객체다. 각 절기 항목에는 절기명, 양력 날짜, 시각(시:분)이 포함된다. 사주 계산에서 실제로 사용하는 것은 24절기 중 "절(節)"에 해당하는 12개뿐이지만, 전체 24절기를 저장하는 것이 데이터의 완결성과 향후 확장성 측면에서 유리하다.

이 스크립트 작성에서도 AI 협업의 효과가 있었다. KASI 공공 데이터의 API 구조를 분석하고, 응답 데이터를 앱에서 사용하기 좋은 형태로 변환하는 과정을 Claude와 함께 진행했다. 특히 API 응답의 날짜/시간 형식을 파싱하고 정규화하는 로직에서, AI가 엣지 케이스(연말 절기가 다음 해로 넘어가는 경우 등)를 미리 지적해준 것이 실제 버그를 예방하는 데 도움이 됐다.

분 단위가 실제로 사주를 바꾸는 사례

절기 정밀 시각이 왜 중요한지, 구체적인 사례로 살펴보자.

2024년 입춘은 2월 4일 16시 27분이다. 같은 날 16시에 태어난 아이와 17시에 태어난 아이를 비교해보자. 16시 출생자는 아직 입춘 전이므로 연주가 계묘년(癸卯年)이다. 17시 출생자는 입춘 후이므로 연주가 갑진년(甲辰年)이다. 띠로 치면 토끼와 용의 차이다.

연주가 다르면 연간(年干)이 다르고, 연간이 다르면 연주의 십신이 달라진다. 그리고 연주의 십신은 "조상궁"이라 불리며 초년운과 사회적 환경에 대한 해석에 영향을 미친다. 1분의 차이가 해석 전체의 톤을 바꿀 수 있는 것이다.

월주에서도 같은 상황이 발생한다. 2024년 경칩은 3월 5일 10시 23분이다. 이 시각을 기준으로 사주의 월이 바뀐다. 절기 경계에서 태어난 사람에게는 분 단위 정밀도가 "다른 사주"를 의미한다.

이런 사례들이 "대략적인" 절기 데이터가 아니라 KASI 수준의 정밀 데이터가 필수인 이유다. "2월 4일이면 입춘"이라는 정보만으로는 경계 시각의 판정이 불가능하다.

AI가 라이브러리 비교를 표로 정리해준 경험

만세력 구현 과정에서 AI 협업이 특히 효과적이었던 순간이 있다. 절기 데이터 확보 방법을 조사할 때, Claude에게 "JavaScript/TypeScript 생태계에서 한국 절기 데이터를 다루는 방법을 비교해줘"라고 요청했다.

AI가 정리해준 비교표에는 NPM 패키지, KASI 공공 API, 직접 계산(천문학 공식) 등 여러 선택지가 장단점과 함께 나열되었다. 각 옵션의 정밀도, 데이터 범위, 유지보수 상태, 한국어 지원 여부가 한눈에 비교 가능했다. 이 표를 보는 순간 "KASI 데이터를 빌드 타임에 수집하는 것이 최선"이라는 결론이 자연스럽게 도출됐다.

만약 이 비교를 혼자 했다면, 각 라이브러리를 설치하고 문서를 읽고 테스트 코드를 돌려보는 데 최소 반나절은 걸렸을 것이다. AI가 10분 만에 비교표를 만들어준 덕분에, 그 시간을 실제 구현에 투입할 수 있었다. 물론 AI의 비교가 100% 정확하다고 믿지는 않았다. 최종 선택한 방식에 대해서는 직접 코드를 작성하고 검증했다. 하지만 "선택지를 좁히는 단계"에서의 효율은 압도적이었다.

이 경험은 AI 협업의 가장 실용적인 패턴 중 하나를 보여준다. AI에게 "결정"을 맡기는 것이 아니라, "비교 분석"을 맡기고 "결정"은 사람이 하는 것이다. AI는 정보를 빠르게 수집하고 구조화하는 데 탁월하고, 사람은 프로젝트의 맥락과 제약 조건을 고려하여 최종 판단을 내린다.

데이터 무결성 검증

빌드 타임에 수집한 데이터가 실제로 정확한지 어떻게 확인할 수 있을까. 두 가지 검증 방법을 적용했다.

첫째, 알려진 값과의 대조다. 특정 연도의 입춘, 경칩 등의 시각을 KASI 웹사이트에서 직접 확인하고, JSON에 저장된 값과 일치하는지 비교했다. 최소 10개 연도를 샘플링하여 교차 검증을 수행했다.

둘째, 전문 만세력 앱과의 비교다. 1편에서 벤치마킹한 앱들이 표시하는 절기 시각과 우리 데이터를 대조했다. KASI 데이터를 사용한다고 명시한 앱들과는 결과가 정확히 일치했고, 그렇지 않은 앱들과는 간헐적으로 1~2분의 차이가 발견됐다. 이 차이가 곧 "데이터 소스의 차이"이며, KASI 기준을 선택한 것이 올바른 결정이었음을 확인해주는 근거가 됐다.

데이터 정확도에 대한 이런 집착이 과하다고 느낄 수 있다. 하지만 사주 앱에서 만세력 데이터는 건물의 기초와 같다. 기초가 1cm 어긋나면 10층에서는 수십 cm가 어긋난다. 절기 시각이 1분 틀리면 경계에서 태어난 사람의 사주 전체가 틀려진다. 기초 데이터에 대한 검증은 아무리 해도 과하지 않다.

이 과정에서 배운 것

첫째, 데이터의 출처가 곧 앱의 신뢰도다. 같은 "2024년 입춘 2월 4일 16시 27분"이라도, KASI에서 가져온 것과 출처 불명의 인터넷 테이블에서 가져온 것은 신뢰의 무게가 다르다.

둘째, 빌드 타임 데이터 수집은 소량의 정적 데이터를 다루는 경우에 매우 효과적인 전략이다. 3,120개의 절기 데이터를 런타임에 API로 호출할 이유가 없다.

셋째, AI의 비교 분석 능력은 "선택지를 좁히는 단계"에서 가장 큰 가치를 발휘한다. 최종 결정은 사람이 하되, 결정에 필요한 정보의 수집과 구조화는 AI에게 맡기는 것이 효율적이다.

넷째, 데이터 무결성 검증은 자동화와 수작업을 병행해야 한다. 스크립트로 형식 검증을 하고, 사람이 직접 샘플을 대조 확인하는 이중 검증이 신뢰도를 높인다.

다음 편 예고

만세력의 데이터는 확보했다. 하지만 사주 계산에는 "시각 보정"이라는 또 다른 벽이 있다. 한국 표준시와 실제 태양 위치의 차이에서 오는 진태양시 보정, 한국이 과거에 시행했던 서머타임, 그리고 자시(子時)를 둘로 쪼개는 야자시 문제까지. 8편에서는 이 세 가지 보정이 시주를 바꾸는 현실과, "규칙의 모호함"이 알고리즘 복잡도보다 더 어려운 이유를 다룬다.