제0부 개관

0.1 챗박스 뒤에 무엇이 있나

당신이 챗봇에게 "우리 회사 환불 정책 알려줘"라고 친 순간부터 첫 글자가 화면에 뜨기까지, 1초 남짓한 그 시간에 벌어지는 일은 이렇다. 입력이 공격이나 유해 표현인지 검사한다. 문장을 벡터로 바꿔 사내 문서 수만 건에서 관련 조각을 찾아온다. 그 조각과 질문과 시스템 지시를 하나의 프롬프트로 구성한다. 프롬프트를 토큰으로 분할해 GPU에 적재한다. 수백억 개의 가중치를 통과시켜 "다음에 올 토큰"의 확률분포를 구하고, 거기서 하나를 뽑는다. 뽑은 토큰을 입력 끝에 붙여 같은 계산을 수백 번 되풀이한다. 흘러나오는 글자를 실시간으로 필터링해 사용자에게 보낸다.

사용자가 보는 것은 이 중 둘뿐이다. 자기가 친 질문과, 한 글자씩 흘러나오는 답. 이 책은 나머지에 관한 것이다.

"ChatGPT 같은 걸 만들자"는 말은 회의실에서 자주 나오지만, 그 말을 꺼낸 사람과 실제로 만들 사람이 같은 그림을 그리고 있는 경우는 드물다. 앞의 문단이 그 간극을 보여준다. 대화형 AI는 하나의 물건이 아니라 여러 겹의 시스템이고, 그 겹들은 서로 다른 전문성·비용·실패 방식을 가진다. 이 첫 장은 그 겹들의 지도를 그린다. 개별 기술은 뒤에서 심층 분석한다. 여기서는 전체가 어떻게 맞물리는지, 어쩌다 지금 모습이 됐는지, 그리고 "만든다"가 실제로 어떤 갈래의 일인지를 판별한다.

0.1.1 모델 하나가 아니라 파이프라인

대화형 AI를 처음 쓰는 사람의 머릿속 그림은 대개 "거대한 뇌 하나가 있고 내가 글을 넣으면 답을 뱉는다"이다. 이 그림에서 빠진 것은 그 뇌가 답을 출력하기까지, 그리고 그 뇌를 애초에 갖추기까지 필요한 모든 장치다. 실제 시스템은 다음 사슬로 이루어진다.

원재료는 데이터다. 웹·책·코드 수조 토큰을 모아 정제하고 중복을 걷어낸다. 이 데이터로 사전학습을 실행한다 — 수백에서 수천 장의 GPU가 몇 주에서 몇 달 동안 "다음 토큰 맞히기"만 반복하며 언어의 통계를 가중치에 내재화한다. 이렇게 나온 모델(베이스 모델)은 놀랍도록 박식하지만 쓸 수가 없다. 지시를 따르지 않고, 질문에 답하는 대신 질문을 이어 쓴다. 그래서 정렬이 필요하다 — 사람의 시연과 선호로 "답하고, 따르고, 거절하는" 법을 가르친다. 여기서 GPT가 ChatGPT가 된다. 만들어 놓고는 평가해야 한다. 벤치마크는 오염되고 리더보드는 조작되므로 이것은 생각보다 어렵다. 쓸 만하다고 판단되면 서빙한다 — 이 거대한 모델이 수천 명에게 동시에, 저렴하고 빠르게 답하도록 만드는 것은 그 자체로 하나의 공학 분야다(KV 캐시·양자화·배칭). 서빙되는 모델 위에 응용을 구축한다 — 프롬프트로 조종하고, 검색을 결합해 사실을 제시하게 하고(RAG), 도구를 쥐여 행동하게 한다(에이전트). 이 모두를 제품으로 감싼다 — 스트리밍 UX, API 게이트웨이, 안전 가드레일, 비용 관리. 그리고 출시 이후 사용자 로그가 다시 데이터로, 정렬로, 검색으로 흘러 들어가 전체를 개선하는 운영의 순환이 반복된다.

이 사슬을 한 방향 화살표로 그렸다고 해서 한 번 실행되면 끝난다는 뜻은 아니다. 오른쪽 끝의 운영이 로그를 왼쪽으로 환류시키며 같은 사슬을 계속 다시 실행한다. 출시는 완성이 아니라 이 순환의 시동이다.

