GPT-OSS-120B에 Google Lens로 눈을 달아주는 법: 천재적인 발상과 엔지니어링의 함정

최근 LLM 씬(Scene)의 화두는 단연 멀티모달(Multimodal)입니다. GPT-4V나 Gemini Pro Vision 같은 모델들은 이미지를 보고 추론하는 능력이 탁월하지만, 오픈소스 진영에서 이를 로컬로, 그것도 거대 모델 수준의 추론 능력과 결합해 돌리는 것은 여전히 하드웨어적으로나 모델 가용성 면에서 장벽이 있습니다.

그런데 오늘 Hacker News에 “GPT-OSS-120B에게 Google Lens와 OpenCV를 이용해 보는 법을 가르쳤다” 는 흥미로운 글이 올라왔습니다. 텍스트 전용 모델에 외부 도구를 붙여 시각 능력을 부여한 것인데, 이 접근 방식이 엔지니어링 관점에서 꽤나 시사하는 바가 큽니다. 동시에 맹점도 명확하죠.

오늘은 이 프로젝트의 기술적 구조와 제가 느낀 현실적인 한계점들을 깊이 파보겠습니다.

작동 원리: “눈” 대신 “통역사”를 쓰다

이 프로젝트의 핵심 아이디어는 간단하면서도 기발합니다. 모델 자체를 멀티모달로 학습시키는(Fine-tuning) 대신, 이미지를 텍스트로 변환해주는 강력한 Oracle(신탁) 을 중간에 끼워 넣은 것입니다.

  1. OpenCV: 로컬 환경에서 이미지를 캡처하거나 전처리합니다.
  2. Google Lens: 이미지를 업로드하여 Google의 거대한 비전 인덱스를 통해 ‘이것이 무엇인지’에 대한 텍스트 설명과 메타데이터를 추출합니다.
  3. GPT-OSS-120B: Google Lens가 뱉어준 텍스트 정보를 프롬프트 컨텍스트로 받아 추론을 수행합니다.

즉, 모델은 실제로 이미지를 “보는” 것이 아니라, Google이 “보고 말해준 것”을 읽는 셈입니다. 기술적으로는 Tool Use 패턴의 일종이라고 볼 수 있겠네요.

왜 이 방식이 흥미로운가?

솔직히 말해, 120B 파라미터 급의 거대 언어 모델이 가진 추론 능력은 웬만한 소형 멀티모달 모델(Llama 3.2 11B Vision 등)보다 뛰어날 때가 많습니다. 하지만 텍스트 모델은 눈이 없죠. 이 프로젝트는 “가장 똑똑한 뇌(GPT-OSS-120B)” 와 “세상에서 가장 방대한 시각 데이터베이스(Google Lens)” 를 API나 복잡한 파이프라인 없이(사실상 스크래핑으로) 연결했다는 점에서 ‘해커’스러운 매력이 있습니다.

엔지니어링 관점에서의 비판: Production Level인가?

하지만 Principal Engineer로서 이 아키텍처를 프로덕션에 도입하겠냐고 묻다면, 제 대답은 단호하게 NO 입니다. HN의 댓글 창도 저와 비슷한 우려로 뜨겁더군요.

1. Fragility (취약성)와 스크래핑의 한계

이 방식은 Google Lens의 웹 인터페이스를 스크래핑하는 것에 의존합니다. HN의 한 유저(anon)가 지적했듯, 이는 매우 Fragile(깨지기 쉬운) 구조입니다.

  • DOM 변경: Google이 div 클래스 명 하나만 바꿔도 전체 파이프라인이 셧다운됩니다.
  • Captcha & Blocking: Playwright나 Puppeteer로 Google을 긁어본 분들은 아실 겁니다. 처음 몇 번은 잘 되다가도, 곧바로 Captcha 지옥에 빠지거나 IP가 차단됩니다. SerpAPI 같은 서비스가 존재하는 이유가 바로 이 ‘Residential Proxy’ 관리와 우회 기술 때문인데, 개인이 이를 안정적으로 유지하는 건 불가능에 가깝습니다.

2. Latency (지연 시간)

이미지를 업로드하고, 구글이 분석하고, 결과를 파싱해서 다시 LLM에 넣고 추론하는 과정. 이 Round-trip Latency는 실시간 애플리케이션에서는 치명적입니다. 로컬 멀티모달 모델을 쓴다면 밀리초(ms) 단위로 끝날 인코딩 작업이, 여기서는 수 초(s)가 걸릴 수 있습니다.

3. TOS (약관) 위반 이슈

커뮤니티에서 가장 뜨거운 감자는 역시 법적 문제입니다. Google의 검색 결과를 무단으로 스크래핑하여 2차 가공하는 것은 명백한 TOS(Terms of Service) 위반 소지가 큽니다. 개인적인 토이 프로젝트라면 모를까, 비즈니스 로직에 Google Lens 스크래핑을 넣는 건 법무팀을 야근시키는 지름길입니다.

대안은 무엇인가?

댓글 중 한 유저가 “Llama를 써봤느냐?” 라고 묻는 부분이 인상적이었습니다. 실제로 Llama 3.2 Vision 같은 모델들은 로컬에서 실행 가능하며, 스크래핑 없이도 준수한 시각적 이해도를 보여줍니다.

물론 Google Lens가 가진 ‘지식 그래프(Knowledge Graph)‘—예를 들어, 특정 상품의 가격이나 희귀한 식물의 정확한 학명 등—는 로컬 모델이 따라가기 힘든 영역입니다. 하지만 순수한 이미지 이해(Scene Understanding)가 목적이라면 로컬 VLM(Vision-Language Model)이 훨씬 안정적이고 빠릅니다.

결론: 재미있는 실험, 위험한 구현

이 프로젝트는 “기존의 강력한 도구들을 어떻게 조합할 것인가” 에 대한 창의적인 접근을 보여줍니다. 텍스트 모델에게 시각 정보를 주입하기 위해 외부의 강력한 ‘눈’을 빌려온다는 컨셉은 RAG(Retrieval-Augmented Generation)의 시각적 확장판처럼 느껴지기도 합니다.

하지만 엔지니어링은 언제나 Trade-off 의 싸움입니다. 외부 의존성(Google Lens)과 법적 리스크, 그리고 시스템의 안정성을 희생하면서까지 120B 모델의 텍스트 추론력을 빌려와야 하는지는 의문입니다.

제 평가는요: 주말에 맥주 한 캔 하면서 깃허브 코드를 뜯어보고 “와, 기발하네!”라고 감탄하기엔 딱 좋습니다. 하지만 월요일 출근해서 회사 코드베이스에 이 로직을 넣지는 마세요. 그건 재앙의 시작이 될 테니까요.

References: