AI 회의 프롬프트, 역할 토론⁠·실패 먼저⁠·판단 기준 요청문 4가지

AI에게 "평가해 줘"라고 한 번 묻는 대신, 여러 역할을 세워 회의하게 하면 찬성과 반대, 보류 이유까지 한꺼번에 받을 수 있습니다. 이 글은 AI 회의 프롬프트를 포함해 질문 방식을 바꾸는 전략 네 가지를 바로 복사해 쓰는 요청문과 21단계로 정리했습니다.

질문 방식을 바꾸는 네 가지 전략

AI를 쓰는 방식은 크게 두 갈래로 나뉩니다. 남이 만든 결과를 받아 쓰는 쪽과, 결과가 나오는 구조를 직접 설계하는 쪽입니다. 차이는 네 쌍으로 정리됩니다.

• 프롬프트를 복사해 쓰기 vs 레퍼런스에서 프롬프트를 뽑아 모듈로 나눠 두기
• AI에게 일을 시키기 vs 여러 역할로 회의를 시키기
• 더 좋은 답을 바로 묻기 vs 나쁜 답(실패)을 먼저 뽑기
• "해 줘"라고 하기 vs 판단 기준을 주기

네 가지 모두 특정 AI 서비스에 묶이지 않는 방법이라 GPT, Claude, Gemini 어디서나 쓸 수 있습니다. 역할 부여, 평가 기준 명시, 출력 구조 지정은 OpenAI, Anthropic, Google의 공식 프롬프트 가이드가 공통으로 권하는 요소이기도 합니다.

준비물

• 대화형 AI 서비스 1개. 전략 1에서는 이미지 첨부가 돼야 합니다.
• (전략 1용) 따라 만들고 싶은 목표 이미지
• (전략 2용) 평가받고 싶은 기획안 파일이나 글
• (전략 4용) 평가받고 싶은 사업 아이디어

전략 1. 레퍼런스 이미지로 "프롬프트 패키지" 만들기

Threads나 YouTube에서 프롬프트를 모아 써 보고, 결과가 아쉬우면 조금씩 고치는 방식은 누구나 거치는 자연스러운 과정입니다. 다만 원하는 결과가 나올 때까지 시행착오가 길어지고, 반복 작업에 쓸 나만의 레시피가 남지 않습니다. 순서를 뒤집으면 이 문제가 풀립니다. 결과 이미지에서 출발해 프롬프트를 거꾸로 뽑는 것입니다.

1단계. 웹이나 SNS에서 따라 만들고 싶은 목표 이미지를 고릅니다. - 확인: 레퍼런스로 쓸 이미지가 정해졌습니다.

2단계. AI 대화창에 그 이미지를 첨부합니다. - 확인: 이미지가 입력창에 첨부됐습니다.

3단계. 거의 똑같은 결과가 나오도록 프롬프트를 만들어 달라고 요청합니다.

첨부한 이미지와 거의 똑같은 결과가 나오도록 이미지 생성 프롬프트를 만들어 줘.

• 확인: AI가 이미지를 재현하는 프롬프트를 보여 줍니다.

4단계. 그 프롬프트를 아래 모듈로 나눠 달라고 요청합니다.

위 프롬프트를 아래 모듈로 나눠서 항목별로 다시 정리해 줘.
구도·카메라, 인물·피사체, 피부 질감, 조명, 환경·배경, 색상 톤, 스타일·매체, 후처리·기술 설정, 무드·감정·내러티브, 텍스트·그래픽 요소

• 확인: 프롬프트가 모듈별 항목으로 나뉘어 나옵니다.

5단계. 모듈로 나뉜 프롬프트를 메모나 문서에 저장합니다. - 확인: 다음에 꺼내 쓸 수 있는 곳에 저장돼 있습니다. 이것이 나만의 프롬프트 가이드북이 됩니다.

