본문 바로가기
MRA Engine Note

1. 처음에는 프롬프트로 해보려 했다

by 夢遊 2026. 6. 10.

[MRA 엔진 노트 흐름]

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

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


어느 날의 화면

처음에는 프롬프트 창 앞에서 오래 망설였다.

무엇을 먼저 적어야 할지부터가 문제였다.
AI에게 그냥 “명리를 분석해 달라”고 하면 되는 걸까.
아니면 “너는 명리 분석가다”라고 역할을 정해 주어야 할까.
명조를 넣고, 신강약과 격국과 용신을 보라고 하면 어느 정도 따라올 수 있을까.

처음에는 그 정도의 기대였다.

프롬프트 몇 줄이면
AI가 명리의 판단 순서를 어느 정도 흉내 내 줄 수 있지 않을까.

그 생각으로 문장을 적기 시작했다.

그런데 막상 답변을 받아 보니 이상했다.

문장은 자연스러웠다.
구성도 나쁘지 않았다.
명리 용어도 제법 익숙하게 섞여 있었다.

그런데 마음이 놓이지 않았다.

분명히 답변은 그럴듯한데,
그 판단이 어디에서 나온 것인지는 잘 보이지 않았다.

월령을 먼저 본 것인지,
오행의 세력을 먼저 본 것인지,
십신의 배치를 먼저 잡은 것인지,
아니면 그럴듯한 결론을 먼저 만들고 그 뒤에 근거를 붙인 것인지 알기 어려웠다.

그때 처음으로 이런 생각이 들었다.

AI가 말을 잘하는 것과
명리적으로 근거 있는 판단을 하는 것은 같은 일이 아닐지도 모른다.


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

처음부터 MRA라는 이름이 있었던 것은 아니다.

처음부터 엔진을 만들겠다고 마음먹은 것도 아니었다.
데이터 구조를 설계하겠다거나, Trace와 Evidence를 남기겠다거나,
AI 호출용 프롬프트를 따로 만들겠다는 생각도 그때는 없었다.

처음에 있었던 것은 아주 단순한 기대였다.

명리(命理)에는 나름의 판단 순서가 있다.
사주(四柱)를 세우고, 명조(命造)를 확인한다.
일간(日干)을 보고, 월령(月令)을 보고, 오행(五行)의 세력을 살핀다.
십신(十神)의 배치를 보고, 격국(格局)을 생각하고, 용신(用神)과 기신(忌神)을 따져 본다.
그리고 대운(大運)과 세운(歲運)이 원국(原局)에 어떻게 작용하는지를 함께 본다.

그렇다면 이 순서를 AI에게 잘 설명하면
AI도 어느 정도 명리 해석을 따라올 수 있지 않을까.

그때의 질문은 거창하지 않았다.

AI에게 명리의 판단 순서를 잘 알려 주면,
명리 해석도 어느 정도 안정적으로 할 수 있지 않을까.

지금 돌아보면 순진한 생각이었지만,
그때는 충분히 해 볼 만한 시도처럼 보였다.

코드가 먼저가 아니었다.
프롬프트가 먼저였다.


무작정 부딪혀본 기록

처음에는 AI에게 역할을 주었다.

너는 명리 분석가다.
아래 명조를 보고 신강약, 격국, 용신, 대운 흐름을 분석하라.

대략 이런 식이었다.

처음에는 이 정도만으로도 꽤 되는 것처럼 보였다.

AI는 명리 용어를 알고 있었다.
문장도 자연스럽게 만들었다.
신강, 신약, 격국, 용신, 대운, 세운 같은 말을 섞어 가며
제법 정돈된 답변을 내놓았다.

처음 보는 입장에서는 꽤 그럴듯했다.

프롬프트 창에 몇 줄을 적고 실행하면,
잠시 뒤 긴 해석문이 흘러나왔다.
혼자 책을 뒤지고, 표를 확인하고, 용어를 다시 찾아보며 한참을 붙잡고 있어야 할 내용을
AI는 몇 초 만에 문장으로 펼쳐 놓았다.

