ChatGPT 프롬프트 2026: '단계별로 생각해'가 이제 안 먹히는 이유 — 추론 모델에 맞게 다시 쓰는 법

ChatGPT 프롬프트
Photo by Hassan Pasha on Unsplash

한동안 ChatGPT 프롬프트를 잘 쓰는 요령이라며 돌아다닌 문장이 있습니다. "단계별로 생각해 봐(Let's think step by step)", "이유를 먼저 설명하고 답해 줘" 같은 것들이죠. 실제로 예전 모델에서는 이 한 줄을 붙이는 것만으로 답이 눈에 띄게 정돈됐습니다. 그런데 요즘 같은 문장을 붙였는데 답이 딱히 나아지지 않거나, 오히려 서론만 길어지고 결론은 흐릿해지는 경험을 하신 분들이 있을 겁니다.

프롬프트 실력이 퇴보한 게 아닙니다. 상대하는 모델의 종류가 바뀐 겁니다. 이 글에서는 왜 예전 요령이 힘을 잃었는지, 그리고 지금의 ChatGPT 프롬프트를 어떻게 다시 써야 하는지를 정리합니다.

지금 ChatGPT 프롬프트가 겉도는 진짜 이유

가장 큰 변화는 모델이 한 종류가 아니게 됐다는 점입니다. 본 글 작성 시점(2026년 8월) 기준으로 ChatGPT의 모델 선택기는 크게 Instant 계열Thinking 계열로 나뉘고, 상위 요금제에는 Pro 계열이 따로 있습니다. OpenAI 헬프센터 안내에 따르면 Instant는 일상적인 질문에 빠르게 답하는 쪽, Thinking은 복잡한 작업을 위해 더 깊게 추론하는 쪽입니다. Plus·Pro·Business 같은 유료 요금제에서는 이 선택기로 직접 고를 수 있습니다.

같은 지시가 모델에 따라 정반대로 작동한다

여기서 문제가 생깁니다. "단계별로 생각해"라는 지시는 스스로 추론하지 않는 모델에게 추론 과정을 밟게 만드는 장치였습니다. 그런데 추론(Thinking) 계열 모델은 답을 내놓기 전에 내부적으로 이미 그 과정을 밟습니다. 이미 하고 있는 일을 다시 시키는 셈이니 효과가 없거나, 답변 앞부분에 불필요한 설명만 늘어놓게 만듭니다.

이건 개인적인 감상이 아니라 공식 문서에 적힌 내용입니다. OpenAI의 추론 모델 모범 사례(Reasoning best practices) 문서는 추론 모델이 내부적으로 추론을 수행하기 때문에 "단계별로 생각해라"거나 "네 추론 과정을 설명해라" 같은 프롬프트가 불필요하다고 안내합니다. 예전 요령이 틀렸다기보다, 그 요령이 필요했던 조건이 사라진 것입니다.

추론 모델에 맞게 바꿔야 할 3가지

1. 사고 과정을 유도하는 문장은 걷어낸다

"천천히 단계별로", "먼저 논리를 세운 다음", "깊이 생각해서" 같은 유도 문구부터 지웁니다. 그 자리에 넣어야 할 것은 사고 방식이 아니라 판단 기준입니다. 예를 들어 "꼼꼼하게 검토해 줘" 대신 "빠진 항목, 숫자가 맞지 않는 부분, 근거가 없는 주장 이렇게 세 가지만 짚어 줘"라고 쓰는 식입니다. 어떻게 생각할지는 모델에게 맡기고, 무엇을 판단 대상으로 삼을지만 지정하는 겁니다.

2. 예시부터 잔뜩 붙이지 않는다

출력 형식을 잡으려고 예시를 두세 개씩 붙이는 방식은 여전히 유효한 기법이지만, 추론 모델에서는 우선순위가 달라집니다. 같은 OpenAI 문서는 추론 모델이 좋은 결과를 내는 데 예시(few-shot)가 필요하지 않은 경우가 많으니 먼저 예시 없이 써보라고 권합니다. 결과가 기대에 못 미칠 때 예시를 추가하는 순서가 낫다는 뜻입니다.

순서를 뒤집으면 실익이 큽니다. 예시를 만드는 데 드는 시간이 줄고, 무엇보다 예시가 답변의 폭을 좁혀버리는 부작용을 피할 수 있습니다. 예시를 세 개 주면 모델은 그 세 개와 비슷한 답을 안전하게 고르는 경향이 있으니까요.

3. 프롬프트를 짧고 직접적으로 줄인다

"~하지 마", "반드시 ~해야 해" 같은 제약을 겹겹이 쌓은 긴 프롬프트는 추론 모델에서 오히려 방해가 되기 쉽습니다. 같은 제약을 표현만 바꿔 세 번 반복하면 모델은 그 제약을 지키는 데 자원을 쓰느라 정작 문제 자체는 얕게 다룹니다. 요구사항을 한 번씩만, 명확한 문장으로 적는 편이 낫습니다.

오늘 바로 적용하는 4단계

이론보다 순서가 중요합니다. 다음 네 단계로 정리해 보세요.

  1. 작업을 분류한다 — 지금 시키려는 일이 "빠른 처리"인지 "정확한 판단"인지 먼저 구분합니다.
  2. 모델을 고른다 — 선택기를 열어 직접 지정합니다. 자동에 맡기면 어떤 성격의 모델이 답했는지 모른 채 프롬프트만 탓하게 됩니다.
  3. 추론 모델이면 프롬프트를 깎는다 — 사고 유도 문장과 예시를 빼고, 목표·제약·판단 기준만 남깁니다.
  4. 부족한 부분만 되붙인다 — 형식이 안 맞으면 그때 예시 하나, 톤이 안 맞으면 그때 톤 지시 한 줄을 추가합니다.

작업 유형별로 어느 쪽을 쓸까

작업 적합한 쪽 프롬프트 요령
번역·요약·문장 다듬기 Instant 계열 예시로 형식 고정이 여전히 유효
이메일 초안·아이디어 나열 Instant 계열 톤과 분량을 구체적으로 지정
계약서·자료 검토, 오류 찾기 Thinking 계열 사고 유도 문장 제거, 판단 기준 제시
복잡한 계획 수립, 코드 설계 Thinking 계열 예시 없이 목표·제약만 먼저

실제로 이렇게 깎입니다

말로만 보면 감이 잘 안 오니, 흔히 쓰는 자료 검토 프롬프트를 예로 들어보겠습니다. 예전 방식은 대개 이런 모양입니다.

너는 20년 경력의 전문 컨설턴트야. 아래 기획안을 아주 깊이, 단계별로 차근차근 생각해서 검토해 줘. 먼저 전체 구조를 파악하고, 그다음 논리를 하나씩 따져보고, 마지막에 결론을 내려 줘. 절대 대충 답하지 마. 반드시 꼼꼼하게 봐야 해.

여기서 실제 정보를 담고 있는 문장은 "기획안을 검토해 줘" 하나뿐입니다. 나머지는 모두 사고 과정을 유도하거나 같은 요구를 표현만 바꿔 반복하는 문장이죠. 추론 모델 기준으로 다시 쓰면 이렇게 짧아집니다.

아래 기획안을 검토해 줘. 세 가지만 짚어 줘. (1) 근거 없이 단정한 주장, (2) 앞뒤 숫자가 맞지 않는 부분, (3) 실행 단계가 빠진 항목. 각 항목은 원문 인용 한 줄과 수정 제안 한 줄로.

길이는 절반 이하로 줄었는데 돌아오는 답은 더 쓸 만해지는 경우가 많습니다. 역할 부여와 사고 유도를 걷어낸 자리에 무엇을 볼지어떤 형태로 돌려줄지가 들어갔기 때문입니다. 프롬프트를 줄인다는 건 대충 쓰라는 뜻이 아니라, 모델이 이미 알아서 하는 일을 지시에서 빼고 그 자리에 판단 기준을 넣는다는 뜻입니다.

되묻기를 다루는 방법

추론 모델을 쓰다 보면 답 대신 질문이 돌아오는 경우가 있습니다. "절대 되묻지 마"라고 못 박기보다, 되물을 조건을 정해 주는 편이 낫습니다. "답이 크게 달라질 정보가 빠졌을 때만 한 번 물어보고, 그렇지 않으면 합리적인 가정을 적고 진행해 줘"처럼요. 금지 대신 기준을 주는 것이 이 글 전체를 관통하는 원칙이기도 합니다.

결론: 프롬프트를 늘리기 전에 모델부터 확인하기

ChatGPT 프롬프트가 안 먹힌다고 느낄 때 우리는 보통 문장을 더 붙입니다. 조건을 추가하고, 예시를 넣고, 강조 표시를 씁니다. 하지만 상대가 추론 모델이라면 그 방향은 대체로 역효과입니다. 지금 필요한 건 더 긴 프롬프트가 아니라, 어떤 모델과 대화하고 있는지 아는 것덜어낼 용기입니다.

오늘 자주 쓰는 프롬프트 하나를 열어서, "단계별로 생각해" 같은 문장을 지우고 Thinking 계열 모델에 한 번만 다시 넣어보세요. 무엇을 빼도 되는지가 그 한 번으로 꽤 분명해집니다.

※ 본 글의 모델 구성·요금제 정보는 작성 시점(2026년 8월) 기준이며, 서비스 정책은 수시로 바뀔 수 있습니다.

AI 글쓰기 도구 2026: 초안은 빨라졌는데 내용이 기억 안 난다면 — 순서만 바꿔도 달라지는 것

AI 글쓰기 도구
Photo by Kelly Sikkema on Unsplash

AI 글쓰기 도구를 쓰기 시작한 뒤로 초안 잡는 시간은 확실히 줄었습니다. 그런데 이상한 경험을 한 적 없으신가요. 어제 발행한 글의 내용을 누가 물었는데 바로 대답이 안 나오는 순간 말입니다. 분명 내 이름으로 나간 글인데, 어느 문단에 무슨 근거를 썼는지 기억이 흐릿합니다. 글은 빨리 나왔는데 머릿속에는 남은 게 없는 겁니다.

이건 게으름이나 기억력 문제가 아닐 수 있습니다. 최근 뇌파를 측정해 이 현상을 관찰한 연구가 있고, 흥미롭게도 그 연구는 "AI를 쓰지 마라"가 아니라 "쓰는 순서를 바꿔라"에 가까운 힌트를 남겼습니다.

초안은 빨라졌는데 왜 내 글 같지 않을까

AI에게 초안을 시키면 대개 이런 흐름이 됩니다. 주제를 던지고, 나온 결과를 읽고, 어색한 곳을 고칩니다. 이 과정에서 내가 실제로 한 일은 판단입니다. 좋은지 나쁜지 고르는 일이죠. 반면 빈 화면 앞에서 직접 쓸 때 하는 일은 생성입니다. 무엇을 말할지 스스로 끌어내야 합니다.

판단과 생성은 들이는 품이 다릅니다. 그리고 이 차이가 글의 완성도가 아니라 글쓴이에게 남는 것에서 벌어진다는 게 문제의 핵심입니다. 결과물만 놓고 보면 AI를 쓴 글이 더 매끈할 때도 많습니다. 맞춤법도 정확하고 문단 길이도 고릅니다. 그래서 문제를 알아채기가 오히려 어렵습니다. 눈에 보이는 산출물에는 이상이 없으니까요.

차이가 드러나는 순간은 따로 옵니다. 누가 그 글에 대해 질문할 때, 후속 글을 이어 써야 할 때, 몇 달 뒤 같은 주제를 다시 다뤄야 할 때입니다. 그때 내가 쓴 글을 처음부터 다시 읽어야 한다면, 그 글은 쓰이는 동안 내 안에 별로 남지 않았다는 뜻입니다.

AI 글쓰기 도구를 쓸 때 실제로 관찰된 것

MIT 미디어랩 연구진은 참가자 54명을 세 그룹으로 나눠 에세이를 쓰게 하고 뇌파(EEG)를 측정했습니다. LLM만 쓰는 그룹, 검색엔진만 쓰는 그룹, 아무 도구 없이 쓰는 그룹이었습니다. 세션은 넉 달에 걸쳐 진행됐고, 한 편당 주어진 시간은 20분이었습니다. 논문 제목은 "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task"입니다.

세 그룹에서 갈린 지점

구분 뇌 연결성 자기 글 소유감
도구 없이 쓴 그룹 가장 강하고 넓게 분포 가장 높음
검색엔진 그룹 중간 수준 중간
LLM 그룹 가장 약함 가장 낮음

특히 눈에 띄는 대목은 인용 능력이었습니다. LLM 그룹은 몇 분 전에 자기가 쓴 에세이를 정확히 인용하는 데 어려움을 겪었습니다. 방금 자기 손을 거쳐 나간 문장인데도 말이죠. 연구진은 이렇게 누적되는 격차를 '인지적 부채(cognitive debt)'라고 불렀습니다. 당장은 편하지만 나중에 갚아야 할 것이 쌓인다는 뜻입니다.

검색엔진 그룹이 중간에 놓였다는 점도 시사적입니다. 검색도 남이 쓴 글을 가져오는 행위지만, 여러 결과 중 무엇을 볼지 고르고 읽어서 내 문장으로 옮기는 과정이 중간에 남아 있습니다. 그 남아 있는 과정만큼 차이가 벌어졌다고 볼 여지가 있습니다.

순서를 바꾼 네 번째 세션

가장 눈여겨볼 부분은 마지막 세션입니다. 연구진은 그동안 LLM을 쓰던 사람을 도구 없는 조건으로(LLM-to-Brain), 도구 없이 쓰던 사람을 LLM 조건으로(Brain-to-LLM) 서로 바꿨습니다.

결과가 대칭적이지 않았습니다. LLM만 쓰다 맨손으로 넘어간 쪽은 알파·베타 대역 연결성이 낮게 나타나 참여도가 떨어진 모습을 보였습니다. 반대로 직접 쓰다가 LLM으로 넘어간 쪽은 기억 회상 점수가 더 높았고, 후두정엽·전전두엽 영역의 활성이 함께 올라갔습니다. 같은 도구를 써도 어떤 순서로 만났는지에 따라 남는 것이 달랐다는 이야기입니다.

이 대목이 실용적으로 중요한 이유가 있습니다. 대부분의 조언은 "AI를 덜 써라" 쪽으로 흐르는데, 이건 현실적이지 않습니다. 마감은 그대로고 쓸 글은 쌓여 있으니까요. 반면 순서를 바꾸는 건 추가 비용이 거의 들지 않습니다.

다만, 이 연구를 과신하지는 마세요

본 글 작성 시점 기준으로 이 논문은 2025년 6월 공개된 프리프린트이며 동료 심사를 거치지 않았습니다. 그룹당 인원이 18명 수준이고, 조건을 맞바꾼 네 번째 세션은 완주자가 18명뿐이라 그룹당 9명 남짓입니다. 충분한 검정력을 확보하려면 참가자가 훨씬 더 많아야 한다는 지적도 나왔습니다. 20분이라는 제한 시간이 복사·붙여넣기를 부추겼을 수 있다는 비판도 있습니다.

그러니 "AI를 쓰면 뇌가 나빠진다"고 단정할 근거는 아닙니다. 다만 순서를 바꿔볼 만하다는 실마리로는 충분히 쓸 만합니다. 어차피 돈이 드는 실험도 아니니까요.

오늘부터 바꿔볼 수 있는 5가지

1. 5분 먼저 쓰고 나서 AI를 켠다

완성된 문장일 필요 없습니다. 하고 싶은 말을 메모 형태로 5분만 먼저 적어보세요. 그다음 AI에게 넘깁니다. 순서만 바뀌었을 뿐인데 AI가 내놓은 초안을 읽는 눈이 달라집니다. 이미 내 안에 기준이 생긴 상태에서 읽기 때문입니다. "이건 내가 하려던 말이 아닌데"라는 판단이 그제야 가능해집니다. 반대로 아무 생각 없이 초안부터 받으면, 화면에 뜬 문장이 곧 기준이 되어버립니다.

2. 구조는 내가, 문장은 AI에게

목차와 각 꼭지에서 할 말은 직접 정하고, 그 뼈대를 준 뒤 살을 붙이게 하세요. 반대로 하면 글의 논리가 내 것이 아니게 되고, 나중에 반박이 들어왔을 때 방어할 근거가 내 머릿속에 없습니다. 문장을 다듬는 일은 맡겨도 큰 손해가 없지만, 무엇을 말할지 정하는 일까지 넘기면 남는 게 급격히 줄어듭니다.

3. 맡길 글과 직접 쓸 글을 미리 나눈다

모든 글에 같은 방식을 적용할 필요는 없습니다. 회의록 정리, 정형화된 안내문, 형식이 정해진 이메일처럼 남아야 할 것이 별로 없는 글은 마음 편히 맡기세요. 반대로 내 전문 분야를 정리하는 글, 반복해서 다룰 주제, 나중에 남 앞에서 설명해야 할 내용은 직접 쓰는 비중을 높이는 편이 낫습니다. 시간을 아낄 곳과 남길 곳을 구분하는 것만으로도 부채가 쌓이는 속도가 달라집니다.

4. 발행 전에 원문을 보지 않고 요약해본다

초안을 덮고 이 글의 핵심을 세 문장으로 말해보세요. 막힌다면 그 부분은 아직 내 것이 아니라는 신호입니다. 위 연구에서 LLM 그룹이 자기 글을 인용하지 못했던 상황과 정확히 같습니다. 전부 다시 쓸 필요는 없고, 막힌 그 대목만 직접 손보면 됩니다. 1분이면 끝나는 점검이지만 효과는 분명합니다.

5. 사실 확인은 반드시 사람이 한다

수치, 법령, 제품 사양처럼 틀리면 곤란한 정보는 AI 출력을 그대로 두지 말고 1차 출처를 직접 확인하세요. 소유감이 낮은 글일수록 검증도 대충 넘어가기 쉽습니다. 내 글이라는 감각이 옅으면 틀렸을 때의 부담도 옅게 느껴지기 때문입니다. 특히 세무·법률·의료처럼 판단이 걸린 주제라면 전문가 상담을 함께 권하는 편이 안전합니다.

결론: 도구가 아니라 순서의 문제

AI 글쓰기 도구는 초안 시간을 줄여주는 확실한 수단입니다. 문제는 도구 자체가 아니라, 아무것도 떠올리지 않은 상태에서 도구를 먼저 켜는 습관입니다. 넉 달간의 뇌파 기록이 남긴 힌트도 결국 그것이었습니다. 같은 도구라도 내가 먼저 생각한 뒤에 만나면 다르게 작동한다는 것.

오늘 쓸 글부터 딱 5분만 먼저 손으로 적어보고 AI를 켜보세요. 바뀌는 건 순서 하나뿐이지만, 한 달 뒤 내 안에 남아 있는 것은 꽤 달라져 있을 겁니다.

n8n 워크플로우 2026: 워크플로우를 공유했는데 API 키까지 넘어갔다면 — 내보내기에 남는 것과 안 남는 것

n8n 워크플로우
Photo by Growtika on Unsplash

자동화를 몇 개 만들어두면 언젠가는 n8n 워크플로우를 밖으로 꺼낼 일이 생깁니다. 혹시 몰라 JSON으로 내려받아 백업해두거나, 동료에게 "이거 그대로 가져다 쓰면 돼" 하고 파일을 넘기거나, 블로그나 깃허브에 예시로 올리기도 하죠. 그때 거의 항상 따라오는 찜찜함이 하나 있습니다. "여기 물려 있던 API 키도 같이 딸려 나가는 거 아닌가?"

결론부터 말하면 파일 쪽은 생각보다 안전하고, 정작 신경 써야 할 곳은 다른 데 있습니다. 2026년 8월에 공개된 조사 하나가 그 지점을 꽤 선명하게 보여줬거든요. 이 글은 본 글 작성 시점(2026년 8월) 기준으로, 내보내기 파일에 실제로 무엇이 남는지와 진짜 새는 통로가 어디인지를 정리합니다.