왜 굳이 이렇게 층으로 갈라 보는가. 각 층이 독립적으로 망가지고, 한 층의 탁월함이 다른 층의 결함을 보완하지 못하기 때문이다. 세계 최고의 모델을 추가해도 서빙이 초당 몇 토큰밖에 못 뽑으면 아무도 기다려주지 않는다. 서빙이 번개처럼 빨라도 검색이 무관한 문서를 물어오면 모델은 자신 있게 틀린 답을 한다. 검색까지 완벽해도 출력 필터가 없으면 누군가 유도한 험한 말이 그대로 나간다. 실제 서비스 장애의 상당수는 "모델이 멍청해서"가 아니라 이 이음매에서 난다. 그래서 시스템을 만드는 사람은 자기가 손대는 층만이 아니라 위아래로 무엇이 오고 가는지를 알아야 한다.

이 층 구조는 이 책의 지도이기도 하다. 왼쪽 절반 — 데이터·사전학습·정렬·평가 — 은 "모델을 만드는" 일이고, 오른쪽 절반 — 서빙·응용·제품 — 은 "모델로 서비스를 만드는" 일이다. 이 경계가 어디를 지나느냐가, 잠시 뒤에 볼 "두 갈래" 독자를 가른다.

한 요청이 이 층들을 실제로 어떻게 관통하는지 보면 추상이 구체가 된다. 전형적인 검색·도구 기반 챗 제품에서 질문 하나의 경로는 대략 이렇다.

사용자는 첫 줄과 마지막 줄만 본다. 가운데 열 단계가 이 책의 대부분을 차지한다.

0.1.2 어떻게 여기까지 왔나

지금의 대화형 AI는 갑자기 나타나지 않았다. "언어를 확률로 다룬다"는 하나의 발상이 수십 년간 몇 번의 도약을 거쳤고, 각 도약은 앞 세대의 구체적인 장벽을 넘는 대신 새로운 장벽을 남겼다. 이 순서를 알면 뒤에 나올 "왜 하필 트랜스포머인가", "왜 RLHF까지 필요했나" 같은 질문이 미리 풀린다.

처음엔 세는 것이었다. 직전 두어 단어를 보고 다음 단어의 빈도를 세어 확률을 매긴다(n-그램). 단순하고 실제로 오래 쓰였지만 두 장벽에 막혔다. 문맥이 몇 단어를 넘으면 못 보고, 단어 조합이 폭발해 대부분의 문구가 학습 데이터에 아예 안 나온다 — 본 적 없는 정상적인 문장에 확률 0을 주기 일쑤였다. 언어의 문제는 "세기"에는 경우의 수가 너무 많다는 것이다.

다음은 기억하는 것이었다. 순환신경망(RNN)과 그 개량형 LSTM은 단어를 하나씩 읽으며 은닉 상태라는 벡터에 지금까지의 문맥을 압축해 이어 나른다. 고정 창을 넘는 문맥도 원리상 담을 수 있게 됐다. 그러나 한 번에 한 단어씩 순서대로 처리해야 하니 긴 글에서 느렸고 — 이 순차성은 GPU 병렬화와 상극이다 — 멀리 떨어진 단어 사이의 관계는 정보가 여러 단계를 거치며 흐려졌다.

전환은 직접 보는 것에서 왔다. 트랜스포머는 은닉 상태를 이어 나르는 대신, 문장 안 모든 토큰이 서로를 한 번에 직접 참조하게 했다(셀프어텐션). 두 토큰이 백 단어 떨어져 있든 옆에 붙어 있든 관계를 포착하는 비용이 같고, 모든 위치를 동시에 계산하니 GPU가 마음껏 병렬로 실행된다. "먼 의존"과 "병렬화"를 한꺼번에 푼 이 구조가 이후 모든 것의 토대가 됐다(1.4).

그 위에서 키우는 것이 통했다. 트랜스포머를 "다음 토큰 맞히기"라는 한 가지 목표로 막대한 데이터·파라미터·연산에 투입하자, 아무도 명시적으로 가르치지 않은 능력 — 번역·요약·코드·간단한 추론 — 이 부수적으로 배어 나왔다. 모델과 데이터를 키우면 성능이 예측 가능하게 좋아진다는 관찰(스케일링 법칙, 2.2)이 이 시대를 이끌었다. 다만 이렇게 얻은 모델은 다음 단어를 그럴듯하게 잇는 데만 능했다. 질문에 답하지도, 위험한 요청을 거절하지도 않았다.

그 간극을 메운 것이 정렬이다. 사람이 쓴 모범 답안으로 지시를 따르게 하고(SFT), 사람이 매긴 선호로 더 나은 답을 강화한다(RLHF). 이 단계에서 박식하지만 제멋대로인 베이스 모델이 말귀를 알아듣는 조수로 바뀐다. 같은 가중치라도 정렬 전과 후는 완전히 다른 물건이다 — 이 단계가 없으면 챗 제품 자체가 성립하지 않는다.

