최근 생성형 AI는 단순히 자연스러운 문장을 만들어내는 수준을 넘어, 다양한 형태의 데이터를 이해하고 그 위에서 스스로 판단하는 방향으로 빠르게 발전하고 있다. 이런 흐름 속에서 카카오가 공개한 Kanana-v-4b-hybrid 개발기는 단순한 모델 소개를 넘어, 앞으로의 AI가 어떤 방향으로 진화하고 있는지를 보여주는 중요한 사례라고 느껴졌다.
이 글이 인상적이었던 이유는 단순히 “더 성능이 좋은 멀티모달 모델을 만들었다”는 식의 설명에 머무르지 않고, 실제 사용자가 원하는 AI가 무엇인지부터 다시 짚고 있다는 점이다. 카카오는 현장에서 사용자가 더 이상 단순히 이미지를 읽어주는 AI가 아니라, 스스로 근거를 찾고, 생각하고, 검증한 뒤 답변하는 AI를 원하고 있다는 점을 확인했다고 설명한다. 그리고 바로 그 요구를 반영해 Kanana-v-4b-hybrid를 설계했다고 밝힌다.
이번 글에서는 Kanana-v-4b-hybrid가 어떤 문제의식에서 출발했는지, 어떤 구조적 특징을 가지는지, 그리고 기존 LLM과 비교했을 때 무엇이 다른지를 중심으로 정리해보려고 한다.
※ 본 글은 kakao tech 기술블로그의「“생각하고 답변하는” 카카오의 하이브리드 멀티모달 언어모델, Kanana-v-4b-hybrid 개발기」 글을 참고하여 작성하였습니다.
https://tech.kakao.com/posts/806
“생각하고 답변하는” 카카오의 하이브리드 멀티모달 언어모델, Kanana-v-4b-hybrid 개발기 - tech.kaka
한국형 하이브리드 멀티모달 언어모델, Kanana-v-4b-hybrid 안녕하세요...
tech.kakao.com
1. 문제의식
기존의 대규모 언어 모델은 자연스럽고 설득력 있는 문장을 생성하는 데 매우 뛰어난 성능을 보여준다. 하지만 실제 서비스나 개발 환경에서는 다음과 같은 문제가 반복적으로 발생한다.
대표적으로는 다음과 같은 문제가 있다.
- 문맥을 부분적으로만 반영하는 문제
- 이미지와 텍스트를 따로 해석하는 한계
- 그럴듯하지만 사실과 다른 답변 생성
- 내부 판단 과정 없이 결과만 출력되는 구조
예를 들어 사용자가 코드와 에러 로그를 함께 입력했다고 가정해보자.
query = "SELECT * FROM users WHERE id = " + user_input
그리고 함께 주어진 로그가 다음과 같다고 해보자.
Database error: syntax error near "' OR 1=1"
이때 기존 모델은 코드만 보고 “문자열 결합이 있네요” 정도로 말하거나, 로그만 보고 “SQL 문법 오류입니다”라고 답할 수 있다.
하지만 실제 중요한 포인트는 이것이 단순 문법 오류가 아니라 SQL Injection 가능성과 직접 연결될 수 있다는 점이다.
즉, 코드와 로그를 따로 보는 것이 아니라, 둘을 하나의 상황으로 묶어 이해해야 한다.
Kanana가 해결하려는 문제는 바로 이런 종류의 “부분 이해” 한계라고 볼 수 있다.
예를 들어 사용자가 코드와 에러 로그를 함께 입력했을 때, 모델이 코드만 보고 답하거나 로그만 따로 해석한다면 실제 문제의 원인을 정확히 짚지 못할 수 있다. 이건 단순한 성능 부족이라기보다, 모델이 입력을 충분히 이해하고 그 위에서 판단하는 구조를 갖추지 못했기 때문에 생기는 문제에 더 가깝다.
보안 측면에서도 비슷하다. LLM이 생성한 코드가 SQL Injection, Command Injection, 하드코딩된 비밀번호, 개인정보 로그 출력 같은 위험을 포함하고 있음에도, 사용자가 이를 그대로 실행하는 경우가 존재한다. 이 문제는 단순한 생성 모델이 가지는 구조적 한계를 보여준다.
결국 핵심 질문은 다음과 같다.
AI는 단순히 자연스럽게 말하는 것인가, 아니면 실제로 이해하고 판단하고 있는가.
Kanana-v-4b-hybrid는 바로 이 질문에서 출발한다.
2. Kanana-v-4b-hybrid의 핵심 방향
카카오 원문에서 드러나는 Kanana-v-4b-hybrid의 핵심은 크게 세 가지로 정리할 수 있다.
- 멀티모달 처리
- 하이브리드 구조
- Thinking 기반 추론
이 세 요소는 각각 독립적으로 존재하는 기능이 아니라, 하나의 흐름으로 연결되어 작동한다.
- 카카오는 실제 멀티모달 대화에서 사용자의 질문을 크게 두 가지 유형으로 나눈다.
- 하나는 OCR, 요약, 이미지 설명처럼 이미지 정보를 텍스트로 바꾸는 모달리티 간 정보변환 유형이고,
- 다른 하나는 여러 모달리티로 주어진 정보를 종합한 뒤 논리를 전개해 정확한 정답을 요구하는 추론 중심 유형이다.
Kanana-v-4b-hybrid는 이 둘을 따로 분리하지 않고, 하나의 모델 안에서 함께 처리할 수 있도록 설계되었다.
이 지점이 중요한 이유는, 실제 사용 환경에서는 이 두 유형이 분리되어 나타나지 않기 때문이다.
사용자는 처음엔 “이미지에서 텍스트만 읽어줘”라고 요청했다가, 다음 질문에서는 “그 합계가 맞는지 검산해줘”처럼 추론이 필요한 질문을 이어서 던질 수 있다. 즉, 실제 사용 환경은 이미 단순 인식과 추론이 섞여 있는 상태이고,
Kanana는 이 현실적인 흐름을 그대로 반영하고 있다.
3. Multimodal: 현실 데이터를 이해하기 위한 기본 조건
3-1. 왜 Multimodal이 필요한가
현실의 데이터는 대부분 단일 형태로 존재하지 않는다.
- 상품 정보와 이미지
- 뉴스 기사와 사진
- 코드와 실행 결과 및 로그
- 문서 이미지와 텍스트 질문
- 표, 차트, 계산 문제와 조건문
이런 데이터를 각각 분리해서 처리하는 방식은 실제 문제 해결에 한계를 만든다. 예를 들어 오류 상황을 분석할 때 코드만 보고 판단하는 것은 충분하지 않다. 실행 로그, 에러 메시지, 환경 정보까지 함께 고려해야 한다.
Kanana는 이러한 현실적인 문제를 반영하여, 다양한 입력을 하나의 맥락으로 통합하는 구조를 가진다.
3-2. 기존 모델과의 차이
기존 모델의 Multimodal 처리 방식은 다음과 같은 한계를 가진다.
- 이미지와 텍스트를 별도로 처리
- 단순 설명 수준에 머무름
- 맥락 간 연결 부족
반면 Kanana는 다음과 같은 수준의 통합을 목표로 한다.
- 이미지 속 상황과 객체 이해
- 텍스트와 이미지 간 관계 해석
- 복합 입력 기반 추론
- 입력에 흩어진 근거를 수집하고 조건을 적용해 결론 도출
이 차이는 단순한 기능 추가가 아니라, 이해 방식 자체의 변화라고 볼 수 있다.
3-3. 실제 예시 1: 이미지 + 텍스트 질의
예를 들어 사용자가 로그인 화면 이미지와 함께 다음과 같이 질문한다고 해보자.
이미지: 로그인 화면 캡처
텍스트: "로그인이 계속 실패합니다"
단순한 모델은 “로그인 실패 문제입니다” 정도의 반응을 보일 수 있다.
하지만 Multimodal 구조를 가진 모델이라면 다음과 같이 더 깊게 해석할 수 있다.
- 이미지 분석: 로그인 UI 구조 확인
- 텍스트 해석: 인증 실패 상황 파악
- 결합 추론:
- 비밀번호 오류
- 계정 잠김
- 서버 인증 문제
- CAPTCHA 또는 2차 인증 실패 가능성
즉, 단순 현상 설명이 아니라 원인 후보를 구조적으로 정리하는 방향으로 확장된다.
3-4. 실제 예시 2: 코드 + 설명 결합 분석
os.system(user_input)
함께 주어진 설명이 다음과 같다고 해보자.
사용자가 입력한 명령어를 그대로 실행합니다.
단순 코드 분석만 하면 “os.system을 사용했네요” 수준일 수 있다.
하지만 설명까지 결합하면 의미가 달라진다.
- 코드 분석: 위험 함수 사용
- 설명 분석: 입력 주체가 사용자
- 결합 판단: 사용자 입력 기반 명령 실행
- 보안 해석: Command Injection 가능성
즉, Multimodal은 이미지+텍스트만이 아니라, 코드+설명+로그처럼
서로 다른 정보 조각을 하나의 문제로 이해하는 방식까지 포함하는 관점으로 확장해서 볼 수 있다.
4. Kanana가 보여주는 시각적 추론: 단순 설명이 아니라 검증 가능한 결론
- Kanana 원문에서 가장 강조되는 부분 중 하나는 이 모델이 단순히 이미지를 설명하는 데서 멈추지 않고, “이미지에서 근거를 찾고 정답을 도출하는 시각적 추론”에 초점을 맞춘다는 점이다.
- 카카오는 영수증 합계 검산, 표 기반 조건 필터링, 차트 비교, 이미지 기반 수학 문제 풀이를 대표 예시로 제시한다.
- 이들 문제는 단순 OCR이나 이미지 캡션으로는 충분하지 않고, 정보 종합 → 조건 적용 → 계산/추론 → 검증의 흐름이 필요하다.
4-1. 실제 예시 3: 영수증 검산
- 카카오 원문에서 가장 직관적으로 제시되는 사례 중 하나가 바로 영수증 검산이다.
- 영수증은 언뜻 단순 OCR 문제처럼 보일 수 있다. 하지만 실제로 사용자가 원하는 것은 각 줄의 텍스트를 읽어주는 것이 아니라, 총액이나 부가세, 할인 적용 후 합계가 정말 맞는지를 확인하는 것이다.
- 이 문제를 풀기 위해서는 단순히 문자열을 읽는 것으로는 부족하다.
이 영수증에서 할인 적용 후 총액이 맞는지 확인해줘.
필요한 단계는 대략 다음과 같다.
- 항목별 금액 추출
- 할인 항목 추출
- 부가세 여부 확인
- 총액 계산
- 영수증 표기 총액과 비교
- 틀릴 경우 어느 항목에서 차이가 나는지 확인
- 이처럼 영수증 검산은 정보 종합 → 계산 → 검증의 흐름이 모두 필요하다. 원문에서도 Kanana가 이런 요청에서 항목을 구조화해 정리하고, 합계를 계산하고, 표기된 총액과 대조하며, 필요할 경우 한 번 더 계산을 확인하는 패턴을 보인다고 설명한다.
- 특히 영수증은 여러 줄에 금액과 할인, 부가세, 총액이 흩어져 있기 때문에 한 줄만 잘못 읽거나 빠뜨려도 결론이 달라질 수 있는데, Kanana는 이런 상황에서 단순 OCR을 넘어 검증 가능한 결론을 내리는 모델로서의 강점을 가진다고 소개된다.
- 이 사례는 Kanana가 단순히 “잘 읽는 모델”이 아니라, 근거를 모으고 계산하고 확인하는 모델이라는 점을 가장 잘 보여준다.
4-2. 실제 예시 4: 표 기반 조건 필터링
두 번째로 중요한 예시는 표와 차트 기반 추론이다. 표와 차트는 구조화된 정보처럼 보이지만, 실제 사용자의 질문은 단순 조회 수준에서 끝나지 않는 경우가 많다. 카카오 원문은 이를 설명하기 위해 이런 유형의 질문을 제시한다.
배송비 포함 최저가를 찾아줘.
단, 쿠폰 적용 불가 상품은 제외해줘.
이 질문은 단순한 최저가 검색이 아니다.
정답을 내기 위해서는 다음과 같은 과정이 필요하다.
- 표에서 상품별 가격 추출
- 배송비 포함 가격 계산
- 쿠폰 불가 상품 제외
- 남은 후보 중 최저가 비교
- 결론 제시
즉, 단순 표 읽기가 아니라 조건 필터링, 비교, 예외 처리가 동시에 필요한 문제다. 원문에서도 Kanana가 이런 상황에서 표를 그대로 읽는 것이 아니라, 문제의 입력으로 보고 조건을 적용하며 검증 가능한 결론을 만드는 형태로 강화되었다고 설명한다.
이 예시는 Kanana가 단순히 정보를 추출하는 것이 아니라,
사용자의 조건을 끝까지 보존한 채 답을 만들어내는 모델이라는 점을 잘 보여준다.
4-3. 실제 예시 5: 수학 문제 풀이
카카오 원문은 실제 수능 수학 문제 풀이 예시도 제시한다. 이 예시에서 중요한 것은 단순히 정답을 맞혔다는 사실이 아니라, 조건을 정리하고 계산을 단계적으로 수행한 뒤 다시 확인하는 흐름이 드러난다는 점이다.
카카오는 이런 패턴이 교육 상황에서 신뢰 가능한 튜터 경험으로 이어질 수 있다고 설명한다.
수학 문제에서 필요한 과정은 대체로 다음과 같다.
- 문제 조건 정리
- 필요한 식 도출
- 단계별 계산
- 중간값 활용
- 마지막 검산
즉, 수학 문제는 추론 구조를 가장 선명하게 보여주는 분야다.
그리고 이건 단순히 교육형 AI에만 의미가 있는 것이 아니라, 실제 개발 환경이나 분석 환경에도 시사점을 준다.
예를 들어 코드 생성 이후에도
- 생성된 코드가 정말 의도에 맞는지,
- 보안상 위험은 없는지,
- 실행 전 한 번 더 검토해야 하는지를 따지는 과정이 필요한데, 이 역시 넓게 보면 “문제 풀이형 검증 구조”라고 볼 수 있다.
5. Reflection: 추론한 뒤 다시 확인하는 능력
원문에서 특히 중요한 개념 중 하나는 Reflection, 즉 자기 점검이다.
카카오는 Kanana의 강점이 단순히 추론을 길게 하는 데 있는 것이 아니라, 스스로 자신의 추론을 다시 돌아보고 조건 누락이나 계산 실수가 없는지 확인하는 경향에 있다고 설명한다.
구체적으로는 1) 필요한 정보를 모으고, 2) 조건을 적용해 결론 후보를 만들고, 3) 마지막으로 계산 실수나 조건 누락 여부를 다시 확인한 뒤, 4) 최종 답변을 마무리하는 흐름이 관찰된다고 한다.
이게 왜 중요하냐면, 대부분의 오류는 완전히 엉뚱해서가 아니라 사소한 조건 하나를 놓치거나 계산을 한 단계 틀리는 방식으로 발생하기 때문이다.
- 영수증에서는 항목 누락이 문제이고,
표에서는 제외 조건 누락이 문제이며,
수학 문제에서는 단위나 계산 실수가 문제다. - Reflection은 이런 “자잘하지만 치명적인 실수”를 줄이는 내부 점검 루프라고 볼 수 있다.
- 즉, Kanana의 추론은 단순히 길게 말하는 것이 아니라, 결론의 신뢰도를 높이기 위한 자기 검토 구조라는 점에서 의미가 있다.
6. 한국어 질의에 대해 한국어로 생각한다는 것의 의미
- Kanana 원문에서 또 하나 중요한 포인트는 “한국어 질의에 대해 한국어로 추론한다”는 점이다.
- 카카오는 한국어 질의가 어려운 이유를, 단순히 언어가 한국어라서가 아니라 실제 질의에서 자주 등장하는 부정, 예외, 조건부 표현, 순서 지정, 우선순위 지정 등이 추론 과정에서 실수하기 쉬운 논리 요소를 포함하기 때문이라고 설명한다.
예를 들어 “~이 아닌 것만”, “단, 이 경우는 제외”, “먼저 A를 하고 그다음 B를 해줘” 같은 표현은 한 번만 잘못 처리해도 결론이 완전히 뒤집힐 수 있다.
예를 들어 다음 문장을 생각해볼 수 있다.
배송비 포함 최저가를 찾아줘.
단, 쿠폰 적용 불가 상품은 제외해줘.
이 문장을 영어식 단순 번역 흐름으로 처리하면,
- “최저가”에만 집중하거나
- “배송비 포함”을 누락하거나
- “쿠폰 적용 불가 제외” 조건을 잊어버릴 가능성이 있다.
반면 한국어 문장 그대로 조건을 분해하면 다음처럼 구조화할 수 있다.
- 비교 기준: 배송비 포함
- 제외 조건: 쿠폰 적용 불가 상품 제외
- 목표: 최저가 찾기
즉, 한국어 조건을 끝까지 보존한 채 추론하는 것이 핵심이다.
이건 법률 문장, 계약 문서, 서비스 정책 문구, 과제 지시문 같은 분야에서도 매우 중요하게 작용한다.
7. Hybrid 구조: 추론과 비추론을 하나의 모델 안에서 공존시키는 구조
- Kanana-v-4b-hybrid가 하이브리드인 이유는 실제 사용자 요청이 항상 같은 깊이의 사고를 요구하지 않기 때문이다. 카카오는 실제 멀티모달 대화에서 요청의 성격이 한 세션 안에서도 빠르게 바뀐다고 설명한다.
- 예를 들어 사용자가 처음에는 “이미지에서 텍스트만 읽어줘”라고 요청했다가, 다음 질문에서는 “내가 제시한 조건을 만족하는 정보만 더 자세히 설명해줘”처럼 복잡한 추론이 필요한 질문을 할 수 있다는 것이다.
원문은 영수증 예시를 통해 이를 매우 직관적으로 보여준다.
- “항목과 금액만 읽어줘”
→ 비추론형 요청 - “할인 적용 후 합계가 맞는지 검산해줘”
→ 추론형 요청 - “결론만 한 줄로 정리해줘”
→ 다시 비추론형 요청
- 이런 요청을 각기 다른 모델로 나눠 처리할 수도 있지만, 카카오는 그렇게 하면 시스템 복잡도가 커지고 응답 톤과 정책의 일관성이 깨질 수 있다고 본다. 그래서 하나의 모델 안에서 추론형·비추론형 응답을 모두 안정적으로 생성하도록 설계했다.
- 또한 필요할 때만 더 깊게 추론하고, 그렇지 않을 때는 불필요한 연산을 줄여 비용과 품질 사이의 균형을 유연하게 맞추는 방향을 택했다고 설명한다.
즉, 이 하이브리드 구조는 단순히 “둘 다 한다”는 뜻이 아니라, 실제 서비스 운영을 고려한 설계 선택이라고 볼 수 있다.
8. Hybrid 구조를 코드 검증 흐름에 비유해 보면
이걸 코드 검증 흐름으로 바꿔보면 더 직관적이다.
실제 예시 6: 단계별 처리 흐름
입력이 다음과 같다고 해보자.
이 코드 안전한가요?
그리고 함께 코드가 주어진다.
password = "1234"
os.system("rm -rf " + user_input)
이 상황을 하이브리드 구조로 처리하면 다음과 같은 단계가 가능하다.
1단계: 입력 해석
- 사용자의 질문 의도 파악
- 코드 블록 추출
2단계: 특징 추출
- 하드코딩 비밀번호 탐지
- 위험한 명령 실행 탐지
- 사용자 입력 연결 여부 탐지
3단계: 추론
- 이 코드가 실제로 어떤 위험을 가지는가
- 시스템 파일 삭제 가능성이 있는가
- 사용자 입력 기반 명령 주입이 가능한가
4단계: 결과 생성
[HIGH RISK]
Risk Score: 90
탐지된 위험 요소:
- 하드코딩 비밀번호
- 위험한 시스템 명령 실행
- 사용자 입력 기반 명령 결합
영향:
- 시스템 파일 삭제 가능
- 계정 정보 노출 가능
권장 조치:
- 입력 검증 추가
- 명령 실행 제한
- 비밀번호 환경변수 분리
이건 단순한 코드 설명이 아니라, 이해 → 판단 → 설명 → 통제 흐름에 가깝다.
9. Thinking 기반 추론: 왜 이런 결과가 나왔는지 설명하는 구조
기존 LLM의 동작은 단순화하면 다음과 같이 볼 수 있다.
입력 → 확률 기반 텍스트 생성 → 출력
반면 Kanana가 지향하는 구조는 다음과 같다.
입력 → 의미 이해 → 내부 추론 → 결과 생성
- 카카오는 이를 위해 <think> ... </think> 블록을 포함한 구조화된 Chat Template을 설계했다고 설명한다. 이 방식은 생각과 답변의 경계를 분리해, 내부적으로는 추론을 유지하면서도 사용자에게는 정제된 최종 답변만 제공할 수 있게 한다.
- 즉, 추론은 하되, 그 추론을 어떤 방식으로 노출할지는 시스템이 제어할 수 있게 만든 것이다.
이 구조를 코드 질문에 적용해보면 다음과 같다.
실제 예시 7: 단순 질문
입력:
이 코드 문제 있어?
코드:
query = "SELECT * FROM users WHERE id = " + user_input
기존 모델은
“문제가 있을 수 있습니다” 정도의 답변을 할 수 있다.
하지만 추론 기반 구조라면 다음처럼 더 설명 가능하게 답할 수 있다.
문제:
- 사용자 입력 검증 없음
이유:
- SQL 문자열이 직접 결합됨
영향:
- SQL Injection 가능
- 데이터베이스 정보 노출 가능
대응:
- Prepared Statement 사용
- 입력 타입 검증
즉, 결과만이 아니라 이유와 영향, 대응책까지 이어지는 구조가 된다.
10. Agentic Coding 환경에서의 중요성
Kanana의 구조는 특히 Agentic Coding 환경에서 중요한 의미를 가진다.
Agentic Coding 환경에서는 다음과 같은 흐름이 흔하다.
사용자 입력 → LLM 코드 생성 → 실행
이 과정에서 가장 큰 문제는 검증 없는 실행이다.
실제 위험 사례는 다음과 같다.
- SQL Injection 코드 생성
- os.system() 같은 위험한 명령 포함
- API Key, 비밀번호 하드코딩
- 로그에 개인정보 출력
이러한 코드가 생성되고, 사용자가 이를 그대로 실행하면 실제 보안 문제가 발생할 수 있다.
10-1. 실제 예시 8: 검증 없는 실행의 위험
def save_log(user):
print("User email:", user.email)
겉보기에는 단순 로그 코드다.
하지만 개인정보 관점에서 보면 다음과 같이 해석할 수 있다.
[WARNING]
위험:
- 개인정보 출력
유형:
- 이메일 노출
영향:
- 로그 기반 개인정보 유출 가능
대응:
- 마스킹 처리
- 민감정보 로그 제외
이런 판단은 단순 코드 생성 모델보다, 입력의 의미와 맥락을 이해하고 위험을 설명할 수 있는 구조에서 더 잘 수행될 가능성이 크다.
10-2. Kanana 구조와의 연결
Kanana의 구조는 이런 문제를 해결할 수 있는 방향을 제시한다.
- Multimodal
→ 코드 + 로그 + 설명 + 실행 결과 통합 분석 - Hybrid
→ 입력 분석, 보안 검증, 결과 생성 같은 역할 분리 가능 - Thinking
→ 실행 전 위험 판단 가능
단순히 코드를 만들어주는 AI가 아니라, 코드를 생성하고, 분석하고, 설명하고, 승인 전에 멈출 수 있는 AI가 필요하기 때문이다.
11. 학습 전략: 왜 이 모델이 단순한 “기능 추가”가 아닌가
Kanana를 더 흥미롭게 만드는 부분은, 이런 구조가 단순 아이디어 수준이 아니라 단계적 학습 전략 위에서 만들어졌다는 점이다. 카카오는 학습 과정을 크게 네 단계로 설명한다.
- 기초 멀티모달 학습
- Long CoT SFT
- 오프라인 강화학습
- 온라인 강화학습
- 기초 멀티모달 학습 단계에서는 다양한 멀티모달 태스크를 수행하는 기본기를 익히고, 시스템 프롬프트까지 포함한 지시 이행 능력을 강화했다. 또한 이 단계부터 <think> ... </think> 구조를 적용해 생각과 답변을 분리하도록 학습했다.
- Long CoT SFT 단계에서는 복잡한 문제를 여러 단계로 나눠 푸는 방법 자체를 학습했다. 이때 중요한 것은 단순히 정답 데이터가 아니라, 올바른 추론 형식과 논리 전개 습관을 가진 고품질 사고 과정 데이터를 학습시키는 것이었다.
- 공개 데이터만으로는 한계가 있어 합성 데이터를 적극 활용했고, 형식 준수 여부, 정답 여부, 추론 결함 여부 등을 점검해 저품질 샘플을 제거했다고 설명한다.
- 그 다음 오프라인 강화학습에서는 선호 응답과 비선호 응답 간의 품질 격차를 학습 신호로 활용했고, 온라인 강화학습에서는 RLVR 기반으로 검증 가능한 정답 여부를 보상으로 사용해 추론 능력을 고도화했다.
즉, Kanana는 처음부터 “똑똑한 모델”이 아니라, 추론 형식 → 추론 습관 → 선호 학습 → 검증 보상 최적화를 단계적으로 쌓아 올린 모델이라고 보는 것이 더 정확하다.
12. 한 가지 더: 앞으로의 확장 방향이 보여주는 것
플러스 알파로 꼭 넣으면 좋은 포인트는, 원문 마지막에 제시된 앞으로의 확장 방향이다. 카카오는 앞으로의 목표로 다음 세 가지를 제시한다.
- 멀티 이미지·비디오 입력 성능 향상
- 멀티모달 외부 함수 호출 기능 지원
- 자동 추론 기능 지원
- 이 세 가지는 매우 중요하다.
왜냐하면 이것이 단순한 모델 성능 경쟁을 넘어, AI가 실제 서비스 워크플로우의 일부가 되는 방향을 보여주기 때문이다. - 특히 외부 함수 호출은 자연어 응답만이 아니라 구조화된 출력을 기반으로 실제 작업을 호출하고, 그 결과를 다시 근거로 삼아 추론을 이어가는 구조를 의미한다.
- 카카오는 이것이 모델을 단순 대화 엔진이 아니라 서비스 워크플로우의 구성 요소로 동작하게 만드는 핵심 인터페이스라고 설명한다.
미래의 AI는 단순히 답변만 잘하는 것이 아니라,
코드를 생성하고
필요한 도구를 호출하고
결과를 다시 해석하고
위험을 판단하고
사용자 승인 하에 실행하는 방향으로 갈 가능성이 크다.
13. 종합 정리
Kanana-v-4b-hybrid는 단순한 모델 개선이 아니라, AI 설계 방식 자체의 변화를 보여주는 사례이다.
핵심 변화는 다음과 같다.
텍스트 중심 → 멀티모달
단일 모델 → 구조 기반 시스템
생성 중심 → 추론 중심
설명 중심 → 검증 가능한 결론 중심
한국어 출력 → 한국어 조건 보존형 추론
단일 응답 모드 → 추론/비추론 공존형 하이브리드 응답
이러한 변화는 AI를 단순한 도구가 아니라, 실제 문제 해결 시스템으로 확장시키는 방향이라고 볼 수 있다.
14. 마무리
앞으로의 AI는 더 자연스럽게 말하는 것이 아니라, 더 정확하게 이해하고 판단하는 방향으로 발전할 것이다.
- Kanana-v-4b-hybrid는 바로 그 변화의 출발점에 있는 구조라고 볼 수 있다.
- 영수증 검산, 표 조건 필터링, 수학 문제 풀이, 한국어 질의 보존, 추론/비추론 공존, 단계적 학습 전략, 그리고 앞으로의 함수 호출 확장 방향까지 살펴보면, 이 모델은 단순한 멀티모달 모델이 아니라 “이해–추론–검증–운영”을 함께 고려한 다음 세대 AI 구조를 보여준다고 할 수 있다.
- 카카오는 이 모델을 통해 한국어를 자연스럽게 이해·추론하면서도, 필요 없을 때는 빠르게 비추론 모드로 응답할 수 있는 하이브리드 멀티모달 언어 모델을 제시했다고 설명한다.
한 줄 정리
Kanana-v-4b-hybrid는 생성 중심 AI를 넘어, 멀티모달 이해와 추론, 자기점검,
그리고 운영 안정성까지 함께 고려하는 다음 세대 AI 구조를 보여주는 모델이다.
'PRISM > 기술 블로그' 카테고리의 다른 글
| [기술 블로그] 음성 AI 모델을 프로덕션에 올리기까지: Kanana-O 서빙 최적화 여정 (0) | 2026.05.22 |
|---|---|
| [기술 블로그] 누적식 보안의 위험: 취약점 클리닝 서비스에서 발견된 RCE 사례 (0) | 2026.05.13 |
| [기술 블로그] 뱅크샐러드에서 합법적으로 Vibe Coding 하는 법 (1) | 2026.05.07 |
| [기술 블로그] 개인화 추천 시스템 1편 - 유저의 행동은 “언어”일까? : Collaborative Embedding 구축기 (feat. Knowledge Distillation) (1) | 2026.04.02 |
| [기술 블로그] 흩어져 있는 AI 자산, ‘MCP stdio’로 헤쳐모여! (0) | 2026.03.26 |