내보낸 n8n 워크플로우 JSON에는 무엇이 남을까

먼저 오해부터 풀고 가죠. n8n에서 워크플로우를 내보내면 자격증명(Credentials)의 실제 값은 파일에 들어가지 않습니다. API 키나 비밀번호 같은 알맹이는 빠지고, 그 자격증명의 이름과 ID만 참조로 남습니다. 워크플로우가 "어떤 자격증명을 쓰는지"는 알아야 하니 껍데기만 남겨두는 구조입니다.

이건 n8n이 자격증명을 다루는 방식과 이어집니다. 사용자가 키를 입력해 저장하면 n8n은 그 값을 암호화해서 데이터베이스에 넣고, 화면에는 실제 값 대신 가려진 표시만 보여줍니다. 워크플로우가 돌 때만 뒤에서 진짜 값을 꺼내 쓰죠. 그러니 노드 화면에 키가 안 보인다고 해서 이상한 게 아니라, 원래 그렇게 설계된 겁니다.

다만 파일에도 빈틈이 두 군데 있습니다.

  • 자격증명 이름 — ID 자체는 민감하지 않지만, 이름은 어떻게 지었느냐에 따라 민감할 수 있습니다. "회사이름_운영서버_관리자계정" 같은 작명은 그 자체가 내부 정보를 흘립니다.
  • cURL로 붙여넣은 HTTP Request 노드 — 이게 실질적으로 가장 흔한 사고 지점입니다. cURL 명령을 그대로 가져와 만든 노드에는 인증 헤더가 노드 설정 안에 텍스트로 박혀 있을 수 있습니다. 자격증명 기능을 거치지 않았으니 암호화 대상이 아니고, 내보내면 그대로 따라 나갑니다.

n8n 공식 문서도 내보내기·가져오기 안내에서 이 부분을 짚으며, 공유 전에 해당 정보를 지우거나 익명화하라고 권합니다. 정리하면 "자격증명에 제대로 넣은 키는 안전하고, 노드에 직접 타이핑한 키는 위험하다"가 됩니다.

진짜 새는 통로는 파일이 아니라 인스턴스였다

파일보다 훨씬 크게 뚫린 쪽은 인스턴스 자체입니다. 2026년 8월 보안 업체 GitGuardian이 공개한 조사가 이걸 보여줬습니다. 연구진은 공개된 깃허브 커밋에 노출된 n8n API 토큰을 모아 검증했는데, 수집된 토큰은 4,576개, 함께 딸려 나온 호스트명은 1,255개였습니다.

여기서 실제로 접속이 되는 인스턴스가 896곳이었고, 그중 321곳이 유출된 토큰을 여전히 그대로 받아들였습니다. 도달 가능한 인스턴스의 약 36%죠. 이 숫자에서 눈여겨볼 대목은 따로 있습니다. 보도에 따르면 이건 소프트웨어 취약점을 뚫은 게 아니었습니다. CVE도 없었고요. 유효한 키 하나면 API 경계를 그냥 넘어갔습니다.

토큰이 통과하면 워크플로우, 실행 기록, 변수, 그리고 저장된 자격증명에 관한 정보까지 들여다볼 수 있습니다. 워크플로우 하나가 아니라 그 인스턴스가 연결해둔 서비스 전체가 사정권에 들어가는 셈입니다. 자동화는 원래 여러 서비스를 한데 묶는 도구라, 한 곳이 열리면 뒤에 달린 것들이 줄줄이 따라옵니다.

암호화 키가 지켜주는 범위

셀프호스팅을 쓴다면 암호화 키도 알아둘 만합니다. n8n은 자격증명을 DB에 저장하기 전 암호화하는데, 이때 쓰는 키를 첫 실행 때 자동으로 만들어 ~/.n8n 폴더에 저장합니다. 직접 정하고 싶으면 N8N_ENCRYPTION_KEY 환경변수로 지정하면 되고, 큐 모드로 워커를 여러 개 띄운다면 메인과 모든 워커가 같은 값을 공유해야 합니다.

중요한 건 이 키의 한계입니다. 암호화 키는 DB 파일이 통째로 새어 나갔을 때를 막아주는 장치이지, 정상적인 API 요청을 걸러주지는 않습니다. 유효한 토큰으로 들어온 요청은 n8n 입장에서 그냥 정상 사용자니까요. 위의 321곳이 뚫린 이유가 정확히 이겁니다.

공유·백업 전에 점검할 4가지

점검 항목 확인할 것
HTTP Request 노드 cURL로 만든 노드에 인증 헤더가 남아 있는지
자격증명 이름 이름만 봐도 내부 정보가 드러나지 않는지
API 토큰 코드·설정 파일에 적어둔 채 커밋하지 않았는지
인스턴스 노출 주소가 외부에 공개된 적이 있는지

1. 키는 반드시 자격증명으로 넣으세요. 급하다고 노드 필드에 직접 타이핑하면 암호화 대상에서 빠지고, 내보내기·스크린샷·화면 공유 모두에서 그대로 노출됩니다. cURL 임포트로 만든 노드는 특히 한 번 더 열어보세요.

2. 내보낸 JSON은 열어서 훑어보세요. 파일을 넘기기 전에 에디터로 열고 Authorization, api_key, token, Bearer 정도만 검색해봐도 큰 사고는 대부분 걸러집니다. 30초면 끝나는 일입니다.

3. API 토큰을 코드에 적어두지 마세요. 위 조사에서 토큰이 새어 나온 경로가 바로 공개 깃허브 커밋이었습니다. 실수로 커밋했다가 나중에 지워도, 커밋 기록에는 남습니다. 이미 올라간 적이 있다면 지우는 것보다 토큰을 새로 발급받아 갈아끼우는 편이 확실합니다.

4. 인스턴스 주소를 아무 데나 흘리지 마세요. 토큰과 주소가 함께 노출되면 그 조합만으로 접근이 가능해집니다. 굳이 외부에서 접속할 일이 없다면 공개 노출 자체를 줄이는 게 가장 단순한 방어입니다.

정리

n8n 워크플로우를 공유할 때 파일 자체는 꽤 잘 막혀 있습니다. 자격증명에 제대로 넣은 키라면 내보내기 파일에 실제 값이 들어가지 않으니까요. 문제가 생기는 지점은 늘 그 규칙을 우회한 자리 — 노드에 직접 적어둔 키, 그리고 코드에 남겨둔 API 토큰입니다.

이번 조사에서 확인된 321곳도 정교한 공격을 당한 게 아니라, 어딘가에 적어둔 키가 공개된 곳에 남아 있었을 뿐이었습니다. 자동화가 편리한 만큼 한 번 열리면 뒤에 묶인 서비스가 함께 노출된다는 점도 같이 기억해둘 만합니다.

오늘 만들어둔 워크플로우 중 하나만 골라 JSON으로 내보낸 뒤 Authorization으로 한 번 검색해보세요. 아무것도 안 나오면 그대로 두면 되고, 뭔가 나온다면 지금이 고칠 때입니다.

Make 자동화 2026: 알림 하나에 행이 두 줄 쌓인다면 — 중복 실행을 막는 데이터 스토어 4단계

Make 자동화 중복 실행 방지 워크플로우
Photo by Team Nocoloco on Unsplash

주문 알림 하나가 들어왔는데 슬랙에는 메시지가 두 번 뜨고, 스프레드시트에는 똑같은 행이 두 줄 쌓입니다. 시나리오를 열어보면 에러 표시는 하나도 없습니다. 실행 기록에도 "성공"이라고 찍혀 있고요. Make 자동화를 쓰다 보면 거의 누구나 한 번쯤 만나는 상황입니다. 문제는 이게 에러가 아니라서 알림도 안 오고, 며칠 뒤 데이터를 정리하다가 뒤늦게 발견한다는 점입니다.

고장 난 시나리오는 고치면 되지만, 정상 작동하면서 같은 일을 두 번 하는 시나리오는 원인을 찾기가 훨씬 까다롭습니다. 이 글에서는 중복이 생기는 세 가지 경로를 먼저 구분하고, 데이터 스토어(Data store)로 "이미 처리한 건"을 기억시켜 중복을 구조적으로 막는 4단계 설계를 정리합니다.

왜 같은 데이터가 두 번 처리될까

먼저 알아둘 것이 있습니다. 중복은 대부분 Make 안에서 생기지 않습니다. 바깥에서 같은 신호가 두 번 들어오는 경우가 훨씬 많습니다. 원인을 나누면 크게 셋입니다.

원인증상확인할 곳
보내는 쪽의 재전송 같은 내용이 몇 초 간격으로 2~3번 웹훅 모듈의 수신 기록(payload 비교)
웹훅이 여러 개 등록됨 항상 정확히 N배로 늘어남 보내는 서비스의 웹훅 설정 목록
내가 수동 실행 + 스케줄 동시 작동 테스트할 때만 두 번 History 탭의 실행 시각

특히 첫 번째가 흔합니다. 많은 서비스는 웹훅을 보낸 뒤 정해진 시간 안에 2xx 응답을 못 받으면 실패로 간주하고 다시 보냅니다. Make의 시나리오가 무거워서 응답이 늦어지면, 보내는 쪽은 "안 갔구나" 하고 재전송하고 Make는 그걸 새 건으로 받아 또 처리합니다. 결과적으로 한 사건에 두 번의 실행이 남습니다.

실행 기록에서 두 실행의 payload를 나란히 열어보세요. 내용이 완전히 같으면 재전송이나 웹훅 중복 등록이고, 미묘하게 다르면(ID가 다르다든지) 애초에 서로 다른 사건입니다. 이 구분을 먼저 해야 엉뚱한 곳을 고치지 않습니다.

중복을 막는 핵심 도구: 데이터 스토어

보내는 쪽의 재전송은 내가 통제할 수 없습니다. 그래서 받는 쪽에서 "이 건은 이미 처리했다"고 기억하는 장치가 필요합니다. Make에서 그 역할을 하는 것이 데이터 스토어입니다.

데이터 스토어는 시나리오 실행이 끝나도 값이 남는 저장소입니다. Make 공식 도움말에 따르면 시나리오 간, 그리고 실행과 실행 사이에 데이터를 전달하는 용도로 설계되어 있습니다. 실행이 끝나면 사라지는 변수와 결정적으로 다른 점이죠.

중복 방지에 쓰는 모듈은 사실상 세 개면 충분합니다.

  • Get a record — 키로 한 건을 조회합니다. "이미 처리했나?"를 묻는 질문에 해당합니다.
  • Add/replace a record — 처리 완료 표시를 남깁니다. 같은 키가 이미 있으면 덮어씁니다.
  • Search records — 조건으로 여러 건을 찾습니다. 뒤에서 다룰 오래된 기록 청소에 씁니다.

키를 무엇으로 잡느냐가 전부입니다

여기가 성패를 가릅니다. 키는 반드시 보내는 쪽이 부여한 고유 ID여야 합니다. 주문번호, 결제 ID, 메일의 message-id 같은 것들이요. 같은 사건이라면 몇 번을 재전송해도 이 값은 변하지 않기 때문입니다.

반대로 이런 것들을 키로 쓰면 중복 방지가 작동하지 않습니다.

  • ❌ 실행 시각 / 타임스탬프 — 재전송할 때마다 달라집니다
  • ❌ Make가 자동 생성한 실행 ID — 실행마다 새로 만들어집니다
  • ❌ 이름, 이메일 주소 같은 속성값 — 같은 사람이 정당하게 두 번 주문하면 두 번째가 막힙니다

고유 ID가 없는 소스라면 변하지 않는 값 두세 개를 이어 붙여 키를 만드세요. 예를 들어 폼 응답이라면 제출시각+이메일처럼요. 단, 이 조합은 완벽한 고유값이 아니므로 차선책으로만 씁니다.

Make 자동화 중복 방지 4단계

1단계 — 데이터 스토어와 키 구조 만들기

시나리오와 별개로 데이터 스토어를 하나 만듭니다. 구조는 단순할수록 좋습니다. 키 외에 status(처리 상태)와 processed_at(처리 시각) 정도만 두면 충분합니다. processed_at은 4단계의 청소 작업에 쓰이니 빠뜨리지 마세요.

2단계 — 쓰기 전에 조회하고 분기하기

트리거 바로 다음에 Get a record를 놓고 키로 조회합니다. 그 뒤에 필터를 걸어 기록이 없을 때만 다음 모듈로 넘어가게 합니다. 이미 있으면 시나리오는 여기서 조용히 끝나고, 슬랙 메시지도 스프레드시트 행도 생기지 않습니다.

필터 조건은 "Get a record의 키 값이 존재하지 않음(Does not exist)"으로 잡는 게 안전합니다. 조회 결과가 비어 있을 때 어떤 필드를 참조할지 헷갈린다면, 한 번 수동 실행해 실제 출력 구조를 보고 조건을 확정하세요.

3단계 — 순서를 지켜 기록 남기기

Add/replace a record를 어디에 놓느냐로 동작이 달라집니다.

  • 맨 끝에 놓으면: 작업이 성공해야 기록이 남습니다. 중간에 실패하면 기록이 없으므로 다음에 재시도됩니다. 누락은 없지만, 실패 직전까지의 작업이 이미 실행됐다면 그 부분은 두 번 돌 수 있습니다.
  • 조회 직후에 놓으면: 처리를 시작하자마자 자리를 선점합니다. 거의 동시에 도착한 재전송을 확실히 막지만, 뒤에서 실패하면 그 건은 영영 처리되지 않습니다.

결제·발송처럼 두 번 실행되면 안 되는 작업은 조회 직후에 선점하고, 실패 시 알림을 받도록 에러 핸들러를 붙이는 쪽이 안전합니다. 반대로 로그 기록처럼 두 번 남아도 큰 손해가 없는 작업은 맨 끝에 두어 누락을 줄입니다.

4단계 — 오래된 기록 청소하기

데이터 스토어 용량은 요금제에 묶여 있고, 가득 차면 저장 공간이 부족하다는 오류로 시나리오가 멈춥니다. 중복 방지용 기록은 무한정 쌓일 필요가 없습니다.

별도 시나리오를 만들어 하루 한 번 Search records로 processed_at이 30일보다 오래된 건을 찾아 삭제하세요. 보관 기간은 "보내는 쪽이 재전송을 시도할 만한 최대 기간"보다 넉넉하면 됩니다. 대개 며칠이면 충분하고, 30일이면 여유 있는 편입니다.

흔히 놓치는 세 가지

체크는 한 번, 쓰기는 여러 갈래

시나리오 시작에서만 중복 검사를 하고, 그 뒤에 라우터로 여러 갈래가 각각 데이터를 쓰는 구조는 위험합니다. 한 갈래가 실패해 부분 재실행되면 나머지 갈래는 또 실행되니까요. 되돌릴 수 없는 쓰기 작업이 있는 갈래마다 별도의 가드를 두는 편이 안전합니다.

순차 처리와 미완료 실행의 조합

시나리오 설정에는 데이터를 받은 순서대로 처리하는 순차 처리 옵션과, 실패한 실행을 보관하는 미완료 실행(incomplete executions) 옵션이 있습니다. Make 시나리오 설정 문서에 따르면 순차 처리가 켜진 상태에서 미완료 실행이 생기면 순서를 지키기 위해 이후 실행이 대기 상태가 되고, 미완료 실행이 정리되어야 다시 움직입니다.

중복이 무서워 순차 처리를 켜두는 경우가 있는데, 에러 하나가 큐 전체를 세울 수 있다는 점을 알고 써야 합니다. 중복 방지는 순차 처리가 아니라 키 기반 검사로 푸는 것이 원래 방향입니다.

조회 모듈도 operations를 씁니다

Make는 모듈 실행 단위로 operations를 계산합니다. 중복 검사를 넣으면 실행마다 조회 1회, 기록 1회가 더 붙습니다. 다만 중복 실행 한 번이 만들어내는 뒷수습 비용을 생각하면 대개 남는 장사입니다. 트래픽이 많은 시나리오라면 트리거 직후 필터로 명백히 무관한 건을 먼저 걸러내고, 살아남은 건에 대해서만 조회하도록 순서를 조정하세요.

결론

중복 실행은 시나리오를 정교하게 만들어서 없애는 게 아니라, "이 건은 처리했다"는 기억을 남겨서 없앱니다. 소스의 고유 ID를 키로 삼고, 쓰기 전에 조회하고, 순서를 정해 기록하고, 오래된 것은 지운다 — 이 네 가지면 대부분의 중복은 사라집니다. 오늘 돌고 있는 시나리오 중 되돌릴 수 없는 작업을 하는 것 하나만 골라, 트리거 다음에 Get a record와 필터를 끼워 넣는 것부터 시작해보세요.

※ 본 글은 작성 시점(2026년 8월) 기준의 Make 기능과 공식 문서를 바탕으로 합니다. 요금제별 제공 범위와 모듈 구성은 변경될 수 있으니 실제 설정 전 공식 도움말에서 최신 내용을 확인하시기 바랍니다.

AI 이미지 생성 2026: 만든 이미지에 AI 표시를 넣어야 할까 — 표시 의무와 저작권의 경계

AI 이미지 생성 표시 의무와 저작권
Photo by Andres Siimon on Unsplash

AI 이미지 생성으로 블로그 썸네일이나 상세페이지 이미지를 만들어 쓰다 보면, 어느 순간 기술이 아니라 다른 질문에 걸립니다. "이거 'AI로 만들었다'고 표시해야 하나?", "그리고 이 그림, 법적으로 내 것이라고 할 수 있나?" 프롬프트를 어떻게 쓰느냐는 검색하면 답이 나오는데, 이 두 가지는 자료마다 말이 달라서 더 헷갈립니다. 이 글에서는 2026년 현재 한국에서 실제로 적용되는 두 가지 규칙 — AI 생성물 표시 의무저작권 등록 기준 — 을 나눠서 정리합니다. 결론부터 말하면, 이 둘은 적용 대상도 판단 기준도 완전히 다릅니다.

표시 의무: 그림을 만든 사람이 아니라 '서비스를 만든 회사'의 몫

가장 많이 오해하는 지점부터 짚겠습니다. 「인공지능 발전과 신뢰 기반 조성 등에 관한 기본법」(이하 AI기본법)은 2026년 1월 22일 시행령과 함께 시행됐고, 생성형 AI 결과물에 'AI가 생성했다'는 사실을 표시하도록 의무를 부과합니다.

다만 이 의무의 주체는 '인공지능사업자'입니다. 생성형 AI 서비스나 그것을 이용한 제품·서비스를 제공하는 쪽이지, 그 도구를 가져다 쓰는 개인 이용자가 아닙니다. 즉 이미지 생성 서비스로 그림을 뽑아 개인 블로그에 올리는 행위 자체에 대해, 현행법이 이용자에게 표시 의무를 직접 지우고 있지는 않습니다. 다만 본인이 AI 기능을 얹은 서비스를 만들어 제공하는 위치라면 이야기가 달라지므로, 자신이 '사업자'에 해당하는지부터 확인하는 게 순서입니다.

표시 방식과 제재는 이렇게 정리됩니다

항목 내용
의무 주체 인공지능사업자 (생성형 AI 서비스·제품 제공자)
표시 방식 눈에 보이거나 들리는 워터마크, 또는 메타데이터 같은 기계 판독 방식
기계 판독 방식만 쓸 때 다운로드 단계에서 최소 1회 이용자에게 안내
딥페이크(실제와 구분 어려운 것) 이용자가 명확히 인식할 수 있게 고지·표시
위반 시 시정명령, 최대 3,000만 원 과태료
계도기간 시행 초기 혼란을 줄이기 위해 1년 이상 운영 방침

여기서 실무적으로 중요한 건, 애니메이션이나 웹툰처럼 실사 딥페이크가 아닌 일반 생성물에는 눈에 보이지 않는 디지털 워터마크도 허용된다는 점입니다. 화면에 로고가 안 박혀 있다고 해서 표시가 없는 게 아니라, 파일 안에 흔적이 들어 있을 수 있다는 뜻입니다. 이 사실은 뒤에 나올 실무 체크리스트와 직접 연결됩니다.

