[KANANA 429] Kanana-o API로 만든 AI 독서 친구, “다독다독” 개발기

Kanana-o API로 만든 AI 독서 친구, “다독다독” 개발기

발달장애 아동이 그림책을 보고, 듣고, 말하며 감정을 이해할 수 있도록 돕는 AI 독서 친구 데모

• Repository: https://github.com/mk-isos/dadokdadok-kanana
• Demo: https://dadokdadok-kanana.vercel.app

다독다독 × Kanana-o

• Youtube (시연영상) : https://youtu.be/eYhslwwuR5M

 

1. 시작하며

이번에 Kanana-o API 베타를 활용해 “다독다독 × Kanana-o” 라는 AI 독서 친구 데모를 만들어보았다.

처음에는 단순히 “Kanana API로 무언가 만들어보자” 정도의 생각이었다. 그런데 Kanana-o가 텍스트만 처리하는 모델이 아니라 이미지와 음성을 함께 다룰 수 있는 옴니모달 모델이라는 점을 보면서 단순 챗봇보다는 보고, 듣고, 말하는 경험이 필요한 서비스에 적용해보고 싶어졌다.

 

그래서 선택한 주제가 그림책, 동화책 서비스였는데 친구의 아이디어로 발달장애 아동을 위한 그림책 독서 지원 서비스를 만들었다.

서비스 이름은 다독다독으로 정했다. 이름에는 두 가지 의미를 담았다.

첫 번째는 책을 많이 읽는다는 뜻의 다독.
두 번째는 아이의 마음을 다정하게 다독여준다는 뜻의 다독다독.

 

즉, 다독다독은 단순히 책을 읽어주는 앱이 아니라 아이가 그림책을 보며 내용을 듣고, 질문에 답하고, Kanana와 대화하면서 책 속 감정과 상황을 조금 더 쉽게 이해하도록 돕는 AI 독서 친구를 목표로 한다.

2. 왜 이 주제를 선택했나

처음 문제의식은 “책을 읽을 수 있다고 해서 반드시 이해하는 것은 아니다”라는 점에서 출발했다.

발달장애 아동에게 독서는 단순히 글자를 읽는 활동이 아니라 인물의 감정, 사건의 원인과 결과, 사회적 관계, 상황 판단을 함께 배우는 과정이라고 생각했다. 그런데 일반 그림책이나 오디오북은 대부분 “읽어주기”에 초점이 맞춰져 있다. 아이가 왜 인물이 슬픈지 어떤 상황에서 어떤 감정을 느끼는지 그 감정을 어떻게 표현할 수 있는지까지 반복적으로 도와주는 서비스는 많지 않았다.

초기 사업계획서에서도 기존 전자책과 오디오북은 책을 읽어주는 기능에 집중되어 있고 발달장애 아동의 감정 이해와 표현 활동을 충분히 지원하지 못한다는 점을 문제로 정리했다. 또한 쉬운 글 서비스는 문장 단순화에 머무르는 경우가 많고 특수교육 교재는 보호자나 교사의 직접 설명에 의존하기 때문에 반복성과 확장성이 낮다는 한계가 있다고 보았다.

그래서 다독다독에서는 단순한 “읽어주기”가 아니라 다음 흐름을 만들고 싶었다.

그림책을 본다
→ 어려운 문장을 아이 수준에 맞게 바꾼다
→ 이야기를 듣는다
→ Kanana가 질문한다
→ 아이가 말로 답한다
→ Kanana가 피드백하고 다음 질문을 이어간다
→ 보호자가 리포트를 확인한다

 

이 흐름이 Kanana-o의 옴니모달 특성과 잘 맞는다고 판단했다.

3. 왜 Kanana-o였나

Kanana-o 공식 문서에 따르면 Kanana-1.5-o-9.8B-instruct-2602는 텍스트, 이미지, 오디오 입력을 처리하고 텍스트 또는 오디오로 출력할 수 있는 옴니모달 모델이다. 문서에는 대표 사용 사례로 이미지 캡셔닝, 문서 이해, OCR 기반 추론, 음성 인식, TTS, 멀티턴 대화, 옴니모달 instruction following 등이 제시되어 있다.

 

