프롬프트 실패 5패턴과 해결: 모델 탓이 아니라 입력 탓입니다

대부분의 프롬프트 실패는 모델의 한계가 아니라 다섯 가지 입력 패턴에서 나옵니다. 모호하다. 맥락이 없다. 목적이 불분명하다. 예시가 없다. 고쳐 쓰지 않는다. 이 다섯을 거꾸로 뒤집으면 그대로 해결책이 되고, 이것이 우리가 교육에서 쓰는 T.I.G.E.R 프레임(Task·Input·Goal·Example·Refine)입니다. 아래에서 각 패턴이 왜 결과를 망가뜨리는지 실제 연구 데이터로 짚고, 어떻게 고치는지 회사 현장 기준으로 정리합니다.

먼저 큰 그림 하나. MIT NANDA의 2025년 보고서 〈The GenAI Divide: State of AI in Business〉는 기업 생성형 AI 파일럿의 약 95%가 손익(P&L)에 의미 있는 영향을 주지 못한다고 밝혔습니다. 보고서가 지목한 원인은 모델 성능이 아니라 “학습 격차”였습니다. 대부분의 도입이 피드백을 남기지 않고, 맥락에 맞춰 바뀌지 않으며, 시간이 지나도 나아지지 않는다는 뜻입니다(MIT NANDA, 2025). 같은 해 맥킨지의 글로벌 설문에서도 전사 EBIT에 AI가 영향을 준다고 답한 기업은 39%에 그쳤고, 그중 대다수조차 그 영향이 EBIT의 5% 미만이라고 답했습니다(McKinsey, 2025). 모델은 충분히 좋아졌습니다. 무너지는 지점은 대개 사람이 모델에게 무엇을, 어떻게 시키느냐, 즉 프롬프트와 운영입니다.

패턴 1. 모호함: “알아서 잘”이라는 함정

가장 흔한 실패는 지시가 모호한 것입니다. “이 내용 정리해줘” “보고서 좀 잘 써줘” 같은 요청은 모델에게 너무 많은 자유도를 줍니다. 자유도가 크면 모델은 가장 그럴듯한 평균값을 출력하고, 그 평균은 당신이 머릿속에 그린 결과와 거의 항상 다릅니다.

연구도 이를 뒷받침합니다. Bsharat 등의 〈Principled Instructions Are All You Need〉는 지시를 구체적으로 쓰고 원하는 형식과 청중, 제약을 밝히기만 해도 LLaMA-1/2와 GPT-3.5/4 전반에서 응답 품질과 정확도가 일관되게 올라간다고 실험으로 보고했습니다(arXiv:2312.16171). 모호함을 줄이는 일은 사소한 요령이 아닙니다. 가장 크게 듣는 지렛대입니다.

해결의 핵심은 동작 가능한 동사와 측정 가능한 기준으로 바꾸는 것입니다. “정리해줘” 대신 “아래 회의록에서 결정사항·담당자·기한을 표로 뽑아줘. 항목당 한 줄, 추측 금지.” 무엇을 하라(do)고 지시하는 것이 무엇을 하지 마라(don’t)보다 효과적이라는 것도 정설입니다(Claude prompting best practices). 이것이 T.I.G.E.R의 T(Task) — 과업을 한 문장으로 명확히 못 박는 단계입니다.

패턴 2. 맥락 부족, 그리고 맥락 과잉

두 번째는 맥락 부족입니다. 모델은 당신 회사의 약어, 지난주 결정, 고객 사정, 사내 톤을 모릅니다. 이걸 안 주면 모델은 빈칸을 일반론으로 채웁니다. 그게 바로 환각의 출발점입니다. 환각 측정의 대표 벤치마크인 TruthfulQA에서, 당시 가장 큰 모델조차 진실한 답변 비율이 58%에 그쳐 인간 기준치(94%)에 크게 못 미쳤다는 결과는, 근거가 없을 때 모델이 얼마나 자신 있게 틀리는지를 보여줍니다(Lin et al., 2021).

그런데 함정이 하나 더 있습니다. 맥락은 많을수록 좋은 게 아닙니다. Liu 등의 〈Lost in the Middle〉(2023)은 관련 정보가 긴 맥락의 중간에 묻히면 성능이 U자 곡선으로 급락한다는 것을 밝혔습니다. 정보가 맨 앞이나 맨 뒤에 있을 때 가장 정확하고, 중간에 있을 때 가장 떨어지며, 이 현상은 여러 모델군에서 반복 확인됐습니다(arXiv:2307.03172). 한꺼번에 자료를 다 붙여넣는 방식이 오히려 핵심을 묻어버립니다.