6단계. 다음에 필요할 때 원하는 모듈 하나만 골라 내용을 바꿉니다. - 주의: 전체를 다시 만들지 않습니다. - 예: 조명 모듈만 "해 질 녘 역광"으로, 배경 모듈만 "비 오는 도심 골목"으로 바꿉니다. - 확인: 바꾼 모듈만 달라진 프롬프트가 완성됩니다.

이렇게 하면 다음부터 이미지 프롬프트를 여기저기 찾아다닐 필요가 없습니다. 모듈로 나누는 방식은 이미지뿐 아니라 글쓰기(대상⁠·말투⁠·구성⁠·분량), 보고서(목적⁠·대상⁠·형식⁠·근거) 같은 다른 분야에도 똑같이 쓸 수 있습니다.

전략 2. 일 시키기 대신 "회의" 시키기

"이 기획안 평가해 줘"는 나쁜 질문이 아닙니다. 요즘 AI는 이 정도 질문에도 꽤 괜찮게 답합니다. 다만 평가가 한 번의 답변, 한 사람의 관점으로 끝나기 쉽습니다. 역할을 나눠 토론하게 하면 단순한 의견이 아니라 조직이 결정을 내리는 과정이 나와서 리스크와 실행 포인트가 더 선명해집니다.

7단계. 평가받을 기획안을 AI 대화창에 첨부합니다. - 확인: 기획안이 첨부됐습니다.

8단계. 아래 요청문을 입력합니다.

첨부한 기획안을 두고 먼저 콘텐츠 기획자, 마케터, CFO, CEO의 역할을 각각 설정해 줘. 이들이 실제 회의처럼 토론하게 하고 각 역할별 찬성 의견, 가장 강한 반대 논리, 최종 합의안과 보류 이유를 정리해 줘.

• 팁: 콘텐츠 기획자, 마케터, CFO(최고재무책임자), CEO는 예시입니다. 개발자, 법무 담당, 고객 대표처럼 내 기획에 맞는 역할로 바꿔 씁니다.
• 확인: 입력창에 요청문이 들어 있습니다.

9단계. 전송합니다. - 확인: AI가 역할별 토론 결과를 보여 줍니다.

10단계. 역할별 목표와 체크포인트가 있는지 확인합니다. - 확인: 역할마다 무엇을 지키려 하는지(목표)와 무엇을 따져 보는지(체크포인트)가 정해져 있습니다.

11단계. 역할별 찬성 근거와 가장 강한 반대 논리를 읽습니다. - 확인: 각 역할의 찬성 근거와 반대 논리가 함께 있습니다.

12단계. 최종 합의안을 읽습니다. - 확인: 최종 합의안이 나와 있습니다.

13단계. 보류 항목과 보류 사유를 읽습니다. - 예: 콘텐츠 사업 기획안이라면 유료 광고, 멤버십, 애니메이션 중심 제작이 현 단계 보류로 나올 수 있습니다. - 확인: 보류 항목마다 왜 보류인지, 어떤 리스크 때문인지 구체적인 사유가 붙어 있습니다.

역할들이 모두 비슷한 말만 한다면 "각 역할은 자기 입장을 끝까지 지키고, 쉽게 동의하지 마"라는 문장을 덧붙입니다. AI는 사용자의 안에 동의하는 쪽으로 기울기 쉬워서, 반대 역할을 분명히 세워 줘야 쓸모 있는 반론이 나옵니다.

전략 3. 나쁜 답(실패)부터 뽑기

"AI 공부 어떻게 시작하는 게 좋아?"는 틀린 질문이 아닙니다. 하지만 범위가 너무 넓어 답도 넓어지고, 오히려 어디서 시작할지 흐려질 수 있습니다. 정답을 묻기 전에 망하는 길부터 지우는 방식이 더 빠릅니다.

14단계. 첫 번째 요청을 입력합니다.

AI 공부 시작할 때 가장 비효율적인 방법 세 가지를 뽑아 줘.

• 팁: "AI 공부"는 예시입니다. 내 주제로 바꿔 씁니다.
• 확인: 비효율적인 방법 3가지가 나옵니다.

15단계. 두 번째 요청을 입력합니다.

