에필로그: LLM을 이해한다는 것은 무엇인가

처음의 질문으로 돌아가기

처음 우리는 아주 단순한 질문에서 출발했습니다. "LLM은 왜 갑자기 중요한 기술이 되었을까?"

처음 마주한 LLM은 마치 사람처럼 말하는 챗봇처럼 보였습니다. 질문을 던지면 답하고, 글을 요약하고, 코드를 고치고, 기획안을 만들고, 때로는 제법 그럴듯한 조언까지 내놓았습니다. 그래서 많은 사람은 LLM을 하나의 신기한 대화 상대로 받아들였습니다. 조금 더 나아간 사람은 프롬프트를 잘 쓰는 법에 관심을 가졌습니다. "어떻게 물어봐야 더 좋은 답을 얻을 수 있을까?"라는 질문은 자연스러운 출발점이었습니다.

하지만 이 책이 따라간 길은 거기서 멈추지 않았습니다. 우리는 LLM을 잘 쓰는 법을 배우기 전에, 먼저 LLM이 무엇인지 물었습니다. 그리고 가장 중요한 문장 하나를 여러 번 확인했습니다.

LLM은 다음 토큰을 예측하는 모델입니다.

이 문장은 처음에는 너무 단순하게 들립니다. 이렇게 말 잘하는 모델이 고작 다음 토큰을 맞히는 기계라니, 어딘가 부족한 설명처럼 느껴질 수도 있습니다. 그러나 책을 끝까지 따라온 지금은 이 문장이 얼마나 강력한 출발점인지 알 수 있습니다. 다음 토큰 예측이라는 단순한 목표 위에 토큰화, 임베딩, Attention, Transformer, 사전학습, 지시 튜닝, 선호 최적화, RAG, 도구 호출, 에이전트가 차례로 쌓입니다.

거대한 건물도 기초가 흔들리면 오래 버티지 못합니다. LLM도 마찬가지입니다. 화려한 데모와 빠르게 바뀌는 API 뒤에는 오래 남는 기본 원리가 있습니다. 이 책의 여정은 바로 그 기본기를 손으로 만져 보는 과정이었습니다.

한 토큰에서 하나의 서비스까지

우리는 텍스트가 곧바로 모델에 들어가지 않는다는 사실에서 시작했습니다. 사람이 읽는 문장은 먼저 토큰으로 나뉘고, 토큰은 어휘 사전의 ID가 되며, ID는 다시 임베딩 벡터로 바뀝니다. 모델은 글자를 보는 것이 아니라 숫자 벡터의 흐름을 봅니다. 이때 벡터는 단순한 숫자 묶음이 아니라, 학습을 거치며 토큰의 쓰임새와 관계를 담는 표현이 됩니다.

그다음에는 문맥을 다루는 방법을 배웠습니다. LLM은 무한한 기억을 가진 존재가 아닙니다. 한 번에 볼 수 있는 토큰의 범위, 즉 컨텍스트 윈도우 안에서 판단합니다. 이 제한은 사소한 구현 세부사항이 아니라 서비스 설계에 직접 영향을 주는 조건입니다. 긴 문서를 한 번에 넣을 수 없을 때 어떻게 나눌지, 이전 대화 중 무엇을 유지할지, 검색된 문서 조각을 얼마나 넣을지 같은 문제가 모두 여기서 시작됩니다.

이후 우리는 Transformer의 핵심으로 들어갔습니다. Attention은 문맥 안의 어떤 토큰을 더 중요하게 볼지 정하는 장치였습니다. Self-Attention은 같은 문장 안의 토큰들이 서로를 바라보며 자기 표현을 갱신하는 과정이었습니다. Query, Key, Value는 "무엇을 찾는가", "무엇을 가지고 있는가", "무엇을 전달할 것인가"라는 세 역할로 나뉘었습니다. Multi-Head Attention은 하나의 관점이 아니라 여러 관점으로 문장을 동시에 읽는 방법이었습니다.

