프롤로그: LLM은 왜 갑자기 중요한 기술이 되었나

어느 날, 텍스트 입력창이 소프트웨어의 얼굴이 되었다

2022년 말, ChatGPT가 처음 공개되었을 때 많은 사람은 그것을 재미있는 실험 정도로 받아들였습니다. 질문을 던지면 답을 하고, 농담을 시키면 농담을 하고, 글을 써 달라고 하면 그럴듯한 문장을 뽑아내는 신기한 챗봇. 처음에는 "와, 이런 것도 되네?"에 가까웠습니다.

그런데 몇 달이 지나자 분위기가 달라졌습니다. 사람들은 ChatGPT를 장난감처럼 쓰는 데서 멈추지 않았습니다. 이메일 초안을 쓰고, 보고서를 요약하고, 영어 문장을 다듬고, 코드를 설명받고, 버그의 원인을 묻고, 회의록을 정리했습니다. 개발자는 낯선 라이브러리의 사용법을 물었고, 기획자는 제품 아이디어를 정리했으며, 학생은 어려운 개념을 쉬운 말로 다시 설명해 달라고 했습니다.

MIT Technology Review는 OpenAI가 2022년 말 ChatGPT를 실험적 프로토타입으로 공개한 뒤, 이 챗봇이 수억 명이 사용하는 일상형 앱으로 확산되었다고 설명합니다.¹ 여기서 중요한 것은 "수억 명"이라는 숫자만이 아닙니다. 더 중요한 변화는 사람들이 처음으로 AI를 검색창이나 추천 알고리즘 뒤에 숨어 있는 기술이 아니라, 직접 대화하고 일을 맡길 수 있는 인터페이스로 경험했다는 점입니다.

예전의 소프트웨어는 대체로 버튼과 메뉴의 세계였습니다. 사용자는 화면 어딘가에 있는 기능을 찾아야 했고, 개발자는 사용자가 무엇을 할지 예상해 수많은 경로를 설계해야 했습니다. 하지만 LLM이 등장한 뒤에는 전혀 다른 방식이 가능해졌습니다. 사용자가 "이 문서를 세 줄로 요약해 줘", "이 오류가 왜 나는지 알려 줘", "고객 문의에 답장 초안을 만들어 줘"라고 자연어로 말하면, 소프트웨어가 그 의도를 해석하고 결과를 만들어냅니다.

이 변화는 단순히 챗봇 하나가 인기를 얻은 사건이 아닙니다. 소프트웨어의 기본 부품이 하나 더 생긴 사건에 가깝습니다. 데이터베이스, 웹 API, 검색 엔진, 결제 모듈, 인증 시스템처럼 이제 많은 제품은 "언어를 이해하고 생성하는 기능"을 기본 구성 요소로 생각하기 시작했습니다.

LLM은 챗봇이 아니라 새로운 소프트웨어 부품이다

LLM은 Large Language Model의 약자입니다. 한국어로는 대규모 언어 모델이라고 부릅니다. 이름은 조금 딱딱하지만, 핵심은 간단합니다. 아주 많은 텍스트를 학습한 뒤, 주어진 문맥 다음에 올 가능성이 높은 토큰을 예측하는 모델입니다.

토큰은 모델이 다루는 글자의 조각입니다. 어떤 토큰은 단어 하나일 수도 있고, 어떤 토큰은 단어의 일부나 문장부호일 수도 있습니다. "안녕하세요"라는 문장을 사람이 보기에는 하나의 인사말로 느끼지만, 모델 내부에서는 여러 토큰으로 나뉘고, 각 토큰은 숫자로 바뀝니다. LLM은 이 숫자들의 흐름을 보고 "다음에는 무엇이 올 가능성이 높은가?"를 계속 계산합니다.

