---
title: "네이버, AI탭을 ‘이미지까지 이해하는 검색 에이전트’로 키운다"
published: 2026-07-05T05:05:03.866Z
canonical: https://jeff.news/article/4649
---
# 네이버, AI탭을 ‘이미지까지 이해하는 검색 에이전트’로 키운다

네이버가 AI탭 정식 출시 이후 처음으로 AI 검색 전략을 꽤 구체적으로 풀었다. 핵심은 범용 챗봇 경쟁이 아니라, 검색·쇼핑·예약·플레이스 같은 네이버 서비스 안에서 실제로 일을 끝내는 ‘프로덕트 네이티브 LLM’과 멀티모달 검색이다.

- 네이버가 AI 검색 전략을 다시 꺼냈는데, 메시지는 꽤 명확함. ‘범용 챗봇’이 아니라 네이버 서비스 안에서 검색·구매·예약까지 이어지는 AI를 만들겠다는 쪽임
  - 지난 7월 2일 네이버 D2SF 강남에서 ‘탐색에서 실행까지, 차세대 AI 기술이 만드는 네이버 AI 검색’ 세션을 열었음
  - 6월 26일 정식 출시한 AI탭을 중심으로, 전용 모델과 하네스 엔지니어링, 멀티모달 기술을 소개함
  - AI탭 사용자는 베타 대비 정식 출시 이후 3~4배 늘었다고 밝힘

- 핵심 모델은 ‘프로덕트 네이티브 LLM’임. 이름 그대로 제품에 붙여 쓰기 위한 모델이라는 뜻에 가까움
  - 기존 하이퍼클로바X(HCX)를 기반으로 경량화했고, 네이버 데이터·서비스 시나리오·사용자 피드백을 모델 설계 전반에 반영함
  - 질의 이해, 답변 요약, 도구 호출 같은 AI 검색 필수 능력을 강화했다고 설명함
  - 장문 컨텍스트에서도 응답 시간이 늘지 않는다고 강조했는데, AI 에이전트가 여러 데이터를 계속 물고 가야 하는 상황을 겨냥한 포인트임
  - 다만 매개변수 규모나 구체적인 모델 스펙은 공개하지 않았음. 이건 좀 아쉬운 부분임

- 네이버가 계속 강조한 건 “LLM 하나로는 서비스가 안 된다”는 관점임
  - 사용자가 원하는 정보가 어디에 있고, 어떤 도구로 가져와야 하며, 어떤 순서로 실행해야 하는지는 모델의 말솜씨만으로 해결하기 어렵다는 얘기임
  - 그래서 네이버는 하네스 엔지니어링(Harness Engineering)을 본격 적용했다고 설명함
  - 쉽게 말하면 LLM 위에 안전장치, 의도 파악, 검색·쇼핑·플레이스 연동, 출처 제공, 실행 연결을 얹어 ‘일머리’를 보강하는 구조임

> [!IMPORTANT]
> 네이버가 내세운 차별점은 모델 크기가 아니라 서비스 실행력임. 검색·구매·예약처럼 실제 사용자 행동으로 이어지는 흐름을 얼마나 안정적으로 처리하느냐가 승부처라는 얘기임

- 학습 방식도 단순히 정답을 외우게 하는 쪽이 아니라, 서비스 상황에서 잘 행동하게 만드는 쪽에 맞춰져 있음
  - 베리파이어 강화학습(Verifier RL)을 적용해 모델이 답을 만든 뒤 풀이가 맞는지 스스로 검증하도록 했음
  - 지도 미세조정(SFT)이 사람이 준 답을 기억하게 만드는 방식이라면, 여기서는 답변 과정과 검증 행동에 보상을 주는 쪽임
  - 보상 기준에는 정확한 도구 호출, 도구 호출 결과에 기반한 답변, 사용자 요구사항 충족, 답변의 자연스러움이 들어감

- 모호한 질문에는 바로 찍어서 답하지 않고 되묻도록 학습한 것도 포인트임
  - 네이버는 이를 명료성 강화학습(Clarify RL)이라고 부름
  - 사용자의 의도가 불분명한데도 답변을 밀어붙이면 검색 AI에서는 환각이나 엉뚱한 실행으로 바로 이어질 수 있음
  - 그래서 먼저 추가 질문을 하도록 보상한 건, 실제 서비스 관점에서 꽤 중요한 선택임

- 모델 개선에는 자기정책 기반 증류(OPD)도 썼음
  - 학생 모델이 만든 답변을 고성능 교사 모델이 토큰 단위로 첨삭하는 방식임
  - 부족한 전문 영역을 보완하고, 교사 모델 성능이 좋아질수록 학생 모델도 계속 개선되는 구조라고 설명함
  - 이건 경량 모델을 서비스에 넣으면서도 품질을 끌어올리려는 전략으로 볼 수 있음

- 비용과 속도 쪽에서는 전문가 혼합(MoE)과 분업형 소형언어모델(sLM) 구조를 꺼냈음
  - 대규모 서비스 환경에 맞춰 MoE 아키텍처를 도입했고, 사용자 경험에 직결되는 E2E 지연 시간(Latency)을 줄였다고 밝힘
  - 하나의 LLM이 모든 작업을 처리하는 대신, 작업별 sLM이 각자 역할을 수행하는 구조를 만들었음
  - 그 결과 일부 컴포넌트 장비 운영 비용은 최대 3배 절감했고, 응답 속도는 2배 이상 개선했다고 함

