2부 8장. 실패하는 프롬프트의 공통점

프롬프트가 잘 안 될 때 많은 사람은 먼저 이렇게 생각합니다. "이 모델이 별로인가?", "내가 말을 너무 못했나?", "조금 더 길게 쓰면 되나?"

하지만 실제로는 감으로 고칠수록 더 꼬이는 경우가 많습니다. 한 줄을 더 붙이고, 조건을 몇 개 더 넣고, 강조 표현을 잔뜩 쓰다 보면 오히려 프롬프트가 비대해집니다. 문제의 원인은 그대로인데, 증상만 덕지덕지 덮어 버리는 셈입니다.

잘 안 되는 프롬프트에는 꽤 비슷한 패턴이 있습니다. 모호하거나, 한 번에 너무 많은 것을 요구하거나, 중요한 전제가 빠져 있거나, 무엇이 좋은 답인지 검증할 수 없거나, 서로 충돌하는 지시가 섞여 있습니다.

이 장의 목표는 단순합니다. 프롬프트가 실패했을 때 "그냥 다시 써 보자"가 아니라, 왜 실패했는지 원인별로 진단하는 눈을 만드는 것입니다. 원인을 보면 수정 방향도 보입니다.

실패는 운이 아니라 구조에서 나온다

프롬프트가 실패한다고 해서 AI가 항상 멍청한 것도 아니고, 사용자가 특별히 서툰 것도 아닙니다. 많은 실패는 구조적인 문제에서 나옵니다.

예를 들어 "마케팅 문구 좀 좋게 써줘"라는 요청이 있다고 해 봅시다. 여기에는 여러 가지 구멍이 있습니다. 무엇이 "좋은지" 모르고, 어떤 상품인지 모르고, 누구에게 쓰는지도 없고, 결과를 어디에 쓸지도 없습니다. 그런데도 사용자는 막연히 머릿속 결과를 기대합니다.

사람끼리도 이런 부탁은 어렵습니다. 하물며 AI는 눈치로 빈칸을 메우는 데 한계가 있습니다. 결국 프롬프트 실패의 핵심은 대개 하나입니다. AI가 추측해야 할 빈칸이 너무 많다는 것입니다.

그래서 실패를 볼 때는 결과만 보지 말고, AI가 어떤 빈칸을 억지로 메웠는지 봐야 합니다. 그러면 "왜 이상한 답이 나왔는지"가 훨씬 선명해집니다.

첫 번째 패턴: 모호한 말이 너무 많다

가장 흔한 실패 원인은 모호함입니다. 사용자는 분명히 말했다고 느끼지만, 실제로는 해석이 여러 갈래로 열려 있습니다.

예를 들어 이런 프롬프트를 보겠습니다.

발표 자료를 전문적으로, 하지만 너무 딱딱하지 않게, 임팩트 있게 정리해줘.

겉보기에 그럴듯하지만, 사실 거의 모든 표현이 모호합니다. "전문적으로"는 어떤 수준인지, "너무 딱딱하지 않게"는 어느 정도인지, "임팩트 있게"는 짧고 강한 것인지, 설득력이 높은 것인지 알 수 없습니다.

AI는 이런 표현을 만나면 보통 평균적인 답을 냅니다. 무난하고, 애매하게 안전하고, 특별히 틀리지는 않지만 딱히 만족스럽지도 않은 결과가 나옵니다. 우리가 자주 보는 바로 그 "그럴듯한데 내가 원한 건 아닌" 출력입니다.

모호한 프롬프트의 특징은 대개 이렇습니다.

• 좋게, 자연스럽게, 전문적으로, 깔끔하게처럼 해석 폭이 넓은 표현이 많다.

• 독자, 목적, 길이, 형식 같은 기준이 빠져 있다.

• 무엇을 포함하고 무엇을 빼야 하는지가 드러나지 않는다.

이 문제를 해결하려면 추상어를 없애라는 뜻이 아닙니다. 추상어를 쓰더라도 판단 기준을 붙여야 합니다. 예를 들어 "전문적으로" 대신 "임원 보고용으로, 핵심 결론부터 말하고 수식어는 줄여서"라고 바꾸면 훨씬 선명해집니다.

