많은 개발자와 프로덕트 매니저들이 AI 모델을 도입하며 겪는 가장 큰 좌절감은 ‘분명히 지시했는데 왜 다르게 행동하는가’라는 점입니다. 최신 모델로 업데이트하고, 수십 줄의 상세한 프롬프트를 작성해도 AI는 때때로 교묘하게 지시사항을 무시하거나, 전혀 엉뚱한 답변을 내놓으며 사용자를 당혹스럽게 합니다. 우리는 이를 단순히 ‘성능 부족’이나 ‘운이 나쁜 케이스’로 치부하곤 하지만, 사실 이 현상 뒤에는 LLM(대규모 언어 모델)의 확률적 구조와 인간의 결정론적 기대 사이의 깊은 간극이 자리 잡고 있습니다.

AI가 사용자의 의도대로 움직이지 않는 현상을 정확히 이해하려면, 먼저 우리가 겪는 불편함의 정체가 무엇인지 구분해야 합니다. 많은 이들이 AI가 말을 듣지 않는 상황을 하나로 묶어 생각하지만, 기술적으로 이는 ‘고집(Stubbornness)’과 ‘환각(Hallucination)’이라는 전혀 다른 두 가지 메커니즘의 결과입니다.

AI의 ‘고집’과 ‘환각’, 무엇이 다른가?

먼저 ‘고집’은 모델이 학습 데이터 속에 강하게 각인된 패턴이나 안전 가이드라인(RLHF)으로 인해 사용자의 특정 지시를 거부하거나 우회하는 현상을 말합니다. 예를 들어, 특정 톤앤매너를 유지하라고 지시했음에도 불구하고 모델이 계속해서 전형적인 ‘AI스러운’ 정중하고 딱딱한 말투로 돌아오는 경우가 이에 해당합니다. 이는 모델이 ‘가장 확률적으로 안전하고 일반적인 답변’을 내놓으려는 경향이 사용자의 ‘특수한 요구사항’보다 강하게 작용하기 때문입니다.

반면 ‘환각’은 모델이 아예 존재하지 않는 정보를 사실처럼 생성해내는 현상입니다. 이는 모델이 지시를 거부하는 것이 아니라, 오히려 사용자의 질문에 답하려는 ‘의욕’이 과해 발생합니다. LLM은 기본적으로 다음에 올 가장 확률 높은 토큰을 예측하는 기계입니다. 정보가 부족한 상태에서도 문법적으로 완벽한 문장을 만들어내야 한다는 압박(확률적 최적화)이 사실 관계의 왜곡으로 이어지는 것입니다.

결국 사용자가 느끼는 ‘내 맘 같지 않은 AI’라는 경험은, 모델이 너무 보수적으로 굴 때(고집)와 너무 과감하게 거짓말을 할 때(환각)가 교차하며 발생하는 인지적 부조화의 결과입니다.

제품 관점에서의 함의: 왜 프롬프트만으로는 부족한가?

많은 실무자가 프롬프트 엔지니어링을 통해 이 문제를 해결하려 합니다. 하지만 프롬프트는 모델의 ‘입력값’을 조정하는 것일 뿐, 모델의 ‘가중치’나 ‘추론 로직’ 자체를 바꾸는 것이 아닙니다. 이는 마치 성격이 급한 사람에게 ‘천천히 말해달라’고 메모를 남기는 것과 같습니다. 잠시 동안은 주의를 기울이겠지만, 대화가 길어지거나 복잡한 과업이 주어지면 결국 본래의 성격(학습된 패턴)이 튀어나오게 됩니다.

따라서 AI 제품을 설계할 때는 모델의 능력을 맹신하기보다, 모델이 실패할 지점을 미리 예측하고 이를 보완하는 ‘가드레일’을 설계하는 것이 훨씬 중요합니다. 모델에게 모든 것을 맡기는 ‘Zero-shot’ 방식에서 벗어나, 구체적인 예시를 제공하는 ‘Few-shot’ 전략이나 외부 지식을 참조하게 하는 RAG(검색 증강 생성) 구조를 도입해야 하는 이유가 여기에 있습니다.

실무 적용을 위한 기술적 접근법

AI가 더 정확하게 사용자의 의도를 반영하게 만들기 위해서는 단순한 명령어를 넘어선 전략적 접근이 필요합니다. 다음은 실제 구현 단계에서 고려해야 할 핵심 요소들입니다.

