배경
웹소설의 인기작이 드라마와 영화로 영상화되는 것을 보며 한 가지 질문에서 시작했습니다. “인기작이 아니어도, AI를 활용하면 누구나 자신의 이야기를 영상으로 만들 수 있지 않을까?” 그래서 처음에는 작가가 자신의 소설을 영상화할 수 있는 AI 도구를 만들었습니다.
하지만 두 번의 사용자 테스트에서 예상과 다른 반응을 마주했습니다.
“특히 주인공의 외모처럼, 내가 상상하던 이미지를 방해할 것 같다.”
솔로툴 사용자 테스트 · P1 · P2
“AI로 뭔가를 직접 만드는 것 자체가 어렵다.”
첫 번째 반응은 소설을 영상으로 만드는 것이 과연 독자에게도 좋은 경험인가라는 질문을 던졌고, 두 번째 반응은 AI가 정말 창작의 문턱을 낮추고 있는가라는 의문을 남겼습니다. 결국 문제는 단순히 “소설을 어떻게 영상화할 것인가”가 아니라, AI를 활용해 창작하는 경험 자체를 다시 생각해 볼 필요가 있다는 것이었습니다.
그러던 중 지인에게 이런 이야기를 들었습니다.
“아는 사람들이 친구들이랑 GPT로 글을 써서 릴레이로 포스타입에 연재하는데, 월 100만 원씩 번대.”
지인에게 들은 이야기
AI로 무언가를 만드는 것이 어렵다는 이야기를 들은 직후였는데, 한편에서는 친구들과 함께 이야기를 만들고 그 과정 자체를 놀이처럼 즐기는 사람들이 이미 존재하고 있었습니다.
질문이 바뀌었습니다
그래서 AI를 잘 사용하는 방법을 가르치는 도구가 아니라, 여럿이 AI와 함께 이야기를 만들어 가는 경험 자체를 실험할 수 있는 형태를 설계했습니다.
요약
생성형 AI를 혼자 쓸 때와 여럿이 함께 쓸 때, 창작 경험은 어떻게 달라지는가?
프로젝트 주제
확인하려는 것
- 혼자 쓸 때와 함께 쓸 때, 결과물을 평가하는 방식은 어떻게 달라지는가
- 다자간 AI 창작에서 참여자 간 상호작용은 어떻게 발생하는가
- AI의 예측하지 못한 결과나 참여자 간의 어긋남은 창작 경험에 어떤 영향을 미치는가
- 대면과 비대면에서 공동 창작 경험은 어떻게 달라지는가
무엇을 묻고, 어떻게 이 질문에 도달했으며, 무엇으로 확인할 것인지를 정리한 문서입니다. 비교 조건 · 측정 지표 · 타당도 위협까지 담았습니다.
문서 열기 →프로젝트 설계
핵심 발견
결과물 중심에서 과정 중심으로
| 이용 방식 | 관찰된 것 | 무엇이 되었나 |
|---|---|---|
| 혼자 | 더 오래 고민하고 결과물의 완성도에 집중했습니다. 특히 인물의 얼굴이 일관되게 유지되는지를 확인하며 결과를 평가했습니다. | 결과물이 평가의 대상 |
| 다자간 | “다음은 어떻게 할까?” · “이거 네가 쓴 거야?” 서로의 행동과 결과를 확인하며 다음 이야기를 함께 만들어 갔습니다. | 창작 과정 자체가 놀이 |
두 조건은 서로 다른 도구를 사용했기 때문에 직접 비교한 결과가 아니라, 각 조건에서 관찰된 경험입니다. 두 방식을 직접 비교하기 위한 실험은 별도로 설계했습니다
어긋남이 실패가 아니라 놀이가 됨
대면에서는 서로의 의도를 즉각 확인하며 맞춰 갔지만, 떨어진 공간에서는 채팅으로 소통하면서 의도가 어긋나기도 했습니다.
알게 된 것
그래서 설계의 기준이 달라집니다. 대면 테스트에서 참여자들은 망가진 결과를 두고 “너무 재밌죠”라고 했습니다 — 품질이 아니라 예측 불가능성이 즐거움이었습니다.
결과물에 전문성이 필요하고 평가의 대상이 된다면 AI의 품질을 올려야 합니다. 그러나 과정 자체가 놀이라면 그럴 필요가 없습니다.
얻은 인사이트
혼자 쓸 때와 여럿이 쓸 때도 같습니다 — 혼자일수록 결과물의 완성도가 중요해지고, 여럿일수록 과정이 중요해집니다.
다만 어긋남을 전부 열어 두면 되는 것도 아니었습니다. 참여자들은 두 종류를 다르게 받아들였습니다.
| 어긋남의 종류 | 어떻게 받아들였나 |
|---|---|
| 내용이 어긋날 때 | 재미 요소가 됩니다 — 제한을 두지 않아도 됩니다 |
| 캐릭터가 바뀔 때 | 몰입이 깨집니다 — 고도화해야 합니다 |
이 구분이 기술 작업의 방향을 정했습니다. 얼굴을 고정하는 리스테이징에는 공을 들이고, 문장 해석은 세계 밖 소재만 걸러낼 뿐 예상 밖의 전개는 그대로 둡니다. 무엇을 고칠지가 아니라 무엇을 고치지 않을지를 정하는 일이었습니다.
과정
방향은 기능 목록이 아니라 두 번의 부정적 피드백이 정했습니다. 기능을 쌓은 것이 아니라 틀린 전제를 버리며 좁혀왔습니다.
첫 해법은 작가가 자기 원고를 영상화하는 솔로툴이었습니다. 프로토타입을 작가와 다독 독자에게 보여주자 제품의 전제를 부정하는 말이 돌아왔습니다.
“영상화하는 것이 웹소설에 대한 상상력을 발휘하는 데 방해가 될 것 같다.”
솔로툴 사용자 테스트
읽은 사람은 이미 머릿속에서 캐스팅을 끝냈고, 외부에서 온 얼굴은 그것을 덮어씁니다. 품질이 아니라 노출 순서의 문제였습니다. 그림체 선택과 세계관 정리 기능을 보완해 다시 보여주자 이번엔 “그냥 AI로 뭘 만드는 게 어렵다”는 말이 나왔습니다. 기능을 더할수록 벽이 높아졌습니다.
틀린 가설
| 반발 | 무너진 전제와 바뀐 것 |
|---|---|
| 상상을 방해한다 | 영상화가 독자에게 좋은 일이다 → 대상을 바꿈. 이미 읽은 사람이 아니라 아직 읽지 않은 사람으로 |
| AI로 만드는 게 어렵다 | 좋은 도구를 주면 쓴다 → 방식을 바꿈. 혼자 오래 만드는 것이 아니라 여럿이 짧게 참여하는 방식으로 |
전환의 단서는 가정이 아니라 실재하는 행동이었습니다. 지인이 들려준 이야기 속에 ChatGPT로 여럿이 함께 소설을 이어 써서 웹소설 플랫폼에 올리는 모임이 있었습니다. 작가가 아닌 사람들이 이미 자생적으로 함께 쓰고 있었습니다. 그래서 질문을 도구의 성능에서 행위의 성립으로 옮겼습니다.
설계 결정
함께 쓰는 방식
연구 질문을 화면으로 옮긴 결과입니다. 한 사람이 한 문장을 쓰고, 여럿이 고르고, 고른 장면의 끝에서 다음 장면이 시작됩니다. 네 가지 규칙으로 돌아갑니다.
- 한 문장 — 참여자는 “무슨 일이 일어나는가”만 씁니다. “어떻게 찍는가”는 보이지 않는 연출 레이어가 정합니다.
- 투표 — 접수 창 안에 둘 이상이 보내면 후보 영상 중 하나를 투표로 선택하고, 선택된 장면이 다음 이야기를 이어가는 기준이 됩니다.
- 체이닝 — 선택된 장면의 마지막 프레임에서 다음 장면이 시작되어, 다른 사람의 문장과 내 문장이 한 편의 이야기로 이어집니다.
- 세 이야기 동시 진행 — 이세계 용사(애니) · 야근(실사) · 게이트(웹툰)가 서로 독립적으로 진행되고, 대형 화면에서는 9:16 세 칸으로 세 이야기를 함께 보여줍니다.
해보기
화면 구조 — 시안 11개 화면
들어오기
한 라운드 — 반복되는 구간
돌아올 이유
이탈 방지 요소
| 장치 | 무엇을 푸는가 |
|---|---|
| 고르기 어려우세요? | 세 갈래 앞에서 멈추는 사람에게 랜덤으로 시작할 수 있는 선택지를 제공합니다. |
| 친구랑 같이 만들기 | 혼자 들어온 사람이 다자간 창작으로 넘어갈 수 있는 입구를 만듭니다. |
| 잠시 쉬어요 | 생성 대기가 길어질 때 빈 화면 대신 코인과 남은 시간을 보여줍니다. |
| 영상 뷰어 · 공유 | 완성된 장면을 크게 보고 외부로 공유할 수 있게 합니다 |
왜 영상인가
솔로툴을 기획하던 때, 웹소설을 영상으로 바꾸는 것이 실제로 되는지 보려고 Kling으로 먼저 테스트했습니다. 혼자 해보다가 팀의 이현정님과 둘이 해봤습니다 — “내가 이 이야기를 쓸 테니, 다음 이야기를 써 달라.”
돌아온 이야기는 제가 상상하던 것과 전혀 달랐습니다. 그런데 그게 재미있었습니다.
사용자도 이 흥미를 느낀다면 실험에 더 즐겁게 참여하지 않을까 생각했습니다.
여럿이 하나의 이야기를 만든다면, 앞선 참여자의 창작이 다음 참여자에게 어떤 형태로 전달되는가가 문제가 됩니다. 글로 이어 붙이면 다음 사람은 앞 문장을 읽고 머릿속에서 다시 그려야 합니다. 영상은 앞사람이 만든 사건을 모두가 같이 보는 하나의 장면으로 내놓습니다.
글로 이어 쓸 때
슥
왜 이미지가 아니라 영상인가
| 매체 | 무엇을 전달하는가 |
|---|---|
| 이미지 | 무엇이 생겼는가 — 인물과 공간을 한 장면에 보여줌 |
| 영상 | 무슨 일이 일어났는가 — 시간의 흐름, 인물의 움직임, 행동의 결과, 공간의 변화 |
참여자가 쓰는 것이 “다음에 무슨 일이 일어나는가”인 만큼, 출력도 사건이 실제로 벌어지는 시간을 가진 장면이어야 했습니다.
발생한 문제
핵심 기술 과제는 모델의 제약 자체보다, 솔로툴 사용자 테스트에서 들었던 말에서 시작되었습니다. AI 영상으로 이어지는 이야기를 만들려면 같은 인물이 유지되고 장면이 자연스럽게 이어져야 하는데, 둘 다 기본 상태에서는 안정적으로 보장되지 않았습니다.
| 들은 말 | 만든 것 | 상태 |
|---|---|---|
| “내가 생각했던 주인공 얼굴과 다르다” | 리스테이징 | 해결 |
| “입력한 문장과 영상의 싱크가 안 맞는다” | 문장 해석 · 체이닝 + 트리밍 | 해결 |
| “더 상세하게 편집할 수 없을까” | — | 미해결 |
무엇을 어떻게 정했나
| 항목 | 결정과 이유 |
|---|---|
| 리스테이징 | Veo 3.1은 시작 프레임과 인물 레퍼런스를 함께 받을 수 없어, 이어갈수록 얼굴이 달라졌습니다. 인물 고정을 이미지 모델 단계로 옮겨 앞 장면의 마지막 프레임을 배우 레퍼런스로 교정한 뒤 영상 모델에 넘겼습니다. |
| 교정과 앵글의 주기 분리 | 얼굴 교정은 매 씬, 앵글 변경은 몇 씬마다 적용했습니다. 한 스위치로 묶으면 앵글을 유지해야 하는 씬에서 레퍼런스가 빠져 얼굴이 달라지는 문제가 생겼습니다. |
| 체이닝 + 트리밍 | 다음 씬의 시작점을 클립 중간에서 뽑으면 되감기처럼 보임. 시작점을 기준으로 클립을 잘라 한 클립의 끝과 다음 씬의 시작이 자연스럽게 이어지도록 맞췄습니다 |
| 문장 해석 | “안녕”처럼 영상으로 표현하기 어려운 문장은 글자가 그대로 등장하고, 세계 밖의 소재(“지하철이 왔다”)도 영상에 나타났습니다. 앞단에서 세계 안에서 표현할 수 있는 사건으로 바꾸고, 자막에는 원문을 그대로 띄워 참여자의 소유감을 유지했습니다 |
| 세 세계 · 세 매체 | 사용자가 창작을 시작할 때 가장 먼저 정한 것은 줄거리가 아니라 실사인가 애니메이션인가였습니다. 그래서 애니 · 실사 · 웹툰 세계를 나눴습니다. |
| 트랙 3개 독립 | 트랙이 하나면 앞선 라운드가 끝날 때까지 다른 참여자가 입력할 수 없습니다. 세 트랙으로 나눠 각 이야기가 독립적으로 진행되도록 했습니다 |
| 대기 숨기기 | 접수 즉시 내 문장을 큰 화면에 노출(영상은 뒤지만 흔적은 1초 만에) · 교정된 첫 프레임 선공개 · 접수 창 동안 미리 처리해 72초 → 47초 |
| 안정 운영 | 자모 분리·기호 삽입 우회까지 막는 입력 필터, 라운드별 상태 저장, 건수·금액 예산 상한, 단계별 폴백을 적용했습니다. 실패해도 정지화면으로 투표가 계속 진행되도록 했습니다. |
| 프롬프트는 설정 파일에 | 배우 · 의상 · 색감 · 샷 6종을 세계별 설정 파일로 분리했습니다. 코드를 수정하지 않고도 톤과 배우를 바꿀 수 있습니다. |
AI를 어떻게 썼나
한 문장이 영상이 되기까지 모델 세 개가 차례로 일합니다. 참여자는 문장만 쓰고, 나머지는 보이지 않는 층에서 처리됩니다.
모델별 역할
| 단계 | 맡긴 일과 이유 |
|---|---|
| 장면 해석 | 문장을 그대로 넘기면 “안녕” 같은 말이 간판이나 자막으로 찍혔습니다. Gemini 2.5 Flash가 문장을 해당 세계 안에서 영상으로 표현할 수 있는 사건으로 바꿉니다. |
| 첫 프레임 교정 | Veo 3.1은 시작 프레임과 인물 레퍼런스를 동시에 받을 수 없습니다. 그래서 영상 전에 이미지 모델이 앞 장면의 마지막 프레임을 배우 얼굴로 교정한 뒤 영상 모델에 넘깁니다. |
| 영상 생성 | Veo 3.1의 가장 가벼운 등급으로 4초 클립을 생성합니다. 품질보다 속도와 비용을 우선해 클립 1편당 약 $0.2로 맞췄습니다. |
| 연출 규칙 | 배우 · 의상 · 색감 · 샷 6종 · 금지어를 세계별 설정 파일로 분리했습니다. 코드에 프롬프트를 넣지 않아 톤을 바꿔도 코드는 그대로 유지됩니다. |
비용과 속도 사이에서
| 선택지 | 얻는 것 | 고른 것 |
|---|---|---|
| Veo 3.1 등급 | 최상위 등급은 초당 비용이 8배 | 가장 가벼운 등급 · 4초 |
| 접수 마감 후 처리 | 구조는 단순하지만 그만큼 대기 | 제출 즉시 백그라운드에서 처리 · 72초 → 47초 |
| 생성 비용 관리 | 운영 중 비용이 새는 것을 막아야 함 | 누적 금액 상한 · 도달하면 조용히 시연 모드로 전환 |
어디에 로그를 붙였나
다음 테스트에서 말과 행동을 나란히 볼 수 있도록, 합본 시안의 화면마다 행동 로그를 미리 붙여 뒀습니다. 화면에서 일어난 일을 17가지 이벤트로 한 줄씩 남깁니다.
| 붙인 자리 | 남기는 것 |
|---|---|
| 화면 이동 | screen · tab · seg — 어느 화면에 들어왔고 어디로 옮겼나 |
| 문장 제출 | submit_ok · submit_blocked — 보낸 것과 필터에 걸린 것을 따로 |
| 투표 | vote — 누가 어느 후보를 골랐나 |
| 막혔을 때 쓴 장치 | hint · random_popup · random_spin — 이탈 방지 요소가 실제로 쓰이는지 |
| 완성 이후 | viewer_open · share_open · share_done — 보기만 했나, 내보냈나 |
| 돌아온 경로 | open_story · cta_write · reward_pick · coin_use · coin_buy_tap |
서버는 해석하지 않고 시각 · 참여자 · 이벤트 이름 · 부가 정보만 그대로 적습니다 — 무엇을 읽어낼지는 나중에 정합니다
만드는 과정
서버, 폰과 대형 화면, 영상 생성 파이프라인을 Claude Code와 함께 구현하고 배포했습니다. 한 문장이 영상이 되어 앞 장면에 이어지기까지 다음 단계를 거칩니다.
문장 한 줄이 장면이 되기까지
| 단계 | 하는 일 |
|---|---|
| 문장 접수 | 폰에서 한 문장(40자)을 받습니다. 접수 창은 15초이며, 그 안에 둘 이상이 보내면 투표가 열립니다. |
| 장면으로 번역 | 받은 문장을 영상으로 표현할 수 있는 사건으로 바꿉니다. 자막에는 원문을 그대로 띄워 “내가 쓴 것”이라는 감각을 유지합니다. |
| 시작 프레임 다시 세우기 | 앞 클립의 마지막 프레임에 배우 레퍼런스를 넣어 얼굴을 교정하고, 필요에 따라 앵글을 바꾼 새 첫 프레임을 만듭니다. 이 단계가 멀티툴의 핵심입니다. |
| 영상 생성 | 교정된 첫 프레임을 시작점으로 4초 클립을 생성합니다. |
| 이음매 맞추기 | 다음 씬이 시작될 지점에서 클립을 잘라 한 클립의 끝과 다음 씬의 시작이 이어지도록 맞춥니다. |
| 다음 씬으로 연결 | 선택된 장면이 다음 이야기의 기준이 되고, 그 마지막 프레임에서 다음 씬이 이어집니다. 6씬이 완성되면 한 이야기가 끝납니다. |
세 이야기가 동시에 · 서로 독립적으로 돕니다. 한 이야기가 투표 중이어도 다른 이야기는 접수를 받습니다
막혔던 것과 푼 방법 — 전부 실측으로 확인했습니다
| 막힌 것 | 푼 방법 |
|---|---|
| 시작 프레임과 인물 레퍼런스를 함께 줄 수 없다 |
영상 모델이 둘을 동시에 받을 수 없었습니다(Image and reference images cannot be both set). 앞 장면에서 이어가려면 시작 프레임이 필요하지만, 그러면 인물 레퍼런스를 넣을 수 없어 세대를 거듭할수록 얼굴이 달라졌습니다. 인물 고정을 영상 모델이 아닌 이미지 모델 단계로 옮겼습니다. |
| 얼굴이 계속 밀린다 (1차 시도가 실패한 이유) |
얼굴 교정과 앵글 변경을 한 스위치로 묶었더니 앵글을 유지하는 씬에는 레퍼런스가 아예 안 들어갔습니다. 둘은 주기가 다릅니다 — 교정은 매 씬, 앵글은 몇 씬에 한 번 |
| 장면이 되감기처럼 보인다 | 다음 씬의 시작점을 클립 중간에서 뽑으면 클립은 끝까지 재생되는데 다음 씬은 그 앞 상태에서 시작합니다. 시드 지점에서 클립을 잘라 이음매를 맞췄습니다 |
| 화면에 글자가 찍힌다 | “안녕”처럼 그릴 게 없는 입력이 오면 모델이 그 단어를 자막이나 간판으로 그려 넣었습니다. 세계 밖 소재(“지하철이 왔다”)도 그대로 렌더됐습니다 |
| 세 트랙이 동시에 끝나면 서버가 멈춘다 |
라운드 드라이버와 HTTP 요청이 락을 반대 순서로 잡고 있었습니다. 데드락입니다. 락 순서를 하나로 고정해 풀었습니다 — 며칠을 이어서 돌아가야 하는 서비스라 치명적인 버그였습니다 |
| 배포해도 이전 화면이 계속 보인다 | 열려 있던 폰 화면이 설정을 한 번만 읽고 이후에는 다시 읽지 않았습니다. 주기적으로 설정을 확인해 목록이 바뀌면 화면을 다시 그리도록 수정했습니다. |
| 45초 대기는 이탈 시간이 된다 | 접수 마감을 기다렸다 처리하면 그 시간이 그대로 대기가 됩니다. 제출 즉시 백그라운드로 시작해 접수 창 안에 숨겼습니다 — 72초 → 47초 |
AI 저작물 관련 확인 사항
공개해서 운영하려면 확인해야 할 것들이 있었습니다.
| 지점 | 확인한 것 |
|---|---|
| 다운로드해서 상업적으로 써도 되는가 | 막는 조항은 없습니다. 약관은 생성 결과를 고객 데이터로 규정하고 “Google은 생성 결과에 새로 생긴 지식재산권에 어떠한 소유권도 주장하지 않는다”고 적었습니다. 다만 독점은 아닙니다 — 같은 약관이 Google이 동일하거나 유사한 결과를 다른 사람에게도 생성할 수 있다고 밝히고 있습니다 Google Cloud Service Specific Terms §20 (2026.09.16 개정) |
| 기존 저작물을 그대로 넣을 때 | 특정 캐릭터나 브랜드를 짚어 금지하는 조항은 없습니다. 일반 조항(“타인의 지식재산권을 침해하지 말 것”)과 Veo의 차단 항목 중 제3자 콘텐츠 범주, 그리고 결과물이 학습 데이터를 그대로 외우지 않았는지 보는 점검이 전부입니다. 정책에 기대기보다 앞단의 문장 해석이 세계 밖 소재를 세계 안 사건으로 바꾸는 쪽이 실효가 있습니다 — 원래는 영상 품질 때문에 넣은 장치입니다 Generative AI Prohibited Use Policy (2024.12.17 개정) · Veo 책임 있는 AI 문서 (2026.09.18) |
| 그런데 자막에는 원문이 남는다 | 영상이 고유명사를 그리지 않아도 자막은 참여자가 쓴 원문을 그대로 띄웁니다. 대면 테스트에서 참여자가 “저작권이 있는 거 쓰면 어떻게 될까?”라 묻고 실제로 기존 작품 속 존재를 집어넣었습니다. 소유감을 지키려고 넣은 설계가 여기서는 반대로 작동합니다. 아직 풀지 못했습니다 |
| 유해한 프롬프트 | 모델 쪽에 괴롭힘 · 혐오 · 성적 · 위험 네 범주의 조절 가능한 필터가 있고, 아동 성착취물과 개인정보는 조절할 수 없이 항상 차단됩니다. 여기에 자모 분리 · 기호 삽입 우회까지 막는 입력 필터를 앞단에 따로 뒀습니다 Safety settings — Gemini API (2026.09.17) · 안전 필터 구성 (2026.09.18) |
| 다자간이라 달라지는 것 | 약관은 최종 사용자의 오용까지 개발자 책임으로 규정합니다. 혼자 쓰는 도구라면 이상한 입력을 넣어도 본인만 봅니다. 슥은 내가 쓴 문장이 남의 화면에 뜹니다 — 필터가 뚫리면 피해가 다른 참여자에게 갑니다. 게다가 접수 창에 둘 이상일 때만 투표가 열리므로, 혼자 참여 중이면 사람이 걸러 주는 층이 아예 없습니다 |
| 면책이 적용되는 조건 | 생성 결과가 제3자 권리를 침해했다는 주장에 대해 Google이 면책을 제공하지만, 유료 프로젝트에서 정식 출시 모델을 쓰고, 필터를 끄지 않고, 결과를 수정하지 않은 경우에만 해당합니다. “침해 가능성을 알았거나 알았어야 하는” 경우는 제외입니다 Service Specific Terms §20(i) · Generative AI Indemnified Services (2026.07.20) |
| 지금 없는 것 | 이용약관 · 동의 절차 · 신고 기능이 없습니다. 탈락한 문장은 서버 메모리에만 있다가 사라집니다. 약관이 만 18세 미만이 접근할 가능성이 높은 서비스에 쓰는 것을 금지하므로, 공개 운영 전에 연령 확인도 함께 정해야 합니다 |
법률 자문이 아니라 확인이 필요한 질문의 목록입니다 — 약관은 자주 바뀌므로 본 날짜를 함께 적었습니다
생성물의 권리가 누구에게 있는지, 원작·스타일·배우 레퍼런스에서 무엇이 걸리는지 미리 모아둔 목록입니다. 법률 자문이 아니라 답해야 할 질문의 목록입니다.
문서 열기 →사용자 테스트
멀티툴을 글쓰기가 본업이 아닌 20~40대 여섯 명에게 실제로 쓰게 했습니다. ChatGPT로 함께 쓰던 모임이 20대였던 것을 따라, 대상을 작가가 아닌 예비 창작자로 두었습니다.
지금까지의 조사 — 표본이 작다는 것을 먼저 밝혀 둡니다
| 조사 | 인원 | 누구 | 참여자 | 바꾼 것 |
|---|---|---|---|---|
| 작가 인터뷰 | 1명 | 현역 웹소설 작가 | P1 | 타깃 · 소구 |
| 솔로툴 테스트 | 2명 | 현역 웹소설 작가 · 다독 독자 | P1 · P2 | 대상 · 형태 |
| 멀티툴 — 원격 | 3명 | 글쓰기가 본업이 아닌 20~40대 | P3 ~ P5 | 시작 가이드 · 투표 관찰 |
| 멀티툴 — 대면 | 3명 | 글쓰기가 본업이 아닌 20~40대 | P6 ~ P8 | 어긋남의 종류 · 시작 방식 |
6명 모두 함께 만드는 행위 자체에는 흥미를 보였고, 막힌 지점은 전원이 “뭘 해야 하는지 모르겠다”는 말로 표현했습니다.
멀티툴 사용자 테스트 · 6명 · 6/6에서 같은 워딩
“어렵다”는 말은 세 번 나왔고, 매번 다른 층을 가리켰습니다. 한 층을 걷어낼 때마다 다음 층이 드러났습니다.
사용자 피드백에 따른 개선 과정
| 단계 | 들은 말 → 바꾼 방향 |
|---|---|
| 착상 | “글을 쓸 때 아이디어를 조금이라도 보태주면 좋겠다” → 쓰기 단계에 AI를 넣음. 문장 하나와 키워드 둘을 건네는 쓰기 보조로 반영 |
| 작성 | “빨리 하는 사람이 다음 이야기를 선점하는 건지 몰랐다” → 라운드 상태 · 남은 시간 · 참여 인원을 보이게 |
| 대기 | “기다리는 시간이 지루하다” → 대기 화면에서 다른 이야기를 이어 쓸 수 있도록 반영 |
| 소유 | “다 만들어진 영상은 어디로 가는 거냐” · “공유할 수 있냐” → 완성본을 남기고 내보내기, 기여자 표시 |
멀티툴 원격 테스트 — 떨어져서 이어 쓰기
투표가 실제로 일어나는 상황을 보기 위해, 떨어진 자리에서 세 사람(P3~P5)이 같은 이야기에 동시에 문장을 보내는 원격 테스트를 진행했습니다.
테스트 설계
| 항목 | 어떻게 했나 |
|---|---|
| 진행 | 원격 약 25분 · 참여자는 폰으로 입력 화면, PC로 상영 화면을 열고 ‘이세계 용사’ 이야기를 함께 진행 |
| 흐름 | 동시 문장 제출 → 투표 → 영상 생성 체험 → 질의응답 |
| 설문 | 창작 주체감 · 만족도 · 지속 사용 의도 · 공유 욕구 문항 중 동의하는 것을 선택 |
| 고른 문항 | “이 장면은 내가 만들었다고 느낀다” · “만들어진 장면이 마음에 든다” · “앞으로도 계속 하고 싶다” · “이 이야기를 밖에 공개해도 좋다” |
| 발견 | 다음 개선 |
|---|---|
| 시작이 막막하다 | “초반에 좀 막막해서 좀 더 가이드가 있으면 시작할 때 더 재미있을 것 같아” → 작성 창에 장르 단서 · 아이디어 제시 |
| 투표가 경쟁심을 만든다 | 처음에는 “저게 더 좋네” 하며 상대 문장을 골랐지만, “이야기가 더 진행되면 내가 선택받고 싶은 생각이 들 것 같아” → 탈락 경험과 참여 동기 관찰 |
| 방향을 먼저 맞추고 싶다 | 같이 있었다면 먼치킨물인지 이세계물인지 먼저 합의했을 것 → 시작점에서 방향을 함께 정하는 단계 |
| 어긋난 장면이 재미가 된다 | 사람을 넣었는데 여우로 나오자 “그 부분이 더 재미있는 것 같기도”, 다만 “설정을 제대로 해야 될 것 같긴 해” → 오류를 허용할지, 설정을 더 정확하게 할지 검토 |
| 공유는 장르에 달렸다 | 공개해도 좋다고 했지만 “로판이면 못 보여줄지도” → 공유 범위를 선택할 수 있게 |
| 남의 이어쓰기가 궁금하다 | “딴 사람은 이야기 진행 어떻게 할지 궁금하긴 해” · 장난스러운 개입도 “재미있을 것 같은데” → 진지한 창작자를 위한 권한 · 관리 검토 |
가장 큰 걸림돌은 여전히 사용성이었습니다. 이야기의 시작점을 정하는 기능은 준비 중입니다. 표본이 작기 때문에, 위 결과는 확정적인 결론이 아니라 다음 테스트를 위한 가설로 사용합니다.
멀티툴 대면 테스트 — 같은 자리에서 이어 쓰기
원격이 아니라 한자리에 앉은 세 사람(P6~P8)이 같은 이야기를 이어 쓰는 세션을 녹음해 다시 들었습니다.
녹음에서 뽑은 것
| 발견 | 들은 말 | 설계로 옮기면 |
|---|---|---|
| 자유를 줘도 허락을 구한다 |
“이세계 용사에서 이어서 써도 돼요?” · “대화가 많은 게 좋아요, 장면 전환이 좋아요?” → “맘대로 하는 거예요” → “아 진짜요?” → “이상한 사람 나와도 되고” → “아 진짜요?” |
한 번으로 믿지 않아 두 번 물었습니다. “자유롭게”는 자유가 아니라 불안입니다. 말로 알리는 대신 어긋난 예시를 먼저 보여 주는 쪽으로 바꿉니다 |
| 어긋남에도 두 종류가 있다 |
내용이 어긋날 때 — “미용실에 가자고 했다” “아 갑자기?”(웃음) · “에반게리온의 신도 튀어나오는 게 대박인데?” / 사람이 바뀔 때 — “얘가 제이 아니에요?” · “방송이 없어지는 거 알고 있었어요?” | 내용은 어긋나도 되지만 사람은 안 됩니다. 인물 고정(리스테이징)을 왜 영상 모델이 아니라 이미지 단계로 옮겼는지가 여기서 사용자 말로 확인됐습니다 |
| 함께 하기는 ‘동시에’가 아니라 ‘받아서’다 |
“서영이 천천히 검을 뽑아들어서 나도 천천히 검을 뽑아들었어” · “혼자 했을 때랑 같이 했을 때랑?” → “엄청 재밌죠” | 재미는 호응에서 나왔는데 지금 구조는 동시 제출 + 투표, 즉 경쟁입니다. 앞선 테스트의 “투표가 경쟁심을 만든다”와 같은 지점 — 방향이 반대로 가 있습니다 |
| 빠질 자유가 없으면 참여가 의무가 된다 |
“이 세 가지 중에 아무것도 하고 싶지 않아” → “그래도 해야 돼요” → “그럼 차라리 후보로 올릴래” | “차라리”가 증거입니다. 투표에 기권을 둡니다 |
| 망가진 결과가 오히려 재미가 된다 | “우리가 스토리 짜는 인간들이 멍청해서” → “이걸 좀 의도했어요, 재밌지 않아요?” → “너무 재밌죠” · “그냥 이런 멍청한 영상이 나온다는 게?” | 품질이 아니라 예측 불가능성이 즐거움이었습니다. 완성도를 올리는 방향이 늘 옳지는 않다는 뜻입니다 |
| 사적인 공간을 필요로 하기도 했다 |
“친구랑 둘이 만들고 싶을 수 있잖아요. 보여주기 창피한 얘기라든지” → 테스트용으로 만든 ‘비밀방’을 먼저 선택 | 공개 릴레이의 억제기는 창피함입니다. 앞 테스트의 “로판이면 못 보여줄지도”와 같은 축 |
| 규칙을 건드려 본다 | “저작권이 있는 거 쓰면 어떻게 될까?” | 경계를 시험하는 것 자체가 놀이입니다. 필터를 숨기는 대신 걸러졌다는 사실을 보여 주는 쪽도 후보입니다 |
대면 세션 · 약 11분 녹음 · 기기 안에서 받아쓰기 후 코딩 (음성은 외부로 보내지 않음)
다음 테스트 설계
지금까지는 “흥미를 느끼는가”를 봤습니다. 남은 질문은 무엇이 그것을 키우고 무엇이 꺾는가입니다. 계획이며 아직 결과가 아닙니다.
실험 설계
| 항목 | 설계 |
|---|---|
| 질문 | 여럿이 참여하는 AI 창작 도구에서, 어떤 방식이 참여를 더 촉진하는가 |
| 비교 조건 | 혼자(투표 없이 내 문장 채택) vs 같이(여럿이 보내고 투표로 하나 선택) — 같은 장치와 화면을 사용하고 사회적 구조만 다르게 |
| 나눠 볼 세 갈래 | ‘같이’ 조건 안에서 참여자가 갈립니다 — 채택된 사람(선택받은 경험이 참여 동기로 이어지는가) · 탈락한 사람(선택되지 않은 경험이 참여를 꺾는가 — 아직 관찰하지 못한 구간) · 투표만 한 사람(고르기만 해도 애착이 생기는가) |
| 방법 | 같은 사람이 두 조건을 모두 겪고 스스로 비교 · 순서는 절반씩 교대 · 최소 4명, 권장 6명 · 약 100분 |
| 측정 | 재참여 · 지속 의향 · 체류 · 창작 주체감 · 만족도 · 공유 욕구(7점) + 투표 탈락 직후의 행동 |
| 판정 | 척도의 절대값보다 참가자별 조건 간 차이를 봅니다. 표본이 작아 통계 검정은 사용하지 않고 기술통계와 질적 해석으로 분석합니다. |
결과
만든 것과 남은 과제를 정리했습니다.
- 배포된 서비스 — 문장 접수 · 투표 · 영상 생성 · 체이닝까지 자동으로 진행되는 멀티툴 (GitHub)
- 솔로툴 프로토타입 — 원고 → 캐스팅 → 영상화를 클릭해볼 수 있는 인터랙티브 목업
- 사용자 조사 4회 · 참여자 8명 — 작가 인터뷰(P1), 솔로툴 테스트(P1·P2), 멀티툴 원격(P3~P5), 멀티툴 대면(P6~P8)
남은 과제도 분명합니다. 여섯 명 테스트에서는 투표 탈락이 한 번도 일어나지 않았고, 원격 테스트에서 처음 투표가 성립했지만 한 번의 사례로는 “내 문장이 지워졌는데도 다시 참여하는가”를 말하기 어렵습니다. 혼자 만들 때와 여럿이 만들 때를 비교하는 실험은 설계를 마치고 실행을 앞두고 있습니다. 표본이 작고 연구자가 테스트 과정에 함께 있었던 만큼, 지금의 결과는 확정이 아니라 다음 검증의 근거로만 씁니다.
참고
만들면서 참고한 것들입니다.
- 생성 AI와 AI 창작물 저작권에 대한 사용자의 인식 연구
— 사용자 그룹의 차이를 중심으로
워크샵 진행 방식을 참고했습니다. 최다혜 · 김정용 · 한다은 · 오창훈 (2023), 『문화기술의 융합』 9(1), 777–786 · DOI 10.17703/JCCT.2023.9.1.777 - Fragments — 폰 한 대를 돌려 가며 한 줄씩 이어 쓰는 3~12인용 이야기 게임. 앞사람이 쓴 것만 보이고 전체는 끝나야 공개됩니다. 슥이 앞 장면의 마지막 프레임만 보여주고 이어받게 하는 구조와 같습니다
- Tellast — 여럿이 한 이야기를 장(章) 단위로 이어 쓰고 다음 장을 커뮤니티 투표로 정하는 플랫폼. 슥의 투표가 같은 장치입니다
- Kling — 솔로툴을 기획하던 때 웹소설을 영상으로 바꾸는 것이 되는지 확인하려고 먼저 써본 도구입니다. 이어 쓰기의 재미를 처음 발견한 자리이기도 합니다
함께한 사람들
| 이름 | 맡은 일 |
|---|---|
| 전제이 | 프로젝트 기획 · 리서치 · 프로토타이핑 |
| 이현정 | 브랜딩 |
| 함영석 | 기술 조언 |