모호함은 프롬프트를 짧게 써서 생기는 문제만은 아닙니다. 길게 썼는데도 모호할 수 있습니다. 말이 많다고 정보가 많은 것은 아니기 때문입니다.

두 번째 패턴: 한 번에 너무 많은 것을 요구한다

AI에게 일을 맡길 때 초보자가 자주 빠지는 함정이 있습니다. 한 번에 끝내고 싶은 마음입니다.

그래서 프롬프트가 이렇게 됩니다.

이 보고서를 읽고 핵심 요약도 하고, 문제점도 찾고, 경쟁사와도 비교하고, 발표용 문장으로도 바꾸고, 마지막에는 CEO가 감탄할 만한 한 줄 메시지도 만들어줘.

이런 요청은 얼핏 효율적으로 보입니다. 하지만 실제로는 서로 다른 작업을 한 덩어리로 묶어 버린 것입니다. 요약, 분석, 비교, 문체 변환, 카피 작성은 각기 다른 작업입니다. 한 프롬프트에 너무 많은 목표가 들어가면 AI는 무엇을 우선해야 할지 흔들립니다.

그 결과는 대개 두 가지 중 하나입니다. 하나는 전부 건드렸지만 다 얕은 답입니다. 다른 하나는 앞부분 작업에 힘을 쓰다가 뒤쪽 요구를 대충 처리하는 답입니다.

특히 다음과 같은 경우 실패 확률이 높습니다.

• 분석과 창작을 동시에 깊게 요구할 때

• 요약하면서도 빠짐없이 모든 세부 사항을 담으라고 할 때

• 짧게 쓰라고 하면서도 충분한 근거와 사례까지 요구할 때

이런 프롬프트의 문제는 AI의 능력 부족만이 아닙니다. 작업 설계가 엉킨 것입니다. 사람에게도 "짧고 자세하게, 빠르게, 창의적으로, 정확하게"를 동시에 요구하면 표정이 굳습니다.

이때 필요한 것은 더 강한 표현이 아니라 작업 분리입니다. 먼저 요약하고, 다음 턴에 문제점을 찾고, 그다음 발표용 문장으로 바꾸는 식으로 나누면 훨씬 안정적입니다.

좋은 프롬프트는 모든 것을 한 번에 해결하려는 프롬프트가 아니라, 지금 이 단계에서 무엇을 하려는지 분명한 프롬프트입니다.

세 번째 패턴: 중요한 전제가 빠져 있다

프롬프트는 종종 사용자의 머릿속에서는 완성되어 있지만, 실제 문장에는 절반만 적혀 있습니다. 이것이 숨은 전제의 문제입니다.

예를 들어 사용자는 "이메일 초안을 써줘"라고 말하면서 이미 머릿속으로는 이런 조건을 알고 있을 수 있습니다. 상대는 거래처 팀장이고, 분위기는 정중해야 하며, 일정 지연 사과가 들어가야 하고, 책임을 회피하는 인상은 주면 안 되며, 분량은 짧아야 한다는 식입니다.

하지만 AI는 그 머릿속을 읽지 못합니다. 결국 빠진 전제를 자기 방식으로 채웁니다. 그러면 사용자는 결과를 보고 "왜 이렇게 썼지?"라고 느끼게 됩니다. 사실 AI 입장에서는 억울할 수도 있습니다. 안 알려 준 부분을 나름대로 추측했을 뿐이니까요.

숨은 전제가 많은 프롬프트는 보통 이런 모습을 보입니다.

• 사용자는 배경을 알고 있지만 프롬프트에는 적지 않는다.

• 누구를 위한 결과물인지 빠져 있다.

• 이미 정해 둔 금지 사항이나 선호가 뒤늦게 등장한다.

• 입력 자료 없이 "알아서"를 기대한다.

이 문제는 특히 업무 문서, 메시지, 기획안, 학습 설명에서 자주 나타납니다. 사용자는 자기 상황을 너무 잘 알기 때문에, 오히려 그 상황을 설명해야 한다는 사실을 잊어버립니다.

