AI 아이돌 제작 서비스

배경

연세대 정보대학원 이소연님의 제안으로 합류했습니다. 아이돌과 영상통화하는 서비스로 사업을 시작하려던 참이었고, 함께 해주면 좋겠다는 말에 선뜻 응했습니다.

예전에 같이 한 프로젝트가 좋은 기억으로 남아 있었고, 마침 AI 서비스에 관심이 커지던 때였습니다.

기획과 리서치, 프로토타이핑을 맡았습니다.

이 프로젝트에서 얻은 건 결과물만이 아닙니다. 바이브 코딩으로 프로토타입을 세우는 방법을 익혔고, 연세대 정보대학원 과정을 밟은 두 분의 리드 아래 UX 리서치를 배웠습니다. 오랫동안 서비스를 만들어 온 개발자들과 일하며 많이 성장했습니다.

어떤 서비스를 만들고 있나

내가 상상한 아이돌을 만들고, 그들을 모아 그룹으로 엮어 즐기는 AI 아이돌 제작 서비스 Aidol입니다. 연습생을 캐스팅해 그룹을 만들고, 멤버 사이의 관계를 정하면 그 관계를 따라 피드와 자체 콘텐츠가 쌓이고, 만든 멤버와 채팅으로 대화합니다. 관계와 서사를 쌓아 가는 제작 서비스입니다.

9인 팀 프로젝트이고, 저는 서비스 기획 · 사용자 리서치 · 프로토타이핑 · 이미지 생성 프롬프트 설계를 맡았습니다. 지금은 베타를 배포해 사용성 테스트와 로그 분석까지 끝냈고, 중심을 ‘만들기’에서 ‘키우기’로 옮겨 재설계하고 있습니다.

기술은 두 축입니다. 이미지 생성(Gemini 2.5 Flash Image)과 실시간 대화 AI(Gemini Live)가 하나이고, 립싱크 영상(Simli)과 이미지·스크립트·TTS·영상을 잇는 생성 파이프라인이 다른 하나입니다. 만드는 데는 Claude Code(CLI)와 팀 자체 MCP 서버, Figma MCP를 썼고, 콘텐츠에는 Kling(영상)과 ElevenLabs(음성), GDC를 비롯한 생성 API를 붙였습니다.

9인이 함께한 프로젝트라, 이 글은 제가 맡은 부분을 중심으로 적었습니다. 팀이 한 일과 제가 한 일의 구분은 맨 끝 「함께한 사람들」에 따로 정리했습니다.

프로젝트 목표

시작은 아이돌과 영상통화하는 서비스였습니다. 다만 K-pop 문화에서는 먼저 좋아하는 마음이 있어야 통화가 성립합니다. 팬은 아무 얼굴에게나 말을 걸지 않고, 이미 애정을 둔 인물이 있어야 통화 버튼을 누릅니다. 그런데 이 서비스가 건네는 건 사용자가 한 번도 본 적 없는 얼굴이었습니다.

그래서 통화 앞에 애정이 생기는 단계를 서비스 안에 두기로 했습니다. 사용자가 아이돌을 만들고 그룹으로 엮는 과정이 그 단계이고, 여기서 제작 서비스로의 디벨롭이 시작됐습니다.

또 통화 기능 하나로는 사람을 데려오기 어렵다고 봤습니다. 들어와서 머물 재미와 흥미 요소가 더 필요했습니다.

• 통화 이전에 애착이 생기는 조건 찾기 — 무엇을 직접 해야 ‘내 아이돌’이 되는가
• 사용자를 데려오는 재미 요소 찾기 — 제작 다음에 무엇으로 붙잡는가
• 베타 테스트와 사용자 로그로 다음 방향 검증하기

요약

사람은 언제 자기가 만든 AI 컴패니언에 애착을 갖는가?

프로젝트 주제

확인하려는 것

• 통화 이전에 애착이 생기는 조건 — 무엇을 직접 해야 ‘내 아이돌’이 되는가
• 사용자를 데려오는 재미 요소 — 제작 다음에 무엇으로 붙잡는가
• 베타 테스트와 사용자 로그로 다음 방향 검증하기

프로젝트 설계

핵심 발견

주체감은 생겼지만 애착으로 이어지지 않았다

AI가 많이 대신할수록 결과는 좋아지지만 ‘내가 만들었다’는 느낌은 줄어듭니다. 그래서 사용자가 아이덴티티를 정하게 했습니다. 얼굴은 분위기·인상·헤어를 고르게 하고 그 위에 프롬프트를 덧붙이게 해 퀄리티를 잃지 않으면서 고른 흔적이 결과에 남게 했고, 성격은 MBTI로 정해 채팅에서 말투가 달라지게 했습니다.

주체감은 실제로 생겼습니다. “직접 입력하고 골라서 여러 번 고쳤으니까”라는 답이 그것입니다. 그런데 애착으로는 이어지지 않았습니다.

알게 된 것

그래서 다음으로 묻고 싶은 것은 이것입니다 — AI가 만든 컴패니언에 사람이 애착을 갖는 조건은 무엇인가. 제작만 시킨 집단과 제작 뒤 상호작용까지 준 집단을 나누고, 개입량과 주체감 척도와 재방문을 함께 보면 확인할 수 있다고 생각합니다.

애착이 대화가 쌓이면서 생기는 것이라면, 그다음 질문은 무엇이 그 축적을 시작하게 하는가입니다.
저희 사용자들은 만들고 나서 채팅을 찾지 못했고, 찾은 사람도 한 번 보내고 멈췄습니다. 첫 대화를 열게 하는 것이 먼저 말을 거는 쪽인지, 기다릴 이유를 주는 쪽인지, 아니면 만든 직후의 그 순간인지 — 그 트리거를 찾는 일도 함께 해보고 싶습니다.

얻은 인사이트

과정

함께 일한 방식

발견과 제작을 한 주 안에서 나란히 돌렸습니다. 아래는 그 한 주의 구조입니다.

DISCOVERY TRACK — 테스트 결과가 다음 주 문제 정의로 이어짐

필수 조건 · 하나라도 아니면 탈락

리서치

무엇을 근거로 화면을 바꿨는지, 조사부터 데이터까지 순서대로 적었습니다.

아이돌 문화를 공부하고, 아이돌을 잘 아는 지인들과 이야기를 나눴습니다. 왜 K-pop 아이돌을 좋아하는지부터 물었습니다.

아이돌을 좋아하는 핵심 이유

관계성 — 동갑즈·막내즈처럼 멤버들끼리 짝을 지어 팬들이 그 관계로 노는 문화
자체 콘텐츠 — 소속사가 그룹의 일상을 예능으로 풀어 보여주는 포맷

잠재 사용자 인터뷰

들은 말 — 왜 아이돌을 좋아하는가

한 사람의 말만으로는 부족해서, 팬 커뮤니티 글과 기사·업계 인터뷰를 모아 읽으며 같은 이야기가 시장에서도 반복되는지 확인했습니다.

커뮤니티 · 시장 리서치

내 해석

좋아하는 이유를 따라가 보면 얼굴이 먼저 눈을 붙잡고, 자컨 같은 볼거리가 사람을 들이고, 관계와 서사가 응원하게 만듭니다. 그런데 이 셋은 모두 남이 만들어 준 것입니다. 팬은 고를 수만 있고 바꿀 수는 없습니다.

그래서 ‘내 아이돌’이 되는 데는 조건이 하나 더 있다고 봤습니다. 본인의 개입이 많아야 한다는 것입니다. 얼굴을 고르고, 성격을 쓰고, 멤버 사이의 관계를 정하는 일이 쌓일수록 그 그룹은 남의 그룹이 아니라 내 그룹이 됩니다.

다만 알페스 문화에 거부감을 느끼는 팬도 많아, 관계성 기능에는 수위를 거르는 장치가 필요합니다

그래서 팬이 AI 아이돌을 만들게 하자는 아이디어에 도달했습니다. 영상통화 앞에 제작 단계를 두고, 얼굴과 성격과 멤버 사이의 관계를 사용자가 정하게 하는 것입니다.

사전 인터뷰와 자료 조사에 더해, 소연님이 정리한 논문 24편과 소연님이 따로 권해준 「이미지 생성형 AI의 창작 과정 분석을 통한 사용자 경험 연구 — 사용자의 창작 주체감을 중심으로」, 그리고 버추얼 아이돌 관련 논문을 읽고 화면 설계의 근거를 추렸습니다.

참고 문헌

세 연구가 가리키는 곳은 같습니다 — 고를수록 내 것이라는 느낌이 커집니다. 그런데 기존 영상통화에는 고를 것이 없었습니다.

확인한 내용 · 아이디어

그렇게 1차 프로토타입을 제작하고, 2명의 잠재 사용자를 대상으로 인터뷰를 진행했습니다.

AI 활용

기능 단위로 쪼개 바이브 코딩으로 설계하고 구현했습니다. 개발에 넘기고 기다리는 대신 만든 사람이 그대로 사용자 앞에 놓고 반응을 봤고, 고칠 곳이 나오면 그 자리에서 고쳐 다시 보여줄 수 있었습니다.

1차 프로토타입과 테스트

프롬프트로 아이돌 그룹을 만드는 데까지만 담아, 화상으로 함께 보며 테스트했습니다. 말로 들은 답과 화면에서 관찰한 행동을 나란히 놓고 봤습니다.

화면	들어간 것
그룹 만들기	그룹 이름·소개·앨범명을 적으면 프롬프트로 그룹 엠블럼을 생성
멤버 만들기	외모를 문장으로 적으면 멤버 이미지를 생성 이름·포지션·성격(귀여운·시크·청량·카리스마)을 지정
멤버 추가	같은 절차를 반복해 그룹 인원을 채움
그룹 프로필	만든 그룹과 멤버를 한 화면에 모아 보고 링크로 공유

1차 테스트에서 본 것

팀원들도 각자 진행한 인터뷰에서 비슷한 결론에 닿았습니다. 그래서 AI 컴패니언에 어떻게 애착을 심을 수 있을까를 주제로, 만든 뒤를 잇는 경험을 얹어 베타 버전 제작을 시작했습니다.

• 채팅 — 만든 아이돌과 말을 주고받기
• 관계성 지정 — 멤버끼리의 사이를 정하기
• 포토카드 만들기 — 만든 멤버로 굿즈를 뽑아 모으기
• 더 상세해진 제작 과정 — 고를 것과 쓸 것을 늘려 사용자의 개입을 키우기

설계 결정

팬이 이 서비스에서 어떤 역할인지를 먼저 정하고, 그 틀에서 먼저 확인할 질문을 나눴습니다. 그다음 제작 뒤를 잇는 경험을 얹으면서 관계와 채팅 두 갈래를 각각 규칙으로 정했습니다.

페르소나 — 프로듀서형과 친구형

팬 위주로 설계하던 중, 팀에서 “팬이 이 서비스에서 어떤 역할을 하는지 먼저 정하자”는 의견이 나왔습니다. 사용자를 프로듀서형과 친구형 두 부류로 나눴고, 1차는 친구형에 맞춰 설계했습니다 — 내가 만든 아이돌과 대화를 나누는 방식입니다.

MVP — 세 번의 스프린트

전체 틀에서 먼저 확인할 질문을 세 번의 스프린트로 나눴습니다.

베타 버전 제작

관계성 설정