ChatGPT, Claude, Gemini, Llama 같은 모델은 제품의 모습도 다르고, 제공 회사도 다르고, 성능과 사용 방식도 다릅니다. 어떤 모델은 웹 서비스로 제공되고, 어떤 모델은 API로 호출할 수 있으며, 어떤 모델은 공개 가중치를 내려받아 로컬 컴퓨터나 서버에서 실행할 수 있습니다. 하지만 큰 줄기에서 보면 이들은 모두 대규모 텍스트에서 패턴을 학습하고, 주어진 문맥에 이어질 가능성이 높은 토큰을 생성하는 언어 모델이라는 공통된 뿌리를 갖습니다.

물론 "다음 토큰 예측"이라는 말만 들으면 조금 실망스러울 수도 있습니다. "그게 전부라고? 그런데 어떻게 코드를 짜고, 시를 쓰고, 수학 문제를 풀고, 상담도 하는 것처럼 보이지?"라는 질문이 자연스럽게 따라옵니다. 이 책의 첫 번째 목적이 바로 그 질문에 답하는 것입니다.

LLM은 단순한 자동완성처럼 보이지만, 엄청난 양의 데이터와 거대한 신경망, 그리고 Transformer라는 구조가 결합되면 놀라운 일이 벌어집니다. 문장 속 단어들의 관계를 파악하고, 앞뒤 문맥을 반영하며, 질문의 의도에 맞는 답변을 만들어내는 능력이 나타납니다. 우리는 이것을 "이해"라고 부르고 싶어지지만, 실제 내부에서는 숫자 벡터와 확률 계산이 빠르게 움직이고 있습니다.

이 책은 그 움직임을 하나씩 꺼내 볼 것입니다. 처음에는 언어 모델이 무엇인지, 다음 토큰을 예측한다는 것이 어떤 의미인지 살펴봅니다. 이어서 텍스트가 어떻게 숫자로 바뀌는지, 토큰화와 임베딩이 왜 필요한지, Attention과 Transformer가 어떤 역할을 하는지 이해합니다. 그리고 결정적으로, 작은 GPT를 직접 만들어봅니다.

이 책에서 만드는 것은 ChatGPT가 아니라, ChatGPT의 핵심 원리를 이해하기 위한 작은 GPT입니다.

이 문장을 꼭 기억해 주세요. 우리는 수천억 개의 파라미터를 가진 상용 모델을 만들려는 것이 아닙니다. 개인 노트북에서 세계 최고 수준의 AI를 훈련시키겠다는 이야기도 아닙니다. 대신 작은 데이터와 작은 모델을 사용해 "아, LLM이 이렇게 돌아가는구나"를 손으로 느껴보려는 것입니다. 직접 만들어본 사람에게 LLM은 더 이상 마법이 아닙니다.

왜 하필 지금 LLM인가

사실 언어를 다루는 AI는 오래전부터 있었습니다. 자동 번역, 검색어 자동완성, 스팸 필터, 음성 인식, 챗봇은 이미 우리 주변에 있었습니다. 그런데 왜 2022년 말 이후 LLM은 갑자기 모든 산업의 중심 주제가 되었을까요?

첫 번째 이유는 품질의 도약입니다. 예전 챗봇은 정해진 시나리오 안에서는 그럭저럭 작동했지만, 조금만 범위를 벗어나면 금세 어색해졌습니다. "상담원 연결해 주세요"라는 말을 반복하게 만들거나, 사용자의 질문을 이해하지 못해 엉뚱한 답을 내놓았습니다. 반면 ChatGPT 이후의 LLM은 훨씬 넓은 범위의 질문에 자연스럽게 답했습니다. 완벽하지는 않았지만, 사람이 일상적으로 사용하는 언어의 폭을 꽤 넓게 받아냈습니다.

