새로운 시대의 AI 프로덕트가 기존의 프로덕트와 무엇이 다른지를 다룹니다. PM의 관점에서 말하지만, AI 프로덕트를 다루는 모두 참고할 만한 이야기를 묶었습니다. 필자가 출간할 예정인 <AI Product Management(가제)> 책의 일부를 요즘IT 독자의 시선에 맞춰 재가공했습니다.

① AI는 왜 자꾸 틀리는가

엔지니어는 아니지만, PM도 가져야 할 직관

1950년 어느 저녁, 벨연구소의 수학자 클로드 섀넌(Claude Shannon)이 부인 메리에게 게임 하나를 제안했습니다. 먼저 책 한 권을 펼쳐놓고, 클로드가 아무렇게나 펼친 페이지에서 한 글자를 가립니다. 이제 메리는 가려진 글자가 무엇일지 맞혀야 합니다. 첫 글자를 맞히면 다음 글자로 넘어가고, 틀리면 정답을 알려준 뒤 다음 글자로 넘어갑니다. 그렇게 한 문장을 끝까지 따라가는 게임입니다.

결과는 놀라웠습니다. 메리는 보통 가려진 글자 4개 중 3개 가까이 맞혔습니다. ‘T’ 다음에 ‘H’가, ‘TH’ 다음에 ‘E’가 올 가능성이 높다는 사실을 무의식적으로 알고 있었기 때문입니다. 이는 메리처럼 영어를 모국어로 쓰는 사람의 머릿속에는 어떤 글자 다음에 어떤 글자가 올 확률이 통계적으로 자리 잡혀 있다는 뜻이기도 했습니다. 섀넌은 이 실험에서 출발해 “언어에는 예측 가능한 구조가 있다”는 사실을 수학적으로 증명했고, 이 발견이 훗날 LLM의 토대가 되었습니다. 앤트로픽의 클로드도, 바로 이 수학자의 이름에서 따왔다고 알려져 있습니다.

참조: Claude E. Shannon, “Prediction and Entropy of Printed English”, Sep 15, 1950

75년이 지난 지금, 우리가 쓰는 LLM은 매일 이 게임을 합니다. 챗GPT나 클로드는 메리가 가려진 글자를 추론한 것과 같은 원리로 논문을 쓰고, 코드를 짜고, 시를 만들어냅니다.

이제 알아볼 모든 지식에 앞서는 핵심은 이것입니다. LLM이 하는 일을 한 줄로 요약하면, “다음에 올 단어를 확률적으로 예측하는 것”이라는 점입니다. 섀넌이 1950년에 메리와 했던 게임을 거대한 규모로 키운 확장판입니다. 다만 “다음 한 글자”가 아니라 “다음 한 단어”이고, 메리 한 사람의 직관이 아니라 인터넷 전체의 텍스트로 학습한 통계 모델을 쓸 뿐입니다.

그런데 PM이 이걸 알아야 하는 이유가 뭘까요? 엔지니어가 아닌데 굳이 LLM의 동작 원리까지 들여다볼 필요가 있을까요?

결론부터 말하면, 있습니다. 다만 엔지니어처럼 깊이 알 필요는 없습니다. “이 정도는 알아야 의사결정을 할 수 있다”는 최소한의 직관이 필요한 이유와 함께, 그 직관을 만들어 줄 지식 다섯 가지를 짚어보겠습니다.

1. 토큰: LLM은 글자를 우리와 다르게 본다

우리는 글을 단어 단위로 읽습니다. “나는 오늘 점심을 먹었다”는 네 단어죠. 그런데 LLM은 다르게 봅니다. 토큰(token)이라는 단위로 잘라서 처리하는 것입니다. 이 토큰은 단어보다 작을 수도 있고 클 수도 있는, 모델이 학습 과정에서 만들어낸 일종의 “기본 조각”입니다.

예를 들어 “unhappiness”라는 단어는 영어 LLM에서 보통 “un”, “happi”, “ness” 세 토큰으로 잘립니다. 한국어 “먹었습니다”는 “먹”, “었”, “습니다” 식으로 쪼개지죠.