이 부분이 다독다독과 잘 맞았다. 그림책 독서 지원 서비스에서 필요한 것은 단순 텍스트 생성이 아니다.

그림책 페이지를 보고 이미지 속 원문을 읽고 아이 수준에 맞게 쉽게 바꾸고 음성으로 들려주고 아이의 답변을 듣고 다시 피드백하는 흐름이 필요하다.

Kanana-o는 공식 문서에서 텍스트/이미지/오디오 입력과 텍스트/오디오 출력을 지원한다고 설명되어 있고 이미지와 오디오를 Base64로 입력하는 방식과 음성 응답 생성 방식도 안내되어 있다.

그래서 이번 프로젝트에서는 Kanana-o를 단순 생성 모델이 아니라 AI 독서 친구의 핵심 엔진처럼 사용해보고자 했다.

4. 완성된 서비스: 다독다독

다독다독은 현재 Vercel에 배포된 Next.js 기반 웹앱이다.

사용자는 자신의 Kanana API Key를 입력하고 준비된 그림책 중 하나를 선택해 데모를 체험할 수 있다. 

1. 책 고르기: 토끼 이야기, 원숭이 이야기, 하율 이야기 중 선택
2. 그림 보기: 원문 OCR 확인 및 필요 시 기초/표준/심화 수준으로 문장 변환
3. 이야기 듣기: 원문 또는 쉬운 글을 음성으로 듣기
4. 말하기: Kanana 질문에 아이가 녹음 또는 텍스트로 답하고, Kanana가 피드백과 다음 질문 제공
5. 리포트: 대화 기반 보호자 관찰 리포트 생성

5. 데모에 들어간 그림책 3권

데모에서는 총 3권의 그림책을 준비했다. (ai로 생성된 이야기와 이미지)

 

첫 번째는 토끼 이야기다.

비 오는 날, 토끼가 친구들이 자신을 두고 간 줄 알고 외로워하는 내용이다. 핵심 감정은 슬픔, 외로움, 친구 관계다.

 

두 번째는 원숭이 이야기다.

원숭이가 덩굴을 타며 친구들의 응원을 받고 신나게 도전하는 이야기다. 핵심 감정은 기쁨, 자신감, 도전, 응원이다.

 

세 번째는 하율 이야기다.

발표를 앞두고 걱정하는 하율이가 엄마의 응원을 듣고 다시 용기를 내는 이야기다. 핵심 감정은 걱정, 긴장, 위로, 용기, 노력이다.

처음에는 토끼와 원숭이 이야기만 있었는데, 두 이야기는 원문 자체가 비교적 쉬워서 “어려운 문장을 아이 수준에 맞게 바꾼다”는 기능이 충분히 드러나지 않았다. 그래서 일부러 문장이 조금 더 길고 감정도 복합적인 하율 이야기를 추가했다.

이 과정에서 서비스 방향도 더 명확해졌다.

다독다독은 단순히 쉬운 이야기를 보여주는 앱이 아니라 조금 어려운 그림책도 아이의 이해 수준에 맞게 다시 다듬어주는 앱이어야 한다고 생각했다.

6. 사용자 플로우 설계

처음 만든 화면은 기능을 한 번에 많이 보여주는 웹앱 형태에 가까웠다. 그런데 발달장애 아동이 사용하는 서비스를 생각하면 한 화면에 너무 많은 글과 버튼이 있는 구조는 적합하지 않다고 판단했다.

그래서 최종적으로는 앱처럼 단계별로 진행되는 구조로 바꿨다.

1. 책 고르기
2. 그림 보기
3. 이야기 듣기
4. 말하기
5. 리포트

 

이 단계 구분은 단순 UI 정리가 아니라, 아이의 실제 독서 흐름을 기준으로 나눈 것이다.

Step 1. 책 고르기

아이가 오늘 읽을 그림책을 고른다.
현재는 3권의 샘플 그림책이 있고 각 책마다 감정 테마가 다르다.

Step 2. 그림 보기

 

그림책 페이지를 먼저 본다. 원문이 너무 어렵다면 기초, 표준, 심화 수준으로 문장을 바꿀 수 있다.

