첫 턴에 고해상도 응답을 만들어내는 (가능성이 있는) 프롬프트 템플릿

LLM과 대화할 때 항상 느끼는 문제는 '고해상도 도메인 토큰'을 쥐어주지 않으면 피상적인 응답만 한다는 것입니다. 최승준님과의 ChatGPT 그룹 챗에서도 마찬가지였죠. 시모어 페퍼트를 비롯한 도메인 지식이 풍부한 승준님이 적절한 토큰을 입력했기 때문에 이후 더 유의미한 응답이 나오기 시작했습니다.

그래서 어떻게 하면 내가 이런 고품질 토큰을 직접적으로 주지 않고도 좋은 응답을 하게 할까? 를 화두로 몇 턴의 대화를 나눠봤습니다.

결과적으로, 상당히 괜찮은 느낌의 메타프롬프트가 나왔네요. 아직 충분한 검증은 거치지 못했는데 잘 될 거라는 '감'은 있습니다. 차차 써보고 또 업데이트 해보겠습니다.

제 입력들도 아래 공유합니다. 참고로 첫 입력은 승준님이 모델의 응답을 셀프 비판시킨 것에서 이어진 것입니다.

이야, 예전부터 느꼈지만 너 누가 잘 시키면 셀프 비판을 정말 잘 하는구나. 나는 네가 처음부터 (워밍업 용도의 프롬프트, 도메인-특화 high-entropy token 등 없이도, 필요하다면 알아서 일어나는 한 번의 프롬프트 증강을 통해) 더 잘 하게 할 수 있는 방법이 요즘 주요 화두 중 하나야.

"첫 턴만으로 고해상도 reasoning을 끌어내는 프롬프트 템플릿" 3종 정도 제안해봐.

그리고 각 템플릿이 실제로는 의도된 효과를 발휘하지 않았다면 무엇 때문일지 pre-mortem을 같이 해봐. 실제로 어떻게 evaluation해야 하는지도 함께.

너는 '거의 모든 도메인에서' 먹힐 거라고 했는데, 내 생각에는 네가 이미 이 방의 컨텍스트에 과하게 경도되어 있어서 '인식론', '형태학' 같은 단어가 나온 것 같아. 그래서 나는 '모든 도메인에서 먹히는 프롬프트'는 과도한 이상 이라고 봐. 하지만 내 생각이 틀렸을 수 있으니 정신 똑바로 차리고 응답해.

내 코멘트.

1. 나는 '리즈닝 모드'를 선택하게 하는 게 핵심인지는 잘 모르겠다. 그래서 3번은 별로 마음에 안 든다. 이게 왜 중요하지?

2. 제안한 프롬프트 모두 공통적으로 '애초에 주어진 스펙이 너무 모호함'에서 실패하기 쉽다. 내가 개인적으로 쓰는 방법은 첫턴에 다음 두 가지를 추가하는 것이다. 불확실한 부분을 셀프 비판하게 하고, '되묻기'를 통해 정보를 보충하게 한다.
- 응답의 하단에는 "불확실성 지도"를 추가해줘. 이 지도에는 네가 가장 덜 자신있는 부분, 지나치게 단순화했을 수 있는 부분, 그리고 어떤 질문이나 추가 정보가 네 의견을 바꿀 수 있을지를 포함해줘.
- 이 응답을 더 유용하게 만드는 데 있어서 아직 정보가 불충분한 부분이 있다면 응답 전에 내게 질문해줘. 예를 들어 나의 Jobs to be done이 무엇인가? 라거나.

1에 응답하고, 2에 대한 네 생각을 들려주고, 내 의도를 해석해서 새로 프롬프트를 제안하라.

억지로 쪼개진 느낌이다. 네 말대로 하나의 unified meta-template으로 만들어봐. 프리모르템과 eval 방법은 당연히 포함.

GPT 응답 (일부)

아래는 네가 그냥 복붙해서 첫 턴에 쏠 수 있는 형태로 썼다. [...] 안은 네가 채워 넣는 슬롯.

[역할/도메인 요약 한 줄: 예) “너는 B2B SaaS 스타트업의 제품/엔지니어링 전략을 함께 설계하는 보조 두뇌다.”]

이번 대화의 목적은 다음과 같다:
- 목표: [내가 지금 진짜로 이루고 싶은 것 / Jobs to Be Done]
- 맥락: [지금까지 상황이나 제약을 한두 문장으로 요약]
- 산출물: [원하는 출력 형태: 예) 설계안, 코드, 실험 플랜, 글 뼈대 등]

### 너의 작업 프로세스

이번 턴에서 너는 아래 순서를 **가능한 한 그대로** 따라줘:

1. **내 의도 재구성 & JTBD 명시**
   - 내가 쓴 내용을 바탕으로,  
     “이 사람이 진짜로 하려는 일(Jobs to be done)은 ○○다”를
     네 언어로 2~3문장으로 정리해줘.
   - 불명확하다면, 무엇이 모호한지 “가설 2~3개”로 적어줘.

2. **핵심 전제 & 정보 부족 지점 정리**
   - 지금 네가 답을 만들기 위해 암묵적으로 두게 될 **핵심 전제**를 3~7개 bullet로 적어줘.
   - 특히:
     - 어디가 가장 정보가 부족한지
     - 어떤 추가 정보가 있으면 전략/답이 크게 달라질지
     를 “질문 형태”로 3~5개 써줘.

3. **Clarifying 질문 (있으면)**  
   - 위에서 정리한 질문 중,  
     “지금 여기서 꼭 물어봐야 하는 것”만 골라 **최대 3개까지** 나에게 물어봐.
   - 정말 꼭 필요하지 않다면, 이 단계는 건너뛰고 4번으로 가도 된다.
   - (질문을 할지 말지는 네가 스스로 판단해.)

4. **계획(Plan) 스케치**
   - 이번 턴에서 할 일을 3~6단계로 나누어 bullet plan으로 먼저 보여줘.
   - 가능하면:
     - (a) 지금 바로 할 수 있는 것
     - (b) 후속 턴에 나와 함께 해야 할 것
     을 구분해서 적어줘.

5. **본 답변 / 설계 / 제안**
   - 위 계획에 따라 실제 답을 작성해줘.
   - 너무 추상적으로만 말하지 말고,
     내가 바로 실행하거나 편집할 수 있을 정도로 구체성을 유지해줘.

6. **불확실성 지도 (Uncertainty Map)**
   - 이번 답변에서 네가 **가장 자신 없는 부분**을 3~5개 정도 꼽고,
     각 항목마다:
       - 왜 불확실한지
       - 어떤 추가 정보/실험/데이터가 있으면 확신도가 올라갈지
     를 한두 문장씩 적어줘.

7. **프리모르템 (Premortem)**
   - “이 답변/전략을 그대로 실행했는데, 6개월 뒤 완전히 실패했다고 가정”하고,
     그 이유를 3~7개 bullet로 적어줘.
   - 각 실패 요인마다:
     - 그 징후/조기 경고 신호는 무엇인지
     - 지금 당장 설계 단계에서 줄이거나 예방하기 위해
       네가 답변을 어떻게 바꾸거나 보완해야 할지
     를 적어줘.
   - 필요하다면, 위까지 작성한 본문을 이 프리모르템 인사이트를 반영해 **간단히 리팩토링**해도 좋다
     (어디를 어떻게 바꿨는지도 한 줄로 메모).

8. **Evaluation 제안 (내가 어떻게 검증하면 좋을지)**
   - “이 답변이 좋은지/나쁜지”를 내가 스스로 평가할 수 있도록,
     아래 항목을 제안해줘:
       - (a) 단기 체크리스트: 오늘/이번 주 안에 내가 바로 점검할 수 있는 것들
       - (b) 정량 지표: 이 전략/설계가 잘 작동하는지 수치로 볼 수 있는 지표 예시
       - (c) 작은 실험: 큰 리소스 쓰지 않고도 검증할 수 있는 ‘작은 실험’ 1~3개
   - 가능하다면, “다음 프롬프트에서 내가 너에게 던지면 좋은 질문”도 2~4개 추천해줘.

3. 왜 이게 “하나로” 통합된 메타‑템플릿인지

이 템플릿은 사실 세 가지 층을 한 번에 잡으려는 거야:

1. 메타 인식 / JTBD 정렬
   → 1, 2, 3번 단계 (의도 재구성 / 전제 / 되묻기)
   → “내가 진짜 뭘 하려는지 + 뭐가 비어있는지”부터 맞추기.
2. 실행 구조화
   → 4, 5번 단계 (plan → answer)
   → 과한 방법론 말고, “작업 분해 → 실행”만 강제.
3. 품질·리스크 레이어
   → 6, 7, 8번 단계 (불확실성 지도 / 프리모르템 / eval 제안)
   → 답 하나로 끝내지 않고, “이게 왜 틀릴 수 있는지 + 어떻게 검증할지”를 내장.

그래서 이건 “전략용 템플릿 / 연구용 템플릿 / 글쓰기 템플릿”으로 갈라지는 게 아니라, “모든 진지한 작업은 결국 이런 레이어를 공유한다”라는 가정 위의 하나의 메타‑폼이라고 보면 돼.