여기에 위치 임베딩이 더해지며 순서 정보가 생겼고, Feed Forward Network는 각 토큰 표현을 더 풍부하게 바꾸었습니다. LayerNorm과 Residual Connection은 깊은 모델이 안정적으로 학습되도록 값의 흐름을 정리하고 원래 정보를 보존했습니다. 이렇게 따로따로 보았던 부품들이 하나로 연결되었을 때, 우리는 GPT 구조를 한눈에 볼 수 있게 되었습니다.

그리고 중요한 전환점이 있었습니다. 우리는 설명에서 멈추지 않고 작은 모델을 직접 만들었습니다.

처음에는 문자 단위 Bigram 모델을 만들었습니다. 바로 앞 글자만 보고 다음 글자를 예측하는 아주 단순한 모델이었습니다. 결과는 서툴렀지만, 언어 모델의 기본 형태는 이미 그 안에 있었습니다. 입력이 있고, 정답이 있고, 손실을 계산하고, 손실이 줄어드는 방향으로 파라미터를 조정했습니다.

그다음에는 작은 신경망 언어 모델을 만들었습니다. 임베딩을 붙이고, 여러 글자의 문맥을 입력으로 넣고, 학습 루프를 돌렸습니다. 이어서 Self-Attention을 직접 구현했고, Multi-Head Attention과 Transformer Block을 만들었습니다. 마침내 Mini GPT를 학습시켰습니다.

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

이 차이는 중요합니다. 우리는 상용 모델을 복제하려 한 것이 아닙니다. 거대한 데이터센터와 천문학적인 학습 비용을 흉내 내려 한 것도 아닙니다. 대신 작은 모형을 통해 원리를 몸으로 익혔습니다. 자동차 공장을 직접 세우지 않아도 작은 엔진 모형을 조립해 보면 연료, 피스톤, 회전의 관계를 이해할 수 있습니다. Mini GPT 구현은 바로 그런 경험입니다.

그 뒤에는 다시 현실의 서비스로 돌아왔습니다. LLM API를 호출하고, 프롬프트를 설계하고, 구조화 출력을 받았습니다. Function Calling과 Tool Use를 통해 모델이 외부 도구와 연결되는 방식을 배웠습니다. 임베딩 API와 벡터 검색을 이용해 RAG 구조를 만들고, 문서 기반 Q&A 챗봇을 구현했습니다. 블로그 글 생성기, PDF 요약기, 책 기반 Q&A 챗봇, 고객지원 챗봇, AI 글쓰기 도우미, 간단한 에이전트까지 만들어 보았습니다.

이 여정의 방향은 분명했습니다. 한 토큰을 예측하는 원리에서 출발해, 실제 사용자가 만지는 AI 기능까지 연결하는 것입니다.

미니 GPT를 만들면 API가 다르게 보인다

LLM API를 처음 쓰면 모델은 하나의 검은 상자처럼 느껴집니다. 입력을 보내면 답이 돌아옵니다. 모델 이름을 바꾸면 품질과 비용이 달라집니다. temperature를 조정하면 답변의 다양성이 바뀝니다. 최대 토큰 수를 줄이면 답변이 짧아집니다. 겉으로는 단순한 설정값처럼 보입니다.

하지만 Mini GPT를 직접 만들어 보면 이 설정값들이 다른 의미로 다가옵니다.

temperature는 모델이 다음 토큰 후보를 얼마나 과감하게 고를지 조절하는 장치로 보입니다. top-k나 top-p는 후보 토큰의 선택 범위를 제한하는 방법으로 이해됩니다. max tokens는 단지 요금 제한이 아니라 생성 루프가 몇 번 반복될지를 정하는 값입니다. context window는 모델이 참고할 수 있는 과거 토큰의 최대 범위입니다. stop sequence는 생성 과정을 어디서 멈출지 알려 주는 신호입니다.