여기서 중요한 것은 “무조건 쉬운 글로 바꾸기”가 아니라 원문을 먼저 보여주고 필요할 때만 쉽게 바꾸는 구조로 설계했다는 점이다.

Step 3. 이야기 듣기

 

글을 읽기 어려운 아이를 위해 원문 또는 쉬운 글을 음성으로 들을 수 있게 했다.
처음에는 이 단계에도 Kanana 질문을 넣었지만 나중에 역할을 분리했다.

Step 3은 듣기에 집중하고 질문과 대화는 Step 4에서 진행하는 것이 더 자연스러웠다.

Step 4. 말하기

 

Kanana가 그림책 내용에 대해 질문한다.
아이는 큰 마이크 버튼을 눌러 답하거나 텍스트로 답할 수 있다. 이후 Kanana가 아이의 답변을 바탕으로 짧은 피드백과 다음 질문을 제공한다.

여기서 핵심은 한 번의 질문으로 끝나지 않고 여러 턴의 대화가 이어진다는 점이다.

Step 5. 리포트

 

대화가 끝나면 보호자용 리포트를 생성한다.
이 리포트는 진단이나 치료 목적이 아니라 오늘 아이가 어떤 내용을 이해했고 어떤 질문에서 도움이 필요했는지 관찰하는 참고 자료다.

README에도 이 서비스의 피드백과 리포트는 독서 활동 관찰을 돕기 위한 참고 자료이며 진단이나 치료 효과를 의미하지 않는다고 명시했다.

7. Kanana API를 어떻게 연결했나

이번 프로젝트에서 Kanana API는 크게 다섯 가지 action으로 나누어 사용했다.

analyze_story
adapt_level_text
conversation_turn
parent_report
tts

 

프로젝트 구조상 사용자가 버튼을 누르면 page.tsx의 함수가 실행되고 클라이언트 래퍼인 lib/kanana.ts를 거쳐 /api/kanana/route.ts로 요청이 전달된다. 이후 route handler에서 Kanana 외부 엔드포인트를 호출하고 응답을 파싱한 뒤 다시 page.tsx의 state에 저장해 UI에 반영하는 흐름이다.

 

전체 흐름을 단순화하면 다음과 같다.

사용자 클릭
→ page.tsx 핸들러 실행
→ lib/kanana.ts API 래퍼 호출
→ /api/kanana/route.ts
→ Kanana API 호출
→ JSON 응답 파싱
→ React state 저장
→ 화면 업데이트

 

8. API Action별 구현 방식

8.1 그림책 분석: analyze_story

그림책 분석은 Step 2에서 사용한다.

사용자가 “이야기 살펴보기”를 누르면 그림책 이미지와 아동 수준, 보정 텍스트를 Kanana로 보낸다. Kanana는 이미지 속 텍스트와 장면을 분석해 원문, 장면 설명, 쉬운 글, 감정, 감정 이유, 아이에게 던질 질문을 생성한다.

 

analyze_story는 이미지 Base64, 아동 수준, 보정 텍스트를 입력으로 받고 extractedText, sceneDescription, easyText, emotion, childQuestion 등을 출력하도록 설계했다.

이 기능은 Kanana-o의 이미지 이해와 OCR 기반 추론을 활용한 부분이다.

8.2 수준별 문장 변환: adapt_level_text

이 기능은 다독다독에서 가장 중요하게 생각한 기능 중 하나다.

기존 그림책 원문은 아이에게 어려울 수 있다. 그래서 원문을 그대로 보여주되 필요하면 기초, 표준, 심화 수준으로 바꿀 수 있게 했다.

 

예를 들어 하율 이야기의 원문은 다음처럼 조금 길다.

하율이는 열심히 준비했지만, 실수할까 봐 걱정이 되었어요.
발표 연습을 할 때마다 목소리가 작아지고, 손이 떨렸어요.

 

이 문장을 기초 수준으로 바꾸면 이런 형태가 된다.

하율이는 발표가 걱정됐어요.
실수할까 봐 무서웠어요.

 

표준 수준에서는 감정과 이유를 조금 더 연결한다.

하율이는 발표를 열심히 준비했어요.
하지만 실수할까 봐 걱정이 되었어요.

 

심화 수준에서는 원문의 의미를 최대한 유지하면서 상황과 감정을 함께 설명한다.

