[MRA 엔진 노트 흐름]
프롬프트 → 프로파일/가중치 → 실행 로직 → 데이터/계산 → 검증/MRA 엔진 → AI 문장화
현재 위치: 제2부 프로파일 변천사와 실행 로직의 시작

어느 날의 화면
8편에서 남긴 말은 단순했다.
강하다, 약하다라는 말만으로는 부족했다.
처음에는 그 말이 하나의 결론처럼 보였다.
일간(日干)이 강하다.
일간이 약하다.
신강하다.
신약하다.
하지만 프로파일을 만들기 시작하자
그 말은 하나의 결론이 아니라
여러 판단 재료가 합쳐진 결과처럼 보이기 시작했다.
득령은 어느 정도인가.
득지는 어느 정도인가.
통근은 어느 깊이에 놓였는가.
월지와 시지를 같은 자리로 볼 수 있는가.
충을 맞은 뿌리는 그대로 남아 있는가.
이 질문들은 모두 “강하다”라는 말 안에 들어갈 수 있었다.
하지만 엔진 안에서는
이 질문들을 같은 칸에 넣을 수 없었다.
득령과 득지는 모두 힘을 말하지만,
같은 힘은 아니었다.
월령(月令)이 주는 계절의 힘과
지지에 뿌리를 둔 힘은 다르게 보아야 했다.
그때부터 MRA는
말로만 있던 강약 감각을 조금씩 밖으로 꺼내기 시작했다.
그때 내 머리를 떠나지 않던 질문
그때 내 머리를 떠나지 않던 질문은 이것이었다.
같은 “힘”이라는 말 안에
얼마나 다른 것들이 섞여 있는가.
명리(命理)를 공부하다 보면
득령, 득지, 득세라는 말을 자주 만난다.
득령은 계절의 힘에 가깝다.
월령을 얻었다는 말은
명조(命造)가 놓인 계절 자체가 일간을 밀어 준다는 뜻에 가깝다.
득지는 지지의 기반에 가깝다.
일간이 기대어 설 수 있는 뿌리가
원국(原局) 안에 있는지를 묻는다.
통근은 다시 그 뿌리의 깊이를 묻는다.
본기에 놓인 뿌리와
중기에 걸친 뿌리와
여기에 잠깐 비친 뿌리를
같은 힘으로 볼 수는 없었다.
위치도 문제였다.
월지는 계절과 연결되는 큰 자리다.
일지는 일간이 앉아 있는 자리다.
시지는 뒤쪽으로 이어지는 흐름이고,
연지는 멀지만 배경처럼 남는다.
그런데 이 모든 것을 한꺼번에
“힘이 있다”라고 적어 버리면
나중에 다시 검토할 길이 사라졌다.
무엇 때문에 강했는가.
어디에서 힘을 얻었는가.
그 힘은 깊은가 얕은가.
그 힘은 충을 맞고도 남아 있는가.
이 질문들이 남았다.
무작정 부딪혀본 기록
처음부터 세련된 모델이 있었던 것은 아니다.
그저 판단 항목을 나누어 보았다.
득령.
득지.
득세.
위치.
통근.
투출.
충.
십이운성.
조후.
격국.
용신.
처음에는 이 항목들이 모두 한 해석문 안에 섞여 있었다.
“월령을 얻어 힘이 있다.”
“지지에 뿌리가 있어 쉽게 무너지지 않는다.”
“통근이 약해 기반이 부족하다.”
“충을 받아 구조가 흔들린다.”
“조후가 맞지 않아 다른 판단이 필요하다.”
문장으로 읽으면 크게 이상하지 않았다.
하지만 프로파일로 옮기려 하자
이 말들은 서로 다른 칸을 요구했다.
득령은 월령의 힘을 따로 보아야 했다.
득지는 지지의 기반을 따로 보아야 했다.
통근은 본기·중기·여기의 차이를 따로 보아야 했다.
위치는 월지·일지·시지·연지를 같은 자리로 보지 말아야 했다.
충은 가점이 아니라 감쇠나 경고 신호로 따로 남겨야 했다.
이것은 단순히 숫자를 붙이는 일이 아니었다.
신강이나 신약이라는 결론이 나오기 전에
그 결론을 만든 재료들을 밖으로 꺼내는 일이었다.
이때부터 세 개의 이름도 함께 보이기 시작했다.
BSI, SSI, USI.
BSI는 Body Strength Index다.
일간의 강약과 기세를 보는 축으로 두었다.
SSI는 Structural Synergy Index다.
격국(格局)과 구조의 성패, 상신과 구신, 파격 여부를 보는 축이었다.
USI는 Useful Spirit Index다.
용신(用神) 후보와 실제 쓰임의 방향을 보는 축으로 잡았다.
이 이름들이 처음부터 완성된 정의였던 것은 아니다.
하지만 이름을 붙이고 나서야
어떤 판단 재료가 어디로 흘러가야 하는지 조금씩 보이기 시작했다.
득령과 득지, 통근과 위치값은
주로 BSI 쪽에서 일간이 얼마나 버틸 수 있는지를 보는 재료가 되었다.
격국의 성립과 파격, 상신과 구신의 문제는
SSI 쪽으로 넘어가야 했다.
무엇을 실제로 쓸 것인가,
그 후보가 대운(大運)과 세운(歲運)에서 어떻게 달라지는가는
USI 쪽에서 따로 보아야 했다.
하나의 분석문 안에 섞여 있던 판단들이
조금씩 다른 방향으로 갈라지기 시작했다.
말만 번지르르한 AI 앞에서 느낀 벽
AI는 이런 말을 자연스럽게 만들 수 있었다.
“월령을 얻어 신강한 편입니다.”
“지지에 뿌리가 있어 일간이 쉽게 무너지지 않습니다.”
“관살이 강해 압박이 있지만 식상으로 제어할 수 있습니다.”
“격국상 구조가 흔들리므로 용신을 신중히 보아야 합니다.”
이 문장들은 틀렸다고 단정하기 어렵다.
명리적으로 가능한 말이기 때문이다.
하지만 문제는 여전히 남았다.
얼마나 강한가.
얼마나 눌린 것인가.
그 힘은 월령에서 온 것인가, 지지의 뿌리에서 온 것인가.
본기에 통근한 것인가, 중기나 여기에 걸친 것인가.
충을 맞은 뒤에도 같은 힘으로 남아 있는가.
AI는 이런 질문에 대해서도
다시 문장으로 답했다.
그러나 문장이 길어진다고
검토가 쉬워지는 것은 아니었다.
오히려 말이 길어질수록
판단은 더 그럴듯해졌고,
그 판단을 다시 확인할 기준은 더 흐려졌다.
프롬프트는 AI에게 신중하게 말하라고 할 수 있다.
하지만 신중함의 기준을
매번 같은 방식으로 적용하게 만들기는 어렵다.
프롬프트는 AI에게 근거를 쓰라고 할 수 있다.
하지만 그 근거가
실제 계산 가능한 값으로 남는 것은 아니다.
그래서 질문은 다시 바뀌었다.
AI에게 어떻게 더 잘 설명하게 할 것인가가 아니라,
AI가 설명하기 전에 어떤 판단 재료를 먼저 만들어 둘 것인가.
그 질문이 프로파일을 더 필요하게 만들었다.
생각의 궤도를 수정하다
이때부터 프로파일은 단순한 가중치표가 아니게 되었다.
처음에는 득령을 얼마로 볼 것인가,
득지를 얼마로 볼 것인가,
통근과 위치값을 어떻게 나눌 것인가를 적어 보는 정도였다.
하지만 곧 알게 되었다.
문제는 숫자 하나가 아니었다.
같은 명조를 자평 표준으로 볼 것인가.
조후를 더 중시할 것인가.
화격이나 종격 같은 특수 구조를 먼저 볼 것인가.
양인격에서 관살을 어떻게 다룰 것인가.
억부와 조후가 충돌할 때 무엇을 우선할 것인가.
이 질문들은 하나의 숫자표로 끝나지 않았다.
그래서 프로파일은
MRA가 어떤 관점으로 명조를 볼 것인지 남기는 기준 초안에 가까워졌다.
정답이라는 뜻은 아니었다.
오히려 반대였다.
정답이라고 믿을 수 없으니 밖으로 꺼냈다.
밖으로 꺼내야 비교할 수 있고,
비교해야 고칠 수 있고,
고치려면 버전이 남아야 했다.
이때부터 MRA의 기록은
단순한 프롬프트 수정 기록이 아니게 되었다.
판단 기준을 어떻게 밖으로 꺼냈는가.
그 기준을 어떤 파일로 남겼는가.
그 값이 왜 바뀌었는가.
바뀐 뒤에는 어떤 결과가 달라졌는가.
이 질문들이 프로파일 변천사의 중심이 되었다.
공개할 것은 숫자보다 방향이었다
프로파일의 모든 값을 그대로 펼쳐 보이는 것이
이 글의 목적은 아니다.
값보다 먼저 보아야 할 것은
그 값을 밖으로 꺼내야겠다고 느낀 이유였다.
득령을 크게 보아야 한다는 생각.
득지를 그다음 축으로 두어야 한다는 생각.
통근의 깊이와 충의 흔들림을 다르게 보아야 한다는 생각.
이런 생각은 명리를 공부하는 사람이라면
어느 정도 떠올릴 수 있다.
하지만 그것을 실제 시스템 안에서 어떻게 나누고,
어떤 구조로 남기고,
어디까지 검토 가능하게 만들 것인지는
각자의 방식이 다를 수밖에 없다.
그래서 이 글에서는 수치 자체보다
프로파일이라는 생각이 왜 필요해졌는지를 남기려 한다.
값은 정답이 아니라 흔적이었다.
MRA에서 중요한 것은
값을 믿는 일이 아니라
값을 다시 볼 수 있게 남기는 일이었다.