작은 모델의 서툰 출력도 상용 모델을 이해하는 데 도움이 됩니다. 우리가 만든 Mini GPT는 이상한 문장을 만들기도 하고, 반복에 빠지기도 하고, 긴 구조를 유지하지 못하기도 했습니다. 그런데 그 실패를 직접 보면 상용 LLM의 실패도 완전히 낯설지 않습니다. 환각, 반복, 문맥 누락, 형식 오류, 애매한 답변은 갑자기 생긴 마법의 오류가 아닙니다. 다음 토큰 예측 모델이 제한된 문맥과 불완전한 근거 위에서 답을 이어 갈 때 나타날 수 있는 자연스러운 실패입니다.

이 경험은 모델을 과신하지 않게 만듭니다. 동시에 불필요하게 두려워하지도 않게 합니다. LLM은 전지전능한 지능도 아니고, 아무렇게나 말하는 장난감도 아닙니다. 특정한 방식으로 학습되고, 특정한 입력을 받아, 특정한 확률 분포에 따라 출력을 생성하는 강력한 도구입니다.

작은 모델을 만들어 본 사람은 상용 API를 사용할 때 더 좋은 질문을 던집니다.

왜 이 답변이 나왔을까? 입력 문맥에 충분한 정보가 있었을까? 모델이 답을 추론한 것일까, 아니면 비슷한 패턴을 이어 쓴 것일까? 출력 형식을 모델에게 말로만 부탁해도 될까, 아니면 구조화 출력으로 강제해야 할까? 외부 데이터를 넣어야 할까? 검색 품질이 나쁜 것은 아닐까? 평가셋을 만들어 확인해야 하지 않을까?

이 질문들이 쌓이면 LLM 사용자는 단순한 호출자가 아니라 설계자가 됩니다.

프롬프트보다 중요한 것은 시스템이다

LLM이 널리 알려지면서 프롬프트 엔지니어링은 가장 먼저 주목받은 기술이 되었습니다. 좋은 프롬프트는 여전히 중요합니다. 모델에게 역할을 알려 주고, 목표를 분명히 하고, 제약 조건을 제시하고, 예시를 제공하면 답변 품질은 크게 달라질 수 있습니다.

하지만 이 책의 후반부에서 확인했듯이, LLM을 잘 쓴다는 것은 프롬프트 문장을 예쁘게 쓰는 것만으로 끝나지 않습니다. 실제 서비스에서는 프롬프트보다 더 넓은 설계가 필요합니다.

좋은 AI 기능은 입력, 검색, 모델 호출, 도구 실행, 출력 검증, 로그, 평가, 보안이 함께 맞물려 동작합니다. 사용자의 질문을 그대로 모델에 던지는 것이 아니라, 필요한 정보를 찾고, 불필요한 정보를 줄이고, 답변 형식을 정하고, 위험한 요청을 걸러내고, 실패했을 때의 대안을 준비해야 합니다.

RAG는 이 관점을 잘 보여 줍니다. RAG 챗봇의 품질은 모델만으로 결정되지 않습니다. 문서를 어떻게 수집했는지, 청크를 어떻게 나누었는지, 임베딩을 어떻게 만들었는지, 벡터 검색이 적절한 결과를 가져오는지, 검색된 근거가 프롬프트에 잘 들어가는지, 모델이 근거 없는 답을 하지 않도록 안내하는지에 따라 결과가 달라집니다.

Function Calling과 Tool Use도 마찬가지입니다. 모델이 도구를 "호출한다"고 말하지만, 실제 실행 책임은 애플리케이션 코드에 있습니다. 모델은 어떤 도구를 어떤 인자로 쓰면 좋을지 제안합니다. 그러나 그 제안이 안전한지 확인하고, 권한을 검사하고, 실행 결과를 다시 모델에 전달하고, 최종 응답을 검증하는 일은 시스템의 몫입니다.