하율이는 발표를 잘하고 싶어서 열심히 연습했어요.
하지만 실수할까 봐 마음이 불안했고, 목소리도 작아졌어요.

 

이렇게 수준별로 문장을 바꾸면 같은 그림책도 아이의 이해 수준에 맞게 다르게 접근할 수 있다.

adapt_level_text는 원문, 책 메타데이터, 목표 수준인 basic | standard | advanced를 입력으로 받고 해당 수준에 맞는 adaptedText를 출력한다.

8.3 멀티턴 대화: conversation_turn

Step 4에서는 아이가 Kanana와 직접 대화한다.

처음에는 “질문 → 답변 → 피드백” 한 번으로 끝나는 구조였다. 그런데 실제 독서 활동은 한 번의 질문으로 끝나지 않는다. 보호자나 교사는 아이의 답변을 듣고 다시 짧게 피드백하고 다음 질문으로 자연스럽게 이어간다.

 

그래서 conversation_turn 구조를 만들었다.

입력으로는 현재 질문, 대화 이력, 아이 답변 텍스트 또는 음성, 선택한 읽기 수준, 그림책 분석 결과 등이 들어간다.

출력으로는 feedbackForChild, nextQuestion, shouldContinue, parentObservation이 나온다.

대화 예시는 이런 식이다.

Kanana:
토끼는 왜 슬펐을까?

아이:
친구들이 없어져서요.

Kanana:
맞아. 토끼는 친구들이 없어진 줄 알고 슬펐어.
친구들이 돌아오면 토끼는 어떤 마음일까?

 

여기서 중요한 원칙은 다음과 같았다.

• 한 번에 질문은 하나만 한다.
• 피드백은 짧게 한다.
• 아이의 답변을 비난하지 않는다.
• “틀렸어”라고 말하지 않는다.
• 정답 맞히기가 아니라 감정 이해를 돕는다.
• 대화가 너무 길어지지 않게 턴 수를 제한한다.

프로젝트 정리 자료에서도 대화 프롬프트에는 현재 질문, 아이 답변, 이전 대화, 턴 수를 포함해 문맥을 유지하고, 질문 길이를 짧게 제한하도록 설계했다고 정리했다.

8.4 보호자 리포트: parent_report

대화가 끝나면 보호자 리포트를 생성한다.

리포트에는 다음 내용을 포함했다.

• 오늘 읽은 장면
• 아이가 말한 내용 요약
• 잘한 점
• 어려웠던 점
• 다음에 함께 해볼 질문
• 주의 문구

중요한 것은 이 리포트를 “평가”처럼 만들지 않는 것이었다.

발달장애 아동 대상 서비스에서는 표현이 매우 중요하다고 느꼈다. “감정을 정확히 판별했다”, “장애 수준을 분석했다”, “치료 효과가 있다” 같은 표현은 피해야 한다. 대신 “독서 활동 관찰을 돕는다”, “다음 질문을 준비할 수 있게 한다”, “감정 이해 연습을 돕는다”는 식으로 표현해야 한다.

README에도 이 프로젝트는 의료/치료 목적이 아닌 독서 활동 관찰 지원 도구라고 정리했다.

8.5 음성 출력: tts

다독다독에서 음성은 핵심 경험이다.

처음에는 브라우저의 SpeechSynthesis만 사용해도 충분할 것 같았다. 그런데 실제로 들어보니 “동화책을 읽어주는 선생님” 같은 느낌을 만들려면 한국어 억양과 감정 표현이 중요했다.

그래서 우선 Kanana TTS를 사용하고 실패하면 브라우저 SpeechSynthesis로 fallback하는 구조를 만들었다.

읽어주기 버튼을 누르면 requestTts()를 통해 tts action이 호출되고 Kanana TTS가 가능한 경우 해당 음성을 재생한다. 실패하거나 응답이 없으면 SpeechSynthesis로 대체한다. 프로젝트 정리 자료에서도 TTS/읽어주기는 우선 Kanana TTS를 요청하고 실패 또는 무음일 때 브라우저 SpeechSynthesis로 자동 대체하는 구조라고 정리했다.

9. 음성 입력은 어떻게 처리했나

