6. 프롬프트가 작은 프로그램처럼 변해 갔다

 

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

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

---

어느 날의 화면

프롬프트 입력창을 가득 채운 텍스트를 다시 읽어 보던 순간이었다.

이것은 더 이상 AI에게 던지는 단순한 질문이 아니었다.

처음에는 “아래 명조를 분석해 달라”는 단순한 부탁이었다.
조금 지나서는 “너는 사주명리 분석가다”라는 역할이 붙었다.
그다음에는 분석 순서가 붙고, 금지 규칙이 붙고, 출력 형식이 붙었다.
나중에는 예외 상황을 처리하기 위한 조건문까지 덧붙기 시작했다.

• 정보가 부족하면 부족하다고 말하라.
• 확실하지 않으면 단정하지 말고 후보로 남겨라.
• 대운과 세운은 원국 판단이 끝난 이후에 연결하라.

이런 문장들이 한 프롬프트 안에 층층이 쌓여 있었다.

가만히 들여다보니,
이 프롬프트는 질문이라기보다 잘 짜인 작은 프로그램처럼 보였다.

입력 규칙이 있고,
처리 순서가 있고,
조건 분기가 있고,
예외 처리가 있으며,
지정된 출력 형식이 있었다.

하지만 겉보기에는 프로그램 같았던 이 텍스트에는
중요한 차이가 하나 있었다.

프로그램은 실행된다.
하지만 프롬프트는 실행을 요청할 뿐이다.

둘은 비슷해 보였지만, 같은 것은 아니었다.

---

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

그때의 질문은 이전보다 더 근본적인 쪽으로 옮겨 갔다.

프롬프트와 프로그램의 차이는 무엇일까.

프롬프트 안에 역할, 절차, 조건, 예외 처리, 출력 형식을 빼곡히 적어 넣으면,
그것은 정말 프로그램처럼 안정적으로 작동하는 것일까.

표면적인 구조는 꽤 비슷해 보였다.

프로그램에 입력값이 있듯
프롬프트에도 입력이 있다.

프로그램에 처리 순서가 있듯
프롬프트에도 분석 순서를 적을 수 있다.

프로그램에 조건문이 있듯
프롬프트에도 “확실하지 않으면 후보로 남겨라” 같은 조건을 적을 수 있다.

프로그램에 출력 형식이 있듯
프롬프트에도 표나 JSON 같은 출력 형식을 요구할 수 있다.

그래서 한동안은 내가 쓴 프롬프트가
작은 소프트웨어처럼 느껴졌다.

하지만 실제 작동 방식은 달랐다.

코드로 짠 프로그램은
같은 입력에 대해 정해진 절차를 실행한다.

반면 LLM은 같은 프롬프트를 받아도
내부의 판단 순서를 매번 똑같이 보장하지 않는다.

프롬프트에 절차를 쓸 수는 있다.

하지만 그 절차가 실제로 순서대로 실행되었는지는 확인하기 어렵다.

프롬프트에 조건을 쓸 수는 있다.

하지만 그 조건이 모든 경우에 같은 기준으로 적용된다고 보기는 어렵다.

프롬프트는 어디까지 프로그램처럼 보일 수 있고,
어디서부터 프로그램이 아니게 되는가.

이 질문이 해결되지 않으면 다음 단계로 넘어갈 수 없었다.

---

무작정 부딪혀본 기록

프롬프트 안에는 계속해서 프로그램 같은 장치들이 추가되고 있었다.

가장 먼저 추가한 것은 입력 확인 규칙이었다.

• 입력된 명조 정보를 먼저 확인하라.
• 생년월일시가 부족하면 부족하다고 표시하라.
• 시주가 불확실하면 단일 결론으로 단정하지 말라.

그다음에는 분석 순서를 넣었다.

• 일간을 확인한다.
• 월령을 확인한다.
• 오행 분포를 살피고 십신 배치를 확인한다.
• 신강약을 판단하고 격국과 용신 후보를 검토한다.

여기에 조건과 예외 처리가 붙었다.

• 득령, 득지, 득세의 지표가 서로 엇갈리면 단정하지 말고 후보로 남겨라.
• 격국 후보가 여러 개이면 우선순위와 그 이유를 설명하라.
• 원국 판단 재료가 부족하면 대운 해석을 강하게 말하지 말라.

마지막으로 출력 형식이 붙었다.

[원국 요약] / [판단 근거] / [후보 판단] / [불확실한 부분] / [종합 해석]