게다가 한국어는 같은 의미를 표현하는 데 영어보다 토큰을 더 많이 씁니다. 같은 말을 하는데 영어보다 약 1.5~2배의 토큰이 필요한 경우가 많습니다. 영어로 “Thank you very much”가 4~5토큰이라면, 한국어 “정말 감사합니다”는 7~8토큰이 들 수도 있다는 뜻입니다.

이게 왜 PM에게 중요할까요? LLM의 비용은 토큰 단위로 계산되기 때문입니다. 같은 길이의 문장을 다룬다 해도, 한국어 서비스는 영어 서비스보다 비용이 더 나옵니다. 또 모델마다 “한 번에 처리할 수 있는 최대 토큰 수”가 정해져 있는데, 한국어로 작업하면 그 한도에 더 빨리 도달합니다. 이걸 모르고 시스템을 설계하면, 출시 후 비용 청구서에서 놀라거나, 긴 문서를 처리할 때 갑자기 답이 잘려 나오는 일을 만나게 됩니다. 한국어 기반 AI 서비스를 만드는 PM이 글로벌 사례를 그대로 가져다 쓰면 안 되는 이유가 여기에 있습니다.

2. 컨텍스트: LLM에게는 단기 기억밖에 없다

챗GPT나 클로드와 길게 대화하다 보면 어느 순간 모델이 앞에서 한 이야기를 잊어버리는 걸 경험해 보셨을 겁니다. 처음에 “제 이름은 홍길동이에요”라고 말해놓고 50번쯤 메시지를 주고받은 뒤 “제 이름이 뭐였죠?”라고 물어보면, 홍길동이라는 이름 대신 이상한 답이 돌아오기도 합니다.

이건 버그가 아니라 구조적 한계입니다. LLM은 컨텍스트 윈도우라는 한정된 “단기 기억 공간”만 가지고 있습니다. 모델마다 다르지만 보통 수만에서 수십만 토큰 정도입니다. 그 안에 들어 있는 정보로만 답을 만들고, 그걸 벗어난 내용은 “존재하지 않는 것처럼” 처리됩니다.

더 중요한 사실은, LLM에는 우리가 흔히 생각하는 “장기 기억”이 없다는 점입니다. 어제 제미나이와 나눈 대화를 모델이 “기억”하고 있는 것처럼 보여도, 실은 대부분의 경우 어제 나눈 그 대화 내용을 매번 새로 컨텍스트에 끼워 넣어주는 방식으로 동작합니다. 모델 자체는 우리를 알지 못합니다. 그저 매번 “이 대화의 앞부분은 이랬다”는 메모를 새로 받아서 읽고 답할 뿐입니다.

이 사실이 PM에게 의미하는 것은 우리가 만드는 AI 기능에서 “사용자를 기억하는 듯한 경험”을 주려면, 이를 위한 시스템을 따로 설계해야 한다는 것입니다. 사용자 정보를 데이터베이스에 저장해두고, 모델에게 매번 “이 사용자는 이런 사람입니다”라고 알려주는 시스템을 만들어야 합니다. 모델이 알아서 기억해 줄 거라고 가정하면 안 됩니다.

컨텍스트 윈도우에는 시스템 프롬프트, 사용자 메시지, 주고받는 내용이 모두 계속 누적된다. <출처: 작가>

3. 추론: 같은 질문에 왜 답이 매번 다른가

지난 글에서 우리는 “챗GPT에 같은 질문을 100번 던지면 100번 다 다른 답이 돌아온다”는 이야기를 했습니다. 이건 단순히 “AI는 확률적이다”라는 문장 하나로 끝맺을 사실은 아닙니다. 왜 그렇게 되는지, 그 안에서 무슨 일이 일어나는지를 알아야 AI 프로덕트를 만들 때 보이는 풍경이 달라집니다. 이를 위해 알아야 할 핵심 지식, 추론(inference)은 학습이 끝난 모델이 실제로 답을 “만들어내는” 과정을 가리키는 말입니다.

답은 “계산”되는 게 아니라 “뽑힌다”