아이의 답변은 크게 두 가지 방식으로 받는다.

첫 번째는 마이크 녹음이다. 브라우저의 MediaRecorder를 사용해 아이의 목소리를 audio blob으로 저장한다.

두 번째는 음성 인식 fallback이다. SpeechRecognition을 사용해 아이가 말한 내용을 텍스트 초안으로 보여준다. 이 텍스트는 보호자나 사용자가 수정할 수 있다.

 

프로젝트 정리 자료에 음성 기능은 브라우저 기본 기능과 Kanana API를 함께 사용하는 하이브리드 구조로 설계했다. MediaRecorder는 아이 목소리를 오디오 파일로 녹음하고 SpeechRecognition은 실시간 텍스트 초안을 만들며 SpeechSynthesis는 Kanana TTS 실패 시 읽어주기 fallback 역할을 한다.

이 구조를 사용한 이유는 안정성 때문이다.

아이 대상 서비스는 “작동하지 않는 순간” UX가 크게 무너진다. Kanana API가 실패하거나 브라우저 음성 인식이 지원되지 않는 환경에서도 최소한 다음 단계로 넘어갈 수 있어야 한다.

그래서 다음과 같은 fallback 구조를 넣었다.

Kanana TTS 실패
→ SpeechSynthesis로 읽기

Kanana 음성 이해 실패
→ Web Speech API 또는 텍스트 입력 사용

Kanana 분석 실패
→ sampleStory fallback 데이터 사용

 

이 fallback 구조 덕분에 API 응답이 불안정하더라도 데모 전체 흐름이 끊기지 않도록 만들 수 있었다.

 

10. 기술 스택

기술 스택은 복잡하게 가져가지 않았다.

처음에는 Spring Boot, MySQL, React 구조도 생각했지만 이번 프로젝트의 목적은 완성형 서비스 운영이 아니라 Kanana-o API를 활용한 빠른 MVP 검증이었다.

그래서 최종적으로는 다음 구조를 선택했다.

Next.js App Router
TypeScript
Tailwind CSS
React state + localStorage
MediaRecorder
Web Speech API
SpeechSynthesis
Kanana-o API

 

README 기준 기술 스택도 Next.js App Router, TypeScript, Tailwind CSS v4, React state와 localStorage, MediaRecorder, Web Speech API, SpeechSynthesis로 정리되어 있다.

 

사용자 API Key는 서버 DB에 저장하지 않았다. 사용자가 직접 입력한 API Key는 브라우저 localStorage에만 저장한다. 이 방식은 베타 API 테스트 단계에서 서버 비용을 줄이고 각 사용자가 자신의 키로 직접 테스트할 수 있게 하기 위한 선택이었다.

11. 프로젝트 구조

프로젝트는 크게 다음 폴더로 나누었다.

src/
  app/          # Next.js 페이지와 API 라우트
  components/   # Step UI와 재사용 컴포넌트
  hooks/        # 녹음, 음성 인식, 음성 출력, localStorage 훅
  lib/          # Kanana API, prompt, 타입, 유틸
  data/         # 그림책 샘플 데이터
docs/           # 기술 문서

 

개발하면서 느낀 점은 AI 서비스일수록 코드를 단순히 화면 중심으로만 짜면 금방 복잡해진다는 것이다.

 

그래서 기능을 분리했다.

components에는 화면 UI를 두고 hooks에는 마이크, 음성 인식, 음성 출력 같은 브라우저 기능을 분리했다.
lib에는 Kanana API 호출, prompt, 타입, JSON 파싱, 오디오 유틸을 모았다.
data에는 토끼, 원숭이, 하율 이야기와 fallback 데이터를 넣었다.

프로젝트 정리 자료에서도 app은 화면과 API 엔드포인트, components는 재사용 UI, hooks는 브라우저 기능 로직, lib는 도메인/API 공통 로직, data는 샘플 콘텐츠와 fallback 데이터 역할로 나뉘어 있다고 정리했다.

12. Prompt Engineering에서 신경 쓴 점

이번 프로젝트에서 prompt는 단순히 “쉬운 글로 바꿔줘”가 아니었다.

다음 원칙을 계속 넣었다.

