7. 시행착오는 AI 호출 설계의 씨앗이었다

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

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

---

어느 날의 화면

한동안 쌓아 두었던 프롬프트 뭉치들을 다시 열어 본 적이 있다.

처음에는 아주 단순한 질문이었다.

“아래 명조를 분석해 달라.”

그다음에는 역할이 붙었다.

“너는 사주명리 분석가다.”

조금 더 지나자 분석 순서가 붙고,
금지 규칙이 붙고,
출력 형식이 붙었다.

나중에는 표, 단계별 보고서, JSON 규격, 조건문, 예외 처리까지 들어갔다.

그 텍스트들을 다시 읽어 보니
문득 이상한 기시감이 들었다.

당시에는 그저 더 나은 답변을 얻기 위해
프롬프트를 고치고 있다고만 생각했다.

그런데 시간순으로 정렬된 기록들을 다시 보니,
나는 프롬프트를 고치고 있었던 것만은 아니었다.

나는 AI에게 무엇을 맡기고,
무엇을 맡기지 말아야 하는지를
하나씩 가려 내고 있었다.

그때는 실패처럼 보였던 문장들이
나중에는 MRA의 AI 호출 설계 원칙으로 돌아왔다.

---

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

당시의 질문은 이랬다.

이 많은 프롬프트 시행착오는
그저 실패였을까.

역할 프롬프트는
말투를 바꾸는 데는 도움이 되었지만
내부 판단을 통제하기에는 충분하지 않았다.

Rulebook Prompt를 써도
실행 절차가 보장되지는 않았다.

길어진 프롬프트는
답변을 더 정교해 보이게 만들었지만,
검증은 오히려 더 어려워졌다.

표, 단계별 보고서, JSON은
답변의 형태를 정돈했을 뿐
내용의 사실성을 보장하지는 못했다.

프롬프트가 작은 프로그램처럼 변해 가도,
그것은 여전히 텍스트였다.

이렇게 놓고 보면
프롬프트 시대는 한계의 기록처럼 보인다.

하지만 조금 다르게 보면,
그 한계들은 모두 다음 설계를 위한 질문으로 바뀌어 있었다.

역할 프롬프트가 부족했다는 것은
역할과 책임을 더 분명히 나누어야 한다는 뜻이었다.

분석 순서가 흔들렸다는 것은
실행 절차를 프롬프트 문장이 아니라
프로토콜로 남겨야 한다는 뜻이었다.

근거가 불분명했다는 것은
판단 재료와 근거를 추적 가능한 구조로 남겨야 한다는 뜻이었다.

출력 형식이 착시를 만들었다는 것은
AI가 형식을 스스로 만들어 내게 할 것이 아니라,
계산된 데이터를 먼저 만들고
그 데이터를 AI에게 넘겨야 한다는 뜻이었다.

프롬프트 시대의 실패는
사실상 다음 설계를 위한 요구사항이었다.

---

무작정 부딪혀본 기록

당시에는 계속 같은 방식으로 벽에 부딪혔다.

답변이 흔들리면 프롬프트를 고쳤다.

근거가 약해 보이면
“근거를 반드시 제시하라”는 문장을 추가했다.

판단이 성급해 보이면
“단정하지 말라”는 규칙을 덧붙였다.

순서가 뒤섞이면
“반드시 아래 순서대로 분석하라”며 번호를 매겼다.

출력이 산만하면 표를 그리게 했고,
그래도 부족하면 JSON으로 쓰게 했다.

이 시기의 작업은 겉으로 보면
프롬프트 엔지니어링을 계속 고도화하는 과정처럼 보였다.

하지만 실제로는
내 머릿속에 다음과 같은 질문들이 쌓이고 있었다.

• 입력값은 누가 검증해야 하는가.
• 명조를 세우는 일은 어디에서 처리해야 하는가.
• 신강약 판단에 쓰인 재료는 어디에 남아야 하는가.
• 격국과 용신 후보는 어떤 구조로 구분해야 하는가.
• 판단의 불확실성은 조심스러운 문장만으로 충분한가.
• AI가 출력한 근거는 실제 계산의 결과인가, 사후 설명인가.
• 최종 문장은 계산 결과를 설명하는가, 아니면 다시 판단을 만들어 내는가.