사용자가 “파리는 어느 나라의 수도인가요?”라고 물었다고 합시다. 모델은 이 질문에 대해 어휘집에 있는 모든 토큰 각각에 확률값을 매깁니다. 문장의 시작부터 답이 나와야 한다고 했을 때, “프랑스”가 42%, “프”가 11%, “유럽”이 8%, 나머지 토큰들이 나머지 확률을 나눠 갖는 식입니다. 그러고 나서 이 확률 분포를 참조해 토큰 하나를 “뽑습니다”. 뽑힌 토큰을 답의 첫 글자로 삼고, 그다음 토큰의 확률 분포를 다시 계산해서 또 뽑습니다. 이 과정을 문장이 끝날 때까지 반복합니다.

핵심은 “뽑는다”는 동사에 있습니다. 모델에 매번 확률이 가장 높은 토큰만 무조건 고르라고 하면(이를 그리디 디코딩이라고 합니다) 결과는 단조롭고 반복적으로 나옵니다. 그래서 실제로는 확률 분포에서 무작위로 샘플링하는 방식을 씁니다. 확률이 높은 토큰이 선택될 가능성이 높지만, 낮은 토큰도 가끔 선택됩니다. 이 작은 무작위성 때문에 같은 질문에도 매번 조금씩 다른 답이 나오는 것입니다.

Temperature, PM이 실제로 만지는 손잡이

그 무작위성의 강도를 조절하는 파라미터가 Temperature(온도)입니다. 보통 0에서 2 사이 값을 가지는데, 낮을수록 확률 분포가 “날카로워져서” 가장 그럴듯한 토큰이 거의 항상 선택됩니다. 그러면 결과가 일관성을 지니며 예측 가능합니다. 반대로 값이 높을수록 분포가 “평평해져서” 낮은 확률의 토큰도 자주 선택됩니다. 다양하고 창의적인 결과가 나오지만, 때로 엉뚱하거나 부정확합니다.

그런 만큼 Temperature는 사용자 경험을 직접 좌우합니다. 팩트를 답해야 하는 고객 지원 챗봇은 Temperature를 낮게(0.1~0.3) 잡아야 합니다. 같은 질문에 다른 답이 나오면 신뢰가 무너지니까요. 반대로 마케팅 문구를 만드는 도구나 브레인스토밍 도우미는 Temperature를 높게(0.7~1.2) 잡아야 다양한 아이디어가 나옵니다. “기본값으로 두면 알아서 잘 되겠지”라는 생각은 PM이 빠지기 쉬운 흔한 함정입니다. 태스크마다 적절한 Temperature를 의식적으로 설계해야 합니다.

환각의 진짜 원인, 자신만만하게 틀리는 이유

1편에서 본 에어캐나다 챗봇 사건, 기억하시나요? 챗봇이 회사의 실제 정책과 다른 답을 자신만만하게 내놓아서 회사가 소송에 휘말렸던 일 말입니다. 그 챗봇은 왜 그렇게 자신만만했을까요? 추론 메커니즘을 알면 답이 보입니다.

LLM은 답을 생성할 때 “이것이 사실인가?”를 검증하지 않습니다. “이 문맥에서 이 토큰이 얼마나 그럴듯한가?”만 계산합니다. 그러니까 “가족 장례로 인한 할인이 있나요?”라는 질문을 받으면, 항공사 챗봇은 으레 할 법한 “네, ~한 절차로 신청하실 수 있습니다” 같은 답변 패턴이 가장 그럴듯하다고 판단합니다. 곧이어 그에 맞춘 적당한 구성으로 답을 뽑아냅니다. 그 답이 실제 회사 정책과 맞는지는 모델의 관심 밖입니다.

더 까다로운 건, 모델이 환각을 일으킬 때도 어조에 망설임이 없다는 점입니다. 사람은 확신이 없을 때 “잘 모르겠는데요”라고 말하거나 목소리가 흔들리는 등 전조를 보입니다. 반면 LLM은 불확실한 상황에서도 가장 그럴듯한 토큰을 자신 있게 뽑아 유창하게 이어 붙입니다. 이것이야말로 환각을 위험하게 만드는 결정적 특성입니다. 틀린 내용을 자신 있게 말한다면, 사용자가 그게 틀렸다는 걸 알아채기가 거의 불가능합니다.

아첨(Sycophancy), 사용자에게 맞춰 비틀어지는 답

최근 몇 년 사이 LLM에서 새롭게 주목받는 현상이 하나 더 있습니다. 아첨(sycophancy)이라고 부르는데, 사용자가 어떤 답을 기대하는 것처럼 보이면 모델이 그 기대에 맞춰 답을 비트는 경향입니다. “제 사업 아이디어 어떻게 생각하세요?”라고 물으면 대부분 칭찬이 돌아옵니다. “이거 문제 있죠?”라고 물으면 정말 문제가 없는 경우에도 문제를 찾아 답해줍니다.

이건 모델이 “착해서”가 아닙니다. 학습 과정에서 사용자가 만족스러워한 답변에 더 높은 점수가 매겨졌고, 그 패턴이 모델의 확률 분포에 새겨졌기 때문입니다. PM 입장에서 이건 진지하게 다뤄야 할 문제입니다. AI 어시스턴트가 의견에 항상 동의하고 칭찬만 남발한다면, 사용자는 그 피드백을 점점 덜 신뢰하게 됩니다. 비판적인 피드백이나 다양한 관점이 필요한 기능을 만들 때는, 모델이 “반대 의견이나 약점을 명시적으로 제시하도록” 프롬프트 수준에서 의도적으로 설계해 줘야 합니다.

4. RAG: LLM에 참고서를 들려주는 법

이제 우리는 환각과 아첨이 왜 일어나는지 알게 됐습니다. 모델이 “학습 때 본 패턴”으로만 답하기 때문이죠. 그렇다면 모델이 학습할 때 보지 못한 정보 — 회사 내부 매뉴얼, 최근 뉴스, 우리 서비스의 정책 같은 것들 — 에 대해 정확히 답하려면 어떻게 해야 할까요?

이 문제를 풀기 위해 등장한 접근법이 RAG(Retrieval-Augmented Generation, 검색 증강 생성)입니다. 이름은 어렵지만 구조는 단순합니다. 사용자가 질문하면, 시스템이 일단 회사의 자료 창고(매뉴얼, 위키, 정책 문서 등)에서 관련 내용을 검색합니다. 그 검색 결과를 모델의 컨텍스트에 함께 넣어주고, "이 자료를 참고해서 답해줘"라고 요청합니다.

쉽게 말하면, LLM에 “참고서”를 펼쳐주고 답하게 하는 방식입니다. 이렇게 하면 모델은 자기 머릿속의 기억에 의존하는 게 아니라, 그 자리에서 펼쳐 본 자료를 근거로 답합니다. 이 방식이 도입되면서 기업용 AI 기능이 비로소 “우리 회사 문서를 아는 챗봇”이 될 수 있었습니다. 환각도 상당 부분 줄어듭니다. 답할 근거가 손에 쥐어져 있으니까요.

PM 입장에서 RAG가 중요한 이유는, AI 기능을 기획할 때 “이건 LLM 혼자 잘 못 한다, 자료를 함께 줘야 한다”는 판단이 필요하기 때문입니다. “우리 회사 정책에 대해 답해주는 챗봇”을 만든다고 했을 때, 그게 LLM만으로 되는 일인지, RAG가 필요한 일인지를 구분할 줄 알아야 합니다. 거의 모든 기업용 AI 기능은 후자입니다. 에어캐나다 챗봇이 환각을 일으킨 것도, 회사의 실제 정책 문서가 모델 곁에 없었기 때문이라고 볼 수 있습니다.

5. 에이전트: LLM에게 손과 발을 주는 법

여기까지 본 LLM은 결국 “질문을 받으면 답을 내놓는” 기계입니다. 그런데 최근 1~2년 사이, AI 업계의 가장 뜨거운 주제는 “AI가 직접 일을 하게 만드는 법”이 되었습니다. 이걸 가능케 하는 무언가를 에이전트(Agent)라고 부릅니다.