이렇게 써 놓고 보면 꽤 정교하게 설계된 명세서처럼 보였다.

그러나 실제로는 이 모든 로직이
텍스트라는 하나의 통 안에 뒤섞여 있었다.

프롬프트는 점점 프로그램처럼 덩치를 키웠지만,
그 내부에는 실제 실행 단위가 존재하지 않았다.

값을 저장할 상태값도 없었고,
중간 산출물을 넘겨줄 함수도 없었으며,
어디서 오류가 났는지 확인할 수 있는 기록도 없었다.

그저 AI에게
“이 조건들을 모두 고려해서 텍스트를 만들어 달라”고
긴 요청문을 쓰고 있을 뿐이었다.

---

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

프롬프트가 작은 프로그램처럼 보이기 시작하자,
오히려 이것이 프로그램은 아니라는 사실이 더 선명해졌다.

예를 들어 이런 지시가 있다.

월령을 확인한 뒤 신강약을 판단하라.

문장으로는 명확하다.

하지만 실제로 AI가 월령 판단을 먼저 수행하고,
그 결과를 신강약 판단의 입력값으로 사용했는지는
시스템적으로 확인하기 어려웠다.

또 이런 지시도 있었다.

불확실한 판단은 후보로 남겨라.

이 문장도 분명해 보인다.

하지만 어떤 기준을 넘지 못했을 때 불확실하다고 볼 것인지,
그 기준이 매번 일관적인지 알 수 없었다.

심지어 초반에는 후보로 남겨 둔 판단이
글을 맺을 때쯤에는 문맥의 흐름을 타며
확정된 결론처럼 바뀌기도 했다.

출력 형식도 마찬가지였다.

결과를 JSON 형태로 작성하라.

이렇게 지시하면
AI는 JSON처럼 보이는 구조를 출력했다.

하지만 그 JSON은
연산 엔진이 산출해 낸 결과 객체가 아니었다.

AI가 자연어 생성 과정에서 만든
구조화된 텍스트에 가까웠다.

프롬프트는 실행의 모양을 흉내 낼 수 있었다.

하지만 실행 자체를 강제하지는 못했다.

AI가 매끄럽게 절차를 설명하는 것과,
그 절차가 실제로 차례대로 실행되는 것은 다른 일이었다.

---

생각의 궤도를 수정하다

이때부터 구조에 대한 밑그림이 조금씩 분명해졌다.

프롬프트가 자꾸 프로그램처럼 보인다면,
오히려 진짜 프로그램으로 넘겨야 할 영역을 찾아야 했다.

물론 프롬프트에 남겨 두어야 할 영역도 있었다.

• 일반인이 이해할 수 있게 설명하라.
• 단정적 표현을 피하고 참고형 문장으로 작성하라.

이런 자연어 생성과 문체 지침은
LLM이 잘할 수 있는 영역이었다.

하지만 프롬프트에만 맡기기 어려운 영역도 뚜렷해졌다.

명조를 세우는 일.
월령을 확인하는 일.
오행의 세력을 정리하는 일.
신강약 판단에 필요한 재료를 모으는 일.
대운과 세운을 원국 판단 이후에 연결하는 일.

이런 과정은 코드와 데이터 구조 쪽으로 옮겨야 했다.

프롬프트는 “월령을 확인하라”고 요청한다.

하지만 엔진은 실제 월령 값을 계산하고,
그 값을 상태로 남길 수 있어야 한다.

프롬프트는 “근거를 제시하라”고 요청한다.

하지만 엔진은 어떤 판단이 어떤 계산 재료에서 나왔는지
추적 가능한 기록으로 남겨야 한다.

이때부터 프롬프트의 역할은
모든 판단을 스스로 내리는 그릇에서,
엔진이 계산해 낸 재료를 받아
읽기 좋은 문장으로 바꾸는 쪽으로 좁혀지기 시작했다.

---

지금 돌아보면

프롬프트가 작은 프로그램처럼 커져 갔던 시기는
MRA 설계에서 중요한 과도기였다.

그 과정에서 프롬프트는
스스로 감당하기 어려운 한계선을 드러내 주었다.

프롬프트는 설계 의도를 담을 수 있다.
순서를 설명할 수 있다.
문체의 방향을 제한할 수 있다.

하지만 계산 엔진을 대신할 수는 없다.

역할, 절차, 조건, 금지 규칙이
한 프롬프트 안에 모두 엉켜 있을 때,
그것은 정교해 보였지만 안정적인 구조는 아니었다.

