5. 출력 형식을 고정하려 했다: 표, 단계, JSON

 

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

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

---

어느 날의 화면

프롬프트가 길어지고 복잡해지자
답변은 꽤 정돈되어 보였다.

하지만 정돈된 문장과
검토 가능한 결과물은 같은 것이 아니었다.

AI가 길고 자연스러운 설명을 만들어 내면
처음에는 그럴듯해 보인다.

그런데 막상 다시 읽어 보면
어느 부분이 실제 명리적 판단이고,
어느 부분이 그 판단의 근거이며,
어느 부분이 문맥을 부드럽게 잇기 위한 문장인지
구분하기 어려웠다.

그래서 다음 시도로
답변의 형식 자체를 고정해 보려 했다.

자유롭게 쓰게 하니까
문장 속에 판단 과정이 숨어 버린다면,
아예 텍스트가 들어갈 칸을 정해 주면 되지 않을까.

표로 쓰게 하면
각 판단 항목을 비교하기 쉬울 것 같았다.

단계별 보고서로 쓰게 하면
분석에서 빠진 부분을 확인하기 쉬울 것 같았다.

JSON처럼 구조화된 형식으로 쓰게 하면
나중에 그 결과를 코드와 연결할 수도 있을 것 같았다.

통제하기 어려운 문장 생성을 제어하기 위해,
적어도 그 문장이 담길 그릇이라도 고정해 보려 했다.

---

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

그때의 질문은 이랬다.

AI의 답변이 흔들린다면,
출력 형식을 고정하면 판단도 함께 안정되지 않을까.

자유 서술형 답변은 읽기에는 편했지만
검토하기에는 어려웠다.

어떤 답변은 원국(原局) 설명에 많은 지면을 썼고,
어떤 답변은 대운(大運) 이야기로 빨리 넘어갔다.

어떤 답변은 격국(格局)을 중심에 두었고,
어떤 답변은 용신(用神)을 먼저 결론처럼 내세웠다.

답변마다 문장의 뼈대가 달라지니
같은 기준에서 비교하기가 어려웠다.

그래서 강제로 넣을 항목을 정해 보았다.

• 원국 요약
• 일간과 월령
• 오행 분포
• 십신 배치
• 신강약 판단
• 격국 후보
• 용신 후보
• 대운과 세운 흐름
• 종합 해석
• 주의 사항

이런 식으로 항목을 쪼개고 고정해 두면,
적어도 어느 분석 단계가 빠졌는지는
한눈에 확인할 수 있을 것 같았다.

나아가 형식이 고정되면
AI도 그 형식에 맞춰 조금 더 신중하게 판단할 것이라는 기대도 있었다.

지금 돌아보면,
이 기대 안에는 중요한 착각이 섞여 있었다.

답변의 형식을 정돈하는 것과
실제 판단을 검증하는 것은
다른 층위의 문제였기 때문이다.

---

무작정 부딪혀본 기록

처음에는 표 출력을 요구했다.

아래 항목을 마크다운 표로 정리하라.
항목, 판단, 근거, 주의 사항을 나누어 작성하라.

그러면 AI는 지시에 맞춰
표처럼 보이는 답변을 만들어 냈다.

항목	판단	근거	주의
일간	신약	월령과 오행 분포 참고	단정 금지
신강약	신약	득령, 득지, 득세 검토	추가 확인 필요
격국 후보	정관격	월지와 투간 여부 검토	확정 보류
용신 후보	인성	원국 균형 참고	단정 금지

처음에는 이 표가 꽤 쓸모 있어 보였다.

자유 서술형 문장보다 비교하기 쉬웠고,
어떤 판단 항목이 빠졌는지도 눈에 들어왔다.

그다음에는 단계별 보고서를 요구했다.

1단계: 원국 요약
2단계: 일간과 월령 확인
3단계: 오행 분포 확인
4단계: 십신 배치 확인
5단계: 신강약 판단
6단계: 격국 후보 검토
7단계: 용신 후보 검토
8단계: 대운과 세운 연결

이 방식도 겉보기에는 효과가 컸다.

AI는 번호에 맞춰 답변을 나누었고,
읽는 사람 입장에서는 분석의 흐름이
훨씬 선명해 보였다.

이후에는 JSON 형태도 요구하게 되었다.

자유문이나 마크다운 표는 결국 텍스트지만,
JSON은 코드와 연결할 수 있을 것 같았기 때문이다.