두 번째 이유는 인터페이스의 단순함입니다. 사람들은 새로운 도구를 배우는 데 많은 시간을 쓰고 싶어 하지 않습니다. LLM 서비스의 입력창은 누구에게나 익숙합니다. 그냥 말하면 됩니다. "이 문장을 더 공손하게 바꿔 줘." "이 코드의 문제를 찾아 줘." "이 계약서에서 위험한 조항을 알려 줘." 자연어 자체가 인터페이스가 되자, AI 사용의 진입 장벽이 크게 낮아졌습니다.

세 번째 이유는 개발 생태계의 성장입니다. LLM이 중요한 기술이 된 것은 모델 하나가 똑똑해졌기 때문만은 아닙니다. API, 오픈소스 모델, 로컬 실행 도구, 임베딩 모델, 벡터 데이터베이스, 프레임워크, 평가 도구가 함께 발전했습니다. 이제 개발자는 거대한 모델을 직접 학습시키지 않아도, API를 호출해 제품에 요약 기능을 넣고, 회사 문서를 검색해 답변하는 챗봇을 만들고, 외부 도구를 호출하는 에이전트를 구성할 수 있습니다.

네 번째 이유는 LLM이 기존 소프트웨어의 빈틈을 잘 메우기 때문입니다. 전통적인 소프트웨어는 규칙이 명확한 일을 잘합니다. 결제 금액을 계산하고, 데이터베이스에서 조건에 맞는 행을 찾고, 정해진 양식으로 화면을 그리는 일에 강합니다. 하지만 사람이 매번 조금씩 다르게 쓰는 문장, 모호한 요청, 긴 문서의 핵심 파악, 비정형 고객 문의 같은 일은 다루기 어려웠습니다. LLM은 바로 그 비정형 언어 영역을 소프트웨어 안으로 끌어들였습니다.

이 변화는 개발 현장에서도 뚜렷합니다. GitHub에 공개된 ChatGPT 대화 링크를 분석한 연구는 개발자들이 코드 생성, 코드 수정과 최적화, 유지보수, 구현 작업 등 다양한 소프트웨어 개발 활동에 ChatGPT를 활용하고 있음을 보여줍니다.² 또 세계은행 데이터랩은 ChatGPT 접근 가능성이 GitHub 활동, 특히 Git push 수 증가와 관련이 있다는 분석을 소개했습니다.³ 개별 연구의 방법과 해석에는 신중함이 필요하지만, 한 가지는 분명합니다. LLM은 이미 개발자의 일상에 들어왔습니다.

검색 보조에서 제품 기능까지

LLM이 가장 먼저 바꾼 경험은 검색이었습니다. 이전에는 궁금한 것이 있으면 검색어를 입력하고, 결과 목록을 훑고, 여러 페이지를 열고, 필요한 정보를 모아야 했습니다. 이제는 질문을 문장으로 던지고, 요약된 답을 먼저 받은 뒤, 필요한 경우 출처나 세부 정보를 확인하는 방식이 익숙해지고 있습니다.

하지만 LLM의 쓰임은 검색 보조에만 머물지 않습니다. 글쓰기 도구는 사용자의 초안을 더 명확하게 다듬고, 코딩 도구는 함수 작성과 테스트 생성을 돕고, 고객지원 시스템은 반복 문의를 분류하고 답변 초안을 만듭니다. 회의 앱은 녹취를 요약하고, 협업 도구는 긴 스레드의 결론을 정리하며, 교육 서비스는 학생의 수준에 맞춰 설명 방식을 바꿉니다.

이때 LLM은 "완성된 답을 내놓는 신탁"이라기보다 "언어 작업을 처리하는 엔진"에 가깝습니다. 입력을 받아 요약하고, 분류하고, 변환하고, 생성하고, 질문에 답합니다. 개발자는 이 엔진을 기존 시스템과 연결합니다. 사용자 정보는 데이터베이스에서 가져오고, 최신 문서는 검색 시스템에서 찾고, 결제나 예약 같은 실제 동작은 외부 API로 수행합니다.