그 속도는 분명히 매력적이었다.

그래서 한동안은 프롬프트를 고치는 일이 답처럼 느껴졌다.

역할을 더 정확히 주면 되지 않을까.
분석 순서를 더 자세히 넣으면 되지 않을까.
주의사항을 더 붙이면 조금 더 신중해지지 않을까.
출력 형식을 정하면 답변이 더 안정되지 않을까.

그런 생각으로 프롬프트를 계속 고쳤다.

처음에는 한두 문장이던 지시가
조금씩 길어졌다.

먼저 일간을 보라.
월령을 확인하라.
오행의 세력을 살펴라.
신강약을 판단하라.
격국 후보를 검토하라.
용신과 기신은 단정하지 말고 근거를 남겨라.
대운과 세운은 원국 판단 뒤에 연결하라.

이런 문장들이 하나씩 붙었다.

프롬프트는 점점 질문문이 아니라
절차문에 가까워졌다.


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

문제는 답변이 계속 흔들린다는 점이었다.

같은 흐름으로 질문해도 어떤 답변은 신강약을 중심으로 설명했다.
어떤 답변은 조후를 더 앞세웠다.
어떤 답변은 격국 후보를 중심에 놓았다.
어떤 답변은 대운과 세운의 분위기로 빨리 넘어갔다.

물론 명리는 보는 관점에 따라 강조점이 달라질 수 있다.
그러니 모든 답변이 반드시 하나의 결론으로만 나와야 한다고 볼 수는 없다.

하지만 공부하는 입장에서는 적어도 알고 싶었다.

이 판단은 어디에서 나온 것인가.
이 말은 계산값에서 나온 것인가.
아니면 AI가 문장을 자연스럽게 만들기 위해 이어 붙인 것인가.

그 구분이 잘 되지 않았다.

AI가 틀렸다고 단순히 말하기도 어려웠다.
그렇다고 그대로 믿기도 어려웠다.

그 지점이 불편했다.

명리를 공부하다 보면 결국 다시 근거로 돌아가게 된다.

월령을 보았는가.
일간이 어디에 뿌리를 두었는가.
오행의 세력은 어떻게 흐르는가.
십신은 어느 자리에 놓였는가.
대운과 세운은 원국의 어떤 부분을 건드리는가.

이런 질문을 따라가야 마음이 놓인다.

그런데 AI의 답변은 그 과정을 한 번에 문장으로 덮어 버렸다.
읽기에는 편했지만, 다시 되짚어 가기에는 불편했다.

문장이 자연스러울수록 오히려 더 헷갈렸다.

자연스러운 문장이
근거를 대신하는 것처럼 보였기 때문이다.


생각의 궤도를 수정하다

이때부터 질문이 조금 바뀌었다.

처음의 질문은 이랬다.

AI에게 명리를 설명하게 할 수 있을까.

하지만 점점 다른 질문이 생겼다.

AI가 어떤 순서로 판단했는지를 남기게 할 수 있을까.
AI가 만든 문장을 다시 검토할 수 있게 만들 수 있을까.
어떤 계산값에서 어떤 해석문이 나왔는지 구분할 수 있을까.

이 변화는 작아 보이지만 컸다.

처음에는 좋은 답변을 얻기 위해 프롬프트를 고쳤다.
하지만 실제로는 명리 판단 절차를 문장으로 구조화하고 있었다.

AI에게 자유롭게 말하게 하는 것이 아니라,
정해진 순서대로 보게 하고,
각 단계마다 근거를 남기게 하고,
마지막에 종합하게 만들려 했다.

그때는 그것을 프로토콜이라고 부르지 않았다.
데이터 구조라고 생각하지도 않았다.
엔진이라는 말도 아직 어울리지 않았다.

그저 답변이 흔들리니
흔들리지 않는 기준이 필요하다고 느꼈을 뿐이다.