에이전트의 개념은 비유로 풀면 쉽습니다. LLM이 “두뇌”라면, 에이전트는 그 두뇌에 “손과 발”을 붙여준 것입니다. 사용자가 “다음 주 파리행 항공편 중에 가장 싼 거 예약해 줘”라고 하면, 단순히 답만 내놓는 게 아니라 실제로 검색 사이트를 열어보고, 가격을 비교하고, 예약 시스템에 정보를 입력하는 일까지 하게 만드는 것입니다.

기술적으로는 LLM이 “도구(tool)”를 쓸 수 있게 만든 구조가 핵심입니다. 모델이 “지금은 검색이 필요하다”고 판단하면 검색 API를 호출하고, “이메일을 보내야 한다”고 판단하면 메일 발송 함수를 부릅니다. 모델은 매 단계에서 “다음에 무엇을 해야 하는가”를 판단하고, 그 판단대로 행동합니다.

PM 관점에서 에이전트가 흥미로운 지점은, AI 기능의 영역이 “대화”에서 “작업”으로 넓어진다는 것입니다.예전에는 “이메일 초안을 써줘”가한계였다면, 이제는 “이메일을 검토하고, 답장을 쓰고, 회의 일정을 잡아서 캘린더에 넣어줘”까지 가능해졌습니다. 물론 그에 따른 책임의 범위도 훨씬 커집니다. AI가 행동을 하면, 그 행동의 결과에 대해 누가 책임지는가의 문제가 따라옵니다. 에이전트 시대의 PM은 이 책임 설계까지 함께 고민해야 합니다.

이 정도면 충분하다

정리하면 이렇습니다. LLM은 다음 단어를 확률적으로 예측하는 기계이고, 그 일은 토큰 단위로 처리하며, 컨텍스트 윈도우라는 단기 기억만 가지고 있고, 부족한 지식은 RAG로 채운 다음, 행동이 필요한 일은 에이전트로 확장합니다. 이게 PM이 알아야 할 “최소한의 직관”을 주는 LLM 지식입니다.

이 다섯 가지를 알고 있으면, 엔지니어와의 회의가 달라집니다. 이를테면 “이거 LLM으로 가능합니까?”라고 묻는 대신 “이 기능에는 RAG가 필요할 것 같은데, 자료 출처는 어디로 잡을까요?”라고 물을 수 있게 됩니다. “왜 답이 자꾸 잘리죠?”라고 묻는 대신 “컨텍스트 한도에 걸린 것 같은데, 입력을 어떻게 줄일까요?”라고 말할 수도 있게 됩니다. PM이 기술적 디테일을 다 알 필요는 없지만, 적어도 엔지니어와 같은 언어로 대화할 수 있어야 좋은 의사결정이 나옵니다.

그리고 한 가지 더, 이 직관이 있으면 사용자에게 줄 수 있는 경험의 범위가 보입니다. “우리 사용자에게 진짜 가치 있는 AI 기능는 단순 대화일까, 자료를 참고하는 답변일까, 아니면 직접 일을 처리하는 에이전트일까?” 이 질문에 답할 수 있어야 좋은 AI 프로덕트가 나옵니다.

앞서 “AI는 확률 시스템이다”라는 큰 그림을 봤다면, 오늘은 그 확률 시스템이 구체적으로 어떻게 동작하는지를 들여다본 셈입니다. 이 두 가지가 결합할 때, 비로소 우리는 AI 프로덕트를 “감으로 만드는 것”이 아니라 “이해하고 만드는 것”으로 옮겨 갈 수 있습니다.

LLM은 신비로운 마법 상자가 아닙니다. 다음 단어를 잘 예측하는, 거대하지만 제약이 분명한 기계입니다. 그 제약이 어디인지를 아는 순간, AI 기능을 만드는 일이 “어떻게든 되겠지” 영역에서 “이렇게 만들면 된다”의 영역으로 옮겨옵니다. 그리고 그러한 이동은 지식에서 나옵니다. 오늘 우리가 함께 짚어본 다섯 개의 단어 — 토큰, 컨텍스트, 추론, RAG, 에이전트만 이해해도 그 첫걸음을 내딛기에 충분할 것입니다.