그래서 현대적인 LLM 애플리케이션을 이해하려면 프롬프트만 알아서는 부족합니다. 프롬프트는 중요하지만 전체 그림의 일부입니다. 실제 제품에서는 구조화 출력, Function Calling, Tool Use, RAG 같은 개념이 함께 등장합니다.

구조화 출력은 모델의 답을 사람이 읽기 좋은 문장뿐 아니라 프로그램이 처리하기 쉬운 형태로 받는 방법입니다. 예를 들어 고객 문의를 "환불", "배송", "계정", "기타" 같은 분류값으로 돌려받거나, 회의록에서 할 일 목록을 JSON 형식으로 추출할 수 있습니다.

Function Calling은 모델이 직접 모든 일을 하는 대신, 필요한 함수를 선택하고 인자를 채워 외부 시스템과 연결되도록 하는 방식입니다. 사용자가 "내일 오후 3시에 회의 잡아 줘"라고 말하면 모델은 캘린더 API를 호출하기 위한 함수 이름과 날짜, 시간, 참석자 정보를 구성할 수 있습니다.

RAG는 Retrieval-Augmented Generation의 약자로, 검색으로 찾은 외부 문서를 LLM의 답변에 함께 넣어주는 방식입니다. 모델이 모든 지식을 머릿속에 외우고 있다고 기대하는 대신, 필요한 정보를 문서 저장소에서 찾아와 답변하게 만드는 구조입니다. 회사 내부 문서 Q&A, 법률 문서 검색, 기술 문서 챗봇처럼 도메인 지식이 중요한 서비스에서 자주 사용됩니다.

이 책의 뒤쪽에서는 이 개념들을 실제 애플리케이션으로 연결합니다. LLM API 기반 요약기를 만들고, 문서 기반 Q&A RAG 챗봇을 만들고, Function Calling 기반 도구 사용 챗봇과 간단한 에이전트까지 구현해 볼 것입니다.

가장 큰 모델이 항상 정답은 아니다

LLM을 처음 접하면 자연스럽게 "어떤 모델이 제일 좋아요?"라고 묻게 됩니다. 이 질문은 중요하지만, 조금 바꿔야 합니다. "내가 하려는 작업에 어떤 모델이 적합한가요?"가 더 좋은 질문입니다.

최신 대형 모델은 대체로 강력합니다. 어려운 추론, 복잡한 코딩, 긴 문서 이해, 다양한 형식의 입력 처리에서 뛰어난 성능을 보일 수 있습니다. 하지만 모든 작업에 가장 큰 모델이 필요한 것은 아닙니다. 짧은 문장 분류, 단순 요약, 정해진 양식의 정보 추출, 내부 도구용 초안 생성에는 더 작고 저렴한 모델로도 충분한 경우가 많습니다.

LLM을 선택할 때는 적어도 다음 요소를 함께 봐야 합니다.

• 작업 목적: 요약, 분류, 검색 보조, 코드 생성, 상담, 에이전트 실행 중 무엇을 하려는가

• 품질 요구사항: 틀려도 되는 초안인지, 사람이 검토해야 하는 전문 답변인지, 자동 처리해도 되는 결과인지

• 비용과 속도: 한 달 요청 수, 토큰 사용량, 응답 지연 시간이 제품 경험에 어떤 영향을 주는가

• 개인정보와 보안: 사용자의 민감한 데이터나 회사 내부 문서를 외부 API로 보내도 되는가

• 도메인 지식: 모델 자체 지식으로 충분한가, 별도 문서 검색이나 파인튜닝이 필요한가

• 운영 방식: 클라우드 API를 쓸 것인가, 오픈소스 모델을 직접 호스팅할 것인가, 로컬 실행이 필요한가

LLM 실무 가이드를 다룬 ACM Computing Surveys 논문도 작업에 LLM을 선택할지 말지, 어떤 LLM이 적합한지 판단할 때 모델 크기, 계산 요구사항, 도메인 특화 사전학습 모델의 존재 등을 고려해야 한다고 설명합니다.⁴