• 발달장애 아동이 이해할 수 있도록 짧은 문장 사용
• 어려운 단어 피하기
• 감정과 이유를 원인-결과로 설명
• 한 번에 질문은 하나만 하기
• 아이의 답변을 비난하지 않기
• “틀렸어”라고 말하지 않기
• 진단, 치료, 평가, 점수화 표현 금지
• 반드시 JSON만 반환

특히 JSON 응답을 강제한 이유는 UI에서 안정적으로 파싱하기 위해서다. 모델이 마크다운 설명이나 불필요한 문장을 섞어 보내면 화면 업데이트가 불안정해질 수 있다. 서버가 모델 응답을 parseJsonFromText로 바로 파싱하고 각 라우트 핸들러가 특정 타입의 결과를 기대하기 때문에 JSON 응답 강제가 필요하다고 생각했다.

 

프롬프트 구조는 다음처럼 나눴다.

buildStoryAnalysisPrompt
buildLevelAdaptationPrompt
buildConversationTurnPrompt
buildParentReportPrompt
buildTtsPrompt

 

기능별로 프롬프트를 분리하니 수정과 실험이 훨씬 쉬웠다.

13. 개발하면서 가장 많이 수정한 부분

가장 많이 바꾼 부분은 UI/UX였다.

처음에는 기능을 많이 보여주는 데 집중했다. 그런데 실제로 화면을 보니 아이가 쓰기에는 너무 복잡했다.

그래서 방향을 바꿨다.

기능이 많은 화면
→ 단계별 앱 흐름

글을 읽는 화면
→ 듣고 이해하는 화면

질문 1회 구조
→ 멀티턴 대화 구조

기술 데모
→ 실제 AI 독서 친구 경험

 

특히 Step 3과 Step 4의 역할을 나눈 것이 중요했다.

Step 3은 이야기 듣기.
Step 4는 말하기.

처음에는 Step 3에서도 질문을 들려줬는데 흐름이 어색했다. 아이가 먼저 이야기를 듣고 이해한 뒤에 다음 단계에서 Kanana와 대화하는 것이 훨씬 자연스러웠다.

또 하나 중요했던 수정은 대화 화면의 마이크 UX였다.

처음에는 녹음 시작, 녹음 종료, 답변 보내기 버튼이 따로 있었다. 하지만 아이 입장에서는 복잡할 수 있어서 큰 마이크 버튼 하나를 중심으로 바꾸었다.

기본 상태: 🎤 크게 말해볼까요?
녹음 중: 🎙️ 듣고 있어요...
녹음 후: 이렇게 들었어요 + 답변 보내기

 

이런 식으로 바꾸니 “AI와 말한다”는 경험이 더 직관적으로 느껴졌다.

14. 개발 과정에서 배운 점

이번 프로젝트를 만들면서 가장 크게 배운 점은 세 가지다.

첫째, 옴니모달 API는 기능보다 경험 설계가 중요하다

이미지 분석, OCR, TTS, STT, 대화 기능은 각각 따로 보면 기능 단위다. 하지만 사용자는 기능을 쓰는 것이 아니라 경험을 한다.

다독다독에서 중요한 것은 “이미지 분석이 된다”가 아니라 아이가 그림책을 보며 Kanana와 자연스럽게 이야기하는 경험이었다.

그래서 API를 단순 호출하는 것보다 언제 어떤 방식으로 호출하고 어떤 결과를 화면에 보여줄지 설계하는 것이 훨씬 중요했다.

둘째, fallback은 선택이 아니라 필수다

AI API는 항상 성공하지 않는다. TTS가 실패할 수도 있고 음성 인식이 잘 안 될 수도 있고 JSON 파싱이 실패할 수도 있다.

특히 아이 대상 서비스에서는 흐름이 멈추는 순간 사용성이 크게 떨어진다. 그래서 fallback 데이터를 준비하고 브라우저 API를 함께 사용하고 텍스트 수정 기능을 제공했다.

셋째, 안전한 표현이 중요하다

처음에는 “감정 분석”, “이해도 판단” 같은 표현을 쉽게 썼다. 그런데 아동 대상 서비스 특히 발달장애 아동을 위한 서비스에서는 이런 표현이 조심스럽게 다뤄져야 한다고 느꼈다.

