무슨 일이 있었나요
Apple이 HuggingFace에 LensVLM-9B라는 모델을 공개했어요. 이름 그대로 렌즈처럼 긴 문맥을 작게 압축해서 훑어보다가, 필요한 부분만 확대해서 자세히 보는 방식의 비전-언어 모델(VLM)이에요. 핵심 아이디어를 한 문장으로 말하면 “긴 텍스트 문맥을 이미지로 렌더링해서 압축된 형태로 넣어두고, 질문과 관련 있는 페이지만 다시 펼쳐서 자세히 읽는다”는 거예요. 긴 문맥 처리 비용을 줄이려는 시도는 많았지만, 텍스트를 굳이 그림으로 바꿔서 넣는다는 발상이 처음 들으면 좀 이상하게 느껴지실 수 있어요. 그런데 이게 요즘 꽤 진지하게 연구되는 방향이거든요.
왜 텍스트를 이미지로 바꾸나요
이게 뭐냐면, LLM은 텍스트를 토큰 단위로 처리하는데 한국어 기준으로 대략 글자 한두 개가 토큰 하나 정도예요. 100페이지짜리 문서면 수만 토큰이 되고, 트랜스포머의 어텐션 연산은 토큰 수의 제곱에 비례해서 비용이 늘어나요. 그런데 같은 텍스트를 이미지로 렌더링해서 비전 인코더에 넣으면, 한 페이지가 수백 개 정도의 시각 토큰으로 표현돼요. 텍스트 토큰으로 하면 천 개 넘게 필요한 분량이 몇 배에서 십 몇 배까지 압축되는 거죠. 이 아이디어를 광학 압축(optical compression)이라고 부르기도 해요.
비유하자면, 두꺼운 책을 한 페이지씩 다 읽는 대신 축소 복사해서 한 장에 여러 페이지를 담은 썸네일 목록을 먼저 보는 거예요. 어느 페이지에 내가 찾는 내용이 있는지 대략 파악한 다음, 그 페이지만 원래 크기로 펼쳐서 읽는 거죠. 사람이 두꺼운 매뉴얼에서 목차와 페이지를 휙휙 넘기며 찾는 방식과 닮았어요.
LensVLM의 두 단계 구조
이름에 붙은 “관련 페이지만 펼친다(expanding only relevant pages)”가 중요한 부분이에요. 긴 문맥을 이미지로 압축하는 것만으로는 세밀한 정보가 손실될 수 있거든요. 압축률을 높일수록 글자가 뭉개지듯이 정확도가 떨어져요. 그래서 LensVLM은 압축된 시각 토큰으로 전체를 훑어본 뒤, 질문에 답하는 데 필요한 페이지만 골라서 원본에 가까운 상세한 표현으로 다시 펼치는 단계를 둔 구조로 보여요. 이렇게 하면 관련 없는 페이지는 싸게 처리하고, 중요한 페이지에만 계산을 집중할 수 있어요.
이건 검색 증강 생성(RAG)과도 닮았어요. RAG는 외부 검색기로 관련 청크를 찾아서 모델에 넣어주지만, LensVLM은 모델 자체가 압축된 전체 문맥을 보면서 어디를 펼칠지 결정하는 셈이라 문서 전체의 흐름을 잃지 않는다는 장점이 있어요. 청킹 경계에서 문맥이 끊기는 RAG의 고질적인 문제를 다른 방식으로 우회하는 거죠.
업계 맥락
이 방향은 2025년 하반기부터 급격히 뜨거워졌어요. DeepSeek이 공개한 DeepSeek-OCR은 “Contexts Optical Compression”이라는 이름으로 텍스트를 이미지로 넣으면 10배 압축에서도 97% 정도의 정확도로 복원된다는 걸 보여줬고, Zhipu AI의 Glyph는 아예 긴 문맥 전체를 이미지로 렌더링해서 VLM으로 읽는 프레임워크를 제안했어요. Apple은 여기서 한 걸음 더 나가서 “압축만 하지 말고 필요한 곳은 다시 펼치자”는 선택적 확장을 붙인 거예요.
Apple의 행보도 눈여겨볼 만해요. Apple은 그동안 FastVLM처럼 온디바이스에서 빠르게 돌아가는 VLM에 꾸준히 투자해 왔는데, 긴 문서를 적은 토큰으로 처리하는 기술은 메모리가 제한된 iPhone이나 Mac에서 특히 가치가 있어요. 9B라는 크기도 Mac 한 대에서 양자화해서 돌려볼 수 있는 수준이고요. 서버가 아니라 기기 안에서 긴 문서를 다루겠다는 방향성과 잘 맞는 선택이에요.
한편 이 접근이 만능은 아니에요. 코드처럼 문자 하나가 중요한 데이터는 압축 시 손실이 치명적일 수 있고, 텍스트를 렌더링하는 폰트와 해상도에 따라 성능이 달라져요. 그리고 애초에 텍스트 토크나이저가 비효율적이라는 근본 문제를 우회하는 것이지 해결하는 건 아니라는 비판도 있죠.
한국 개발자에게 주는 시사점
첫째, 긴 PDF, 계약서, 기술 문서를 다루는 서비스를 만들고 있다면 직접 실험해볼 가치가 있어요. HuggingFace에 가중치가 공개되어 있으니 transformers나 MLX로 Mac에서 돌려볼 수 있을 거예요. 특히 한국어는 영어보다 토큰 효율이 나쁜 편이라 이미지 압축의 이득이 상대적으로 클 수 있어요. 다만 한글 렌더링 품질과 한글 인식 정확도는 꼭 직접 검증해 보세요. 영어 중심으로 학습된 모델이라면 한글에서 성능이 다를 수 있거든요.
둘째, RAG 파이프라인 설계에 새로운 관점을 줘요. 청킹과 임베딩 검색으로 관련 부분을 찾는 대신, 모델이 압축된 전체를 보고 스스로 어디를 펼칠지 결정하는 구조가 가능해지는 거니까요. 지금 당장 교체하라는 건 아니지만, 벤치마크에 하나 추가해두면 좋을 거예요.
셋째, 이 흐름은 “토큰은 곧 텍스트”라는 고정관념이 흔들리고 있다는 신호예요. 앞으로 문맥 창을 늘리는 경쟁이 단순히 숫자를 키우는 게 아니라, 얼마나 똑똑하게 압축하고 필요할 때만 펼치느냐로 옮겨갈 수 있거든요.
마무리
한 줄로 정리하면, Apple이 긴 문맥을 이미지로 압축해 훑어보고 필요한 페이지만 펼쳐 읽는 9B 모델을 공개했다는 이야기예요.
여러분은 긴 문서 처리에서 어떤 방법을 쓰고 계세요? RAG로 잘라서 넣는 방식과 이렇게 압축해서 통째로 넣는 방식, 어느 쪽이 실무에서 더 믿을 만하다고 생각하시나요?
🔗 출처: Hacker News