AI 컴패니언 개발을 통해 알게 된, 채팅·이미지·영상 생성 기능을 연결하는 프로덕트 설계

생성형 AI를 사용한 프로덕트를 만들 경우, 단순히 LLM의 API를 연결만 한다면 그리 어렵지 않습니다.

반면에 실제로 사용자가 지속적으로 사용하는 서비스를 만들려고 하면,

• 캐릭터 설정
• 대화의 일관성
• 이미지 생성
• 영상 생성
• 콘텐츠 저장
• 비용 관리
• UX
• 모더레이션(Moderation)

등, 모델 외적인 설계가 매우 중요해집니다.

현재 저는 Veline AI라는 AI 컴패니언 서비스를 개발하고 있습니다.

이 글에서는 서비스 자체를 소개하기보다는, AI 캐릭터, 채팅, 이미지 생성, 영상 생성을 하나의 프로덕트로 결합하는 과정에서 느낀 설계상의 포인트를 정리했습니다.

처음에 생각했던 것은 LLM을 이용해 캐릭터와 대화할 수 있는 기능이었습니다.
구성 자체는 매우 간단합니다.

User
↓
Character Profile
...

하지만 실제로 만들어보니, LLM의 답변 품질만 높인다고 해서 사용자 경험에는 한계가 있습니다.

사용자에게 중요한 것은 'AI의 답변' 그 자체라기보다는,

같은 캐릭터와 지속적으로 소통하고 있다는 느낌이기 때문입니다.

그래서 Veline AI에서는 캐릭터에 여러 속성을 부여했습니다.

예를 들어,

{
"personality": "romantic",
"occupation": "doctor",
...
}

와 같은 정보입니다.

이것들을 대화 생성 시의 컨텍스트로 활용합니다.

중요한 것은 매번 방대한 설정을 LLM에 전달하는 것이 아니라, '현재 대화에서 무엇이 필요한지'를 판단하여 적절한 정보만 전달하는 것입니다.

컨텍스트가 너무 길어지면,

• 토큰 비용(Token cost)이 증가하고
• 응답 속도가 느려지고
• 캐릭터의 중요한 설정이 묻히는

문제가 발생합니다.

채팅, 이미지, 영상을 각각 별도의 기능으로 만들 경우, 사용자 입장에서는 단순한 'AI 도구 모음'처럼 느껴지게 됩니다.

그래서 서비스 내부적으로는 Character를 중심으로 데이터를 갖도록 설계했습니다.
이미지는 다음과 같습니다.

┌─ Chat
│
Character ──────┼─ Image
...

즉,

Chat → Image → Video

와 같은 기능 중심이 아니라,

Character → 각종 Generation

이라는 설계입니다.

이를 통해 사용자가 만든 한 명의 캐릭터를 여러 생성 기능에서 활용할 수 있습니다.

개인적으로 AI 컴패니언 계열 서비스에서는 이 사고방식이 상당히 중요하다고 느낍니다.

이미지 생성 기능을 구현할 때 가장 간단한 방법은 사용자에게 프롬프트(Prompt) 입력란을 제공하는 것입니다.
예를 들어,

A woman wearing a black dress,
standing in a cafe,
cinematic lighting...

와 같은 형식입니다.

하지만 일반 사용자에게는 프롬프트를 작성하는 것 자체가 부담이 됩니다.

따라서 UI에서는 가능한 한 구조화된 정보를 선택하도록 설계했습니다.
예를 들어,

Scene
- Cafe
- Beach
...

같은 선택지입니다.

내부적으로는 이것들을 조합하여 최종 프롬프트를 생성합니다.

Character
+
Scene
+
Outfit
...

사용자는 프롬프트 엔지니어링(Prompt Engineering)을 의식할 필요가 없습니다.

이는 생성형 AI 프로덕트를 만들 때 개인적으로 매우 중요하다고 생각하는 포인트입니다.

모델의 능력을 사용자에게 직접 조작하게 하는 것이 아니라, UI 측면에서 추상화한다.

모델이 고도화될수록 이 설계는 더욱 중요해질 것입니다.

4. Image-to-Video는 UX가 어렵다

