# 메타 프롬프팅

> 프롬프트를 잘 쓰지 말고 재료를 다 넘긴 뒤 AI가 깎게 하라는 방법. 3단계 어디에도 결과를 재는 자리가 없습니다.

- 수치: 3단계 · 검증 0
- 사람이 보는 화면: https://aitryed.com/ko/teardowns/harness/meta-prompting/
- 반대 언어: https://aitryed.com/en/teardowns/harness/meta-prompting/index.md
- 출처(원본 영상): https://www.youtube.com/watch?v=J3BbFNYHvZM
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

**「AI에게 시킬 말을 잘 쓰려고 애쓰지 말고, 재료를 다 던져 준 다음 AI가 깎게 하라」는 방법입니다. 방법 자체는 맞습니다. 그런데 세 단계 어디에도 «잘 만들어졌는지 재는 자리»가 없습니다.**

> **[도판]** 절차는 셋인데 게이트는 0이다. 이 그림에서 제일 중요한 건 상자가 아니라 상자 사이에 없는 것이다.
>
> 세 단계 파이프라인. 컨텍스트를 정제하지 않고 전부 던지고, AI가 되묻게 만들어 실행 환경에 맞춰 깎고, 사람이 도메인 지식으로 손본 뒤 새 창에 붙인다. 어느 단계에도 결과를 재는 자리가 없다.

## 이 방법이 뭔가요

AI에게 일을 시킬 때 보통 이렇게 씁니다.

> **「X를 만들어 줘.」**

이 방법은 이렇게 씁니다.

> **「X를 만들 건데, 그걸 시킬 좋은 «지시문»을 네가 먼저 만들어 줘.」**

즉 **AI에게 시킬 말 자체를 AI에게 만들게** 합니다.

## 제일 좋았던 설명 — 「크게 펼친 뒤 깎아라」

핵심 발상은 이겁니다. 처음부터 딱 맞게 쓰려 하지 말고, **일단 크게 다 펼친 다음 깎아내라.**

이게 왜 나은지 비유가 좋았습니다.

> **길게 못 쓰는 건 초보다. 진짜 어려운 건 많이 쓴 글에서 핵심만 남기고 줄이는 것이다.**

그리고 근거를 이렇게 답니다 — **고등학교는 「최소 몇 자 이상」을 정하고, 대학은 「최대 몇 자 이내」를 정합니다.** 어느 쪽이 더 어려운지가 그 차이에 있습니다.

실제로도 그렇습니다. 처음부터 4,000자에 맞춰 쓰면 **떠오르지 않은 것은 영원히 안 들어갑니다.** 크게 펼친 뒤 깎으면 **같은 4,000자 안에 훨씬 많은 디테일이 살아남습니다.**

## 그런데 세 단계 어디에도 「재는 자리」가 없습니다

여기가 이 편의 본론입니다.

깎을 때 기준이 하나 있습니다 — **「이건 안 적어도 AI가 알아서 판단할 수 있나?」** 그렇다면 뺍니다.

기준 자체는 명료합니다. **문제는 뺀 뒤에 확인을 안 한다는 것**입니다.

| 상황 | 알 수 있나 |
|---|---|
| 뺐는데 결과가 좋았음 | **뺄 만해서 좋았나, 운이 좋았나 — 구분 불가** |
| 확인하려면 | **뺀 것과 안 뺀 것을 각각 돌려 비교**해야 함 |
| 영상에 그 비교가 | **없음** |

그래서 이 방법은 **「해 보니 좋더라」에서 멈춰 있습니다.** 나쁜 방법이라는 뜻이 아니라, **좋다는 증거가 아직 없다**는 뜻입니다.

이게 도판에서 제일 중요한 부분입니다 — **상자가 셋인데, 상자 «사이»에 아무것도 없습니다.**

## 제 것과 대 봤더니 — 앞의 둘은 이미 코드로 갖고 있었습니다

제 작업 파이프라인이 실제로 그렇게 돕니다. 기획서 원문을 **손질 없이 통째로** 넣고, 다음 단계에서 **필요한 것만 잘라 냅니다.** 절차의 모양이 같습니다.

**다만 한 가지가 다릅니다.**

| | 이 영상 | 제 쪽 |
|---|---|---|
| 깎는 주체 | **AI** | **코드** |
| 무엇이 왜 잘렸나 | **매번 달라짐** | **재현됨** |

이 차이가 큽니다. AI가 깎으면 **같은 입력에 대해 매번 다르게 깎일 수 있습니다.** 그러면 결과가 나빴을 때 **깎는 방식이 문제인지 다른 게 문제인지 못 가립니다.**

코드가 깎으면 **항상 같게 깎이고, 뭐가 왜 잘렸는지 다시 볼 수 있습니다.**

## 실제로 가져온 것은 절차가 아니라 한 문장이었습니다

3단계 절차는 이미 하고 있던 것이라 가져올 게 없었습니다.