에이전트 역시 이름만 보면 스스로 일하는 비서처럼 보입니다. 그러나 실제로는 목표, 계획, 도구, 메모리, 중단 조건, 검증 로직이 조심스럽게 설계되어야 합니다. 잘 만든 에이전트는 무작정 자율적인 프로그램이 아니라, 제한된 범위 안에서 반복적으로 생각하고 실행하고 확인하는 시스템입니다.

그래서 LLM을 잘 쓴다는 말은 결국 시스템을 잘 설계한다는 뜻에 가깝습니다. 프롬프트는 그 시스템의 중요한 부품이지만 전체는 아닙니다.

한계를 아는 것이 실력이다

기술을 배울 때 우리는 종종 "무엇을 할 수 있는가"에 집중합니다. LLM으로 요약할 수 있다. 번역할 수 있다. 코드를 만들 수 있다. 고객 문의에 답할 수 있다. 문서를 검색해 답할 수 있다. 도구를 호출할 수 있다. 에이전트처럼 여러 단계를 수행할 수 있다.

그러나 실전에서 더 중요한 질문은 "언제 실패하는가"입니다.

LLM은 모르는 것을 모른다고 말하지 못하고 그럴듯하게 이어 쓸 수 있습니다. 문맥이 길어지면 앞부분의 세부사항을 놓칠 수 있습니다. 검색된 문서가 틀리면 틀린 근거를 바탕으로 자신 있게 답할 수 있습니다. 출력 형식을 어길 수 있습니다. 사용자의 악의적인 지시나 문서 안에 숨은 프롬프트 인젝션에 영향을 받을 수 있습니다. 개인정보를 다루는 서비스에서는 입력과 로그만으로도 위험이 생길 수 있습니다.

이런 한계는 LLM의 가치를 깎아내리는 이유가 아닙니다. 오히려 제대로 쓰기 위해 반드시 알아야 하는 조건입니다. 다리는 하중을 이해할 때 안전하게 지을 수 있고, 약은 부작용을 이해할 때 책임 있게 처방할 수 있습니다. LLM도 한계를 이해할 때 비로소 제품 안에 안전하게 들어갈 수 있습니다.

그래서 우리는 비용 최적화와 응답 속도 개선을 다루었고, 품질 평가와 로그 기반 개선을 배웠습니다. 보안과 개인정보를 살펴보았고, 프롬프트 인젝션 대응 방법도 확인했습니다. 마지막에는 좋은 AI 기능을 설계하는 법을 정리했습니다.

좋은 AI 기능은 "AI를 넣었다"는 사실만으로 완성되지 않습니다. 사용자의 문제를 실제로 줄여 주어야 합니다. 사용자가 결과를 이해하고 통제할 수 있어야 합니다. 실패했을 때 피해가 커지지 않아야 합니다. 운영자는 품질을 측정하고 개선할 수 있어야 합니다. 비용과 속도도 제품의 일부로 관리되어야 합니다.

한계를 아는 것은 소극적인 태도가 아닙니다. 오히려 더 멀리 가기 위한 실력입니다.

앞으로 뻗어 나갈 길

이 책을 끝냈다고 해서 LLM 학습이 끝나는 것은 아닙니다. 오히려 이제부터는 여러 방향으로 더 깊게 들어갈 수 있습니다. 중요한 것은 새로운 유행어가 나올 때마다 처음부터 다시 시작하지 않아도 된다는 점입니다. 기본기를 알고 있으면 새로운 기술도 기존 개념 위에 올려 이해할 수 있습니다.

파인튜닝은 그중 하나입니다. 우리는 사전학습, 지도 미세조정, Instruction Tuning, 선호 최적화를 배웠습니다. 앞으로 특정 도메인에 맞게 모델을 조정하고 싶다면, 먼저 정말 파인튜닝이 필요한지 판단해야 합니다. 많은 경우에는 프롬프트 개선, RAG, 도구 연결, 평가셋 정비만으로도 충분합니다. 하지만 특정한 문체, 형식, 도메인 행동을 안정적으로 학습시켜야 한다면 파인튜닝은 강력한 선택지가 됩니다.