그 차이를 인정하고 나서야
MRA의 방향이 조금 더 선명해졌다.

계산은 코드가 해야 한다.
판단 재료는 객체와 데이터로 남아야 한다.
근거는 추적 가능한 구조로 연결되어야 한다.
그리고 AI는 그 뼈대 위에서 문장을 입히는 일을 맡아야 한다.

이 기준이 생기면서,
텍스트 입력창 안에서 모든 것을 해결하려던 시도는
조금씩 바깥으로 나올 준비를 하게 되었다.

프롬프트는 더 이상 혼자 모든 것을 책임질 수 없었다.

---

부록 A. 작은 프로그램처럼 변해 간 프롬프트

이 시기의 프롬프트에는 입력 확인, 분석 순서, 조건문, 금지 규칙, 출력 형식이 모두 들어가기 시작했다.

겉으로는 빈틈없는 명세서처럼 보였지만,
그 안에는 실제 연산을 수행할 구조가 없었다.

---

A-1. 입력 확인 규칙

입력된 명조 정보를 먼저 확인하라.
생년월일시가 부족하면 부족하다고 표시하라.
시주가 불확실하면 단일 결론으로 단정하지 말라.
경계 시각에 해당하면 후보 가능성을 열어 두라.

당시 의도

• 분석을 시작하기 전, 입력 정보의 결측이나 불확실성을 먼저 확인하고 싶었다.
• 불확실한 명조를 하나의 결론으로 밀어붙이지 않게 하려 했다.
• 분석 전에 기본 정보 검토 단계를 두고 싶었다.

남은 문제

• 데이터 검증이 실제 연산 단계로 분리되어 있지 않았다.
• AI가 부족한 정보를 문맥상 그럴듯하게 보완한 듯 말할 위험이 있었다.
• 후보 명조를 별도 데이터로 관리할 수 없었다.

다음 변화

• 입력값과 후보 상태를 별도의 구조로 남겨야 한다는 생각으로 이어졌다.

---

A-2. 조건과 예외 처리

득령, 득지, 득세가 서로 엇갈리면 단정하지 말고 후보로 남겨라.
격국 후보가 여러 개이면 우선순위를 설명하라.
용신 판단이 불확실하면 확정하지 말고 가능한 후보로 제시하라.

당시 의도

• 복잡한 사주의 판단을 단일 결론으로 줄이지 않게 하려 했다.
• 불확실성을 인지하고 분기 처리하도록 유도했다.
• 후보 판단과 확정 판단을 구분하려 했다.

남은 문제

• 무엇을 기준으로 엇갈렸다고 판단할지 기준값이 분명하지 않았다.
• 조건 분기문처럼 적어 두었지만, 실제 코드처럼 엄격하게 실행되지는 않았다.
• 후보와 확정 판단이 문장 속에서 다시 섞일 수 있었다.

다음 변화

• 확정 판단과 후보 판단을 단순 텍스트가 아니라, 내부 상태값으로 구분해야 한다는 생각으로 이어졌다.

---

A-3. 출력과 문체 지침

결과는 단계별로 작성하라.
반드시 근거를 함께 제시하라.
불확실한 부분은 후보로 표시하라.
최종 문장은 일반인이 이해할 수 있게 작성하며, 단정형보다 참고형 문장으로 마무리하라.

당시 의도

• 근거와 판단을 함께 남기려 했다.
• 명리 해석이 예언처럼 보이지 않도록 톤을 낮추려 했다.
• 답변 구조를 일정하게 만들고 싶었다.

남은 문제

• 제시된 근거가 실제 데이터 흐름에서 온 것인지, AI가 사후적으로 만든 문장인지 확인하기 어려웠다.
• 출력 구조와 판단 절차가 하나의 프롬프트 안에서 섞였다.
• 문체 지침이 판단 내용에 영향을 줄 수 있었다.

다음 변화

• 계산된 재료와 최종 문장화를 분리해야 한다는 생각으로 이어졌다.

---

노트 한 줄 요약

프롬프트는 절차를 프로그램처럼 적을 수는 있지만, 그 절차의 실행을 보장하지는 못한다.

---

다음 글

다음 글에서는 당시에는 단순한 시행착오처럼 보였던 이 프롬프트 실험들이, 나중에 MRA의 AI 호출 설계 원칙으로 어떻게 돌아왔는지를 다룹니다.

---

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