이 질문들은 당시에는 명확히 정리되지 않았다.

그저 프롬프트가 조금씩 복잡해졌고,
AI의 답변을 읽을 때마다
해소되지 않는 불편함이 남았다.

그 불편함이 결국
AI 호출 구조를 다시 생각하게 만든 씨앗이 되었다.

---

날짜보다 먼저 남아 있던 버전 번호

지금 노션(Notion)에 남아 있는 생성일을 다시 보면,
이 흐름은 생각보다 짧은 시간 안에 빠르게 진행되었다.

2025년 9월 말,
명리 공부가 본격적으로 생활 안으로 들어오던 시기와
AI 프롬프트 실험이 거의 겹쳐 있었다.

그 무렵의 기록에는
신왕신약 판별, 가중치, 계량화 같은 말들이 보이기 시작한다.

처음부터 완성된 계산 엔진을 만들려고 한 것은 아니었다.

다만 AI의 자연스러운 답변을 보면서
“적어도 이 말이 맞는지 내가 확인할 수 있어야 한다”는 생각이 강해졌다.

그리고 2025년 10월 초로 넘어가면
기초 계량화, 확장 변수, AI명리Calc, 엔진 지침서 같은 이름들이 나타난다.

곧이어 Rulebook Prompt,
초기 코드 프레임,
AnalysisState 같은 구조화의 흔적도 보이기 시작한다.

10월 10일 전후에는
LLM 실행 프로토콜,
학파별 프로파일,
종합 보고서 프롬프트가 집중적으로 생겨났다.

10월 중순에는
반례 튜닝,
Gold Labels,
교차검증,
공개 고전 기반 데이터 수집 같은 문서들이 이어졌다.

10월 말에는
v0.4.x, v0.5.0, v0.6.x 계열의 종합 보고서 프롬프트와
AI Studio 관련 문서들이 빠르게 늘어났다.

지금 돌아보면
이 흐름은 단순한 프롬프트 수정 기록이 아니었다.

프롬프트는 이미
프로토콜, 데이터 구조, 검증 구조, 초기 코드 쪽으로
자리를 내어주고 있었다.

당시에는 날짜보다 버전 번호가 먼저 눈에 들어왔다.

v0.3.1, v0.3.2, v0.4.7, v0.5.0, v0.6.0.

그 숫자들은 완성도를 자랑하는 번호가 아니었다.

오히려 해결되지 않은 같은 문제를
여러 번 나누어 붙잡았던 흔적이었다.

---

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

이 시기에 생성형 AI 모델들의 성능도 빠르게 좋아지고 있었다.

긴 프롬프트를 더 잘 따라오는 것처럼 보였고,
표나 JSON 같은 구조화된 답변도
이전보다 훨씬 자연스럽게 만들어 냈다.

그래서 한동안은
모델이 조금 더 좋아지면
복잡한 코드 없이 프롬프트만으로도
명리 판단을 안정시킬 수 있지 않을까 하는 기대가 있었다.

하지만 반복해서 테스트해 볼수록
그 기대는 조금씩 조정되었다.

모델이 좋아지면
문장은 더 매끄러워진다.

긴 지시도 더 잘 받아들이고,
표도 더 깔끔하게 만들고,
JSON 규격도 더 잘 맞춘다.

하지만 모델이 좋아진다고 해서
그 판단이 어디에서 나왔는지
자동으로 검증 가능해지는 것은 아니었다.

AI가 월령을 말할 수는 있다.

하지만 그 월령 값이
시스템에서 계산된 값인지,
문맥상 그럴듯하게 이어 낸 말인지
텍스트만으로는 구분하기 어려웠다.

AI가 신강약을 말할 수는 있다.