저작권: '프롬프트를 잘 썼다'는 것만으로는 인정되지 않습니다

표시 의무를 통과했다고 해서 그 이미지가 자동으로 내 저작물이 되는 건 아닙니다. 이건 완전히 별개의 문제입니다.

문화체육관광부와 한국저작권위원회는 2025년 6월 「생성형 인공지능 활용 저작물의 저작권 등록 안내서」를 통해 기준을 정리했습니다. 핵심은 'AI 산출물'과 'AI를 활용한 저작물'을 구분한다는 것입니다.

AI가 만들어낸 결과물 자체는 저작물이 아니어서 등록 대상이 아닙니다. 프롬프트를 아무리 정교하게 다듬어도 마찬가지입니다. 프롬프팅은 아이디어를 제시하거나 브레인스토밍하는 정도로 보기 때문입니다. 오타 수정, 사소한 크기 조정, 단순 색상 변경 같은 손질도 창작적 기여로 보기 어렵습니다.

반대로 인정될 수 있는 경우 3가지

  • 내 저작물을 프롬프트로 넣은 경우 — 직접 그린 그림이나 촬영한 사진을 입력해, 결과물에 그 저작물의 창작성이 나타난 경우
  • 추가 작업에 창작성이 있는 경우 — AI 산출물을 받아 수정·증감한 부분에 창작성이 인정되는 경우
  • 선택·배열·구성에 창작성이 있는 경우 — 여러 산출물을 골라 배열하고 구성한 데에 창작성이 인정되는 경우

헷갈리기 쉬우니 두 개념을 나란히 놓고 보겠습니다.

구분 AI 산출물 AI 활용 저작물
사람의 개입 프롬프트 입력 위주, 결과물 그대로 사용 수정·증감, 선택·배열 등 창작적 기여 존재
저작물 인정 인정되지 않음 기여한 부분에 한해 인정
저작권 등록 불가 가능 (AI 부분과 사람 부분을 구분 기재)

실제 작업에서는 이 경계가 칼로 자르듯 나뉘지 않습니다. AI로 배경을 뽑고 그 위에 직접 그린 요소를 얹은 뒤 구도를 다시 잡았다면, 사람이 손댄 그 부분은 판단 대상이 됩니다. 반대로 마음에 드는 컷이 나올 때까지 프롬프트만 바꿔 가며 백 번을 돌렸다면, 들인 시간과 무관하게 창작적 기여로 보기는 어렵습니다. 기준은 투입한 노력의 양이 아니라 결과물에 사람의 창작성이 드러났는지입니다.

다만 등록이 된다고 해도 보호 범위는 인간이 창작적으로 기여한 부분에만 미칩니다. AI 산출물 부분 자체가 보호받는 게 아닙니다. 그래서 등록을 신청할 때는 저작물 내용란에 AI가 만든 부분과 사람이 만든 부분을 구분해서 적어야 합니다. 실제로 2023년 12월 국내 첫 생성형 AI 영화가 등록된 사례도 일반 영상저작물이 아니라 '편집저작물'로 등록됐습니다.

AI 이미지 생성 결과물을 실무에서 안전하게 쓰는 체크리스트

1. 만드는 과정을 기록으로 남기세요

나중에 권리를 주장하거나 등록을 시도할 때 필요한 건 완성본 하나가 아니라 사람이 무엇을 했는지에 대한 증거입니다. 원본 산출물, 수정 전후 파일, 어떤 기준으로 골랐는지 메모를 남겨 두세요. 폴더 하나에 날짜별로 쌓는 것만으로도 충분합니다. 지금은 번거로워 보여도, 필요한 순간에 없으면 뒤늦게 만들 수 없는 자료입니다.

2. 파일 메타데이터를 함부로 지우지 마세요

표시가 눈에 보이지 않는 방식으로 들어갈 수 있다는 건, 편집 과정에서 무심코 지워질 수도 있다는 뜻입니다. 이미지 압축 도구나 리사이즈 툴 중에는 메타데이터를 통째로 날리는 것들이 있습니다. 표시를 일부러 제거하는 행위는 전혀 다른 문제가 될 수 있으니, "용량 줄이려고 돌렸더니 같이 사라졌다"는 상황을 애초에 만들지 않는 편이 낫습니다. 원본 파일을 따로 보관해 두면 이런 사고의 영향을 줄일 수 있습니다.

3. 상업적 이용은 법이 아니라 '약관'이 먼저입니다

저작권 등록 가능 여부와, 그 이미지를 상품·광고에 써도 되는지는 또 다른 층위입니다. 후자는 사용한 서비스의 이용약관이 정합니다. 유료 플랜에서만 상업적 이용을 허용하거나, 생성 결과물의 권리 귀속을 별도로 규정하는 경우가 있으므로 본인이 쓰는 서비스의 약관을 직접 확인하세요. 서비스마다 다르고 정책이 바뀌기도 해서, 남의 요약글보다 원문 확인이 정확합니다.

4. 게시할 플랫폼의 자체 규칙도 별도로 봅니다

법적 의무와 별개로, 콘텐츠 플랫폼들이 자체적으로 AI 생성 콘텐츠 표기란을 두는 경우가 있습니다. 법상 의무 주체가 아니더라도 플랫폼 규칙을 어기면 노출 제한 같은 불이익을 받을 수 있으니, 올리려는 곳의 정책을 한 번 확인하고 시작하는 게 안전합니다.

흔히 하는 실수 3가지

  • 표시 의무와 저작권을 한 덩어리로 묶어 생각하기 — 적용 대상도 판단 기준도 다릅니다. 표시했다고 권리가 생기지 않고, 표시 의무가 없다고 권리가 보장되지도 않습니다.
  • 결과물만 남기고 중간 과정을 버리기 — 창작적 기여를 설명해야 할 때 근거가 되는 건 중간 파일과 작업 기록입니다.
  • 여러 서비스 결과물을 섞어 쓰면서 출처를 안 적어 두기 — 나중에 어느 이미지가 어떤 약관의 적용을 받는지 되짚기 어려워집니다.

자주 묻는 질문

  • Q. 블로그에 AI로 만든 썸네일을 쓰면서 "AI 생성"이라고 적어야 하나요?
    A. 현행 AI기본법상 표시 의무는 사업자에게 부과된 것입니다. 다만 적는다고 불이익이 있는 것도 아니고, 읽는 사람에 대한 신뢰 측면에서는 밝히는 쪽이 무난합니다.
  • Q. 프롬프트를 100번 고쳐서 뽑았는데도 저작권이 없나요?
    A. 안내서 기준으로 프롬프팅 자체는 창작적 기여로 보지 않습니다. 다만 그 결과물을 직접 수정·증감하거나, 여러 결과물을 선택·배열한 부분에 창작성이 있으면 그 부분은 달리 평가될 수 있습니다.
  • Q. 저작권 등록을 꼭 해야 하나요?
    A. 등록은 의무가 아닙니다. 다만 분쟁이 생겼을 때 입증에 도움이 되는 절차이므로, 상업적으로 비중 있게 쓰는 결과물이라면 검토해 볼 만합니다.

결론

정리하면 두 가지입니다. AI 이미지 생성물의 표시 의무는 서비스를 제공하는 사업자의 몫이고, 저작권은 사람이 얼마나 창작적으로 개입했느냐로 갈립니다. 둘을 섞어서 생각하면 "표시했으니 내 것"이라거나 "표시 안 해도 되니 신경 쓸 것 없다"는 잘못된 결론에 도달하기 쉽습니다. 오늘 만든 이미지부터 원본과 수정 이력을 한 폴더에 모아 두는 것으로 시작해 보세요. 나중에 필요해졌을 때 가장 아쉬운 게 바로 그 기록입니다.

※ 본 글의 법령·제도 내용은 작성 시점(2026년 8월) 기준이며, 이후 개정될 수 있습니다. 본 글은 일반 정보 제공 목적이며, 개별 상황에 따라 다를 수 있으니 전문가 상담을 권장합니다.

클로드 활용법 2026: 한도에 걸려 멈춘다면 — 사용량 한도와 길이 한도는 다른 문제다

클로드 활용법 사용량 한도 관리
Photo by Anthony Riera on Unsplash

한창 일이 잘 풀리던 중에 "한도에 도달했습니다"라는 안내를 보고 손을 놓아본 적 있으신가요. 클로드 활용법을 익히는 과정에서 가장 먼저 부딪히는 벽이 바로 이 한도입니다. 그런데 많은 분들이 놓치는 지점이 하나 있습니다. 클로드에서 만나는 제한은 사실 두 종류이고, 원인이 다르면 해법도 완전히 다르다는 점입니다. 하나는 "일정 시간 동안 얼마나 많이 썼는가"의 문제이고, 다른 하나는 "이 대화가 얼마나 길어졌는가"의 문제입니다. 둘을 구분하지 못하면 기다려도 소용없는 상황에서 하염없이 기다리거나, 반대로 굳이 상위 플랜을 알아보게 됩니다. 이 글에서는 두 한도를 구분하는 법과, 같은 일을 하면서도 한도를 덜 쓰는 실전 습관을 정리했습니다.

클로드 활용법의 첫 관문: 사용량 한도 vs 길이 한도

Anthropic 공식 도움말은 두 제한을 명확히 구분합니다. 화면에 뜨는 안내는 비슷해 보여도 대응은 정반대입니다.

구분 사용량 한도 길이 한도
무엇을 제한하나 일정 시간 동안 쓸 수 있는 총량 대화 하나가 담을 수 있는 정보량
언제 풀리나 시간이 지나 창이 초기화될 때 기다려도 그 대화에서는 안 풀림
해법 쓰는 방식을 아껴서 재조정 새 대화를 열고 핵심만 옮기기

길이 한도는 대화창의 용량 문제입니다. 새 대화를 시작하면 클로드가 한 번에 다룰 수 있는 정보량이 정해져 있는데, 대화가 길어지거나 파일을 여러 개 올리면 그 공간이 차오릅니다. 한계에 가까워지면 길이 초과 안내가 뜨고, 이건 아무리 기다려도 그 대화 안에서는 해결되지 않습니다. 반면 사용량 한도는 시간이 지나면 회복됩니다. "기다리면 되는 문제인가, 대화를 새로 열어야 하는 문제인가"를 먼저 판단하는 것이 시작입니다.

사용량이 생각보다 빨리 차는 세 가지 이유

1. 자정에 리셋되는 일일 한도가 아니다

가장 흔한 오해입니다. 클로드의 사용량 한도는 하루 단위로 끊기지 않습니다. 첫 메시지를 보낸 시점부터 시작되는 5시간 단위 창으로 굴러갑니다. 오전 9시에 첫 메시지를 보냈다면 그 창은 오후 2시에 초기화되는 식입니다. 자정까지 기다릴 필요가 없다는 뜻이기도 하고, 반대로 "어제 안 썼으니 오늘은 두 배로 쓸 수 있다"는 계산은 성립하지 않는다는 뜻이기도 합니다. 한도에 걸렸을 때 가장 먼저 확인할 것은 날짜가 아니라 내가 오늘 언제 첫 메시지를 보냈는지입니다.

2. 여러 제품을 써도 한도는 하나로 합산된다

웹 브라우저의 claude.ai, 데스크톱 앱, 터미널에서 쓰는 Claude Code — 사용하는 창구는 달라도 사용량은 같은 한도에 합산됩니다. 오전 내내 코드 작업을 돌린 뒤 오후에 웹에서 문서를 정리하려다 갑자기 막히는 상황이 여기서 나옵니다. 도구를 여러 개 쓰고 있다면 "웹에서는 얼마 안 썼는데"라는 감각은 실제 잔량과 어긋날 수 있습니다. 유료 플랜에는 이 5시간 창과 별도로 주간 단위 한도도 함께 적용됩니다.

3. 대화가 길수록 메시지 한 통이 무거워진다

보낼 수 있는 메시지 수는 고정값이 아닙니다. 메시지 길이, 첨부한 파일의 분량, 지금 대화가 얼마나 길어졌는지, 어떤 모델과 기능을 쓰는지에 따라 달라집니다. 같은 "네, 계속해주세요" 한마디라도 자료를 잔뜩 올린 긴 대화의 끝에서 보내는 것과 새 대화 첫 줄에서 보내는 것은 소모량이 다릅니다. 대화가 길어질수록 그동안 쌓인 내용이 매번 함께 처리되기 때문입니다. 참고로 본 글 작성 시점(2026년 8월) 기준 유료 플랜의 대화 용량은 20만 토큰 수준으로 안내되고 있습니다.

한도를 덜 쓰면서 같은 일을 끝내는 4가지 습관

Anthropic이 사용 한도 모범 사례 문서에서 안내하는 내용을 실제 업무 흐름에 맞춰 정리했습니다.

질문은 묶어서 한 번에

긴 문서를 올려놓고 "요약해줘" → "핵심 3개만" → "그럼 반론은?"처럼 나눠 묻는 방식이 한도를 가장 빨리 태웁니다. 주고받을 때마다 그 문서를 포함한 대화 전체가 다시 처리되기 때문입니다. 처음부터 "① 3문단 요약 ② 핵심 쟁점 3개 ③ 예상되는 반론"처럼 번호를 매겨 한 메시지에 담으면 같은 결과를 훨씬 적은 소모로 받을 수 있습니다. 보고서 검토처럼 물어볼 것이 뻔한 작업일수록 효과가 큽니다.

같은 대화에 파일을 다시 올리지 않기

대화 중간에 "아까 그 파일 한 번 더 볼래?"라며 같은 자료를 재업로드하는 경우가 많습니다. 클로드는 그 대화의 맥락을 이미 갖고 있으므로 다시 올릴 필요가 없습니다. 재업로드는 용량만 두 배로 잡아먹고 길이 한도까지 앞당깁니다. 다시 올리는 대신 "앞서 올린 자료의 3장 부분"처럼 위치를 짚어주면 됩니다.

반복해서 쓰는 자료는 프로젝트에 올려두기

매주 참조하는 브랜드 가이드, 회사 양식, 제품 소개서처럼 계속 쓰는 문서는 대화마다 첨부하지 말고 프로젝트에 등록해두는 편이 낫습니다. 프로젝트에 추가한 문서는 캐시되어, 그 내용을 참조할 때 캐시된 부분이 그렇지 않은 경우보다 한도에 적게 계산됩니다. 같은 자료로 반복 작업하는 사람일수록 차이가 누적됩니다.

주제가 바뀌면 대화도 바꾸기

하나의 대화창에서 기획서 검토 → 이메일 초안 → 코드 디버깅까지 이어가는 습관은 두 한도를 동시에 압박합니다. 앞의 기획서 내용이 계속 따라다니면서 뒤의 작업까지 무겁게 만들기 때문입니다. 주제가 바뀌는 순간 새 대화를 여는 것만으로도 체감이 달라집니다. 이때 이전 대화의 결론 몇 줄만 직접 붙여넣으면 맥락은 대부분 유지됩니다.

5시간 창을 염두에 둔 하루 작업 배치

한도 구조를 알면 작업 순서를 바꾸는 것만으로 하루에 처리하는 양이 달라집니다. 아래는 직장인이 흔히 겪는 흐름을 예시로 구성한 것입니다.

시간대 흔한 방식 한도를 고려한 방식
오전 가벼운 질문으로 워밍업하며 창을 미리 열어둠 가장 무거운 문서 작업부터 착수
점심 전후 같은 대화창에 다른 주제를 계속 이어붙임 주제가 바뀌는 지점에서 새 대화로 분리
오후 한도에 걸려 대기, 급한 일이 밀림 창이 초기화된 뒤 두 번째 무거운 작업 배치

핵심은 무거운 작업을 창의 앞쪽에 두는 것입니다. 사소한 질문으로 창을 먼저 열어두면 정작 집중이 필요한 시점에 남은 여유가 줄어든 상태로 시작하게 됩니다. 마감이 걸린 자료 작업이 있다면 그날의 첫 메시지를 그 작업에 쓰는 편이 안전합니다.

한도를 빨리 태우는 흔한 실수

  • 결과가 마음에 안 들 때 무작정 재생성 — 같은 요청을 반복하면 대화 전체가 한 번 더 처리됩니다. 재생성보다 "두 번째 항목을 표로 바꿔주세요"처럼 고칠 지점을 짚어주는 편이 소모도 적고 결과도 의도에 가깝습니다.
  • 참고용 파일을 미리 몰아서 첨부 — 나중에 쓸지 모른다며 자료를 한꺼번에 올려두면 이후 모든 메시지가 그 자료를 안고 갑니다. 실제로 필요한 시점에 필요한 자료만 올리는 것이 낫습니다.
  • 한 대화를 며칠씩 이어 쓰기 — 어제 대화를 오늘 이어가면 어제 내용까지 매번 함께 처리됩니다. 어제의 결론이 필요하다면 그 몇 줄만 새 대화에 옮겨 붙이면 충분합니다.

자주 묻는 질문

  • Q. 한도에 걸렸는데 얼마나 기다려야 하나요?
    A. 사용량 한도라면 해당 창이 초기화될 때까지입니다. 정확한 잔량과 초기화 시점은 앱 내 사용량 화면에서 확인하는 것이 가장 확실합니다.
  • Q. 대화를 지우면 한도가 회복되나요?
    A. 아닙니다. 이미 사용한 분량은 대화를 삭제해도 되돌아오지 않습니다. 다만 새 대화를 열면 길이 한도는 초기 상태에서 다시 시작합니다.
  • Q. 짧게 여러 번 vs 길게 한 번, 뭐가 유리한가요?
    A. 큰 자료를 다루는 중이라면 질문을 묶어 길게 한 번 보내는 쪽이 유리합니다. 자료 없이 가볍게 주고받는 대화라면 큰 차이가 없습니다.

결론: 막히는 지점을 알면 대응이 달라진다

클로드에서 작업이 멈췄을 때 무작정 기다리거나 곧장 상위 플랜을 알아보기 전에, 지금 막힌 것이 사용량 한도인지 길이 한도인지부터 확인해보세요. 길이 문제라면 새 대화로 옮기는 30초면 해결되고, 사용량 문제라면 질문을 묶고 파일 재업로드를 줄이는 것만으로 하루 작업량이 달라집니다. 오늘 작업부터 "질문 묶어 보내기" 하나만 먼저 적용해보세요.

※ 한도 정책과 수치는 변경될 수 있습니다. 본 글은 작성 시점(2026년 8월) 기준이며, 최신 내용은 Anthropic 공식 도움말에서 확인하시기 바랍니다.

AI 유튜브 자동화 2026: AI 성우를 쓰기 전에 — 남의 얼굴·목소리가 걸리는 지점

AI 유튜브 자동화를 돌리다 보면 파이프라인의 마지막 칸은 대개 목소리와 얼굴입니다. 대본은 AI가 쓰고, 이미지는 생성하고, 내레이션은 AI 성우를 얹죠. 그런데 여기서 조회수가 아니라 채널 자체를 흔드는 문제가 생깁니다. 그 목소리와 얼굴이 남의 것일 때입니다.

2026년 8월 일본에서는 유명 성우들의 목소리를 생성형 AI로 무단 복제한 영상이 대량으로 유통되면서 성우들이 공개적으로 문제를 제기했습니다. 하루에 100~200건씩 새 합성물이 올라오는 탓에, 피해자가 URL을 하나씩 잡아 삭제를 요구하는 방식으로는 따라잡기 어렵다는 지적이 나왔습니다. 이건 남의 이야기가 아닙니다. 자동화 채널은 구조상 소재를 긁어오고 목소리를 합성하기 때문에, 나쁜 의도가 없어도 이 선을 넘기 쉽습니다.

먼저 오해부터 정리: AI 목소리 자체는 금지가 아니다

