3. Rulebook Prompt — 명리의 순서를 규칙으로 써 보려 했다

 

[MRA 엔진 노트 흐름]
프롬프트 → 프로토콜 → 데이터/계산 → AI Studio/초기 코드 → 검증/MRA 엔진

현재 위치: 제1부 프롬프트 시대

---

어느 날의 화면

역할만으로는 부족했다.

“너는 명리 분석가다”라는 첫 줄의 선언은
AI의 말투를 바꾸는 데는 확실히 도움이 되었다.

하지만 그 말만으로는
AI가 내부에 어떤 기준을 세우고,
어떤 순서로 명조를 풀어 가는지 확인하기 어려웠다.

그래서 어느 순간부터 프롬프트의 형태가 조금씩 달라지기 시작했다.

기존의 문장 아래로 커서를 내리고,
AI에게 무엇을 먼저 보고 무엇을 나중에 판단해야 하는지
순서를 매겨 적기 시작했다.

처음에는 단출한 몇 줄뿐이었다.

• 먼저 일간을 보라.
• 월령을 확인하라.
• 신강약을 판단하라.
• 격국과 용신은 그 뒤에 보라.

그런데 예외 상황을 줄이고 지시를 구체화하며
한 줄씩 더하다 보니, 프롬프트는 점점 길어졌다.

역할을 주던 짧은 문장은
어느새 조항이 달린 작은 규칙집처럼 변해 가고 있었다.

그때는 그것을 ‘Rulebook Prompt’라고 거창하게 부르지는 않았다.

그저 AI가 중요한 판단 순서를 건너뛰는 것 같아서,
명리의 기본 순서를 하나씩 적어 넣었을 뿐이다.

---

그때 내 머리를 떠나지 않던 질문

역할을 주는 것과 절차를 주는 것은 근본적으로 달랐다.

AI에게 “너는 명리 분석가다”라고 입력하면
AI는 명리 분석가처럼 말할 줄은 알았다.

하지만 명리(命理) 판단에는
겉으로 드러나는 말투보다 더 중요한 뼈대가 있었다.

무엇을 먼저 볼 것인가.
어떤 기준을 앞세울 것인가.
어떤 판단은 보류해야 하는가.
어떤 근거가 없으면 결론으로 넘어가면 안 되는가.

이런 질문들이 계속 꼬리를 물었다.

명리 공부를 하다 보면 결국 ‘순서’로 돌아가게 된다.

사주(四柱)를 세우고, 명조(命造)를 확인한다.
일간(日干)을 보고, 월령(月令)을 본다.
오행(五行)의 세력을 살피고, 십신(十神)의 배치를 확인한다.
신강약(身強弱)을 검토하고, 격국(格局) 후보를 생각한다.
용신(用神)과 기신(忌神)은 원국(原局)의 구조를 살핀 뒤에 조심스럽게 다룬다.
대운(大運)과 세운(歲運)은 이 모든 뼈대가 선 다음에 연결한다.

그렇다면 AI에게도 이 순서를 그대로 적어 주면,
멋대로 결론을 내리지 않고 조금 더 안정적으로 판단하지 않을까.

이 소박한 질문이 Rulebook Prompt의 시작이었다.

---

무작정 부딪혀본 기록

처음에는 분석 순서를 짧고 명확하게 적었다.

1. 일간을 먼저 확인하라.
2. 월령을 기준으로 계절의 힘을 판단하라.
3. 오행의 분포와 십신의 배치를 살펴라.
4. 신강약을 판단한 뒤 격국과 용신 후보를 검토하라.
5. 대운과 세운은 원국 판단 이후에 연결하라.

이 정도만 적어도 답변의 양상은 달라졌다.

AI는 이전보다 논리적인 순서가 있는 것처럼 답했다.
항목을 나누고, 단계별로 설명하려 했다.
자유롭게 써 내려가던 답변보다 훨씬 정돈되어 보였다.

그래서 금지와 제한 규칙을 더 붙여 보았다.

