그림톡 만들기 1편: 아이의 그림이 말을 걸기까지 (MVP 기획과 프로토타입)

시작하며

요즘 계속 붙잡고 있는 프로젝트가 하나 있다. 이름은 grimtalk, 한국어로는 대충 그림톡이라고 부르고 있다.

처음 아이디어는 꽤 단순했다.

아이가 그린 그림이, 진짜 친구처럼 말을 걸어오면 어떨까?

그림을 그리고 끝나는 게 아니라, 그 그림 속 친구가 살아난 것처럼 느껴지는 경험. 아이가 자기 그림을 더 오래 바라보게 되고, 그 그림과 다시 말을 섞고 싶어지는 경험. 그 감정이 이 프로젝트의 출발점이었다.

이번 글에서는 그림톡을 왜 만들기 시작했는지, 어떤 흐름으로 첫 프로토타입을 잡았는지, 그리고 구현하면서 어떤 구조를 세웠는지 정리해보려고 한다.

1. 그림톡은 어떤 프로젝트인가

그림톡은 아주 짧게 설명하면 이런 서비스다.

1. 아이가 그림을 보여준다
2. 아이가 한마디 말을 건넨다
3. AI가 그림 속 친구가 되어 대답한다
4. 아이는 그 친구와 다시 대화를 이어간다

중요한 건 여기서 AI가 “무언가를 설명하는 시스템”처럼 보이면 안 된다는 점이었다. 그냥 이미지 분석 결과를 읽어주는 제품이 아니라, 내가 그린 친구가 진짜 말을 시작한 것 같은 경험이어야 했다.

그래서 프로젝트를 설계할 때도 기능보다 감정선을 먼저 생각하게 됐다.

• 그림이 주인공이어야 한다
• 결과가 정보 카드처럼 보이면 안 된다
• 친구의 첫 인사가 가장 중요하다
• 아이가 “다시 말 걸기”를 자연스럽게 누르게 만들어야 한다

이 기준은 뒤에 UX를 다듬을 때도 계속 기준점이 됐다.

2. 기본 흐름 설계

초기 플로우는 비교적 명확했다.

• 랜딩
• 카메라 촬영
• 미리보기
• 녹음
• 로딩
• 결과
• 다시 대화

이 흐름을 만든 이유는 단순하다. 아이가 해야 하는 행동을 복잡하게 만들고 싶지 않았기 때문이다.

특히 초반에는 “입력 단계가 어렵지 않게” 만드는 데 집중했다.

• 카메라에서 바로 그림을 찍을 수 있게 하고
• 찍은 뒤에는 한 번 확인하고
• 마이크로 짧게 말을 건네면
• 곧바로 친구가 답하는 구조

입력 자체가 길어지면, 아이 입장에서는 서비스보다 절차를 쓰는 느낌이 강해진다. 그래서 단계는 분리하되, 체감상으로는 한 번에 흘러가게 만드는 게 중요했다.

3. 기술적으로는 어떻게 붙였나

프로젝트는 Next.js 기반으로 구현했고, 핵심은 이미지와 오디오를 같이 받아서 응답을 만드는 흐름에 있었다.

초기엔 크게 세 가지 입력 모드를 분리해서 다뤘다.

• image_only
• audio_only
• image_audio

이렇게 나눈 이유는 디버깅과 품질 점검 때문이었다.

• 그림만 넣었을 때 어떤 캐릭터가 만들어지는지
• 음성만 넣었을 때 음성 인식이 어떻게 되는지
• 둘 다 넣었을 때 실제 대화가 어떻게 이어지는지

이걸 한꺼번에만 다루면 어디서 어긋나는지 잡기가 어려웠다.

4. Kanana 연동과 프롬프트 방향

이 프로젝트에서 중요한 건 단순한 응답 생성보다도, 캐릭터의 말투와 존재감이었다.

그래서 프롬프트도 일반적인 비서형 응답이 아니라, 처음부터 그림 속 친구 역할에 강하게 고정하는 쪽으로 잡았다.

핵심 규칙은 이런 느낌이었다.

• 너는 그림 속 친구 그 자체다
• AI라고 소개하지 마라
• 사용자의 마지막 말에 먼저 반응하라
• 너무 길게 설명하지 말고 짧고 따뜻하게 말하라
• 첫 응답은 특히 “방금 깨어난 친구”처럼 느껴져야 한다

