주역(I Ching) 멀티에이전트 AI 구축기 (2일차: 괘 도출 엔진 & 시뮬레이션)

안녕하세요! 퇴근 후 취미로 코딩하고 있는 직장인 바이브코더입니다.

 

1일 차에 PostgreSQL 인프라와 테이블 설계를 세팅한 데 이어, 오늘은 주역 점법의 핵심 알고리즘인 '괘 도출 규칙 엔진'을 이식했습니다. 

주역은 데이터가 어설프게 꼬여도 AI가 워낙 그럴듯하게 환각(Hallucination)을 지어내기 쉽습니다(이전에 한번 겪어봤네요). 그래서 눈으로 대충 검증하는 편한 길 대신

기계적으로 껍데기까지 탈탈 터는 전수 대조 테스트와 통계 검증을 거쳤습니다. 

 

 

🛠️ My Vibe Coding Stack

- Local Dev: Mac Mini M4 Pro + Ollama + Docker Compose

- Database: PostgreSQL 16 + pgvector (iching-db)

- Model: Gemma 4 26B (MoE)

- AI Assistants: Google Antigravity + Claude Code

 

📝 오늘의 작업 결과

Claude Code및 구글 안티그래비티의 보조를 받으며 괘 도출 엔진의 무결성을 극한까지 검증하고 데이터 클렌징을 마쳤습니다.

 

1. 주자(朱子) 점법 규칙 엔진 구현 완료 (변효 개수 0~6개에 따라 참조할 괘사·효사 자동 조건 분기)

2. 40만 회 시뮬레이션 기반 확률 분포 실측 통과 (시초점 특유의 비대칭 확률 7/16이 이론값과 정확히 일치)

3. 64괘 이진코드 및 4,096가지 모든 변효 조합 전수 검사 완료 (오류 0)

4. (덤) IDE 멈춤을 유발하던 원격 MCP 서버 무한 로딩 연결 버그 디버깅 완료

 

🔍 데이터와 엔진에서 때려잡은 위험한 버그들

아래 오류들은 그냥 넘어갔다면 나중에 상담 AI가 그럴듯하게 엉뚱한 원문을 인용하는 시점에나 발견되어 디버깅 지옥을 선물했을 녀석들입니다.

 

1. 384효가 아니라 386효였다 (用九와 用六의 누락)

   64괘 × 6효 = 384효로 흔히 알고 있지만, 건괘의 用九와 곤괘의 用六이 별도로 존재합니다. 기존 JSON 데이터를 교차 검증해 보니 건괘 用九 데이터의 효사와 소상전 텍스트가 지저분하게 한 줄로 붙어 유실된 것을 확인했습니다.

데이터 파서와 원본 JSON을 동시에 교정했습니다.

 

2. Latin-1 인코딩 오류로 깨진 고한자(𤨏) 복원

   56번 화산려 괘 원문 중 '旅ð¤¨ð¤¨'로 깨져 들어온 4바이트 확장 한자가 있었습니다. 바이트를 정밀 추적하여 U+24A0F인 '𤨏'(자잘할 쇄, 瑣의 이체자)를 찾아내 '旅瑣瑣'로 완벽히 복원했습니다.

 

3. "실패하지 않는 테스트는 가짜다"

   6효가 모두 변할 때 원래는 지괘의 괘사만 봐야 하는데 엔진이 둘 다 반환하던 조용한 로직 버그를 수정했습니다. 더불어 엔진과 DB의 이진 맵이 조금이라도 어긋나면 빌드가 터지도록 의도적인 '실패 테스트'를 심었습니다.

실패해 볼 줄 모르는 테스트는 없는 것과 마찬가지니까요.

 

💬 바이브코더분들께 드리는 질문!

이제 3단계 '괘사·효사 한글 번역 386건' 배치 작업으로 들어갑니다. (현재 원문은 한문만 있고 번역문이 아예 비어 있는 생날것 상태입니다.)

 

1. 386개의 까다로운 고전 한문 원문을 LLM API 배치로 한글 번역하려 합니다. 번역 시 프롬프트 튜닝이나 번역 결과물의 톤앤매너 일관성을 지키는 자신만의 노하우가 있으신가요?

2. LLM 배치 처리 시, API 레이트 리밋(Rate Limit)을 안전하게 우회하며 병렬 처리를 매끄럽게 쏘는 파이프라인 팁이 있다면 아낌없이 훈수 부탁드립니다! 👇