{
  "day_master": "",
  "month_command": "",
  "five_elements_summary": "",
  "ten_gods_summary": "",
  "strength_assessment": {
    "value": "",
    "evidence": []
  },
  "structure_candidates": [],
  "useful_god_candidates": [],
  "narrative_summary": ""
}

이 형식을 처음 보았을 때는
조금 다른 단계로 넘어간 것처럼 느껴졌다.

이제 AI의 답변이 그냥 글이 아니라
데이터처럼 보였기 때문이다.

하지만 곧 알게 되었다.

JSON처럼 생긴 답변과
실제로 계산된 데이터는 같은 것이 아니었다.

---

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

출력 형식을 고정하자
답변은 훨씬 관리하기 쉬워 보였다.

하지만 문제의 성격은 그대로 남아 있었다.

표가 있다고 해서
표 안의 판단이 맞는 것은 아니었다.

단계 번호가 있다고 해서
그 단계가 실제로 순서대로 실행된 것도 아니었다.

JSON 구조가 있다고 해서
그 값들이 계산 엔진에서 나온 것도 아니었다.

예를 들어 AI가 이렇게 썼다고 해 보자.

"strength_assessment": {
  "value": "신약",
  "evidence": ["월령 불득", "관성 강함"]
}

겉으로 보기에는 판단과 근거가 연결되어 있다.

하지만 실제로는
AI가 먼저 월령을 계산하고,
그 결과를 저장하고,
그 값을 다시 신강약 판단에 사용했는지 알 수 없었다.

문장으로 근거가 붙어 있을 뿐이었다.

또 다른 문제도 있었다.

형식을 고정하면
오히려 빈칸이 채워져야 한다는 압력이 생겼다.

AI는 항목이 비어 있으면
무언가를 써 넣으려 했다.

확실하지 않은 항목도
그럴듯한 말로 채워질 수 있었다.

표의 칸은 비어 있지 않았지만,
그 안의 판단이 얼마나 검증 가능한지는 여전히 알 수 없었다.

이때 분명해진 것은 하나였다.

출력 형식은 답변을 정돈해 준다.

하지만 판단의 사실성을 보장하지는 않는다.

---

생각의 궤도를 수정하다

처음에는 형식을 고정하면
판단도 함께 안정될 것이라고 생각했다.

하지만 몇 번 반복해 보니
형식과 판단은 분리해서 보아야 한다는 쪽으로 생각이 바뀌었다.

표는 비교를 돕는다.
단계별 보고서는 누락을 발견하는 데 도움이 된다.
JSON은 시스템 연결 가능성을 생각하게 만든다.

그러나 이들은 모두 출력의 그릇이다.

그릇이 정돈되어 있다고 해서
그 안의 내용이 자동으로 검증되는 것은 아니다.

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

어떤 형식으로 출력하게 할 것인가가 아니라,
그 형식 안에 들어갈 값이 어디에서 나왔는가를 물어야 했다.

AI가 만든 표인가.
엔진이 계산한 값을 표로 보여 준 것인가.

AI가 만든 JSON인가.
계산 모듈이 산출한 데이터를 JSON으로 직렬화한 것인가.

겉모양은 비슷해도
둘은 완전히 다른 구조였다.

이 차이를 인정하면서
MRA의 방향도 조금 더 선명해졌다.

AI에게 구조화된 답변을 만들라고 할 것이 아니라,
먼저 계산된 구조를 만들고
그 구조를 AI에게 넘겨야 했다.

AI가 표를 만들어 내는 것이 아니라,
엔진이 산출한 항목을 표로 보여 주어야 했다.

AI가 근거를 만들어 붙이는 것이 아니라,
근거가 먼저 있고
AI는 그것을 문장으로 바꾸어야 했다.

---

지금 돌아보면

출력 형식을 고정하려던 시도는
실패라기보다 필요한 중간 단계였다.

그 시도를 통해
나는 형식의 유용성과 한계를 동시에 보게 되었다.

형식은 분명 도움이 된다.

자유 서술형 답변보다
표는 비교하기 쉽다.

단계별 보고서는
어디가 빠졌는지 확인하기 쉽다.

JSON은 나중에 코드와 연결할 가능성을 생각하게 한다.

하지만 형식은 어디까지나 형식이다.

표는 판단을 담는 그릇이지
판단 그 자체가 아니다.

단계 번호는 절차의 표시이지
실제 실행 로그가 아니다.

JSON은 데이터처럼 보일 수 있지만,
AI가 만들어 낸 JSON은
계산 엔진의 산출물과 다르다.

이 차이를 알게 되면서
프롬프트 시대의 다음 문제가 드러났다.