하지만 그 판단이
득령, 득지, 득세, 십신 배치 같은 재료를
어떤 순서와 기준으로 반영한 것인지
확인하기 어려웠다.

AI가 근거를 제시할 수는 있다.

하지만 그 근거가
판단 전에 확보된 재료인지,
이미 나온 결론을 설명하기 위해 뒤에 붙은 문장인지
분명하지 않을 때가 있었다.

여기서 중요한 구분이 생겼다.

문장의 품질과 판단의 검증성은 다른 문제다.

프롬프트 시대가 남긴 가장 큰 벽은
바로 이 지점이었다.

---

생각의 궤도를 수정하다

이때부터 AI를 바라보는 관점이 바뀌기 시작했다.

AI에게 분석의 전 과정을 맡기는 것이 아니라,
AI에게 넘겨 줄 재료를 먼저 준비해야 한다.

AI가 명조를 계산하게 하는 것이 아니라,
명조 계산은 엔진이 해야 한다.

AI가 근거를 문장으로 만들어 내게 하는 것이 아니라,
근거는 계산 과정에서 추적 가능한 기록으로 남아 있어야 한다.

AI가 스스로 새로운 판단을 내리게 하는 것이 아니라,
엔진이 확정한 판단 재료와 후보 상태를 넘겨주고
AI는 그 범위 안에서 문장화해야 한다.

이것이 나중에 MRA의 AI 호출 설계 원칙이 되었다.

당시에는 이런 표현을 쓰지 않았지만,
지금의 언어로 정리하면 방향은 분명하다.

• AI는 계산자가 아니다.
• AI는 원자료 없이 독단적으로 판단을 확정하지 않는다.
• AI는 엔진이 산출한 데이터를 받아 문장화한다.
• 계산 재료와 최종 서술 문장은 분리한다.
• 근거는 사후 윤색이 아니라 앞단의 산출물이어야 한다.
• 불확실성은 말투가 아니라 상태값으로 관리되어야 한다.
• 출력 형식은 AI가 꾸미는 것이 아니라 시스템이 제공하는 구조여야 한다.

이 원칙들은 처음부터 있었던 것이 아니다.

역할 프롬프트가 흔들렸기 때문에 생겼고,
Rulebook Prompt가 절차를 보장하지 못했기 때문에 생겼으며,
JSON 출력이 데이터처럼 보이는 착시를 만들었기 때문에 생겼다.

시행착오가 설계 원칙으로 바뀐 셈이었다.

---

지금 돌아보면

제1부 프롬프트 시대는
겉으로 보면 프롬프트를 계속 고쳐 쓴 기록이다.

하지만 그 안에는
MRA의 거의 모든 핵심 문제가 이미 들어 있었다.

역할의 문제.
절차의 문제.
근거의 문제.
출력 형식의 문제.
계산과 문장화의 분리 문제.
검증 가능성의 문제.

처음에는 이 모든 것을
프롬프트 안에서 해결하려 했다.

하지만 그 시도는 오래 버티기 어려웠다.

프롬프트는 요청할 수 있다.
하지만 실행을 보장하지는 못한다.

프롬프트는 형식을 정할 수 있다.
하지만 사실성을 보장하지는 못한다.

프롬프트는 근거를 말하게 할 수 있다.
하지만 그 근거가 실제 계산 과정에서 나온 것인지는
따로 확인해야 한다.

이 지점에서 다음 단계가 필요해졌다.

프롬프트를 더 길게 쓰는 것이 아니라,
프롬프트 밖에 실제 실행 가능한 로직을 두어야 했다.

AI가 임의로 판단 순서를 정하지 않도록,
무엇을 먼저 계산하고,
어떤 값을 중간 상태로 남기며,
어떤 판단을 후보로 보류하고,
어떤 결과를 다음 단계의 입력으로 넘길 것인지를
프로그램 구조 안에서 정리해야 했다.

그 흐름이 나중에 초기 코드 프레임으로 이어졌다.

프롬프트 안에 문장으로 적어 두었던
입력 확인, 월령 확인, 오행 분포, 신강약 판단, 격국 후보, 용신 후보 같은 항목들은
점차 코드의 함수와 상태값, 데이터 구조로 옮겨 가기 시작했다.