그래서 “진단”, “치료 효과”, “장애 수준 판단”, “감정 점수화” 같은 표현은 피했다.

대신 다음과 같은 표현을 사용했다.

독서 활동 관찰
감정 이해 연습
다음 질문 가이드
참여 중심 피드백
보호자 참고 자료

 

이 부분은 앞으로도 계속 신경 써야 할 지점이라고 생각한다.

15. 현재 한계

현재 다독다독은 MVP 데모다. 그래서 아직 한계도 많다.

 

첫 번째, 현재는 단일 페이지 그림책 중심이다.
실제 그림책처럼 여러 페이지를 넘기며 읽는 구조는 아직 구현하지 않았다.

두 번째, 사용자 세션 저장 기능이 없다.
아이가 지난번에 어떤 책을 읽었고 어떤 질문에 답했는지 장기적으로 추적하는 기능은 아직 없다.

세 번째, Kanana 오디오 응답 포맷이나 브라우저별 음성 기능 차이에 대한 안정화가 더 필요하다. README에서도 Kanana 오디오 응답 포맷 일부는 문서 불확실성으로 TODO가 남아 있고 Web Speech API는 브라우저별 지원 편차가 있다고 정리했다.

네 번째, 실제 발달장애 아동과 보호자, 특수교사, 언어재활사 검증이 필요하다.
현재는 기술 데모에 가깝고 실제 서비스로 발전하려면 전문가 검수와 파일럿 테스트가 반드시 필요하다.

16. 앞으로 개선하고 싶은 점

앞으로는 다음 방향으로 개선하고 싶다.

1. 다중 페이지 그림책 지원
2. 그림책 라이브러리 확대
3. 아동별 세션 저장
4. 보호자 계정 기능
5. 기관용 리포트
6. Kanana 기반 감정형 음성 고도화
7. 실제 보호자/전문가 피드백 반영

 

특히 가장 해보고 싶은 것은 여러 페이지 그림책 흐름이다.

현재는 한 장면을 분석하고 대화하는 구조지만 실제 그림책은 여러 장면이 이어진다. 각 페이지마다 감정이 바뀌고, 사건이 진행되고, 아이는 앞 장면과 뒤 장면을 연결해야 한다.

Kanana-o를 활용하면 이런 흐름도 가능할 것 같다.

1페이지: 상황 이해
2페이지: 감정 변화
3페이지: 갈등
4페이지: 해결
5페이지: 회상 질문

 

이런 식으로 확장하면 단순 독서 보조를 넘어 이야기 전체의 흐름을 함께 이해하는 AI 독서 친구로 발전시킬 수 있을 것 같다.

17. Kanana-o API에 대한 개인적인 피드백

이번 프로젝트를 통해 느낀 Kanana-o의 장점은 꽤 명확했다.

 

첫째, 한국어 기반 감정형 대화 시나리오에 잘 어울린다.
다독다독처럼 아이에게 짧고 따뜻하게 말해야 하는 서비스에서는 단순 문장 생성 능력보다 “한국어 톤”과 “말투의 자연스러움”이 중요하다고 느꼈다. 특히 질문과 피드백을 짧고 부드럽게 이어가는 흐름이 그림책 기반 상호작용 서비스와 잘 맞았다.

둘째, 이미지와 텍스트를 함께 다루는 시나리오에 적합했다.
그림책은 단순 텍스트가 아니라 이미지와 문장이 함께 의미를 만든다. Kanana-o의 이미지 이해와 OCR 기반 추론 기능은 이런 구조와 잘 어울렸고 “그림책 페이지를 보고 → 원문을 추출하고 → 쉬운 문장으로 바꾸고 → 질문을 생성하는 흐름”을 하나의 서비스 경험으로 연결할 수 있었다.

셋째, 음성 기능과 멀티턴 대화를 하나의 사용자 경험으로 묶을 수 있다는 점이 인상적이었다.
공식 문서에서도 Kanana-o는 자연스러운 멀티턴 대화, 감정과 의도 인식, 음성 생성 등을 주요 특징으로 제시하고 있는데 실제로 프로젝트를 만들면서도 단순 “텍스트 생성 모델”보다는 사용자의 상황을 보고, 듣고, 다시 반응하는 상호작용형 서비스에 더 잘 어울린다고 느꼈다.

 

