
Eleven 다국어 v2
- 카테고리
- ElevenAPI
- 날짜
대화형 AI 시스템에서 대형 언어 모델을 제대로 프롬프트하는 것이 결과를 크게 좌우합니다.
오늘날 LLM(대형 언어 모델)은 대화형 AI 시스템의 핵심 역할을 하고 있습니다. 특히, LLM은 대화형 AI — 원래는 복잡한 전화 트리 기반으로 만들어졌던 시스템 — 에서도 동적인 기능과 사람과 비슷한 경험을 제공할 수 있게 해줍니다. 하지만 LLM이 만능 해결책은 아닙니다. 기본적으로 인간의 대화에 맞춰 세밀하게 조정되어 있지 않기 때문에, 전문적인 프롬프트가 필요합니다.
개발자들이 대화형 AI에서 LLM을 프롬프트할 때 흔히 하는 실수는, 사람 직원을 교육할 때 사용했던 방식 그대로를 적용하는 것입니다. 이 전략은 겉보기엔 쉬워 보이지만, 실제로는 거의 효과가 없습니다. LLM은 일반적인 사람과는 다른 가정을 하며, 기본적인 말투와 범위도 대화에 적합하지 않습니다.
오늘은 LLM을 어떻게 프롬프트해야 성공적인 대화형 AI 시스템을 만들 수 있는지 알아보겠습니다. 이 주제에 대해 더 자세하고 기술적인 가이드는 ElevenLabs 개발자 문서.
LLM 도입 전에는 대화형 AI 시스템이 복잡한 논리 트리를 활용해 음성 입력에 따라 요청을 분류했습니다. 이런 방식은 고객센터(예: 항공사 콜센터)나 결제 시스템(예: 신용카드 전화 서비스)에서 많이 사용됐습니다.
이전 시스템은 느리고, 기계적인 느낌이 강했으며, 사용자가 입력할 수 있는 범위도 매우 제한적이었습니다. 아마 직접 경험해보셨을 수도 있는데, 프롬프트에 대답하려고 전화기에 대고 “예!”라고 소리쳤던 기억이 있을 겁니다. 이런 불편한 경험 때문에 많은 사용자가 실제 상담원과 대화하려고 ‘시스템을 뚫으려’ 시도하곤 했습니다.
하지만 이런 전화 트리에도 장점이 있었습니다. 범위가 제한적이었기 때문에, 대화가 갈 수 있는 경로가 한정되어 있었고, 개발자가 허용되지 않은 입력을 쉽게 차단할 수 있었습니다. 이 제한이 LLM의 장단점을 잘 보여줍니다. LLM은 전화 트리의 한계를 크게 뛰어넘지만, 동시에 예측 불가능해져서 불가능한 약속을 하거나, 고객에게 화를 내거나, 민감한 정보를 유출하는 등 다양한 위험이 생길 수 있습니다.
LLM이 사람을 위해 만들어진 매뉴얼만으로 학습된다면, 몇 가지 핵심적인 한계 때문에 성과가 그저 그런 수준에 머물 수 있습니다. 이 한계를 이해하면, 이를 보완하는 프롬프트를 설계할 수 있습니다:
LLM은 강화 학습을 통해 훈련되며, 사람의 피드백을 받아 구조화된 답변을 하도록 유도됩니다. 그래서 LLM의 답변은 장황하고, 글머리표, 강조 블록, 제목 등이 자주 포함됩니다.
하지만 대화형 AI에서는 LLM이 실제 대화처럼 간결하고 평평한(단순한) 말투를 따라야 합니다.
LLM은 모르는 부분이 있으면 질문하기보다는 스스로 추론해서 채우려는 경향이 있습니다. 이로 인해 잘못된 가정을 하거나, 사용자를 오도하거나, 비용이 드는 실수를 할 수 있습니다(예: 환불 약속). 이후에 지식 베이스와 가드레일을 활용해 LLM이 잘못된 약속이나 허용되지 않은 행동을 하지 않도록 하는 방법을 살펴보겠습니다.
LLM은 프로그래밍적으로 함수 호출을 실행해 사람 대신 데이터를 수집하거나 기록할 수 있습니다. 이는 LLM의 큰 장점이지만, 예전에는 상담원이 작업을 하면서 ‘시간을 벌기’ 위해 사용하던 안내 문구가 더 이상 필요하지 않다는 의미이기도 합니다. 하지만 함수 호출도 즉각적이지 않으므로, LLM은 지연이 예상될 때마다 사용자에게 미리 안내해야 합니다(예: “잠시만 기다려 주세요, 내용을 확인하겠습니다.”).
LLM은 원하는 스타일에 맞춰 말투를 조정하는 데 꽤 능숙합니다. LLM은 친근하거나, 유머러스하거나, 간결하거나, 격식 있는 등 다양한 스타일로 설정할 수 있습니다. 프롬프트 작성 시 이 부분이 중요한 입력값이 됩니다.
예를 들어, 불만이 많은 항공사 고객을 지원하는 대화형 AI 고객센터를 개발하는 경우, 다음과 같은 프롬프트를 사용할 수 있습니다:
Nicole
LLM이 어떻게 답변해야 하는지 명확하게 지시해야 합니다. 불필요한 추가 문구 없이, 사용자에게 전달할 답변의 구조를 LLM에 제공하는 것이 좋습니다.
예를 들어, LLM에 다음과 같이 프롬프트할 수 있습니다:
이런 구조를 제공하면 LLM이 실제로 말로 전달하기 좋은 답변을 생성하도록 유도할 수 있습니다.
하지만 LLM이 글과 말의 차이를 직관적으로 구분하지 못해 실수하는 경우도 있습니다. 대표적인 예가 숫자입니다. LLM이 우편번호 10023을 그대로 출력하면 텍스트 음성 변환 모델이 “만 이십삼”처럼 읽게 됩니다. 대신, LLM에 숫자를 한 자리씩 읽고, 의미를 명확히 안내하도록 프롬프트해야 합니다. 예: “우편번호는 일, 영, 영, 이, 삼입니다.”
온도는 대화형 AI에서 LLM을 설정할 때 매우 중요한 파라미터입니다. 온도가 낮을수록 더 집중되고 예측 가능한 답변이 생성되어, 업무 중심의 대화에 적합합니다. 반면, 온도가 높으면 더 창의적이고 다양한 답변이 나옵니다.
온도가 낮은 설정은 일관된 답변이 필요한 대화형 AI(예: 환불 고객센터)에 적합합니다. 반면, 더 몰입감 있고 현실감 있는 경험을 제공하고 싶다면(예: 디지털 코치), 온도를 높게 설정하는 것이 좋습니다:
더 많은 지식이 필요한 대화형 AI 시스템에서는 프롬프트 길이를 최소화하기 위해 지식 베이스를 활용해야 합니다. 실제 서비스에서는 벡터 데이터베이스(예: Pinecone, Elasticsearch)나 LLM 제공업체의 지식 저장소를 통해 구현합니다.
일반적으로, 지식 베이스는 LLM의 답변이 사실에 기반하고 승인된 정보에 근거하도록 하는 데 필수적입니다. 대화형 AI 시스템을 구축할 때는 제품, 서비스, 정책, 절차 등 최신의 정확한 정보를 담은 지식 베이스를 LLM에 제공해야 합니다. 이렇게 하면 LLM이 정보를 지어내거나 일관성 없는 답변을 하는 것을 방지할 수 있습니다.
LLM이 사용자 대신 함수를 호출하는 경우가 많기 때문에, 어떤 입력값이 꼭 필요한지도 알아야 합니다. 예를 들어, LLM이 미용실 예약을 도와주는 역할이라면, 다음 정보를 반드시 확보해야 합니다:
단순하게 구현하면 LLM이 한 번에 모든 정보를 요청할 수 있습니다. 텍스트라면 괜찮지만, 대화에서는 부담스럽게 느껴질 수 있습니다:
정보는 대화를 통해 점진적으로 수집되는 경우가 많으므로, LLM이 한 번에 묻지 않고 나눠서 질문하도록 유도해야 합니다. 이렇게 하면 훨씬 자연스러운 대화 경험을 제공합니다:
분산 시스템을 만들 때 서버가 언젠가 장애를 일으킬 수 있다고 가정하듯, AI 시스템을 만들 때도 LLM이 실수할 수 있다고 생각해야 합니다. 실수의 영향을 최소화하려면, 시스템에 꼭 필요한 최소한의 권한만 부여해야 합니다. 아래는 이를 실현하는 방법의 예시입니다:
대화형 AI 음성 에이전트 시스템에서 도구를 사용해 작업을 수행할 때, 사용자의 정보를 올바르게 수집하고 있는지 검증 및 확인 프로세스를 구축하는 것이 좋습니다. 실제 상담원과 대화할 때도 중요한 정보를 다시 확인해 잘 들었는지, 고객이 잘못 말하지 않았는지 체크하듯, LLM도 비슷한 오류 검증이 필요합니다:
검증 단계에서는 고객이 제공한 정보가 일반적인 형식에 맞는지 확인해야 합니다. 전화번호 자릿수가 맞는지, 나이가 합리적인 범위인지, 주소가 유효한지 등을 체크합니다.
사용 목적에 따라 모든 정보를 검증할 수도 있고, 검증에 실패한 정보만 다시 확인할 수도 있습니다. 또한, 정보가 들어올 때마다 바로 검증할지, 마지막에 한 번에 검증할지도 선택할 수 있습니다.
성공적인 대화형 AI 에이전트 시스템 프롬프트 작성은 적절한 설정과 가드레일을 조화롭게 적용해, 사람과 대화하는 듯한 효율적인 경험을 만드는 일입니다. 단순히 기존 교육 자료를 LLM에 적용하는 것만으로는 충분하지 않습니다. LLM은 예측 가능하고 효과적인 결과를 위해 전문적인 구조와 전략이 필요한 도구입니다.