• 확실하지 않은 용신은 단정하지 말라.
• 격국은 단정 짓지 말고 후보로 제시하라.
• 신강약 판단에는 반드시 근거를 붙여라.
• 대운과 세운 해석은 원국 판단을 앞지르지 말라.
• 건강, 수명, 사고 같은 내용은 절대 단정하지 말라.
• 최종 문장은 단정형이 아닌 참고형으로 작성하라.

이렇게 적다 보니 프롬프트는 점점
AI에게 던지는 ‘질문’이 아니라,
작업자가 지켜야 할 ‘업무 지침서’에 가까워졌다.

AI와 대화한다기보다
AI의 답변 범위를 좁혀 가는 느낌이었다.

처음에는 흔들리는 답변을 정돈하기 위한 임시 처방이었다.

그런데 지금 돌아보면,
프롬프트 안에 규칙을 계속 덧붙이려 했던 이 시도가
훗날 ‘프로토콜’과 ‘데이터 구조’로 넘어가게 되는 단서였다.

---

말만 번지르르한 AI 앞에서 느낀 벽

Rulebook Prompt는 분명 가시적인 효과가 있었다.

답변은 깔끔하게 정돈되었고,
AI는 단계별로 문단을 나누어 썼다.

근거를 붙이라는 지시에 맞춰
“이러하기 때문에”라는 근거 문장도 더 자주 적어냈다.

하지만 그 표면적인 깔끔함 뒤에
또 다른 문제가 숨어 있었다.

‘규칙을 적는 것’과
‘규칙이 실제로 실행되는 것’은 다른 일이었다.

AI가 “월령을 보았다”고 텍스트를 출력한다고 해서,
내부적으로 정말 월령을 기준으로 전체 판단의 기틀을 세운 것인지는
여전히 확인하기 어려웠다.

AI가 “신강약 판단의 근거”라며 그럴듯한 문장을 적어낸다 해도,
그것이 실제 계산값과 연결되어 있다는 뜻은 아니었다.

AI가 “격국은 후보로 보겠다”고 서두를 떼더라도,
문장을 이어가다 보면 어느새 하나의 결론처럼 흘러가기도 했다.

문서의 형식상으로는 절차가 생긴 것처럼 보였다.

하지만 그 절차가 실제 판단 순서로 작동했는지,
아니면 답변을 정돈해 보이게 만드는 형식으로만 쓰였는지는
구분하기 어려웠다.

이 지점이 핵심이었다.

프롬프트에 규칙을 적어 두면
AI는 그 규칙을 반영하는 듯한 문장을 만들 수 있다.

하지만 프롬프트 창에 텍스트로 적어 두었다는 사실만으로
그 글이 계산 절차처럼 고정될 수는 없었다.

Rulebook Prompt는 역할 부여보다는 한 걸음 나아갔지만,
엔진이 될 수는 없었다.

---

생각의 궤도를 수정하다

이때부터 프롬프트를 바라보는 관점이 달라졌다.

처음에는 그저 ‘좋은 역할’을 주면 된다고 생각했다.
그다음에는 ‘좋은 규칙’을 적어 주면 해결될 줄 알았다.

하지만 Rulebook Prompt를 복잡하게 다듬어 갈수록,
LLM에게 규칙을 텍스트로 읽히는 것만으로는
본질적인 한계를 넘기 어렵다는 생각이 들었다.

규칙은 적어 둘 수 있다.

하지만 그 규칙이 흔들림 없이 실행되려면
문장 이상의 것이 필요했다.

• 각 단계에서 어떤 명리적 입력을 받을 것인가?
• 각 단계에서 LLM이 아닌 시스템은 무엇을 계산해야 하는가?
• 각 판단의 근거를 시스템의 어느 곳에 남길 것인가?
• 다음 단계는 이전 단계의 어떤 값을 넘겨받아야 하는가?
• 최종 문장은 어떤 구조화된 자료를 바탕으로 생성되어야 하는가?