2026년 상반기에 "7월부터 AI 음성(TTS)을 쓴 영상은 수익 창출이 전면 금지된다"는 이야기가 SNS를 통해 퍼졌습니다. 확인 결과 이는 사실이 아니었습니다. TTS라는 도구를 이유로 수익화를 일괄 차단하는 규정은 없었고, 유튜브가 강화한 것은 저품질·반복 양산 콘텐츠에 대한 기준이었습니다.

정리하면 판단 기준은 "AI를 썼는가"가 아니라 두 가지입니다.

  • 누구의 얼굴·목소리인가 — 실존 인물을 사실적으로 흉내 냈다면 별도의 신고 트랙에 걸립니다.
  • 사람의 기획과 개입이 있는가 — 형식만 바꿔 기계적으로 찍어내는 구성은 도구와 무관하게 제재 대상이 됩니다.

이 글에서 다루는 건 앞쪽, 즉 초상과 음성입니다. 두 번째 항목은 콘텐츠 기획의 문제라 시간이 걸리지만, 첫 번째는 규칙 몇 개로 오늘 바로 막을 수 있습니다.

유튜브가 실제로 보는 판단 기준

누군가 AI로 자신의 외모나 음성과 유사하게 만든 콘텐츠는, 저작권이 아니라 개인정보 침해(프라이버시) 신고 절차로 삭제를 요청할 수 있습니다. 저작권 신고와 트랙이 다르다는 점이 중요합니다. 음원이나 영상 클립을 쓰지 않았더라도, 목소리를 흉내 낸 것만으로 걸릴 수 있다는 뜻이니까요. 요청이 들어오면 유튜브는 대략 다음을 따집니다.

확인 항목 어떻게 작용하나
사실적인 합성인가 실제처럼 보이는 변조·생성 버전이어야 삭제 대상이 됨
특정 개인을 식별하는가 그 사람이라고 알아볼 수 있는지
AI 제작임이 명확히 표시됐는가 표시 여부가 판단에 참작됨
패러디·풍자·공익적 가치가 있는가 해당하면 삭제 대상에서 빠질 수 있음
민감한 행위를 묘사했는가 범죄·폭력, 제품이나 정치인 지지 등은 더 엄격히 봄

신고는 원칙적으로 본인이 해야 합니다(미성년자·사망자 등 예외 있음). 신고가 접수되면 업로더에게 약 48시간의 여유가 주어지고, 그 안에 처리하지 않으면 유튜브가 직접 검토합니다. 자동화 채널 입장에서 중요한 건 이겁니다. 영상 하나가 아니라 채널 전체가 같은 템플릿으로 돌아가기 때문에, 문제가 한 번 걸리면 과거 영상까지 줄줄이 같은 성격을 갖습니다. 한 건을 지우고 끝나는 게 아니라, 같은 규칙으로 만든 수십 편이 동시에 위험해지는 구조입니다.

유사성 감지가 전체 크리에이터로 열렸다

2025년 10월 정식 출시된 유사성 감지(likeness detection)는 2026년 5월, 만 18세 이상 자격 요건을 갖춘 크리에이터 전체로 확대됐습니다. 처음에는 파트너 프로그램 참여자와 언론인·공인 등 일부 대상에서 시작해 배우·운동선수·음악가로 넓혀오다 문이 열린 것입니다.

기술적으로는 Content ID의 지문(fingerprint) 방식을 얼굴과 음성 패턴에 맞게 다시 학습시킨 구조입니다. 사용법은 YouTube 고객센터의 유사성 감지 안내에 정리돼 있고, 흐름은 이렇습니다.

  1. YouTube 스튜디오의 콘텐츠 감지 탭에서 '유사성' 항목을 켠다
  2. 신분증과 짧은 얼굴 영상으로 본인 확인을 마친다
  3. 내 얼굴이 AI로 변조·생성된 것으로 보이는 영상 목록을 스튜디오에서 검토한다
  4. 문제가 있으면 개인정보 침해 신고로 삭제를 요청한다

피해자 쪽 탐지 비용이 크게 낮아졌습니다. 예전에는 당사자가 직접 검색해 찾아내야 했지만, 이제는 플랫폼이 후보를 모아서 보여줍니다. 남의 얼굴·목소리에 기대는 자동화 채널이 예전만큼 오래 눈에 안 띌 거라고 기대하기 어려워진 이유입니다.

AI 유튜브 자동화 파이프라인에 넣을 체크리스트

규칙을 외우는 것만으로는 부족합니다. 자동화의 본질은 사람이 매번 판단하지 않는다는 데 있으니까요. 아래 항목은 발행 직전이 아니라 소재 수집 단계에 넣어야 실제로 작동합니다.

  • 썸네일 소재 규칙을 먼저 정한다 — 유명인 얼굴로 클릭을 끌어오는 방식은 자동화 채널이 가장 흔하게 걸리는 지점입니다. 소재 수집 단계에서 인물 사진을 아예 제외하는 편이 안전합니다.
  • AI 성우는 '누구 목소리인지'를 확인한다 — 상업적 이용이 허용된 합성 음성인지, 실존 인물의 음성을 복제한 것은 아닌지. 특정인을 흉내 내는 음성은 목적이 무엇이든 위험합니다.
  • 민감 분야는 아바타를 쓰지 않는다 — 의료·금융·법률 정보를 실존 인물처럼 보이는 AI 아바타가 전달하는 형식은 특히 문제가 되기 쉽습니다.
  • 합성 사실을 표시한다 — 표시 여부는 삭제 판단에서 참작 요소로 작동합니다. 붙여서 손해 볼 일이 없습니다.
  • 내 채널도 등록해둔다 — 얼굴을 노출하는 채널이라면 유사성 감지는 지금 켜두는 게 맞습니다. 도용은 채널이 커진 다음에 옵니다.
  • 소재 출처를 로그로 남긴다 — 어떤 이미지·음성을 어디서 가져왔는지 기록해두면, 나중에 문제가 생겼을 때 해명이 가능합니다.

본 글은 작성 시점(2026년 8월) 기준의 플랫폼 정책과 보도를 정리한 것입니다. 정책 세부 사항은 바뀔 수 있고, 초상권·퍼블리시티권 관련 분쟁은 국가와 사안에 따라 판단이 달라지므로 실제 문제가 생겼다면 법률 전문가와 상담하시기 바랍니다.

결론: 자동화의 리스크는 속도가 아니라 소재에 있다

자동화 채널을 만들 때 대부분은 "얼마나 빨리 찍어낼 수 있는가"를 고민합니다. 하지만 실제로 채널을 멈춰 세우는 건 생산 속도가 아니라 파이프라인에 흘러 들어온 소재입니다. 남의 얼굴과 목소리는 그중 가장 조용하게 쌓이다가 한 번에 터지는 항목이고, 탐지 도구가 전체 크리에이터에게 열린 지금은 발각까지 걸리는 시간도 짧아졌습니다.

오늘 자기 채널의 최근 영상 다섯 개만 열어보세요. 썸네일에 실존 인물의 얼굴이 있는지, 내레이션이 누구의 목소리를 흉내 내고 있는지 확인하는 것부터 시작하면 됩니다.

Perplexity 검색 2026: 답은 최신 같은데 정보는 작년 것 — 소스 발행일부터 확인하는 법

Perplexity 검색으로 요금제를 조사해 팀에 공유했는데, 회의 자리에서 "그거 지난달에 바뀌었는데요"라는 말을 들은 적 있으신가요? 답변은 매끄럽고 각주까지 달려 있었으니 의심할 이유가 없었을 겁니다. 문제는 내용이 틀렸다는 게 아니라, 맞긴 맞는데 시점이 지났다는 데 있습니다. 출처가 붙어 있다는 사실과 그 출처가 최신이라는 사실은 전혀 다른 이야기입니다.

AI 검색을 쓰면서 가장 놓치기 쉬운 게 이 지점입니다. 링크가 몇 개 달려 있으면 검증이 끝났다고 느끼지만, 정작 그 글이 언제 쓰였는지는 아무도 확인하지 않습니다. 틀린 정보를 걸러내는 일은 그래도 신경 쓰는 편인데, 낡은 정보를 걸러내는 일은 아예 점검 항목에 없는 경우가 많습니다. 오늘은 답변의 신뢰도를 시점 기준으로 점검하는 방법을 정리해 보겠습니다.

왜 Perplexity 검색에 낡은 자료가 섞일까

AI 검색 엔진은 실시간으로 웹을 훑어 근거를 모읍니다. 그런데 "잘 정리된 글"과 "지금 유효한 글"은 다릅니다. 몇 년에 걸쳐 링크가 쌓이고 검색 상위에 오래 노출된 글은 그만큼 참조되기 쉽고, 반대로 어제 올라온 공식 공지는 아직 아무도 인용하지 않아 존재감이 약합니다. 정리가 잘 된 예전 글이 새 공지를 밀어내는 구조인 셈입니다.

여기에 한 가지 함정이 더 있습니다. 많은 웹페이지가 발행일을 명확히 표시하지 않거나, 본문은 그대로 둔 채 날짜만 갱신합니다. 사람이 봐도 헷갈리는 정보를 기계가 정확히 판별하리라 기대하기는 어렵습니다.

바뀌는 속도가 빠른 주제일수록 위험하다

모든 질문이 똑같이 위험한 건 아닙니다. 역사적 사실이나 개념 설명은 3년 전 글이어도 대체로 유효합니다. 반면 아래 주제들은 몇 달만 지나도 내용이 뒤집힙니다.

  • 소프트웨어 요금제·기능 — 가격 정책과 무료 한도는 수시로 바뀝니다.
  • 세법·정부 지원 제도 — 연도가 바뀌면 한도와 요건이 함께 달라집니다.
  • 플랫폼 운영 정책 — 수수료율, 수익화 조건, 약관은 예고 없이 개정됩니다.
  • AI 모델·도구 — 분기 단위로 이름과 사양이 갈아치워지는 영역입니다.

이런 주제를 조사할 때는 "답이 맞나"보다 "이 답이 언제 기준인가"를 먼저 물어야 합니다. 반대로 개념 정리나 원리 설명을 찾는 중이라면 날짜에 과하게 신경 쓸 필요는 없습니다. 점검의 강도를 주제에 따라 다르게 두는 것이 현실적입니다.

발행일과 최종 수정일은 다른 정보다

시점을 확인할 때 알아두면 유용한 구분이 하나 있습니다. 글이 처음 발행된 날마지막으로 수정된 날은 별개의 정보라는 점입니다.

이 구분은 Perplexity가 개발자용 API에서 제공하는 필터에도 그대로 반영돼 있습니다. 공식 문서인 Search Date and Time Filters에 따르면, 발행일 기준으로 거르는 search_after_date_filter·search_before_date_filter와, 최종 수정일 기준으로 거르는 last_updated_after_filter·last_updated_before_filter가 따로 존재합니다. 여기에 더해 search_recency_filter로 day·week·month·year 같은 상대 기간을 지정할 수도 있습니다.

도구가 두 날짜를 굳이 나눠서 다룬다는 건, 그만큼 둘이 다른 판단 근거라는 뜻입니다. 2023년에 쓰였지만 지난주에 갱신된 가이드는 쓸 만할 수 있고, 반대로 발행일만 최근인 요약 글은 옛 내용을 옮겨 적은 것일 수 있습니다. 출처를 볼 때 두 날짜를 같이 놓고 판단하면 훨씬 정확해집니다.

출처의 상태 어떻게 읽을까
발행일·수정일 모두 최근 가장 안전한 축. 그대로 활용해도 무리 없음
발행일은 오래됐지만 최근 수정됨 유지·보수되는 문서일 가능성. 다만 본문 어디가 갱신됐는지 확인 필요
발행일만 최근 옛 자료를 재가공한 요약 글일 수 있음. 원문 확인 권장
날짜 표시가 아예 없음 시점 판단 불가. 중요한 수치의 근거로는 쓰지 않는 편이 안전

특히 마지막 경우를 조심해야 합니다. 날짜가 없는 글은 "오래됐다"가 아니라 "언제인지 알 수 없다"에 해당하고, 판단할 수 없는 정보는 결국 판단되지 않은 채로 그대로 옮겨지기 때문입니다.

검증을 돕는 기능도 있다

Perplexity는 답변 문장을 드래그해 그 주장이 어떤 출처에 근거했는지 확인하는 'Check Sources' 기능을 제공합니다. 공식 체인지로그 기준으로 이 기능은 베타 단계이며 Pro 구독자에게 먼저 배포됐습니다(본 글 작성 시점 기준). 답변 전체를 통으로 믿는 대신 의심 가는 문장 하나만 집어서 근거를 열어볼 수 있다는 점이 유용합니다.

최신 정보만 걸러 받는 4단계

실제 리서치에 바로 적용할 수 있는 순서로 정리했습니다.

1단계 — 질문에 기간을 못 박는다

"○○ 요금제 알려줘" 대신 "○○ 요금제, 최근 3개월 내 자료 기준으로 알려줘"처럼 기간을 명시합니다. 여기에 "각 항목이 언제 기준 정보인지 함께 적어줘"를 덧붙이면, 답변 안에서 시점이 애매한 부분이 어디인지 스스로 드러납니다. 날짜를 못 채우고 넘어간 항목이 곧 확인이 필요한 항목입니다.

2단계 — 소스 목록을 날짜로 훑는다

답변을 읽기 전에 출처 목록부터 봅니다. 확인할 건 두 가지입니다. 인용된 글이 대체로 최근인가, 그리고 공식 도메인이 하나라도 있는가. 요약 블로그만 잔뜩 달려 있다면 그 답변은 전부 2차 정보라는 뜻입니다.

3단계 — 1차 출처로 좁혀 다시 묻는다

가격·정책·법령처럼 확정된 답이 있어야 하는 주제라면, 검색 범위를 그 내용을 만든 곳으로 좁혀 재질문합니다. "이 내용을 회사 공식 문서나 정부 기관 자료에서 확인해줘"처럼 요청하면 참조 대상이 달라집니다. 2차 요약본이 아니라 원문에서 확인해야 시점 문제가 사라집니다.

4단계 — 숫자 하나는 직접 눈으로 본다

보고서나 블로그에 옮길 핵심 수치가 있다면, 그 숫자 하나만큼은 출처 링크를 열어 원문에서 확인합니다. 시간은 1분이면 충분하고, 이 습관 하나가 대부분의 사고를 막아줍니다. 같은 조사를 반복적으로 자동화한다면 앞서 소개한 날짜 필터를 파이프라인에 넣어 아예 낡은 자료가 들어오지 못하게 막는 방법도 있습니다.

정리: 각주의 개수가 아니라 날짜를 보세요

AI 검색의 각주는 "이 답이 사실이다"의 증거가 아니라 "이 답이 어디서 왔는지"의 주소입니다. 주소를 확인하지 않으면 각주는 장식일 뿐입니다. 특히 요금제·정책·세제처럼 자주 바뀌는 주제에서는 정확성보다 시점이 먼저 무너집니다.

정리하면 이렇습니다. 질문할 때 기간을 명시하고, 소스 목록의 날짜와 도메인을 훑고, 중요한 주제는 1차 출처로 좁히고, 핵심 숫자 하나는 직접 확인한다. 네 가지 모두 30초씩이면 되는 일이고, 익숙해지면 따로 의식하지 않아도 손이 먼저 움직입니다.

오늘 Perplexity로 무언가를 조사한다면, 답변을 복사하기 전에 출처 목록을 한 번만 열어 날짜를 확인해보세요. 그 30초가 "지난달에 바뀌었는데요"라는 말을 듣는 상황을 막아줍니다.

※ 본 글에 언급된 기능과 정책은 작성 시점 기준이며, 서비스 사양은 변경될 수 있습니다. 세무·법률 관련 판단이 필요한 경우에는 전문가 상담을 권장합니다.

Gemini 활용법 2026: 매번 내가 물어봐야 움직인다면 — 예약 작업으로 아침에 미리 받아두는 법

Gemini 활용법을 검색해서 프롬프트도 다듬고, 자주 쓰는 지시는 Gems로 저장까지 해뒀습니다. 그런데 이상하게 체감되는 시간 절약이 크지 않습니다. 이유는 단순합니다. 여전히 내가 앱을 열고, 내가 물어봐야만 무언가가 시작되기 때문입니다. 답변 품질은 올라갔는데 "질문하러 가는 일" 자체는 그대로 남아 있는 셈이죠.

매일 아침 같은 질문을 반복하고 있다면 개선할 지점은 프롬프트가 아니라 실행 시점입니다. 이 글에서는 Gemini를 "물어보면 답하는 도구"에서 "정해둔 시각에 먼저 일해두는 도구"로 옮기는 방법을 정리합니다.

매일 같은 질문을 반복하는 게 진짜 낭비인 이유

반복 질문의 비용은 타이핑 시간이 아닙니다. 하루 1분 아끼자는 얘기였다면 애초에 고민할 가치도 없었을 겁니다. 진짜 비용은 다른 데 있습니다.

  • 맥락 전환 비용 — 하던 일을 멈추고 앱을 열고 질문을 떠올리는 과정에서 집중이 끊깁니다. 돌아와서 원래 하던 일에 다시 붙는 시간이 질문 자체보다 깁니다.
  • 누락 — 바쁜 날엔 아예 안 물어봅니다. 주 5일 중 2~3일만 하는 건 습관이 아니라 그때그때의 여유일 뿐입니다.
  • 타이밍 불일치 — 정보가 필요한 시점(출근길)과 물어보는 시점(자리에 앉은 뒤)이 어긋납니다. 늦게 받은 정보는 이미 쓸모가 절반입니다.

이 세 가지는 프롬프트를 아무리 잘 써도 해결되지 않습니다. 사람이 매번 방아쇠를 당겨야 하는 구조 자체를 바꿔야 합니다.

Gemini 활용법의 다음 단계: '예약 작업'으로 방아쇠 넘기기

Gemini 앱에는 지정한 시각이나 주기에 프롬프트를 자동 실행해 주는 예약 작업(Scheduled Actions) 기능이 있습니다. "월~금 아침 7시에 오늘 일정과 안 읽은 메일을 정리해 줘"처럼 한 번만 등록해두면, 그 뒤로는 내가 앱을 열지 않아도 결과가 준비됩니다. 프롬프트를 잘 쓰는 것과는 결이 다른 개선입니다. 답의 품질이 아니라 시작하는 주체가 바뀌기 때문입니다.

먼저 확인할 사용 조건

이 기능은 모든 계정에서 바로 켜지지 않습니다. 시작하기 전에 아래 세 가지를 확인하세요 (본 글 작성 시점 기준이며, 자세한 조건은 구글 Gemini 앱 고객센터의 작업 예약 안내에서 확인할 수 있습니다).

확인 항목 내용
구독 개인 계정은 Google AI Pro 또는 Ultra 구독이 필요합니다. 자격 요건을 갖춘 Workspace 비즈니스·교육 플랜에서도 제공됩니다.
활동 기록 Gemini 앱 활동 기록이 사용 중지되어 있으면 예약 작업을 쓸 수 없습니다.
개수 한도 한 계정에서 동시에 활성화할 수 있는 예약 작업은 최대 10개입니다.

여기서 가장 중요한 건 마지막 줄입니다. 10개라는 한도는 생각보다 빨리 찹니다. "이것도 자동화하면 좋겠는데" 싶은 걸 전부 등록하면 정작 중요한 자리가 없어집니다. 그래서 예약 작업은 많이 만드는 게 아니라 골라 넣는 기능으로 봐야 합니다.

예약에 어울리는 일과 어울리지 않는 일

10칸을 낭비하지 않으려면 기준이 필요합니다. 판단은 간단한 질문 하나로 갈립니다. "내가 물어보지 않아도 어차피 알아야 하는 정보인가?"

  • 어울리는 일 — 매일·매주 반복되고, 결과 형식이 거의 고정되어 있으며, 정해진 시각에 봐야 의미가 있는 것. 아침 일정·메일 브리핑, 주간 회고 질문지, 관심 주제의 주 1회 동향 정리 같은 것들입니다.
  • 어울리지 않는 일 — 그때그때 조건이 달라지는 것, 결과를 보고 바로 되물어야 하는 탐색형 작업, 한 번만 필요한 일. 이런 건 그냥 그 자리에서 물어보는 편이 빠릅니다.