멀티모달도 중요한 확장 방향입니다. 텍스트뿐 아니라 이미지, 음성, 영상, 표, 화면을 함께 이해하는 모델이 빠르게 발전하고 있습니다. 그러나 여기서도 기본 구조는 완전히 낯설지 않습니다. 입력이 토큰 또는 벡터 표현으로 바뀌고, 모델은 여러 표현 사이의 관계를 학습하며, 사용자의 요청에 맞는 출력을 생성합니다. 텍스트 LLM의 원리를 이해하면 멀티모달 모델도 더 차분하게 바라볼 수 있습니다.

로컬 LLM은 또 다른 흐름입니다. 모든 서비스를 외부 API에만 의존할 수는 없습니다. 비용, 지연 시간, 개인정보, 오프라인 환경, 커스터마이징 요구 때문에 로컬 또는 자체 호스팅 모델을 검토해야 할 때가 있습니다. 이때도 모델 크기, 컨텍스트 길이, 양자화, 추론 속도, 하드웨어 메모리 같은 요소를 이해해야 합니다. Mini GPT를 만들어 본 경험은 이런 선택지를 평가할 때 좋은 감각을 제공합니다.

LLMOps도 빼놓을 수 없습니다. LLM 애플리케이션은 한 번 배포하고 끝나는 프로그램이 아닙니다. 모델 버전이 바뀌고, 프롬프트가 바뀌고, 문서 인덱스가 바뀌고, 사용자 질문이 바뀝니다. 따라서 평가셋, 로그, 모니터링, 회귀 테스트, 배포 게이트, 비용 추적, 보안 점검이 함께 필요합니다. 일반적인 소프트웨어 운영에 LLM 특유의 불확실성을 더해 관리하는 일이 LLMOps의 핵심입니다.

이 길들은 서로 떨어져 있지 않습니다. 실제 제품에서는 RAG와 파인튜닝을 함께 고민하고, 멀티모달 입력을 받아 도구를 호출하고, 로컬 모델과 API 모델을 라우팅하며, LLMOps로 품질을 관리할 수 있습니다. 중요한 것은 유행의 이름이 아니라 문제를 해결하는 구조입니다.

오래 남는 기본기

AI 기술은 빠르게 변합니다. 모델 이름은 바뀌고, API 형식도 바뀌며, 오늘의 최신 기법이 내일은 기본 기능이 되기도 합니다. 그래서 LLM을 공부하는 사람은 불안해지기 쉽습니다. "지금 배운 것이 금방 낡아 버리면 어떡하지?"라는 걱정이 생깁니다.

물론 세부 도구는 바뀝니다. 하지만 오래 남는 기본기는 있습니다.

첫째, 데이터입니다. 모델은 데이터에서 배웁니다. RAG도 결국 좋은 문서를 잘 정리해 검색하는 문제이고, 파인튜닝도 좋은 예시를 준비하는 문제이며, 평가도 좋은 테스트 데이터를 만드는 문제입니다. 데이터의 품질, 최신성, 범위, 편향을 이해하는 능력은 쉽게 낡지 않습니다.

둘째, 평가입니다. "좋아 보인다"는 느낌만으로는 제품을 운영할 수 없습니다. 어떤 질문에 잘 답하는지, 어떤 질문에 실패하는지, 이전 버전보다 나아졌는지, 비용을 줄였을 때 품질이 얼마나 떨어지는지 측정해야 합니다. 평가할 수 없는 시스템은 개선하기 어렵습니다.

