타로 다음, 사주 — "이건 차원이 다른 복잡도다"

"혹시 사주에 필요한 데이터를 가지고 있어? 사주 프로그램을 만들고 싶어."

타로 마스터 프로젝트를 끝낸 직후였다. 20편의 개발기를 쓸 만큼 충분히 배운 프로젝트였고, AI 협업 개발이라는 방식에 대한 확신도 생겼다. 자연스럽게 다음 주제가 떠올랐다. 그런데 프로젝트를 시작하자마자 한 가지 사실이 분명해졌다. 이건 타로와는 차원이 다른 복잡도라는 것이다.

왜 사주였나

타로 마스터를 완성하고 나니, 비슷한 영역에서 더 도전적인 주제를 찾고 싶었다. 동양 철학 기반의 분석 도구. 관심 분야를 떠올리다 보니 사주명리가 자연스럽게 후보에 올랐다.

사주는 개인적으로도 흥미가 있는 주제였다. 생년월일시만으로 사람의 성향과 운의 흐름을 분석한다는 체계. 수천 년간 축적된 동양의 분류 시스템이 현대의 코드로 옮겨질 수 있을까? 그 궁금증이 프로젝트의 출발점이었다.

타로 프로젝트에서 경험한 AI 협업의 효용도 한몫했다. 타로에서는 78장 카드의 해석 데이터를 AI가 생성하고, 리딩 로직을 함께 설계했다. 그 경험이 좋았기에, 더 복잡한 도메인에서도 같은 방식이 통할지 시험해보고 싶었다.

타로와 사주의 근본적 차이

타로는 복잡한 프로젝트였지만, 구조 자체는 비교적 단순했다. 78장의 카드가 있고, 각 카드에 정방향과 역방향 해석이 있고, 리딩 방식에 따라 카드를 배치한다. 데이터 모델로 보면 카드 78개, 해석 텍스트 156개, 리딩 레이아웃 3~4가지. 이게 전부다.

사주는 출발선부터 다르다. 천간 10개, 지지 12개. 여기까지는 단순해 보인다. 그런데 이 22개의 글자가 만들어내는 조합과 관계의 그물망이 문제다.

60갑자 — 천간과 지지의 조합으로 만들어지는 60개의 간지. 오행 — 목화토금수 다섯 가지 기운과 상생상극 관계. 십신 — 일간을 기준으로 나머지 글자들과의 10가지 관계. 지장간 — 지지 안에 숨어 있는 천간. 12운성 — 오행의 에너지가 태어나서 죽고 다시 시작되는 12단계 생명주기. 그리고 합충형파해 — 글자들 사이의 다양한 상호작용. 천간합, 삼합, 방합, 육합, 육충, 형, 파, 해.

타로가 "78장의 카드"였다면, 사주는 "22개 글자가 만들어내는 관계의 우주"다. 데이터의 양이 아니라 관계의 복잡도가 차원이 다르다.

AI에게 던진 첫 질문

"혹시 사주에 필요한 데이터를 가지고 있어? 사주 프로그램을 만들고 싶어."

이 한 문장을 Claude에게 던졌을 때, 타로 때와는 확연히 다른 반응이 돌아왔다. 타로에서는 비교적 빠르게 구조가 정리됐다. 사주에서는 AI가 먼저 도메인의 지형도를 펼쳐 보여줬다.

천간지지 체계, 60갑자, 오행의 상생상극, 십신 분석, 지장간 체계, 12운성, 합충형파해. 10분도 안 되는 시간에 사주명리의 핵심 구성 요소가 목록으로 나열됐다. 각 요소가 무엇인지, 서로 어떻게 연결되는지, 프로그래밍에서 어떤 구조로 표현해야 하는지까지.

이 순간이 프로젝트의 첫 번째 전환점이었다. 도메인의 전체 지형이 한눈에 보이자, "이걸 내가 만들 수 있을까"라는 막연한 불안이 "이 순서로 하나씩 구현하면 되겠구나"라는 구체적인 계획으로 바뀌었다. 물론 그 계획이 얼마나 순탄치 않을지는 아직 모르고 있었다.

AI가 던진 세 가지 핵심 질문

도메인 지형도를 펼친 후, Claude는 세 가지 핵심 질문을 던졌다. 이 질문들이 프로젝트의 방향을 결정지었다.

첫 번째, "풀이 엔진을 어떻게 구현할 것인가?" 순수 룰 기반으로 갈 것인가, AI에게 맡길 것인가, 아니면 둘을 섞을 것인가. 이 질문의 핵심은 사주 분석의 어디까지를 코드로 정확하게 계산하고, 어디부터를 AI의 자연어 해석에 맡길 것인가 하는 경계선이었다.

두 번째, "프로젝트의 목표 수준은?" 학습용 프로토타입으로 충분한가, 아니면 실제 서비스 수준을 목표로 하는가. 이 질문은 만세력 정확도, UI/UX 완성도, 해석의 깊이 등 모든 후속 결정에 영향을 미쳤다.

세 번째, "만세력 데이터를 어떻게 처리할 것인가?" 직접 계산할 것인가, 오픈소스 라이브러리를 쓸 것인가, 외부 API를 호출할 것인가. 사주 분석의 첫 단계는 생년월일시를 사주 팔자로 변환하는 것인데, 이 변환에 필요한 만세력 데이터가 프로젝트의 기술적 기반이 된다.

하이브리드 아키텍처를 선택한 이유

첫 번째 질문에 대한 답은 "하이브리드"였다. 룰 기반 엔진과 AI 해석을 모두 사용하는 구조.