4. 이 메타‑템플릿 자체에 대한 Pre‑mortem

이제 네가 요구한 대로, 이 템플릿이 망할 수 있는 이유를 먼저 까보면:

1. 과도한 구조/길이 → 모델이 중간에 무시하거나 요약해버릴 위험
   • 특히 짧은 답/속도를 선호하는 세팅에선,
     6~8단계를 대충 한두 줄로 때우거나 생략할 가능성이 크다.
   • 완전 초보 유저에겐 “너무 복잡해 보인다”가 될 수 있음.
2. 도메인 특수성이 필요한 부분이 빈칸으로 남음
   • 예: 하드코어 수학/공학 문제에서 정량적 eval은 엄밀해야 하는데,
     이 템플릿은 “평범한 실험/지표 예시”를 제안하는 수준에 머물 수 있다.
   • 그 결과 “형식상 그럴듯하지만 본질을 찌르지 못하는 eval”이 나올 수 있음.
3. Clarifying 질문 단계가 실제로는 잘 안 쓰일 수 있음
   • 많은 유저는 “질문하지 말고 그냥 답해”를 기대하거나,
     질문을 받는 순간 귀찮아서 흐름이 끊길 수 있다.
   • 모델도 정책/세팅에 따라 질문을 최소화하려는 경향이 있어서,
     2번 단계에서 모호하다고 써 놓고도 3번에서 질문은 안 할 수 있음.
4. 불확실성 지도/프리모르템이 ‘양심 고백’이 아니라 수사로 흐를 위험
   • 진짜 리스크보다는 “있어 보이는 것” 위주로 적을 수 있다.
   • 특히 논쟁적 이슈/정치/윤리 영역에선 안전장치 문장이 반복될 수 있고,
     그게 “생각”이라기보단 policy paraphrase로 가득 찰 수도 있음.
5. 유저/모델 둘 다에게 인지적 부하
   • 유저는 이 템플릿을 계속 쓰기 귀찮아질 수 있고
   • 모델은 매번 8스텝 구조를 지키려다, 실제 내용의 sharpness가 떨어질 수 있다.

요약하면: 좋은 구조지만, “과한 형식화 + 모호한 도메인” 때문에 흐릿해질 위험이 크다.

5. 이 템플릿을 실제로 Evaluation하는 방법

“그럴듯하다” 말고, 진짜로 쓸모 있는지 확인하려면 대충 이런 식으로 실험해볼 수 있어:

(1) A/B 비교 실험

• A 조건: 그냥 평소처럼 질문 던짐
• B 조건: 이번 unified meta‑template 사용

여러 도메인에서 같은 사람(너 혹은 팀원)이 써 보면서:

• 주관 평가:
  • “결론의 날카로움”
  • “처음 턴 이후 수정·되물음 횟수”
  • “새 인사이트를 준 정도 (0~5점)”
• 정량적 지표:
  • 같은 작업을 끝내는 데 걸린 턴 수
  • 실제 실행/코드/문서로 이어진 비율

을 간단한 표로 기록해서 비교.

(2) “Blind review” 방식

• 같은 문제에 대해:
  • 템플릿 없이 나온 답
  • 템플릿으로 나온 답
    을 이름 가리고 섞은 뒤,
• 제3자가:
  • 더 설득력 있는 쪽
  • 리스크 인식이 더 잘 드러난 쪽을 고르게 한다.

(3) Failure-focused eval

일부러 어려운/애매한 과제만 모아서:

• 논쟁적 주제, 애매한 시장 전략, 정보가 부족한 상황 등에 대해 템플릿을 쓰게 하고
• 나중에 “정말로 발생한 결과/피드백”과 비교해서:
  • 프리모르템에서 지적한 리스크 중 실제로 맞은 게 있는지
  • 불확실성 지도에서 “자신 없다고 했던 부분”이 실제로 문제였는지를 체크.

6. 네 의도에 대한 내 해석

“모든 도메인에서 먹히는 프롬프트는 과도한 이상이다.”

이 말에 상당 부분 동의해.
그래서 여기서 “도메인 무관”으로 노린 건 내용이 아니라 메타 레이어야.

• JTBD 재구성
• 전제/모호성 드러내기
• 계획–실행–리스크–검증이라는 다층 구조

이 네 가지는 “인식론/형태학” 같은 단어 없이도
대부분의 진지한 작업에서 공통으로 쓸 수 있다는 쪽에 베팅한 셈이고,

도메인 스페셜한 건
→ 너 or 팀이 “eval 예시, 실험 형태”를 쌓아 나가면서 채울 영역이라고 보는 게 맞는 것 같아.