프롬프트를 쓸 때는 이렇게 자문해 보면 좋습니다. "내가 당연하다고 생각하는 것 중, AI는 아직 모를 것이 무엇인가?" 이 질문 하나만으로 많은 실패를 줄일 수 있습니다.

네 번째 패턴: 검증할 수 없는 요청이다

어떤 프롬프트는 결과가 좋아도 왜 좋은지 설명하기 어렵고, 나빠도 어디가 문제인지 짚기 어렵습니다. 이런 프롬프트는 검증 기준이 없기 때문입니다.

예를 들어 이런 요청을 봅시다.

완벽한 사업 아이디어를 만들어줘.

여기서 "완벽한"은 무엇일까요. 수익성이 높은 것인지, 참신한 것인지, 지금 당장 실행 가능한 것인지, 투자 유치에 유리한 것인지 알 수 없습니다. 평가 기준이 없으니 결과가 마음에 안 들어도 무엇을 고쳐야 하는지 말하기 어렵습니다.

또 이런 요청도 비슷합니다.

사람들이 무조건 좋아할 만한 제목 10개 써줘.

"무조건"은 검증할 수 없습니다. 누구를 기준으로, 어떤 상황에서, 무엇을 통해 판단할 것인지 없기 때문입니다.

검증 불가 프롬프트의 문제는 단지 표현이 과장돼서가 아닙니다. 좋은 답의 판정 규칙이 없다는 데 있습니다. 판정 규칙이 없으면 개선도 안 됩니다. 한 번은 마음에 들고, 다음 번에는 마음에 안 들어도 이유를 쌓을 수 없습니다.

실전에서는 "좋다"를 측정 가능한 기준으로 바꾸는 것이 중요합니다. 예를 들면 이런 식입니다.

• 클릭을 노리는 제목인지, 신뢰감을 주는 제목인지 정한다.

• 초보자용 설명인지, 실무자용 설명인지 정한다.

• 설득의 기준이 감정인지, 논리인지, 행동 유도인지 정한다.

검증 기준이 생기면 프롬프트는 단지 요청이 아니라 평가 가능한 작업 지시가 됩니다.

다섯 번째 패턴: 서로 충돌하는 지시가 섞여 있다

프롬프트가 실패하는 이유 중 꽤 많은 수는 지시 충돌입니다. 사용자는 많은 걸 챙기고 싶어서 이것도 넣고 저것도 넣는데, 그 조건들이 서로 부딪힙니다.

예를 들어 이런 요청은 흔합니다.

아주 짧게 써줘. 그런데 배경, 원인, 사례, 비교, 결론까지 빠짐없이 넣어줘.

또는 이런 식입니다.

창의적으로 써줘. 다만 절대로 일반적인 표현에서 벗어나면 안 돼.

또는 이렇게도 말합니다.

비판적으로 검토해줘. 하지만 부정적으로 보이지 않게 해줘.

이런 프롬프트를 받으면 AI는 우선순위를 몰라 난감해집니다. 어느 조건을 더 중요하게 지켜야 하는지 모르기 때문입니다. 그러면 결과는 중간쯤에서 어정쩡해지기 쉽습니다. 짧지도 않고 충분하지도 않으며, 창의적이지도 않고 안정적이지도 않은 답이 나옵니다.

지시 충돌을 줄이려면 조건을 많이 쓰지 말라는 뜻이 아닙니다. 우선순위를 써야 한다는 뜻입니다. 예를 들어 "짧게 쓰되, 배경 설명은 생략하고 결론과 다음 액션만 남겨줘"라고 하면 충돌이 줄어듭니다. 또는 "참신함보다 정확성을 우선해줘"처럼 기준의 순서를 정해 줄 수 있습니다.

프롬프트는 체크리스트의 길이보다, 조건 사이의 관계가 더 중요합니다.

여섯 번째 패턴: 입력은 빈약한데 출력 기대는 크다

AI는 없는 정보를 만들어 낼 수는 있지만, 그럴수록 틀릴 가능성도 커집니다. 그런데 사용자들은 종종 재료는 거의 주지 않으면서, 완성도 높은 결과를 기대합니다.