이 지점이 꽤 중요했다. 같은 모델이어도 프롬프트를 어떻게 주느냐에 따라 결과가 완전히 달라진다. 조금만 잘못 잡으면 친구가 아니라 설명봇처럼 말하기 시작한다.

그림톡에서는 그게 가장 피해야 할 결과였다.

5. 실제로 부딪힌 첫 문제들

초기 프로토타입을 만들고 나서 금방 보이기 시작한 문제들이 있었다.

1) 응답이 너무 정리형으로 나온다

모델이 캐릭터가 되기보다, 그림을 보고 성격을 요약하거나 예쁘게 설명하는 쪽으로 흘러갈 때가 있었다. 그러면 감정선이 바로 깨졌다.

2) 입력 단계가 제품 설명처럼 보인다

아이 대상 경험인데 문구가 너무 어른스럽거나 안내형이면 바로 거리감이 생겼다.

3) 결과 화면이 “만남”이 아니라 “분석 결과”처럼 느껴진다

이건 나중에 더 큰 작업으로 이어졌는데, 처음엔 이름/정체/성격/질문/응답을 다 보여주는 게 좋아 보였지만 실제로는 정보 화면처럼 느껴졌다.

6. 그래서 중간에 MOCK_KANANA 모드를 넣었다

이 프로젝트를 실제로 다듬는 데 가장 큰 도움이 된 건 mock 모드였다.

실제 AI 호출만 붙여두면 UX를 다듬기가 꽤 번거롭다.

• 응답이 매번 달라지고
• 테스트할 때 시간이 걸리고
• 특정 화면만 반복 확인하기가 어렵다

그래서 mock | live 분기를 만들고, 아래 같은 입력 시나리오를 따로 돌릴 수 있게 했다.

• image only
• audio only
• image + audio

여기에 약간의 지연도 넣어서 로딩 화면이 실제처럼 보이게 만들었다. 이건 단순한 개발 편의보다도, 화면 자체를 다듬기 위한 기반에 가까웠다.

결과적으로 mock 모드가 생기고 나서야 입력/로딩/결과 화면을 반복해서 보고 손볼 수 있었다.

7. 입력과 로딩 화면에서 중요했던 것

입력 화면에서는 아이가 무엇을 해야 하는지 바로 이해할 수 있어야 했다.

그래서 카메라/미리보기/녹음 단계에서 계속 보게 된 질문은 비슷했다.

• 지금 이 문구는 설명처럼 들리나, 행동처럼 들리나?
• 버튼이 먼저 보이나, 안내문이 먼저 보이나?
• 다음 단계가 자연스럽게 이어지나?

로딩 화면에서도 비슷했다. 로딩은 짧지만, 감정적으로는 꽤 중요한 구간이다. 여기서 그냥 시스템이 처리 중이라는 느낌만 나면 금방 제품 같아진다.

그래서 동화책 톤의 카피를 짧게 돌리고, 나나의 연출도 너무 과하지 않게 조정했다. 특히 중복으로 캐릭터가 보이면 시선이 분산돼서, 상단/중앙에 겹치던 요소도 정리하게 됐다.

8. 현재까지의 핵심 배움

그림톡을 만들면서 가장 크게 느낀 건, 이 프로젝트는 기능보다 장면 설계에 더 가깝다는 점이다.

중요한 질문은 이런 쪽이었다.

• 지금 사용자는 뭘 이해했는가?
• 지금 사용자는 어떤 감정을 느끼는가?
• 이 화면은 친절한가, 아니면 설명적인가?
• 지금 보이는 요소 중 진짜 중요한 건 무엇인가?

처음엔 “이 정보도 있으면 좋겠다”가 많았는데, 시간이 갈수록 오히려 덜어내는 쪽이 맞다는 확신이 생겼다.

마무리

1편에서는 그림톡을 왜 만들었는지, 어떤 흐름으로 첫 프로토타입을 잡았는지, 그리고 왜 mock/live 구조까지 도입하게 됐는지를 정리해봤다.

다음 글에서는 이 프로젝트에서 가장 오래 붙잡고 있었던 결과 화면 UX 이야기를 해보려고 한다. 어떻게 “정보 정리 화면”을 버리고, “내 그림 친구가 처음 살아난 장면” 쪽으로 바꾸게 됐는지 그 과정을 정리할 예정이다.