4. 프롬프트가 길어질수록 더 잘 되는 것처럼 보였다

 

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

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

---

어느 날의 화면

프롬프트 입력창의 스크롤이 점점 길어지고 있었다.

처음에는 한두 줄이면 충분할 것 같았다.

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

하지만 역할 부여만으로는 부족했다.

그래서 분석 순서를 넣었다.
분석 순서를 넣어도 판단이 흔들렸다.
그래서 금지 규칙을 붙였다.
금지 규칙을 붙여도 결과물의 구조가 흔들렸다.
결국 출력 형식까지 지정하기 시작했다.

처음에는 이 덧붙임의 과정이 옳은 방향처럼 보였다.

프롬프트가 길어질수록
AI의 답변은 눈에 띄게 정돈되었다.

문단이 나뉘고,
항목이 생기고,
나름의 근거 문장이 붙고,
마지막에는 조심스러운 종합문까지 출력되었다.

화면 속의 결과물은 분명히 나아지고 있었다.

하지만 프롬프트가 길어질수록
내가 직접 확인해야 할 의심의 영역도 함께 늘어났다.

답변의 형식은 좋아졌지만,
그 안의 내용을 정말 더 믿을 수 있게 된 것인지는
별개의 문제였다.

---

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

당시의 질문은 단순했다.

프롬프트를 더 정교하고 자세히 쓰면,
AI의 명리 판단도 그만큼 안정될까.

처음에는 그렇다고 생각했다.

AI가 빠뜨리는 부분이 있으면
그 항목을 프롬프트에 추가하면 된다.

AI가 너무 확정적으로 말하면
단정하지 말라는 규칙을 쓰면 된다.

AI가 순서를 건너뛰면
번호를 매겨 순서를 요구하면 된다.

문장이 너무 일반적이면
명리 용어를 쓰라고 하면 된다.

문장이 너무 어렵게 나오면
일반인도 이해할 수 있게 풀어서 설명하라고 하면 된다.

이렇게 구멍을 하나씩 메우다 보면
언젠가는 꽤 안정적인 명리 분석 프롬프트가 만들어질 것 같았다.

하지만 텍스트가 쌓일수록
문제는 예상과 다른 방식으로 나타났다.

프롬프트가 길어질수록
답변은 더 그럴듯해졌지만,
그 문장 속에서 어떤 지시가 우선적으로 작동했는지를
추적하기는 더 어려워졌다.

역할 지시, 분석 순서, 금지 규칙, 출력 형식, 문체 요구가
하나의 프롬프트 텍스트 안에서 뒤섞이기 시작했다.

통제력이 커지는 것처럼 보였지만,
실제로는 점점 더 관리하기 어려운 덩어리가 되어 가고 있었다.

---

무작정 부딪혀본 기록

프롬프트 안에는 계속 새로운 요구사항이 붙었다.

처음에는 역할이었다.

너는 사주명리 분석가다.

그다음에는 분석 순서가 붙었다.

1. 일간을 확인하라.
2. 월령을 기준으로 계절의 힘을 보라.
3. 오행의 분포와 십신의 배치를 확인하라.
4. 신강약을 판단한 뒤 격국과 용신 후보를 검토하라.

여기에 금지 규칙이 더해졌다.

• 용신은 근거 없이 단정하지 말라.
• 격국은 후보로만 검토하라.
• 건강, 수명, 사고는 단정하지 말라.
• 불확실한 판단은 불확실하다고 명시하라.

다음에는 출력 형식이 지정되었다.

출력은 다음 항목으로 나누어라.
원국 요약, 신강약 판단, 격국 후보, 용신 후보, 대운 흐름, 세운 흐름, 종합 해석, 주의 사항.

마지막으로 문체 지침까지 들어갔다.

전문적인 명리 용어를 사용하되 일반인도 이해할 수 있게 설명하라.
상담이나 예언처럼 보이는 표현은 피하라.
참고형 문장으로 마무리하라.

조목조목 보면 모두 필요한 지시들이었다.

문제는 이 모든 조건이
단 하나의 프롬프트 안에 들어갔다는 점이다.

겉으로는 고도화된 지침서처럼 보였다.

하지만 내부적으로는 역할, 절차, 금지, 출력, 문체가
한 공간에서 뒤섞여 있었다.

어떤 문장은 분석을 요구하고,
어떤 문장은 단정을 금지했다.

어떤 문장은 결론을 요구하면서도,
다른 문장은 조심스럽게 쓰라고 했다.

이 지시들은 저마다 타당했지만,
동시에 서로 긴장 관계를 만들고 있었다.

---

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

긴 프롬프트는 분명 답변을 좋아 보이게 만들었다.

짧은 지시문일 때보다 훨씬 체계적이었고,
표현은 신중해졌으며,
근거처럼 보이는 문장도 늘어났다.

