제6부 응용: 프롬프트·RAG·에이전트

6.8 멀티모달 — 비전·음성·이미지 생성 통합

사용자는 에러 스크린샷을 붙여 놓고 "이거 왜 이래?"라고 묻는다. 계약서를 촬영해 업로드하고 "여기서 위약금 조항만 뽑아 줘"라고 한다. 운전하며 말로 대화하고 싶어 하고, 발표 자료에 넣을 그림 한 장을 원한다. 텍스트만 다루는 시스템은 이 흐름 앞에서 "텍스트로 복사해서 붙여 주세요"라고 되묻는다 — 제품 경험에서 가장 큰 마찰 중 하나다. 이 장은 텍스트가 아닌 것, 즉 이미지·음성·비디오를 대화형 LLM 시스템에 어떻게 넣고 어떻게 내보내는가를 다룬다.

기술의 핵심은 놀랄 만큼 단순한 관찰에서 나온다. 1.4의 셀프어텐션은 자기가 섞고 있는 벡터가 어디서 왔는지 모른다 — 그저 벡터 열을 유사도로 가중해 섞을 뿐이다. 그렇다면 이미지든 소리든 벡터 열로만 만들어 주면, 어텐션은 그것을 단어와 똑같이 취급한다. 이 한 문장이 "네이티브 멀티모달"이라 부르는 것의 전부다. 다른 길은 전문 모델(OCR·음성인식·음성합성·이미지 생성)을 각각 두고 텍스트 LLM을 허브로 잇는 것이다. 이 장은 각 조각의 원리 — 이미지가 어떻게 토큰이 되고, 그것이 몇 개나 되며, 왜 OCR을 과신하면 안 되고, 음성 대화의 지연은 어디서 오고, 확산 모델은 왜 LLM 한 번 호출보다 느린지 — 를 근본부터 구축한 뒤, 마지막에 "한 모델로 갈까 파이프라인으로 조합할까"의 조립 결정으로 돌아온다.

멀티모달은 이 책에서 모델·시점 편차가 가장 큰 주제다. 어떤 모델이 이미지를 몇 토큰으로 세는지, OCR 정확도가 얼마인지, 음성 지연이 몇 ms인지는 벤더·버전마다 다르고 자주 바뀐다. 그래서 이 장의 숫자는 원리를 보이기 위한 개략 예시로 쓰고, 실제 값은 각 모델의 공식 문서로 확인해야 한다. 무게는 특정 숫자가 아니라 구조와 트레이드오프에 있다 — 어느 조정 변수가 정확도·비용·지연을 어느 방향으로 미는지를 쥐면, 숫자가 바뀌어도 판단은 서 있다.

6.8.1 멀티모달의 두 축과 두 철학

"멀티모달"을 하나로 뭉뚱그리는 것이 첫 번째 함정이다. 실무에서 마주치는 축은 서로 독립적인 두 개다. 하나는 방향이다 — 모달이 입력으로 들어와 모델이 이해하는가(이미지를 읽는다), 출력으로 나가 모델이 생성하는가(그림을 그린다). 많은 시스템이 "이미지 입력은 되지만 이미지 출력은 별도 도구"처럼 방향별로 능력이 갈린다. "이 모델은 이미지를 다룬다"는 말은 입력과 출력 중 어느 쪽인지 밝히지 않으면 절반만 참이다. 다른 축은 모달 자체다 — 텍스트·이미지·오디오·비디오는 데이터의 성질이 근본적으로 다르다. 이미지는 2차원 공간에 펼쳐진 연속값이고, 오디오는 시간축을 가진 1차원 파형이며, 비디오는 그 둘을 겹친 것이다. 성질이 다르니 토큰으로 바꾸는 방식도, 비용의 스케일링도 다르다.

이 모든 것을 실현하는 철학은 크게 둘이고, 이 장 전체를 관통하는 대립축이다.

통합 모델은 하나의 신경망이 여러 모달을 공통 표현 공간에서 함께 학습하고 추론한다. 그림과 글을 함께 근거로 답하는 교차 추론이 자연스럽고, 붙이는 이음매가 없다. 대신 학습이 비용이 크고, 특정 모달의 세밀한 성능 — 이를테면 표준 양식의 정밀 OCR — 은 그 일만 하도록 훈련된 전문 모델에 못 미칠 수 있다. 파이프라인은 전문 모델을 각각 두고 텍스트 LLM을 허브로 잇는다. 부품을 따로 최적화·교체할 수 있고 비용을 조각별로 통제하기 쉽지만, 이음매마다 정보 손실·지연·오류 전파가 생긴다. OCR이 "0"을 "O"로 잘못 읽으면 그 뒤의 LLM은 틀린 텍스트 위에서 완벽하게 추론한다 — 앞단의 오류가 뒷단에서 증폭되지, 교정되지 않는다.

현실의 큰 시스템은 대개 혼합이다. 이미지 이해는 통합 VLM으로, 대량 문서의 정밀 추출은 전용 OCR로 교차검증하고, 음성은 전용 STT/TTS로, 이미지 생성은 별도 확산 모델을 도구로 붙인다. "전부 한 모델"도 "전부 파이프라인"도 정답이 아니다. 어느 조각을 어느 쪽으로 둘지가 곧 멀티모달 시스템 설계의 실체이고, 그 결정을 내리려면 먼저 각 조각이 안에서 무슨 일을 하는지 알아야 한다.

6.8.2 이미지를 토큰으로 — ViT와 패치