MRA는 완성된 엔진에서 출발하지 않았다.

처음에는 프롬프트였다.

그리고 그 프롬프트가 한계에 부딪혔을 때,
비로소 실제 로직을 구성해야 한다는 다음 단계가 보이기 시작했다.

---

부록 A. 프롬프트 시대가 남긴 AI 호출 설계 원칙

프롬프트 시대의 실험들은
나중에 AI 호출 설계의 기준으로 돌아왔다.

다만 그 기준은
AI에게 더 정교한 프롬프트를 주는 방향이 아니었다.

오히려 계산과 판단 재료를 프로그램 로직으로 옮기고,
AI에게는 그 결과를 문장화하는 역할만 맡기는 방향이었다.

당시에는 흩어진 메모에 가까웠지만,
지금 보면 다음과 같은 원칙으로 정리할 수 있다.

---

A-1. AI에게 계산을 맡기지 않는다

당시 문제

AI는 명조와 오행, 십신, 신강약을 자연스럽게 설명할 수 있었다.

하지만 그 판단이 실제 계산을 거친 것인지
확인하기 어려웠다.

설계 원칙

• 명조 계산은 프로그램 로직이 수행한다.
• 월령, 오행 분포, 십신 배치 등은 계산된 데이터로 남긴다.
• AI는 계산 결과를 다시 계산하지 않는다.

다음 변화

• 계산 모듈과 설명 모듈을 분리하는 방향으로 이어졌다.

---

A-2. 근거는 사후 문장이 아니라 앞단의 산출물이어야 한다

당시 문제

AI는 근거를 잘 설명했다.

하지만 그 근거가 실제 판단 전에 사용된 재료인지,
결론을 설명하기 위해 뒤에 붙은 문장인지
구분하기 어려웠다.

설계 원칙

• 판단에는 반드시 근거 재료가 연결되어야 한다.
• 근거는 문장 생성 이전에 존재해야 한다.
• 어떤 재료가 어떤 판단에 쓰였는지 추적 가능해야 한다.

다음 변화

• Trace와 Evidence 개념으로 이어졌다.

---

A-3. 후보 판단과 확정 판단을 구분한다

당시 문제

프롬프트에 “후보로 남겨라”라고 적어도,
최종 문장에서는 후보가 확정처럼 표현되는 경우가 있었다.

설계 원칙

• 후보 판단은 후보 상태로 남긴다.
• 확정 판단과 후보 판단을 같은 층위에서 섞지 않는다.
• 불확실성은 말투가 아니라 데이터 상태로 관리한다.

다음 변화

• 후보군, 불확실성, 검증 상태를 별도 필드로 나누는 방향으로 이어졌다.

---

A-4. AI는 문장화 계층으로 제한한다

당시 문제

AI가 계산, 판단, 근거 생성, 최종 해석을 모두 맡으면
어디서 오류가 생겼는지 확인하기 어려웠다.

설계 원칙

• AI는 프로그램 로직이 넘긴 재료 안에서 설명한다.
• AI는 새로운 판단을 임의로 추가하지 않는다.
• AI는 일반인이 이해할 수 있는 문장으로 바꾸는 역할을 맡는다.

다음 변화

• 계산 로직, 분석 상태, 설명 계층을 나누는 구조로 이어졌다.

---

노트 한 줄 요약

시행착오는 실패가 아니라, 프롬프트 밖에 실행 로직을 세워야 한다는 설계 원칙으로 돌아온 기록이었다.

---

다음 글

다음 글에서는 프롬프트 안에 문장으로 적어 두었던 판단 순서가 어떻게 실제 프로그램 로직과 초기 코드 프레임으로 옮겨 가기 시작했는지를 다룹니다.

태그: MRA, MRA엔진노트, AI명리, 프롬프트실험, 프롬프트공학, AI호출, LLM, 데이터구조, Trace, K명리
locale: ko-KR