결과물 말고 프롬프트를 시켜라 — 메타 프롬프팅 3단계 (컨텍스트 덤핑·깎아내기·새 창 주입)

AI에게 뭔가를 시켰는데 나온 결과가 미묘하게 어긋나 있는 경험, 다들 있으실 겁니다. “랜딩페이지 카피 써줘”라고 했더니 우리 서비스가 아니라 일반적인 SaaS 이야기를 하고 있고, “이 기능 구현해줘”라고 했더니 기존 코드 컨벤션을 무시한 파일이 새로 생깁니다. 그래서 다시 설명하고, 또 어긋나고, 세 번째쯤에 “됐고 내가 하지” 하고 창을 닫습니다.

여기서 흔히 나오는 처방이 “프롬프트를 잘 쓰세요”인데, 이 조언은 사실상 아무 정보가 없습니다. 문제는 내가 뭘 안 썼는지를 내가 모른다는 데 있기 때문입니다. 머릿속에 있는 맥락 — 이 페이지를 왜 만드는지, 누가 보는지, 어떤 톤이면 안 되는지, 어떤 상태가 되면 “다 됐다”고 할 수 있는지 — 은 나한테는 너무 당연해서 굳이 문장으로 옮길 생각이 안 듭니다. 그리고 그 당연한 것들이 정확히 AI가 모르는 것들입니다.

메타 프롬프팅은 이 간극을 사람이 아니라 AI가 메우게 하는 방법입니다. 결과물을 바로 요청하지 말고, “그 결과물을 만들 최적의 프롬프트를 네가 먼저 써 줘” 라고 시키는 것이 전부입니다. 이 글은 유튜브 채널 코드팩토리의 메타 프롬프팅 계속 물어보셔서 제 스타일 알려드림(16분)에서 소개된 방식을 정리하고, 실무에 붙일 수 있는 형태로 재구성한 것입니다.

미리 밝혀둡니다. 이 글은 해당 영상에서 공개된 방법과 그 구조를 정리한 것이지, 저희가 A/B 테스트로 출력 품질 차이를 계량한 결과가 아닙니다. “몇 % 좋아진다” 같은 수치는 이 글에 없습니다.

왜 AI가 쓴 프롬프트가 내가 쓴 프롬프트보다 나은가

영상의 논지는 시작 지점(00:38)에서 명확합니다. 최종 결과물을 직접 요청하는 대신, AI에게 “주입할 최적화된 프롬프트를 만들어 달라”고 요청한다는 것입니다. 그러면 사람이 놓치는 디테일까지 채워진 고품질 지시서가 나온다는 게 핵심 주장입니다.

이유는 두 가지로 볼 수 있습니다.

첫째, 프롬프트를 쓰는 일은 결과물을 만드는 일보다 훨씬 쉬운 과제입니다. 랜딩페이지를 잘 만드는 것보다 “랜딩페이지를 만들 때 어떤 항목이 정해져 있어야 하는가”를 나열하는 게 쉽습니다. 후자는 LLM이 대량으로 학습한 종류의 지식이고, 실패해도 티가 납니다.

둘째, 프롬프트는 내가 읽고 고칠 수 있는 중간 산출물입니다. 5,000자짜리 코드가 나오면 검수 비용이 큽니다. 하지만 20줄짜리 지시서가 나오면 훑어보다가 “아 이건 틀렸네, 우리는 B2C야” 하고 한 줄 고치면 됩니다. 오류를 싸게 잡아내는 지점이 앞으로 당겨지는 겁니다.

3단계 흐름

영상에서 제시하는 절차는 세 단계(01:16)입니다.

단계	하는 일	실패하기 쉬운 지점
1. 컨텍스트 덤핑	머릿속 아이디어·회의 내용을 정제하지 말고 전부 던진다	미리 요약해서 던짐 → 정작 중요한 단서가 잘려나감
2. 프롬프트 깎아내기	목적·글자 수 제한 등에 맞춰 프롬프트를 다듬는다	나온 프롬프트를 그대로 씀 → 검수 없이 신뢰
3. 새 창에 주입	완성된 프롬프트를 점검한 뒤 새 채팅창에서 실제 작업 시작	브레인스토밍하던 창에서 그냥 이어감

1단계에서 가장 많이 하는 실수가 “정리해서 물어보기”입니다. 깔끔하게 세 줄로 요약해서 던지면 AI가 이해하기 좋을 것 같지만, 그 요약 과정에서 버려지는 게 대부분 맥락입니다. 회의록 원문, 슬랙 대화 붙여넣기, 두서없는 메모, 참고 사이트 URL, “이건 좀 아닌 것 같은데”라는 애매한 감상까지 그대로 넣는 편이 낫습니다. 정제는 2단계에서 AI가 합니다.

프롬프트에 반드시 들어가야 할 3가지

영상은 좋은 프롬프트를 얻기 위한 필수 요소를 세 가지로 정리합니다.