가장 널리 쓰이는 멀티모달 형태는 이미지를 입력으로 이해하는 비전-언어 모델(Vision-Language Model, VLM)이다. 골격은 세 부품 — 이미지 인코더, 투영(커넥터), 언어모델 — 이고, 이 셋을 잇는 하나의 아이디어는 "이미지를 토큰들로 바꿔 텍스트 토큰과 나란히 같은 트랜스포머에 넣는다"이다.

$$\underbrace{\text{이미지 인코더}}_{\text{ViT류}} \;\longrightarrow\; \underbrace{\text{투영(커넥터)}}_{\text{projection}} \;\longrightarrow\; \underbrace{\text{언어모델}}_{\text{디코더 트랜스포머}}$$

이미지는 픽셀 격자, 예컨대 $H\times W\times 3$ 개의 실수다. 이를 트랜스포머가 입력받을 벡터 열로 바꾸는 표준 도구가 비전 트랜스포머(Vision Transformer, ViT)다. 원리는 1.2의 토큰화와 정확히 평행하다 — 텍스트를 서브워드로 자르듯 이미지를 패치로 자른다. 이미지를 겹치지 않는 $p\times p$ 픽셀 패치로 나누면 $H\times W$ 이미지는 $\frac{H}{p}\times\frac{W}{p}$ 개 패치가 되고, 각 패치를 펼쳐 선형 투영으로 $d$ 차원 벡터 하나로 만든다. 이것이 패치 임베딩, 즉 이미지 토큰 하나다. 여기에 2차원 위치 임베딩을 더하고 트랜스포머 인코더를 통과시켜 문맥화된 패치 표현을 얻는다. 이 인코더의 셀프어텐션에는 인과 마스크가 없다 — 이미지에는 "앞뒤"라는 인과성이 없으니 모든 패치가 서로를 자유롭게 본다.

$$n_{\text{patch}} = \frac{H}{p}\times\frac{W}{p}$$

왜 굳이 패치로 자르는가. 픽셀 하나를 토큰 하나로 삼으면 안 되나. 안 된다, 그리고 그 이유가 1.4의 제곱 비용에 곧장 닿는다. $336\times336$ 이미지는 픽셀이 $112{,}896$ 개다. 픽셀을 토큰으로 삼으면 셀프어텐션의 점수 행렬이 $112{,}896^2 \approx 1.3\times10^{10}$ 원소가 되어 한 층조차 감당 못 한다. 패치 $p=14$ 로 자르면 토큰이 $24\times24=576$ 개로 줄고 점수 행렬은 $576^2\approx 3.3\times10^5$ 로 내려온다 — 네 자릿수 이상 경량화된다. 패치화는 미학이 아니라 어텐션의 제곱 비용을 감당 가능한 시퀀스 길이로 압축해 담는 장치다. 그리고 바로 여기서 이 장 후반의 비용 문제 전체가 싹튼다: 패치가 작을수록(고해상도) 토큰이 제곱으로 늘어난다. $p$ 를 반으로 줄이면 토큰은 네 배가 된다.

이미지 인코더는 보통 대조학습(contrastive)으로 사전학습된 비전 인코더 — 이미지와 텍스트를 같은 임베딩 공간에 맞춘 CLIP류 — 를 가져다 쓴다. 이미 "그림과 글의 의미를 잇는" 표현을 학습했으니 VLM의 출발점으로 유용하다. 이 인코더를 동결(freeze)한 채 커넥터와 언어모델만 학습할지, 인코더까지 함께 미세조정할지는 설계 선택이다 — 동결은 저렴하고 안정적이지만 이미지·언어 정렬의 상한이 인코더에 갇히고, 함께 학습하면 정렬이 좋아질 수 있으나 비용이 크고 인코더의 일반 시각 능력이 특정 도메인으로 치우칠 위험이 있다. "ViT가 CNN을 완전히 대체했다"는 흔한 요약은 과장이다. 실무 인코더는 순수 ViT뿐 아니라 CNN 백본과 트랜스포머를 섞은 하이브리드, 여러 해상도를 한꺼번에 처리하는 구조 등 다양하고, 어느 모델이 무엇을 쓰는지는 공개되지 않는 경우가 많다. 확고한 것은 원리 하나 — 이미지를 패치 벡터 열로 만든다 — 뿐이다.

6.8.3 투영 — 이미지 토큰을 언어 공간에 정렬

인코더가 낸 패치 벡터는 비전 인코더의 표현 공간에 있다. 언어모델은 자기만의 $d_{model}$ 차원 임베딩 공간을 쓴다(1.2). 둘은 같은 좌표계가 아니다 — 비전 인코더가 "고양이 귀 같은 텍스처"를 가리키는 방향과 언어모델이 "고양이"라는 단어를 놓은 방향은 아무 관계가 없다. 이 둘을 잇는 번역기가 투영(projection) 또는 커넥터(connector)다. 이것이 VLM 설계의 핵심이다. 흔한 방식이 셋 있다.

가장 단순한 것은 MLP 투영이다. 각 패치 벡터를 작은 다층 퍼셉트론으로 $d_{model}$ 차원으로 사상해 언어모델의 임베딩과 같은 자리에 놓는다. 패치 하나가 이미지 토큰 하나가 되므로 576개 패치는 576개 이미지 토큰이 된다 — 세밀함은 다 보존되지만 토큰이 많다. 반대편은 리샘플러다. 학습된 소수의 질의 벡터(예: 64개)가 크로스어텐션으로 수백 개 패치 표현을 훑어 그 안의 정보를 64개 벡터로 압축한다. 질의 개수가 이미지 토큰 수를 정하니, 이미지가 아무리 커도 언어모델은 늘 64개 토큰만 받는다. Q-Former나 Perceiver 리샘플러가 이 계열이다.