해결은 두 가지입니다. 첫째, 필요한 맥락만 선별해서 줍니다 — 관련 문서, 제약, 용어집, 예외. 둘째, 핵심 정보와 질문을 맨 앞 또는 맨 뒤에 배치합니다. 긴 자료는 구분자(XML 태그, ### 섹션 제목)로 명확히 나누는 것이 좋습니다. 실제로 한 2024년 연구는 같은 내용이라도 프롬프트 포맷(JSON·Markdown·YAML 등)에 따라 GPT-3.5의 정확도가 코드 변환 과제에서 최대 40%까지 달라졌다고 보고했습니다(He et al., 2024). 이것이 I(Input) — 무엇을, 어떤 구조로 넣을지 설계하는 단계입니다.

패턴 3. 목적 불명: 어디에 쓸 결과물인지 안 알려준다

세 번째는 목적 불명입니다. 같은 “요약”이라도 임원 보고용 3줄 요약과 실무 인수인계용 체크리스트는 완전히 다른 결과물입니다. 누가 읽는지, 어디에 쓰이는지, 무엇을 결정하는 자료인지를 빼면 모델은 용도를 모른 채 무난한 글을 만들고, 그 무난함이 곧 “쓸 수 없음”입니다.

목적을 명시하면 모델은 길이, 어조, 강조점, 생략할 것을 스스로 조정합니다. “이 요약은 영업 임원이 5분 안에 다음 분기 투자 여부를 판단하는 데 쓴다”는 한 줄이, 같은 입력에서 전혀 다른 — 훨씬 쓸 만한 — 출력을 끌어냅니다. 출력 형식(표/불릿/JSON), 분량, 독자, 의사결정 용도를 못 박는 것이 G(Goal)입니다. 목표가 명확하면 평가도 명확해집니다. 좋은 결과물의 기준을 프롬프트 안에 적어두면, 모델은 그 기준을 향해 수렴합니다.

패턴 4. 예시 없음: 설명하지 말고 보여줘라

네 번째는 예시 없음입니다. 원하는 형식을 말로 길게 설명하는 것보다, 잘 된 예시 한두 개를 보여주는 편이 압도적으로 정확합니다. 이를 퓨샷(few-shot) 프롬프팅이라고 합니다.

근거는 충분합니다. Wei 등의 〈Chain-of-Thought Prompting〉(2022)은 단 8개의 추론 예시를 제시하는 것만으로 540B 모델이 GSM8K 수학 문제 벤치마크에서 검증기를 붙인 파인튜닝 GPT-3마저 넘어서는 최고 수준 정확도를 달성했다고 보고했습니다(arXiv:2201.11903). 잘 고른 예시 몇 개가 장황한 설명보다 강력하다는 뜻입니다. 단, 예시는 실제 용도와 가깝고, 다양하며, 엣지 케이스를 포함할 때 효과가 큽니다 — 빈약하거나 한쪽으로 치우친 예시는 오히려 편향을 학습시킵니다.

회사에서 이건 자산화로 직결됩니다. 잘 나온 결과물 하나를 “골든 예시”로 저장해 다음 프롬프트에 붙이면, 품질이 사람에서 시스템으로 옮겨집니다. 이것이 E(Example) — 설명 대신 모범 사례를 보여주는 단계입니다.

패턴 5. 반복 없음: 한 번에 끝내려는 착각

마지막은 반복(피드백) 없음입니다. 첫 출력을 그대로 쓰고 마는 것은 가장 흔한 낭비입니다. 좋은 프롬프트는 대화이지 한 방의 명령이 아닙니다. “이 부분은 너무 일반적이야, 우리 사례로 다시” “톤을 더 단호하게” 같은 교정을 한두 번 거치는 것만으로 결과물이 크게 좋아집니다.

더 중요한 건 개인의 반복을 시스템의 반복으로 만드는 것입니다. MIT 보고서가 95% 실패의 원인으로 지목한 “학습 격차”의 핵심이 바로 이것입니다. 대부분의 도입이 피드백을 보존하지 않고, 맥락에 적응하지 않으며, 시간이 지나도 개선되지 않습니다(MIT NANDA, 2025). 잘 된 프롬프트와 교정 이력을 팀이 공유하고 재사용해야 개인의 시행착오가 조직의 자산으로 축적됩니다. 이것이 R(Refine) — 결과를 평가하고, 교정하고, 그 교정을 다시 자산으로 남기는 단계입니다.

5패턴을 한 장으로: T.I.G.E.R로 다시 쓰기

다섯 패턴은 그대로 T.I.G.E.R에 매핑됩니다. 모호함 → T(과업을 동사로 명확히), 맥락 부족·과잉 → I(필요한 입력만 구조화해서, 핵심은 앞뒤로), 목적 불명 → G(독자·형식·용도·기준), 예시 없음 → E(골든 예시 1~2개), 반복 없음 → R(교정과 자산화).

같은 회의록 요약 요청을 비교해 보면 차이가 분명합니다. “회의록 정리해줘”(모호·맥락 없음·목적 없음·예시 없음·반복 없음)와, “[T] 아래 회의록에서 결정사항을 추출해 [I] 다음 용어집과 지난 결정 맥락을 참고하고, 자료는 ### 구분자로 구분했어, [G] 영업 임원이 투자 판단에 쓸 3줄 요약 + 결정사항 표로, [E] 이 형식처럼, [R] 초안 후 내가 톤을 교정할게” 이 둘은 같은 모델, 같은 입력에서 전혀 다른 결과를 냅니다. 더 깊은 작성 원칙은 프롬프트 5원칙 가이드에서 이어집니다.

여기까지가 개인이 프롬프트를 잘 쓰는 법입니다. 그런데 진짜 격차는 그다음에 생깁니다. 우리가 사내에서 구축한 사례들 — 결재 처리를 30분에서 3분으로 줄인 12개 도구 기반 자가복구 에이전트, 음성 기록을 30분에서 5분으로 줄이고 주간보고를 1시간에서 10분으로 줄인 영업 대시보드, 위키 150건과 3개 에이전트로 돌아가는 통합 운영 — 의 공통점은 좋은 프롬프트가 한 사람의 머리가 아니라 시스템에 박혀 반복·축적·복구된다는 것입니다. 이것이 T.I.G.E.R의 R을 조직 단위로 끌어올린 결과입니다. 팀 차원에서 프롬프트 역량을 표준화하고 싶다면 에이전틱타이거 교육에서 시작하시는 것을 권합니다.

자주 묻는 질문

프롬프트만 잘 쓰면 환각을 없앨 수 있나요?

완전히 없앨 수는 없지만 크게 줄일 수 있습니다. 환각의 상당 부분은 모델이 근거 없이 빈칸을 메우는 데서 나옵니다. TruthfulQA에서 당시 최대 모델조차 진실한 답변이 58%에 그쳤다는 결과가 그 증거입니다(Lin et al., 2021). 필요한 맥락을 명확히 주고, “자료에 없으면 모른다고 답하라”는 제약을 걸고, 출력을 검증 가능한 형식으로 받으면 환각은 눈에 띄게 감소합니다. 다만 사실 정확성이 중요한 업무라면 프롬프트만이 아니라 검색 기반(RAG)과 검증 단계를 함께 설계해야 합니다.

맥락은 많이 줄수록 좋은 거 아닌가요?

아닙니다. 〈Lost in the Middle〉 연구는 긴 맥락의 중간에 핵심 정보가 묻히면 성능이 급락하고, 맨 앞이나 맨 뒤에 있을 때 가장 정확하다는 것을 보였습니다(arXiv:2307.03172). 자료를 무작정 다 붙여넣기보다, 관련된 것만 선별하고 핵심과 질문을 맨 앞이나 맨 뒤에 배치하는 편이 낫습니다. 양보다 구조와 위치가 중요합니다.

예시는 몇 개나 넣어야 하나요?

용도에 따라 다르지만, 1~3개로 시작해 부족하면 늘리는 것이 실용적입니다. Wei 등의 연구에서는 8개의 추론 예시로 큰 성능 향상을 얻었지만(arXiv:2201.11903), 단순 형식 지정 작업은 한두 개로 충분한 경우가 많습니다. 중요한 건 개수보다 품질입니다 — 실제 업무와 닮았고, 엣지 케이스를 포함한 예시여야 효과가 납니다.

한국 기업도 이런 격차가 있나요?

있습니다. 대한상공회의소·산업연구원이 국내 기업 500곳을 조사한 결과, 78.4%가 AI 기술이 필요하다고 답했지만 실제 활용률은 약 30%에 그쳤습니다(중소기업 28.7%, 중견기업 30.1%, 대기업 48.8%)(대한상공회의소, 2024). 도입 자체보다 “어떻게 일에 녹여 쓰느냐”가 격차의 핵심이며, 이는 글로벌 데이터(MIT 95% 파일럿 무성과, 맥킨지 전사 EBIT 영향 39%)와 같은 결을 보입니다.

프롬프트 잘 쓰는 직원만 키우면 충분한가요?

개인 역량은 출발점이지 종착점이 아닙니다. MIT 보고서가 95% 실패의 원인으로 지목한 것은 모델이 아니라 학습 격차 — 피드백이 보존되지 않고 시스템에 축적되지 않는 구조였습니다(MIT NANDA, 2025). 개인의 좋은 프롬프트가 팀의 골든 예시·표준 워크플로우·자가복구 에이전트로 옮겨갈 때 비로소 ROI가 납니다. 무엇을 자동화할지(반복·연결·누적·복구되는 일), 무엇을 사람이 쥘지(최종 결정·신뢰·창의)를 함께 설계하는 것이 다음 단계입니다.