1주차 복습: LLM에게 질문이 들어가면

오늘의 질문

한 주 동안 prompt, token, 확률, sampling, 검증을 하나씩 다뤘다. 개념을 따로따로 보면 다 이해한 것 같은데, 막상 이런 질문을 받으면 말문이 막히는 경우가 많다.

내가 질문을 입력하고 답이 화면에 뜨기까지, 그 사이에서 정확히 무슨 일이 순서대로 일어나는가?

이번 글은 새 개념을 추가하지 않는다. 대신 이번 주에 배운 것만으로 이 질문에 처음부터 끝까지 답해본다. 흐름이 한 줄로 이어지지 않는다면 어느 개념이 아직 비어 있는지도 같이 드러날 것이다.

먼저 답하기

전체를 한 문장으로 줄이면 이렇다.

질문은 prompt라는 텍스트 뭉치로 조립되고, token이라는 조각으로 쪼개지고, 모델은 다음 조각 후보들의 확률을 계산하고, 그중 하나를 골라 이어붙이는 일을 종료 조건까지 반복한다. 그리고 사실인지 아닌지를 판정하는 단계는 이 흐름 안에 없다.

마지막 문장이 이번 주 전체의 결론이다. 앞의 네 단계는 전부 확률 계산이다. 어느 단계에서도 “이게 참인가”를 묻지 않는다. 그래서 검증은 흐름의 다섯 번째 단계가 아니라, 흐름이 끝난 뒤에 사람이 바깥에서 붙이는 별도의 절차다.

주제에 맞는 핵심 설명

질문에서 답변까지, 한 번에 이어보기

사람이 쓴 질문이 prompt로 조립되어 token으로 쪼개지고, 모델이 후보별 확률을 만든 뒤 하나를 골라 이어붙이는 과정을 반복해 답변을 만들고, 그 답변을 사람이 출처와 대조해 검증하는 1주차 전체 흐름을 보여주는 다이어그램

이 그림에서 눈여겨볼 부분은 세 가지다.

첫째, 점선 상자의 안과 밖이 다르다. 상자 안(token, 확률, sampling)은 사람이 직접 들여다볼 수 없는 구간이다. 우리가 손댈 수 있는 건 상자 왼쪽(질문을 어떻게 쓸지)과 오른쪽(나온 답을 어떻게 검증할지)뿐이다. “답이 마음에 안 든다”는 문제를 상자 안에서 해결하려 하면 방법이 없고, 대개 왼쪽에서 풀린다.

둘째, 보라색 점선 루프가 답변 길이만큼 돈다. 답변 하나가 통째로 만들어지는 게 아니라, token 하나마다 확률 계산과 선택이 한 번씩 일어난다. 답이 200 token이면 이 루프가 200번 돈다.

셋째, 검증 상자가 흐름 바깥에 붙어 있다. 이건 그림을 그리다 보니 그렇게 된 게 아니라 이번 주 내용의 핵심이다. 가운데 네 칸 어디에도 사실 여부를 재는 단계가 없기 때문에, 검증은 사람이 밖에서 붙여야만 존재한다.

순서대로 다시 짚기

1단계, 질문이 prompt로 조립된다. 사람이 입력한 문장 하나만 들어가는 게 아니다. 미리 정해둔 지침, 지금까지의 대화, 이번 질문이 하나의 텍스트 뭉치로 합쳐져서 들어간다. 이 뭉치가 들어갈 수 있는 공간에는 한계가 있고, 넘치면 오래된 부분부터 밀려난다.

2단계, prompt가 token으로 쪼개진다. tokenizer가 정해진 규칙대로 텍스트를 조각내고, 각 조각을 vocabulary에서 찾아 정수 id로 바꾼다. 이 조각은 사람이 생각하는 단어와 일치하지 않을 수 있다. 그래서 “몇 글자냐”가 아니라 “몇 token이냐”가 실제로 자리를 차지하는 기준이 된다.

3단계, 다음 조각 후보들의 확률이 계산된다. 모델은 먼저 후보마다 점수를 매기고, 그 점수를 softmax를 거쳐 전체 합이 1인 확률로 바꾼다. 이 구조는 트랜스포머를 처음 제시한 Vaswani 외의 논문 “Attention Is All You Need”(2017)에서 확인할 수 있다. 이 논문은 decoder가 이전에 생성한 기호들을 다음 기호 생성의 입력으로 함께 사용하는 구조를 취한다고 설명하고, decoder의 출력을 학습된 선형 변환과 소프트맥스 함수를 거쳐 다음 token에 대한 예측 확률로 변환한다고 기술한다. 즉 “점수를 매기는 일”과 “확률로 바꾸는 일”이 원래부터 분리된 두 단계다.

4단계, 확률 분포에서 token 하나를 고른다. 항상 1등만 고를 수도 있고, 확률에 비례해 무작위로 뽑을 수도 있다. 같은 질문에 매번 같은 답이 나오는지 여부가 여기서 갈린다. 고른 token은 문맥 뒤에 붙고, 늘어난 문맥으로 3단계부터 다시 반복된다. 종료 조건에 닿으면 멈춘다.

5단계, 사람이 검증한다. 답변을 문장 단위로 쪼개서 사실 주장과 해석과 확인 필요로 분류하고, 사실 주장만 실제 출처를 열어 대조한다. 이 단계는 모델이 대신해줄 수 없다. 모델에게 “확실해?“라고 되묻는 것도 결국 3~4단계를 한 번 더 도는 일이기 때문이다.