최근에는 Image-to-Video 모델도 상당히 진화했습니다.

기본적인 플로우는 다음과 같습니다.

Character
↓
Image Generation
...

기술적으로는 API를 호출하는 것만으로 되지만, 실제 프로덕트에서는 생성 시간이 문제가 됩니다.

이미지는 몇 초에서 수십 초 정도는 용인되기 쉽지만, 영상의 경우 훨씬 더 오래 걸립니다.

그래서,

POST /video/generate
→ task_id
GET /video/status/{task_id}
...

와 같은 비동기 태스크(Asynchronous Task)로 처리해야 합니다.

사용자가 페이지를 닫아도 생성 처리는 계속되고, 완성 후에 'My Creations' 같은 목록에서 확인할 수 있도록 설계하는 것이 더 자연스럽습니다.

생성형 AI 서비스에서는,

Generation과 UI Session을 분리하는 것

이 중요하다고 느낍니다.

또 하나 느끼는 것은, 생성 모델을 하나로 고정하지 않는 편이 좋다는 것입니다.

예를 들어 이미지 생성에서도,

Model A
- 고품질
- 고비용
...

와 같은 차이가 있습니다.

모든 요청에 최고 품질 모델을 사용하면, 서비스로서 비용 구조가 성립하기 어렵습니다.

따라서 장기적으로는,

User Request
↓
Model Router
...

와 같은 Model Routing도 중요해질 것이라고 생각합니다.

사용자가 원하는 품질과, 생성 비용 및 속도의 균형을 맞출 필요가 있습니다.

특히 Video Generation은 Image Generation보다 비용 차이가 크기 때문에 이 문제가 두드러집니다.

생성형 AI 서비스에서는 무료 사용자에게도 API 비용이 발생합니다.

예를 들어,

100 users
× 10 generations
× $0.02
...

정도라면 문제가 없습니다.

하지만 사용자 수가 늘어나면,

100,000 users
× 10 generations
× $0.02
...

이 됩니다.

따라서,

• 최초 이용 시에만 무료
• 크레딧(Credits) 방식
• 일일 제한(Daily Limit)
• 모델별로 소비하는 크레딧을 다르게 하는

등의 설계가 필요합니다.

특히 이미지나 비디오 생성 서비스의 경우,

전환율(Conversion Rate)뿐만 아니라, 무료 사용자 1인당 추론 비용(Inference Cost)

을 봐야 합니다.

이것은 SaaS와는 조금 다른 생성형 AI 서비스 특유의 지표라고 생각합니다.

AI 캐릭터를 다룰 경우, 생성 기능뿐만 아니라 콘텐츠 모더레이션(Content Moderation)도 중요합니다.

예를 들어,

Input
↓
Safety Check
...

와 같은 여러 단계의 검사가 필요합니다.

특히 외부 이미지/비디오 생성 API를 이용하는 경우,

'API 측에서 필터링되니까 괜찮겠지'라고 생각하지 않는 것이 안전합니다.

모델마다 정책이나 필터링 동작이 다르기 때문에, 자체 서비스 측에서도 일정한 제어를 넣을 필요가 있습니다.

AI 컴패니언을 만들면서 느끼는 것은, LLM이나 Image Generation Model 그 자체보다,

여러 AI 모델을 어떻게 하나의 사용자 경험으로 통합하느냐

쪽이 더 어렵다는 것입니다.

현재 구성은 간단히 표현하자면,

┌─ LLM
│
Character ────┼─ Image Model
...

와 같습니다.

앞으로는 더욱더 Model Routing이나 Memory 등도 중요해질 것이라고 생각합니다.

생성형 AI 프로덕트는 모델의 진화가 매우 빠르기 때문에, 특정 모델에 강하게 의존하기보다는,

Product Layer
↓
AI Abstraction Layer
...

와 같은 구조로 만들어 놓는 것이 새로운 모델로 이전하기 쉽습니다.

Veline AI를 개발하면서 이 부분은 계속해서 시행착오를 거쳐 나갈 예정입니다.

참고로, 실제로 개발하고 있는 서비스는 여기입니다.