프롬프트 안에 순서도를 적어 넣는 것만으로는
이 질문들에 답할 수 없었다.

순서가 실제로 작동하려면,
각 단계마다 명확하게 분리된 입력과 출력이 있어야 했다.

예를 들어 “월령을 확인하라”는 지시는
사람이나 LLM에게는 이해하기 쉬운 문장이다.

하지만 시스템과 엔진의 관점에서는 다른 과제다.

월지는 무엇인가.
계절의 한난조습(寒暖燥濕)은 어떻게 반영할 것인가.
득령 여부는 내부적으로 어떤 상태값으로 남길 것인가.
그리고 그 값은 최종 신강약 산출에 어떻게 개입하는가.

이런 질문들을 더 이상 피하기 어려웠다.

그때부터 프롬프트는 단순한 지시문을 넘어,
언젠가 데이터 구조로 옮겨 심어야 하는 설계 메모처럼 보이기 시작했다.

---

지금 돌아보면

Rulebook Prompt는 완성된 답안지가 아니었다.

하지만 MRA의 진화 과정에서
생략할 수 없는 중요한 징검다리였다.

역할 프롬프트가 AI의 말투를 바꾸었다면,
Rulebook Prompt는 명리의 판단 순서를 글로 꺼내 놓고
하나씩 나누어 보는 과정이었다.

그전까지는 내 머릿속의 명리 지식과
AI의 해석 문장이 한 덩어리처럼 섞여 있었다.

하지만 규칙을 명문화하기 시작하면서,
모든 것이 조금씩 나뉘기 시작했다.

무엇이 입력 재료인가.
무엇이 판단 절차인가.
무엇이 검증 가능한 근거인가.
무엇이 최종 문장인가.

물론 이 단계에서는 그 구분이 아직 흐릿했다.

그럼에도 Rulebook Prompt를 작성하며
한 가지 사실은 분명하게 알 수 있었다.

AI에게 역할을 주고,
꼼꼼한 순서도를 쥐여 주는 것만으로는
안정적인 명리 판단을 보장할 수 없다.

그 순서는 텍스트 바깥에서 실제로 실행되어야 하고,
그 실행 결과는 다시 검토될 수 있는 형태로 남아야 한다.

나중에 MRA 엔진이 Trace와 Evidence를 중요하게 보게 된 것도
이 시기에 느꼈던 불편함과 맞닿아 있다.

Rulebook Prompt는 실패한 프롬프트가 아니다.

프롬프트가 감당할 수 있는 한계선이 어디까지인지,
그리고 어디서부터 프로토콜과 데이터 구조의 영역이 시작되어야 하는지를
보여 준 이정표였다.

---

부록 A. Rulebook Prompt의 초기 형태

Rulebook Prompt는 명리 판단의 흐름을
AI가 따라야 할 일련의 규칙처럼 적어 보려는 시도였다.

완성된 분석 엔진의 규칙집이라기보다는,
초기 역할 프롬프트의 불안정성을 보완하기 위한 임시 구조에 가까웠다.

---

A-1. 분석 순서를 적어 넣은 형태

다음 순서에 따라 명조를 분석하라.

1. 일간을 확인한다.
2. 월지를 기준으로 계절과 월령을 판단한다.
3. 득령, 득지, 득세를 나누어 신강약을 검토한다.
4. 오행의 분포와 편중을 확인한다.
5. 십신의 위치와 작용을 본다.
6. 격국 후보를 검토하되 단정하지 않는다.
7. 용신과 기신은 원국 전체의 균형을 본 뒤 후보로 제시한다.
8. 대운과 세운은 원국 판단 이후에 연결한다.

당시 의도:

• AI가 의식의 흐름대로 자유롭게 말하는 것을 줄이고, 일정한 순서로 사주를 해체하게 만들려 했다.
• 신강약, 격국, 용신 판단이 섣불리 단정 지어지는 것을 늦추고 싶었다.
• 원국 판단과 운의 흐름 해석을 분리하려 했다.

남은 문제:

• 텍스트상으로는 순서를 따랐지만, 실제로 그 순서대로 판단했는지는 알기 어려웠다.
• 단계별 판단의 근거가 독립된 계산값으로 남지 않았다.
• 단순히 답변의 목차 형식으로만 소모될 위험이 있었다.

다음 변화:

• 자연스럽게 각 판단 단계의 입력값과 출력값, 그리고 근거를 데이터로 따로 분리해야 한다는 생각으로 넘어가게 된다.

---

A-2. 금지 규칙을 덧붙인 형태

다음 사항을 반드시 지켜라.

• 용신은 근거 없이 단정하지 않는다.
• 격국은 확정 짓지 말고 후보로 검토한다.
• 신강약 판단에는 반드시 그 이유를 논리적으로 붙인다.
• 원국 판단이 끝나기 전에 대운과 세운을 먼저 결론 내리지 않는다.
• 건강, 수명, 사고, 재난 등에 대해서는 절대 단정적인 표현을 쓰지 않는다.
• 불확실한 판단은 후보군으로 남겨둔다.
• 최종 문장은 단정형이 아닌 참고형으로 작성한다.

당시 의도:

• AI 특유의 과도한 확신과 단정을 줄이고 싶었다.
• 불확실한 사안을 마치 정답인 양 서술하는 것을 막고 싶었다.
• 명리 해석이 예언이나 단정처럼 보이는 것을 피하고 싶었다.

남은 문제:

• 금지 규칙이 누적될수록 프롬프트 안의 지시 우선순위가 흐려졌다.
• AI는 금지 규칙을 피하는 듯한 문장을 만들었지만, 모든 제약을 매번 안정적으로 지켜내지는 못했다.
• 이 규칙들은 훗날 단일 프롬프트가 아니라 별도의 실행 프로토콜로 분리해야 할 성질의 것들이었다.

다음 변화:

• 프롬프트 하나에 역할, 분석 절차, 금지 규칙, 출력 형식을 모두 한곳에 넣는 방식에서 벗어나, 이를 기능별로 분리해야 한다는 생각으로 이어졌다.

---

A-3. 이 단계에서 남은 메모

• 프롬프트는 절차를 요청할 수 있지만, 절차를 보장하지는 못한다.
• 근거를 요구하면 근거처럼 보이는 문장은 출력된다. 하지만 그 근거가 실제 계산값에 기반하고 있는지는 별도의 확인 장치가 필요하다.
• 역할, 절차, 금지 규칙, 출력 형식이 하나의 프롬프트 안에 뒤엉키면 통제와 관리가 어려워진다.
• 다음 단계에서는 프롬프트를 단순한 질문문이 아니라, 실행 규약에 가깝게 다루어야 한다.

당시 의도:

• Rulebook Prompt의 한계를 마주하며, 문제의 본질을 메모로 남겨두려 했다.
• 단순한 문구 수정이 아니라 구조 분리가 필요하다는 점을 정리하는 과정이었다.

남은 문제:

• 여전히 모든 계산과 명리적 판단이 LLM 내부에 남아 있었다.
• 단계별 산출물이 객체나 데이터로 남지 않았다.
• 오류가 발생해도 추적하고 교정할 방법이 부족했다.

다음 변화:

• 지시문은 점점 비대해졌고, 결국 프롬프트의 틀을 넘어 LLM 실행 프로토콜이라는 새로운 체계로 넘어가게 된다.

---

노트 한 줄 요약

프롬프트는 명리의 순서를 요청할 수는 있지만, 그 순서의 실행을 보장하지는 못한다.

---

다음 글

다음 글에서는 프롬프트가 길어질수록 분석이 더 정교해지는 것처럼 보였지만, 실제로는 지시 충돌과 검증의 사각지대가 커져 갔던 딜레마를 다룹니다.

---

태그: MRA, MRA엔진노트, AI명리, 프롬프트실험, 프롬프트공학, RulebookPrompt, LLM, 명리해석, 사주명리, K명리
locale: ko-KR