대신 화자가 **지나가듯 던진 한 문장**이 남았습니다.

> **AI가 되묻는 질문 셋만 봐도, 내가 준 정보가 얼마나 빈약했는지 안다.**

이게 왜 값이 나가냐면 — **「AI에게 질문하게 시키기」의 목적을 다시 정의하기 때문**입니다.

보통은 「AI가 잘 이해하게 하려고」 질문을 시킵니다. 그런데 진짜 값은 **질문의 답**이 아니라 **질문 자체**에 있습니다. **AI가 무엇을 묻는지를 보면 내 설명의 구멍이 어디인지가 보입니다.**

그래서 저는 이걸 **기획서를 파이프라인에 넣기 «전에» 한 번 돌려 보는 자리**로 채택했습니다.

## 이 편에서 값을 치른 교훈

> **방법론 영상은 「절차」가 아니라 「부작용」에서 값어치가 나옵니다.**

소개된 3단계 절차는 제가 이미 하던 것이었습니다. 실제로 남은 건 **화자가 본론이라고 생각하지 않고 흘린 한 줄**이었습니다.

그러니까 이런 자료는 **요약본을 보면 안 됩니다.** 요약본에는 절차만 남고, **흘린 한 줄은 요약에서 제일 먼저 잘립니다.**

## 여기부터는 자세한 기록입니다

**방법 자체는 맞고, 세 단계 어디에도 「만든 프롬프트가 좋은지」를 재는 자리가 없습니다.** 16분짜리 영상이 자기 메타프롬프팅 방식을 정리합니다 — **프롬프트를 잘 쓰려 하지 말고, 프롬프트를 만들 재료를 전부 AI에게 넘긴 다음 AI가 깎게 하라.** 절반은 개념이고 절반은 실시간 데모입니다. 제가 여기서 실제로 가져온 건 절차가 아니라 **질문 유도의 진짜 효용에 대한 한 문장**이었고, 못 가져온 건 **이 방법이 이득이라는 증거**였습니다.

## 무엇을 말한 영상인가

**정의는 한 줄입니다 — AI에게 입력할 프롬프트를 AI에게 작업시키는 방법.** *"X를 만들어 줘"* 가 아니라 *"X를 만들 건데, 네가 AI에게 주입할 만한 좋은 프롬프트를 최적화해서 만들어 줘"* 입니다.

그리고 **고려할 요소가 셋**입니다.

- **질문 유도.** *"프롬프트 만들어 줘"* 로 끝내지 말고 *"좋은 프롬프트를 만들기 위해 더 필요한 컨텍스트가 있다면 나한테 물어봐 줘"* 를 붙입니다.
- **성공 조건 명시.** *"개쩌는 랜딩페이지 만들어줘"* 가 아니라 *"모바일 첫 화면 안에 핵심 가치가 보여야 하고, 모든 버튼과 폼이 실제로 동작해야 한다"* 입니다.
- **실행 환경에 맞게 변환.** 최종 프롬프트가 들어갈 도구마다 필요한 게 다릅니다 — 어떤 도구는 **중지 요건**을, 어떤 도구는 **제약 조건**을, 이미지 생성이면 구도·조명·카메라를, 리서치라면 출처 기준과 검증 방식을 박아야 합니다.

**안티패턴을 콕 집는 게 좋았습니다.** *"CRM 만들 건데 메타프롬프트 제작해 줘"* 로 바로 들어가면, **AI가 제멋대로 만든 프롬프트의 틀에 갇힙니다.** 내 머릿속을 안 넣었으니 나올 게 없고, 한 번 틀이 잡히면 그 틀 안에서만 고치게 됩니다.

**실무 팁 하나가 인상적이었습니다.** 회의에서 받은 요청사항이 있으면 **정리하지 말고 그대로 복붙하라**는 것입니다. 정제하는 순간 내가 이해한 만큼만 남기 때문입니다.

## 대표 기법 — 왜 「펼친 뒤 줄이기」인가

**처음부터 4,000자로 쓰는 것보다, 크게 다 펼친 뒤 깎아내는 쪽이 같은 글자 수 안에 디테일이 훨씬 많이 살아남습니다.** 화자가 붙인 비유가 정확합니다 — **길게 못 쓰는 건 초보고, 진짜 어려운 건 많이 쓴 글에서 포인트만 남겨 줄이는 것**입니다. 고등학교는 최소 글자수를 정하고 대학교는 최대 글자수를 정하는 이유가 그것입니다.

**그리고 새 창에서 시작합니다.** *"모든 LLM은 초반에 제일 잘합니다. 컨텍스트가 제일 적게 차 있을 때."* 프롬프트를 만드느라 쌓인 잡컨텍스트를 끌고 갈 이유가 없습니다.

