대규모 언어 모델

글을 다루는 기능은 오랫동안 작업 하나에 모델 하나가 필요했습니다. 고객 문의를 종류별로 나누려면 사람이 직접 분류해 둔 문의 수천 건을 모아 분류기를 학습시키고, 같은 문의를 세 줄로 줄이는 기능이 필요해지면 그 일에 맞는 자료를 처음부터 다시 모아야 했습니다. 두 기능은 같은 문장을 다루지만 아무것도 공유하지 않았습니다.

페이지덱에서도 같은 벽에 부딪혔습니다. 지현이 문의를 종류별로 나눠 보자고 제안했을 때 돌아온 답은 자료부터 모아야 한다는 말이었고, 몇 달치 일정이 필요하다는 뜻이었습니다. 기능 하나를 시험해 보는 데 드는 비용이 너무 커서, 될지 안 될지 모르는 아이디어는 시도조차 되지 않았습니다.

대규모 언어 모델은 이 순서를 뒤집었습니다. 특정 작업이 아니라 아주 많은 글 자체를 미리 학습해 두고, 무엇을 할지는 나중에 지시문으로 받습니다. 분류하라고 쓰면 분류하고, 줄이라고 쓰면 줄입니다. 자료를 모아 학습시키는 몇 달이 문장 몇 줄을 쓰는 몇 분으로 바뀌었고, 아이디어를 버리는 비용도 그만큼 내려갔습니다.

이 도구가 실제로 바꾸는 것은 셋입니다.

1. 시작 비용. 학습 자료 없이 지시문만으로 첫 결과를 봅니다. 문의 열 건을 넣고 종류를 나눠 보라고 쓰면 그 자리에서 결과가 나옵니다. 프롬프트 엔지니어링은 이 지시문을 다듬어 원하는 답을 받아 내는 일이고, 같은 모델에서도 지시문에 따라 결과가 크게 갈립니다.
2. 정해진 모양이 없는 글. 표에 담긴 숫자가 아니라 사람이 자유롭게 쓴 문장을 다룹니다. 회의록에서 결정된 것만 뽑기, 문의를 감정별로 나누기, 긴 문서를 요약하기처럼 규칙으로 적기 어려운 일이 여기 들어갑니다.
3. 입력 형식. 쓰는 사람이 화면의 버튼을 익히지 않고 하고 싶은 말을 그대로 적어도 됩니다.

대신 세 가지 한계가 붙어 다닙니다. 하나는 크기입니다. 모델은 글을 토큰이라는 단위로 쪼개 다루고, 한 번에 볼 수 있는 토큰의 최대 개수를 컨텍스트 윈도라고 합니다. 이 창을 넘는 문서는 통째로 넣을 수 없어 잘라 넣어야 하고, 잘린 부분은 모델에게 없는 것이 됩니다.

다른 하나는 정확성입니다. 사실을 찾아 답하는 것이 아니라 그럴듯한 다음 말을 고르는 방식이라, 없는 내용을 자신 있게 지어내는 환각이 구조적으로 따라옵니다. 회사 내부 자료를 모른다는 점도 같은 자리에서 걸립니다. 그래서 질문이 들어오면 관련 문서를 먼저 찾아 지시문에 붙여 주는 RAG 방식을 얹는 경우가 많습니다.

마지막은 값과 속도입니다. 요금이 토큰 수로 매겨지므로 긴 문서를 넣을수록 비싸지고, 답이 돌아오기까지 몇 초가 걸립니다. 화면을 누른 즉시 결과가 나와야 하는 기능에는 그대로 붙이기 어렵습니다.

같은 문제를 다른 방법으로 푸는 길이 있고, 판단 기준은 대개 작업이 얼마나 정해져 있느냐입니다.

1. 규칙으로 적기. 정해진 낱말이 들어 있는지 보고 나누는 방식입니다. 환불이라는 말이 들어간 문의를 환불 담당에게 보내는 정도라면 이쪽이 더 낫습니다. 값이 거의 들지 않고, 같은 입력에 늘 같은 결과가 나오며, 왜 그렇게 나뉘었는지 설명할 수 있습니다.
2. 전통적인 머신러닝 분류기. 사람이 분류해 둔 자료가 이미 쌓여 있다면 그 자료로 학습시킨 작은 모델이 더 빠르고 싸고 결과가 고릅니다. 문의 분류처럼 종류가 고정된 일에서 특히 그렇습니다.
3. 작은 특화 모델. 큰 모델로 먼저 만들어 보고 쓸 만하다는 것이 확인되면, 그 결과를 자료 삼아 작은 모델을 학습시켜 비용과 지연을 줄이는 순서를 밟기도 합니다.
4. 사람이 하기. 하루에 열 건 들어오는 일이라면 자동화가 아니라 사람이 처리하는 편이 빠릅니다. 자동화의 값은 건수가 받쳐 줄 때만 회수됩니다.

큰 모델의 자리는 이 넷이 감당하지 못하는 구간입니다. 종류가 미리 정해져 있지 않거나, 자료가 아직 없거나, 한 기능 안에서 여러 일을 섞어 해야 할 때입니다.

"이 기능 규칙으로 될 것 같은데 굳이 모델을 써야 할까요?"

값과 예측 가능성을 근거로 더 단순한 방법을 먼저 보자는 제안입니다.

"문서가 길어서 컨텍스트 윈도를 넘어요. 잘라서 넣어야 합니다."

한 번에 다 넣을 수 없으니 나눠 넣는 설계가 필요하다는 뜻입니다.

"모델을 바꿨는데 좋아졌는지 어떻게 확인하죠?"

느낌이 아니라 같은 기준으로 비교할 방법을 묻는 질문입니다.

페이지덱에서 문의 요약 기능을 만들 때도 순서가 그랬습니다. 지현이 지시문 몇 줄로 스무 건을 돌려 보고 쓸 만하다는 감을 잡은 뒤, 태오가 사내 문서를 함께 넣는 방식으로 바꾸고, 형식을 벗어난 답을 걸러 내는 가드레일을 붙였습니다.

그다음에 한 일이 평가셋을 만드는 것이었습니다. 문의와 기대하는 요약을 짝지어 60건을 모아 두고, 지시문이나 모델을 바꿀 때마다 같은 묶음을 다시 돌려 점수를 비교합니다. 이것이 없으면 좋아졌다는 말이 사례 두세 건에 기대게 됩니다.

모델이 어딘가에서 답을 찾아온다고 생각하는 경우가 가장 많습니다. 질문하면 답이 나오는 모양이 검색과 닮아서 그렇게 읽기 쉽습니다. 하지만 모델이 하는 일은 이어질 말을 고르는 것이고, 근거 문서를 따로 붙여 주지 않는 한 출처라는 개념 자체가 없습니다. 검색으로 읽으면 사람은 답을 확인 없이 씁니다. 존재하지 않는 조항 번호나 없는 기능 이름이 문서에 그대로 실려 나가는 사고가 대부분 여기서 시작됩니다.

틀린 답을 알려 주면 모델이 배운다고 생각하는 것도 흔한 오해입니다. 대화 중에 지적하면 그 자리에서 고쳐 답하니 배운 것처럼 보입니다. 실제로는 그 대화 안에서만 반영되고 다음 대화에는 남지 않습니다. 학습은 모델을 만드는 쪽에서 따로 하는 일입니다. 이 점을 모르면 같은 실수를 계속 지적하면서 왜 안 고쳐지는지 묻게 됩니다. 반복되는 오류를 줄이는 방법은 지시문을 고치거나, 근거 자료를 붙여 주거나, 가드레일로 걸러 내는 쪽입니다.