가장 최근의 도약은 시간을 성능과 맞바꾸는 것이다. 잘 정렬된 모델도 여러 단계의 수학·논리에서 자주 미끄러졌다. 그래서 답하기 전에 스스로 긴 풀이를 쓰고 검증하도록 학습시키고, 어려운 문제에는 추론 시점에 연산을 더 쓰게 했다(test-time compute, 3.7). 학습 때 능력을 키우는 축과, 쓸 때 더 생각해서 답을 사는 축이 분리된 셈이다.

이 계보를 관통하는 교훈은 하나다. 각 세대는 앞 세대의 구체적 한계를 정확히 겨냥해 나왔고, 그 자리에 새 한계를 남겼다. 트랜스포머의 셀프어텐션은 먼 의존을 풀었지만 시퀀스 길이의 제곱에 비례하는 연산량을 남겼고(이것이 나중에 KV 캐시와 롱컨텍스트 문제를 낳는다), 스케일링은 능력을 낳았지만 정렬되지 않은 위험을 남겼다. 지금 우리가 씨름하는 문제들 — 환각, 비용, 컨텍스트 길이, 안전 — 은 대부분 이전 도약이 남긴 비용이다. 특정 모델 이름이나 벤치마크 점수는 반년이면 노후화되지만, "무엇이 무엇을 풀었고 그 대가로 무엇을 남겼나"라는 이 인과의 사슬은 노후화되지 않는다.

0.1.3 "만든다"는 두 가지 다른 일이다

"우리도 ChatGPT 같은 걸 만들자"는 문장은 실은 아주 다른 두 작업 중 하나를, 혹은 그 사이 어딘가를 가리킨다. 어느 쪽인지를 처음에 못 박지 않으면 무엇을 배우고 어디에 돈과 사람을 넣을지가 흐려진다.

한쪽은 모델 자체를 만드는 일이다. 데이터를 모아 정제하고, 수백에서 수천 장의 GPU로 사전학습을 수행하고, SFT·RLHF·DPO로 정렬하고, 레드팀으로 두들긴다. 여기서 승부는 데이터의 질과 규모, 학습을 발산 없이 완주시키는 노하우, 그리고 그것을 감당할 자본에서 갈린다. 프런티어 모델을 처음부터 짓는 일은 현실적으로 대기업·전문 연구소·국가급 자원의 영역이다. 그렇다고 이 길이 소수만의 것은 아니다 — 오픈웨이트 모델 위에 도메인 데이터로 계속사전학습을 추가하거나, 작은 특화 모델을 훈련하는 일은 훨씬 낮은 문턱에서 이루어진다. "직접 만든다"에도 스펙트럼이 있다.

다른 한쪽은 이미 만들어진 모델 위에 서비스를 구축하는 일이다. 상용 API든 오픈웨이트든 학습과 정렬이 끝난 모델을 가져다, 프롬프트로 조종하고 검색·도구로 능력을 확장하고 제품·API·안전·비용·운영을 설계한다. 오늘날 LLM으로 무언가를 만드는 사람의 절대다수가 여기에 있다. 이 길에서 승부는 모델 내부의 가중치가 아니라 검색 품질, 프롬프트, 도구 설계, UX, 단위 비용, 안전, 그리고 사용 데이터를 다시 개선으로 환류시키는 순환에서 갈린다. 남과 같은 모델을 쓰면서도 제품의 격차는 얼마든지 벌어진다 — 격차가 나는 층이 모델 바깥에 있기 때문이다.

두 길은 갈라지지만, 갈라지기 전에 공유하는 토대가 있다. 토큰이 무엇이고(1.2), 트랜스포머가 왜 그렇게 동작하며(1.4), 정렬이 무엇을 바꾸고(3.1), 평가가 왜 믿기 어렵고(4.1), 추론이 왜 유독 비용이 큰지(5.1). 서비스만 구축하는 사람도 이 원리를 모르면 컨텍스트 길이·지연·환각·비용을 잘못 읽고 헛발질한다. "왜 이 프롬프트를 넣을 때마다 돈이 더 나가지"라는 질문의 답은 응용 계층이 아니라 서빙 계층의 원리에 있다. 반대로 두 길은 분명히 갈라지기도 한다. 분산학습과 보상모델 훈련은 첫째 길만의 세계이고, RAG 파이프라인과 API 게이트웨이는 둘째 길의 일상이다.

내 견해를 밝히자면, 대부분의 팀에게 처음부터 파운데이션을 짓는 것은 답이 아니다. 남의 모델 위에서 제품을 먼저 검증하고, 도메인·프라이버시·비용·차별화의 이유가 분명해진 다음에야 파인튜닝이나 자체 학습으로 내려가는 편이 자원을 아낀다. 이것은 논쟁의 여지가 있는 판단이고, 반례와 결정 기준은 9.1에서 정면으로 따진다. 이 장에서는 두 길이 다르다는 지형만 세운다.

