프롬프트 리뷰 EP01: “이 분야의 모든 전문가가 공유하는 다섯 가지 핵심 멘탈 모델”라는 프롬프트를 효과적으로 개선하자.

haegyung.com 의 모든 글은, LLM 과 협력적 글쓰기를 통하여 작성된 글이며,
근거 기반 프롬프트 리뷰 는 한국어 버전은 이곳에, 영문버전은 Augmentedtechnology SUBSTACK 에 발행됩니다.

Thank you for reading this post, don't forget to subscribe!

오늘은 근거 기반으로 “모든 전문가가 공유하는 핵심 멘탈 모델” 이라는 프롬프트를 리뷰해보려고 합니다.

바로 답부터 말하면

이 질문은 똑똑해 보이지만, 실제로는 범위 정의, 전문가 정의, 합의 판단, 핵심 기준 설정, 개수 제한을 한 문장에 겹쳐 넣은 프롬프트입니다. 그래서 AI가 근거를 따라 답하기보다, 비어 있는 전제를 스스로 채워 넣으며 그럴듯한 답을 만들 가능성이 커집니다. 프롬프트 설계 가이드는 이런 경우 명확한 지시, 맥락 제공, 구조화, 복잡한 작업의 분해를 권합니다. (Google Cloud Documentation)

왜 이 질문이 자꾸 그럴듯한 오답을 부르는가

“이 분야의 모든 전문가가 공유하는 핵심 멘탈 모델 다섯 가지 멘탈모델”

문제는 질문의 방향이 틀려서가 아닙니다.
오히려 문제의식은 좋습니다. 누구나 한 번쯤 “전문가들은 이 문제를 어떤 사고 틀로 바라보지?”를 알고 싶어 하기 때문입니다.

하지만 좋은 문제의식과 좋은 프롬프트는 다릅니다. 프롬프트는 모델이 어떤 근거 위에서, 어떤 순서로, 어떤 형식으로 답해야 하는지를 알려줘야 합니다. 그런데 “이 분야의 모든 전문가가 공유하는 핵심 멘탈 모델 다섯 가지”라는 문장은 그 과정을 통째로 생략한 채 결론만 바로 요구합니다. 그래서 답이 빠르게 나오더라도, 그 안에 어떤 전제가 깔려 있는지 확인하기 어려워집니다. 프롬프트 가이드가 작업을 나누고 맥락을 먼저 주라고 권하는 이유가 여기에 있습니다. (Google Cloud Documentation)

펼쳐보기 1: “이 분야”는 생각보다 큰 빈칸이다

가장 먼저 걸리는 표현은 “이 분야”입니다.

도대체 어느 분야를 말하는 걸까요.
하나의 분야인가요, 아니면 여러 하위 분야가 섞여 있나요.
같은 단어를 쓰지만 서로 다른 문제를 말하고 있는 건 아니까요.

범위가 먼저 정해지지 않으면, 이후 분석 전체가 흔들립니다. 모델은 빈칸을 그냥 두지 못하기 때문에, 결국 자기 나름의 추정으로 범위를 채워 넣게 됩니다. 그래서 더 안전한 프롬프트는 보통 “아래 자료가 하나의 분야로 묶이는지 먼저 판단하라” 같은 문장으로 시작합니다. 필요한 정보를 모델이 알아서 보충하길 기대하기보다, 맥락과 제약을 직접 적는 편이 더 안정적입니다. (Google Cloud Documentation)

펼쳐보기 2: “모든 전문가”는 멋있지만 너무 강한 표현이다

다음으로 위험한 표현은 “모든 전문가”입니다.

현실의 연구 방법론은 이렇게 단순하지 않습니다. Delphi 관련 검토 문헌을 보면, 누가 전문가인지에 대한 표준 기준은 없고, 전문가 선정과 합의 기준은 연구마다 다르게 설정됩니다. 최근 검토에서도 Delphi 연구는 전문가 정의와 합의 방식이 이질적이며, 합의 임계값 역시 넓게 분포한다고 설명합니다. 한 개요 논문은 Delphi 연구의 합의 기준 중앙값을 75%, 범위를 50%~97%로 요약합니다. (PMC)

즉 현실에서는 “모든 전문가가 동의하는가”를 묻기보다, 누가 전문가인지, 어떤 기준으로 선정했는지, 어느 수준을 합의라고 볼 것인지를 먼저 정합니다. 그런데 원문 프롬프트는 이 과정을 모두 건너뛰고, 처음부터 전체 전문가 집단의 완전 합의를 전제합니다. 이건 강한 질문이라기보다 강한 가정에 가깝습니다. (PMC)

펼처보기 3: “공유하는”은 “완전히 같다”는 뜻이 아니다

여기서 더 섬세하게 봐야 할 표현이 “공유하는”입니다.

shared mental model이라는 개념은 실제 연구에 존재합니다. 하지만 여기서의 shared는 보통 완전히 동일함을 뜻하지 않습니다. 관련 논문은 shared mental models를 “identical”이 아니라 similar and overlapping, 즉 비슷하고 겹치는 상태로 설명합니다. 다시 말해, 전문가들이 같은 큰 틀을 공유할 수는 있어도 세부 해석과 강조점까지 모두 같을 필요는 없습니다. (PMC)