지금 돌아보면
지금 돌아보면 이 글의 자리는 중요하다.
1부가 프롬프트의 한계를 다루었다면,
여기서는 그 한계가 어디로 넘어갔는지를 다루어야 한다.
그 다음 자리는 곧바로 엔진이 아니었다.
먼저 프로파일이었다.
프롬프트 안에 있던 판단 기준을 밖으로 꺼내고,
말로만 있던 강약 감각을 값으로 적어 보고,
그 값이 흔들리면 고칠 수 있게 만드는 일.
이것이 MRA가 엔진으로 가기 전에 지나간 중요한 단계였다.
프로파일은 단순한 설정 파일이 아니었다.
그것은 판단 기준을 문장 밖으로 꺼낸 첫 형태였다.
AI에게 “월령을 중시하라”고 말하는 것과
프로파일 안에서 월령의 비중을 따로 관리하는 것은 다르다.
AI에게 “충을 고려하라”고 말하는 것과
충을 받았을 때 어떤 항목을 얼마나 감쇠할지 남기는 것도 다르다.
AI에게 “조후를 보라”고 말하는 것과
조후 중심 프로파일을 따로 두는 것도 다르다.
이 차이가 MRA를 프롬프트 실험에서
엔진 쪽으로 밀어냈다.
프롬프트는 말을 요청했다.
프로파일은 기준을 남겼다.
그리고 그 기준은 완성된 답이 아니라,
다시 검토하기 위한 임시 좌표였다.
부록 A. 초기 가중치 설계의 흔적
A-1. 당시 흐름을 정리한 형태
| 판단 항목 | 당시 떠오른 질문 | 프로파일로 옮길 때의 의미 |
|---|---|---|
| 득령 | 월령의 힘은 어느 정도인가 | 일간 강약 판단의 큰 축 |
| 득지 | 지지에 뿌리가 있는가 | 일간이 버틸 기반 |
| 위치 | 월지, 일지, 시지, 연지는 같은가 | 자리별 영향 차이 |
| 통근 | 본기, 중기, 여기는 같은가 | 뿌리의 깊이 차이 |
| 투출 | 천간에 드러났는가 | 작용의 외현성 |
| 충 | 뿌리나 구조가 흔들리는가 | 감쇠 또는 위험 신호 |
| 십이운성 상태 | 이름인가, 힘의 차이인가 | 상태값 또는 보조 가중치 |
| 조후 | 한난조습이 우선되는가 | 억부와 별도의 판단 축 |
| 격국 | 구조가 어떻게 잡히는가 | SSI 판단의 중심 |
| 용신 후보 | 무엇을 쓸 것인가 | USI 판단의 중심 |
당시 의도
- 신강·신약 판단을 말로만 두지 않고, 검토 가능한 항목으로 나누려 했다.
- 득령, 득지, 위치, 통근, 충, 조후를 같은 무게로 보지 않으려 했다.
- AI가 결론을 만들기 전에 엔진이 참고할 판단 기준을 밖으로 꺼내려 했다.
- BSI, SSI, USI가 뒤섞이지 않도록 판단 축을 나누려 했다.
남은 문제
- 숫자가 곧 정답은 아니었다.
- 항목을 더하면 중복 가점이 생길 수 있었다.
- 월령과 통근, 조후와 억부, 격국과 용신이 서로 충돌할 때 우선순위가 필요했다.
- 어떤 값이 적절한지는 실제 사례와 반례로 검증해야 했다.
다음 변화
- 단순 가중치표는 프로파일 구조로 바뀌기 시작했다.
- 프로파일은 BSI, SSI, USI를 나누는 방향으로 확장되었다.
- BSI는 일간 강약과 기세를 보는 축, SSI는 격국과 구조의 성패를 보는 축, USI는 용신 후보와 쓰임의 방향을 보는 축으로 정리되어 갔다.
- 이후에는 이론 기반 프로파일과 실제 엔진용 production 프로파일이 갈라지기 시작했다.
부록 B. BSI, SSI, USI의 첫 구분
BSI, SSI, USI라는 이름은 나중에 더 다듬어졌지만,
초기에는 판단 책임을 나누기 위한 표지에 가까웠다.
| 약어 | 영문 풀이 | 맡기려 한 역할 |
|---|---|---|
| BSI | Body Strength Index | 일간의 강약과 기세를 보는 축 |
| SSI | Structural Synergy Index | 격국과 구조의 성패, 상신과 구신, 파격 여부를 보는 축 |
| USI | Useful Spirit Index | 용신 후보와 실제 쓰임의 방향을 보는 축 |
이 구분은 기술 용어를 멋지게 붙이기 위한 것이 아니었다.
AI가 한 문장으로 섞어 말하던 판단을
다시 검토 가능한 층으로 나누기 위한 표시였다.
노트 한 줄 요약
MRA의 프로파일은 점수를 믿어서가 아니라, 강하다와 약하다라는 말을 검토 가능한 기준으로 꺼내기 위해 생겨났다.
다음 글
다음 글에서는 하나의 분석문 안에 섞여 있던 판단이 왜 BSI, SSI, USI라는 세 갈래 구조로 나뉘어야 했는지를 다룹니다.
locale: ko-KR
태그: MRA, MRA엔진노트, AI명리, 프로파일, BSI, SSI, USI, 신강신약, 명리계산, K명리
'MRA Engine Note' 카테고리의 다른 글
| 8. 강하다, 약하다 너머에 값이 있을까 (0) | 2026.06.15 |
|---|---|
| 7. 시행착오는 AI 호출 설계의 씨앗이었다 (0) | 2026.06.11 |
| 6. 프롬프트가 작은 프로그램처럼 변해 갔다 (0) | 2026.06.10 |
| 5. 출력 형식을 고정하려 했다: 표, 단계, JSON (0) | 2026.06.10 |
| 4. 프롬프트가 길어질수록 더 잘 되는 것처럼 보였다 (0) | 2026.06.10 |