프롬프트 안에 절차와 조건, 형식을 모두 넣다 보면
그것은 점점 작은 프로그램처럼 변해 간다.

하지만 프로그램처럼 보이는 것과
실제로 실행되는 것은 다른 문제다.

이 지점에서 5편은 자연스럽게 6편으로 이어졌다.

형식을 고정하려던 시도는
프롬프트가 작은 프로그램처럼 비대해지는 계기가 되었고,
그 과정에서 계산과 문장화를 분리해야 한다는 생각이
조금씩 더 분명해졌다.

---

부록 A. 출력 형식을 고정하려던 프롬프트의 흔적

이 시기의 프롬프트에는
답변을 자유 서술형으로 두지 않기 위한 여러 형식 지시가 들어갔다.

표, 단계별 보고서, JSON은
모두 답변을 검토 가능하게 만들려는 시도였다.

다만 그 형식은
검증의 시작점일 수는 있어도
검증 자체는 아니었다.

---

A-1. 표 출력 요구

아래 항목을 마크다운 표로 정리하라.
항목, 판단, 근거, 주의 사항을 나누어 작성하라.
불확실한 판단은 주의 사항에 표시하라.

당시 의도

• 자유 서술형 답변을 비교 가능한 형태로 바꾸고 싶었다.
• 판단과 근거를 같은 행에 놓고 확인하려 했다.
• 누락된 항목을 쉽게 찾고 싶었다.

남은 문제

• 표 안의 근거가 실제 계산 결과인지 확인하기 어려웠다.
• AI가 항목을 채우기 위해 그럴듯한 표현을 만들 수 있었다.
• 표는 비교를 도왔지만 판단의 정확성을 보장하지는 않았다.

다음 변화

• 판단 항목과 근거 항목을 단순 문장이 아니라 데이터 구조로 분리해야 한다는 생각으로 이어졌다.

---

A-2. 단계별 보고서 요구

1단계: 원국 요약
2단계: 일간과 월령 확인
3단계: 오행 분포 확인
4단계: 십신 배치 확인
5단계: 신강약 판단
6단계: 격국 후보 검토
7단계: 용신 후보 검토
8단계: 대운과 세운 연결

당시 의도

• 명리 판단 순서를 눈에 보이게 만들고 싶었다.
• 어느 단계가 빠졌는지 확인하고 싶었다.
• AI가 분석 순서를 건너뛰지 않게 하려 했다.

남은 문제

• 번호가 붙었다고 해서 실제로 그 순서가 실행된 것은 아니었다.
• 앞 단계의 판단이 뒤 단계의 입력으로 사용되었는지 확인하기 어려웠다.
• 단계별 서술이 오히려 절차가 실행된 것처럼 보이는 착시를 만들 수 있었다.

다음 변화

• 절차는 프롬프트 문장이 아니라, 실행 가능한 프로토콜과 계산 흐름으로 분리되어야 한다는 생각으로 이어졌다.

---

A-3. JSON 출력 요구

결과는 아래 JSON 형식으로 작성하라.
각 필드는 빠뜨리지 말고 채워라.
근거는 evidence 배열에 넣어라.
불확실한 판단은 candidates 배열로 분리하라.

{
  "day_master": "",
  "month_command": "",
  "five_elements_summary": "",
  "ten_gods_summary": "",
  "strength_assessment": {
    "value": "",
    "evidence": []
  },
  "structure_candidates": [],
  "useful_god_candidates": [],
  "uncertainty_notes": [],
  "narrative_summary": ""
}

당시 의도

• AI 답변을 나중에 코드에서 다시 다룰 수 있는 형태로 만들고 싶었다.
• 판단값과 근거를 구조화해 보려 했다.
• 후보 판단과 확정 판단을 구분하고 싶었다.

남은 문제

• AI가 만든 JSON은 계산 엔진의 산출물이 아니라 구조화된 텍스트였다.
• 필드가 있다고 해서 그 값의 출처가 보장되지는 않았다.
• JSON 구조가 오히려 데이터처럼 보이는 착시를 만들 수 있었다.

다음 변화

• AI가 JSON을 만들게 하는 것이 아니라, 계산 엔진이 먼저 데이터를 만들고 AI는 그 데이터를 문장화해야 한다는 방향으로 이어졌다.

---

노트 한 줄 요약

형식은 답변을 정돈하지만, 사실성을 보장하지는 않는다.

---

다음 글

다음 글에서는 표, 단계, JSON을 넘어 프롬프트가 점점 작은 프로그램처럼 변해 가던 시기를 다룹니다.

---

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