임베딩과 생성: 모델이 하는 두 가지 일

사람들은 "AI를 쓴다"는 말을 마치 그것이 하나의 능력인 것처럼 이야기합니다. 하지만 실제로 대부분의 제품을 떠받치는 모델은 적어도 두 가지 매우 다른 일을 하며, 이 둘을 혼동하는 것이 프로젝트가 멈춰 서는 흔한 원인입니다. 한 가지 일은 생성입니다. 텍스트, 코드, 이미지를 토큰 단위로 새롭게 만들어 내는 것이죠. 다른 한 가지는 임베딩입니다. 어떤 콘텐츠를 그 의미를 담은 숫자 목록으로 바꿔, 기계가 다른 콘텐츠와 비교할 수 있게 만드는 것입니다. 같은 기반 기술이 둘 다를 떠받치는 경우가 많아 비슷해 보이지만, 이 둘은 서로 다른 질문에 답하며 시스템의 서로 다른 자리에 속합니다.

이 글은 두 가지 일을 쉬운 말로 설명하고, 각각이 어디에 들어맞는지 보여 주며, 내 문제가 실제로 어느 쪽을 필요로 하는지 가려내는 데 도움을 드립니다. 의외로 많은 "더 똑똑한 모델이 필요해" 문제가 사실은 "엉뚱한 일을 시켰어" 문제이기 때문입니다.

생성이 하는 일

생성은 사람들이 언어 모델을 떠올릴 때 가장 먼저 그리는 일입니다. 입력 — 프롬프트, 질문, 쓰다 만 문서 — 을 주면, 모델은 한 조각씩 출력을 만들어 내며, 각 조각은 앞서 나온 모든 것을 바탕으로 선택됩니다. 그 결과는 이전에 존재하지 않던 새로운 콘텐츠입니다. 답변, 요약, 재작성, 코드 한 덩어리 같은 것이죠.

생성의 결정적 특징은 무언가를 만들어 낸다는 점입니다. 생성은 열려 있습니다. 정해진 정답 메뉴가 따로 없고, 모델이 무언가를 지어냅니다. 그 힘이 곧 비용이기도 합니다. 생성은 단계를 하나씩 밟기에 상대적으로 느리고, 각 단계가 실제 연산이기에 상대적으로 비싸며, 매 단계마다 진짜 선택이 일어나기에 출력이 들쭉날쭉합니다. 무언가를 만들어 내야 할 때는 생성이 맞는 일이며, 이런 비용들은 그 대가입니다.

임베딩이 하는 일

임베딩은 새로운 콘텐츠가 아닙니다. 측정값입니다. 모델은 어떤 콘텐츠를 읽고 고정 길이의 숫자 목록 — 벡터 — 을 돌려줍니다. 이 벡터는 그 콘텐츠가 일종의 "의미 공간" 속 어디에 자리하는지를 나타냅니다. 비슷한 의미를 지닌 두 콘텐츠는 그 공간에서 가까이 놓이고, 다른 의미를 지닌 두 콘텐츠는 멀리 떨어집니다. 숫자 자체는 사람이 읽을 수 없지만, 그래도 괜찮습니다. 그 숫자의 유일한 목적은 컴퓨터가 비교하는 것이기 때문입니다.

임베딩의 결정적 특징은 유사도를 대규모로 측정할 수 있게 해 준다는 점입니다. 문서들을 한 번 임베딩해 두면, 어떤 질의에 가장 관련 깊은 문서를 찾는 일은 빠른 수학 연산이 됩니다. 질의의 벡터를 저장된 벡터들과 비교해 가까운 순으로 정렬하는 것이죠. 임베딩은 값싸고 빠르며, 저장해 두고 다시 쓸 수 있는 안정적인 결과를 냅니다. 생성이 만들어 낸다면, 임베딩은 찾아냅니다.

둘을 구별하는 간단한 방법

내 문제에 이 한 가지 질문을 던져 보세요. 시스템이 무언가를 만들어야 하는가, 아니면 무언가를 찾거나 비교해야 하는가?

답이 "만든다"라면 — 이 답장을 써라, 이 요약을 작성하라, 이 문단을 번역하라, 이 코드를 생성하라 — 생성이 필요합니다. 답이 "찾는다"거나 "비교한다"라면 — 어느 문서가 이 질문에 답하는가, 이 두 티켓은 중복인가, 이 리뷰들을 주제별로 묶어라, 이 질의가 우리가 본 것 중 무엇과 가까운가 — 임베딩이 필요합니다. 실제 기능 중 상당수는 두 가지를 순서대로 모두 필요로 하며, 그 둘 사이의 이음매를 알아보는 것이 설계 작업의 대부분입니다.

둘이 함께 작동하는 방식