예를 들어 개인 블로그 글의 제목 후보를 20개 뽑는 기능이라면 최고 성능 모델이 꼭 필요하지 않을 수 있습니다. 반대로 의료 기록을 바탕으로 의사 결정을 보조하거나, 금융 계약서에서 위험 조항을 찾거나, 대규모 코드베이스를 수정하는 작업이라면 품질, 검증, 보안, 감사 로그까지 훨씬 신중하게 설계해야 합니다.

또 로컬 LLM이라는 선택지도 있습니다. 로컬 LLM은 사용자의 컴퓨터나 회사 서버에서 직접 실행하는 모델입니다. 성능은 최신 상용 모델보다 낮을 수 있지만, 민감한 데이터가 외부로 나가지 않는다는 장점이 있습니다. 인터넷 연결 없이 동작할 수도 있고, 사용량 제한이나 API 가격 정책 변화의 영향을 덜 받을 수도 있습니다. 반면 설치와 운영, 하드웨어 비용, 모델 업데이트, 성능 튜닝은 사용자의 몫입니다.

결국 좋은 LLM 선택은 "가장 똑똑한 모델 고르기"가 아니라 "제품의 제약 안에서 충분히 좋은 결과를 안정적으로 내는 조합 찾기"입니다. 때로는 큰 모델 하나보다 작은 모델, 검색 시스템, 규칙 기반 검증, 사람 검토 단계를 조합한 설계가 더 좋은 답입니다.

유창함은 정확함이 아니다

LLM을 사용할 때 가장 먼저 경계해야 할 것은 유창함입니다. 이상하게 들릴 수 있습니다. 유창함은 LLM의 강점 아닌가요? 맞습니다. LLM은 매우 유창하게 답합니다. 문제는 그 유창함 때문에 틀린 말도 그럴듯하게 보인다는 것입니다.

사람은 보통 머뭇거리는 답보다 자신감 있는 답을 더 믿습니다. LLM은 틀릴 때도 자신감 있게 틀릴 수 있습니다. 존재하지 않는 논문을 지어내거나, 오래된 정보를 최신 정보처럼 말하거나, 코드에서 미묘한 오류를 놓치거나, 질문의 전제를 잘못 받아들인 채 멋진 문장을 이어갈 수 있습니다. 이런 현상을 흔히 환각, 즉 hallucination이라고 부릅니다.

환각은 단순한 버그라기보다 LLM의 작동 방식과 관련이 깊습니다. LLM은 기본적으로 다음 토큰을 생성하도록 학습된 모델입니다. 답변이 사실인지, 외부 세계에서 검증되었는지, 특정 회사의 최신 정책과 일치하는지까지 자동으로 보장하지는 않습니다. 물론 최신 모델은 점점 더 나아지고 있고, 검색이나 도구 사용과 결합하면 정확도를 높일 수 있습니다. 하지만 "LLM이 말했다"는 사실은 "검증되었다"는 뜻이 아닙니다.

특히 기술, 법률, 의료, 금융처럼 오류의 비용이 큰 영역에서는 더 조심해야 합니다. 한 연구는 현재 LLM이 도메인에 대한 깊은 모델을 갖고 있지 않기 때문에 추론이나 계획에서 한계를 보일 수 있으며, 고도로 기술적인 분야에서 환각은 위험할 수 있다고 지적합니다.⁵ 이 말은 LLM을 쓰지 말라는 뜻이 아닙니다. 제대로 된 안전장치 없이 LLM의 답을 최종 판단으로 사용하지 말라는 뜻에 가깝습니다.

그래서 좋은 LLM 서비스에는 보완 설계가 필요합니다. 필요한 정보는 검색으로 가져오고, 중요한 동작은 도구 호출로 실제 시스템에서 확인하며, 모델의 출력을 구조화해 검증하고, 위험한 결과는 사람에게 넘겨야 합니다. 또한 로그를 남기고, 평가 데이터를 만들고, 실패 사례를 분석해야 합니다. LLM 제품 개발은 "프롬프트를 멋지게 쓰는 일"에서 끝나지 않습니다. 오히려 그 뒤의 검증과 운영이 제품의 품질을 결정합니다.