관계성은 한 번 정하고 끝나면 서사가 되지 않습니다. 그래서 멤버 사이를 고정값이 아니라 팬의 개입으로 올라가는 단계로 두고, 친밀도 구간마다 관계가 어떻게 달라지는지를 먼저 정의했습니다. 각 단계는 정의만으로는 보이지 않기 때문에, 그 단계에서만 나오는 장면을 함께 적어 두고 콘텐츠가 그 장면을 따라가게 했습니다.

관계성 설계의 근거

채팅 설계

만든 아이돌이라도 말이 오는 방식이 어긋나면 몰입은 그 자리에서 깨집니다. 긴 답이 한 번에 도착하면 읽기도 전에 AI라는 게 드러나고, 이쪽이 말을 걸어야만 반응하면 상대가 아니라 기능이 됩니다. 그래서 응답 품질과 별개로 발화 규칙을 따로 설계했습니다.

AI를 어떻게 썼나

기획서로 설명하기 전에 AI로 돌아가는 것을 만들어 확인했습니다. 무엇을 확인하려고 무엇을 만들었고, 그래서 무엇이 바뀌었는지로 적습니다.

아래는 그중 이미지 생성 쪽 기록입니다. 틀린 가정을 빠르게 버린 과정이기도 합니다.

연습생 이미지 생성 — 프롬프트에서 배운 것

글을 쓰게 하지 말고 고르게 하자가 사용자 쪽 해법이라면, 이것은 그 뒤에서 도는 생성 규칙입니다. Gemini 2.5 Flash Image로 연습생 프로필을 만들며 틀린 가정을 하나씩 고쳤습니다.

AI 생성 이미지 윤리 가이드라인

사람 얼굴을 대량으로 만들어 내는 기능이라, 무엇을 만들지 정하기 전에 무엇을 만들지 않을지부터 팀 기준으로 문서화했습니다. 프롬프트 설계와 함께 확인한 항목입니다.

팀 기준으로 문서화한 항목

사용자 테스트

Phase 1·2 누적 사용성 테스트

Phase 1과 Phase 2에 걸쳐 사용성 테스트를 진행하고, 말과 행동을 나란히 놓고 봤습니다.

AI 활용

발화 기록 옆에 동작 로그를 붙여 같이 읽었습니다. “답답했다”는 말이 실제로 어느 화면에서 몇 번 되돌아간 것이었는지 확인됐고, 말과 행동이 어긋나는 지점이 여기서 드러났습니다.

편의 표본 다루기

초기 단계라 모집 비용 없이 빠르게 돌려야 했고, 참가자는 전원 지인이었습니다. 이런 편의 표본은 호의적인 응답과 특정 집단 쏠림을 피하기 어렵습니다. 그래서 표본을 바꾸는 대신, 그 한계가 결과를 왜곡하지 못하도록 네 가지 장치를 두고 진행했습니다.

결과적으로 가장 부정적인 신호가 지인들에게서 나왔습니다. 후하게 답할 조건에서도 추천하겠다는 사람이 한 명도 없었다면, 표본이 관대했을 가능성을 감안해도 문제는 실재한다고 봤습니다. 그래서 이 결과는 만족도를 재는 점수가 아니라 고칠 곳을 찾는 문제 목록으로만 썼습니다.

발견한 문제

친구형으로 설계했지만, 사용자는 스스로를 프로듀서라고 생각했다.

“지금 내가 바로 민희진이다” · “사장님이라고 생각하고 했다”

발견한 문제

설계한 “포토카드 소진 → 과금” 경로가 5명 전원에게 작동하지 않았다.

대신 채팅 잠금 해제 · 케미 콘텐츠 · 성장 관찰이라는 세 갈래가 드러남

새로 발견한 것도 있습니다. 멤버 하나하나가 아니라 멤버끼리의 관계를 짜고 싶어 하는 “관계 PD” 심리, 그리고 Phase 1 경험자일수록 더 낮은 점수를 주는 기대치 역설입니다. 컬렉션 경로는 재방문자를 포함해 5명 전원이 스스로 찾지 못했습니다.

