AI에게 “캠페인 아이디어 20개만 줘”라고 부탁하면 빈 화면은 금방 채워진다. 그런데 그 목록을 회의에 가져가면 이상한 일이 생긴다. 사람마다 한두 개씩 고르기는 하는데, 왜 그 안이어야 하는지 설명하기 어렵다. 후보는 늘었는데 결정은 쉬워지지 않는다.
운영자는 브런치 글 「가본 만큼만 내 땅이다: AI가 줄 수 없는 것」에서 AI를 아이디어의 정답지가 아니라 회의 전에 가능성을 시험하는 시뮬레이터로 설명했다. 반면 「AI가 뭉뚝한 게 아니라, 내가 뭉뚝해지고 있었다」에서는 회의 전 검증을 반복할수록 반박받을 만한 모서리까지 깎일 수 있다는 경험을 적었다.
두 경험을 함께 놓으면 순서가 보인다. AI에게 먼저 답을 받는 것이 아니라, 사람이 먼저 날것의 생각을 꺼낸 뒤 AI로 조건과 허점을 확인해야 한다. 이 글은 그 순서를 실제 회의에 가져갈 수 있는 6단계로 바꾼 것이다.
30초 답: 사람 초안 → AI 반론 → 현장 근거 순서로 쓴다
AI 브레인스토밍은 아이디어를 많이 받는 작업이 아니다. 회의에서 결정할 후보와 아직 모르는 것을 분리하는 작업에 가깝다.
- 문제와 결정할 항목을 한 문장으로 적는다.
- AI를 켜기 전에 사람이 서로 다른 방향의 초안 세 개를 쓴다.
- AI에게 새 아이디어가 아니라 각 초안의 조건 위반과 빈 근거를 찾게 한다.
- 반론을 ‘필수 수정·확인 필요·낯섦’으로 나눈다.
- 실제 고객 반응이나 운영 자료로 확인 가능한 부분을 채운다.
- 회의에서는 후보, 근거, 미확인 가정, 다음 행동을 함께 결정한다.
이 순서를 지키면 AI가 회의를 대신하지 않는다. 회의가 처음부터 시작하지 않도록 재료를 정리해준다.
AI가 잘하는 일과 사람이 남겨야 할 일을 먼저 나눈다
브레인스토밍이 흐려지는 가장 흔한 이유는 AI의 역할이 정해져 있지 않기 때문이다. 같은 도구도 언제 부르느냐에 따라 결과가 달라진다.
| 작업 | AI에게 맡기기 좋은 부분 | 사람이 남겨야 할 부분 |
|---|---|---|
| 문제 정리 | 문장 속 목적·대상·제약을 표로 분리 | 이번 회의에서 실제로 결정할 것 확정 |
| 아이디어 확장 | 사람이 낸 방향의 변형, 반대 관점 제시 | 첫 초안과 낯선 발상 만들기 |
| 조건 검토 | RFP·일정·예산과 충돌하는 문장 표시 | 조건의 우선순위와 예외 판단 |
| 근거 점검 | 근거가 필요한 주장과 출처 공백 표시 | 실제 고객 경험·현장 자료 확인 |
| 선택 | 후보별 장단점과 미확인 가정 정리 | 무엇을 버리고 무엇을 시험할지 결정 |
AI는 많은 문장을 빠르게 비교할 수 있다. 그러나 “우리 고객이 이 장면에서 실제로 멈췄다” 같은 경험은 만들어낼 수 없다. 그럴듯한 예시는 줄 수 있어도 실제로 확인한 사실은 아니다.
1단계: 아이디어보다 회의의 출구를 적는다
“신선한 아이디어가 필요하다”는 말만으로 시작하면 신선함의 정의를 두고 다시 회의하게 된다. 먼저 회의가 끝났을 때 무엇이 남아야 하는지 적는다.
예를 들어 “다음 분기 캠페인 아이디어를 정한다”보다 다음 문장이 낫다.
다음 회의에서 3개 후보 중 1개를 소규모 테스트 대상으로 고른다. 후보마다 대상 고객, 보여줄 장면, 반드시 지킬 조건, 확인하지 못한 가정을 한 줄씩 남긴다.
이 문장에는 선택 수, 결과물의 모양, 다음 행동이 들어 있다. 좋은 업무 프롬프트의 5요소에서 설명한 목표·입력·제약·출력 구조를 회의에도 그대로 적용할 수 있다.
2단계: AI를 열기 전에 사람이 초안 세 개를 쓴다
운영자의 실제 제안 경험에서 중요한 변화는 AI 검증 전에 날것의 생각을 먼저 펼쳐놓는 것이었다. 처음부터 AI가 낸 목록을 보면 그 단어와 형식이 생각의 범위를 정할 수 있다.
세 개는 충분히 작고 서로 비교할 수 있는 수다. 단, 같은 아이디어의 문구만 바꾼 세 개는 피한다.
- 장면이 다른 안: 고객이 제품을 쓰는 순간을 바꾼다.
- 관계가 다른 안: 브랜드가 말하는 대신 고객이나 파트너가 말한다.
- 형식이 다른 안: 설명, 체험, 참여 가운데 접근법을 바꾼다.
문장이 어설퍼도 고치지 않는다. 이 단계의 목적은 발표 가능한 카피가 아니라 사람이 처음 떠올린 방향을 보존하는 것이다.
3단계: AI에게 아이디어가 아니라 반론을 요청한다
이제 AI를 부른다. 그러나 “더 좋은 아이디어로 수정해줘”라고 하지 않는다. 수정부터 시키면 어떤 모서리가 사라졌는지 알 수 없기 때문이다.
AI에게는 네 가지를 분리하게 한다.
| 반론 종류 | 질문 | 처리 방법 |
|---|---|---|
| 명시된 조건 위반 | RFP·일정·예산과 실제로 충돌하는가? | 근거 번호를 붙여 수정 |
| 근거 없는 가정 | 고객이 좋아할 것이라고 단정했는가? | 사실이 아니라 가설로 이동 |
| 설명 공백 | 아이디어와 목표 사이의 연결이 빠졌는가? | 한 문장으로 보완 |
| 단순한 낯섦 | 틀린 것이 아니라 익숙하지 않은 것인가? | 바로 삭제하지 않고 테스트 후보로 보존 |
AI의 반론도 정답은 아니다. 입력하지 않은 조건을 사실처럼 추가하거나, 흔한 업계 관행을 절대 규칙처럼 말할 수 있다. AI 답변 오류 검증 7단계에 따라 원문 조건과 출처를 다시 확인한다.
4단계: 반론을 모두 받아들이지 않는다
반론이 많다고 나쁜 아이디어는 아니다. 파격적인 안은 원래 설명할 것이 많고, 익숙한 안은 질문을 덜 받을 수 있다. 그래서 반론을 받은 뒤 후보를 바로 점수화하지 않는다.
먼저 각 반론에 라벨을 붙인다.
- 필수 수정: 명시된 요구, 사실, 법적·보안 조건과 충돌한다.
- 확인 필요: 고객 반응이나 운영 가능성을 아직 모른다.
- 남길 모서리: 낯설지만 목표와 충돌하지 않고 시험할 가치가 있다.
이 구분은 AI 제안서 아이디어 검증 기준표와 연결된다. 지킬 것, 번역할 것, 실험할 것을 나누면 “AI가 반대했다”가 아니라 “어떤 조건 때문에 바꿨는가”를 말할 수 있다.
5단계: 현장 근거 한 조각을 붙인다
AI가 만든 근거는 현장 근거가 아니다. 검색 결과 요약도 실제 고객이 이 아이디어를 좋아한다는 증거는 아니다. 후보마다 작은 확인 한 가지를 붙인다.
- 최근 문의나 후기에서 반복된 표현이 있는가?
- 고객이 제품을 사용하는 장면을 실제로 관찰했는가?
- 지난 캠페인에서 비슷한 형식이 어디에서 이탈했는가?
- 담당자가 현실적으로 운영할 수 있는가?
비공개 고객 자료를 외부 AI에 넣을 필요는 없다. 사람은 승인된 자료에서 패턴을 확인하고, AI에는 익명화한 구조나 합성 예시만 준다. 회사 정보를 AI에 넣기 전 체크리스트로 입력 가능 범위를 먼저 정한다.
6단계: 회의에는 네 칸짜리 결정표를 가져간다
긴 AI 대화 전체를 공유하면 팀원은 결론보다 로그를 읽느라 시간을 쓴다. 후보마다 아래 네 칸만 남긴다.
| 후보 | 이 안을 남긴 이유 | 아직 모르는 것 | 다음 확인 |
|---|---|---|---|
| A | 목표와 직접 연결되는 장면 | 고객이 이 상황을 자기 일로 느끼는지 | 5명에게 장면 설명 후 이해한 내용 듣기 |
| B | 브랜드의 기존 자산을 활용 | 형식이 너무 익숙한지 | 기존 성과 자료와 차별 요소 비교 |
| C | 가장 낯설고 공유 가능성이 있음 | 2주 안에 제작 가능한지 | 제작 담당자에게 최소 버전 견적 확인 |
회의의 목적은 완벽한 안을 고르는 것이 아니라 어떤 불확실성을 감수하고 무엇을 먼저 확인할지 결정하는 것이다. 회의가 끝나면 회의록을 결정·담당자·기한으로 정리하는 법에 따라 선택 이유와 다음 행동을 남긴다.
합성 사례: 웨비나 신청 캠페인을 준비한다면
가상의 B2B 협업 도구 ‘플로우픽’이 신규 고객용 웨비나를 연다고 가정해보자. 브랜드와 수치는 모두 설명을 위해 만든 합성 자료다.
회의의 출구는 “후보 세 개 중 작은 광고 소재로 확인할 한 개를 고른다”다. 사람이 먼저 낸 초안은 다음과 같다.
- A: 기능 10개를 10분 안에 소개하는 속도 중심 웨비나
- B: 팀장이 실제로 자주 놓치는 인수인계 장면을 고치는 웨비나
- C: 참가자가 자기 팀의 업무 한 가지를 현장에서 다시 설계하는 실습형 웨비나
AI의 1차 반론은 A가 구체적이지만 기능 나열로 끝날 수 있고, C는 참여 장벽이 높을 수 있다는 것이었다. 여기서 A와 C를 바로 버리면 안 된다. ‘끝날 수 있다’와 ‘높을 수 있다’는 모두 아직 확인하지 않은 가정이다.
팀은 B를 우선 후보로 남기되 “팀장이 다 놓친다”는 과장 표현을 삭제한다. C는 60분 전체 실습이 아니라 신청 페이지에서 5분 미리보기로 시험한다. A는 기능 수보다 한 장면을 빠르게 해결하는 형식으로 다시 써본다.
결과적으로 AI가 승자를 고른 것이 아니다. 조건 위반과 가정을 분리했고, 사람은 실제로 확인할 최소 버전을 정했다.
회의 시간이 줄었는지는 이렇게 계산한다
AI를 썼다는 사실만으로 효율이 생기지는 않는다. 준비 시간이 늘고 회의가 그대로라면 단지 일이 추가된 것이다.
절약 시간 = 기존 탐색 회의 시간 − (사전 정리 시간 + 결정 회의 시간)
예를 들어 기존에 90분씩 두 번 탐색 회의를 했다면 180분이다. 사전 정리에 45분, 결정 회의에 60분을 썼다면 계산상 75분이 줄었다. 다만 이 수치는 품질이나 성과를 증명하지 않는다. 수정 횟수, 선택 이유 기록 여부, 테스트 결과까지 함께 봐야 한다.
복사해서 쓰는 AI 브레인스토밍 반론 프롬프트
너는 아이디어를 대신 만드는 사람이 아니라 회의 전 검토 보조자다.
내 초안을 무난하게 다시 쓰지 말고, 원문을 보존한 채 검토하라.
[회의에서 결정할 것] [대상 고객] [공개 가능한 요구사항과 제약. R1, R2처럼 번호 부여] [사람이 먼저 쓴 후보 A, B, C]
후보마다 아래 표를 작성하라.
- 목표와 맞는 부분
- 명시된 조건을 어긴 부분과 근거 번호
- 사실처럼 적었지만 근거가 없는 가정
- 설명이 빠진 연결 고리
- 단지 낯설다는 이유로 반대할 가능성
- 핵심 모서리를 지키면서 작게 확인할 방법
RFP에 없는 조건은 새 요구사항처럼 만들지 마라. 예상 성과와 고객 반응을 지어내지 마라. 점수로 승자를 고르지 말고 사람이 결정해야 할 질문 세 개를 남겨라.</code></pre>
잘 안 되는 경우
- 사람이 아무 생각도 쓰지 않고 AI 목록에서 시작한다.
- ‘더 현실적으로’를 반복해 낯선 부분을 모두 제거한다.
- AI의 반론에 원문 근거가 없어도 받아들인다.
- 합성 사례를 실제 고객 반응이나 집행 결과처럼 쓴다.
- 회의가 끝났는데 담당자, 기한, 확인 방법이 없다.
보안과 저작권 주의
미공개 RFP, 고객사명, 예산, 일정, 계약 조건, 소비자 개인정보, 내부 제안서 원문은 회사가 승인하지 않은 외부 AI에 입력하지 않는다. 공개 가능한 요약과 합성 자료로 절차를 먼저 시험한다.
다른 사람의 캠페인이나 글에서 본 문장을 그대로 아이디어로 제출하지 않는다. 출처를 남기고, 무엇을 참고했고 무엇을 새로 판단했는지 구분한다. AI가 출처를 제시하더라도 실제 페이지에서 존재 여부와 맥락을 확인한다.
자주 묻는 질문
AI에게 아이디어를 먼저 받아도 되는 경우는 없나요?
분류명, 질문 후보, 반대 관점처럼 사고를 여는 재료는 먼저 받을 수 있다. 다만 브랜드의 핵심 콘셉트나 최종 방향처럼 개성이 필요한 결정은 사람의 초안을 먼저 남기는 편이 좋다.
몇 개의 아이디어를 준비해야 하나요?
정해진 정답은 없다. 초기 회의라면 서로 다른 방향 세 개면 비교가 가능하다. 후보 수를 늘리기보다 왜 다른지 설명할 수 있어야 한다.
AI가 RFP 위반이라고 하면 버려야 하나요?
먼저 RFP의 실제 문장과 번호를 확인한다. 명시된 필수 조건과 충돌하면 수정해야 하지만, AI가 추정한 관행이나 선호라면 가설로 돌려 사람에게 확인한다.
브레인스토밍 회의를 완전히 없앨 수 있나요?
없애는 것이 목표는 아니다. 탐색을 사전에 일부 진행해 회의에서 더 좋은 질문과 결정을 다루게 만드는 것이 목적이다. 이해관계가 다르거나 현장 정보가 흩어져 있다면 사람의 대화가 필요하다.
AI 초안을 받을 때마다 결국 처음부터 다시 고치고 있다면, 아이디어보다 업무 기준이 먼저 빠졌을 수 있다. 내 업무를 AI에게 인수인계할 수 있는지 10문항으로 점검하기에서 무료로 확인할 수 있다.
근거와 공식 출처
- 브런치: 가본 만큼만 내 땅이다—AI가 줄 수 없는 것 — AI를 회의 전 시뮬레이터로 사용하되 실제 경험과 오리지널리티를 대체하지 않는다는 운영자의 경험.
- 브런치: AI가 뭉뚝한 게 아니라, 내가 뭉뚝해지고 있었다 — 제안서 작업에서 사람의 날것 아이디어를 먼저 펼친 뒤 AI로 구체화하도록 순서를 바꾼 근거.
- Google Cloud: 프롬프트 설계 전략 — 목표·맥락·제약·예시를 구조화하고 반복 평가하는 방법의 기술적 참고.
- NIST: AI Risk Management Framework — AI 결과의 신뢰성과 위험을 조직적으로 검토하기 위한 자발적 프레임워크. 이 글의 캠페인 성과를 보증하는 자료는 아니다.
편집 안내: 운영자의 공개 브런치 경험을 출발점으로 삼았지만 문장을 복제하지 않았다. 단계, 표, 프롬프트와 ‘플로우픽’ 사례는 이 글을 위해 새로 만든 합성 자료다. 변동 가능한 AI 기능과 조직 정책은 실제 적용일에 다시 확인한다.