하지만 지금 돌아보면,
이 지점에서 이미 MRA의 방향이 조금씩 생겨나고 있었다.


지금 돌아보면

처음의 프롬프트 실험은 완성된 방법이 아니었다.

오히려 허술한 부분이 많았다.
AI에게 너무 많은 것을 맡겼고,
명리 판단과 문장 생성을 한꺼번에 처리하게 했다.
계산값과 해석문도 제대로 분리하지 못했다.

하지만 그 시행착오는 의미가 있었다.

그때 처음으로 알게 되었기 때문이다.

AI가 말을 잘하는 것과
명리적으로 근거 있는 판단을 하는 것은 같은 일이 아니다.

AI가 자연스럽게 설명하는 것과
그 설명이 실제 계산 재료에서 나오는 것도 같은 일이 아니다.

이 차이를 느낀 것이 MRA의 출발점이었다.

MRA는 처음부터 엔진으로 시작된 것이 아니다.
프롬프트가 자신의 한계를 드러내는 지점에서 시작되었다.

처음에는 프롬프트로 해보려 했다.
그리고 그 프롬프트가 흔들리는 것을 보면서,
조금씩 다른 구조가 필요하다는 생각이 생겨났다.

코드보다 먼저 있었던 것은 프롬프트였다.
프롬프트보다 먼저 있었던 것은 하나의 불편함이었다.

그럴듯한 명리 문장을 그대로 믿어도 되는가.

MRA 엔진 노트의 첫 기록은 그 질문에서 시작한다.


부록 A. 초기 프롬프트의 형태

초기 프롬프트는 처음부터 정교하지 않았다.
역할을 주고, 항목을 넣고, 부족한 부분을 다시 고치는 식으로 조금씩 바뀌어 갔다.

공개용 원문을 실을 때는 개인 명조, 생년월일시, 사적 대화, 내부 경로, API 키 등은 반드시 제거한다.


A-1. 역할을 부여하던 단계

너는 사주명리 분석가다.
아래 명조를 보고 신강약, 격국, 용신, 대운 흐름을 분석해라.
전문적인 명리 용어를 사용하되, 일반인도 이해할 수 있게 설명해라.

당시 의도

  • AI의 말투를 명리 분석에 맞추려 했다.
  • 일반적인 조언이 아니라 명리 용어를 사용하는 답변을 원했다.
  • 신강약, 격국, 용신, 대운 같은 핵심 항목을 빠뜨리지 않게 하려 했다.

남은 문제

  • 말투는 바뀌었지만 판단 순서는 고정되지 않았다.
  • 어떤 근거에서 판단했는지 확인하기 어려웠다.
  • AI가 명리 분석가처럼 말하는 것과 실제 분석 절차를 따르는 것은 달랐다.

다음 변화

  • 역할 부여만으로는 부족하다고 보고, 분석 순서를 프롬프트 안에 넣기 시작했다.

A-2. 분석 순서를 추가하던 단계

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

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

당시 의도

  • AI가 자유롭게 말하는 대신 정해진 순서대로 분석하게 하려 했다.
  • 판단마다 근거를 남기게 하려 했다.
  • 단정적인 용신 판단이나 과도한 결론을 줄이려 했다.

남은 문제

  • 답변 구조는 정돈되었지만 실제로 그 순서대로 판단했는지는 확인하기 어려웠다.
  • 근거처럼 보이는 문장은 나왔지만, 계산값과 직접 연결되는지는 별도로 검토해야 했다.
  • 프롬프트는 절차를 요청할 수 있지만, 실행을 보장하지는 못했다.

다음 변화

  • 분석 순서를 더 세밀하게 나누고, 나중에는 Rulebook Prompt와 실행 프로토콜 쪽으로 넘어가게 된다.

노트 한 줄 요약

AI가 말을 잘하는 것과 근거 있는 판단을 하는 것은 같은 일이 아니었다.


다음 글

다음 글에서는 “너는 명리 분석가다”라는 역할 부여가 왜 충분하지 않았는지를 다룹니다.


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