셋째, 보안입니다. LLM은 자연어를 입력으로 받기 때문에 공격 표면이 넓습니다. 사용자의 입력, 검색된 문서, 외부 웹페이지, 도구 실행 결과가 모두 위험한 지시를 포함할 수 있습니다. 개인정보와 권한 문제도 늘 따라옵니다. 보안은 마지막에 덧붙이는 장식이 아니라 처음부터 설계해야 하는 조건입니다.

넷째, 사용자 문제 이해입니다. AI 기능의 목적은 모델의 능력을 자랑하는 것이 아닙니다. 사용자의 시간을 줄이고, 실수를 줄이고, 더 나은 결정을 돕는 것입니다. 어떤 작업이 반복적인지, 어디서 막히는지, 어느 수준의 자동화가 적절한지, 사용자가 무엇을 직접 통제해야 하는지 이해해야 합니다.

다섯째, 시스템 사고입니다. LLM 하나만 바라보면 답이 보이지 않을 때가 많습니다. 입력 전처리, 검색, 프롬프트, 모델 선택, 도구 실행, 출력 검증, UI, 로그, 평가, 운영 정책을 함께 보아야 합니다. 좋은 결과는 하나의 천재적인 프롬프트가 아니라 여러 부품이 안정적으로 맞물릴 때 나옵니다.

이 기본기들은 모델이 바뀌어도 남습니다. 오히려 모델이 강력해질수록 더 중요해집니다. 더 강한 도구일수록 더 좋은 설계가 필요하기 때문입니다.

LLM을 이해한다는 것

이제 마지막 질문에 답해 봅시다. LLM을 이해한다는 것은 무엇일까요?

그것은 모든 수식을 외운다는 뜻이 아닙니다. 모든 논문을 읽었다는 뜻도 아닙니다. 가장 최신 모델의 세부 구조를 전부 알고 있다는 뜻도 아닙니다.

LLM을 이해한다는 것은, 먼저 그것이 다음 토큰 예측에서 출발한다는 사실을 아는 것입니다. 텍스트가 토큰이 되고, 토큰이 벡터가 되며, Transformer가 문맥 안의 관계를 계산하고, 학습을 통해 그럴듯한 언어 패턴을 만들어 낸다는 흐름을 설명할 수 있는 것입니다.

LLM을 이해한다는 것은, 작은 모델을 직접 만들어 보며 원리와 한계를 함께 경험하는 것입니다. 손실이 줄어드는 것을 보고, 이상한 문장이 생성되는 것을 보고, sampling 설정 하나로 출력이 달라지는 것을 보고, 모델이 문맥을 완벽히 이해하지 못하는 장면을 보는 것입니다. 그 경험은 어떤 설명보다 오래 남습니다.

LLM을 이해한다는 것은, 상용 API를 마법 상자가 아니라 설계 가능한 부품으로 다루는 것입니다. 모델에게 무엇을 맡기고, 무엇을 코드로 검증하고, 언제 검색을 붙이고, 언제 도구를 호출하고, 언제 사람의 승인을 받아야 하는지 판단하는 것입니다.

LLM을 이해한다는 것은, 가능성과 위험을 동시에 보는 것입니다. 이 기술이 글쓰기, 검색, 고객지원, 교육, 개발, 분석의 방식을 바꿀 수 있다는 점을 인정하면서도, 환각, 보안, 개인정보, 편향, 비용, 책임 문제를 함께 고려하는 것입니다.

그리고 마지막으로, LLM을 이해한다는 것은 사용자에게 돌아가는 것입니다. 기술의 끝에는 늘 사람이 있습니다. 사용자가 더 빨리 이해하고, 더 쉽게 결정하고, 더 안전하게 일하고, 더 창의적으로 표현할 수 있다면 LLM은 좋은 도구가 됩니다. 반대로 사용자를 혼란스럽게 하거나, 검증할 수 없는 결과를 그럴듯하게 내놓거나, 책임을 흐리게 만든다면 아무리 최신 모델을 썼더라도 좋은 기능이라고 말하기 어렵습니다.