• 페르소나의 구체적 정의: 단순히 ‘전문가처럼 행동해줘’라고 하기보다, ’10년 차 시니어 소프트웨어 엔지니어로서, 코드의 효율성보다는 유지보수성을 최우선으로 생각하며 비판적으로 리뷰하라’와 같이 제약 조건과 가치 판단 기준을 명확히 설정해야 합니다.
• 단계별 사고 유도 (Chain-of-Thought): 복잡한 지시를 한 번에 내리면 모델은 중간 단계를 생략하고 확률적인 결론으로 점프하려 합니다. ‘먼저 문제를 분석하고, 해결 방안 세 가지를 도출한 뒤, 각 방안의 장단점을 비교하여 최종안을 선택하라’는 식으로 사고의 경로를 강제해야 합니다.
• 출력 형식의 엄격한 제한: AI의 ‘말 많음’을 방지하기 위해 JSON이나 Markdown 표와 같은 구조화된 형식을 요구하십시오. 형식이 제한될수록 모델은 불필요한 수식어를 줄이고 핵심 정보에 집중하게 됩니다.

AI 모델 활용의 장단점 비교

우리가 사용하는 LLM의 특성을 이해하면, 어떤 상황에 어떤 전략을 써야 할지 명확해집니다.

실제 사례: 고객 상담 챗봇의 진화

한 이커머스 기업은 고객의 불만을 처리하는 AI 챗봇을 도입했습니다. 초기에는 ‘친절하고 공감하는 상담원’이라는 프롬프트만 설정했습니다. 결과는 참담했습니다. AI는 고객의 화난 감정에 너무 공감한 나머지, 규정에도 없는 환불 약속을 남발하는 ‘환각’ 증세를 보였습니다. 반대로 규정을 엄격히 입력하자, 고객의 감정을 완전히 무시하고 매뉴얼만 읊어대는 ‘고집’ 센 챗봇이 되었습니다.

이 문제를 해결하기 위해 팀은 전략을 수정했습니다. 먼저 RAG를 도입해 최신 환불 규정 문서를 실시간으로 참조하게 하여 환각을 줄였습니다. 그리고 ‘공감’과 ‘해결’이라는 두 단계를 분리했습니다. 모듈은 고객의 감정을 읽고 공감 메시지를 생성하고, 모듈은 참조 문서에 기반해 해결책을 제시한 뒤, 마지막 검수 모듈이 이 두 내용이 충돌하지 않는지 확인하는 파이프라인을 구축했습니다. 단일 프롬프트에 의존하던 방식에서 ‘워크플로우’ 중심으로 설계를 변경하자, AI는 비로소 사용자의 의도와 기업의 정책 사이에서 균형을 잡기 시작했습니다.

지금 당장 실행할 수 있는 액션 아이템

AI가 내 맘 같지 않아 답답함을 느끼는 실무자라면, 오늘부터 다음 세 가지를 시도해 보십시오.

첫째, ‘부정 명령어’를 ‘긍정 명령어’로 바꾸십시오. AI는 ‘~하지 마세요’라는 부정어보다 ‘~하세요’라는 긍정어에 더 잘 반응합니다. ‘전문 용어를 쓰지 마세요’ 대신 ‘중학생이 이해할 수 있는 쉬운 단어로 설명하세요’라고 지시하십시오.

둘째, ‘생각할 시간’을 부여하십시오. 답변을 바로 내놓으라고 하지 말고, “답변을 작성하기 전에 내부적으로 먼저 계획을 세우고, 그 계획을 먼저 출력한 뒤 최종 답변을 작성하라”고 요청하십시오. 이는 모델의 추론 정확도를 획기적으로 높이는 방법입니다.

셋째, 실패 사례의 데이터베이스를 구축하십시오. AI가 지시를 무시한 케이스들을 모아 ‘Bad Case’ 리스트를 만드십시오. 이를 통해 우리 서비스의 모델이 특히 어떤 부분에서 ‘고집’을 부리는지, 어떤 패턴에서 ‘환각’을 일으키는지 파악하면 프롬프트 수정이 아닌 시스템적 보완(예: 필터링 레이어 추가)이 가능해집니다.

결론: 통제가 아닌 협업의 관점으로

AI를 완벽하게 통제할 수 있는 마법의 프롬프트는 존재하지 않습니다. LLM은 결정론적인 소프트웨어가 아니라 확률적인 엔진이기 때문입니다. 우리가 해야 할 일은 AI를 완벽하게 조종하려는 시도가 아니라, AI가 가질 수 있는 한계를 인정하고 그 빈틈을 메우는 시스템을 설계하는 것입니다.

결국 고품질의 AI 경험은 모델의 성능 그 자체가 아니라, 모델의 불완전함을 어떻게 관리하느냐는 ‘오케스트레이션’ 능력에서 결정됩니다. AI가 내 말을 듣지 않는다고 화를 내기보다, 왜 이 지점에서 모델이 확률적 함정에 빠졌는지를 분석하는 관점을 가질 때 비로소 우리는 AI를 도구가 아닌 진정한 파트너로 활용할 수 있을 것입니다.