**긴 작업일수록 앞단이 전부라는 근거도 붙습니다.** 며칠씩 도는 작업에 토큰을 태울 거라면 **앞에서 잘못된 방향으로 출발하는 비용이 그만큼 커집니다.**

> **[도판]** 무엇을 뺄지의 기준은 명료하다. 뺀 게 맞았는지를 확인하는 방법이 없을 뿐이다.
>
> 압축 단계에서 실제로 깎인 것과 남은 것. 판단 기준은 프롬프트에 없어도 AI가 동적으로 결정할 수 있는가 하나뿐이고, 그 기준은 사후 검증이 되지 않는다.

## 깨본 결과

**압축 기준이 사후 검증되지 않습니다.** *"프롬프트에 없어도 AI가 동적으로 결정 가능한가"* 는 판단 기준으로는 명료한데, **뺐는데 결과가 좋았을 때 그게 뺄 만해서인지 운이 좋아서인지 구분할 방법이 없습니다.** 같은 요구를 뺀 버전과 안 뺀 버전으로 각각 돌려 보지 않는 한 알 수 없고, 영상에는 그 대조가 없습니다.

**그리고 이득이 측정된 적이 없습니다.** 이 방법이 안 쓴 것보다 나은지, 얼마나 나은지에 대한 수치가 영상 전체에 하나도 없습니다. 화자 본인이 마지막에 *"다 하고 나서도 이게 진짜 가르칠 만한 내용인지 모르겠다"* 고 자평하는데, **그 정직함이 이 자료의 신뢰도를 올립니다.** 파는 물건이 아니라 방식 공유라서 그렇습니다.

**제일 값어치 있는 문장은 절차가 아니라 부작용에 있었습니다.** 질문 유도를 걸었더니 프롬프트가 안 나오고 질문이 쏟아졌고, 화자는 그걸 *"그것부터가 엄청난 성공"* 이라고 부릅니다. 그리고 **답을 세 개만 하고 나머지는 위임합니다.** 여기서 나온 한 줄이 이 영상의 핵심입니다.

> 1, 2, 3번만 봐도 원래 정보가 얼마나 빈약했는지 알 수 있다

**질문 유도의 본체는 좋은 프롬프트가 아니라, 내 컨텍스트에 구멍이 어디 났는지를 나에게 보여주는 것**입니다. 이건 프롬프트 기법이 아니라 진단 도구입니다.

⚠ 다만 **전부 위임하면 무의미해집니다.** 화자도 경고합니다 — 다 맡기면 애초에 이 절차를 돌린 이유가 사라집니다.

## 내 환경에 대봤다

**①과 ②는 이미 코드로 갖고 있었습니다.** 제 파이프라인은 기획서 원문을 정제 없이 통째로 넣고, 그다음 단계에서 결정론 코드가 필요한 것만 잘라 냅니다. 절차의 형태가 같습니다 — **다만 제 쪽은 깎는 주체가 LLM이 아니라 코드**라서, 무엇이 왜 잘렸는지가 재현됩니다.

**③은 제가 더 강하게 갖고 있습니다.** 결과물 점검이 사람 손보기로 끝나지 않고 게이트로 걸립니다. 이 영상의 3단계에 없는 게 정확히 그 자리입니다.

**안 갖고 있던 건 하나입니다 — 질문 유도를 컨텍스트 구멍 진단으로 쓰는 것.** 저는 지금까지 "질문해 줘"를 **더 나은 출력을 얻으려고** 써 왔지, **내가 뭘 빠뜨렸는지 보려고** 쓴 적이 없습니다. 같은 문장인데 목적이 다르면 읽는 것도 달라집니다.

## 판정

| 무엇 | 판정 |
|---|---|
| **질문 유도 = 컨텍스트 구멍 진단** | **채택.** 기획서를 넣기 전에 한 번 돌려 볼 자리가 있다 |
| **펼친 뒤 줄이기** | **이미 함.** 다만 깎는 주체가 코드라 재현된다는 점이 다르다 |
| **새 창에서 시작** | **이미 함.** 근거 문장은 가져올 만하다 |
| 3단계 절차 통째 도입 | **불필요.** ①②는 이미 있고 ③은 제 쪽이 더 세다 |

**이 편에서 값을 치른 교훈은 이겁니다 — 방법론 영상은 절차가 아니라 부작용에서 값어치가 나옵니다.** 3단계 절차는 제가 이미 하고 있는 것이었고, 실제로 남은 건 화자가 지나가듯 던진 *"질문 셋만 봐도 내 정보가 얼마나 빈약했는지 안다"* 한 줄이었습니다.

그리고 **재는 자리가 없는 방법은 좋아지지도 나빠지지도 않습니다.** 이 방법이 이득인지 아닌지는 지금 알 수 없고, 알려면 같은 요구를 두 방식으로 각각 돌려 보는 수밖에 없습니다. 화자가 *"모르겠다"* 로 끝낸 건 그래서 정확한 자평입니다.