이 책이 다루는 세 가지 층위

이 책은 LLM을 세 가지 층위에서 다룹니다. 원리, 구현, 활용입니다.

먼저 원리입니다. LLM이 무엇인지, 언어 모델이 왜 다음 토큰을 예측하는지, 텍스트가 어떻게 숫자로 바뀌는지, 토큰화와 임베딩이 어떤 역할을 하는지 배웁니다. 이어서 Attention, Self-Attention, Query·Key·Value, Multi-Head Attention, 위치 임베딩, Feed Forward Network, LayerNorm과 Residual Connection을 차례로 살펴봅니다. 용어는 낯설 수 있지만, 하나씩 풀어보면 결국 "문맥 안에서 중요한 정보를 어떻게 보고, 섞고, 다음 출력을 만드는가"라는 이야기로 이어집니다.

다음은 구현입니다. 여기서 이 책의 가장 중요한 실습이 등장합니다. 우리는 문자 단위 Bigram 언어 모델부터 시작합니다. Bigram은 바로 앞 글자를 보고 다음 글자를 예측하는 아주 단순한 모델입니다. 처음에는 투박하고 어색한 결과가 나오겠지만, 이 작은 모델은 언어 모델의 출발점을 보여줍니다. 그다음 작은 신경망 언어 모델을 만들고, Self-Attention을 직접 구현하고, Multi-Head Attention과 Transformer Block을 쌓아 Mini GPT를 학습시킵니다.

이 과정에서 독자는 LLM을 "API로 부르면 답이 나오는 검은 상자"로만 보지 않게 됩니다. 물론 우리가 만드는 Mini GPT는 작습니다. 데이터도 작고, 모델도 작고, 생성 결과도 상용 모델과 비교할 수 없습니다. 하지만 작은 모델이 글자를 하나씩 예측하고, 학습을 통해 조금씩 나아지고, 문맥을 반영해 다음 토큰을 고르는 장면을 보면 큰 모델의 원리도 훨씬 선명해집니다.

마지막은 활용입니다. 실제 제품에서는 모델을 직접 학습시키는 일보다 이미 존재하는 LLM을 잘 연결하는 일이 더 자주 필요합니다. LLM API를 호출하고, 프롬프트를 설계하고, 구조화 출력을 받고, Function Calling과 Tool Use로 외부 기능을 연결하고, 임베딩 API와 벡터 데이터베이스를 활용해 RAG를 구성합니다. 이어서 블로그 글 생성기, PDF 요약기, 책 기반 Q&A 챗봇, 고객지원 챗봇, AI 글쓰기 도우미, 간단한 에이전트를 만들어봅니다.

책의 후반부에서는 운영과 제품화도 다룹니다. 비용 최적화, 응답 속도 개선, 품질 평가, 로그 기반 개선, 보안과 개인정보, 프롬프트 인젝션 대응, 좋은 AI 기능 설계가 그것입니다. AI 기능은 데모에서 끝나면 안 됩니다. 사용자가 반복해서 믿고 쓸 수 있어야 제품입니다.

프롬프트 사용자에서 AI 기능 설계자로

이 책을 읽기 전의 독자는 아마 이런 상태일 수 있습니다. ChatGPT를 자주 쓰고, 프롬프트를 조금 바꾸면 답이 달라진다는 것을 알고, RAG나 파인튜닝 같은 말을 어디선가 들어봤지만 정확한 차이는 헷갈립니다. LLM은 똑똑한 챗봇처럼 보이고, 잘 쓰려면 질문을 잘해야 한다고 생각합니다.