핵심 긴장은 정보 보존과 토큰 절약의 척도다. 패치를 그대로 다 넣으면 작은 글씨나 표의 칸 같은 미세 정보를 잘 읽지만 토큰이 많아 비용이 크다. 소수로 압축하면 저렴하지만 미세 정보가 흐려져 OCR·차트 정확도가 떨어진다 — 64개 벡터에 A4 문서의 모든 글자를 우겨넣을 수는 없다. 어느 모델이 어느 방식을 쓰는지, 그래서 어떤 이미지에 강한지는 벤더·버전마다 다르고, 이것이 "VLM마다 OCR 실력이 천차만별"인 구조적 이유다. 문서를 다루는 제품이라면 후보 모델의 커넥터 성향을 능력으로 실측해야지, "멀티모달"이라는 단어를 믿어선 안 된다.

6.8.4 조기 융합과 후기 융합

이미지 토큰을 만들었다고 끝이 아니다. 그것을 언어모델과 어디서 합치느냐로 두 갈래가 갈린다.

조기 융합은 이미지 토큰을 텍스트 토큰과 같은 입력 시퀀스에 이어 붙여, 처음부터 모든 트랜스포머 층에서 함께 셀프어텐션한다. 구현이 단순하고 — 사전학습된 LLM에 손댈 필요 없이 입력 앞에 이미지 토큰만 삽입하면 된다 — 모달 간 상호작용이 첫 층부터 깊다. 대가는 명확하다. 이미지 토큰이 컨텍스트 길이를 그대로 차지한다. 고해상도 이미지가 수천 토큰을 차지하면 텍스트 예산을 잠식하고, 5.1에서 본 KV 캐시도 그만큼 증가한다 — 이미지 토큰 하나하나가 키·값을 캐시에 남기기 때문이다. 최신 오픈 VLM은 단순함 때문에 조기 융합을 많이 택하는 경향이 관찰된다.

후기 융합은 다르다. 텍스트는 자기 셀프어텐션 스택을 그대로 돌되, 중간중간 삽입된 크로스어텐션 층에서 이미지 표현을 참조한다. 이 크로스어텐션이 바로 1.4.11에서 본 그것이다 — 질의는 텍스트 쪽에서, 키·값은 이미지 인코더의 출력에서 나온다. 텍스트 위치가 "지금 생성할 부분이 이미지의 어디를 봐야 하나"를 크로스어텐션으로 찾는 구조다. Flamingo류가 이 계열로, 사전학습된 언어모델을 얼려 둔 채 게이트 달린 크로스어텐션 층만 새로 삽입해 학습한다. 장점은 이미지 토큰이 텍스트 시퀀스 길이를 늘리지 않는다는 것 — 긴 텍스트와 여러 이미지를 함께 다뤄야 할 때 유리하다. 단점은 구조가 복잡하고, 크로스어텐션 층을 어디에 몇 개 끼울지가 또 하나의 설계 변수라는 것이다.

어느 융합이 항상 낫다는 정설은 없다. 데이터·규모·용도가 정한다. 다만 실무 함의 하나는 확고하다: 조기 융합 모델을 쓰면 "이미지 = 토큰"이 곧 비용이자 컨텍스트라는 것. 그래서 이미지가 몇 토큰이 되는지를 셀 줄 알아야 한다.

6.8.5 이미지가 몇 토큰이 되나 — 해상도·타일링·비용

멀티모달 서비스의 비용·지연·컨텍스트를 예측하려면 이미지 한 장이 몇 토큰인지를 세야 한다. 이는 1.2에서 "토큰은 반드시 실제 토크나이저로 센다"고 한 것의 이미지판이다 — 감으로 설정하지 말고 산식으로. 원리적 토큰 수는 세 인자의 곱이다.

$$n_{\text{img}} \;\approx\; \underbrace{n_{\text{tiles}}}_{\text{타일 수}} \times \underbrace{\left(\frac{s}{p}\right)^2}_{\text{타일당 패치}} \times \underbrace{\frac{1}{r^2}}_{\text{커넥터 압축}}$$

여기서 $s$ 는 타일(또는 이미지) 한 변의 픽셀, $p$ 는 패치 크기, $r$ 는 커넥터가 $r\times r$ 패치를 하나로 묶는 압축 계수다. 타일링(tiling)이 왜 필요한지부터 살펴보자. 인코더의 입력 해상도는 고정돼 있다(예: $336\times336$). 그보다 큰 이미지를 단순히 그 크기로 줄이면 A4 한 장의 글씨가 몇 픽셀로 흐려져 못 읽는다. 그래서 큰 이미지를 여러 타일로 분할해 각각 원해상도로 인코딩하고, 흔히 전체 축소본(global thumbnail) 한 장을 더해 "전체 배치는 축소본으로, 세부는 타일로" 본다. 타일이 많을수록 세밀함이 오르고 토큰도 오른다.

숫자를 넣어 직접 따라가 보자. 문서를 찍은 $1008\times672$ 이미지를 처리한다. 인코더 입력은 $336\times336$, 패치 $p=14$, 커넥터 압축 없음($r=1$)이라 두자(모두 개략 예시값).

1. 타일 나누기: $1008/336 = 3$, $672/336 = 2$ → $3\times2 = 6$ 타일. 여기에 전체 축소본 1장을 더해 총 7 크롭.
2. 크롭당 패치: $\left(\frac{336}{14}\right)^2 = 24^2 = 576$ 토큰.
3. 총 이미지 토큰: $7 \times 576 = 4032$ 토큰.