사람들이 가장 많이 착각하는 접근 세 가지도 정리해 줘.

• 확인: 착각하기 쉬운 접근 3가지가 나옵니다.

16단계. 세 번째 요청을 입력합니다.

가장 비효율적인 방법과 가장 많이 착각하는 접근을 전부 피하는 최적의 시작 전략을 제안해 줘.

• 확인: 앞의 실패 요소를 피하는 시작 전략이 나옵니다.

17단계. 결과를 읽습니다. - 확인: 피해야 할 길이 먼저 정리돼 있습니다. 실수를 줄이면 속도가 붙고, 그다음 내 상황에 맞는 전략을 세우기가 쉬워집니다.

전략 4. "해 줘" 대신 판단 기준 주기

"이 사업 아이디어 괜찮아 보여. 평가해 줘"라는 질문에는 어떤 기준에서 괜찮은지가 빠져 있습니다. 기준이 없으면 AI가 매번 다른 관점을 골라 답이 들쭉날쭉해집니다. 기준을 주면 같은 틀로 평가해서 결과가 흔들리지 않고, 약한 부분과 보완 방법이 바로 보입니다.

18단계. 평가받을 사업 아이디어를 정합니다. - 확인: 아이디어를 두세 문장으로 적어 뒀습니다.

19단계. 아래 요청문에 아이디어를 붙여 입력합니다.

이 아이디어를 실행 난이도, 수익화 가능성, 확장성 기준으로 각각 10점 만점으로 평가해 줘. 그리고 점수가 낮은 항목은 전제를 바꿔서 점수를 올릴 수 있는 개선안도 같이 제안해 줘.

• 팁: 실행 난이도, 수익화 가능성, 확장성은 예시 기준입니다. 초기 비용, 법적 위험, 내 역량과의 맞음처럼 나에게 중요한 기준으로 바꿔 씁니다.
• 확인: 입력창에 요청문과 아이디어가 있습니다.

20단계. 전송합니다. - 확인: 기준별 점수(10점 만점)가 나옵니다.

21단계. 점수가 낮은 항목의 개선안을 읽습니다. - 확인: 낮은 항목마다 전제를 바꿔 점수를 올릴 수 있는 개선안이 있습니다.

회사에서 느낌이 아니라 기준과 논리로 결론을 내는 방식과 같습니다. 점수가 더 믿을 만하려면 "몇 점이 어떤 상태인지" 점수 구간 기준도 함께 적어 주면 좋습니다. AI가 매긴 점수는 판단을 돕는 참고 자료이고, 실제 사업 결정은 시장 자료와 전문가 검토로 확인해야 합니다.

끝나고 점검할 것

• 레퍼런스 이미지로 모듈별 프롬프트를 얻어 저장했다.
• 평가 요청에 역할(기획자, 마케터, CFO, CEO 등)을 정했고, 찬성⁠·반대⁠·합의안⁠·보류 이유를 받았다.
• 넓은 질문 대신 비효율적인 방법과 착각을 먼저 뽑는 질문을 썼다.
• "평가해 줘"에 기준과 점수 체계를 붙였다.

막힐 때

결과가 아쉬워서 수정만 반복하게 된다

복사한 프롬프트를 조금씩 고치는 방식은 시행착오가 길어집니다. 레퍼런스로 프롬프트 패키지를 만들고 필요한 모듈만 바꿔 씁니다(1~6단계).

답이 한 번에 끝나 관점이 한쪽으로 쏠린다

역할을 나눠 회의하게 합니다(7~13단계). 반대 역할이 약하면 "쉽게 동의하지 마"를 덧붙입니다.

답이 너무 넓고 어디서 시작할지 흐리다

질문 범위가 넓어서입니다. 비효율적인 방법과 착각을 먼저 뽑는 질문으로 바꿉니다(14~17단계).

답이 매번 들쭉날쭉하다

판단 기준이 빠져 있어서입니다. 기준과 10점 만점 점수를 요청문에 넣습니다(18~21단계).