메타 프롬프팅: AI로 더 좋은 프롬프트 쓰기

메타 프롬프팅은 프롬프트에 대한 프롬프트입니다. 모델에게 작업을 시키는 대신, 그 작업을 위한 프롬프트를 쓰게 하거나, 이미 가진 프롬프트를 개선하게 하거나, 작업을 다른 모델 호출이 실행할 작은 프롬프트들로 나누게 합니다. 앞의 두 가지는 ChatGPT, Claude, Gemini에서 통하는 일상적인 요령입니다. 세 번째는 연구에서 나온 기법으로, 모델 인스턴스 하나가 다른 여러 인스턴스를 지휘합니다.

세 가지 모두 같은 사실에 기댑니다. 요즘 모델은 모델에게 지시하는 법에 관한 텍스트를 아주 많이 봤기 때문에, 프롬프트에서 무엇이 빠졌는지 잘 알아챕니다. 그리고 그 빈틈을 추측으로 채우는 데도 똑같이 능숙한데, 이것이 가장 경계해야 할 점입니다.

모델에게 프롬프트 쓰게 하기

프롬프트를 생성하는 가장 약한 방법은 "X를 위한 프롬프트를 써 줘"입니다. 모델은 여러분의 X에 대해 아무것도 모르므로, 평균적인 버전의 작업을 위한 뻔한 프롬프트를 씁니다. 해결책은 먼저 질문하게 하는 것입니다. 질문은 빠진 맥락을 드러내고, 여러분의 답이 프롬프트의 알맹이가 됩니다.

모델이 나를 인터뷰하게 하기

EditCopy

Fill in작업

이 작업에 재사용할 프롬프트가 필요해: 회의록을 팀에 보낼 짧은 요약 이메일로 바꾸기. 프롬프트를 쓰기 전에, 잘 쓰려면 알아야 할 것에 대해 최대 다섯 개까지 질문해 줘(독자, 내용, 길이, 말투, 뺄 것). 번호를 붙여 한꺼번에 물어봐. 내가 답하면, 매번 채울 부분은 [대괄호]로 남겨서 코드 블록 안에 프롬프트를 써 줘.

Try it

Example replyReplies vary between models and runs.

1. 이메일은 누가 읽나요? 회의 참석자만인가요, 아니면 관리자와 다른 팀도 읽나요?
2. 모든 요약에 꼭 들어가야 할 것은 무엇인가요? 예를 들어 결정 사항, 담당자와 마감일이 있는 할 일, 남은 질문 같은 것들이요.
3. 길이는 어느 정도가 좋고, 글머리 기호와 짧은 문단 중 무엇을 선호하나요?
4. 팀에서 이메일에 쓰는 말투는 격식체, 중립적인 말투, 편한 말투 중 어느 쪽인가요?
5. 곁가지 대화, 개인적인 발언, 기밀 수치처럼 절대 들어가면 안 되는 것이 있나요?

질문에 한 번에 답하면, 모델의 기본값이 아니라 여러분의 결정이 담긴 프롬프트를 받게 됩니다. 저장해 두세요. 자리 표시자가 있는 프롬프트는 매주 쓸 수 있는 프롬프트 템플릿입니다.

가진 프롬프트 개선하기

"이 프롬프트를 개선해 줘"는 가장 흔한 메타 프롬프트 중 하나이고, 전형적인 실패는 아래 첫 번째 탭에서 볼 수 있습니다. 모델은 세부 사항을 지어내면서 프롬프트를 더 길고 자신 있게 만듭니다. 독자, 글자 수, 행동 유도 문구 같은 것들입니다. 지어낸 것 하나하나가 그럴듯하고, 하나하나가 여러분이 내리지 않은 결정입니다. 두 번째 탭은 모델에게 다시 쓰기 규칙을 줍니다.

그냥 개선해 줘지어내지 말고 개선해 줘

EditCopy

이 프롬프트를 개선해 줘: "내 뉴스레터에 쓸 수 있게 이 기사를 요약해 줘."

Try it

Example replyReplies vary between models and runs.

개선된 버전의 프롬프트입니다.

"너는 디지털 출판 분야에서 수년간 경험을 쌓은 전문 콘텐츠 작가이자 편집자야. 기술 업계의 바쁜 직장인들이 읽는 내 뉴스레터를 위해 다음 기사를 요약해 줘. 친근하면서도 전문적인 말투로 400~500자 분량의 흥미로운 요약을 써 줘. 관심을 끄는 첫 문장으로 시작하고, 가장 중요한 인사이트 세 가지를 강조하고, 독자가 전체 기사를 읽도록 권하는 행동 유도 문구로 마무리해 줘."