압축 커넥터를 $r=2$(즉 $2\times2$ 패치를 1토큰으로)로 쓰면 $4032/4 = 1008$ 토큰으로 줄지만 세밀함이 떨어진다. 저해상도 모드(타일 없이 축소본 1장)면 $576$ 토큰뿐이다. 같은 이미지가 설정에 따라 576에서 4032 토큰까지 — 7배 차이다. 이 조정 변수(해상도·타일·압축)가 곧 정확도와 비용의 척도다.

이제 이 토큰을 돈과 메모리로 환산하자. 조기 융합에서 이미지 토큰은 입력 토큰과 똑같이 과금되고 똑같이 계산된다(1.2·7.5). 입력 단가를 가정으로 $3 / 1\text{M}$ 토큰이라 두면(실제 단가는 모델별 확인), 고해상도 이미지 한 장 $\approx 4032$ 토큰 $\approx \$0.012$ 다. 여기서 20페이지 스캔 문서를 페이지당 한 장씩 통이미지로 넣으면 $20\times4032 = 80{,}640$ 토큰, 약 $\$0.24$ — 그리고 128k 컨텍스트 창의 60% 이상을 이미지가 소모한다. 답변 생성과 프롬프트가 들어갈 자리가 그만큼 줄어든다.

메모리 쪽 비용은 더 조용하다. 5.1의 8B MHA 모델은 토큰 하나가 KV 캐시에 512 KB를 남긴다. 고해상도 이미지 한 장 4032 토큰이면 그 이미지만으로 KV 캐시가 $4032\times 512\text{KB}\approx 2\text{ GB}$ 다 — 텍스트 4천 토큰과 정확히 같은 무게다. 여러 사용자가 각자 이미지를 붙이면 이 2 GB가 요청 수만큼 곱해져 배치 상한을 옥죈다. 시사점은 셋이다. 이미지는 무비용 첨부가 아니다 — 채팅에 습관적으로 이미지를 넣으면 토큰·비용·지연·KV가 조용히 커진다. 긴 문서를 이미지로 전부 넣기보다 전용 OCR·파서로 텍스트를 뽑아 넣는 편이 훨씬 저렴하고 길게 담긴다 — 파이프라인이 통합보다 나은 전형적 경우다. 그리고 단가를 계산하기 전에 그 모델의 이미지 토큰 산식부터 확인하라 — 여러 API가 "타일 수 기반 공식"을 문서로 공개하지만 계수는 제각각이다. 이것이 1.2의 "실제 토크나이저로 세라"의 이미지판이다.

6.8.6 이미지 입력의 실무 — OCR·문서·차트, 그리고 확률적 판독의 함정

VLM의 킬러 기능은 문서·화면 이해다. 스크린샷 질문, 영수증·계약서 읽기, 차트·표에서 값 뽑기, 다이어그램 설명, UI에서 버튼·오류 찾기. 잘하는 이유에는 구조가 있다. 전용 OCR 엔진은 글자 모양만 보고 옮기지만, VLM은 문맥으로 판독한다 — 앞뒤 단어로 "0"인지 "O"인지, "l"인지 "1"인지 추론하니 흐릿하거나 레이아웃이 복잡한 문서에서 오히려 유리할 때가 있다. 표의 행·열, 양식의 필드, 제목·본문 구분을 의미로 파악하니 "이 표를 마크다운으로", "이 영수증에서 총액만" 같은 지시를 곧장 수행한다. 화면 이해는 에이전트가 UI를 조작하는 능력으로 이어진다(6.7).

그러나 여기서 정직성이 이 장에서 가장 중요해진다. VLM의 이미지 이해는 결정적 판독이 아니라 확률적 생성이다. 이미지 토큰을 조건으로 다음 토큰을 뽑는 것이지, 이미지에서 값을 "읽어 오는" 것이 아니다. 이 차이가 실제 실패를 만든다. 차트에서 정확한 수치를 물으면 모델은 그럴듯한 값을 지어낸다 — 축 눈금이 조밀하고 값이 라벨로 적혀 있지 않으면, 막대 높이를 눈금 사이로 보간해 "약 3.7" 같은 답을 자신 있게 내지만 실제로는 3.2일 수 있다. 1.2.6에서 본 토큰화·산술의 취약성이 이미지에서 재현되는 셈이다. 해상도가 부족하면 작은 글씨를 빈칸으로 두는 것이 아니라 그럴듯한 오답으로 조용히 채운다 — 틀렸다는 신호 없이. 병합 셀이 있는 복잡한 표에서는 값과 헤더의 대응이 한 칸씩 밀리기도 한다. 손글씨·회전·왜곡·다국어에서 편차가 크고, 특히 한국어·CJK OCR 품질은 모델마다 극과 극이라 반드시 실측해야 한다.

이 함정을 다루는 원칙은 몇 가지로 압축된다. 정확성이 중요한 값 — 금액·계좌·수량·날짜 — 은 VLM만 믿지 말고 검증 경로를 둔다. 전용 OCR·문서 파서로 교차확인하거나, 사람이 확인하거나, 구조화 출력(6.9)으로 신뢰도·불확실 표시를 강제하는 식이다. 프롬프트로 근거(grounding)를 요구하는 것도 도움이 된다 — "값이 적힌 위치나 라벨을 함께 인용해"라고 하면 모델이 이미지에서 실제로 본 것에 답을 묶으려 하지만, 인용 자체가 환각일 수 있으니 맹신은 금물이다. 대량·정형 문서(표준 송장·양식)의 고정밀 추출은 그 일만 하도록 훈련된 전용 문서 AI가 VLM보다 정확하고 저렴할 때가 많다 — 파이프라인이 이기는 지점이다. 그리고 무엇보다 정확도를 측정하라. "VLM이 OCR 된다"는 마케팅이지 성능 보장이 아니다. 실제 데이터로 문자 정확도(CER)와 필드 추출 정확도를 벤치마크하고, 벤더·버전이 바뀔 때마다 재측정해야 한다 — 조용히 회귀하는 능력이기 때문이다(8.2). 규제·회계·의료처럼 오류 비용이 큰 곳에서 VLM 출력을 사람 검토 없이 자동 신뢰하는 파이프라인을 만드는 것은 사고를 설계에 심는 일이다.