두 가지 일이 협력하는 가장 분명한 예는 검색 증강 생성(RAG)입니다. 대부분의 "내 문서와 대화하기" 기능을 떠받치는 표준 패턴이죠. 이것은 두 가지 일에 정확히 대응되는 두 단계로 작동합니다.

먼저 임베딩 단계입니다. 지식 베이스의 모든 문서를 미리 한 번 임베딩해 벡터를 저장해 둡니다. 사용자가 질문을 하면 그 질문도 임베딩한 뒤, 벡터 비교를 통해 의미가 가장 가까운 몇 개의 저장된 조각을 끌어옵니다. 이 과정은 빠르고 값싸며, 수천 개의 문서를 중요한 몇 개로 좁히는 방법입니다.

다음은 생성 단계입니다. 검색된 그 몇 조각이 사용자의 질문과 함께 생성 모델에 전달되고, 모델은 그 제공된 맥락에 근거해 답변을 씁니다. 임베딩이 찾아내고, 생성이 써낸 것이죠. 모든 문서를 프롬프트에 욱여넣어 생성만으로 전부 해결하려 들면 느리고 비싸며 금세 한계에 부딪힙니다. 임베딩만으로 하려 들면 관련 문서는 얻지만 실제 답변은 없습니다. 두 가지 일은 상호 보완적이지, 서로 바꿔 쓸 수 있는 것이 아닙니다.

이 구분이 돈과 시간을 아끼는 이유

이 두 가지 일을 헷갈리지 않을 때의 실질적 이득은, 값싼 일에 비싼 도구를 쓰는 짓을 멈추게 된다는 것입니다. 생성은 비싼 작업이고, 임베딩은 값싼 작업입니다. 콘텐츠를 한 번 임베딩해 두고 매 질의마다 빠른 벡터 비교를 돌리는 시스템은 검색 단계에 거의 비용을 쓰지 않으며, 진짜로 새 텍스트가 필요한 순간에만 비싼 생성 단계를 아껴 둡니다.

반대 실수는 흔하면서도 조용히 비용을 잡아먹습니다. 임베딩이 더 잘 처리할 일을 생성 모델에 시키는 것이죠. "이 지원 티켓이 과거 티켓과 비슷한가?"는 무언가를 쓸 필요가 없습니다. 비교가 필요하고, 그것이 바로 임베딩이 하는 일입니다. 이를 생성으로 처리하면 알맞은 도구보다 느리고 비싸며 덜 믿음직합니다. 마찬가지로 분류와 중복 제거도 대개 생성의 옷을 입은 유사도 문제입니다. 그 옷을 알아보는 곳에 절감의 여지가 있습니다.

각각이 무너지는 지점

각 일에는 알아둘 만한 실패 양상이 있습니다. 임베딩은 자기 모델이 학습한 방식대로 의미를 포착하므로, 내 분야는 신경 쓰지만 모델은 배운 적 없는 구분을 놓칠 수 있습니다. 일반적으로는 비슷해 보이지만 내 특수한 맥락에서는 정반대를 뜻하는 두 문장처럼요. 검색이 그럴듯하지만 틀린 결과를 돌려준다면, 임베딩이 가진 "비슷함"의 개념이 용의자입니다.

생성의 실패 양상은 더 잘 알려진 쪽입니다. 유창하고 자신만만하지만 그냥 틀린 콘텐츠를 만들어 낼 수 있습니다. 그 일이란 그럴듯한 무언가를 지어내는 것이지, 그것을 검증하는 것이 아니기 때문입니다. 검색 시스템에서 둘을 짝짓는 이유가 바로 이것입니다. 임베딩이 근거 있는 원자료를 가져와, 생성이 지어내는 대신 딛고 설 사실을 갖게 하는 것이죠. 어느 일도 스스로 교정하지 못합니다. 설계가 각각이 어떻게 실패하는지를 감안해야 합니다.

정리

두 가지 일, 두 가지 목적입니다. 생성은 새 콘텐츠를 한 단계씩 만들어 냅니다 — 강력하고 열려 있지만 상대적으로 느리고 비쌉니다. 임베딩은 의미를 측정해 콘텐츠를 대규모로 찾고 비교할 수 있게 합니다 — 빠르고 값싸며 다시 쓸 수 있습니다. 작동하는 시스템에 가장 빨리 이르는 길은, 내 문제의 각 부분마다 무언가를 만들어야 하는지 찾아야 하는지를 묻고 거기에 맞는 일을 쓰는 것입니다. 견고한 AI 기능 대부분은 한 모델이 모든 것을 하는 것이 아니라, 이 두 가지 일이 각자 잘하는 것을 하도록 배치된 형태입니다. 분업을 제대로 하면 나머지는 훨씬 쉬워집니다.