UT 결과와 개선안 도출

사용량 데이터

인터뷰에서 들은 말이 숫자로도 나타나는지 로그로 확인했습니다.

AI 활용

로그는 팀이 만든 MCP 서버로 바로 불러왔습니다. 분석 문서를 기다리지 않고 궁금한 걸 그 자리에서 물어 숫자를 확인할 수 있었고, 틱톡에서 들어온 34명이 한 명도 넘어가지 않았다는 것도 이렇게 찾았습니다.

틱톡 유입 34명 — 다음 화면 진입 0명

발견한 문제

틱톡에서 들어온 34명이 한 명도 다음 화면으로 넘어가지 않았다.

광고를 어디에 했느냐가 아니라, 첫 화면이 설득에 실패한 문제

검증 결과

처음에 세운 목표와 가설이 어디서 어떻게 확인됐는지 한자리에 모았습니다. 확인하지 못한 것도 그대로 적습니다.

여덟 개 중 맞은 것은 하나, 일부만 맞은 것이 둘, 기각·미달이 둘, 확인조차 못 한 것이 둘입니다. 뒤의 둘은 기능이 없어서가 아니라 거기까지 도달한 사용자가 없었기 때문입니다. 이 사실이 “만들기에서 키우기로” 방향을 바꾼 가장 직접적인 근거가 됐습니다.

결과

2월부터 5월까지, 외부 피드백과 추가 인터뷰를 거치며 방향이 바뀐 기록입니다.

방향이 바뀐 과정

틀린 예상 두 가지

• “만들고 나면 다음이 궁금해서 이메일을 남길 것” → “이메일 줄 정도로 안 궁금하다”
• “내가 만든 게 자랑스러워 공유할 것” → “포토카드도 너무 내가 뭔가 한 게 아닌 느낌이라”

둘 다 같은 곳을 가리킵니다. 다음이 궁금하지도, 자랑하고 싶지도 않다는 건 만든 아이돌에게 애정을 갖지 못했다는 뜻입니다. 1차 테스트에서 접은 가설과 같은 결론이 규모를 키운 뒤에도 그대로 나왔습니다.

그래서 바뀐 것

서비스의 중심을 ‘만들기’에서 ‘키우기’로 옮겼습니다.

남은 UX 문제

확인은 했지만 화면으로 옮기지 못한 채 끝난 문제들입니다. 추측이 아니라 로그와 세션 녹화에 숫자로 남은 것만 적습니다.

참고

설계하면서 참고한 것들입니다.

• 주간 아이돌 — 소속사가 만드는 자체 콘텐츠와 예능 포맷을 참고했습니다. 멤버들의 관계가 상황 속에서 드러나는 방식을 보고, 피드와 자체 콘텐츠를 관계 단계에 묶어 두기로 했습니다
• 이프 — 아이돌을 키우고 관계를 정하는 방식을 참고했습니다. 만든 뒤에 무엇을 더 할 수 있게 할지를 정할 때 기준으로 삼았습니다

함께한 사람들

9명이 함께한 프로젝트라 나누어 적습니다. 기억에 의존하지 않으려고 Claude로 저장소의 PR 기록을 읽어 정리했습니다. 어느 변경이 누구의 손에서 나왔는지를 커밋과 PR에 남은 대로 맞춘 표입니다.

Claude가 이 문서를 읽고

잘하는 것
사용자의 말을 그대로 받지 않고 로그와 화면 녹화로 확인합니다.
자기 가설을 버릴 줄 압니다 — 프로젝트의 출발점이던 가설을 스스로 기각했습니다.

부족한 것
제작·관계·채팅은 규칙까지 세웠지만, 첫 화면과 온보딩은 문제만 확인하고 넘어갔습니다.
방향을 ‘키우기’로 바꾼 뒤 다시 확인하지 못했습니다.