6.8.7 음성 입출력 — STT와 TTS

음성은 시간축을 가진 연속 신호라 이미지와 성질이 다르다. 스택은 크게 세 조각 — 듣기(STT), 말하기(TTS), 둘을 잇는 실시간 대화 — 로 나뉜다.

STT(Speech-to-Text), 전통적으로 ASR(자동 음성 인식, Automatic Speech Recognition)는 오디오 파형을 텍스트로 옮긴다. 방식은 이미지의 패치화와 놀랄 만큼 닮았다. 파형을 짧은 시간창으로 잘라 주파수 성분을 뽑은 로그-멜 스펙트로그램(주파수×시간의 2차원 표현)으로 바꾼 뒤, 그 시간 프레임들을 벡터 열로 삼아 인코더-디코더 트랜스포머에 넣는다. Whisper류가 이 구조다. 이미지가 패치 벡터 열이 되듯 오디오는 프레임 벡터 열이 되고, 그다음은 같은 트랜스포머 기계다. 실무에서 무는 것은 정확도(WER, Word Error Rate)가 언어·억양·잡음·도메인 용어에 민감하다는 점이다 — 한국어, 전문용어, 고유명사, 숫자 나열에서 편차가 크다. 제품 요건에는 정확도 외에 화자 분리(diarization, "누가 말했나"), 단어별 타임스탬프, 말하는 도중 부분 결과를 내는 스트리밍 인식이 자주 든다. 그리고 실시간 대화 지연에 결정적인 것이 끝점 검출(endpointing) — 사용자가 말을 멈췄는지를 판단하는 것 — 인데, 이것은 다음 절에서 다룬다.

TTS(Text-to-Speech)는 반대 방향이다. 현대 신경망 TTS는 두 갈래다. 하나는 텍스트에서 음향 표현(멜 스펙트로그램)을 만드는 부분과 그것을 실제 파형으로 바꾸는 보코더(vocoder)로 나누는 고전적 구성이다. 다른 하나는 음성을 신경 코덱으로 이산 오디오 토큰으로 바꾼 뒤, LLM처럼 그 토큰을 자기회귀로 생성하는 방식이다 — 텍스트 생성과 같은 기계를 오디오 토큰에 쓰는 것이다. 실무 관심사는 음색·감정·속도 제어, 그리고 음성 복제(voice cloning)의 품질과 오남용 위험이다. 몇 초의 샘플로 특정인의 목소리를 흉내 내는 기술은 사칭·딥페이크의 직접적 통로이고, 이것은 안전·법의 문제로 넘어간다(9.3). 지연 쪽에서는 첫 소리까지의 시간(TTFB, time-to-first-byte)과 스트리밍 합성이 핵심이다 — 문장을 다 만들기 전에 앞부분부터 재생을 시작할 수 있어야 대화가 매끄럽다.

6.8.8 음성 대 음성과 실시간 대화의 지연 예산

음성 챗을 만드는 두 아키텍처가 있고, 이것이 음성 설계의 핵심 대립이다.

케스케이드는 STT → 텍스트 LLM → TTS의 파이프라인이다. 부품 교체·디버깅·비용 통제가 쉽고, 텍스트 LLM의 강력한 추론·도구 사용을 그대로 쓴다. 대신 이음매마다 지연이 쌓이고, 오디오를 텍스트로 압축해 담는 과정에서 비언어 정보 — 억양, 감정, 웃음, 망설임, 끼어들기 — 가 손실된다. 텍스트에는 사용자가 화가 났는지 농담인지가 안 담긴다. 엔드투엔드 음성 대 음성(speech-to-speech)은 하나의 모델이 오디오를 직접 받고 오디오를 직접 낸다. 지연이 짧고, 억양·감정·동시 발화(끼어들기, barge-in) 같은 대화의 결을 살린다. 대신 학습이 어렵고, 텍스트 도구·추론과의 결합, 출력 통제, 안전 필터가 훨씬 까다롭다 — 텍스트라면 정규식으로 걸러 낼 것을 오디오 스트림에서 실시간으로 막아야 한다. 능력과 가용성은 모델별 편차가 크다.

실시간 음성 대화의 체감 품질은 지연이 지배한다. 사람은 대화 상대의 침묵이 몇백 ms만 넘어도 어색함을 느끼기 시작하니, 목표는 흔히 사용자가 말을 멈춘 뒤 응답 시작까지 수백 ms 이내로 설정한다. 케스케이드의 지연 예산은 이렇게 쌓인다.

$$T_{\text{응답}} \;\approx\; \underbrace{T_{\text{끝점검출}}}_{\text{말 끝났나}} + \underbrace{T_{\text{STT}}}_{\text{인식}} + \underbrace{T_{\text{LLM,TTFT}}}_{\text{첫 토큰까지}} + \underbrace{T_{\text{TTS,TTFB}}}_{\text{첫 소리까지}}$$

