레퍼런스 50개를 모아도 기획이 안 되는 이유
이 글은 챗지피티와 클로드코드가 작성했습니다
1. 노션 폴더는 가득한데, 기획안은 비어 있다
노션에 폴더가 하나 있다. 이름은 '레퍼런스'.
안에는 스크린샷, 링크, 캡처한 카드뉴스가 수십 개 들어 있다. 경쟁사 블로그도 봤고, 해외 사례도 모았다. 잘 된 광고 카피도 저장해뒀다.
그런데 기획안을 열면 커서만 깜빡인다.
한 번이면 운이 나빴다고 할 수 있다. 반복된다면 문제는 자료의 양이 아니다.
나도 그랬다. 어떤 프로젝트에서 레퍼런스를 40개 넘게 모은 적이 있다. 3일 동안 자료를 모았는데, 막상 기획 회의에서 꺼낸 건 "아직 정리 중입니다"뿐이었다. 자료는 넘쳤는데 내 기획은 한 줄도 없었다. 그때 깨달았다. 수집과 기획 사이에 내가 뭔가를 빼먹고 있다는 걸.
2. '많이 본다'는 착각의 구조
"일단 많이 봐."
선배가 말했다. 유튜브 기획 강의도 같은 말을 한다. 그래서 봤다. 많이.
그런데 기획안은 안 나왔다.
"좋은 레퍼런스를 많이 보면 좋은 기획이 나온다"는 말은 틀린 건 아니다. 다만 빠진 게 있다. 레퍼런스를 보는 건 수용이다. 기획은 생성이다. 수용에서 생성으로 넘어가려면 다른 종류의 사고가 필요하다.
물론 레퍼런스를 많이 보는 것 자체가 나쁜 건 아니다. 업계의 흐름을 파악하거나, 감각을 유지하는 데는 분명 도움이 된다. 문제는 수집 만으로 기획이 완성된다고 착각하는 것이다.
많은 기획자가 수용 상태에서 곧바로 생성으로 넘어가려 한다. 재료를 사 놓고 손질 없이 바로 요리하려는 것과 같다. 손질하는 시간이 빠져 있다.
3. 빠진 단계 첫 번째: 해체
수집과 기획 사이에 빠진 첫 번째 단계는 해체다.
해체는 간단하다. 레퍼런스를 통째로 보지 말고, 부품으로 쪼개는 것이다.
경쟁사 블로그에서 잘 쓴 글을 하나 발견했다. 보통 어떻게 하는가?
"오, 좋다" → 저장 → 끝.
해체는 다르다.
- 이 글의 제목은 어떤 구조인가? (질문형? 숫자형? 반전형?)
- 도입부 3줄이 독자를 잡는 방식은? (공감? 통계? 에피소드?)
- 본문의 논리 전개 순서는? (문제→원인→해결? 통념→반박→대안?)
- 결론에서 독자에게 요구하는 행동은?
하나의 레퍼런스를 이렇게 4개 부품으로 쪼개면, 완성품이 아니라 조립 가능한 재료가 생긴다. 완성품만 쌓아두면 조립은 불가능하다. 부품이 있어야 내 것을 만들 수 있다.
4. 빠진 단계 두 번째: 질문
해체한 부품을 앞에 놓았다면, 다음은 질문이다.
"이 글은 왜 도입부에 통계를 넣었을까?"
"이 브랜드는 왜 고객 후기를 첫 문단에 배치했을까?"
"이 카피는 왜 혜택이 아니라 손실을 먼저 말할까?"
질문하는 순간, 레퍼런스가 감상에서 도구로 바뀐다.
"이 글 좋다"는 감상이다.
"왜 이 구조가 효과적이었을까"는 분석이다.
분석이 쌓여야 자기 기획에 적용할 수 있는 원리가 추출된다. 구체적으로 보자.
감상 (해체 전) → 분석 (해체 + 질문 후)
"이 블로그 글 잘 썼네" → "도입부에서 독자의 잘못된 믿음을 건드린 뒤, 3문단 안에 반전 데이터를 제시하는 구조가 효과적이다"
"이 광고 카피 센스 있다" → "혜택보다 손실을 먼저 언급해서 손실 회피 심리를 자극한 구조다" |
"이 뉴스레터 재밌다" → "본문을 질문 3개로 나누고, 각 질문에 한 문단씩만 답하는 형식이 가독성을 높인다"
왼쪽은 저장만 된다. 오른쪽은 기획에 쓸 수 있다.
5. 질문에서 기획으로 — 재조립
해체하고 질문했다면, 이제 재조립할 차례다.
재조립이란 남의 부품에서 뽑아낸 원리를 내 맥락에 맞게 새로 배열하는 것이다. 핵심은 '내 맥락'이다. 레퍼런스의 구조를 그대로 베끼면 짝퉁이 된다. 내 독자, 내 메시지, 내 채널의 조건에 맞게 부품을 재배치해야 한다.
실제 예시로 보자.
해체에서 뽑은 원리: "도입부에 반직관적 질문을 던지면 독자의 관심을 잡을 수 있다."
내 글의 주제: 이메일 마케팅
재조립 결과: "이메일 제목에 이모지를 넣으면 오픈율이 올라간다고요? 실제 데이터는 정반대를 가리킵니다."
원리는 빌려왔지만, 주제와 문장은 내 것이다.
이 과정을 거치면 기획은 빈 화면에서 시작하는 게 아니라, 재료가 놓인 테이블 위에서 시작하는 것이 된다.
6. 실전 루틴: 레퍼런스 3개로 기획 1개 뽑기
50개를 전부 해체할 필요는 없다. 실전에서는 3개면 충분하다.
루틴:
1. 주제와 관련된 레퍼런스 3개를 고른다
- 잘 된 것 2개 + 아쉬운 것 1개
2. 각각 4가지 부품으로 해체한다
- 제목 구조 / 도입 방식 / 논리 전개 / 결론 행동
3. 부품마다 "왜?"를 한 번씩 묻는다
4. 내 독자와 메시지에 맞게 부품을 재배치한다
5. 재배치한 결과가 곧 기획안의 아웃라인이 된다
소요 시간? 빠르면 20분, 느려도 40분.
레퍼런스 50개를 스크롤하며 "뭔가 좋은 게 있었는데..."를 반복하는 2시간과 비교해 보라.
시연: 레퍼런스 3개 → 기획 아웃라인
→ 내 기획에 적용:
- 제목: 질문형 + 반전 ("레퍼런스 50개를 모아도 기획이 안 되는 이유")
- 도입: 독자의 잘못된 믿음 지적 ("많이 보면 된다는 착각")
- 전개: 통념→반박→실전 루틴
- 결론: 구체적 행동 하나 제시
이렇게 기획 아웃라인이 나온다. 빈 화면에서 짜낸 게 아니라, 부품에서 조립한 것이다.
7. 오늘부터 바꿀 한 가지
수집은 '일한 느낌'을 준다. 좋은 자료를 저장하면 "나 오늘 리서치 했다"는 만족감이 든다.
하지만 그건 기획한 게 아니라 기획을 미룬 것이다.
오늘부터 한 가지만 바꿔보자.
레퍼런스를 저장할 때, 옆에 메모 한 줄을 추가한다.
"이 레퍼런스에서 내가 가져갈 부품은 ___이다."
이 한 줄이 수집을 해체로 전환시키는 트리거가 된다. 필자도 이 습관을 들인 뒤, 기획안 앞에서 멈추는 시간이 눈에 띄게 줄었다.
레퍼런스 폴더는 박물관이 아니라 부품 창고여야 한다.
저장하는 순간 한 줄을 쓸 것인가, 말 것인가. 그 차이가 수집가와 기획자를 가른다.
이 글은 클로드코드 에이전트 팀을 실험하기 위해 클로드코드로 작성한 글입니다.
챗지피티가 블로그 글 작성 에이전트 팀을 구성하는 프롬프트를 작성해줬고 클로드코드가 이를 실행해 작성해줬습니다.
제가 한 건 챗지피티한테 프롬프트 만들어달라 하고 클로드코드한테 이걸 실행해달라고 한 것 뿐입니다
ai로 글을 작성한 결과물은 대부분 단락별 맥락을 잘 살리지 못하고 각 단락과 단락이 분절된 느낌을 주기 때문에 단락별로 생성 또는 수정을 거쳐야 합니다. 그런데 이 글은 그래도 나름대로 브릿지 문장을 잘 넣고 있네요.
이 글은 어떤 수정도 하지 않았습니다. 에이전트 팀 구성 프롬프트조차 수정하지 않았습니다.
ai가 쓴 글을 구분할 수 있다고 생각하는 분들도 있지만, 우리는 이미 그럴 수 없는 시대에 살고 있습니다. 물론 티가 나는 글들이 있고, ai가 생성한 글을 걸러내려는 움직임도 있습니다. 하지만 티나지 않게 하는 방법도 얼마든지 있을 것는데 그걸 안하는 것일 뿐일 테고요, 기술적으로 ai 워터마크를 100% 잡아내는 건 언제 어떻게 가능한 건지는 제가 잘 알지 못합니다. 하여간 뭐.. 저는 ai 생성 글과 사람 작성 글을 완벽하게 구분하지 못할 수 있다고 생각하고, 구분 자체가 의미 없는 상황이 있으며, 언젠가는 정말로 의미가 없어질 거라 생각합니다.
여튼 ai가 생성한 글에 대해 실험하려던 건 아니고
에이전트 팀을 한번 써보고 싶었던 건데 요거 잘쓰면 너무 편하겠네요 세상이 정말 빠르게 변하고 있습니다