하지만 바로 그 지점에 문제가 있었다.

답변이 좋아 보이는 것과
판단이 검증 가능해지는 것은 다른 일이었다.

AI가 문장에 “월령을 기준으로 보았다”고 적어도,
실제로 월령을 먼저 반영해 판단했는지는 알 수 없었다.

“용신은 후보로만 제시한다”고 서두를 떼고도,
글을 맺을 때쯤에는 하나의 결론처럼 흘러가기도 했다.

“근거를 제시한다”며 문장을 이어 갔지만,
그 근거가 명리적 산출값에서 나온 것인지
문장 흐름에 맞춰 붙은 것인지는 다시 검토해야 했다.

프롬프트가 길어질수록
AI는 더 많은 조건을 수용하는 듯 보였다.

하지만 동시에
어떤 조건이 우선되었는지는 더 흐려졌다.

가장 큰 벽은 지시의 충돌에서 나타났다.

• “용신을 단정하지 말라”면서도 “용신 후보를 종합해 설명하라”고 했다.
• “전문적으로 설명하라”면서도 “일반인이 쉽게 이해하게 하라”고 했다.
• “판단의 근거를 자세히 쓰라”면서도 “최종 문장은 간결하게 정리하라”고 했다.

이 조건들을 하나의 프롬프트로 받으면,
AI는 그 사이를 자연스러운 문장으로 메웠다.

AI는 지시가 충돌한다고 따로 알려 주지 않았다.
그저 그럴듯한 타협점을 찾아 문장으로 정리했다.

읽는 입장에서는 좋아 보였다.

하지만 시스템을 설계하고 검토해야 하는 입장에서는
이 매끄러운 타협이 오히려 조심스러웠다.

어떤 지시가 실제로 반영되었고,
어떤 지시가 흐려졌는지 다시 확인해야 했기 때문이다.

---

생각의 궤도를 수정하다

이때를 기점으로
프롬프트를 길게 쓰는 것이 항상 해결책은 아니라는 생각이 들었다.

문장의 길이가 시스템의 안정성을 보장해 주지는 않는다.

정작 필요한 것은 지시문을 계속 덧붙이는 일이 아니라,
지시의 역할을 분리하는 일이었다.

역할 지시는 역할 지시대로.
분석 절차는 분석 절차대로.
금지 규칙은 금지 규칙대로.
출력 형식은 출력 구조로.
문체 지침은 최종 문장 생성 단계로.

이 기능들이 텍스트 박스 하나에 뒤섞여 있으면
검토와 제어가 어려웠다.

프롬프트를 늘릴 것이 아니라,
프롬프트를 나누어야 했다.

나중에 MRA 구조가
명조 계산, 판단 재료, 추적, 근거, 최종 AI 문장화로 나뉘게 된 것도
이 시기의 불편함과 연결되어 있다.

처음에는 단순히 프롬프트가 너무 길어져서 문제인 줄 알았다.

하지만 본질은 길이가 아니라
구조적 분리의 부재에 있었다.

---

지금 돌아보면

긴 프롬프트를 작성했던 시간들이 실패였다고 생각하지는 않는다.

그렇게 계속 덧붙였던 과정이 있었기에,
명리 AI 시스템에 어떤 요소들이 필요한지 조금씩 알 수 있었다.

역할 부여가 필요하다는 것.
판단 절차가 필요하다는 것.
금지 규칙이 필요하다는 것.
출력 형식이 필요하다는 것.
검증 가능한 근거가 필요하다는 것.

문제는 그것들을
프롬프트라는 단일 텍스트 안에서 모두 해결하려 했다는 데 있었다.

길어진 프롬프트는
답변의 품질을 올려 주는 해결책이라기보다,
앞으로 MRA가 무엇을 구조적으로 분리해야 하는지 보여 주는
요구사항 목록에 가까웠다.

역할과 절차를 분리해야 한다.
절차와 계산을 분리해야 한다.
계산과 해석 재료를 분리해야 한다.
해석 재료와 최종 문장화를 분리해야 한다.
그리고 그 모든 과정은 다시 되짚어 검토할 수 있는 흔적을 남겨야 한다.

프롬프트는 마치 자신이 작은 엔진인 것처럼 보이기도 했다.

하지만 프롬프트는 엔진이 될 수 없었다.

프롬프트는 LLM에게 절차를 요청할 수는 있다.
하지만 그 절차가 실제로 실행되었음을 보장하지는 못한다.

이 한계와 불편함이 자연스럽게 다음 시도로 이어졌다.

모호한 자유문 답변을 통제하기 위해,
출력 형식을 표나 JSON으로 고정해 보려는 실험이었다.

---

부록 A. 길어진 프롬프트의 흔적

프롬프트가 길어진 것은 단순히 요구사항이 많아서가 아니었다.