이 버전은 역할, 독자, 길이, 말투, 명확한 구조를 더해서 더 집중되고 쓸모 있는 요약을 얻게 해 줍니다.

첫 번째 답이 틀린 것은 아닙니다. 주제넘을 뿐입니다. 여러분의 뉴스레터가 취미 원예가를 위한 것이라면, "기술 업계의 바쁜 직장인"이 모든 요약을 조용히 엉뚱한 쪽으로 이끌 것입니다. 두 번째 답은 덜 하고, 중요한 결정을 여러분에게 맡깁니다. 자리 표시자는 원래 프롬프트에 어떤 맥락이 빠져 있었는지도 보여 주므로, 다시 쓴 프롬프트를 버리더라도 쓸모가 있습니다.

생성된 프롬프트를 믿기 전에 확인하기

모델이 쓴 프롬프트는 잘 읽히고, 그래서 문제를 놓치기 쉽습니다. 쓰기 전에 다음을 확인하세요.

• 지어낸 요구 사항. 요청하지 않은 길이, 독자, 말투, 규칙이 있다면 지우거나 여러분의 실제 답으로 바꾸세요.
• 일반적인 역할. "너는 세계 최고의 전문가야"는 길이만 늘리고 별로 더해 주는 것이 없습니다. 역할은 독자와 기준을 밝힐 때 도움이 됩니다. 역할 프롬프팅을 참고하세요.
• 반복. 생성된 프롬프트는 같은 지시를 세 가지 방식으로 말하는 경우가 많습니다. 명확한 한 문장이면 똑같이 통하고, 모순이 생길 여지도 줄어듭니다.
• 테스트 없음. 프롬프트를 읽는 것만으로는 결과에 대해 알 수 있는 것이 적습니다. 까다로운 것 하나를 포함해 실제 입력 서너 개로 실행하고, 이전 프롬프트의 결과와 비교하세요. 스스로를 속이지 않고 이렇게 하는 방법은 프롬프트 반복 개선에서 설명합니다.

모델은 실패한 프롬프트를 진단하는 데도 도움이 됩니다. 프롬프트가 나쁜 결과를 내면 프롬프트, 입력, 나쁜 출력을 붙여 넣고 물어보세요. "이 프롬프트의 어느 부분이 이 출력의 원인일 가능성이 가장 높아? 이를 고칠 가장 작은 변경을 제안해 줘." 전체를 다시 쓰는 것보다 목표를 좁힌 진단이 더 쓸모 있습니다. 어떤 지시가 문제였는지 배울 수 있기 때문입니다.

지휘자 방식 (Suzgun과 Kalai, 2024)

연구에서 "메타 프롬프팅"은 Suzgun과 Kalai의 2024년 논문 "Meta-Prompting: Enhancing Language Models with Task-Agnostic Scaffolding"의 특정 방법을 가리키기도 합니다. 지휘자(conductor)라는 모델 인스턴스 하나가, 모든 작업에 똑같이 쓰이는 고정된 상위 지시와 함께 작업을 받습니다. 지휘자는 작업을 조각으로 나누고, 조각마다 "전문가"를 위한 프롬프트를 씁니다. 전문가는 지휘자가 그 조각을 위해 쓴 지시를 받은, 같은 모델에 대한 새로운 호출입니다. 전문가는 전체 기록이 아니라 지휘자가 보낸 것만 보므로, 새로운 눈으로 작업을 확인합니다. 지휘자는 전문가의 답을 읽고, 의심스러우면 검증을 요청하고, 최종 답을 조립합니다. 일부 실험에서는 전문가 중 하나가 Python 코드를 실행할 수 있었습니다.

저자들은 GPT-4로 여러 작업을 섞어 테스트했습니다. 24 게임 퍼즐, 체스에서 한 수 만에 체크메이트 찾기, Python 프로그래밍 퍼즐, 소네트 쓰기 등입니다. 작업 전체를 평균하면, Python 인터프리터를 붙인 지휘자 구성이 일반 프롬프팅과 비교 대상이었던 다른 프롬프팅 구조들을 앞섰습니다.

이것은 채팅 메시지 하나가 아니라 프로그램입니다. 프롬프트 체이닝이 단계 사이에 출력을 넘기는 것과 같은 방식으로, 전문가 호출 하나하나가 코드가 보내는 별도의 요청입니다. 차이는 체인에서는 단계를 미리 설계하지만, 지휘자는 실행 중에 단계를 정한다는 것입니다. 이 유연성은 호출이 더 많이 들고 디버깅하기 더 어려우므로, 단계를 이미 아는 작업이라면 보통 고정된 체인이 더 나은 선택입니다.