도구 탓이기 전에, 문장 탓인 경우
도구를 바꿔가며 리뷰를 하다 보니 알게 된 게 하나 있어요. "이 AI 별로던데요"라는 이야기를 따라가 보면, 도구 차이보다 요청 문장 차이에서 갈린 경우가 자주 있다는 것. 같은 모델에게 같은 일을 시켜도 문장을 어떻게 쓰느냐로 결과의 층이 달라집니다. 그 갈림 지점이 어디인지가 이 글의 주제예요.
형식은 클리닉입니다. 상태가 좋지 않은 프롬프트 4개를 접수해서, 증상(무엇이 나오나) → 진단(무엇이 빠졌나) → 처방(어떻게 고치나) 순서로 봅니다. 처방에 쓰는 원칙은 넷이에요. 맥락 제공, 출력 형식 지정, 역할 부여, 검증 요청. 특정 도구의 꼼수가 아니라 Anthropic·Google 공식 프롬프트 가이드가 공통으로 권하는, 모델을 가리지 않는 원칙들입니다. 기법 이름을 처음 본다면 프롬프트 엔지니어링 입문을 먼저 읽고 와도 좋아요. 그 글이 기법 소개라면, 이 글은 고치는 과정을 보여주는 실습입니다.
미리 밝혀둘 것 하나. 아래 비포·애프터의 "증상" 설명은 특정 서비스의 실제 출력을 옮긴 게 아니라, 구조를 보여주기 위해 제가 저작한 전형적인 예시예요. 여러분이 넣으면 당연히 다른 문장이 나옵니다. 다만 갈리는 지점은 같을 거예요.
사례 1. "이 글 요약해줘" — 맥락이 없어서 기준도 없다
비포
이 보고서 요약해줘. (30쪽짜리 문서 첨부)
증상: 문법도 맞고 문장도 매끈한데, 어디에도 못 쓰는 요약이 나옵니다. 목차를 고르게 훑은 축소판이라, 내게 중요한 부분과 뻔한 부분이 같은 비중으로 섞여 있어요.
진단: 틀린 답이 아니라 기준 없는 답이에요. 요약은 원래 "누가, 왜 읽을 것인가"에 따라 남길 것이 달라지는 작업인데, 비포 문장에는 그 정보가 없습니다. AI는 여러분이 팀장 보고용으로 읽는지, 계약 리스크를 찾는지 모르니 가장 무난한 평균을 내놓을 수밖에요. Google 공식 가이드가 첫 번째로 꼽는 것도 "모델이 문제를 풀 때 필요한 맥락과 제약을 프롬프트에 함께 담으라"는 것입니다.
애프터
이 보고서를 요약해줘. 나는 마케팅팀 실무자이고, 내일 팀장에게 "우리 팀이 뭘 바꿔야 하는지"를 구두 보고해야 해. 팀장은 배경은 이미 알고 있어. 실행 관련 내용 위주로 10줄 이내로 정리하고, 근거가 된 쪽 번호를 각 항목 끝에 붙여줘. 보고서에 없는 내용은 추가하지 마.
무엇이 바뀌었나: 추가된 건 네 조각이에요. 읽는 사람과 목적(팀장 구두 보고), 상대의 사전 지식(배경은 안다), 분량과 근거 표시(10줄, 쪽 번호), 금지선(없는 내용 추가 금지). 이 네 줄이 "무난한 평균"을 "내 용도의 요약"으로 바꿉니다. 문서가 아주 길다면 한 번에 다 넣기보다 장별로 나눠 요약한 뒤 합치는 편이 안정적인데, 왜 그런지는 AI 용어 오해 사전의 컨텍스트 항목에 적어뒀어요.
사례 2. "블로그 글 써줘" — 누구의 목소리인지 정하지 않았다
비포
동네 빵집 홍보 블로그 글 써줘.
증상: "안녕하세요 여러분! 오늘은 특별한 빵집을 소개해드릴게요!" 류의, 어디서 본 듯한 들뜬 광고 문체가 나옵니다. 우리 가게 이야기가 아니라 아무 빵집에나 붙는 문장들이고요.
진단: 화자가 비어 있어요. 누가 쓰는 글인지, 어떤 톤인지, 무엇을 하지 말아야 하는지를 정하지 않으면 모델은 학습한 "홍보 글의 평균 문체"로 채웁니다. 공식 가이드들이 역할(페르소나) 부여를 권하는 이유가 이거예요. 역할은 마법 주문이 아니라, 문체·어휘·관점의 기본값을 한 번에 설정하는 압축 지시입니다. 역할만큼 힘이 센 게 금지 목록이고요.
애프터
너는 15년째 새벽에 반죽을 시작하는 동네 빵집 주인이야. 그 1인칭 시점으로, 단골에게 말하듯 담백한 존댓말로 블로그 글을 써줘. 소재는 "가을 신메뉴 무화과 캉파뉴를 만들며 실패한 반죽 이야기". 느낌표 남발, "여러분", "강추" 같은 광고 상투어는 쓰지 마. 800자 안팎, 소제목 2개.
무엇이 바뀌었나: 역할(빵집 주인 1인칭), 관계와 톤(단골에게, 담백한 존댓말), 구체 소재(실패한 반죽), 금지 목록(느낌표·상투어), 형식(분량·소제목). 특히 금지 목록은 비포의 증상을 그대로 뒤집어 적은 거예요. 첫 결과에서 거슬렸던 것을 다음 프롬프트의 금지선으로 옮겨 적는 것, 이게 클리닉에서 제일 자주 쓰는 처방입니다.
사례 3. "이 데이터 분석해줘" — 받고 싶은 모양을 말하지 않았다
비포
우리 매장 6개월 매출 데이터야. 분석해줘. (표 붙여넣기)
증상: "매출이 전반적으로 증가 추세를 보이며…"로 시작하는 긴 줄글이 나옵니다. 읽다 보면 맞는 말 같긴 한데, 어디에 옮겨 쓸 수도 없고 다음 행동으로 이어지지도 않아요.
진단: "분석"이라는 단어가 하는 일이 없어요. 무엇을 비교하고, 결과를 어떤 모양으로 받고 싶은지가 없으니 모델은 인상비평 줄글을 냅니다. 공식 가이드들은 원하는 출력 형식(표, 목록, 구조화된 틀)을 명시하고 복잡한 작업은 단계로 쪼개라고 권해요. 형식 지정은 겉치레가 아니라, 모델이 무엇을 계산해야 하는지 정하는 일입니다. 표의 열 이름을 정해주는 순간 "무엇을 비교할지"가 함께 정해지거든요.
애프터
우리 매장 6개월 매출 데이터야. 다음 순서로 정리해줘. 1) 월별 합계와 전월 대비 증감률을 표로(열: 월, 합계, 증감률). 2) 증감 폭이 가장 큰 달 2개와, 데이터 안에서 확인되는 원인 후보를 각 2줄로. 3) 데이터만으로 알 수 없는 것(예: 외부 요인)은 "추가 확인 필요"로 따로 묶어줘. 계산 과정도 간단히 보여줘.
무엇이 바뀌었나: 형식(열 이름까지 정한 표), 단계(1→2→3), 그리고 경계선("데이터만으로 알 수 없는 것"의 분리)이 생겼어요. 마지막 줄이 은근히 중요합니다. 분석 요청에서 나오는 그럴듯한 헛소리 대부분은 데이터 밖의 원인을 데이터가 말해준 것처럼 붙이는 데서 나오는데, 그 자리를 미리 "추가 확인 필요" 칸으로 만들어두면 지어낼 공간이 줄어요. 계산 과정을 보여달라는 요청은 검산용이고요.
사례 4. "이거 맞아?" — 확인을 시켰는데 맞장구가 온다
비포
내가 쓴 기획서 초안이야. 이 시장 규모 부분 맞는지 확인해줘.
증상: "네, 전반적으로 잘 정리되어 있습니다"로 시작하는 부드러운 맞장구가 옵니다. 틀린 숫자가 있어도 좀처럼 지적하지 않고, 지적해도 근거 없이 다른 숫자를 자신 있게 대기도 해요.
진단: 두 겹의 문제예요. 첫째, "맞는지 확인해줘"는 사실상 동의를 구하는 문장에 가깝고, 모델은 요청의 결을 따라가는 경향이 있습니다. 둘째, 더 근본적으로 모델은 학습 시점 이후를 모르고 아는 것도 확률적으로 재구성하기 때문에, 검증 없는 확인 요청은 그럴듯한 확신만 돌려줍니다. 그래서 이 사례의 처방은 문장 수리에서 끝나지 않아요. 모르는 것을 모른다고 말할 자리, 확신의 정도를 표시할 자리를 프롬프트 안에 만들어주는 것까지가 처방입니다.
애프터
내 기획서의 시장 규모 문단이야. 동의해 주지 말고 검증자 역할로 읽어줘. 1) 사실 주장을 문장 단위로 뽑아 목록으로 만들고, 2) 각 주장에 대해 "네 학습 지식과 일치 / 상충 / 판단 불가"를 표시해줘. 3) 판단 불가나 상충인 항목은 이유와 함께, 내가 원문을 어디서 확인하면 되는지(기관·자료 유형)를 제안해줘. 근거 없이 대체 숫자를 만들어내지는 마.
무엇이 바뀌었나: 역할이 "맞장구 상대"에서 "검증자"로 바뀌었고, 출력이 판정표 형식이 됐고, "판단 불가"라는 도망갈 문이 생겼고, 숫자 창작 금지선이 그어졌어요. 그리고 한 가지는 프롬프트 밖의 일입니다. 이렇게 받은 판정표는 검증의 시작이지 끝이 아니에요. 최종 확인은 사람이 1차 출처로 해야 하고, 그 방법은 AI 답변 1차 출처 검증 가이드에 따로 정리해 뒀습니다.
네 처방을 한 장으로
사례는 넷이지만 처방전은 사실 한 장이에요. 요청을 보내기 전에 이 다섯 줄만 훑으세요.
- 맥락: 누가, 왜, 누구를 위해 쓰는 결과물인지 적었나?
- 형식: 받고 싶은 모양(표·목록·분량·열 이름)을 정했나?
- 역할: 어떤 화자·관점으로 답해야 하는지 정했나?
- 금지선: 첫 결과에서 거슬렸던 것을 금지 목록으로 옮겨 적었나?
- 검증: 사실이 걸린 작업이면 "판단 불가" 칸과 근거 표시를 요구했나?
다섯 개를 매번 다 채울 필요는 없어요. 결과가 이상하게 나왔을 때 어느 줄이 비었는지 짚어내는 진단 틀로 쓰는 게 이 표의 용도입니다.
클리닉을 나서며
Q. 이렇게 길게 쓰면 오히려 번거롭지 않나요?
A. 처음엔 그래요. 다만 한 줄짜리 요청을 서너 번 다시 시키는 왕복과, 다섯 줄짜리를 한 번에 통과시키는 것 중 뭐가 빠른지는 몇 번 해보면 몸이 먼저 압니다. 자주 쓰는 유형은 저장해 두고 빈칸만 갈아 끼우세요. 직군별로 미리 짜둔 틀은 프롬프트 라이브러리에 모아뒀습니다.
Q. 도구마다 프롬프트를 다르게 써야 하나요?
A. 오늘 다룬 네 원칙은 모델을 가리지 않아요. 도구별 미세한 결 차이보다 이 원칙의 유무가 훨씬 크게 갈랐습니다. 애초에 어떤 도구를 잡을지가 고민이라면 AI 도구 선택 프레임워크부터 보세요.
Q. 복붙할 한국어 예문이 더 필요해요.
A. 상황별 문장 100개를 한국어 프롬프트 100선에 정리해 뒀어요. 오늘 글의 진단 틀을 들고 가서 읽으면, 그 100개가 왜 그렇게 쓰였는지도 보일 겁니다.
본문의 4원칙은 Anthropic 공식 프롬프트 엔지니어링 가이드(명확한 지시·예시·역할 부여·프롬프트 체이닝)와 Google 공식 프롬프트 설계 전략(맥락 추가·출력 형식 지정·제약 명시·few-shot 예시)이 공통으로 권하는 내용을 재구성한 것입니다 · 확인일 2026-07-09. 비포·애프터의 증상 서술은 특정 서비스의 실제 출력이 아니라 구조 설명을 위해 저작한 예시입니다.
