헤르메스 1단계 — 명식 파싱 Skill 만들기 부제: 시주|일주|월주|연주를 확정하는 에이전트용 업무 설명서 (판단층 스킬)
블루스 · 에이전트 / 노코드 자동화 · · 좋아요 0 · 답글 0
연재 업무를 스킬로 가르치는 에이전트 하네스 7/8편
2-1. 매번 반복하던 그 설명
10년간 명리 상담을 하면서, 사주를 세우기 전에 늘 같은 것을 확인했습니다.
"양력입니까 음력입니까" → "몇 시입니까, 그 시간은 병원 기록입니까 기억입니까" → "출생지가 어디입니까" → "그해에 서머타임이 있었습니까" → "절기 경계일에 걸리지는 않습니까"
이 다섯 가지를 확인하지 않고 세운 사주는, 아무리 정교하게 통변해도 출발점이 틀린 통변입니다. 그런데 이 확인 절차는 지금까지 제 머릿속에만 있었습니다. 문서로도 없었고, 코드로도 없었고, LLM에게 시킬 때마다 매번 말로 다시 설명했습니다.
23기 커리큘럼 WEEK1의 과제 — "내가 매번 설명하던 일을 에이전트용 업무 설명서로 바꾼다" — 는 정확히 이 지점을 겨냥합니다. 헤르메스 6노드 중 가장 앞단인 N1(명식 파싱) 을 첫 Skill로 잡은 이유입니다.
2-2. 왜 하필 파싱부터인가 — 정량적 근거
"명식 파싱쯤은 LLM이 알아서 하지 않나"라고 생각하기 쉽습니다. 그 생각이 틀렸다는 것을 저는 이미 데이터로 확인했습니다.
프로젝트 초기에 작성한 「LLM 절기 계산 오류 종합보고서 v1.0」에서, 1920~2025년 106년간의 입춘(立春) 시각을 KASI(한국천문연구원) 기준값과 대조했습니다.
LLM
절대평균 오차
완전일치
추정 원인
ChatGPT (중국천문대 참조)
61.6분
11건
1920~2000년 일괄 60분 오차
Gemini (자체 계산)
450.7분 (약 7.5시간)
0건
UTC → KST 변환 누락 추정
Claude (ephem 라이브러리)
677.5분 (약 11.3시간)
0건
한국 역사적 시간대 변경 미반영
Claude는 1920년대 구간에서 최대 1,589분(약 26시간) 오차까지 냈습니다. 하루가 통째로 어긋나면 일주(日柱)가 바뀌고, 입춘 근처면 연주(年柱)와 월주(月柱)까지 함께 바뀝니다. 8글자 중 최대 6글자가 달라지는 것입니다.
여기서 도출한 원칙: 절기 시각은 LLM이 계산할 대상이 아니라 조회할 대상이다. 韓바둑 시스템은 KASI 실측 DB(107년, 12절기)를 절대 기준으로 삼는다.
2-3. 이 스킬의 계층 — 판단층
v2.0에서 12편 전체를 관통하는 프레임으로 정식 편입한 스킬 3계층(규율 / 판단 / 조립) 중, N1은 판단층에 속합니다.
계층
정의
N1에서의 의미
규율층
어기면 안 되는 규칙을 구조에 박는 문지기
(6편 GuardrailAgent가 담당)
판단층
근거를 갖고 해석하되 "근거불충분" 탈출구를 반드시 두는 층
불확실하면 추정하지 말고 warnings로 선언
조립층
하위 스킬을 재작성하지 않고 호출로만 엮는 층
(4·7·10편이 담당)
판단층 스킬의 성패는 정확도가 아니라 "모르는 것을 모른다고 말하는 구조가 있는가" 에 달려 있습니다. 이것은 반성문 총괄표 v3.7의 제1교훈("모르면 아는 척 금지")을 스킬 명세 수준으로 내린 것입니다.
3-1. 사용 도구
도구
역할
비고
LangGraph
N1 노드 실행
기존 11노드 파이프라인은 수정하지 않음 — 헤르메스는 사이드카
PostgreSQL 18.1
profiles 19컬럼 저장
hanbadook_production
KASI 절기 DB
절기 경계 판정 절대 기준
107년 · 12절기 실측
Claude Opus 4.5
판단·조립 (claude-opus-4-5-20251101)
결정적 계산은 맡기지 않음
myeongsik-normalizer v0.2.0
표기 정규화 (Hermes native candidate)
W1 확장과제 산출물
3-2. Skill 6요소 정의
클로더즈 Skill 표준 6요소(사용 조건 / 입력 / 작업 순서 / 출력 형식 / 주의사항 / 완료 기준)로 명세를 고정했습니다.
yaml
# skill_n1_parse_saju.yaml
name: 명식 파싱
layer: 판단 # 규율 / 판단 / 조립 중 판단층
node: N1
version: 0.3.0
사용조건:
- 사용자가 사주 통변을 요청할 때 최초 1회
- 이미 profiles에 확정 레코드가 있으면 재파싱하지 않고 조회로 대체
negative_trigger:
- 통변 해석·길흉 판단에는 사용하지 않는다 (그건 N4~N6의 일)
입력:
필수: [birth_date, birth_time, gender, birth_type] # birth_type: 양력/음력
선택: [longitude, summer_time_applied, time_correction_minutes]
결측허용: birth_time # "시 불명" 허용 → 시주만 미확정 처리
작업순서:
1. 입력 정합성 검사 (음력이면 윤달 여부 확인)
2. 절기 경계 판정 — KASI DB 조회 (황경 λ 기준, 겉보기태양) # 적경 α 아님
3. 시간대 계층 확정 — 표준시 → 지방시 → 진태양시 (혼용 금지)
4. 서머타임 적용 여부 확인 (해당 연도 시행 이력 조회)
5. 60갑자 룩업으로 4주 확정 (연두법·일두법 제약 검사)
6. 표기 정규화 — myeongsik-normalizer 호출
출력형식:
saju: {hour: .., day: .., month: .., year: ..} # 표시는 時|日|月|年
confidence: {year: .., month: .., day: .., hour: ..}
warnings: []
evidence: {jeolgi_source: "KASI", record_id: ..}
주의사항:
- 표준시 / 역학시 / 지방시를 섞지 않는다
- 절기 경계 ±1일은 무조건 warnings 플래그
- 서머타임 시행 여부를 스스로 추정하지 않는다 (조회 실패 시 warnings)
- 추정 금지 — 불확실은 warnings로 선언 (근거불충분 탈출구)
- 4관법 금기어(격국·용신·기신·희신)는 이 노드에서 등장할 일이 없다.
등장하면 해석이 섞인 것이므로 즉시 중단
완료기준:
- 4주가 모두 확정되었거나, 미확정 기둥이 warnings에 명시되었을 것
- evidence에 절기 판정 근거 레코드 ID가 남아 있을 것설계 포인트 1 — confidence를 기둥별로 쪼갠 이유. 초안(v0.1)에서는 신뢰도가 명식 전체에 하나였습니다. 그러면 "시각만 불확실한 사주"와 "연주까지 흔들리는 사주"가 같은 등급으로 묶입니다. 실제로는 시주 하나만 불명인 경우가 압도적으로 많고, 그건 부분 활용이 가능합니다. 기둥별로 분리하니 하류 노드가 "시주를 근거로 쓰지 말 것"을 판단할 수 있게 됐습니다.
설계 포인트 2 — negative_trigger를 명세에 넣은 이유. 스킬이 늘어나면 라우팅 충돌이 생깁니다. "이 스킬이 하지 않는 일"을 명시해야 조립층(4편 엄브렐러 Tree)에서 오호출을 막을 수 있습니다.
3-3. 핵심 프롬프트 전문
text
당신은 명식 파싱기다. 해석은 하지 않는다. 아래 규칙을 지켜라.
[계산 규칙]
1. 절기는 황경(λ) 기준으로만 판단한다. 적경(α)을 쓰지 않는다.
2. 겉보기태양을 사용한다. 평균태양을 쓰지 않는다.
3. 절기 시각은 스스로 계산하지 않는다. KASI DB 조회 결과만 사용한다.
조회 실패 시 계산으로 대체하지 말고 즉시 중단하고 사유를 남긴다.
4. 표준시·역학시·지방시를 한 문장 안에서 섞지 않는다.
어느 계층의 시각인지 항상 명시한다.
[출력 규칙]
5. 사주는 시주|일주|월주|연주 순서(오른쪽→왼쪽)로 출력한다.
6. 기둥별 confidence를 0.0~1.0으로 각각 부여한다.
[탈출구 규칙]
7. 절기 경계 ±1일이면 warnings에 "경계일 확인 필요"를 남긴다.
8. 해당 연도의 서머타임 시행 여부를 모르면 추정하지 말고
warnings에 "서머타임 확인 필요"를 남긴다.
9. 확신이 없으면 그럴듯한 답을 만들지 말고 warnings에 기록한다.
빈칸으로 남기는 것이 틀린 값을 채우는 것보다 낫다.
입력: {birth_info}7~9번이 이 프롬프트의 핵심입니다. 1~6번은 어느 파싱기에나 있는 규칙이고, 판단층 스킬을 판단층답게 만드는 것은 7~9번의 탈출구입니다.
3-4. myeongsik-normalizer — 결정적 처리의 분리
버전 이력. 이 스킬은 W1 과제를 거치며 세 번 바뀌었습니다.
버전
시점
무엇이 바뀌었나
계기
v0.1.0
W1 기본과제 최초 작성
7필드 구조 확정
—
v0.1.1
첫 실행 직후
Output 필드만 수정 — 일주(日)에 ★ 표시 + 순서 안내 한 줄
실행 관찰(§4-3 7번)
v0.2.0
W1 확장
Hermes native 구조로 전환
이식성 확보
v0.1.0 → v0.1.1은 강의자료 35장의 수리 원칙("전체 rewrite 대신 실패한 한 곳만")을 그대로 따른 사례입니다. 진단표의 "결과 모양이 다름 → output contract"에 걸린 항목 하나만 고쳤고, trigger·input·decision·verification은 손대지 않았습니다.
배포 스킬은 수정하지 않았습니다. W1 기본과제 스킬(제작: 클로더즈 지아코모 안재흥 스터디장, 개인 학습용)의 안내를 받되, 제 업무용 스킬은 별도 candidate로 새로 만들었습니다. 원본을 고쳐 쓰면 다음 주 배포본과 어긋나기 때문입니다.
7필드 구조 — 기본과제에서 확정한 형태이며, 강의자료 18장의 5질문에 QA와 실패 복구를 더한 것입니다.
필드
핵심
18장 5질문 대응
Use when
8글자+생년월일+성별이 뒤섞인 텍스트를 표준 표기로 통일할 때 (해석·길흉 제외)
01 사용 조건
Input
이름·생년월일·시각·성별·8글자. 민감값은 [REDACTED]
02 입력
Judgment
입력은 연→월→일→시로 해석, 출력은 뒤집어 時|日|月|年. 불확실은 [가설]/not_checked
(판단)
Steps
분리 → 8글자 확인 → 2글자 배열 → 표기 뒤집기 → 출처 조립 → QA
03 순서
Output
4기둥 표 + 표준형 출처 한 줄
04 출력
QA / verifier
5항목 (아래)
05 완료
Failure repair
3유형 부분 처리 (아래)
(확장)
v0.2.0 전환의 핵심은 "LLM에게 시킬 일과 코드에게 시킬 일을 나눈 것" 입니다.
처리
담당
이유
8글자 검증 · 2글자 분할 · 순서 뒤집기
scripts/normalize.py
결정적 연산 — LLM이 하면 매번 흔들림
입력 분리 · 결측 판단 · 표시 조립
LLM
자연어 입력의 모호성 처리
출력 서식
templates/output-format.md
진실은 한 곳에서만 관리
규칙 상세
references/normalization-rules.md
SKILL.md 비대화 방지
frontmatter에는 라우팅 3요소를 명시했습니다.
yaml
routing:
trigger: "명식 정규화."
negative_trigger: "통변 해석·길흉 판단."
differentiator: "표기 정규화만 — 해석은 하지 않음."differentiator가 있어야 나중에 스킬이 20개, 30개로 늘어났을 때 라우터가 "이 스킬과 저 스킬의 차이"를 판단할 수 있습니다.
QA verifier 5항목 — 스킬이 스스로 자기 출력을 검사합니다.
□ 기둥 순서가 時|日|月|年 인가
□ 입력 8글자가 출력에 8/8 보존되었는가
□ 출처가 표준형 `이름(YYYY.M.D H시/성별/8글자)` 인가
□ 추정으로 채운 값이 없는가
□ 해석이 섞이지 않았는가Failure repair — 실패해도 전량 폐기하지 않고 부분 처리합니다.
실패 유형
처리
8글자가 아님
글자 수 명시 후 확인 가능한 기둥만 출력
시각 불명
시주 미확정 표기, 나머지 3주는 정상 처리
한자 근거 없음
[가설] 표기 후 진행, 확정하지 않음
3-5. 실행 — 실제로 돌린 것과 아직 안 돌린 것
두 구간을 반드시 구분합니다. 이 스킬이 다루는 범위는 표기 정규화이고, N1 전체는 절기·지방시·60갑자 계산까지 포함합니다. 앞은 실행했고 뒤는 안 했습니다.
구간
담당
실행 상태
표기 정규화 (8글자 분할·순서 뒤집기·출처 조립)
myeongsik-normalizer
실행 1회 (simulation_only)
절기 경계 판정 · 지방시 보정 · 60갑자 룩업
N1 본체
미실행
(A) 실제 실행 — 큰딸 명식 (W1 기본과제 증거)
작은 안전 입력으로 가족 명식 중 공개 가능한 건을 넣었습니다.
입력:
큰딸 1985.5.13 6시 여 을축신사임자계묘출력:
時 | 日 | 月 | 年
계묘 | 임자 ★ | 신사 | 을축
★ = 일주(日, 본인 기준). 표기는 오른쪽→왼쪽.
출처: 큰딸(1985.5.13 6시/여/을축신사임자계묘)검사 항목
결과
기대 결과 계묘|임자|신사|을축 과 일치
✅
입력 8글자 보존
8/8 ✅
출처 표준형
✅
추정으로 채운 값
없음 ✅
해석 혼입
없음 ✅
입력이 연→월→일→시 순(을축·신사·임자·계묘)으로 들어왔고, 출력은 뒤집혀 시→일→월→연으로 나왔습니다. 매번 손으로 바로잡던 일이 규칙으로 굳은 지점입니다.
★ 표시는 처음부터 있던 것이 아닙니다. 첫 실행에서 발견해 붙인 것입니다(§4-3 7번).
(B) 미실행 — 설계 의도만 있는 구간
아래는 아직 돌리지 않은 설계 예시입니다. 실행 결과가 아니므로 증거로 쓰지 않습니다.
입력: (교수님 본인 명식 — 서머타임 시행기에 걸치는 케이스)
기대 동작:
warnings:
- [서머타임] 해당 연월일이 한국 서머타임 시행 이력 확인 구간에 해당.
시행 여부에 따라 시각이 1시간 당겨질 수 있고, 이 경우 시주가 변동됨.
→ 자동 추정하지 않음. 법령·KASI 기록 확인 필요.
- [지방시] longitude 미입력. 표준시(동경 135°) 기준 처리.
confidence: {year: 1.0, month: 1.0, day: 1.0, hour: 0.6}여기서 확인하려는 것은 시주 confidence가 1.0으로 올라가지 않는가입니다. 입력에 시주가 명시돼 있어도 서머타임 확인 전까지 유보해야 합니다. 탈출구가 실제로 작동하는지는 돌려봐야 압니다.
강의자료 32장은 첫 실행을 "성능 평가가 아니라 업무 설명서의 빈칸을 찾는 실험"이라고 규정합니다. (B)를 돌리는 것이 다음 실험입니다.
개인정보 처리. (A)의 큰딸 명식은 비밀정보가 없어 공개 가능으로 판단해 기본과제에 그대로 실었습니다. (B)는 교수님 본인 명식이라 본 상세본에서는 생년월일시를 뺐습니다. 강의자료 38장의 "공개 전 개인정보 제거"에 따른 조치입니다.
3-6. profiles 테이블 연결
파싱 결과는 profiles 19컬럼에 저장됩니다. 이 스키마가 이미 판단층 원칙을 반영하고 있습니다.
컬럼
역할
birth_type
양력/음력 구분 — 추정하지 않고 반드시 입력받음
birth_longitude
지방시 보정 근거
summer_time_applied
불리언이 아니라 "확인됨/미확인"을 구분해 다뤄야 함
true_solar_time / local_solar_time
시간대 계층을 컬럼으로 분리 — 혼용 원천 차단
time_correction_minutes
보정값을 결과가 아니라 근거로 보존
source
test_dummy / 수동 입력 분리 — 데이터 오염 방지
true_solar_time과 local_solar_time이 별도 컬럼인 것이 중요합니다. 하나의 컬럼에 뭉뚱그렸다면 "이 시각이 어느 계층인지"를 나중에 알 수 없게 됩니다. 스키마 레벨에서 혼용을 막은 것입니다.
(이미지 자리 — profiles 조회 결과 + N1 실행 로그 캡처)
4-1. 꿀팁 3가지
① 절기 경계일 플래그 하나가 최대 오류원을 잡는다. 명식 오류의 대부분은 복잡한 논리 실수가 아니라 경계에서 하루 밀린 것입니다. ±1일 무조건 플래그라는 한 줄이 가장 비용 대비 효과가 컸습니다.
② "황경 기준, 겉보기태양"을 주의사항에 못박으면 흔들림이 준다. 같은 입력을 반복 실행할 때 결과가 미세하게 달라지던 현상이, 이 두 단어를 명세에 넣은 뒤 사라졌습니다. LLM에게 선택지를 주지 않는 것이 재현성의 조건입니다.
③ 결정적 연산은 코드로 내려라. 8글자 분할과 순서 뒤집기를 LLM에게 맡겼을 때, 100회 중 몇 번은 순서가 반대로 나왔습니다. normalize.py로 내린 뒤 그 오류는 0이 됐습니다. LLM은 판단에 쓰고, 계산에 쓰지 않습니다.
4-2. 판단층 원칙의 검증
첫 스킬에서 확인한 것은 단순합니다.
"확신 없으면 warnings" 탈출구가 없으면, 스킬은 반드시 그럴듯한 거짓을 만든다.
LLM은 빈칸을 싫어합니다. 명세에 "모르면 이렇게 하라"는 경로가 없으면, 스스로 가장 그럴듯한 값을 채워 넣고 그것을 확정처럼 출력합니다. 탈출구는 친절이 아니라 구조적 필수 요소입니다.
이것을 반성문 총괄표 v3.7과 대조하면 정확히 겹칩니다.
반성문 교훈
N1 스킬에서의 구현
제3-4호 "모르면 모른다고 하기"
warnings 탈출구
제6호 "역법 데이터는 추측 금지"
KASI DB 조회 실패 시 계산 대체 금지
제13호 "DB 직접 조회 필수"
절기 하드코딩 금지
제8호 "검증 없이 완료 선언 금지"
QA verifier 5항목
반성문은 사후 기록이지만, 스킬 명세는 사전 예방입니다. 34건의 반성문을 스킬 명세로 번역하는 작업이 곧 이 프로젝트의 지식관리라는 것을 1편에서 확인했습니다.
4-3. 시행착오
#
무슨 일이 있었나
어떻게 고쳤나
발견 시점
1
지방시 보정을 빠뜨려 경계일 사주가 틀림
time_correction_minutes를 선택 → 입력 필수급으로 승격, 미입력 시 warnings
설계
2
신뢰도가 명식 전체에 하나뿐이라 시주 불명과 연주 불명이 같은 등급
confidence를 기둥별로 분리
설계
3
8글자 분할을 LLM에 맡겨 순서 역전 산발 발생
scripts/normalize.py로 결정적 처리 분리
설계
4
서머타임을 "그 연도면 아마 적용"으로 자동 판단할 뻔함
추정 금지 규칙 추가 — 조회 불가 시 warnings
설계
5
SKILL.md에 규칙을 전부 적어 비대해짐
references/로 분리, SKILL.md는 라우팅·순서만
설계
6
배포 스킬을 직접 고칠 뻔함
별도 candidate로 분리 — 다음 배포본과 충돌 방지
설계
7
헤더 時|日|月|年만으로는 어느 게 일주인지 즉시 안 보임
Output 필드만 수정 — 일주에 ★ + 순서 안내 한 줄 (v0.1.0→v0.1.1)
실행 관찰
7번만 실제 실행에서 나왔습니다. 나머지 여섯은 설계 단계의 판단입니다. 이 차이가 중요합니다.
큰딸 명식에서 일주는 임자인데, 헤더가 붙어 있어도 순서 규칙(오른쪽→왼쪽)을 모르는 사람에게는 보이지 않았습니다. 만든 사람에게만 자명한 규칙이었던 것입니다. 책상에서는 절대 안 나오고, 결과를 눈으로 봐야만 나오는 종류의 문제입니다.
고칠 때는 Output 필드 하나만 건드렸습니다. 강의자료 35장의 진단표에서 "결과 모양이 다름 → output contract"에 해당하므로, trigger·input·decision·verification은 그대로 뒀습니다. 같은 입력으로 다시 돌려 임자★가 한눈에 들어오는 것을 확인했습니다.
시행착오 표에 "발견 시점" 열을 넣기를 권합니다. 설계 항목만 잔뜩 있고 실행 관찰이 하나도 없으면, 그 스킬은 아직 안 돌려본 것입니다.
4번이 가장 아찔했던 지점입니다. 통계적으로 그럴듯한 추정은 틀렸을 때 발견되지 않습니다. 경고를 남긴 오류는 고칠 수 있지만, 조용히 맞춰 넣은 오류는 통변 마지막까지 살아남습니다.
4-4. 도움이 필요한 부분
음력 윤달 예외 케이스 목록화 — 반성문 제6호(7개 연도 윤달 오류)의 재발 방지책이 아직 목록 수준에 머물러 있습니다. 규칙으로 승격시킬 방법을 찾고 있습니다.
한국 서머타임 시행 이력의 1차 사료 확보 — 2차 자료 간 기간 표기가 엇갈립니다. 관보·법령 원문 기준으로 고정하려 합니다.
confidence임계값 설정 — 몇 이하일 때 하류 노드가 해당 기둥을 근거에서 배제해야 하는지, 아직 실측 근거가 없습니다.
4-5. 첫 실행 로그 (first-run-log.md)
강의자료 33장은 "첫 실행 로그는 결과보다 판정 근거와 다음 수정 한 가지를 남긴다"고 규정합니다. 7항목 서식을 그대로 따릅니다.
#
항목
기록
01
실행 날짜 · 실행 환경 · Skill 이름
2026-07-22 (KST) / 채팅 내 시뮬레이션 (simulation_only, 설치 not_checked) / myeongsik-normalizer v0.1.0
02
사용한 입력 · 예상 결과
입력: 큰딸 1985.5.13 6시 여 을축신사임자계묘
예상: 계묘|임자|신사|을축 + 표준형 출처 한 줄
03
실제 결과
계묘|임자★|신사|을축 + 큰딸(1985.5.13 6시/여/을축신사임자계묘) — 예상과 일치
04
통과 / 실패 / 미확인 기준
통과 = QA verifier 5항목 충족 → 충족(기둥 순서·8/8 보존·출처 형식·추정 없음·해석 없음)
미확인 = Hermes/OpenClaw 실제 설치 미확인, 배포 스킬의 템플릿 참조 파일 부재
05
잘된 점 · 막힌 점
잘된 점: 뒤섞인 입력이 규칙대로 뒤집혀 나왔고 글자 손실 없음
막힌 점: 헤더만으로는 어느 게 일주인지 안 보임(§4-3 7번)
06
다음에 수정할 한 가지
완료 — Output 필드에 일주 ★ + 순서 안내 추가 (v0.1.0 → v0.1.1)
다음 한 가지 — §3-5 (B) 미실행 구간(서머타임 케이스) 1회 실행
07
최종 상태
partial
partial인 이유 — 세 가지 미충족.
실행 환경이 시뮬레이션입니다. 설치 상태가
not_checked이므로 실제 런타임에서 같은 결과가 나온다고 말할 수 없습니다.범위의 절반만 돌렸습니다. 표기 정규화는 검증됐지만, 절기·지방시·60갑자 계산 구간은 미실행입니다(§3-5 B).
watchdog 실검증이 남았습니다. 제출 시 handoff 값이
skill_decision: not_performed,watchdog_live_verification: required였습니다. 실검증 전까지는 자체 판정만 있는 상태입니다.
1회 통과했다고
pass로 올리지 않습니다. 입력 1건, 시뮬레이션, 범위 절반이면partial이 정확한 표기입니다. 강의자료 32장이 첫 실행을 "성능 평가가 아니라 빈칸 찾기"로 규정한 것과 같은 취지입니다.
4단계 판정 기준(전 편 공통).
상태
뜻
이 편의 적용
pass
예상 결과와 실제 결과가 일치
실행 환경·범위·실검증까지 충족해야 부여
partial
일부만 충족
현재 상태 — 시뮬레이션 · 범위 절반 · 실검증 미완
fail
실행됐으나 결과가 기준 미달
예: 기둥 순서 역전
not_checked
실행 자체를 하지 않음
2026-07-22 이전 상태
35장의 수리 원칙에 따라 전체 재작성이 아니라 실패한 한 곳만 고칩니다. 06번을 한 가지로 제한한 이유입니다.
< 앞으로의 계획 >
직접 연결 — 사례글 2 (N2 계통 라우팅 Skill). N1의 출력 {saju, confidence, warnings, evidence} 전체가 N2의 입력이 됩니다. 특히 warnings를 버리지 않고 그대로 넘기는 것이 핵심입니다. 경고가 파이프라인 끝까지 따라가야 최종 리포트에 "이 통변은 시주 불확실을 전제로 한다"가 남습니다.
설계 원칙 재확인. N1은 판단층이므로 앞으로도 계속 개선합니다. 다만 6편에서 만들 규율층(GuardrailAgent)은 한번 고정하면 건드리지 않습니다. 3계층을 뒤섞지 않는다 — 규율 고정, 판단만 개선이 12편 전체의 진행 규칙입니다.
기존 자산 보호. 헤르메스는 LangGraph 11노드 파이프라인의 사이드카입니다. 기존 파이프라인은 배치 360건 100% 성공 상태이며, 수정하지 않습니다. (반성문 최다 반복 패턴 = "기능 추가 시 기존 기능 파괴")
도움 받은 글
「W1 기본과제 — 명식 정규화 Skill 사례글 v1.0」(2026-07-22) — §3-5 (A)의 실행 증거, §4-3 7번, §4-5 first-run-log의 출처
W1 기본과제 스킬
w1-basic-assignment(제작: 클로더즈 지아코모 안재흥 스터디장, 개인 학습용) — 안내를 받되 배포본은 수정하지 않음「23기 W1 강의자료 요약본 v1.0」 (원자료
CANONICAL-02-agent-harness-W1-knowledge-deck.pptx) — 18장 5질문, 32·33장 첫 실행·로그, 35장 수리 원칙, 38장 개인정보 제거「LLM 절기 계산 오류 및 명리학 미신 인식 종합 보고서 v1.0」 (프로젝트 내부 자료) — §2-2 오차 수치의 출처
「韓바둑 통변 고급화 전략 v2.0 (누적통합본)」 — 5계층 구조 · 헤르메스 6노드 정의
「Claude 반성문 총괄표 v3.7」 (34건 / 18패턴) — §4-2 대조표의 출처
myeongsik-normalizerSKILL.md v0.2.0 (클로더즈 W1 확장과제 산출물)KASI(한국천문연구원) 절기 실측 데이터 — 107년 · 12절기
태그: #황경 #절기 #KASI #에이전트하네스 #헤르메스 #LangGraph #근거불충분탈출구 #판단층 #韓바둑 #명식파싱 #Skill