이 결정에는 명확한 이유가 있었다. 사주명리에서 "계산"과 "해석"은 성격이 완전히 다르다. 천간과 지지의 오행 배속, 십신 관계 판별, 합충 여부 판단 같은 것들은 명확한 규칙이 있다. 갑(甲)은 목(木)이고, 갑과 기(己)는 합이 되고, 인묘진(寅卯辰)은 방합이다. 이런 것들은 코드로 정확하게 구현해야 한다.

반면, "이 사주의 전체적인 흐름이 어떤가", "이 합이 이 사람의 삶에서 어떤 의미인가" 같은 종합 해석은 맥락과 뉘앙스가 중요하다. 여기는 AI의 자연어 생성 능력이 훨씬 효과적이다.

룰 기반 엔진이 정확한 분석 데이터를 생성하고, AI가 그 데이터를 바탕으로 사람이 읽을 수 있는 종합 해석을 생성한다. 두 계층이 각자의 강점을 발휘하는 구조다. 이 결정이 프로젝트 아키텍처의 근간이 됐다.

실서비스 수준을 목표로

두 번째 질문에 대한 답은 "실서비스 수준"이었다. 학습용 프로토타입으로 시작할 수도 있었지만, 타로 프로젝트에서의 경험이 욕심을 키웠다.

실서비스 수준을 목표로 한다는 것은 구체적으로 이런 의미였다. 만세력 변환이 정확해야 한다. 단순히 음력/양력 변환이 아니라, 절기 기준의 월 결정, 진태양시 보정, 서머타임 처리, 야자시 판단까지 포함해야 한다. UI/UX가 실제 사용자가 쓸 수 있는 수준이어야 한다. 해석의 깊이가 "장난감" 수준을 넘어야 한다.

이 결정이 프로젝트의 난이도를 크게 높였다. 하지만 돌이켜보면 이 결정이 옳았다. "대충 돌아가는 프로토타입"은 만드는 과정에서도, 완성한 후에도 배울 것이 적다. 정확도를 추구하는 과정에서 도메인의 깊은 곳까지 파고들게 되고, 그 과정이 진짜 배움이 된다.

오픈소스 만세력 라이브러리

세 번째 질문, 만세력 처리 방식에 대한 답은 "오픈소스 라이브러리"였다. korean-lunar-calendar라는 npm 패키지를 기반으로 하되, 절기 데이터는 한국천문연구원(KASI) 데이터를 별도로 사용하기로 했다.

만세력을 직접 구현하는 것은 가능하지만, 이 프로젝트의 핵심은 만세력 자체가 아니라 사주 분석 엔진이다. 만세력은 "정확한 입력 데이터를 만드는 도구"일 뿐이다. 여기에 개발 리소스를 쏟는 것보다, 검증된 라이브러리를 사용하고 분석 엔진에 집중하는 것이 합리적이었다.

다만 라이브러리를 그대로 쓰는 것으로 끝나지는 않았다. 절기 기반의 월 결정은 라이브러리가 제공하지 않는 기능이었고, 진태양시 보정과 서머타임 처리도 직접 구현해야 했다. 이 부분의 이야기는 이후 편에서 자세히 다루겠다.

10분 만에 그려진 지형도의 가치

돌이켜보면, 이 프로젝트에서 가장 중요한 순간은 AI에게 첫 질문을 던지고 10분 만에 도메인 지형도가 그려진 그 순간이었다. 사주명리라는 방대한 도메인의 전체 윤곽이 한눈에 보이는 순간, "이걸 할 수 있겠다"는 확신이 생겼다.

타로 프로젝트에서도 비슷한 경험을 했다. 하지만 사주에서의 그 10분은 타로 때보다 훨씬 가치가 컸다. 사주명리는 독학으로 지형도를 그리려면 몇 주가 걸릴 수 있는 도메인이다. 천간지지가 뭔지 이해하고, 오행이 뭔지 파악하고, 십신이 뭔지 알아보고, 그것들이 어떻게 연결되는지까지 스스로 정리하려면 상당한 시간이 필요하다.

AI는 그 시간을 10분으로 압축해줬다. 물론 각 요소의 깊은 이해는 직접 구현하면서 쌓아야 했다. 하지만 전체 지형을 먼저 보고 세부로 들어가는 것과, 세부에서 시작해 전체를 그려나가는 것은 효율에서 하늘과 땅 차이다.

이 과정에서 배운 것

첫째, 프로젝트의 복잡도는 데이터의 양이 아니라 관계의 밀도가 결정한다. 타로의 78장보다 사주의 22글자가 훨씬 복잡한 이유는, 글자들 사이의 관계가 다층적으로 얽혀 있기 때문이다.

둘째, 도메인이 복잡할수록 "전체 지형도를 먼저 그리는 것"의 가치가 커진다. AI가 10분 만에 펼쳐준 사주명리의 지형도는, 이후 모든 설계와 구현의 나침반이 됐다.

셋째, AI에게 좋은 답을 얻으려면 좋은 질문이 필요한 게 아니다. 솔직한 질문이면 충분하다. "사주 프로그램을 만들고 싶어"라는 솔직한 한 문장이 프로젝트 전체의 방향을 잡아줬다.

다음 편 예고

프로젝트의 방향은 잡혔다. 하이브리드 아키텍처, 실서비스 수준, 오픈소스 만세력. 그런데 개발을 시작하기 전에 한 가지 충격적인 사실을 발견했다. 같은 생년월일시를 넣어도 사주 앱마다 결과가 다르다는 것이다. 도대체 왜? 정답이 여러 개인 도메인에서 어떻게 설계해야 하는지, 2편에서 이어진다.