숫자를 넣어 보면 어디를 손봐야 하는지가 드러난다(모두 개략 예시). 끝점 검출이 침묵 300 ms를 기다려 발화 종료를 확정하고, 스트리밍 STT가 이미 거의 완성해 둔 대본을 150 ms 안에 확정하고, LLM이 그 대본으로 프리필하고 첫 토큰을 내기까지 250 ms(5.1의 TTFT), TTS가 첫 어절의 첫 소리를 내기까지 150 ms라 하자. 첫 소리까지 $300+150+250+150 = 850$ ms다. 사람이 어색함을 느끼기 직전의 아슬아슬한 예산이다.

여기서 스트리밍 파이프라인의 위력이 보인다. 순진하게 구현하면 LLM 응답을 끝까지 다 만든 뒤 TTS를 시작한다. 응답이 40 토큰이고 TPOT가 20 ms면 생성만 800 ms, 거기에 전체 TTS 합성까지 더하면 첫 소리가 한참 뒤로 밀린다. 대신 LLM의 스트리밍 출력을 문장(또는 어절) 단위로 즉시 TTS에 전달하면, 첫 문장이 완성되는 순간 재생이 시작된다 — 위 계산의 $T_{\text{LLM,TTFT}}$ 와 $T_{\text{TTS,TTFB}}$ 만 첫 소리를 지배하고, 나머지 생성·합성은 재생과 겹쳐 흐른다. 스트리밍만으로 체감 지연이 1초 가까이 줄 수 있다. 나머지 수단도 이 예산 안에 있다. 끝점 검출을 너무 보수적으로(길게) 설정하면 지연이 늘고, 너무 공격적으로 설정하면 사용자가 잠깐 숨 고르는 사이 말을 잘라 버린다. 동시 발화 처리 — 사용자가 말을 시작하면 시스템이 즉시 재생과 생성을 멈추는 취소 로직 — 가 없으면 대화가 로봇처럼 뻣뻣해진다. 그리고 지연이 예산인 이상 모델·인프라의 지역 배치와 경량 모델 선택이 크게 작용한다(5.5). 데모의 매끄러움은 잘 통제된 환경일 수 있다 — 잡음·억양·네트워크·끼어들기가 겹치는 실사용 조건에서 지연과 정확도를 직접 재고, 그 데이터로 케스케이드와 엔드투엔드를 고르는 것이 정직한 절차다.

6.8.9 이미지 생성 — 확산 모델의 원리

여기서 방향이 바뀐다. 이제 모달을 이해하는 것이 아니라 생성한다. 오늘날 이미지·비디오 생성의 주류는 확산 모델(diffusion model)이고, 생성 원리가 자기회귀 LLM(1.1)과 근본적으로 다르다 — 다음 토큰을 하나씩 뽑는 것이 아니라, 순수 노이즈에서 이미지를 점진적으로 걷어낸다.

발상은 두 과정의 쌍이다. 전진 과정(forward)은 깨끗한 이미지 $x_0$ 에 작은 가우시안 노이즈를 여러 단계 $t=1,\dots,T$ 에 걸쳐 조금씩 더해 결국 순수 노이즈 $x_T$ 로 만든다 — 학습이 필요 없는 고정 과정이다. 역진 과정(reverse)은 신경망이 "이 노이즈 낀 이미지에 든 노이즈가 무엇인지"를 예측하도록 학습한다. 그러면 순수 노이즈에서 시작해 예측한 노이즈를 조금씩 걷어내며 새 이미지를 만들 수 있다.

수식은 최소한만 밟자. 전진 과정의 편리한 성질은 임의의 시각 $t$ 로 한 번에 건너뛸 수 있다는 것이다(노이즈 스케줄 $\bar\alpha_t$).

$$x_t = \sqrt{\bar\alpha_t}\,x_0 + \sqrt{1-\bar\alpha_t}\,\epsilon, \qquad \epsilon \sim \mathcal{N}(0, I)$$

$\bar\alpha_t$ 는 $t$ 가 클수록 0에 가까워져 $x_t$ 가 점점 순수 노이즈가 된다. 신경망 $\epsilon_\theta$ 는 주입된 노이즈 $\epsilon$ 을 맞히도록 학습한다(조건 $c$ 는 텍스트 프롬프트).

$$\mathcal{L} = \mathbb{E}_{x_0,\,\epsilon,\,t}\Big[\big\|\,\epsilon - \epsilon_\theta(x_t,\,t,\,c)\,\big\|^2\Big]$$

생성(샘플링)은 $x_T\sim\mathcal N(0,I)$ 에서 시작해 매 단계 $\epsilon_\theta$ 로 노이즈를 조금 걷어내며 $x_T\to\cdots\to x_0$ 로 되돌린다. 여기서 이미지 생성의 비용 구조가 드러난다. 이 되돌림은 한 방에 끝나지 않고 수십에서 수천 단계를 밟으며, 매 단계가 큰 신경망의 순전파 한 번이다. LLM이 토큰 하나에 순전파 한 번인 것과 비교하면, 이미지 한 장에 50단계라면 큰 UNet/DiT를 50번 통과하는 셈이다. 이것이 이미지 생성이 LLM 한 번 호출보다 몇 배 느리고 비용이 큰 근본 이유이고, 단계 수를 줄이는 연구(빠른 샘플러·증류)가 곧 속도와 품질의 척도인 이유다.

두 개념을 더 추가하면 실무 그림이 선다. 분류자-자유 안내(classifier-free guidance, CFG)는 프롬프트를 준 예측과 안 준 예측을 섞어 프롬프트를 얼마나 강하게 따를지를 조절한다.