① 역질문 유도하기 (01:45)

아이디어를 던진 뒤 곧바로 만들라고 하지 말고, “좋은 프롬프트를 위해 내가 놓친 정보가 있으면 역으로 질문해 줘” 라고 요청합니다. AI와 내 생각의 싱크를 맞추는 게 핵심이라는 설명입니다.

실무에서 이 한 줄의 효과가 가장 체감이 큽니다. 보통 3~7개 정도의 질문이 돌아오는데, 그중 두어 개는 “아 그건 생각 안 해봤네” 하는 것들입니다. 예를 들어 랜딩페이지라면 “주요 유입 채널이 검색인가요, 광고인가요?” 같은 질문이 나오고, 답에 따라 카피의 첫 문장 구조가 통째로 달라집니다.

② 성공 조건 명시하기 (03:24)

팀원에게 일을 시키듯, 어떤 가치가 보여야 하고 어떤 기능이 동작해야 하는지 명확한 “엔딩 조건”을 구체적으로 적으라는 것입니다.

이건 사실 소프트웨어 쪽에서는 인수 조건(acceptance criteria)이라고 부르던 것과 같습니다. 차이는 이걸 프롬프트 안에 못박아 넣는다는 점입니다. “잘 만들어줘”는 검증이 불가능하지만, “모바일 375px에서 가로 스크롤이 생기지 않는다 / 폼 제출 실패 시 사용자에게 한국어 에러 문구가 보인다”는 검증이 가능합니다. 검증 가능한 문장만 성공 조건에 넣는 게 요령입니다.

③ 실행 환경에 맞게 변환하기 (05:13)

최종적으로 사용할 툴의 환경과 제약에 맞춰 최적화를 요청합니다. 영상에서는 글자 수 제한이 있는 프롬프트 입력창(4,000자 제한 사례), 코드 작성용, 이미지 생성용 등 용도별로 각각 “깎아내는” 방식을 듭니다.

같은 요구사항이라도 붙일 곳에 따라 형태가 달라야 합니다. 코딩 에이전트에 넣을 프롬프트는 파일 경로와 컨벤션이 핵심이고, 이미지 생성기에 넣을 프롬프트는 구도·조명·스타일 키워드가 핵심입니다. 산문으로 잘 쓴 지시서를 이미지 생성기에 그대로 넣으면 대부분 무시됩니다.

참고로 각 서비스의 입력 길이 제한이나 지원 문법은 자주 바뀝니다. 구체적인 상한은 쓰기 직전에 해당 툴의 공식 문서를 확인하시는 편이 안전합니다.

그대로 쓸 수 있는 시작 문구

세 요소를 한 덩어리로 묶은 시작 문구를 스니펫으로 저장해두면 매번 고민할 일이 없습니다. 기본형은 이렇습니다.

아래 내용을 바탕으로, [만들 것]을 만들 최적의 프롬프트를 작성해줘.

1) 먼저, 좋은 프롬프트를 쓰기 위해 내가 놓친 정보가 있으면 역으로 질문해줘.
   질문에 내가 답한 다음에 프롬프트를 써줘.
2) 프롬프트에는 "성공 조건"을 반드시 포함해줘.
   무엇이 보여야 하고 어떤 기능이 동작해야 완료인지 검증 가능한 문장으로.
3) 최종적으로 [사용할 툴]에 넣을 거야. 그 환경의 제약에 맞게 깎아줘.

--- 여기부터 내 컨텍스트 (정리 안 된 상태 그대로) ---
(회의 메모, 슬랙 대화, 참고 URL, 두서없는 아이디어 전부 붙여넣기)

코딩 에이전트용으로 쓸 때는 3번 줄을 이렇게 바꿉니다.

3) 최종적으로 Claude Code / Codex에 넣을 거야.
   - 수정할 파일 경로를 명시할 것
   - 기존 코드 컨벤션을 먼저 읽고 따르라는 지시를 포함할 것
   - 한 번에 바꿀 범위를 제한할 것 (전체 리팩터링 금지)
   - 완료 판정 방법(빌드 통과 / 특정 화면에서 동작 확인)을 넣을 것

역질문에 답할 때는 짧게 답해도 됩니다. “1번 B2C, 2번 검색 유입, 3번 모름” 정도로 충분하고, 모르는 건 모른다고 답하는 편이 낫습니다. 그래야 AI가 그 부분을 가정으로 처리하고 프롬프트 안에 “이 부분은 확인 필요”로 남겨둡니다.

가장 중요한 한 가지: 완성된 프롬프트는 새 창에 넣는다

영상에서 후반부(14:30)에 강조하는 부분이자, 실제로 가장 자주 건너뛰는 단계입니다.

완벽한 프롬프트를 얻었다면 그 대화창에서 바로 이어서 작업하지 않습니다. 프롬프트를 복사해서 반드시 새 채팅창을 열고 거기에 주입합니다. 이유는 LLM이 이전 컨텍스트가 적고 깔끔할수록 명령 수행을 잘 하기 때문이고, 브레인스토밍 과정에서 나온 불필요한 데이터가 섞이는 걸 막기 위해서입니다.