이 책을 끝까지 읽고 나면 목표 지점은 달라집니다. LLM이 다음 토큰 예측 모델이라는 것을 설명할 수 있어야 합니다. 토큰화, 임베딩, Attention, Transformer가 어떻게 이어지는지 말할 수 있어야 합니다. Mini GPT를 직접 만들어본 경험을 바탕으로, 큰 모델이 왜 더 강력한지와 작은 모델이 왜 한계를 갖는지도 이해해야 합니다. 그리고 LLM API, RAG, Tool Use를 이용해 실제 서비스 기능을 설계할 수 있어야 합니다.

여기서 "설계할 수 있다"는 말이 중요합니다. 앞으로의 개발자는 LLM을 단순히 사용하는 사람에 머물기 어렵습니다. 제품 안에 AI 기능을 넣을 때, 무엇을 모델에게 맡기고 무엇을 코드로 처리할지 결정해야 합니다. 어떤 데이터는 검색으로 보강하고, 어떤 출력은 JSON으로 강제하고, 어떤 작업은 사람의 승인을 거쳐야 하는지 판단해야 합니다. 비용이 너무 많이 나오면 모델과 프롬프트와 캐시 전략을 바꿔야 하고, 답변 품질이 흔들리면 평가 데이터를 만들어 개선해야 합니다.

LLM은 개발자를 대체하는 단일한 존재라기보다, 개발자가 다룰 수 있는 강력한 재료에 가깝습니다. 데이터베이스를 이해하는 개발자가 더 좋은 제품을 만들 수 있었듯, 웹을 이해하는 개발자가 더 넓은 서비스를 만들 수 있었듯, LLM을 이해하는 개발자는 언어와 지식을 다루는 새로운 종류의 기능을 설계할 수 있습니다.

마법을 분해하는 즐거움

처음 LLM을 만나면 마법처럼 느껴집니다. 질문을 입력했을 뿐인데 답이 나오고, 빈 화면에 글이 채워지고, 오류 메시지 하나로 해결책이 제안됩니다. 그러나 기술을 배우는 즐거움은 마법을 부정하는 데 있지 않습니다. 마법처럼 보이던 것을 한 겹씩 열어보고, 그 안에서 작동하는 원리를 발견하는 데 있습니다.

이 책은 LLM을 과장하지 않을 것입니다. LLM이 모든 문제를 해결한다고 말하지도 않을 것입니다. LLM은 유창하지만 틀릴 수 있고, 강력하지만 비용이 들며, 놀랍지만 검증이 필요합니다. 동시에 이 책은 LLM을 과소평가하지도 않을 것입니다. LLM은 이미 검색, 글쓰기, 코딩, 고객지원, 문서 요약, 자동화, 제품 인터페이스를 바꾸고 있습니다. 앞으로 더 많은 소프트웨어는 언어를 입력으로 받고, 언어를 출력으로 내보내며, 그 사이에서 외부 도구와 데이터를 연결하게 될 것입니다.

우리는 이제 그 변화를 구경하는 위치에서 한 걸음 더 들어가려 합니다. 다음 장부터는 가장 기본적인 질문에서 시작합니다.

언어 모델이란 무엇인가.

이 질문에 답하는 순간, ChatGPT의 화려한 화면 뒤에서 움직이는 작고 단단한 원리가 보이기 시작할 것입니다. 그리고 언젠가 직접 만든 작은 GPT가 어설픈 문장을 한 글자씩 생성하는 장면을 보게 되면, 아마 이런 생각이 들지도 모릅니다.

"아, 이게 시작이었구나."

참고

¹LLMs+: 10 Things That Matter in AI Right Now

²Unveiling the Role of ChatGPT in Software Development: Insights from Developer-ChatGPT Interactions on GitHub

³Impact of the Availability of ChatGPT on Software Development Activity

⁴Harnessing the Power of LLMs in Practice: A Survey on ChatGPT and Beyond

⁵Quo Vadis ChatGPT? From large language models to Large Knowledge Models