우리 대부분은 프롬프트 엔지니어링을 우리가 하는 일로 여깁니다. 나쁜 결과물을 훑어보고, 몇 단어를 수정하고, 다시 실행하는 식입니다. 메타 프롬프팅(Meta-prompting)은 이 방식을 뒤집습니다. 모델에게 그 작업을 맡기는 것입니다. 즉, 대략적이고 형태가 갖춰지지 않은 요청을 날카롭고 잘 구조화된 것으로 바꾸는 전체 목적을 가진 재사용 가능한 하나의 프롬프트를 작성하는 것입니다. 이렇게 하는 프롬프트가 바로 _메타 프롬프트(meta-prompt)_이며, 이것이 생성하는 것이 실제로 실행하는 _태스크 프롬프트(task prompt)_입니다.

이 아이디어는 간단한 관찰에 기반합니다. 모호한 의도를 정확한 지침으로 바꾸는 것 자체가 언어 작업이기 때문입니다. 이는 LLM(대규모 언어 모델)이 잘하는 바로 그 종류의 일입니다. 따라서 완벽한 프롬프트를 직접 만드는 대신, 모델에게 당신의 초안을 비평하고 다시 작성하도록 맡기는 것입니다.

약한 프롬프트가 실패하는 이유

진단(diagnosis)과 생성(generation)을 분리하는 것이 중요합니다. 비평(critique)을 먼저 요청하면 모델이 특정 결함에 대해 추론하게 되므로, 다시 작성할 때 단순히 "더 좋게 만들어라"라는 막연한 욕구 대신 명시된 격차(gaps)에 기반하여 작성할 수 있습니다. 이는 self-refine과 동일한 '비평 후 수정(critique-then-revise)' 패턴이며, 단지 답변 대신 프롬프트에 적용했을 뿐입니다.

"강아지에 대해 써줘"라는 문구로 실행하면 다음과 같은 결과가 나옵니다:

역할(ROLE): 당신은 수의학 작가입니다.
대상(AUDIENCE): 사전 지식이 없는 초보 반려견 주인.
맥락(CONTEXT): 책임감 있는 반려동물 양육에 관한 블로그 시리즈.
...

동일한 모델, 동일한 주제임에도 불구하고, 모호한 요청은 형태 없는 덩어리를 만들어내지만, 다시 작성된 프롬프트는 표와 5가지 특정 품종이 포함된 구조화된 가이드를 만들어냅니다. 변한 것은 오직 명세(specification)의 품질뿐이며, 이것이 바로 메타 프롬프트(meta-prompt)가 자동화한 핵심입니다.

두 가지 방식

제가 설명한 것은 템플릿(template) 방식입니다. 이는 사람이 작성한 고정된 메타 프롬프트를 사용하여, 추가적인 호출(call) 한 번의 비용으로 단 한 번 다시 작성하는 방식이며 별도의 학습 데이터가 필요하지 않습니다. 이는 가장 저렴하고 이식성이 높은 형태입니다. 팀들은 린터(linter)가 코드 스타일을 강제하는 것처럼, 모든 프롬프트가 동일한 기준을 충족하도록 내부용 메타 프롬프트를 유지합니다.

다른 방식은 **LLM-as-optimizer(최적화 도구로서의 LLM)**입니다. 여기서는 모델이 여러 개의 후보 프롬프트를 제안하면, 사용자가 레이블이 지정된 평가 세트(eval set)를 통해 각 프롬프트의 점수를 매기고, 그 점수를 다시 모델에 입력하여 최적의 성능을 내는 방향으로 반복(iterate)하게 합니다. 즉, 자동화된 프롬프트 탐색(automated prompt search)입니다. APE (Automatic Prompt Engineer, 2022)는 지시어 후보를 생성하고 순위를 매기며, OPRO (2023)는 모델을 과거의 프롬프트-점수 쌍을 읽는 최적화 도구로 취급합니다. OPRO는 "심호흡을 하고 단계별로 생각하세요"라는 지시어를 찾아낸 것으로 유명합니다. 강력하지만, 데이터와 많은 호출이 필요합니다.

지휘자 변형 (The conductor variant)

Meta-prompting은 두 번째 방향으로도 확장됩니다. 지휘자 (conductor) 프롬프트는 하나의 프롬프트를 다시 쓰는 것이 아닙니다. 대신 큰 목표("내 제품 출시하기")를 설정하면, 이를 전문화된 하위 프롬프트들(시장 분석가 프롬프트, 카피라이터 프롬프트, 체크리스트 생성 프롬프트 등)로 분해하고, 각각을 새로운 모델 인스턴스에 할당한 뒤 그 결과들을 병합합니다. 지휘자는 객체 수준 (object-level)의 작업을 직접 수행하지 않습니다. 대신 그 작업을 수행할 프롬프트들을 작성하고 조정합니다. 이는 멀티스텝 에이전트 파이프라인 (multi-step agent pipelines)의 오케스트레이션 (orchestration) 개념을 한 단계 더 높인 것과 같습니다.

언제 사용해야 하는가, 그리고 주의할 점

프롬프트가 자주 재사용될 때, 작업이 매우 까다로워 명세 (specification)가 품질을 결정할 때, 또는 비전문가가 프롬프트를 작성하여 안전장치가 필요할 때 사용하십시오. 손으로 직접 신중하게 작성할 수 있는 일회성 작업이라면 이 방식을 건너뛰십시오.

주의할 점: 이것은 여전히 일반적인 LLM 호출입니다. 재작성 과정에서 원치 않는 제약 조건이 만들어지거나, 품질은 나아지지 않으면서 길어지기만 할 수도 있습니다. 또한 메타 프롬프트 (meta-prompt)의 성능은 그 체크리스트의 품질에 달려 있습니다. 잘못된 기준이 설정되면 모든 곳에 잘못된 기준이 적용됩니다. 재작성된 결과물을 신탁 (oracle)이 아닌, 검토가 필요한 강력한 초안으로 취급하십시오.

저는 인터랙티브 워크스루 (interactive walkthrough)를 제작했습니다. 메타 프롬프트가 취약한 프롬프트를 비판하고, 차원별로 재작성한 뒤, 두 프롬프트를 나란히 실행하는 과정을 확인해 보세요:

https://dev48v.infy.uk/prompt/day26-meta-prompting.html