이걸 컨텍스트 위생이라고 부를 만합니다. 프롬프트를 뽑아내는 대화창에는 이런 것들이 잔뜩 쌓여 있습니다.

• 중간에 폐기한 방향 (“아니 그거 말고”)
• AI가 던진 역질문과 내 단답
• 내가 붙여넣은 원본 회의록 전체
• 한번 시도했다가 마음에 안 들었던 초안

여기서 그대로 “그럼 만들어줘”라고 하면, 모델은 확정된 지시서와 폐기된 방향을 같은 무게로 보게 됩니다. 폐기했던 아이디어가 결과물에 슬쩍 되살아나는 현상이 여기서 옵니다. 새 창에서는 확정본 하나만 있으니 그럴 여지가 없습니다.

특히 코딩 에이전트 세션이 길어져서 히스토리가 지저분해졌을 때 효과가 큽니다. 긴 브레인스토밍 뒤에는 새 세션에서 실제 빌드를 시작하는 습관을 들이는 편이 좋습니다.

주의사항 — 이 방법이 잘 안 통하는 경우

단순 작업에는 오버헤드입니다. “이 함수 이름 바꿔줘”, “이 문장 오타 고쳐줘” 같은 일에 메타 프롬프팅을 붙이면 왕복만 늘어납니다. 결과물의 재작업 비용이 큰 일 — 랜딩페이지 전체, 기능 하나, 영상 기획안 — 에서만 이득이 납니다.

AI가 쓴 프롬프트를 검수 없이 쓰면 오히려 나빠집니다. 그럴듯한 요구사항이 자동으로 추가되는 경우가 꽤 있습니다. 아무도 요청하지 않은 “다크모드 지원”, “다국어 대응” 같은 항목이 성공 조건에 들어가 있으면, 그대로 넘겼을 때 정말로 그걸 만들고 있습니다. 2단계 “깎아내기”는 AI가 아니라 사람이 최종 결정하는 단계로 두는 게 맞습니다.

역질문이 형식적으로 돌아오는 경우도 있습니다. 컨텍스트를 너무 조금 던지면 “타깃이 누구인가요, 예산은요, 일정은요” 같은 뻔한 질문만 나옵니다. 이건 방법의 문제가 아니라 1단계 덤핑이 부족했다는 신호로 읽으시면 됩니다.

점수: 8.4

좋은 점

• 배우는 비용이 거의 없습니다. 새 툴 설치도, 구독도 필요 없고 문장 하나 바꾸는 게 전부입니다.
• 검수 지점이 앞으로 당겨집니다. 완성된 결과물을 뜯어보는 것보다 20줄 지시서를 고치는 쪽이 훨씬 쌉니다.
• “성공 조건”을 강제하는 구조라, 요구사항이 애매한 채로 작업이 시작되는 일을 줄여줍니다.
• 모델이나 툴에 종속되지 않습니다. Claude·ChatGPT·Codex 어디서든 같은 방식으로 씁니다.

아쉬운 점

• 왕복이 최소 2~3번 늘어납니다. 급할 때는 오히려 부담이고, 짧은 작업에는 명백한 낭비입니다.
• AI가 만든 프롬프트에는 요청하지 않은 요구사항이 섞여 들어옵니다. 사람이 반드시 잘라내야 하는데, 그 판단은 여전히 사람 몫입니다.
• 창을 옮기는 단계가 수동입니다. 복사·붙여넣기를 잊으면 컨텍스트 위생이라는 핵심 이점이 그대로 날아갑니다.
• 효과를 계량하기 어렵습니다. 같은 요청을 두 방식으로 돌려 비교하지 않는 한 “좋아진 것 같다”는 인상에 머무릅니다. 이 글의 점수도 방법의 구조적 타당성과 도입 비용을 기준으로 매긴 것이지, 출력 품질을 측정한 결과가 아닙니다.

이럴 때 쓰세요: 결과물이 어긋나면 다시 만드는 비용이 큰 작업 — 페이지 하나, 기능 하나, 기획안 하나 — 을 AI에 맡기기 직전에 쓰세요.

이어서 붙이면 좋은 것

메타 프롬프팅은 그 자체로 완결된 워크플로우라기보다, 기존 작업 순서의 앞단에 끼워 넣는 부품에 가깝습니다. 웹 제작이라면 시안 프롬프트를 쓰기 전과 구현 지시를 내리기 전, 두 지점에 각각 한 번씩 넣는 식입니다. 어차피 프롬프트를 쓰긴 써야 하는 자리라면, 그 프롬프트를 누가 쓸지만 바꾸는 셈입니다.

원본 영상은 16분 분량이고, 위 타임스탬프를 참고하면 필요한 부분만 골라 보실 수 있습니다.