```mermaid
sequenceDiagram
    participant 사용자
    participant AI탭
    participant 하네스
    participant 네이버서비스
    participant 전용모델
    사용자->>AI탭: 질문 또는 이미지 입력
    AI탭->>하네스: 의도와 맥락 분석 요청
    하네스->>전용모델: 답변 전략과 도구 호출 판단
    전용모델-->>하네스: 필요한 검색·쇼핑·예약 도구 선택
    하네스->>네이버서비스: 데이터 조회와 실행 연결
    네이버서비스-->>하네스: 결과와 출처 반환
    하네스-->>AI탭: 검증된 답변 구성
    AI탭-->>사용자: 답변 또는 추가 질문
```

- 멀티모달 쪽에서는 스마트렌즈가 대표 사례로 나왔음
  - 네이버는 2017년부터 이미지 검색을 선보였고, 그동안 쌓은 멀티모달 기술을 AI 검색에 더 깊게 붙이겠다는 입장임
  - 앞으로는 텍스트뿐 아니라 이미지 중심으로 정보를 이해하는 검색 서비스로 발전시키겠다고 밝힘
  - 최종 그림은 사용자가 사진이나 영상을 보여주면 AI가 장면을 이해하고 검색, 쇼핑, 예약 같은 행동까지 이어주는 멀티모달 검색 에이전트임

- 네이버가 자신감의 근거로 드는 건 한국어와 국내 서비스 데이터임
  - 글로벌 AI 서비스와 달리 네이버는 한글 정보와 국내 검색·쇼핑·지역 서비스 데이터를 20년 넘게 쌓아왔다는 점을 강조함
  - 한국 사용자 입장에서는 이게 꽤 현실적인 차별점임. 맛집, 예약, 쇼핑, 로컬 정보는 글로벌 모델이 아무리 똑똑해도 서비스 연결이 약하면 체감 품질이 떨어질 수밖에 없음

- 아직 안 밝힌 것도 많음
  - 음성 모델이나 AI 음성 비서 계획에 대해서는 “정해진 바 없다”고 했음
  - AI 서비스 유료화나 토큰 사용량 제한 계획도 아직 확정되지 않았다고 함
  - 결국 지금 단계의 네이버 AI탭은 수익화보다 검색 경험과 서비스 신뢰를 먼저 잡겠다는 모드에 가까움

---
## 기술 맥락

- 네이버가 고른 방향은 ‘범용 LLM 하나로 전부 처리’가 아니라 ‘서비스 전용 모델과 도구 호출 구조를 묶는 방식’이에요. 검색, 쇼핑, 플레이스, 예약처럼 이미 운영 중인 서비스가 많기 때문에, 모델이 말만 잘하는 것보다 어떤 데이터를 언제 가져올지 판단하는 게 더 중요하거든요.

- 하네스 엔지니어링이 중요한 이유는 AI 검색이 단순 답변창이 아니라 실행 인터페이스가 되기 때문이에요. 사용자가 예약 가능한 식당을 찾거나 상품을 비교하려면 모델 답변만으로 끝나지 않고, 실제 서비스 API와 데이터 소스가 안정적으로 연결돼야 해요.

- 경량 모델, MoE, sLM 분업 구조를 강조한 것도 비용 때문이에요. 검색 서비스는 호출량이 크기 때문에 매 요청마다 큰 모델을 돌리면 응답 속도와 인프라 비용이 바로 문제가 돼요. 네이버가 일부 컴포넌트 비용을 최대 3배 줄이고 속도를 2배 이상 개선했다고 말한 건 이 운영 부담을 의식한 결과예요.

- Clarify RL은 환각 방지 기술이라기보다 제품 UX에 가까운 선택이에요. 모호한 질문에 그럴듯한 답을 내는 모델은 데모에서는 멋져 보여도, 검색·예약·구매에서는 사고로 이어질 수 있거든요. 그래서 모르면 되묻는 행동 자체를 보상하는 게 실제 서비스에는 더 맞아요.

## 핵심 포인트

- AI탭 전용 경량 모델은 하이퍼클로바X 기반으로 만들었고, 네이버 데이터·서비스 시나리오·사용자 피드백을 설계에 반영함
- 명료성 강화학습, 베리파이어 강화학습, 자기정책 기반 증류 등을 적용해 모호한 질문에 되묻고 도구 호출 품질을 높이는 쪽으로 학습함
- 분업형 소형언어모델 구조로 일부 컴포넌트 장비 운영 비용을 최대 3배 줄이고 응답 속도는 2배 이상 개선했다고 밝힘
- 스마트렌즈를 중심으로 이미지 이해를 강화해 텍스트 검색을 넘어 멀티모달 검색 에이전트로 확장하려는 전략을 내놈

## 인사이트

네이버의 방향은 ‘가장 똑똑한 범용 모델’보다 ‘국내 서비스 데이터와 실행 도구를 제일 잘 엮는 모델’에 가깝다. 스펙을 공개하지 않은 건 아쉽지만, 비용·응답 속도·도구 호출을 전면에 세운 건 실제 서비스 운영 관점에선 꽤 현실적인 접근이다.