예를 들어 "이 제품 소개 페이지 써줘"라고 하면서 제품 정보는 두 줄만 주는 경우가 있습니다. 또는 "이 학생에게 맞는 학습 계획 짜줘"라고 하면서 현재 수준, 목표, 기간, 과목별 약점이 하나도 없습니다.

이럴 때 AI는 빈칸을 메워야 합니다. 그 순간 결과는 맞춤형이 아니라 추정형이 됩니다. 얼핏 그럴듯하지만 실제 상황과는 어긋날 수 있습니다.

이 문제는 특히 다음과 같은 상황에서 자주 생깁니다.

• 특정 조직, 팀, 고객, 제품에 맞춘 문서가 필요할 때

• 개인 맞춤 조언을 기대할 때

• 기존 자료를 바탕으로 변환해야 할 때

• 사실 기반 정리가 필요한데 원문이 없을 때

프롬프트의 품질은 문장 솜씨만으로 결정되지 않습니다. 입력 자료의 질과 양도 큰 변수입니다. 좋은 출력을 원하면, 적어도 그 출력이 설 수 있는 바닥은 깔아 줘야 합니다.

간단히 말해, AI에게 셰프처럼 요리해 달라고 하려면 재료라도 꺼내 줘야 합니다. 빈 냉장고를 열어 놓고 미슐랭을 기대하면 곤란합니다.

일곱 번째 패턴: 결과를 쓰는 장면이 빠져 있다

프롬프트가 실패하는 또 하나의 이유는 "무엇을 만들지"는 말했지만 "어디에 쓸지"는 말하지 않았기 때문입니다.

같은 내용도 쓰이는 장면에 따라 전혀 다른 답이 필요합니다. 사내 보고용 요약과 블로그용 설명은 다르고, 고객 공지와 내부 메모는 다르며, 시험 공부용 정리와 면접 준비용 정리는 다릅니다.

그런데 사용자는 종종 이렇게만 말합니다.

이 내용을 정리해줘.

정리해서 어디에 쓸까요? 발표 전에 훑기 위한 것인지, 상사에게 보낼 것인지, 공부용 복습 카드인지에 따라 구조와 말투와 길이가 달라져야 합니다.

사용 장면이 빠지면 AI는 평균적인 형식을 택합니다. 그래서 결과가 맞긴 맞는데 애매하게 쓸모없게 느껴집니다. 내용이 틀린 것은 아니지만 바로 사용할 수가 없습니다.

이 문제는 앞 장에서 본 형식 지정과도 이어집니다. 형식이란 예쁘게 꾸미는 장식이 아니라, 어떤 행동을 바로 가능하게 만드는 틀이기 때문입니다. 결국 "어디에 쓸 것인가"를 말해야 "어떤 모양으로 줄 것인가"도 정해집니다.

실패한 프롬프트를 진단하는 다섯 가지 질문

이제 중요한 것은 패턴을 외우는 것이 아니라, 실제로 진단하는 순서를 갖는 것입니다. 프롬프트가 기대만큼 나오지 않았을 때는 감으로 뜯어고치기 전에 먼저 다섯 가지를 확인해 보세요.

• 내가 쓴 표현 중 해석이 여러 갈래로 갈 수 있는 말은 무엇인가?

• 한 번에 너무 많은 작업을 묶어 놓지는 않았는가?

• 내가 당연하다고 생각한 전제 중 프롬프트에 빠진 것은 무엇인가?

• 무엇이 좋은 결과인지 판정할 기준이 있는가?

• 조건끼리 서로 부딪히는 부분은 없는가?

이 다섯 질문만으로도 문제의 절반 이상은 잡힙니다. 그리고 이 질문의 장점은, 모델이 바뀌어도 여전히 유효하다는 점입니다. 특정 도구의 요령이 아니라 작업 설계의 원리이기 때문입니다.

같은 실패를 보는 두 가지 방식

프롬프트 실패를 대하는 방식은 크게 두 가지입니다.

첫 번째 방식은 감정적으로 반응하는 것입니다. "왜 또 이상하게 나왔지?", "모델이 요즘 별로네", "다시 돌리면 되겠지." 이 방식은 빠르지만 배움이 남지 않습니다.

두 번째 방식은 구조적으로 반응하는 것입니다. "지금 실패 원인이 모호함인가, 정보 부족인가, 지시 충돌인가?" 이렇게 보면 다음 수정이 훨씬 정확해집니다.

예를 들어 결과가 너무 뻔하다면 많은 사람은 "더 창의적으로 써줘"를 붙입니다. 하지만 실제 원인이 입력 부족일 수도 있습니다. 배경 자료와 차별점 정보가 없는데 창의성만 요구했을 수 있기 때문입니다.

반대로 결과가 너무 산만하다면 "짧게 써줘"라고만 할 수도 있습니다. 그러나 진짜 원인은 작업 과잉일 수 있습니다. 한 프롬프트 안에 요약과 분석과 제안이 다 들어 있었던 것입니다.

즉, 겉으로 보이는 증상과 실제 원인은 다를 수 있습니다. 프롬프트도 사람의 몸처럼 증상만 눌러서는 자꾸 재발합니다.

실패를 줄이는 가장 현실적인 습관

완벽한 프롬프트를 처음부터 쓰려는 태도는 오히려 비효율적입니다. 실전에서는 실패를 아예 없애기보다, 실패를 빨리 읽고 빨리 수정하는 습관이 더 중요합니다.

그러려면 이런 습관이 도움이 됩니다.

• 첫 시도에서는 목표를 한 문장으로 분명히 적는다.

• 출력이 기대와 다르면 문장을 더 꾸미기 전에 실패 원인부터 분류한다.

• 한 번에 하나의 문제만 고쳐 보고, 무엇이 달라졌는지 확인한다.

• 모호한 표현을 구체적 기준으로 바꾸고, 빠진 전제를 추가한다.

• 작업이 크면 멀티턴으로 나누어 진행한다.

이 습관의 핵심은 "많이 써서 해결"이 아니라 "원인을 찾아 해결"입니다. 프롬프트 실력은 멋있는 표현을 많이 아는 데서 나오지 않습니다. 실패를 분해하는 능력에서 나옵니다.

실패하는 프롬프트를 보는 새로운 기준

이제부터는 프롬프트를 이렇게 보지 않았으면 합니다. "길면 좋다, 짧으면 나쁘다", "정중하면 좋다, 강하게 쓰면 잘 먹힌다" 같은 식의 단순한 감각 말입니다.

대신 이렇게 보아야 합니다. 이 프롬프트는 목표가 선명한가? 입력이 충분한가? 조건의 우선순위가 있는가? 출력의 쓰임이 정해져 있는가? 결과를 평가할 기준이 있는가?

이 기준으로 보면 프롬프트는 훨씬 덜 신비롭습니다. 잘 되는 프롬프트는 재능의 산물이 아니라, 정보와 구조가 정돈된 작업 지시문에 가깝습니다. 실패하는 프롬프트 역시 운이 나빠서가 아니라, 어디엔가 구조적인 틈이 있어서입니다.

이 장의 핵심 정리

실패하는 프롬프트에는 공통점이 있습니다. 말이 모호하거나, 한 번에 너무 많은 것을 요구하거나, 사용자의 머릿속 전제가 빠져 있거나, 무엇이 좋은 결과인지 검증할 수 없거나, 조건끼리 충돌하거나, 입력은 빈약한데 출력 기대만 큰 경우입니다.

중요한 것은 실패를 막연히 느끼는 데서 멈추지 않는 것입니다. 왜 실패했는지를 원인별로 진단할 수 있어야 합니다. 그래야 다음 수정이 정확해지고, 프롬프트 실력도 쌓입니다.

결국 프롬프트를 잘 쓴다는 것은 화려한 문장을 쓰는 일이 아닙니다. AI가 추측해야 할 빈칸을 줄이고, 작업의 구조를 선명하게 만드는 일입니다.

다음 장에서는 여기서 한 걸음 더 나아가 보겠습니다. 실패하는 프롬프트의 패턴을 알았다면, 이제는 실제로 프롬프트를 어떻게 고쳐 나가야 하는지 살펴볼 차례입니다.