메타 프롬프팅

「AI에게 시킬 말을 잘 쓰려고 애쓰지 말고, 재료를 다 던져 준 다음 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가 동적으로 결정 가능한가” 는 판단 기준으로는 명료한데, 뺐는데 결과가 좋았을 때 그게 뺄 만해서인지 운이 좋아서인지 구분할 방법이 없습니다. 같은 요구를 뺀 버전과 안 뺀 버전으로 각각 돌려 보지 않는 한 알 수 없고, 영상에는 그 대조가 없습니다.

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

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

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

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

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

내 환경에 대봤다

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

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

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

판정

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

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

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