정리하면 예약 작업은 '탐색'이 아니라 '정기 배송'에 가깝습니다. 답을 파고들어야 하는 일은 사람이 직접, 매번 같은 모양으로 받아보면 되는 일은 예약으로 넘기는 겁니다.

10칸을 채운다면 이런 순서로

처음부터 열 개를 다 쓰지 말고, 성격이 다른 세 종류로 시작해 보는 걸 권합니다. 서로 겹치지 않아야 어떤 유형이 나에게 맞는지 판단할 수 있습니다.

유형 주기 받는 목적
하루 브리핑 평일 아침 오늘 할 일의 윤곽을 자리에 앉기 전에 파악
주간 회고 질문 주 1회 금요일 한 주를 닫는 고정 질문 3개를 받아 직접 답하기
관심 주제 동향 주 1회 따라가야 할 분야를 놓치지 않기

세 개를 2주 굴려보면 대개 하나는 매번 열어보고, 하나는 가끔 보고, 하나는 아예 안 봅니다. 그 결과가 곧 나머지 칸을 어디에 쓸지 알려주는 답입니다.

실전: 예약 작업 정착시키는 4단계

1단계 — 최근 2주 대화에서 반복 질문 찾기

새로 만들지 말고 이미 하고 있는 걸 찾으세요. Gemini 대화 목록을 2주치만 훑어보면 비슷한 질문이 눈에 띕니다. 세 번 이상 반복된 질문이 1순위 후보입니다. 머릿속으로 "이런 게 있으면 좋겠다"며 상상해서 만든 예약은 대부분 2주 안에 안 보게 됩니다. 이미 반복하고 있다는 건 그 정보가 실제로 필요하다는 증거니까요.

2단계 — 결과물의 '형식'까지 프롬프트에 적기

예약 작업은 내가 옆에서 보고 있지 않다는 게 핵심 차이입니다. 애매하면 되물어 고칠 기회가 없으니, 출력 형식을 미리 못 박아야 합니다.

❌ "오늘 일정 정리해 줘"
✅ "오늘 캘린더 일정을 시간순 목록으로 정리하고, 준비물이 필요한 일정에는 한 줄로 준비 사항을 덧붙여 줘. 전체 10줄을 넘기지 마."

줄 수 제한, 순서, 항목 구성처럼 눈에 보이는 조건을 넣어두면 매일 같은 모양으로 도착합니다. 형식이 일정해야 훑어보는 시간도 줄어듭니다. 반대로 형식을 안 정해두면 어떤 날은 세 줄, 어떤 날은 스무 줄이 와서 결국 읽지 않게 됩니다.

3단계 — Gems와 역할 나누기

Gems는 반복하는 역할·말투·지시를 저장해 두는 기능이고, 예약 작업은 그 실행 시점을 정하는 기능입니다. 둘은 경쟁 관계가 아니라 "무엇을 어떻게"는 Gems, "언제"는 예약 작업으로 나눠서 생각하면 정리가 쉽습니다. 매번 같은 배경 설명을 붙이고 있었다면 그 부분을 Gem으로 빼두고, 예약 프롬프트에는 그날 필요한 요청만 짧게 남기세요. 프롬프트가 짧아질수록 나중에 고치기도 쉬워집니다.

4단계 — 2주 뒤 열어보고 정리하기

예약 작업의 진짜 함정은 안 읽는 알림이 쌓이는 것입니다. 자동으로 오니까 일하고 있다는 착각은 드는데, 정작 열어보지 않으면 아무 일도 안 일어난 것과 같습니다. 등록하고 2주가 지나면 한 번 점검하세요. 판단 기준은 하나입니다. "최근 2주 동안 이 결과를 실제로 열어봤는가?" 아니라면 지웁니다. 10칸을 비워두는 게 꽉 채우는 것보다 낫습니다.

구독까지 할 만한 기능일까

솔직하게 짚자면, 예약 작업 하나 때문에 유료 구독을 시작할 이유는 크지 않습니다. 이미 Google AI Pro나 Ultra를 쓰고 있는데 여태 안 켜봤다면 그건 확실히 손해지만, 무료로 쓰는 중이라면 먼저 2단계의 '형식까지 적는 프롬프트'부터 적용해 보세요. 자동 실행이 없어도 체감 차이가 납니다. 결국 예약 작업이 하는 일은 좋은 프롬프트를 제시간에 대신 눌러주는 것이지, 없던 답을 만들어 주는 게 아닙니다.

또 하나. 예약 작업이 캘린더나 메일 같은 개인 데이터를 다루게 되면, 어떤 정보에 접근하는지 등록 전에 한 번 확인하는 습관이 필요합니다. 회사 자료가 섞이는 경우라면 사내 정책을 먼저 확인하는 편이 안전합니다.

결론: 프롬프트보다 '시점'을 바꿀 차례

Gemini 활용법을 오래 찾아봤는데 시간이 크게 안 줄었다면, 문제는 질문의 완성도가 아니라 매번 사람이 시작 버튼을 눌러야 하는 구조일 가능성이 큽니다. 예약 작업은 그 버튼을 시계에 넘기는 기능이고, 10개라는 한도 덕분에 오히려 "정말 반복되는 일이 뭔지" 골라내게 만듭니다.

거창하게 시작할 필요는 없습니다. 오늘 Gemini 대화 목록을 2주치만 훑어보고 세 번 이상 반복한 질문 하나를 찾아, 그것부터 예약으로 옮겨보세요.

※ 본 글의 기능·요건 정보는 작성 시점 기준이며, 서비스 정책과 제공 범위는 변경될 수 있습니다. 구독·요금 관련 사항은 구글 공식 안내를 확인하세요.

Claude vs ChatGPT 2026: 회사 자료 붙여넣어도 될까 — 학습·보관 정책부터 확인하기

Claude vs ChatGPT 데이터 학습 정책 비교
Photo by freestocks on Unsplash

회의록을 요약하려고 AI 채팅창에 붙여넣으려던 순간, 손이 멈춘 적 있으신가요. 거래처 이름과 단가가 그대로 적힌 문서인데 "이거 어디로 가는 거지?" 싶은 그 찜찜함 말입니다. Claude vs ChatGPT를 비교하는 글은 대부분 성능과 가격을 다루지만, 실무에서 정작 발목을 잡는 건 "내가 넣은 내용이 학습에 쓰이느냐, 얼마나 보관되느냐"입니다. 이 글에서는 두 서비스의 데이터 학습·보관 정책이 어떻게 다른지, 개인 요금제와 업무용 요금제가 왜 정반대로 동작하는지, 그리고 오늘 당장 확인해야 할 설정 위치를 정리합니다. (본 글 작성 시점 기준이며, 정책은 수시로 바뀌므로 결정 전 공식 문서를 다시 확인하시기 바랍니다.)

왜 성능보다 이 항목을 먼저 봐야 할까

개인이 취미로 쓰는 글이라면 학습 여부가 큰 문제가 아닐 수 있습니다. 하지만 직장인이 AI에 넣는 자료는 성격이 다릅니다. 계약서 초안, 고객 문의 원문, 사내 기획서, 아직 공개되지 않은 일정 같은 것들이죠. 이런 자료는 한 번 외부 서비스로 넘어가면 되돌리기 어렵습니다.

더 중요한 건 대부분의 사람이 기본값을 그대로 쓴다는 점입니다. 두 서비스 모두 개인 요금제에서는 별도로 손대지 않으면 대화가 모델 개선에 쓰이는 쪽으로 기울어 있습니다. 성능 비교표를 아무리 열심히 봐도, 설정 화면을 한 번도 열어보지 않았다면 가장 중요한 선택을 하지 않은 셈입니다.

Claude vs ChatGPT, 개인 요금제의 학습 정책 비교

Claude(Anthropic)의 경우

Anthropic은 2025년 8월 28일 소비자 약관 및 개인정보 처리방침 업데이트를 통해, Free·Pro·Max 요금제 사용자의 대화와 코딩 세션을 모델 학습에 활용할 수 있도록 정책을 바꿨습니다. 핵심은 사용자가 직접 선택하게 했다는 점입니다. 신규 가입자는 가입 과정에서, 기존 사용자는 앱 내 안내를 통해 허용 여부를 고르도록 했습니다.

보관 기간도 선택에 따라 달라집니다. 학습에 동의한 경우 대화가 최대 5년까지 보관될 수 있고, 동의하지 않으면 기존과 같이 30일 기준으로 처리됩니다. 이 설정은 Anthropic 개인정보 센터의 모델 개선 설정 안내에서 확인할 수 있으며, 설정 화면의 "Help improve Claude" 항목을 끄면 됩니다.

한 가지 알아둘 점은, 학습을 꺼도 안전 관련 검토는 별개로 동작한다는 것입니다. 이용 정책 위반이 의심되어 분류 시스템에 걸린 대화는 별도 기준으로 검토·보관될 수 있습니다.

ChatGPT(OpenAI)의 경우

OpenAI 역시 개인 요금제(무료·Plus·Pro)에서는 대화가 모델 개선에 쓰이는 것이 기본입니다. 끄는 방법은 설정 → 데이터 제어(Data Controls) → "Improve the model for everyone" 토글을 해제하는 것입니다.

여기서 사람들이 자주 오해하는 부분이 있습니다. 이 토글을 끈다고 해서 지난 대화가 학습 데이터에서 빠지지는 않습니다. 앞으로의 대화에만 적용되는 설정이고, 이미 반영된 것은 되돌아가지 않습니다. 또 학습을 꺼도 남용 방지·안전 모니터링 목적의 보관은 별도로 이뤄집니다.

기록 자체를 남기고 싶지 않다면 임시 채팅(Temporary Chat)이 대안입니다. 대화 목록에 남지 않고, 메모리를 만들거나 참조하지 않으며, 학습에도 쓰이지 않습니다. 다만 "전송 자체를 안 한다"는 뜻은 아니고 30일 내 삭제되는 구조라는 점은 구분해서 이해해야 합니다.

한눈에 보는 비교

구분 Claude (Free·Pro·Max) ChatGPT (무료·Plus·Pro)
개인 요금제 학습 사용자가 선택 (허용 시 학습에 활용) 기본 활성, 직접 꺼야 함
끄는 위치 설정 → 개인정보 → Help improve Claude 설정 → 데이터 제어 → Improve the model for everyone
보관 기간 학습 허용 시 최대 5년 / 거부 시 30일 기준 임시 채팅은 30일 내 삭제
학습을 꺼도 남는 것 안전 정책 위반 의심 건은 별도 검토 남용 방지·안전 모니터링 목적 보관
기록 안 남기는 모드 임시 채팅(Temporary Chat)
업무용 요금제 상용 약관 적용 (소비자 약관과 별개) 기본적으로 학습에 미사용

업무용 요금제는 이야기가 완전히 다릅니다

여기서 많은 분들이 놓치는 지점이 있습니다. 개인 요금제와 업무용 요금제는 적용되는 약관 자체가 다릅니다.

Anthropic의 소비자 약관 변경은 Claude for Work, Claude for Government, Claude for Education, 그리고 상용 약관이 적용되는 API 이용에는 해당하지 않습니다. 즉 회사에서 도입한 팀 플랜을 쓰고 있다면, 개인 계정 기준으로 걱정하던 내용이 그대로 적용되지는 않습니다.

OpenAI도 마찬가지입니다. OpenAI 공식 안내에 따르면 ChatGPT Team, Enterprise, Edu 및 API 플랫폼의 입력·출력은 기본적으로 모델 학습에 사용되지 않습니다. API 사용자는 명시적으로 동의(opt-in)하지 않는 한 학습 대상에서 제외됩니다.

정리하면 이렇습니다. "AI에 회사 자료를 넣어도 되나?"의 답은 서비스 이름이 아니라 어떤 계정으로 로그인했느냐에 달려 있습니다. 같은 ChatGPT라도 개인 계정과 회사 Team 계정의 기본값이 정반대입니다.

실무에서 가장 위험한 조합은 이겁니다. 회사가 Team 플랜을 결제해 뒀는데, 정작 직원은 퇴근길에 익숙한 개인 계정으로 로그인해 같은 문서를 붙여넣는 경우죠. 도구는 같아 보여도 적용되는 약관은 완전히 다릅니다. 브라우저 프로필을 업무용과 개인용으로 분리해 두면 이런 실수를 상당히 줄일 수 있습니다.

오늘 바로 할 수 있는 4단계 점검

1단계: 지금 쓰는 계정 종류부터 확인

설정 화면에서 요금제 이름을 확인하세요. Free/Pro/Plus/Max처럼 개인 요금제라면 아래 단계를 모두 밟아야 합니다. Team/Enterprise/Edu 같은 조직 계정이라면 기본 보호 수준이 다르므로, 회사 IT 담당자에게 내부 지침을 확인하는 편이 빠릅니다.

2단계: 학습 설정 토글 직접 열어보기

Claude는 개인정보 설정의 "Help improve Claude", ChatGPT는 데이터 제어의 "Improve the model for everyone"입니다. 5분이면 끝나는 일인데, 실제로 열어본 적 없는 분이 많습니다. 지금 켜져 있는지 꺼져 있는지 눈으로 확인하는 것 자체가 목적입니다.

3단계: 넣기 전에 "3초 룰" 적용하기

붙여넣기 전에 세 가지만 훑어보세요.

  • 실명·연락처·주민번호가 들어 있는가 → 삭제하거나 A씨, B사로 치환
  • 계약 단가·미공개 일정이 들어 있는가 → 필요한 부분만 잘라서 사용
  • 고객이 보낸 원문인가 → 요약해서 넣기

예를 들어 "○○물산 김철수 부장님과 3월 12일 미팅, 단가 협의" 같은 회의록은 "거래처 담당자와 미팅, 단가 협의"로 바꿔도 요약 품질에는 거의 영향이 없습니다. 대부분의 업무 요청은 고유명사 없이도 충분히 처리됩니다. AI는 문서의 구조와 맥락을 보고 일하지, 거래처 실명을 알아야 요약을 잘하는 게 아니기 때문입니다.

4단계: 민감한 건은 기록 안 남는 모드로

ChatGPT라면 임시 채팅을 쓰면 대화 목록과 메모리에 남지 않습니다. 인사 관련 고민, 이직 준비, 건강 상담처럼 히스토리에 쌓이는 것 자체가 부담스러운 주제에 특히 유용합니다. 반대로 프로젝트처럼 맥락이 계속 이어져야 하는 작업에는 맞지 않으니, 주제 성격에 따라 구분해 쓰는 게 좋습니다.

흔한 오해 3가지

  • "학습을 끄면 내 대화가 즉시 삭제된다" → 아닙니다. 학습 제외와 보관 삭제는 별개 개념입니다. 안전 모니터링 목적의 보관은 유지될 수 있습니다.
  • "지금 끄면 예전 대화도 빠진다" → 아닙니다. 설정은 앞으로의 대화에 적용됩니다. 그래서 미루지 말고 지금 확인하는 게 의미가 있습니다.
  • "유료 결제하면 자동으로 학습에서 빠진다" → 아닙니다. 개인 유료 요금제도 별도로 끄지 않으면 기본값을 따릅니다. 돈을 냈느냐가 아니라 어떤 약관이 적용되는 계정이냐가 기준입니다.

결론

Claude vs ChatGPT를 고를 때 벤치마크 점수보다 먼저 봐야 할 건, 내가 매일 넣는 자료가 어디까지 쓰이느냐입니다. 개인 요금제는 두 서비스 모두 사용자가 직접 설정을 확인해야 하고, 업무용 요금제는 기본 보호 수준이 다릅니다. 오늘 두 서비스의 설정 화면을 한 번씩만 열어보고, 지금 어떤 상태인지 눈으로 확인하는 것부터 시작해보세요.

※ 본 글은 작성 시점의 공개 자료를 바탕으로 한 일반 정보 제공 목적이며, 각 서비스의 약관과 정책은 변경될 수 있습니다. 회사 자료 취급 기준은 개별 상황과 사내 규정에 따라 다를 수 있으니 필요 시 전문가 및 사내 담당 부서 상담을 권장합니다.

AI 블로그 자동화 2026: 진짜 병목은 초안이 아니라 '사실 확인' — 검증을 파이프라인에 넣는 4단계

AI 블로그 자동화
Photo by Andrew Neel on Unsplash

AI 블로그 자동화를 한 번이라도 구성해 본 분이라면 비슷한 경험을 하셨을 겁니다. 키워드를 넣으면 몇 분 만에 글 한 편이 나옵니다. 문장도 매끄럽고 소제목도 알아서 붙습니다. 그런데 막상 발행 버튼을 누르려고 글을 다시 읽어보면, 손이 멈춥니다. "이 수치, 진짜 맞나?" 결국 링크를 하나씩 열어보며 확인하다가, 글을 뽑는 시간보다 확인하는 시간이 더 길어집니다. 자동화를 했는데 정작 손이 덜 가지 않는 이 느낌, 원인은 대부분 같은 곳에 있습니다.

AI 블로그 자동화의 진짜 병목은 초안이 아니라 '사실 확인'이다

많은 사람이 자동화를 설계할 때 "글을 얼마나 빨리 뽑느냐"를 기준으로 삼습니다. 하지만 초안 생성은 이미 충분히 빠르고 저렴한 단계입니다. 병목은 그다음입니다. 나온 글이 사실인지 확인하는 일은 여전히 사람 몫으로 남아 있고, 이 단계는 자동화가 거의 안 된 채 방치되는 경우가 많습니다.

더 문제인 건, 이 검증 부담이 글을 많이 뽑을수록 그대로 비례해서 늘어난다는 점입니다. 하루 한 편이면 어떻게든 읽어보겠지만, 하루 네 편이 되는 순간 "대충 맞겠지"라고 넘기게 됩니다. 자동화가 확대될수록 검증은 오히려 얇아지는 구조인 셈입니다. 그래서 자동화 설계에서 진짜로 공들여야 하는 지점은 생성 속도가 아니라 검증 절차입니다.

근거를 줘도 오류는 남는다

여기서 흔한 오해가 하나 있습니다. "요약만 시키면 안전하지 않나?"라는 생각입니다. 내가 자료를 넣어줬으니 모델이 지어낼 여지가 없다는 논리입니다.

이 부분은 실제로 측정되고 있습니다. Vectara가 공개 운영하는 Hallucination Leaderboard는 짧은 문서를 주고 요약하게 한 뒤, 요약문이 원문과 사실적으로 어긋나는 비율을 모델별로 집계합니다. 본 글 작성 시점 기준으로 상위권 모델들의 수치는 낮은 한 자릿수 퍼센트대에 머물러 있습니다. 예전보다 크게 좋아진 건 분명하지만, 중요한 건 그 값이 0이 아니라는 사실입니다.

원문이 눈앞에 주어진 요약 작업에서도 어긋남이 남는다면, 아무 자료 없이 주제만 던지고 "1500자로 써줘"라고 했을 때 더 정확해질 이유는 없습니다. 특히 위험한 건 자주 다뤄지지 않는 세부 정보입니다. 널리 알려진 상식은 대체로 잘 맞지만, 특정 서비스의 수수료율이나 최근 바뀐 제도처럼 좁고 구체적인 항목일수록 그럴듯한 형태로 틀리기 쉽습니다. 하필 블로그 글에서 독자가 가장 신뢰하고 인용하는 부분이 바로 그 대목입니다.

그리고 이런 오류는 티가 잘 나지 않습니다. 문장이 어색하면 바로 눈에 걸리지만, 사실이 틀린 문장은 오히려 더 매끄럽게 읽힙니다. 맞춤법 검사기로도, 가독성 점수로도 걸러지지 않습니다. 별도의 절차를 두지 않으면 그냥 통과한다고 보는 편이 맞습니다.

검증을 파이프라인 안으로 집어넣는 4단계