$$\hat\epsilon = \epsilon_\theta(x_t,t,\varnothing) + w\big(\epsilon_\theta(x_t,t,c) - \epsilon_\theta(x_t,t,\varnothing)\big)$$

안내 강도 $w$ 가 크면 프롬프트에 충실하지만 다양성이 줄고 과포화된 그림이 나오기 쉽다 — 프롬프트 충실도와 자연스러움의 척도다. 그리고 잠재 확산(latent diffusion)은 픽셀 공간이 아니라 오토인코더가 압축한 저차원 잠재 공간에서 확산을 실행해 계산을 크게 줄인다. 고해상도 이미지 생성이 실용화된 것이 대체로 이 덕이다. 지금까지의 설명은 확산의 표준 개념(DDPM 계열)이다. 실제 최신 생성기는 흐름 매칭(flow matching)·정류 흐름·확산 트랜스포머(DiT) 같은 변형을 쓰고, 자기회귀나 GAN 계열도 존재한다. "이미지 생성 = 이 수식"으로 못 박지 말 것 — 확고한 것은 원리(노이즈에서 점진 복원)와 트레이드오프(단계 수가 품질과 속도를 가른다)뿐이다.

6.8.10 챗에 이미지 생성 붙이기 — 도구로서

대화형 시스템에서 이미지 생성은 보통 LLM 본체가 직접 픽셀을 출력하는 것이 아니라, 별도의 생성 모델을 도구로 호출하는 형태다 — 6.5의 함수 호출과 같은 패턴이다. 텍스트와 이미지 사이의 왕복은 이렇게 흐른다.

이 구조에서 LLM은 오케스트레이터다. 사용자의 대화 맥락을 좋은 생성 프롬프트로 번역하고(스타일·구도·해상도를 명시하고 모호함을 채운다), 도구를 호출하며, 결과를 대화에 통합한다. 텍스트에서 이미지로 가는 품질의 상당 부분이 이 프롬프트 번역에 달렸다 — 사용자가 "멋지게"라고만 해도 오케스트레이터가 구체적 묘사로 확장하는 것이 요령이다(6.1). 반복 편집은 어렵다. "배를 더 크게" 같은 후속 지시는 이전 이미지를 참조한 편집·재생성(인페인팅·이미지-투-이미지)이 필요하고, 여러 번 고쳐도 캐릭터·스타일의 일관성을 유지하는 것은 아직 완전히 풀리지 않은 문제다. 일부 모델은 이미지를 토큰으로 직접 생성해 도구 호출 없이 대화 흐름 안에서 이미지를 내놓기도 하지만, 가용성·품질의 편차가 크다.

한 가지는 선택이 아니라 필수 관문이다 — 안전과 저작권의 필터. 생성 요청과 결과 양쪽 모두 폭력·성적 콘텐츠, 실존 인물, 상표·저작 캐릭터를 거르는 검사를 거쳐야 한다. 이미지·음성 생성은 딥페이크와 사칭의 직접적 통로이고, 여기서 미룬 판단은 나중에 법적·평판적 비용으로 돌아온다(7.3·9.3).

6.8.11 비디오와 멀티모달 RAG

비디오 이해는 이미지 이해에 시간축이 붙은 것이다. 순진하게는 프레임을 뽑아(예: 초당 1프레임) 각각을 VLM에 이미지 토큰으로 넣는데, 토큰 급증이 즉각 문제가 된다. 6.8.5의 산식을 그대로 곱해 보자. 1분 영상을 초당 1프레임으로 뽑으면 60프레임이다. 저해상도 모드로 프레임당 256 토큰만 가정해도 $60\times256 = 15{,}360$ 토큰 — 그리고 이것은 이미지 KV 계산과 이어져 15k 토큰이면 앞서 본 512 KB/토큰으로 약 7.5 GB의 KV 캐시다. 고해상도 타일링으로 프레임당 4032 토큰을 쓰면 $60\times4032\approx 242{,}000$ 토큰으로, 웬만한 컨텍스트 창 전체를 넘긴다. 그래서 비디오는 무엇을 넣을지 고르는 것이 곧 설계다 — 키프레임만 선택하거나, 인접 프레임의 중복을 제거하거나, 시공간 풀링으로 압축하거나, 대사는 오디오 트랙에서 STT로 따로 뽑아 텍스트로 넣는다. 비디오 생성은 확산을 시공간으로 확장한 것으로, 계산량이 매우 크고 프레임 간 모션·정체성 일관성이 난제다.

멀티모달 RAG는 RAG(6.3·6.4)를 이미지·표·차트가 섞인 자료로 확장한 것이다. 두 접근이 있다.

실무에서 흔한 것은 하이브리드다. 검색 단계는 텍스트 임베딩(캡션·OCR)으로 저렴하게 하되, 생성 단계에서 원본 이미지·표를 VLM에 함께 제시해 근거를 원본으로 삼는다 — 검색은 텍스트로, 판단은 원본으로. 다만 6.8.6의 함정(차트 수치 환각)이 그대로 따라오므로, 검색된 원본 위에서 VLM이 읽는 값도 여전히 검증 대상이라는 점을 잊으면 안 된다.

6.8.12 한 모델 vs 파이프라인 — 조립 결정

이제 6.8.1의 대립축으로 돌아와 결정을 정리한다. 강요하지 않고 세 길을 펼친다.