테스트 과정에서 발견된 AI의 불안정한 판단과 오류를
하나씩 문장으로 막아 보려다 보니 생긴 일이었다.

---

A-1. 역할 지시가 붙은 형태

너는 사주명리 분석가다.
고전 명리의 원리에 따라 명조를 분석하라.
전문적인 명리 용어를 사용하되, 일반인도 이해할 수 있도록 설명하라.

당시 의도

• AI의 답변을 막연한 조언에서 명리 분석문으로 전환시키고 싶었다.
• 명리 용어를 사용하게 하려 했다.
• 독자가 읽기 편한 톤을 맞추려 했다.

남은 문제

• 말투는 바뀌었지만 판단 절차는 여전히 보이지 않았다.
• 문체 지시와 분석 지시가 섞이기 시작했다.
• 전문적인 문장과 검증 가능한 판단은 분리되지 않았다.

다음 변화

• 지시문 아래에 구체적인 분석 순서를 추가하기 시작했다.

---

A-2. 분석 순서와 금지 규칙이 함께 들어간 형태

다음 순서로 분석하라.
일간 확인 → 월령 확인 → 오행 분포와 십신 배치 확인 → 신강약 판단 → 격국과 용신 후보 검토 → 대운과 세운 연결.

다음 사항은 반드시 지켜라.
용신은 근거 없이 단정하지 말 것.
격국은 후보로만 남길 것.
건강, 수명, 사고는 단정하지 말 것.
불확실한 부분은 후보로 표시할 것.

당시 의도

• AI가 정해진 순서에 따라 답변하게 하려 했다.
• 과도한 단정과 성급한 결론을 줄이고 싶었다.
• 원국 판단과 운 해석을 분리하려 했다.

남은 문제

• 절차와 금지 규칙이 한 공간에 섞이며 지시의 우선순위가 흐려졌다.
• 규칙을 텍스트로 적어 두었다고 해서 LLM의 실행이 보장되지는 않았다.
• 답변 형식은 정리되었지만, 판단 근거는 여전히 따로 검토해야 했다.

다음 변화

• 자유 서술형 답변의 한계를 느끼고, 출력 형식을 강제로 고정하는 방향으로 넘어갔다.

---

A-3. 출력 형식까지 결합된 형태

출력은 반드시 다음 항목으로 나누어 작성하라.

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

당시 의도

• 답변을 규격화해 테스트 결과를 비교하기 쉽게 만들고 싶었다.
• AI가 임의로 판단 단계를 누락하는 것을 줄이고 싶었다.
• 이후 검토하기 쉬운 구조를 만들고 싶었다.

남은 문제

• 겉보기 형식은 정돈되었지만, 내용의 사실성은 별개의 문제였다.
• 항목이 존재한다고 해서 그 안의 텍스트가 정확한 계산을 거쳤다는 뜻은 아니었다.
• 출력 형식은 답변을 정리할 수 있지만, 판단을 보장하지는 못했다.

다음 변화

• 텍스트 기반의 항목 구분을 넘어, 표, 단계, JSON 형태의 더 엄격한 출력 형식을 시도하게 된다.

---

A-4. 이 단계에서 남긴 설계 메모

• 프롬프트가 길어진다고 해서 검증성이 확보되는 것은 아니다.
• 프롬프트 안의 지시 사항이 많아질수록 충돌 가능성도 커진다.
• AI는 지시 충돌을 따로 경고하지 않고 자연스러운 문장으로 메울 수 있다.
• 역할, 절차, 제약 조건, 출력 형식은 분리해서 관리해야 한다.
• 현재의 프롬프트는 작은 프로그램처럼 보이지만, 프로그램처럼 확정적으로 동작하지 않는다.

당시 의도

• 프롬프트 튜닝의 한계를 인정하고, 텍스트 수정을 넘어선 구조 분리의 필요성을 정리하려 했다.
• 프롬프트 개선이 곧 판단 안정화는 아니라는 점을 남기려 했다.
• 다음 단계에서 출력 형식을 고정해야 할 필요성을 기록하려 했다.

남은 문제

• 명리의 계산과 해석 로직이 여전히 LLM 내부에 남아 있었다.
• 지시의 우선순위가 명확하지 않았다.
• 검증 가능한 산출물이 남지 않았다.

다음 변화

• AI의 자유도를 줄이기 위해 출력 형식을 표, 단계, JSON 등으로 고정하려는 다음 단계의 실험으로 넘어가게 된다.

---

노트 한 줄 요약

프롬프트가 길어질수록 문장은 정교해 보였지만, 그것이 검증 가능한 올바른 판단을 뜻하는 것은 아니었다.

---

다음 글

다음 글에서는 자유문 답변의 불안정성을 통제하기 위해 표, 단계별 보고서, JSON 구조 등을 동원하여 출력 형식을 고정하려 했던 시도를 다룹니다.

---

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