- 증상: AI에게 새 콘텐츠 채널 기획을 맡겼더니, 지금 운영 중인 채널의 컨셉을 그대로 씌운 기획안이 왔습니다 — 머릿속엔 “기존과는 별개”가 분명했는데요
- 원인: 그 “~와는 다른”이 프롬프트에 문장으로 적혀 있지 않았습니다. 대조 구문 속의 암시였고, 적히지 않은 부정형 조건은 AI에게 없는 조건이었어요
- 해결: 정정 2회 + 레퍼런스를 다시 읽히자 기획이 제자리를 찾았고, 이어서 AI가 자기 추천을 스스로 뒤집는 더 재밌는 일도 일어났습니다
혹시 이런 상황인가요?
AI에게 기획을 맡겨 보셨나요 — 새 프로젝트, 새 채널, 새 문서 구조 같은 것요. 요구사항을 길게 적어 줬는데, 돌아온 기획안이 어딘가 익숙합니다. 잘 만들긴 했는데, 지금 하고 있는 것의 복사본 같은 느낌. “새로운 걸 해 달라니까?”
저도 정확히 그걸 겪었습니다. 수학 과외를 하며 바이브코딩 오답노트 블로그(지금 읽고 계신 이곳)를 함께 꾸리고 있는데, 이것과는 별개로 정보 전달에 특화된 유튜브 중심 콘텐츠 파이프라인을 하나 더 만들고 싶었어요. 그래서 AI에게 평소 관심 있게 본 영상·기사 제목 목록을 주며 기획을 발주했습니다. 첫 프롬프트의 해당 대목 원문은 이랬습니다.
L2C가 바이브코딩 하면서 생기는 다양한 에피소드로 “바이브코딩 오답노트” 컨셉으로 워드프레스에 바이브코딩 개발기 또는 경험담을 제공한다면, 나와 같이 바이브코딩을 즐기는 사람들이 관심을 가질만한 소재로 사용법, 활용법, 진짜 힘순찐 기능 등 핵심 정보를 알기 쉽게 전달하는 정보전달에 특화된 유튜브 first 컨텐츠 파이프라인 구축을 하고자해.
오답 1 — 머릿속의 “~와는 다른”이 프롬프트엔 없었다
돌아온 기획안 v1은… “오답노트” 컨셉의 유튜브 채널이었습니다. 새 파이프라인에 기존 컨셉을 그대로 씌운 거죠. 저는 곧장 정정했습니다.
컨셉을 잘못잡았어. 내 최초 프롬프트를 보면, 오답노트 컨셉의 L2C와는 다른, 정보전달에 특화된 유튜브 first 컨텐츠 파이프라인 이라고 했어.
그런데 이 글을 쓰며 첫 프롬프트 원문을 다시 읽다가 머쓱해졌습니다. “와는 다른”이라는 말은 원문 어디에도 없어요. 위 인용을 다시 보세요 — “A를 제공한다면, B를 구축하고자 해”라는 대조 구문이 있을 뿐입니다. 제 머릿속에선 그 구문이 “별개의 것”을 뜻했지만, 문장으로는 “기존 오답노트 컨셉”이 새 기획의 배경 설명인지 분리 대상인지 적히지 않았던 거예요. 정정 프롬프트에서 제가 “~라고 했어”라고 우긴 것도, 실은 의도가 적혀 있었다고 기억이 조작된 쪽에 가깝습니다.
그래서 교훈은 처음 생각보다 한 칸 더 깊습니다. 암시된 부정형 조건은 AI에게 없는 조건입니다. 긍정형 요구(“유튜브 퍼스트”, “정보 전달 특화”)는 문장에 적혀 있었고 전부 반영됐어요. “무엇이 아니어야 하는가”는 문장 구조에 얹혀만 있었고, 통째로 증발했습니다. 그리고 그게 기획의 방향 전체를 결정했죠.
정정하면서 레퍼런스 블로그 링크 네 개를 주고 다시 기획하게 했더니 이번엔 제대로 왔습니다 — AI가 그중 열린 세 편을 분석해(한 편은 접속이 차단돼 못 읽었어요) 정보 전달 글의 DNA 5원칙(결론·수치 먼저 / 비유 한 줄 / 단계별 실습과 캡처 / 실측·비교표 / 바로 써먹기)을 뽑아 v2를 재설계했어요.
오답 2 — 첨부 이미지의 정체를 오독했다
같은 세션에서 하나 더 틀렸습니다. 저는 “이런 게 최종 목표”라는 뜻으로 17년 된 IT 블로그의 지표 화면을 첨부했는데, AI가 그걸 제 블로그 사례로 읽고 그 전제로 이야기를 이어간 거예요. 제 정정 원문은 이랬습니다.
그 이미지의 사례가 지금 구축하려는 유튜브 퍼스트 컨텐츠 파이프라인의 최종 목표라고 얘기한거야. 내가 17년동안 블로그를 운영한게 아니라!!
웃자고 옮겼지만 패턴은 진지합니다. 첨부 자료에는 세 가지 정체가 있어요 — 내 것 / 남의 것 / 목표로 삼는 것. 사람끼리는 맥락으로 구분되지만, AI에게는 첨부할 때 정체를 한 줄로 붙여 주지 않으면 셋 중 아무거나로 읽힙니다.
오답 3(인데 절반은 정답) — 추천이 같은 세션 안에서 뒤집혔다
기획이 자리 잡자 다음 결정이 왔습니다 — 새 파이프라인의 글은 어느 블로그에 실을 것인가. 재밌는 건 순서예요. AI는 처음엔 제가 갖고 있던 다른 블로그(티스토리)를 추천하지 않았는데, 제가 “추천 안 하는 이유가 뭐야?”라고 묻고, 그래도 그 블로그를 키우는 건 어떻겠냐고 한 번 더 밀어붙이자 우호적인 분석을 내놨습니다. 그런데 직후에, 제 다른 작업 기록(원장)을 읽다가 자기 분석과 충돌하는 맥락을 발견합니다 — 이 워드프레스 블로그가 애드센스 재신청 게이트(노출 지표) 앞에 있고, 가이드형 콘텐츠가 이 블로그의 최강 수익 축과 같은 방향이라는 기록이요. AI는 우호 분석을 밀어붙이는 대신 추천을 접고 판정을 저에게 넘겼고, 저는 결정을 다음 날로 미뤘습니다. 이틀 뒤 최종 결정은 “기존 블로그에 가이드 카테고리 신설 + 원고 납품”으로 났고요.
이 사건을 오답 목록에 넣을지 한참 고민했는데, 반은 오답이고 반은 모범이에요.
오답인 부분: 둘이 나눠 가졌습니다. AI는 추천을 내기 전에 원장을 먼저 읽었어야 했고 — AI가 모르는 맥락은 대화창이 아니라 기록에 있었으니까요 — 저는 원하는 답이 나올 때까지 두 번 되물었습니다. 내가 원하는 답을 물으면 AI는 그 답을 만들어 줍니다.
모범인 부분: 충돌을 발견한 순간 자기 분석을 붙들지 않고 접은 것. 수학으로 치면 검산에서 모순을 발견하고 답을 고친 셈이라, 혼낼 일이 아니라 칭찬할 일이더라고요.
이렇게 바꾸기로 했습니다 — 기획 발주 프롬프트에 세 가지를 추가
이 세 사건을 복기하고, 다음 기획 발주부터는 아래 세 줄을 붙이기로 했습니다. 복붙해서 쓰세요.
(기획 발주 프롬프트에 추가하는 세 줄)
1. 시작하기 전에, 내 요구사항 중 "무엇이 아니어야 하는지"(부정형 조건)를
너의 말로 다시 정리해서 보여줘. 그게 내 의도와 맞는지 확인받고 진행해.
2. 첨부 자료마다 정체를 표기해 뒀다: [내 것 / 남의 사례 / 목표].
표기가 없으면 진행 전에 물어봐.
3. 추천·결정을 내기 전에, 관련된 내 작업 기록([경로])을 먼저 읽어라.
기록과 네 추천이 충돌하면 추천을 내지 말고 충돌 지점을 보고해라.
1번이 핵심입니다. 부정형 조건은 일단 문장으로 적혀야 하고(암시는 조건이 아닙니다), 적었어도 복창으로 확인받아야 지켜집니다. 긍정형 요구는 산출물에 자연히 드러나서 틀리면 바로 보이는데, 부정형은 “안 한 것”이라 v1처럼 통째로 증발해도 발주자가 늦게 알아채거든요.
같은 실수를 막는 체크리스트
- 머릿속의 “~와는 다른“, “~는 빼고“가 프롬프트에 문장으로 적혀 있나요? 대조 구문·맥락에 암시로만 얹혀 있다면 그건 AI에게 없는 조건입니다 — 한 줄로 명시하고, 복창까지 시키세요
- 첨부한 이미지·링크·문서에 정체 표기(내 것/남의 사례/목표)를 붙였나요?
- 레퍼런스는 링크만 던지지 말고 “이 레퍼런스에서 무엇을 뽑았는지”를 먼저 보고하게 하세요 — 저희 v2가 산 것도 DNA 5원칙 추출부터였습니다
- AI에게 추천을 요구하기 전에, 판단에 필요한 기록을 먼저 읽혔나요? 대화창에 없는 맥락은 AI에게 없는 맥락입니다
- 추천이 뒤집히면 화내기 전에 — 뒤집은 근거가 어디 있었는지를 보세요. 그 자리가 다음부터 “먼저 읽힐 곳”입니다
자주 묻는 질문
Q. 부정형 조건을 왜 유독 잘 놓치나요?
두 겹입니다. 먼저 사람이 놓칩니다 — 머릿속에 선명한 의도일수록 “적었다”고 착각하기 쉬워요(제가 그랬듯요). 다음으로 AI가 놓칩니다 — 긍정형 요구는 산출물을 만드는 재료라 결과에 남는데, 부정형은 “만들지 말아야 할 것”이라 산출물 어디에도 흔적이 없거든요. 그래서 부정형만큼은 명시 + 복창의 이중 확인을 걸려는 겁니다.
Q. 정정 두 번이면 많이 틀린 것 아닌가요? 처음부터 사람이 기획하는 게 낫지 않나요?
정정 두 번에 든 시간보다, v2에서 AI가 레퍼런스 세 편을 해부해 원칙 다섯 개를 뽑아 온 시간 절약이 훨씬 컸습니다. 관건은 틀리느냐가 아니라 정정 비용이 싸게 설계돼 있느냐더라고요 — 첫 프롬프트를 남겨 뒀다가 “내 최초 프롬프트를 보면”으로 되짚을 수 있으면 정정은 한 줄이면 됩니다.
Q. AI가 자기 추천을 뒤집는 건 좋은 건가요, 불안한 건가요?
근거가 함께 오면 좋은 겁니다. 저희 사례에서 AI는 “무엇을 새로 읽었고 그게 추천과 어디서 충돌하는지”를 보고했고, 덕분에 저는 더 나은 정보로 결정할 수 있었어요. 불안한 쪽은 근거 없이 확신만 바뀌는 경우고, 그건 위 3번 줄(충돌 지점 보고)로 구분됩니다.
Q. 요구사항을 아무리 잘 써도 이런 일이 또 생기지 않나요?
생깁니다. 그래서 방어선을 프롬프트 품질이 아니라 확인 절차(복창·정체 표기·기록 선독)에 두려는 거예요. 잘 쓰는 것보다 잘 확인받는 게 오래갑니다.
한 줄 교훈
기획 위임에서 무너지는 자리는 화려한 요구가 아니라 적히지 않은 “~와는 다른” 한 마디입니다 — 부정형 조건은 문장으로 적어 복창시키고, 첨부물엔 정체를 붙이고, 추천 전엔 기록부터 읽히세요.