그래서 “모든 전문가가 공유하는”보다 더 현실적인 표현은 “반복적으로 나타나는”, “공통적으로 관찰되는”, “합의 수준이 높은”에 가깝습니다. 질문의 톤은 조금 덜 강해 보일 수 있지만, 실제 분석 가능성은 오히려 높아집니다. (PMC)

펼쳐보기 4: “핵심 멘탈 모델”이라는 표현 자체가 틀린 것은 아니다

이 부분은 무조건 잘못이라고 말하면 오히려 부정확합니다.

mental model 연구는 멘탈 모델을 서로 연결된 신념의 집합으로 설명합니다. 그리고 그 안에는 더 중심적인 믿음과 더 주변적인 믿음이 있을 수 있다고 봅니다. 실제로 관련 문헌은 mental model이 core beliefs와 peripheral beliefs를 포함할 수 있다고 설명합니다. 즉 “핵심”이라는 단어 자체는 사용할 수 있습니다. (PMC)

진짜 문제는 다른 데 있습니다.
무엇을 기준으로 핵심이라고 부를지 적혀 있지 않다는 점입니다.

반복 빈도인지, 설명력인지, 의사결정 영향도인지, 합의율인지가 빠져 있으면 모델은 자기 방식으로 중요도를 정하게 됩니다. 그래서 이 질문에 대한 더 정확한 비판은 “핵심이라는 단어가 틀렸다”가 아니라, 핵심의 판정 기준이 비어 있다입니다. 멘탈 모델은 경험과 지식에 따라 다르게 형성되고, 널리 공유된 모델도 정확하다고 자동 보장되지는 않기 때문에, 기준을 분명히 적어주는 것이 중요합니다. (PMC)

펼쳐보기 5: “다섯 가지”는 분석 결과보다 출력 형식에 가깝다

마지막 문제는 숫자입니다.

왜 하필 다섯 가지일까요.
실무에서는 3개, 5개, 7개처럼 요약 개수를 정할 일이 많습니다. 그 자체가 문제는 아닙니다. 문제는 그 숫자를 분석의 결과가 아니라 분석의 전제로 놓을 때 생깁니다.

앞서 본 것처럼, 전문가 합의 연구는 패널 구성과 합의 기준에 따라 결과가 달라질 수 있습니다. 그렇다면 처음부터 “핵심 멘탈 모델은 다섯 가지다”라고 못 박는 것은 다소 무리입니다. 실제 자료가 3개나 6개를 더 잘 지지해도, 모델은 형식에 맞추기 위해 억지로 채우거나 줄일 수 있기 때문입니다. 그러니 “다섯 가지”는 진실의 개수라기보다 최종 요약의 상한으로 두는 편이 더 타당합니다. (PMC)

결국 이 프롬프트의 핵심 문제는 무엇인가

정리하면 이렇습니다.

이 프롬프트의 문제는 질문이 지적으로 보이지 않아서가 아닙니다.
오히려 너무 많은 판단을 한 문장에 압축해 넣어서, 모델이 근거보다 추정으로 답하게 만들 수 있다는 데 있습니다.

좋은 프롬프트는 어려운 단어를 많이 넣는 문장이 아닙니다. 좋은 프롬프트는 빠진 전제를 줄이고, 판단 기준을 드러내고, 모델이 추정이 아니라 근거를 따라가게 만드는 문장입니다. 그래서 원문은 방향은 좋지만, 구조는 다시 짜는 편이 낫습니다. (Google Cloud Documentation)

더 나은 프롬프트는 이렇게 바뀐다

실제로는 아래처럼 바꾸는 편이 훨씬 안정적입니다.

나는 지금 [상황]에서 [대상]에게 [목적]을 위해 [산출물]을 만들고 있다.
아래 자료만 근거로 답하라.

1. 먼저 이 자료가 하나의 분야로 묶이는지 판단하라.
2. 묶인다면 그 안에서 반복적으로 나타나는 멘탈 모델을 추출하라.
3. “모든 전문가가 공유한다”라고 단정하지 말고, 각 항목의 합의 수준을 높음·중간·낮음으로 제시하라.
4. “핵심”은 반복 빈도, 설명력, 의사결정 영향도를 기준으로 판정하라.
5. 개수는 고정하지 말고, 필요하면 마지막에 상위 5개까지만 요약하라.
6. 상충되는 관점과 불확실성도 함께 적어라.

이렇게 바꾸면 모델은 “멋진 말”을 채우는 대신, 정해진 기준과 순서를 따라가며 답을 만들게 됩니다. 프롬프트 가이드가 권하는 방식도 바로 이 방향입니다. (Google Cloud Documentation)

마무리

“이 분야의 모든 전문가가 공유하는 핵심 멘탈 모델 다섯 가지”라는 질문은 얼핏 날카로워 보입니다.
하지만 질문을 조금만 펼쳐 보면, 그 안에는 너무 많은 숨은 전제가 들어 있습니다.

그래서 더 좋은 방법은 질문을 더 어렵게 만드는 것이 아니라, 더 분명하게 만드는 것입니다.
범위를 먼저 정하고, 전문가를 정의하고, 합의 수준을 나누고, 핵심의 기준을 적고, 숫자는 마지막 요약 형식으로 돌려놓는 것. 그 순간 이 질문은 훨씬 더 믿을 만하고, 더 실무적이고, 실제로 신뢰 가능한 작업 과정으로 바뀝니다. (Google Cloud Documentation)