용어 복습: 각 개념이 무엇을 결정하는가

정의를 다시 나열하는 대신, 각 개념이 흐름의 어느 지점에서 무엇을 결정하고, 잘못 이해하면 어떤 증상이 나타나는지로 정리했다. 개념 사이의 역할 차이를 같은 축에서 비교해야 흐름이 하나로 이어지기 때문이다.

개념 흐름상 위치 무엇을 결정하는가 잘못 이해했을 때 나타나는 증상
prompt 모델에 들어가기 직전 모델이 근거로 삼을 내용의 범위 대화가 길어지면 앞 내용을 “기억”할 거라 기대하다가 어긋남
token 입력 직후, 출력 단위 무엇을 한 조각으로 셀지, 공간을 얼마나 차지할지 글자 수로 분량을 가늠하다가 한도나 비용 예측이 틀어짐
probability 매 조각 생성 시점 어떤 후보가 얼마나 그럴듯한지 확률이 높은 답을 “맞는 답”으로 읽음
sampling 확률 계산 직후 실제로 어떤 조각이 선택될지, 결과가 매번 같을지 같은 질문에 답이 달라지는 걸 모델의 오작동으로 오해함
verification 답변이 나온 뒤 그 답을 실제 업무에 쓸 수 있는지 유창한 답변을 검증 없이 그대로 사용함

이 표에서 마지막 열이 실질적으로 쓸모 있는 부분이다. 다섯 개념 모두 “정의를 외웠는가”보다 **“이걸 몰랐을 때 실제로 어떤 실수를 하는가”**로 기억해두는 편이 낫다.

이번 주를 한 문장으로 묶으면

앞의 네 단계에는 공통점이 하나 있다. 전부 **“다음에 올 조각으로 무엇이 그럴듯한가”**를 계산하는 일이라는 것이다. token으로 쪼개는 것도 이 계산의 단위를 정하기 위해서고, 확률과 sampling은 그 계산 자체이며, prompt는 이 계산의 조건을 제공한다.

그래서 이번 주 내용을 한 줄로 묶으면 이렇게 된다.

LLM은 그럴듯함을 계산하는 기계이고, 사실 여부는 그 계산 바깥에서 붙여야 하는 별도의 일이다.

이 문장이 다음 주 이후의 출발점이 된다. 이 반복 계산이 실제 하드웨어에서 어떤 비용을 만드는지, 그리고 사실 여부를 계산 안으로 끌어들이려면 무엇이 더 필요한지가 이후 다룰 주제다.

자주 묻는 질문

흐름을 이해했는지 스스로 어떻게 확인하나요? 빈 종이에 아무것도 보지 않고 다섯 칸을 그려보고, 각 칸 사이의 화살표에 “여기서 무엇이 무엇으로 바뀌는가”를 적어보면 된다. 예를 들어 prompt와 token 사이에는 “텍스트가 정수 배열로 바뀐다”가 들어가야 한다. 화살표 위에 적을 말이 떠오르지 않는 구간이 있다면, 그 구간이 아직 비어 있는 개념이다. 특히 확률과 sampling 사이를 하나로 뭉뚱그려 적게 되는 경우가 흔한데, 둘은 다른 단계다.

실무에서 답변 품질이 나쁠 때 어디부터 손대야 하나요? 위 그림 기준으로 왼쪽부터다. 대부분의 문제는 prompt 단계에서 모델이 추측해야 할 빈칸이 너무 많아서 생긴다. 대상, 형식, 남길 것과 뺄 것을 명시하는 것만으로 해결되는 경우가 많다. 그 다음으로 볼 것은 필요한 맥락이 실제로 함께 전달되고 있는지다. 답이 매번 달라지는 게 문제라면 그건 품질이 아니라 sampling 방식의 문제이므로, 선택 방식을 조절하는 쪽을 봐야 한다. 이 셋을 다 확인한 뒤에도 남는 문제는 대개 검증 절차로 다뤄야 할 문제지, 질문을 더 다듬어서 해결될 문제가 아니다.

이 흐름은 어떤 모델에나 똑같이 적용되나요? 큰 골격은 공통적이지만 세부는 다르다. tokenizer가 다르면 같은 문장의 token 수가 달라지고, 선택 방식이나 조절 옵션도 서비스마다 이름과 동작이 다르다. 한 번에 참고할 수 있는 분량의 한도도 제각각이다. 그래서 “이 흐름”은 어디서 무엇을 확인해야 하는지 알려주는 지도로 쓰고, 구체적인 수치나 옵션은 실제로 쓰려는 대상의 공식 문서에서 그때그때 확인하는 게 맞다.

모델이 답을 만드는 중간에 사람이 개입할 수는 없나요? 일반적인 사용 환경에서는 어렵다. 위 그림의 점선 상자 안은 한 번 시작되면 종료 조건까지 자동으로 도는 구간이기 때문이다. 다만 실무에서는 이 한계를 우회하는 방식이 흔히 쓰인다. 긴 작업을 한 번에 시키지 않고 여러 단계로 쪼개서, 각 단계의 출력을 사람이 확인한 뒤 다음 단계의 입력으로 넘기는 방식이다. 개입 지점을 상자 안에 만들 수 없다면, 상자를 여러 개로 나눠서 그 사이에 만드는 셈이다.