해법은 "사람이 더 꼼꼼히 읽기"가 아닙니다. 그건 확장이 안 됩니다. 검증 자체를 자동화의 한 단계로 만들어 넣어야 합니다.

1단계 — 쓰기 전에 검색부터 시킨다

가장 효과가 큰 조치입니다. 주제만 던지지 말고, 먼저 검색해서 자료를 모으게 한 다음 그 자료 안에서만 쓰게 하는 순서로 바꿉니다. 모델이 기억에 의존해 빈칸을 채워 넣는 구간을 줄이는 것이 핵심입니다. 이때 프롬프트에 "검색 결과에 없는 내용은 쓰지 말 것"을 명시적으로 넣어야 효과가 있습니다. 순서만 바꿔도 결과가 달라집니다.

2단계 — 검증할 문장만 골라낸다

글 전체를 똑같은 강도로 볼 필요는 없습니다. 확인이 필요한 문장은 사실상 유형이 정해져 있습니다.

유형 예시 확인 방법
숫자 수수료율, 한도, 가격, 수익률 공식 페이지에서 원값 대조
날짜·기간 시행일, 신청 마감일 공고 원문 확인
제품·기능명 특정 도구의 기능 이름 공식 문서에 실재하는지 확인
인용 "○○에 따르면" 그 출처가 실제로 있는지 확인

반대로 "꾸준히 하면 도움이 됩니다" 같은 일반론은 검증 대상이 아닙니다. 이 분류만 해도 실제로 확인해야 할 분량이 눈에 띄게 줄어듭니다.

3단계 — 출처를 못 대면 삭제한다

검증 단계에서 가장 중요한 규칙입니다. 골라낸 문장마다 "이 값의 출처 링크를 댈 수 있는가"를 묻고, 못 대면 고치지 말고 지웁니다. 여기서 흔히 저지르는 실수가 "약 ○○ 수준"처럼 표현을 흐려서 남기는 것입니다. 이러면 틀린 정보가 검증을 통과한 것처럼 위장된 채 그대로 발행됩니다. 애매한 수치는 문장째 빼고, 그 자리를 검증 가능한 다른 내용으로 채우는 편이 낫습니다. 문단 하나가 통째로 빠져도 괜찮습니다.

4단계 — 살아남은 사실에 링크를 붙인다

확인된 구체 사실에는 1차 출처를 인라인 링크로 답니다. 정부·공공기관 페이지, 공식 제품 문서, 주요 언론 보도 순으로 신뢰도가 높습니다. 개수를 채우려고 억지로 넣을 필요는 없고, 방법론 위주의 글이라면 링크가 없어도 자연스럽습니다. 다만 이 작업에는 부수 효과가 있습니다. 링크를 달려고 출처를 찾다 보면, 검증을 빠져나간 문장이 이 시점에 걸리는 경우가 꽤 있습니다.

운영에서 놓치기 쉬운 것들

몇 가지만 덧붙이겠습니다. 첫째, 시점에 의존하는 정보에는 "본 글 작성 시점 기준"을 반드시 표기하세요. 오늘 맞는 수치가 반년 뒤에도 맞다는 보장은 없습니다. 둘째, 검증 라운드는 한 번으로 제한하는 편이 낫습니다. 고치고 또 고치다 보면 시간만 쓰고 결과는 크게 달라지지 않습니다. 애매하면 삭제 쪽으로 기울이세요. 셋째, 검증 결과를 한 줄이라도 로그로 남겨두면 어느 유형의 오류가 반복되는지 나중에 파악할 수 있고, 그 패턴을 프롬프트에 다시 반영할 수 있습니다.

결론: 자동화의 품질은 삭제 기준에서 갈린다

AI 블로그 자동화에서 경쟁력은 글을 몇 편 뽑느냐가 아니라, 확인되지 않은 문장을 얼마나 단호하게 걷어내느냐에서 갈립니다. 생성은 이미 누구나 할 수 있는 단계가 됐고, 남은 차이는 검증 절차의 유무입니다. 오늘 돌리는 자동화 파이프라인에 '출처를 못 대면 삭제한다'는 규칙 한 줄부터 추가해 보세요. 글 편수는 조금 줄어도, 독자가 다시 찾아오는 글이 됩니다.

본 글은 일반 정보 제공 목적이며, 개별 상황에 따라 다를 수 있으니 전문가 상담을 권장합니다.

AI 코딩 도구 비교 2026: 구독료 2만원인데 청구서는 왜 더 나올까 — 사용량 과금 시대에 고르는 법

"월 2만 원짜리 구독인 줄 알고 결제했는데, 월말에 추가 요금이 붙었어요." 요즘 AI 코딩 도구 비교를 하다 보면 이런 하소연을 자주 봅니다. 예전에는 '월 얼마'만 보면 끝이었는데, 2026년 들어 주요 도구들이 잇따라 사용량 기반 과금(usage-based billing)으로 구조를 바꾸면서 사정이 달라졌어요. 같은 도구라도 하루 종일 에이전트를 돌리는 사람과 가끔 자동완성만 쓰는 사람의 실제 청구액이 크게 벌어집니다. 이 글에서는 '왜 구독료 하나로는 비용을 알 수 없게 됐는지', 대표 도구 세 가지의 과금 구조가 어떻게 다른지, 그리고 내 사용 패턴에 맞게 고르는 법까지 정리했습니다. (요금 정보는 본 글 작성 시점인 2026년 8월 기준입니다.)

왜 '월 얼마' 하나로는 비용을 알 수 없게 됐나

2026년 AI 코딩 도구 비교에서 가장 크게 달라진 지점은 과금 방식입니다. 대표적으로 GitHub Copilot은 2026년 6월 1일부터 모든 요금제를 사용량 기반 과금으로 전환했어요. 이제는 요금제마다 매달 일정량의 'AI 크레딧'이 포함되고, 그 한도를 넘겨 쓰면 초과분이 따로 청구됩니다. 크레딧은 1크레딧 = 0.01달러 기준으로 계산돼요.

이게 왜 중요할까요? 예전 정액제에서는 아무리 많이 써도 구독료가 고정이었습니다. 하지만 사용량 과금에서는 '포함된 한도'가 실질적인 커트라인이 되고, 무거운 작업(여러 파일을 오가는 리팩토링, 장시간 에이전트 실행)을 많이 하는 사람일수록 한도를 빨리 소진합니다. 즉 표지에 적힌 구독료는 '시작 가격'이지 '내가 낼 돈'이 아니게 된 거예요. 반대로 자동완성 위주로 가볍게 쓰는 사람은 포함 한도조차 다 쓰지 못하는 경우가 많아, 같은 요금제라도 체감 부담이 전혀 다릅니다.

AI 코딩 도구 비교: 세 도구의 과금 구조 한눈에 보기

가장 많이 비교되는 Cursor, GitHub Copilot, Claude Code를 과금 구조 중심으로 정리하면 다음과 같습니다.

도구형태개인 요금제(작성 시점)비용이 늘어나는 지점
Cursor 독립형 AI 편집기(IDE) Pro $20 · Pro+ $60 · Ultra $200 구독료에 포함된 모델 사용량 한도 초과분
GitHub Copilot 여러 IDE용 확장 Free · Pro $10 · Pro+ $39 월 포함 AI 크레딧 초과분(1크레딧=$0.01)
Claude Code 터미널 기반 에이전트 Claude 구독(Pro·Max) 또는 API 사용량 API 사용량 방식일 때 실행량에 비례

Cursor: 구독료에 '사용량이 포함'된 구조

Cursor 공식 요금제 안내를 보면 Pro($20)에는 매달 $20어치, Pro+($60)에는 $70어치, Ultra($200)에는 $400어치의 모델 사용량이 포함됩니다. 탭 자동완성은 요금제 공통으로 무제한이지만, 에이전트로 여러 파일을 다루는 작업은 이 사용량을 소모해요. 그래서 Cursor는 매일 에이전트를 쓰는 사용자에겐 Pro+를, 헤비하게 돌리는 사용자에겐 Ultra를 권장합니다. 즉 '$20이면 충분하다'는 가벼운 사용 기준이라는 점을 회사도 명시하고 있는 셈이에요.

GitHub Copilot: 크레딧을 초과하면 과금

Copilot은 무료 요금제가 있고 Pro는 월 $10, Pro+는 월 $39입니다. 2026년 6월 전환 이후에는 각 요금제에 매달 AI 크레딧이 포함되고, 그 안에서 쓰면 구독료 이상은 청구되지 않도록 설계돼 있어요. 문제는 크레딧을 다 쓴 뒤부터입니다. 자동완성 위주로만 쓰면 여유롭지만, 채팅·에이전트를 자주 부르면 크레딧 소모가 빨라집니다.

Claude Code: 터미널에서 실행량만큼

Claude Code는 IDE가 아니라 터미널에서 동작하는 에이전트형 도구입니다. Claude 구독제(Pro·Max)에 포함해서 쓰거나, API 사용량 과금 방식으로 쓸 수 있어요. 여러 파일에 걸친 복잡한 리팩토링처럼 '한 번에 크게 일을 시키는' 작업에 강점이 있는 대신, API 방식으로 쓸 때는 실행을 많이 할수록 비용이 비례해서 늘어난다는 점을 기억해야 합니다.

내 사용 패턴으로 도구 고르는 법

도구 자체의 우열보다 '내가 어떻게 쓰는가'가 실제 비용을 좌우합니다. 아래 세 유형으로 나눠 보세요.

1) 자동완성 위주의 가벼운 사용자

코드를 직접 짜면서 다음 줄 제안 정도만 받는다면 무거운 요금제가 필요 없습니다. Copilot 무료·Pro나 Cursor Pro처럼 낮은 구독료로 시작해도 한도를 넘길 일이 드물어요. 이 유형은 '싼 요금제 + 자동완성 품질'만 비교하면 됩니다.

2) 하루 종일 에이전트를 돌리는 헤비 사용자

여러 파일을 오가며 에이전트에게 작업을 위임하는 스타일이라면, 가장 싼 요금제로 시작해도 결국 한도를 넘겨 상위 요금제로 올라가게 됩니다. 이럴 땐 처음부터 '포함 사용량이 큰 요금제'를 고르는 편이 초과 과금보다 예측 가능해요. Cursor가 매일 에이전트 사용자에게 Pro+ 이상을 권하는 것도 같은 이유입니다.

3) 복잡한 리팩토링·대규모 작업 중심

기존 코드베이스 전체를 이해시켜 큰 변경을 맡기는 작업이 많다면, 터미널 에이전트인 Claude Code를 편집기(Cursor·Copilot)와 병행하는 조합이 흔히 쓰입니다. 일상 편집은 IDE에서, 무거운 작업은 터미널 에이전트에서 나눠 돌리는 식이죠. 다만 이 경우 두 곳에서 각각 비용이 발생하므로 합산 지출을 미리 계산해 두는 게 좋습니다.

가상 시나리오로 보는 비용 차이

이해를 돕기 위해 같은 도구를 쓰는 두 사람을 가정해 볼게요. A는 주로 코드를 직접 쓰면서 자동완성만 받고, 채팅은 하루 몇 번 정도만 씁니다. B는 아침부터 저녁까지 "이 기능 전체를 이렇게 바꿔줘" 하고 에이전트에게 통째로 위임하죠. 같은 요금제를 결제해도 A는 포함 한도 안에서 여유롭게 끝나는 반면, B는 한도를 며칠 만에 소진하고 초과분을 추가로 내거나 상위 요금제로 갈아타게 됩니다. 도구가 나빠서가 아니라 '작업의 무게'가 다르기 때문이에요. 그래서 남의 추천 요금제를 그대로 따르기보다, 내 하루가 A에 가까운지 B에 가까운지부터 판단하는 게 먼저입니다.

자동완성 품질과 에이전트 능력은 별개다

비용만큼 자주 놓치는 게 '어떤 작업에 강한가'입니다. 자동완성은 타이핑 흐름을 끊지 않는 속도와 정확도가 중요하고, 에이전트는 여러 파일에 걸친 맥락을 얼마나 잘 잡느냐가 관건이에요. 둘은 평가 기준이 다릅니다. 자동완성이 빠른 도구가 대규모 리팩토링에서도 최고라는 보장은 없고, 그 반대도 마찬가지예요. 그래서 "무엇을 가장 자주 하는가"를 먼저 정한 뒤, 그 작업에서의 체감 품질을 무료 체험이나 저가 요금제로 확인하는 편이 안전합니다.

요금 폭탄을 피하는 체크리스트

  • 구독 전, 요금제에 '포함된 사용량/크레딧'이 얼마인지부터 확인한다.
  • 내 작업이 자동완성 위주인지, 에이전트 위주인지 스스로 구분한다.
  • 사용량 알림·한도 설정 기능이 있으면 켜 두고 첫 달 실제 소모량을 관찰한다.
  • 여러 도구를 병행한다면 각각의 청구서를 합쳐 월 총액으로 본다.
  • 가격·크레딧 정책은 자주 바뀌므로 결제 전 공식 요금제 페이지를 다시 확인한다.

자주 묻는 질문(FAQ)

Q. 비싼 요금제일수록 좋은가요?
꼭 그렇진 않습니다. 가벼운 사용자에겐 초과 과금이 날 일이 거의 없어 낮은 요금제가 오히려 합리적입니다. '내 사용량'을 먼저 파악하는 게 순서예요.

Q. 하나만 써야 하나요?
꼭 그렇진 않습니다. 실제로 일상 편집은 IDE 도구로, 복잡한 작업은 터미널 에이전트로 나눠 쓰는 조합이 많이 언급됩니다. 대신 합산 비용은 챙겨 보세요.

Q. 가격이 자꾸 바뀌던데요?
맞습니다. 2026년 들어 과금 구조 개편이 잦았어요. 그래서 이 글의 숫자도 '작성 시점 기준'이며, 결제 전 공식 페이지 확인이 사실상 필수입니다.

결론

이제 AI 코딩 도구 비교의 핵심은 '월 얼마'가 아니라 '내 사용량에서 실제로 얼마가 나오는가'입니다. 표지 가격만 보고 고르면 헤비 사용자는 초과 과금에, 가벼운 사용자는 불필요한 상위 요금제에 돈을 흘리기 쉬워요. 오늘 바로 최근 한 달 내 작업이 자동완성 위주였는지 에이전트 위주였는지 떠올려 보고, 후보 도구의 공식 요금제 페이지에서 '포함 사용량'부터 확인해 보세요.

본 글은 일반 정보 제공 목적이며, 요금·정책은 수시로 변동될 수 있으니 결제 전 각 서비스의 공식 안내를 확인하시기 바랍니다.

Cursor AI 개발 2026: AI가 코딩 규칙을 자꾸 무시한다면 — .cursorrules 대신 쓰는 규칙 파일

Cursor AI 개발 규칙 설정을 다루는 개발자
Photo by Danial Igdery on Unsplash

Cursor AI 개발을 하다 보면 답답할 때가 있습니다. 분명히 "우리 프로젝트는 함수형으로 짜고, any 타입 쓰지 말라"고 채팅으로 몇 번을 말했는데, 새 파일을 만들면 또 any 범벅으로 코드를 뱉어내죠. 매번 같은 잔소리를 반복하는 기분이 든다면, 문제는 AI가 멍청해서가 아니라 규칙을 넣는 자리가 틀렸기 때문일 가능성이 높습니다. 이 글에서는 Cursor AI 개발에서 코딩 규칙이 왜 자꾸 무시되는지, 그리고 예전에 쓰던 .cursorrules 대신 지금 표준이 된 규칙 파일 두 가지를 어떻게 세팅하는지 정리합니다.

왜 Cursor AI 개발에서 규칙이 계속 무시될까

가장 흔한 원인은 규칙을 채팅창에만 적어두는 것입니다. 채팅으로 준 지시는 그 대화 안에서만 유효하고, 새 대화를 열거나 에이전트가 백그라운드로 도는 순간 증발합니다. 그래서 많은 사람이 프로젝트 루트에 .cursorrules 파일을 두는 방식을 써 왔는데, 여기에 함정이 있습니다.

Cursor 공식 문서 기준으로 루트의 .cursorrules는 레거시(구형) 포맷입니다. 특히 자율적으로 여러 파일을 고치는 Agent(에이전트) 모드에서는 이 파일이 읽히지 않습니다. 채팅과 탭 자동완성에서는 참고되지만, 정작 대규모 리팩터링이나 멀티파일 편집처럼 규칙이 제일 중요한 순간에 빠져버리는 겁니다. "규칙 파일까지 만들었는데 왜 안 지키지?"의 정체가 대부분 이것입니다.

.cursor/rules와 AGENTS.md — 지금의 규칙 파일 두 가지

2026년 현재 규칙을 넣는 표준 자리는 두 곳입니다. 성격이 다르니 역할을 나눠 쓰는 게 핵심입니다.

구분 .cursor/rules/*.mdc AGENTS.md
위치 프로젝트 내 .cursor/rules/ 폴더 프로젝트 루트
성격 Cursor 전용, 조건부 적용 세밀 제어 도구 중립 개방형 표준
강점 파일 유형별·상황별로 규칙 켜고 끄기 한 파일로 여러 AI 도구가 공유
적합한 내용 프레임워크별 코딩 컨벤션, 세부 제약 프로젝트 개요, 빌드·테스트 명령, 브랜치 규칙

.cursor/rules(.mdc): 상황에 맞게 규칙을 켜고 끈다

모던 규칙은 .cursor/rules/ 폴더 안에 .mdc 확장자 파일로 둡니다. Cursor 공식 문서에 따르면 .mdc는 "설정이 붙은 마크다운"으로, 상단 YAML 프론트매터에 세 가지 필드를 넣어 언제 이 규칙이 적용될지를 제어합니다.

  • description: 이 규칙이 무슨 용도인지 한 줄 설명 (AI가 필요할 때 스스로 불러오는 판단 근거)
  • globs: 적용 대상 파일 패턴 (예: **/*.tsx)
  • alwaysApply: 항상 불러올지 여부(true/false)

이 조합으로 활성화 방식이 네 가지로 나뉩니다. ① Always(alwaysApply: true)는 늘 로드 — 기술 스택·폴더 구조처럼 프로젝트 전반에 필요한 것. ② Auto Attached는 globs에 맞는 파일을 열거나 편집할 때만 자동 적용. ③ Agent Requested는 description을 보고 AI가 필요하다고 판단하면 끌어옴. ④ Manual@규칙이름으로 직접 호출. 예를 들어 리액트 컴포넌트 규칙을 globs: ["**/*.tsx"]로 걸어두면, 백엔드 파일을 만질 땐 끼어들지 않아 컨텍스트가 깔끔해집니다.

실제 파일은 이런 모양입니다. 예컨대 .cursor/rules/react.mdc를 아래처럼 두면, .tsx 파일을 편집할 때만 이 규칙이 붙습니다.

---
description: React 컴포넌트 작성 규칙
globs: ["**/*.tsx"]
alwaysApply: false
---
- 함수형 컴포넌트만 사용한다.
- any 대신 명시적 타입을 쓴다.
- 상태 로직은 커스텀 훅으로 분리한다.

여기서 핵심은 globs로 범위를 좁히는 것입니다. 프론트엔드 규칙이 백엔드 파일까지 따라붙으면 불필요한 컨텍스트가 늘고, AI가 엉뚱한 규칙을 적용할 여지도 생깁니다. "이 규칙이 언제 켜져야 하는가"를 파일 패턴으로 명확히 지정해 두는 것이 요령입니다.

AGENTS.md: 여러 AI 도구가 함께 읽는 한 장

AGENTS.md는 특정 도구에 묶이지 않은 개방형 표준입니다. OpenAI에서 시작해 현재는 리눅스 재단 산하에서 관리되며, Cursor뿐 아니라 Codex·Copilot·Gemini CLI·Aider·Windsurf·Zed 등 여러 에이전트가 같은 파일을 그대로 읽습니다. 팀원마다 쓰는 AI 도구가 다르다면, 이 한 파일이 단일 기준점이 됩니다.