0.1.4 이 책이 믿지 않는 것들

이 분야에는 사실처럼 굳은 통념이 유난히 많다. 벤더의 마케팅, 트위터의 데모, 절반가량 읽은 논문이 뒤섞여 "다들 그렇게 안다"가 되고, 그 위에서 잘못된 결정이 내려진다. 이 책의 태도는 그런 통념을 원리로 되짚어 깨는 것이다. 몇 개를 미리 꺼내 둔다 — 뒤 장 전체가 이것들을 근거로 반박하는 긴 각주라고 봐도 된다.

LLM이 답을 "찾아온다"는 것. LLM은 문서를 조회하지 않는다. 학습으로 형성된 분포에 근거해 다음 토큰을 생성할 뿐이다. 그래서 존재하지 않는 판례, 틀린 API, 그럴듯한 가짜 인용을 자신 있게 지어낸다(환각). 조회가 필요하면 검색을 따로 결합해야 한다(6.3). 유창함을 지식으로 착각하는 것이 이 분야 최대의 함정이다.

RAG를 결합하면 환각이 사라진다는 것. 검색은 근거를 제공할 뿐 그 근거를 따르라고 강제하지 못한다. 검색이 무관한 문서를 물어오거나, 맞는 문서를 물어와도 모델이 무시하면 환각은 그대로 난다. RAG는 환각을 줄이는 도구지 끄는 스위치가 아니다. 그리고 검색의 품질이 답의 상한을 정한다 — 이것이 6.4 전체를 검색 품질에 쓰는 이유다.

파라미터가 크면 무조건 낫다는 것. 데이터·정렬·용도가 고정일 때만 대략 맞다. 데이터가 부족하면 큰 모델은 낭비고(스케일링 법칙, 2.2), 특정 작업에서는 잘 정렬된 작은 모델이 큰 모델을 이긴다. 게다가 서빙 비용과 지연은 크기를 따라 급격히 오른다. "제일 큰 모델을 쓰자"는 대개 유닛 이코노믹스를 안 따져 본 결정이다(7.5).

프롬프트만 잘 작성하면 다 된다는 것. 프롬프트는 강력하지만 하나의 수단일 뿐이다. 최신·사설 지식은 검색으로, 외부 행동은 도구로, 안정적 형식과 말투는 파인튜닝으로 풀어야 할 때가 있다. 프롬프트 엔지니어링을 범용 해법으로 여기면 검색이나 파인튜닝으로 30분에 풀 문제를 프롬프트로 며칠을 소모한다.

정렬(RLHF)이 안전을 보장한다는 것. 정렬은 안전을 개선하지만 보장하지 않는다. 탈옥과 프롬프트 인젝션은 정렬과는 별개의 공격면이고, 시스템 계층의 방어가 따로 필요하다(7.3·7.4). 모델을 착하게 훈련시켰다는 것과 그 모델을 악용할 수 없다는 것은 다른 이야기다.

이 통념들을 관통하는 실수는 하나다. 대화형 AI의 유창함을, 정확함이나 안전함이나 경제성으로 넘겨짚는 것. 말을 잘한다는 것과 사실을 안다는 것, 위험하지 않다는 것, 저렴하게 동작한다는 것은 각각 별개의 문제이고, 이 책은 그 각각을 다른 장에서 따로 다룬다.

한 가지 실무적인 습관도 여기서 명시해 둔다. 이 책은 특정 모델의 이름·크기·점수·가격을 골격으로 삼지 않는다. 그런 숫자는 몇 달이면 노후화되고, 노후화된 순간 그 문장은 틀린 문장이 되기 때문이다. 대신 "어텐션이 왜 그렇게 생겼나", "KV 캐시가 왜 지연을 지배하나" 같은, 훨씬 천천히 변하는 원리에 무게를 싣는다. 구체적인 벤더 스펙 — 모델 ID, 토큰 단가, 요율 한도 — 이 필요할 때는 본문에 고정 기재하는 대신 공식 문서를 확인하라고 안내한다. 답답해 보여도, 이것이 반년 뒤에도 이 책이 대체로 맞아 있게 하는 유일한 방법이다.

다음 장은 이 지형을 층으로 더 정밀하게 해부하고, "직접 만들 것인가 사서 얹을 것인가"의 첫 판단 기준을 세운다. 거기서부터 제1부로 내려가, 이 모든 것의 근저에 있는 질문 — 언어를 확률로 모델링한다는 것이 대체 무슨 뜻인가 — 에서 다시 시작한다.