메타 프롬프팅

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

무엇을 말한 영상인가

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

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

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

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

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

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

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

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

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

깨본 결과

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

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

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

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

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

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

내 환경에 대봤다

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

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

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

판정

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

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

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