중요한 차이가 하나 더 있습니다. AGENTS.md는 Chat·Composer·Agent 모드를 가리지 않고 읽힙니다. 앞서 말한 .cursorrules가 에이전트 모드에서 빠지는 것과 대비되는 지점이죠. 그래서 "이 프로젝트가 뭘 하는지, 어떤 명령으로 빌드·테스트하는지, 커밋 전 무엇을 확인해야 하는지" 같은 프로젝트 공통 지식은 AGENTS.md에 두는 편이 안전합니다. 반대로 특정 프레임워크의 세부 코딩 스타일처럼 파일마다 켜고 꺼야 하는 규칙은 .cursor/rules가 더 적합하니, 둘을 경쟁 관계가 아니라 역할 분담으로 보는 게 맞습니다.

실전: 규칙이 먹히게 만드는 4단계

1단계 — 공통 지식은 AGENTS.md에

루트에 AGENTS.md를 만들고 프로젝트 개요, 주 언어·프레임워크(버전 포함), 정확한 빌드·테스트 명령, 브랜치 규칙을 적습니다. 코드 스타일은 "언어 기본값과 다른 것만" 적는 게 요령입니다. 당연한 걸 잔뜩 적으면 정작 중요한 규칙이 묻힙니다. 예컨대 "테스트는 npm test로 돌린다", "메인 브랜치에 직접 커밋하지 않는다" 같은 실행 지침이 여기 들어갑니다.

2단계 — 세부 컨벤션은 .mdc로 쪼갠다

프레임워크별·영역별로 규칙 파일을 나눕니다. 하위 폴더도 지원하므로 .cursor/rules/frontend/react.mdc, .cursor/rules/backend/api.mdc처럼 정리하면 관리가 편합니다. 각 파일은 globs로 적용 범위를 좁혀두세요.

3단계 — 손으로 안 만들어도 된다

규칙 파일을 처음부터 손으로 쓸 필요는 없습니다. 채팅에서 /create-rule로 원하는 내용을 설명하면 프론트매터까지 갖춘 파일을 .cursor/rules에 생성해 줍니다. 또는 사이드바의 Customize → Rules → Add Rule 경로로도 만들 수 있습니다.

4단계 — git에 커밋해서 팀과 공유

규칙 파일은 반드시 git에 포함시키세요. 개인 설정처럼 로컬에만 두면 팀원은 여전히 규칙 없는 AI를 쓰게 됩니다. 커밋해 두면 저장소를 받는 모두가 같은 규칙 위에서 작업하게 됩니다.

자주 하는 실수 (FAQ)

  • .cursor/rules에 .md로 저장 — 프론트매터가 없는 일반 .md는 무시됩니다. 반드시 .mdc 확장자를 쓰세요.
  • 규칙 하나에 모든 걸 몰아넣기 — 수백 줄짜리 만능 규칙보다, 상황별로 쪼개 globs로 거는 편이 실제로 더 잘 지켜집니다.
  • 아직 .cursorrules만 믿기 — 에이전트 모드를 쓴다면 .cursor/rules나 AGENTS.md로 옮기는 것을 권장합니다.
  • 규칙에 배경 설명만 잔뜩 적기 — "~하는 게 좋다"는 서술보다 "함수형만 사용한다"처럼 짧고 명령형인 문장이 더 잘 지켜집니다.

참고: 요금제는 어디에 있나

본 글 작성 시점(2026년 8월) 기준 Cursor는 무료(Hobby) 플랜과 유료 플랜(개인용 Pro 월 20달러대부터 상위 등급까지)을 함께 제공하며, 사용량 기반 과금이 섞여 있어 실제 청구액이 플랜 표시가와 다를 수 있습니다. 규칙 파일 자체는 어느 플랜에서나 쓸 수 있으니 비용 부담 없이 먼저 세팅해 볼 수 있습니다. 다만 가격·한도는 자주 바뀌므로, 결제 전에는 항상 공식 요금 안내 페이지에서 최신 정보를 확인하세요.

결론

Cursor AI 개발에서 규칙이 무시되는 대부분의 이유는 AI 성능이 아니라 규칙을 넣는 자리 때문입니다. 프로젝트 공통 지식은 도구 중립 표준인 AGENTS.md에, 파일 유형별 세부 컨벤션은 .cursor/rules.mdc에 나눠 담고 git에 커밋하는 것 — 이 구조 하나면 같은 잔소리를 반복할 일이 크게 줄어듭니다. 오늘 여러분 프로젝트 루트에 AGENTS.md 한 장부터 만들어 보세요.

※ 본 글은 일반 정보 제공 목적이며, 제품의 기능·가격·정책은 업데이트에 따라 달라질 수 있으니 공식 문서에서 최신 내용을 확인하시기 바랍니다.

ChatGPT 프롬프트 2026: 설명을 길게 쓸수록 겉도는 이유 — 예시 2~3개로 출력 형식을 고정하는 법

원하는 결과를 얻으려고 ChatGPT 프롬프트에 설명을 계속 덧붙여 본 적 있으신가요. "표로 정리해 줘, 각 항목은 한 문장으로, 존댓말로, 이모지는 빼고…" 요구사항을 아무리 촘촘하게 적어도 답변의 형식은 매번 미묘하게 달라집니다. 어떤 날은 표로, 어떤 날은 불릿으로, 문장 길이도 제각각이죠. 설명을 길게 쓸수록 오히려 결과가 겉도는 이 느낌, 해결책은 의외로 단순합니다. 말로 설명하지 말고, 완성된 예시를 보여주는 것입니다.

왜 설명보다 예시가 형식을 잘 고정할까

프롬프트에 원하는 결과물의 예시(샘플) 한두 개를 직접 붙여 넣는 방식을 '퓨샷 프롬프팅(few-shot prompting)'이라고 부릅니다. 예시 없이 지시만 하는 '제로샷'과 대비되는 개념인데요. 모델은 추가 학습 없이도 프롬프트 안의 예시 패턴을 그대로 흉내 내어 답을 만들어 냅니다. Prompt Engineering Guide에서도 복잡하거나 형식이 까다로운 작업에서 제로샷이 흔들릴 때, 예시를 넣어 결과를 안정시키는 기법으로 소개합니다.

핵심은 추상적인 규칙보다 구체적인 샘플이 훨씬 덜 모호하다는 데 있습니다. "간결하게"라는 말은 사람마다 기준이 다르지만, "이렇게 생긴 결과물"을 하나 보여주면 길이·말투·구분 기호·들여쓰기까지 한 번에 전달됩니다. 말로 다 적기 힘든 규칙이 예시 안에는 이미 녹아 있는 셈이죠. 그래서 지시문을 다섯 줄 늘리는 것보다, 잘 만든 예시 하나를 붙이는 편이 형식을 훨씬 안정적으로 고정해 줍니다.

제로샷 vs 퓨샷, 언제 무엇을 쓸까

상황 추천 방식 이유
간단한 질문·요약 제로샷(예시 없이) 지시만으로 충분, 예시는 낭비
형식이 반복되는 작업
(분류·추출·표 만들기)
퓨샷(예시 2~3개) 패턴을 눈으로 보여줘야 고정됨
말투·문체가 중요한 글 퓨샷(내 글 샘플 1~2개) "내 톤"은 설명이 거의 불가능

ChatGPT 프롬프트에 예시를 넣는 실전 순서

거창한 문법은 필요 없습니다. 아래 순서대로 프롬프트를 짜면 됩니다.

  1. 작업을 한 줄로 지시한다. "아래 예시와 같은 형식으로 상품 설명을 만들어 줘"처럼 무엇을 원하는지 먼저 밝힙니다.
  2. 입력 → 출력 쌍을 예시로 붙인다. 실제로 원하는 결과물을 2~3개 완성된 형태로 보여줍니다. 이때 모든 예시의 형식을 똑같이 맞추는 것이 가장 중요합니다. 예시마다 줄바꿈·기호·항목 순서가 다르면 모델도 헷갈립니다.
  3. 마지막에 진짜 요청을 붙인다. 예시와 같은 형식의 '입력'만 주고 출력은 비워 두면, 모델이 그 패턴을 이어서 채웁니다.

예를 들어 고객 문의를 '긍정/부정/중립'으로 분류하고 싶다면, "문의: 배송이 빨라서 좋았어요 → 긍정", "문의: 포장이 찌그러져 왔네요 → 부정" 같은 예시를 두어 개 보여준 뒤 진짜 문의를 넣는 식입니다. 규칙을 장황하게 설명하는 것보다 결과가 훨씬 일정합니다.

그대로 따라 써 보는 예시 프롬프트

아래는 상품 후기를 한 줄 홍보 문구로 바꾸는 작업에 예시를 넣은 형태입니다. 지시 한 줄 → 예시 두 개 → 진짜 입력, 이 순서가 그대로 보입니다.

아래 예시와 같은 형식으로, 후기를 한 줄 홍보 문구로 바꿔 줘.

후기: 생각보다 가벼워서 하루 종일 들고 다녀도 안 힘들어요.
문구: 하루 종일 들어도 부담 없는 가벼움

후기: 색이 화면이랑 똑같아서 실물 보고 놀랐어요.
문구: 화면 그대로, 실물이 더 좋은 컬러

후기: 방수라서 비 오는 날에도 걱정 없이 썼어요.
문구:

마지막 줄의 '문구:'를 비워 두는 것이 포인트입니다. 모델은 앞의 두 예시가 만든 리듬(짧고, 명사로 끝나고, 과장 없는 톤)을 이어받아 세 번째 문구를 채웁니다. "짧고 담백하게 써 줘"라고 열 번 설명하는 것보다, 이 두 줄짜리 예시가 훨씬 정확하게 톤을 전달합니다.

예시는 몇 개가 적당할까

일반적으로 권장되는 범위는 1~5개이고, 대체로 2~3개에서 효과가 가장 좋습니다. OpenAI의 프롬프트 가이드도 "제로샷으로 잘 안 될 때에만 예시를 추가하고, 예시는 짧게 유지하라"는 취지로 안내합니다. 예시를 무작정 늘리면 두 가지 손해가 있습니다. 첫째, 예시가 길고 많아질수록 입력 토큰(맥락 창)을 잡아먹어 정작 본 작업에 쓸 공간이 줄어듭니다. 둘째, 다섯 개를 넘어가면 품질 개선 폭이 눈에 띄게 완만해집니다. 비슷한 예시를 반복하기보다, 서로 다른 유형을 하나씩 보여주는 편이 낫습니다.

이럴 때 특히 효과가 크다

퓨샷은 아무 데나 필요한 게 아니라, 같은 형식을 반복 생산할 때 빛을 발합니다. 대표적으로 이런 경우입니다.

  • 대량 분류·태깅: 문의 유형, 감정, 카테고리처럼 정해진 라벨을 반복해서 붙일 때
  • 정해진 틀의 문서 생성: 상품 설명, 회의록 요약, 이메일 답변처럼 매번 같은 뼈대를 채워야 할 때
  • 내 말투 재현: 내가 쓴 글 한두 편을 예시로 주고 "이 톤으로 이어 써 줘"라고 할 때

주의할 점 — 예시가 독이 되는 경우

예시가 항상 정답은 아닙니다. 몇 가지 주의점이 있습니다.

  • 예시의 편향이 그대로 옮겨간다. 예시가 전부 한쪽 결론(예: 모두 '긍정')이면 모델도 그쪽으로 쏠릴 수 있습니다. 라벨이 골고루 섞이도록 구성하세요.
  • 형식 불일치가 가장 흔한 실수다. 예시 A는 표, 예시 B는 문단이면 곤란합니다. 띄어쓰기·기호까지 통일해야 패턴이 살아납니다.
  • 추론 특화 모델에서는 오히려 방해가 될 수 있다. 단계적 추론에 최적화된 일부 모델에서는 예시를 붙이는 것보다, 문제와 원하는 출력 형식을 제로샷으로 명확히 설명하는 편이 더 나은 경우가 보고됩니다. 결과가 이상하면 예시를 빼고 지시만 남겨 비교해 보세요.

결론 — 규칙을 늘리기 전에 예시 하나를 붙여 보자

ChatGPT 프롬프트가 자꾸 겉돈다면, 설명을 더 붙이기 전에 "내가 원하는 완성본은 이렇게 생겼다"는 예시 하나를 먼저 보여주세요. 형식이 반복되는 작업일수록 예시 2~3개가 열 줄짜리 규칙보다 결과를 정확하게 고정해 줍니다. 다만 예시는 형식을 통일하고, 유형을 다양하게, 개수는 적게 — 이 세 가지만 기억하면 됩니다. 오늘 자주 쓰는 프롬프트 하나를 골라, 지시문 뒤에 완성된 예시 한 개를 붙여 결과가 얼마나 일정해지는지 직접 비교해 보세요.

※ 본 글은 2026년 8월 작성 시점 기준의 일반적인 프롬프트 작성 방법을 정리한 것으로, 특정 모델의 성능은 버전과 업데이트에 따라 달라질 수 있습니다.

노션 AI 활용 2026: 초안이 내 말투가 아니라 다시 쓴다면 — 톤·형식 지정으로 편집 줄이는 법

노션 AI 활용
Photo by Luke Southern on Unsplash

"초안이라도 빨리 뽑자"며 노션 AI에게 글을 시켰는데, 막상 나온 결과를 보니 내 말투가 아니라서 결국 처음부터 다시 쓴 경험이 있으신가요? 문장은 매끄러운데 어딘가 남의 옷을 입은 것 같고, 톤을 손보다 보면 차라리 백지에서 쓰는 게 나았겠다 싶어집니다. 노션 AI 활용에서 느끼는 실망의 대부분은 'AI가 못 써서'가 아니라, 무엇을 어떻게 써야 하는지 우리가 충분히 알려주지 않은 데서 옵니다. 오늘은 생성한 초안을 버리지 않고, 톤과 형식을 지정해 '다시 쓰기'를 줄이는 방법을 정리합니다. (본 글은 작성 시점 기준이며, 기능·요금은 수시로 바뀝니다.)

왜 초안을 통째로 다시 쓰게 될까

빈 페이지에서 스페이스바를 눌러 "블로그 글 써줘"처럼 막연하게 요청하면, AI는 가장 무난한 평균값의 문장을 내놓습니다. 독자도, 목적도, 길이도, 말투도 정해주지 않았으니 당연한 결과입니다. 문제는 이 '평균 문장'이 내 글과 미묘하게 어긋난다는 점입니다. 한 문장씩 고치다 보면 손대는 양이 새로 쓰는 양과 비슷해지고, 그래서 "AI 써봐야 소용없다"는 결론에 이르게 됩니다.

여기엔 심리적 함정도 있습니다. AI가 이미 그럴듯한 문장을 만들어 놓으면, 우리는 그 문장에 끌려가 원래 하려던 이야기를 잊습니다. 완성도 높아 보이는 남의 초안을 고치는 일은, 백지에 내 생각을 쏟아내는 것보다 오히려 더 피곤합니다. 그래서 '생성'에만 기대면 시간을 아끼려다 더 쓰는 역설이 생깁니다.

핵심은 노션 AI가 백지 생성만 하는 도구가 아니라는 데 있습니다. 이미 써 둔 문장을 드래그해 선택한 뒤 다듬는 편집 도구로 쓸 때 만족도가 훨씬 높습니다. 노션 공식 안내에 따르면 텍스트를 선택하면 문장 다듬기(Improve writing), 길이 줄이기·늘리기, 맞춤법 교정, 어조 변경(Change tone), 번역 같은 명령을 바로 적용할 수 있습니다(Notion 공식 도움말 참고). 즉, 0에서 100을 만들게 하지 말고, 내가 쓴 60을 90으로 올리는 데 쓰는 것이 요령입니다.

노션 AI 활용의 갈림길: 생성이 아니라 '지정'

같은 도구인데 결과가 갈리는 이유는 지시의 구체성입니다. 아래처럼 상황에 맞는 명령을 골라 쓰면, 초안을 버리는 일이 눈에 띄게 줄어듭니다.

상황 추천 접근
말투가 남의 글 같다 어조 변경(Change tone)으로 '친근하게/간결하게' 지정
문장이 늘어진다 길이 줄이기(Make shorter)로 핵심만 남기기
메모가 너무 짧다 길이 늘리기(Make longer)로 살 붙이되 사실은 직접 확인
초안 자체가 밋밋하다 내가 쓴 문단을 선택 후 문장 다듬기(Improve writing)
영어 문서로 바꿔야 한다 번역(Translate)으로 초벌 후 핵심 용어만 직접 검수

여기서 중요한 원칙 하나. AI에게 사실·수치를 새로 만들어 넣게 하지 마세요. 길이 늘리기나 초안 생성은 문장을 그럴듯하게 채우는 데 강하지만, 없는 통계·인용을 지어낼 수도 있습니다. 숫자와 출처는 반드시 내가 직접 넣고, AI에게는 '표현'만 맡기는 것이 안전합니다. 이 원칙 하나만 지켜도 AI가 만든 글에서 가장 위험한 부분인 '그럴듯한 거짓말'을 걸러낼 수 있습니다.

다시 쓰기를 줄이는 4가지 지정법

1. 요청에 독자·목적·길이·톤을 함께 적는다

"블로그 글 써줘" 대신 "직장인 독자에게, 노션 정리 팁을, 친근하지만 담백한 말투로, 500자 내외로"처럼 네 가지를 붙입니다. 이 네 요소(독자·목적·길이·톤)를 명시하는 것만으로 초안의 방향이 크게 달라져, 이후 손볼 양이 줄어듭니다. 반대로 이 중 하나라도 비면, AI는 빈칸을 자기 마음대로 채우고 그 부분이 곧 여러분이 다시 고쳐야 할 지점이 됩니다.

2. '생성'보다 '선택 후 편집' 흐름을 기본으로

먼저 뼈대와 핵심 문장을 내 손으로 거칠게 써 둡니다. 완결된 문장이 아니어도 좋습니다. 그다음 그 문단을 드래그해 어조 변경·문장 다듬기를 적용하면, AI가 내 논리 위에서 표현만 손봐 주므로 '내 글'의 결이 유지됩니다. 백지에서 생성한 글보다 고쳐 쓸 일이 훨씬 적고, 무엇보다 내가 원래 하려던 이야기가 사라지지 않습니다.

3. 내 말투 샘플을 예시로 붙인다

내가 예전에 쓴 문단 한두 개를 함께 붙이고 "이 말투를 유지해서 다듬어줘"라고 하면, 추상적인 '친근하게'보다 훨씬 내 목소리에 가깝게 나옵니다. 사람마다 '친근함'의 기준이 다르기 때문에, 형용사보다 실제 예시가 훨씬 정확한 지시가 됩니다. 반복해서 쓰는 톤이라면 이 샘플을 노션 페이지 한 곳에 저장해 두고 매번 복사해 쓰면 편합니다.

4. 형식을 문장으로 지시한다

"세 개의 소제목으로 나누고, 각 소제목 아래 불릿 3개, 마지막에 한 줄 요약"처럼 구조를 말로 지정하면 편집 후 다시 배치하는 수고가 사라집니다. 표·체크리스트·단계별 목록이 필요하면 그 형식도 처음부터 함께 요청하세요. 형식을 미리 못 박아 두면, 내용이 채워지는 방식도 그 틀에 맞춰지므로 훨씬 정돈된 초안이 나옵니다.

실전 예시: 같은 내용, 다른 지시

지시가 결과를 어떻게 바꾸는지 짧은 예로 보겠습니다. 아래는 회의 후 팀에 보낼 안내 문장을 다듬는 상황입니다.

  • 막연한 요청 "이거 정리해줘" → AI가 딱딱한 보고서 말투로 길게 늘려, 정작 팀 채팅에는 어울리지 않는 문장이 나옵니다.
  • 지정한 요청 "팀 동료에게 보낼 채팅 메시지로, 3문장 이내, 친근하지만 핵심만" → 인사 한 줄, 결정 사항 한 줄, 다음 할 일 한 줄로 바로 붙여 쓸 수 있는 형태가 나옵니다.