더 이상 마법이 아닌 기술

처음 LLM을 보면 마법처럼 느껴집니다. 빈 입력창에 질문을 넣었을 뿐인데, 문장이 흘러나옵니다. 설명하고, 요약하고, 추론하고, 제안합니다. 때로는 사람보다 빠르고, 때로는 사람보다 더 정돈된 문장을 내놓습니다.

하지만 여기까지 온 지금, 우리는 그 마법의 무대 뒤를 조금은 볼 수 있게 되었습니다. 토큰이 있고, 확률이 있고, 임베딩이 있고, Attention이 있고, Transformer Block이 있고, 학습 데이터가 있고, 평가와 운영이 있습니다. 그리고 그 모든 요소가 실제 서비스 안에서 입력, 검색, 도구, 검증, 보안, 사용자 경험과 연결됩니다.

미니 GPT를 직접 만들어보면, LLM은 더 이상 마법이 아닙니다.

마법이 아니기 때문에 배울 수 있습니다. 마법이 아니기 때문에 고칠 수 있습니다. 마법이 아니기 때문에 실패를 분석할 수 있습니다. 마법이 아니기 때문에 책임 있게 설계할 수 있습니다.

앞으로도 LLM은 계속 변할 것입니다. 모델은 더 커지거나 더 작아질 것이고, 더 빠르거나 더 저렴해질 것이며, 텍스트를 넘어 이미지와 음성, 영상과 도구를 더 자연스럽게 다룰 것입니다. 새로운 이름과 새로운 방법이 계속 등장할 것입니다.

그때마다 모든 것을 처음부터 다시 배울 필요는 없습니다. 이 책에서 익힌 기본 질문으로 돌아오면 됩니다.

이 입력은 어떻게 표현되는가? 모델은 어떤 문맥을 보고 있는가? 필요한 정보는 어디에 있는가? 출력은 어떻게 검증할 것인가? 실패하면 어떻게 안전하게 멈출 것인가? 사용자의 문제를 정말 해결하고 있는가?

이 질문들을 붙잡고 있다면 변화는 두려운 파도가 아니라 탈 수 있는 흐름이 됩니다.

LLM을 이해한다는 것은 결국 태도의 문제이기도 합니다. 신기함에만 머물지 않고 원리를 들여다보는 태도, 원리를 배웠다고 과신하지 않고 한계를 확인하는 태도, 도구의 힘을 제품과 사용자 문제에 연결하는 태도입니다.

이제 여러분은 LLM을 단순히 사용하는 사람에서 한 걸음 더 나아갔습니다. 다음 토큰 예측의 원리를 알고, Transformer의 핵심 구조를 살펴보았고, Mini GPT를 직접 만들었으며, RAG와 도구 호출과 에이전트를 서비스 관점에서 연결해 보았습니다.

이제 남은 일은 각자의 문제로 돌아가는 것입니다.

반복되는 업무를 줄이는 작은 도구를 만들 수도 있습니다. 사내 문서를 검색하는 Q&A 챗봇을 만들 수도 있습니다. 긴 PDF를 요약하는 서비스를 만들 수도 있습니다. 글쓰기를 돕는 편집기를 만들 수도 있습니다. 고객지원 흐름을 개선할 수도 있습니다. 또는 아직 이름 붙지 않은 새로운 AI 기능을 설계할 수도 있습니다.

무엇을 만들든 출발점은 같습니다. LLM을 마법처럼 숭배하지도, 단순한 유행처럼 가볍게 넘기지도 않는 것입니다. 원리를 이해하고, 작게 실험하고, 실패를 측정하고, 사용자의 문제에 맞게 조심스럽게 연결하는 것입니다.

그때 LLM은 비로소 진짜 도구가 됩니다. 그리고 도구를 이해하는 사람은, 변화하는 기술의 한가운데에서도 자신의 방향을 잃지 않습니다.