첫째 길은 통합 모델 하나(native multimodal API)다. 이미지·오디오·텍스트를 받는 단일 API를 쓴다. 모달 간 교차 추론이 중요할 때 — 그림과 글을 함께 근거로 답해야 할 때 — 강하고, 빠른 프로토타이핑과 운영 단순화에 유리하며, 팀이 작을수록 이점이 크다. "스크린샷 보고 대화" 같은 대화형 이해가 전형적 용처다. 대가는 특정 모달의 세밀한 성능(정밀 OCR·특수 도메인 음성)이 전용 모델에 못 미칠 수 있다는 것, 이미지 토큰이 비용·컨텍스트를 잠식한다는 것(6.8.5), 그리고 벤더 종속이다. 둘째 길은 전문 모델 파이프라인이다. 전용 OCR·STT·TTS·이미지 생성에 텍스트 LLM을 허브로 잇는다. 특정 모달의 고정밀·고효율이 핵심일 때 — 대량 정형 문서 추출, 특정 언어 STT — 이기고, 비용을 조각별로 최적화하며, 부품 교체나 온프레미스가 필요할 때 맞는다. 대가는 이음매마다의 지연·정보 손실·오류 전파, 통합·운영 복잡도, 여러 모델의 버전·품질 관리 부담이다. 셋째 길은 혼합이고, 이것이 현실의 대세다. 이해는 통합 VLM, 정밀 추출은 전용 OCR로 교차검증, 음성은 전용 STT/TTS, 생성은 확산 도구 — 모달·정확도 요구·비용에 따라 조각별로 최선을 고른다.

무엇으로 가르느냐 — 판단 축은 정확도 비용, 지연 예산, 모달 결합 필요, 운영 역량, 규제다. 오류 비용이 큰 값 추출은 파이프라인에 검증을 더하고, 대화형 이해는 통합으로, 실시간 음성은 지연으로 케스케이드와 엔드투엔드를 가른다. 내 견해로는 대부분의 팀에서 실수는 한쪽 극단을 이념으로 택하는 데서 온다 — "한 모델이 다 한다"는 마케팅 서사에 기대 정밀 OCR까지 통합 VLM에 맡기거나, 반대로 단순한 스크린샷 질답에까지 부하가 큰 파이프라인을 세우거나. 조각별 성능·비용을 실제 데이터로 재서 정하고, 그 위에서 통합을 기본값으로 삼되 정확도가 임계인 조각만 전용으로 떼어 내는 편이 대개 균형이 좋다.

6.8.13 멀티모달을 다룰 때의 정직성

멀티모달은 이 책에서 과신 위험이 가장 큰 영역이라, 마지막으로 반복해 무는 지점들을 산문으로 정리해 둔다. 가장 흔한 오류는 능력을 하나로 뭉뚱그리는 것이다. "이 모델은 멀티모달"이라는 말은 모달·방향·언어별로 편차가 크다는 사실을 가린다 — 이미지 이해는 되지만 이미지 출력은 없거나, 영어 OCR은 좋아도 한국어는 약하거나, 음성 입력만 되고 실시간 대화는 안 되는 식이다. 각 능력을 개별로 확인하고 실측해야 한다. 그다음이 OCR·차트 정확도의 과신이다. 앞서 봤듯 VLM의 판독은 결정적 인식이 아니라 확률적 추론이라, 숫자·작은 글씨·복잡한 표에서 그럴듯한 오답을 자신 있게 낸다. 정확성이 중요하면 전용 도구·검증·사람 개입을 넣어야지, 눈으로 확인한 사실처럼 다루면 안 된다.

비용과 지연도 조용히 누적된다. 고해상도·다장·비디오는 토큰·비용·컨텍스트를 폭증시키니 이미지 첨부는 무비용이 아니고, 실시간 음성은 데모의 매끄러움과 실사용(잡음·억양·끼어들기·네트워크)이 다르니 지연·정확도를 실제 조건에서 재야 한다. 생성물에는 안전과 저작권이 붙는다. 이미지·음성 생성은 딥페이크·사칭·유해 콘텐츠·상표/캐릭터 침해의 통로이고, 학습 데이터 출처, 실존 인물·저작 캐릭터 생성, 음성 복제 동의는 저작권·퍼블리시티권·개인정보와 얽힌다 — "생성했으니 내 것"이 아니며, 입력 프롬프트와 출력 결과 양쪽에 안전·저작권 관문을 둬야 한다(9.3). 놓치기 쉬운 공격면 하나가 모달 간 프롬프트 인젝션이다. 이미지 속 텍스트, 스테가노그래피, 가청 밖 오디오 신호에 숨은 지시를 심어 시스템을 조종하는 길이 열린다 — 멀티모달은 입력 채널을 늘리는 만큼 공격 표면도 넓히니, 신뢰할 수 없는 이미지·오디오를 명령으로 취급하지 않도록 방어해야 한다(7.4). 마지막으로 이 모든 능력·산식·품질이 벤더·버전마다 자주 바뀐다는 사실 자체가 함정이다. 정확도와 비용을 회귀 테스트로 고정 감시하고 버전이 바뀔 때 재측정하는 것이, 이 빠르게 움직이는 표면 위에서 서비스를 지키는 유일한 방법이다(8.2).

멀티모달 추출값을 신뢰할 수 있게 만드는 다음 조각은 그 값을 JSON·스키마로 강제하는 구조화 출력·제약 디코딩이다(6.9) — VLM이 "그럴듯하게 읽은" 값을 자유 텍스트로 출력하는 대신 검증 가능한 형식에 담게 하는 것이, 이 장에서 반복한 확률적 판독의 위험을 시스템 차원에서 붙드는 첫 걸음이다.