내용은 똑같은데 '누구에게, 어떤 형식으로, 얼마나 길게'를 덧붙였을 뿐입니다. 이 작은 차이가 편집 시간을 좌우합니다. 지시를 한 줄 더 쓰는 습관이, 결과를 다섯 줄 고치는 수고를 없애 줍니다.

이럴 땐 AI 편집을 멈추자

AI 편집이 항상 이득은 아닙니다. 다음 경우엔 오히려 직접 쓰는 편이 낫습니다.

  • 감정이나 경험이 핵심인 글 — 진심 어린 감사 메시지, 사과문처럼 '진짜 내 목소리'가 중요한 글은 AI가 다듬을수록 밋밋해집니다.
  • 사실 정확성이 생명인 문서 — 계약·수치·정책 안내는 표현보다 정확성이 우선입니다. AI에게 맡기더라도 사실은 한 줄씩 직접 검증하세요.
  • 이미 충분히 좋은 문장 — 만족스러운 문장을 습관적으로 다시 돌리면 개성만 깎입니다. '고칠 이유가 분명할 때'만 편집을 부르세요.

요금과 한도, 먼저 알아둘 점

무료·플러스 요금제에서도 AI를 맛보기로 쓸 수 있지만, 응답 횟수에 제한이 있어 본격적으로 쓰기엔 부족할 수 있습니다. 무제한에 가까운 AI 사용은 상위 유료 요금제에서 제공됩니다. 정확한 금액과 포함 범위는 시기에 따라 달라지므로, 결제 전 노션 요금제 페이지에서 최신 조건을 직접 확인하는 것을 권장합니다. 유료 전환 전에 무료 응답으로 앞서 소개한 지정법을 충분히 연습해 보면, 자신에게 정말 필요한 요금제인지 판단하기 쉽습니다.

결론: AI에게 '무엇을'이 아니라 '어떻게'를 알려주자

노션 AI가 실망스러웠다면, 도구의 한계라기보다 지시가 막연했을 가능성이 큽니다. 독자·목적·길이·톤을 함께 적고, 백지 생성보다 내가 쓴 문장을 선택해 다듬는 흐름으로 바꾸면, 초안을 통째로 버리는 일이 확연히 줄어듭니다. 오늘 쓰던 노션 문서 하나를 골라, 문단을 드래그하고 '어조 변경'부터 한 번 눌러보세요. AI를 대필가가 아니라 편집자로 쓰는 감각이 잡히기 시작할 겁니다.

※ 본 글의 기능·요금 정보는 작성 시점 기준이며, 노션 정책에 따라 변경될 수 있습니다. 최신 사양은 공식 페이지를 확인하세요.

Midjourney 프롬프트 2026: 매번 결과가 들쭉날쭉하다면 — 구조와 파라미터로 그림을 통제하는 법

Midjourney 프롬프트
Photo by Vitaly Gariev on Unsplash

분명 머릿속엔 원하는 그림이 있는데, 막상 뽑아보면 매번 다른 결과가 나옵니다. 어제는 마음에 드는 이미지가 나왔는데 오늘 비슷하게 적으니 전혀 다른 분위기가 나오고, 같은 프롬프트를 네 컷 돌리면 넷이 제각각입니다. Midjourney 프롬프트를 쓸 때 가장 많이 겪는 답답함이 바로 이 "들쭉날쭉함"인데요. 원인은 대부분 프롬프트를 '문장'으로만 던지고, 결과를 통제하는 구조와 파라미터를 쓰지 않기 때문입니다. 오늘은 운에 맡기지 않고 원하는 방향으로 그림을 몰아가는 방법을 정리해 봅니다.

왜 같은 프롬프트인데 결과가 달라질까

Midjourney는 텍스트를 그대로 '그리는' 도구가 아니라, 프롬프트를 해석해 매번 새로운 이미지를 생성하는 도구입니다. 같은 문장을 넣어도 내부적으로는 매번 다른 시작점에서 출발하기 때문에, 아무 제약을 주지 않으면 결과가 넓게 퍼지는 게 정상입니다. 즉 '똑같은 그림이 안 나온다'는 건 버그가 아니라 기본 동작에 가깝습니다.

문제는 이 자유도를 방치할 때입니다. 구도, 화면 비율, 스타일의 강도 같은 걸 지정하지 않으면 Midjourney가 알아서 채우고, 그 '알아서'가 매번 다르니 결과가 흔들립니다. 반대로 말하면, 흔들리는 축을 하나씩 고정해 주는 순간 결과는 예측 가능한 범위로 좁혀집니다. 그래서 잘 뽑는 사람은 문장을 더 화려하게 쓰기보다, 어떤 축을 열어두고 어떤 축을 잠글지를 먼저 정합니다.

Midjourney 프롬프트, 문장이 아니라 구조로 짜기

좋은 프롬프트는 긴 문장이 아니라 요소의 조합입니다. 아래 4가지 축을 의식하고 순서대로 채우면, 같은 주제라도 훨씬 일관된 결과를 얻습니다.

  • ① 주제(무엇을) — 그리려는 대상과 핵심 동작. 예: "책상에서 노트북으로 일하는 여성"
  • ② 스타일/매체(어떻게) — 사진인지 일러스트인지, 어떤 분위기인지. 예: "cinematic photo, soft morning light"
  • ③ 구도/디테일 — 앵글, 배경, 색감. 예: "close-up, shallow depth of field, warm tones"
  • ④ 파라미터 — 비율·스타일 강도 등 뒤에 붙는 옵션. 예: --ar 16:9 --stylize 250

핵심은 중요한 것을 앞에 두는 것입니다. Midjourney는 앞쪽 단어에 더 큰 비중을 두는 경향이 있어, 꼭 살리고 싶은 요소를 문장 앞부분에 배치하면 반영 확률이 올라갑니다. 반대로 형용사를 잔뜩 나열하면 서로 경쟁하다 뭉개지기 쉬우니, 수식어는 꼭 필요한 것만 남기는 편이 낫습니다.

실제 예시로 비교하기

같은 장면을 두 가지 방식으로 적어 보면 차이가 분명합니다. 아래처럼 뭉뚱그린 프롬프트는 매번 다른 그림이 나오기 쉽습니다.

예쁘고 감성적인 카페에서 커피 마시는 사람, 좋은 분위기

반면 4가지 축을 나눠 구조화하고 파라미터로 폭을 좁히면, 의도한 방향으로 훨씬 안정적으로 모입니다.

a woman drinking coffee by a cafe window, cinematic photo, soft morning light, shallow depth of field, warm tones --ar 16:9 --stylize 250 --chaos 10

주제(창가에서 커피 마시는 여성)를 앞에 두고, 매체(cinematic photo)와 빛·색감을 지정한 뒤, 뒤쪽 파라미터로 비율·스타일 강도·다양성까지 고정했습니다. '감성적인'처럼 사람마다 해석이 갈리는 형용사 대신 구체적인 조명·앵글 표현을 쓴 것도 포인트입니다. 영어로 쓰는 이유도 같은 맥락인데, Midjourney가 영어 표현을 더 안정적으로 해석하는 편이라 핵심 묘사는 영어로 적는 것을 권합니다.

결과를 통제하는 핵심 파라미터

파라미터는 프롬프트 맨 뒤에 --를 붙여 넣는 옵션입니다. 문장을 아무리 다듬어도 안 되던 부분이 파라미터 하나로 정리되는 경우가 많습니다. 아래는 값의 범위와 기본값이 공식 문서 기준으로 안정적으로 유지되어 온 대표 옵션들입니다(본 글 작성 시점 기준).

파라미터 역할 범위·기본값
--ar 화면 비율(구도). 세로 9:16, 가로 16:9, 정사각 1:1 비율 지정(예: 16:9)
--stylize (--s) AI의 '예술적 재량'. 낮으면 프롬프트에 충실, 높으면 더 꾸밈 0~1000, 기본 100
--chaos (--c) 네 컷의 다양성. 높을수록 결과가 서로 크게 갈림 0~100, 기본 0
--sref + --sw 스타일 레퍼런스. 특정 이미지/코드의 화풍을 이어받음 --sw 0~1000, 기본 100
--no 빼고 싶은 요소 지정(네거티브) 예: --no text

흔들림을 잡는 순서

파라미터를 한꺼번에 다 넣으면 뭐가 효과를 냈는지 알 수 없습니다. 다음 순서로 하나씩 잡는 걸 권합니다.

  1. 구도부터 고정 — 먼저 --ar로 비율을 정합니다. 비율이 바뀌면 구도 자체가 달라지므로 이걸 가장 먼저 확정하는 게 효율적입니다.
  2. 다양성 좁히기 — 네 컷이 너무 제각각이면 --chaos를 낮게(또는 0으로) 두어 비슷한 방향으로 모읍니다.
  3. 스타일 강도 조절 — 프롬프트대로 안 나오고 과하게 꾸며진다면 --stylize를 낮추고, 밋밋하면 올립니다.
  4. 화풍 고정 — 여러 이미지의 톤을 통일하고 싶으면 마음에 든 결과를 --sref로 물려줍니다.

일관성을 높이는 실전 팁

파라미터를 이해했다면, 실제 작업에서 시간을 아끼는 습관 몇 가지를 더 챙겨보세요.

  • 한 번에 하나만 바꾸기. 프롬프트 문구와 파라미터를 동시에 여러 개 손대면 무엇이 결과를 바꿨는지 추적이 안 됩니다. 변수를 하나씩 고정하며 비교해야 '나만의 공식'이 쌓입니다.
  • 마음에 든 세팅은 메모. 잘 나온 프롬프트와 파라미터 조합, 그리고 스타일 레퍼런스는 따로 저장해 두면 다음에 비슷한 톤을 재현하기 쉽습니다.
  • 캐릭터·제품 일관성이 필요하면 레퍼런스 기능을 활용. 같은 인물이나 물건을 여러 컷에 유지하려면 문장만으로는 한계가 있어, 오므니 레퍼런스(--oref)나 스타일 레퍼런스 같은 참조 기능을 쓰는 편이 안정적입니다.
  • 부정형보다 --no. "글자 없이"처럼 문장에 부정형을 넣으면 오히려 그 요소가 강조될 때가 있습니다. 빼고 싶은 건 --no로 지정하는 게 깔끔합니다.

Midjourney는 버전이 올라가며 파라미터와 기능이 계속 바뀌므로, 옵션의 정확한 범위와 최신 기능은 Midjourney 공식 문서에서 확인하는 습관을 들이면 좋습니다.

결론: 운이 아니라 설계로 뽑는다

결과가 들쭉날쭉한 건 Midjourney가 원래 자유도가 큰 도구이기 때문이고, 그 자유도를 어디까지 열어둘지는 우리가 정할 수 있습니다. 프롬프트를 주제·스타일·구도·파라미터의 구조로 나눠 짜고, --ar로 구도를 먼저 고정한 뒤 --chaos·--stylize로 폭을 좁혀가면 '우연히 잘 나온 한 장'이 아니라 '원하는 대로 반복 가능한 결과'에 가까워집니다. 오늘 작업부터 파라미터 하나만 바꿔 두 컷을 비교해 보세요. 무엇이 그림을 움직이는지 감이 잡히는 순간, Midjourney가 훨씬 다루기 쉬운 도구로 바뀝니다.

AI 글쓰기 도구 2026: 긴 글은 왜 뒤로 갈수록 헤맬까 — 한 번에 쓰지 말고 뼈대부터 잡는 법

AI 글쓰기 도구로 긴 글 쓰기
Photo by Luke Southern on Unsplash

짧은 이메일이나 한 문단 요약은 AI 글쓰기 도구로 몇 초 만에 깔끔하게 나옵니다. 그런데 2천 자, 3천 자짜리 긴 글을 "한 번에 써줘"라고 시켜 보면 이야기가 달라집니다. 앞부분은 그럴듯한데 뒤로 갈수록 논지가 흐려지고, 앞에서 한 말을 뒤에서 또 하고, 어느 순간 말투까지 바뀌어 있죠. 도구 탓 같지만, 사실은 글을 만드는 방식의 문제인 경우가 훨씬 많습니다.

이 글에서는 긴 글이 뒤로 갈수록 무너지는 이유를 짚고, 한 번에 통째로 뽑아내는 대신 뼈대부터 잡아 섹션 단위로 완성하는 작성법을 정리합니다. 도구를 바꾸기 전에 방식부터 바꾸면, 지금 쓰는 도구로도 결과가 확 달라집니다.

왜 긴 글일수록 AI 글쓰기 도구가 헤맬까

언어 모델은 앞에 나온 내용을 참고해 다음 문장을 이어 붙이는 방식으로 글을 만듭니다. 짧은 글에서는 참고할 맥락이 한눈에 들어오니 흐름이 안정적입니다. 하지만 글이 길어질수록 "지금까지 무슨 얘기를 했는지"를 스스로 관리해야 하는 양이 늘어나고, 명확한 설계도 없이 즉흥적으로 이어가다 보면 방향이 조금씩 어긋납니다.

여기에 사용자의 지시 방식도 한몫합니다. "이 주제로 3천 자 블로그 글 써줘" 같은 한 문장짜리 지시는, 모델 입장에서 목차도 우선순위도 없이 알아서 채우라는 뜻입니다. 그러면 모델은 가장 무난한 문장들로 빈칸을 메우고, 그 결과가 바로 '앞뒤가 겉도는 긴 글'입니다.

쉽게 말해, 사람에게도 "아무 준비 없이 지금부터 3천 자를 쉬지 말고 말해 보세요"라고 하면 뒤로 갈수록 횡설수설하기 마련입니다. 개요를 손에 쥐고 한 꼭지씩 말하는 사람과, 무작정 입을 떼는 사람의 차이라고 생각하면 됩니다. AI도 다르지 않습니다.

한 번에 다 쓰라고 시키면 나타나는 세 가지 증상

1. 앞뒤가 어긋난다

서두에서 "초보자용"이라고 해놓고 중반부터 갑자기 전문 용어를 쏟아내거나, 앞에서 "세 가지"라고 예고하고 두 가지만 다루는 식입니다. 전체 구조를 미리 정해두지 않으면 생기는 전형적인 어긋남입니다.

2. 같은 말을 표현만 바꿔 반복한다

분량을 채우려다 보면 핵심 주장 하나를 문단마다 살짝 다른 말로 되풀이합니다. 읽는 사람은 "아까 그 얘기 아닌가?" 하고 금방 알아챕니다. 두 문단이 결국 같은 말이라면, 더 구체적인 쪽만 남기고 나머지는 지우는 게 맞습니다.

3. 톤과 형식이 중간에 바뀐다

앞부분은 친근한 존댓말이었는데 뒤로 가면 딱딱한 개조식으로 변하거나, 리스트와 줄글이 뒤죽박죽 섞입니다. 한 호흡에 길게 생성할수록 이런 흔들림이 커집니다.

AI 글쓰기 도구로 긴 글, 뼈대부터 잡는 4단계

핵심은 단순합니다. 통째로 뽑지 말고, 설계하고 → 조립하라는 것입니다.

1단계 · 구조(목차)를 먼저 확정한다

본문을 쓰기 전에 "제목 후보 3개, 그리고 H2 소제목 4~5개와 각 소제목에서 다룰 핵심 한 줄"만 먼저 뽑아 달라고 하세요. 예를 들어 "본문은 아직 쓰지 말고, 목차와 각 꼭지의 요지만 한 줄씩 정리해줘"처럼 요청하는 식입니다. 이 목차를 사람이 직접 손봐서 순서와 범위를 확정한 다음에야 본문에 들어갑니다. 설계도가 있으면 뒤로 갈수록 헤매는 문제의 대부분이 사라집니다.

2단계 · 섹션 단위로 나눠서 쓴다

확정한 목차를 통째로 넘기며 "전체를 다 써줘"라고 하지 말고, 소제목 하나씩 작성을 요청합니다. "방금 정한 목차 중 두 번째 섹션만, 앞 섹션과 톤을 맞춰서 써줘"처럼요. 한 번에 생성하는 길이가 짧아질수록 일관성과 밀도가 올라가고, 마음에 안 드는 꼭지는 그 부분만 다시 요청하면 되니 수정도 훨씬 가볍습니다.

3단계 · 구조와 문장을 다른 도구로 나눠 쓴다

2026년 현재 실무자들 사이에서 자리 잡은 방식 중 하나는 역할 분담입니다. 목차·표·개요처럼 뼈대를 잡는 작업과, 긴 문장을 자연스럽게 다듬는 작업을 서로 다른 도구에 맡기는 식이죠. 일반적으로 개요·구조화에 강한 도구로 뼈대를 만들고, 장문에서 주제를 일관되게 끌고 가는 데 강한 도구로 문장을 완성하면 서로의 약점을 메울 수 있습니다. 꼭 두 개를 써야 하는 건 아니지만, 결과가 계속 아쉽다면 한 도구에 전부 맡기고 있는 건 아닌지 점검해 보세요.

4단계 · 마지막에 통독하며 반복·톤을 정리한다

섹션을 다 조립했으면 사람이 처음부터 끝까지 한 번 읽습니다. 이때 볼 것은 세 가지입니다. ① 같은 말을 반복한 문단은 없는가 ② 톤이 중간에 바뀐 곳은 없는가 ③ 서두에서 예고한 걸 본문이 실제로 지켰는가. 반복이 보이면 구체적인 쪽만 남기고, 시점에 따라 달라지는 정보(가격·정책·기능 등)에는 "본 글 작성 시점 기준" 같은 단서를 붙여 둡니다.

한눈에 보는 두 방식 비교

구분 한 번에 통째로 쓰기 뼈대부터 조립하기
지시 방식 "3천 자 글 써줘" 한 문장 목차 확정 → 섹션별 요청
일관성 뒤로 갈수록 흔들림 설계도가 방향을 고정
반복 분량 채우려 되풀이 섹션 역할이 겹치지 않음
수정 부담 통째로 다시 문제 섹션만 다시

자주 하는 실수: "최신 정보로 업데이트해줘"

긴 글을 다 뽑은 뒤 "내용을 최신으로 업데이트해줘"라고 덧붙이는 경우가 많습니다. 하지만 모델은 자기 학습 시점(컷오프) 이후의 사실을 스스로 알 수 없습니다. 그 요청을 받으면 최신처럼 보이는 문장을 그럴듯하게 지어낼 위험이 있습니다. 최신 수치·정책·가격이 필요하다면, 사람이 직접 1차 출처를 확인해 넣거나 검색 기능이 붙은 도구로 근거 링크를 함께 받아 검증하는 편이 안전합니다. 확인되지 않은 숫자는 흐릿하게 남겨 두느니 아예 빼는 게 낫습니다.

결론: 도구를 바꾸기 전에 순서를 바꾸자

긴 글이 자꾸 헤매는 건 AI 글쓰기 도구의 한계라기보다, 설계 없이 한 번에 뽑아내려는 방식의 한계인 경우가 많습니다. 목차를 먼저 확정하고, 섹션 단위로 조립하고, 마지막에 사람이 통독해 반복과 톤을 정리하는 것 — 이 순서만 지켜도 같은 도구로 결과가 눈에 띄게 달라집니다. 다음에 긴 글을 쓸 때는 "다 써줘" 대신 "목차부터 잡아줘"로 첫 문장을 바꿔서 시작해 보세요.


라벨: AI 글쓰기 도구, AI 글쓰기, 장문 작성, 블로그 글쓰기, ChatGPT 활용, Claude 활용, 콘텐츠 제작, 생산성

ChatGPT 프롬프트 2026: '단계별로 생각해'가 이제 안 먹히는 이유 — 추론 모델에 맞게 다시 쓰는 법

Photo by Hassan Pasha on Unsplash 한동안 ChatGPT 프롬프트를 잘 쓰는 요령이라며 돌아다닌 문장이 있습니다. "단계별로 생각해 봐(Let's think step by ste...