다만 실제 웹앱 형태로 구현하면서는 몇 가지 추가로 보강되면 좋겠다고 느낀 부분도 있었다.

공식 문서에는 이미지/오디오 Base64 입력, TTS, ASR, 스트리밍 응답, 멀티턴 대화 예제가 잘 정리되어 있었다. 하지만 이번 프로젝트는 Next.js 기반 웹앱 형태였기 때문에 브라우저에서 녹음한 audio blob을 Base64로 변환하고 API Route를 통해 전달한 뒤 응답 음성을 다시 브라우저에서 재생하는 흐름은 직접 실험하며 구현해야 했다.

특히 Kanana TTS를 우선 사용하고 실패하면 브라우저 SpeechSynthesis로 fallback하는 구조를 만들면서 “웹 프론트엔드 관점의 실전 예제”가 조금 더 추가되면 개발자 입장에서 훨씬 빠르게 적용할 수 있겠다고 느꼈다.

예를 들어 다음과 같은 예제가 있다면 실제 MVP를 만드는 과정에서 도움이 많이 될 것 같다.

• Next.js / React 기준 Kanana-o API 호출 예제
• 브라우저 MediaRecorder로 녹음한 audio blob을 Base64로 변환해 전달하는 예제
• Next.js API Route에서 Kanana-o를 프록시로 호출하는 예제
• Kanana TTS streaming 응답을 브라우저에서 바로 재생하는 예제
• TTS 실패 시 SpeechSynthesis fallback을 구성하는 예제
• 멀티턴 대화 상태를 프론트엔드에서 관리하며 Kanana-o와 연결하는 예제

또 이번 프로젝트는 MVP 구조였기 때문에 Next.js API Route 중심으로 구현했지만 실제 서비스 단계에서는 Spring Boot 기반 백엔드에서 오디오 처리, 사용자 세션 관리, 대화 기록 저장, AI 요청 제어 등을 분리해 운영하는 방향도 충분히 고려할 수 있겠다고 느꼈다.

전체적으로 Kanana-o는 단순 텍스트 생성 모델이라기보다 교육·독서·상담처럼 “사용자와 상호작용하는 경험” 중심 서비스에서 특히 강점이 있는 모델이라고 느꼈다. 다독다독처럼 그림책을 보고, 듣고, 말하며 감정을 이해하는 흐름과도 잘 어울렸고 실제 서비스 형태로 연결해보면서 옴니모달 모델의 가능성을 꽤 흥미롭게 체감할 수 있었다.

18. 마무리

이번 다독다독 프로젝트는 단순히 “Kanana API를 호출해봤다”는 수준을 넘어서 실제 서비스 시나리오 안에서 Kanana-o를 어떻게 사용할 수 있을지 실험해본 프로젝트였다.

처음에는 그림책 이미지를 분석하고 쉬운 글을 만드는 정도로 시작했다. 하지만 개발하면서 점점 방향이 바뀌었다.

그림책 분석 도구
→ 이야기 듣기 앱
→ 아이와 대화하는 AI 독서 친구
→ 보호자 리포트까지 포함한 독서 지원 MVP

 

이 과정을 거치면서 옴니모달 API의 가능성을 더 체감했다.

 

앞으로 AI 서비스는 단순히 텍스트를 잘 생성하는 것만으로는 부족하다고 생각한다. 사용자가 보고 있는 것, 말하는 것, 듣고 싶은 것, 이해하기 어려워하는 맥락을 함께 다룰 수 있어야 한다.

그런 점에서 Kanana-o는 한국어 기반 교육, 독서, 상담형 서비스에 꽤 흥미로운 가능성을 가진 API라고 느꼈다.

다독다독은 아직 작은 데모지만 이 프로젝트를 통해 내가 확인한 것은 분명하다.

 

Kanana-o는 단순한 생성 API가 아니라, 사용자의 상황을 보고 듣고 다시 말해주는 “상호작용 경험”을 만들 수 있는 도구다.

 

앞으로도 이 프로젝트를 계속 개선하면서 더 자연스럽고 따뜻한 AI 독서 경험을 만들어보고 싶다.