“회의록 정리 프롬프트를 만들어 줘.”
AI에게 이렇게 말하면 대개 곧바로 프롬프트 하나가 나온다.
당신은 전문 회의록 작성자입니다. 아래 회의 내용을 분석하여 핵심 논의, 결정 사항, 액션 아이템을 체계적으로 정리하세요…
겉보기에는 괜찮다. 역할도 있고, 해야 할 일도 있고, 출력 형식도 있다.
그런데 실제 회의록 업무를 조금만 들여다보면 질문이 생긴다.
담당자가 전사에 없으면 어떻게 할 것인가. AI가 대화 흐름을 보고 담당자를 추정해도 되는가. 기한이 언급되지 않았으면 빈칸으로 둘 것인가. ‘다음 주’라는 말이 나왔을 때 회의 날짜를 기준으로 실제 날짜로 바꿔도 되는가. 결정된 내용과 단순 제안을 어떻게 구분할 것인가.
이런 판단은 “회의록 프롬프트”라는 업무명만으로 정해지지 않는다.
빈칸을 모르는 프롬프트
사용자가 프롬프트를 만들기 어려운 이유는 문장력이 부족해서만이 아니다.
자기가 무엇을 빠뜨렸는지 모르기 때문이다.
프롬프트를 처음 만들 때는 이미 알고 있는 내용을 설명하는 데 집중한다.
회의록을 정리해야 해. 핵심 논의와 결정 사항, 할 일을 뽑아줘.
하지만 결과를 실제로 바꾸는 것은 숨어 있는 조건일 때가 많다.
- 추정 금지인가
- 불명확하면 ‘확인 필요’라고 표시할 것인가
- 말한 사람 이름을 그대로 유지할 것인가
- 민감한 내용은 제외할 것인가
- 다음 회의 안건까지 만들 것인가
좋은 메타 프롬프트의 첫 역할은 이 빈칸을 질문으로 바꾸는 것이다.
바로 만들지 말고 먼저 물어보게 한다
기본형은 짧다.
내가 반복해서 하는 업무를 설명하겠다. 바로 실행 프롬프트를 만들지 말고, 결과를 실제로 바꾸는 정보 가운데 내가 아직 말하지 않은 것만 먼저 질문해 줘. 질문은 우선 최대 5개로 제한하고, 현재 정보만으로 첫 버전을 만들 수 있으면 불필요하게 계속 묻지 마.
이 문장이 하는 일은 두 가지다.
첫째, AI가 너무 빨리 정답을 만들어내는 것을 늦춘다.
둘째, 사용자가 빠뜨린 결정을 밖으로 꺼낸다.
질문 수를 최대 5개로 제한하는 것은 절대 규칙이 아니다. 대화가 끝없이 요구사항 인터뷰로 변하는 것을 막기 위한 실용적인 기본값이다. 복잡한 업무라면 더 물을 수 있고, 간단한 업무라면 두세 질문으로 끝날 수 있다.
AI가 정하면 편한 것과 사람이 정해야 하는 것
모든 세부사항을 사람이 정할 필요는 없다.
예를 들어 제목 후보 세 개를 만드는 작업에서 제목 순서나 문장부호까지 하나하나 결정하는 것은 오히려 비효율적일 수 있다. AI가 자연스럽게 선택해도 결과에 큰 문제가 없을 수 있다.
반면 다음은 사람이 소유할 가능성이 높다.
목적
왜 이 결과를 만드는가.
보고서를 기록용으로 남기는지, 팀장이 다음 행동을 결정하게 하려는지에 따라 구조가 달라진다.
신뢰할 자료
어떤 자료가 우선인가.
운영 대시보드와 재무 집계가 다를 때 어느 쪽을 우선할지 조직 규칙이 있다면 사람이 알려줘야 한다.
반드시 포함할 것
빠지면 결과를 쓸 수 없는 정보가 무엇인가.
금지 사항
자료에 없는 담당자, 원인, 숫자를 추정하면 안 되는지. 특정 표현을 쓰면 안 되는지.
합격 기준
무엇이 맞아야 결과를 사용할 수 있는가.
AI는 이 다섯 가지를 결정해 주는 존재라기보다, 사용자가 결정을 잊지 않도록 질문하게 할 수 있다.
업무 설명이 메타 프롬프트를 거쳐 실행 프롬프트가 되고 실제 결과로 이어지는 네 단계 구조
그림 F02. 메타 프롬프트 구조
일반 프롬프트와 메타 프롬프트
둘의 차이는 어렵지 않다.
일반 프롬프트
아래 회의 전사를 정리해 줘.
이 요청은 최종 산출물을 요구한다.
메타 프롬프트
내가 매주 회의 전사를 정리할 실행 프롬프트를 만들고 싶다. 필요한 조건을 먼저 질문하고, 답을 반영해 반복 사용할 프롬프트를 만들어 줘.
이 요청은 최종 산출물을 만드는 지시 구조를 요구한다.
메타 프롬프트 안에서도 종류가 나뉠 수 있다.
처음부터 실행 프롬프트를 만드는 생성형 메타 프롬프트가 있고, 기존 프롬프트와 결과를 비교해 수정하는 개선형 메타 프롬프트도 있다. 다른 입력으로 시험할 테스트를 설계하게 할 수도 있다.
하지만 독자는 처음부터 이름을 외울 필요가 없다.
실제 업무에서는 다음 두 문장만 기억해도 된다.
이 일을 반복해서 시킬 방법을 만들어 줘.
이 결과를 보고 무엇을 고쳐야 할지 찾아 줘.
메타 프롬프트가 필요 없는 순간
모든 요청을 메타 프롬프트로 바꾸면 오히려 일이 늘어난다.
“이 문장을 자연스럽게 고쳐줘.”
“오늘 회의 제목 세 개만 추천해줘.”
“이 숫자 두 개의 증감률을 계산해줘.”
한 번 쓰고 끝나는 작은 요청은 그냥 시키는 편이 낫다.
메타 프롬프트를 만들 가치가 큰 업무에는 공통점이 있다.
- 반복된다
- 품질 기준을 유지해야 한다
- 결과를 사람이 다시 많이 고친다
- 여러 입력 형태를 처리해야 한다
- 실패했을 때 비용이 크다
- 다른 사람이 같은 방식으로 수행해야 한다
프롬프트를 설계하는 데에도 비용이 있다. 질문에 답하고, 테스트하고, 결과를 기록해야 한다. 이 비용을 다시 회수할 수 있는 업무에 사용한다.
첫 번째 메타 프롬프트
지금 자주 하는 일 하나를 떠올린다.
이메일 작성도 좋고, 보고서도 좋고, 콘텐츠 초안이나 조사도 좋다.
다음 문장으로 시작한다.
나는 [업무]를 반복해서 하고 있다. 이 일을 위한 실행 프롬프트를 만들고 싶다. 바로 프롬프트를 작성하지 말고, 결과를 실제로 바꾸는 정보 가운데 내가 빠뜨린 것을 먼저 최대 5개 질문해 줘. 이미 말한 내용은 다시 묻지 말고, 모르는 것은 모른다고 답할 수 있게 해 줘. 현재 정보로 첫 버전을 만들 수 있으면 질문을 멈추고 실행 프롬프트를 만들어 줘.
질문을 받았을 때 완벽하게 답하려고 하지 않는다.
“모름.”
“아직 정하지 않음.”
“이번에는 중요하지 않음.”
이런 답도 가능하다.
목적은 모든 조건을 채우는 것이 아니라 첫 버전에 필요한 결정을 찾는 것이다.
첫 실습에서 하나만 발견해도 된다.
아, 이것도 정해야 했구나.
그 한 항목이 메타 프롬프트가 처음 해낸 일이다.
같은 업무인데 결과가 갈리는 지점
메타 프롬프트가 실제로 무엇을 바꾸는지 더 구체적으로 보자.
사용자가 매주 고객 문의를 요약한다고 해보자. 원본 요청은 다음과 같다.
이번 주 고객 문의를 요약해서 팀에 공유할 글을 써줘.
여기서 AI가 바로 결과를 만들면 자연스럽게 몇 가지를 결정해야 한다. 문의 건수를 유형별로 묶을지, 대표 사례를 넣을지, 고객 이름을 남길지, 심각도 순으로 정리할지, 담당자를 제안할지 스스로 선택한다.
그런데 실제 업무 규칙은 이럴 수 있다.
- 고객 이름과 연락처는 공유 문서에 넣지 않는다.
- 문의 유형은 배송/결제/상품/기타 네 범주를 쓴다.
- 같은 문의가 반복되면 건수를 표시한다.
- 담당자는 원문에 명시된 경우에만 적는다.
- 원인을 추정하지 않는다.
- 팀이 이번 주 바로 확인할 항목을 마지막에 세 개 이내로 제시한다.
이 정보가 들어가면 같은 ‘문의 요약’도 완전히 다른 업무가 된다.
메타 프롬프트의 역할은 이 규칙을 미리 다 알고 있는 척하는 것이 아니다. 사용자에게 물어봐야 할 규칙과 AI가 자연스럽게 처리해도 되는 세부사항을 나누는 것이다.
예를 들어 다음 질문은 결과를 크게 바꾼다.
고객 식별정보는 제거해야 하나요?
담당자가 전사에 없으면 추정해도 되나요?
결과를 누가 읽고 어떤 행동을 해야 하나요?
반면 다음 질문은 첫 버전에서 꼭 필요하지 않을 수 있다.
제목에 대시를 쓸까요, 콜론을 쓸까요?
소제목은 굵게 할까요?
질문을 잘 고른다는 것은 요구사항을 많이 수집하는 일이 아니라, 잘못 결정했을 때 결과의 의미가 바뀌는 지점을 찾는 일이다.
내가 결정하지 않은 것을 AI가 결정했는지 찾는 법
AI가 만든 첫 프롬프트를 받은 뒤 한 번 읽어본다. 이때 문장 표현을 고치려 하지 말고 결정문만 찾는다.
예를 들어:
가장 중요한 문의 유형을 우선순위 순으로 정렬한다.
라는 규칙이 들어 있다면 묻는다.
‘중요함’을 어떤 기준으로 정했지?
사용자가 정하지 않았다면 AI가 새 기준을 만든 것이다.
고객 불만이 큰 문의를 최우선으로 표시한다.
라고 되어 있다면:
불만이 크다는 것을 무엇으로 판단하지?
라고 묻는다.
이런 식으로 프롬프트 안의 동사와 판단 표현을 훑으면 숨어 있는 결정을 찾기 쉽다.
- 우선한다
- 제외한다
- 중요하다고 판단한다
- 추천한다
- 강조한다
- 위험하다고 본다
- 최적의 것을 고른다
이런 표현 뒤에는 기준이 필요할 수 있다.
AI가 기준을 제안해도 된다. 다만 제안과 확정을 구분한다.
현재 정보가 부족한 항목은 네가 임의로 확정하지 말고, 선택지가 있다면 후보와 장단점을 보여줘. 내가 선택하면 그 결정을 실행 프롬프트에 반영해 줘.
이 한 문장을 메타 프롬프트에 넣어두면, 결정권을 넘기지 않으면서 AI의 제안 능력을 활용할 수 있다.
첫 버전에 필요한 최소 계약
실행 프롬프트 V1을 만들 때 다음 일곱 칸이 모두 길 필요는 없다.
목적 — 무엇을 위해 하는가.
사용자 — 누가 결과를 쓰는가.
입력 — 무엇을 넣는가.
필수 규칙 — 항상 지킬 것은 무엇인가.
금지 — 무엇을 하면 안 되는가.
출력 — 어떤 형태로 받을 것인가.
판정 — 무엇을 확인하면 되는가.
한 줄씩만 있어도 반복 업무의 첫 계약이 된다.
메타 프롬프트를 처음 사용할 때는 거대한 프롬프트를 만들려고 하지 않는다. 이 칸들을 채울 만큼만 질문을 받고, 실제 실행으로 넘어가는 편이 낫다.
이 장을 끝내기 전에
반복 업무 하나를 적는다. 그리고 AI에게 바로 프롬프트를 만들어 달라고 하지 말고 빠진 결정을 최대 5개 질문하게 한다. 답변 중 아직 정하지 않은 내용에는 미정이라고 적는다. 마지막으로 AI가 만든 실행 프롬프트에서 우선한다, 추천한다, 제외한다, 중요하다고 판단한다 같은 표현을 찾아 그 기준을 누가 정했는지 확인한다. 사용자가 정하지 않은 큰 결정이 하나라도 보이면 질문 단계로 되돌린다.
