# 작품을 만들 때

> [!NOTE]
> **한 장 요약.** ① 큰 도약은 말로, 미세 조정은 손으로. ② 통째로 시키면 야심이 줄고, 나눠서 시키면 생각이 는다. ③ 첫 결과에 닻을 내리지 말고 대안 셋을 본다. ④ 아이디어는 내가, 구현은 AI가 — 반대로 하면 창의적 순간이 줄고 결과가 서로 닮는다. ⑤ 사람이 방향과 선택을 쥐고 있을 때만 반복할수록 좋아진다. ⑥ 소리는 LLM이 듣지 못하니 귀로 고른다.

예술가·창작 코더를 직접 연구한 논문은 많지 않지만, 있는 것들은 놀랄 만큼 같은 말을 합니다. 순서대로 봅니다: 무엇이 잘 되는가, 무엇이 망가지는가, 소리·움직임 작업은 어떤가.

## 큰 도약은 말로, 미세 조정은 손으로

가장 먼저 나온 예술가 연구가 Spellburst입니다(UIST 2023) [21]. 생성 예술가·디자이너·게임 개발자 10명을 인터뷰하고 p5.js 위에 노드형 프롬프트 환경을 만들어 평가했어요. 발견은 뚜렷합니다.

- 프롬프트는 **의미의 큰 점프**에 좋았습니다. "그렇게 정확하지 않아도 됐다", "내가 잡으려던 느낌의 일부를 얻었다." 자동완성이 "생각도 안 했던 길로 데려갔다."
- 그러나 **작은 구문 수정**에는 나빴어요. "원하는 게 분명할 때는 채팅으로 씨름하는 게 직접 코딩보다 훨씬 답답하다." 한 참가자: "마법이 조금 과하다."
- 예술가들은 자기 실천을 **"사고(事故) 주도 개발"** 이라 불렀습니다. "연결을 잘못했더니 가운데서 두 개가 붙었고 … 그 작은 사고들이 영감이다." 그리고 git은 탐색과 충돌했어요: "이 과정은 앞을 계획하는 게 아니라 **어디로 가는지 보는 것**인데 git은 너무 많은 계획을 요구한다." 대신 파일 복제와 스크린샷("versionFinalFinal.jpg")으로 버전을 관리했습니다.
- 평가에서 가장 좋았던 건 프롬프트가 아니라 **분기와 병합**이었습니다. "분당 훨씬 많은 아이디어를 탐색했다", "예쁜 상태를 잃을까 겁내지 않아도 된다."

![큰 도약은 말로, 미세 조정은 손으로 — [21][23]의 관찰을 이 위키가 그린 것](/wiki/vibe/leap-tune.svg)

같은 결론이 3년 뒤 Reflexa(예술가 18명)에서 반복됩니다 [23]:

![Reflexa의 세 발판 — Core(왜·다음은? 묻는 대화), Flow(버전 나무: 복제·수정·병합), Spark(막혔을 때 시각적 자극). 출처: Wang 외 (2026) Fig. 1 [23], CC BY 4.0](/wiki/vibe/fig-2601.17769-2.jpg)

 한 번의 대화로 끝내면 **조기 수렴**하고 "개념적 깊이보다 예측 가능한 결과"에 머무른다. LLM의 예측 불가능성은 창의성을 자극하기도 하지만 "목표를 방해하는 무관한 내용"을 끌어들이기도 한다. 해법은 **버전 나무 + 근거 요구 + 변형 프롬프트**였고, 전문가가 평가한 독창성·복잡성이 올라갔습니다. 다만 AI에 크게 의존한 참가자는 "프롬프트 손질이나 사소한 변형에 그쳤고", 최고 결과를 낸 P5는 **사람이 이끄는 규칙 변경**(마우스를 피하는 입자, 재생성)으로 구조를 다시 세웠어요.

## 통째로 시키면 야심이 줄어든다

예술·디자인 실무자 22명이 p5.js 인터랙티브 스케치를 만드는 실험 [22]. 한 조건은 작품 전체를 한 프롬프트로, 다른 조건은 **하위 과제로 나눠서** 시켰습니다.

- 통째로 시킨 쪽: "충분히 명확하지 않았나 봐요… 이해할 줄 알았는데", "다섯 번 다시 썼는데 결과가 그대로다." 그리고 **야심을 줄였습니다** — "이 인터랙션은 너무 어렵네, 그냥 정적인 비주얼로 하자."
- 나눠서 시킨 쪽: 성찰 에피소드가 1.5배(222 대 147, p<.001). 파라미터 가설 검증("0.5는 너무 느려, 1로"), 충돌 진단, 그리고 **의도를 지키며 수단을 바꾸는 재구성** — "내가 원한 건 유동감이었어, 경로 대신 입자로 하면 되겠다."

![예술가들이 실제로 남긴 버전 나무 — 선형 확장(P5·P8), 갈라지는 탐색(P3·P7·P12·P13), 병합 반복(P4·P11). 빨강 = 반복, 노랑 = 수정, 보라 = 병합. 출처: Wang 외 (2026) Fig. 13 [23], CC BY 4.0](/wiki/vibe/fig-2601.17769-1.png)

![통째로(C1) 대 나눠서(C2): 성찰 유형별 평균 빈도. 나눈 쪽이 Breakdown·Inquiry 모두 유의하게 높다. 출처: Wang 외 (2025) Fig. 1 [22], CC BY-NC-ND 4.0](/wiki/vibe/fig-2402.09750-1.png)

이건 [잘 하는 법](https://opencircuit.club/wiki/vibe/practice)의 첫 항목 "작게 나눠라"의 예술가 버전 증거입니다.

## 첫 결과에 닻을 내리는 문제

CHI 2025의 Pail 연구 [24]는 6주 동안 ChatGPT·Claude로 p5.js를 만든 학생들과, 이어서 미디어 아티스트·사운드 아티스트를 포함한 11명을 관찰했습니다.

- 모델은 "트레이드오프 논의 없이 **단일 해답**"을 주고, 사람은 거기에 닻을 내립니다.
- 11명 중 7명이 어느 시점부터 **코드를 아예 보지 않았고**, 루프는 "돌려 보고 → 에러를 LLM에게 고쳐 달라고"였습니다.
- 대안을 보여 주자 100%가 "생각 못 한 대안"을 발견했지만, **먼저 요청하지는 않았어요**. 설명보다 시도를 선호했습니다 — "보여 줘라, 말하지 말고."
- 뚜렷한 비전을 가진 예술가 P8은 성찰 기능을 거부했습니다: "시스템이 뭐라고 하든 관심 없다, 아이랑 해 보고 싶을 뿐." 이것도 정당한 태도입니다. 도구는 그때 조용히 있어야 해요.

![Pail: 코드·출력·채팅 옆에 "디자인 창"을 두어 설계 질문, 확정된 요구, 암묵적 결정, 유용한 추상을 대화 밖에 붙잡아 둔다. 출처: Zamfirescu-Pereira 외 (2025) Fig. 3 [24], CC BY-NC-ND 4.0](/wiki/vibe/fig-2503.06911-1.jpg)

교육 해커톤(31명, 영화·디자인·문학 전공 포함) [14]에서도 같은 것이 보였습니다: 27명 중 23명이 아이디어를 5개 이하로 탐색했고, 40%는 **하나만 만들고 손봤습니다**. 그리고 "모든 앱의 UI가 매우 비슷했다" — 서로 다른 도구, 다른 프롬프트를 쓴 두 교사의 결과조차. 주최자의 처방: **커밋하기 전에 서로 다른 컨셉 3개와 프롬프트 변형을 의무화**하라.

![해커톤 팀들의 도구 파이프라인 — 시각 프로토타입(FigJam·Stitch) → 프롬프트 다듬기(Grok·ChatGPT·Gemini) → 바이브 코딩(Lovable·Cursor·Copilot·V0). 출처: Gama 외 (2025) Fig. 8 [14], CC BY 4.0](/wiki/vibe/fig-2512.02750-1.png)



## 최소 저항 경로

가장 강한 통제 실험 [25]: 20명이 Copilot 유무로 각각 과제를 풀었습니다(예술 과제는 아닙니다).

- LLM이 있으면 **더 맞고**(40개 중 32 대 18 정답) **더 길고**(71.7 대 50.6줄) **덜 유지보수 가능**했습니다.
- 정답끼리도 **더 비슷했고**, 그 효과는 "창의적 탐색의 자유가 가장 큰 과제에서 가장 컸습니다."
- **아이디어 생성 시간이 짧아지고 '아하' 순간이 줄었습니다**(p=.01). 시간이 남아도 그랬어요. 한 참가자: "LLM이 있으면 그냥 포기하고 답을 달라고 할 압력이 있다 … 뇌는 최소 저항 경로를 택한다." 다른 참가자: "AI가 충분히 잘하면 창의적일 수 없다."
- 네 가지 협업 방식 중 **"구현자(Implementer)" 모드** — 사람이 아이디어를 내고 LLM은 타이핑만 — 가 창의적 순간(49회)과 고유 아이디어 비율(0.72)이 가장 높았고, LLM이 발상을 주도한 "브레인스토머" 모드는 4회였습니다.

저자들의 권고를 한 줄로: **"LLM을 아이디어 생성기가 아니라 구현 가속기로 다뤄라."** 아이디어를 물었을 때 구현까지 돌려주는 도구를 경계하라고요. 예술가 앞에서 이건 작품의 핵심을 어디에 둘 것인가의 문제입니다. Spellburst의 한 예술가가 미리 말했듯: "핵심에는 쓰고 싶지 않다, 하지만 방금 한 것을 **증폭**하는 데는 쓸 수 있겠다" [21].

## 공예의 관점

TU/e의 디자인 교육 연구 [26]는 데이비드 파이의 "위험의 공예 / 확실성의 공예"로 이 상황을 읽습니다. 처음엔 무제한 GPT 채팅을 붙였더니 "학습자가 최소한의 성찰만 하고 AI 코드를 복사·붙여넣기"했어요. 시스템 프롬프트를 고쳐 **답 대신 개념 안내와 질문만** 주게 하자 AI는 "계산적 물질성의 번역자 — 불확실성을 해소하지 않고 규칙과 구조를 보이게 하는" 역할이 됐습니다. 참가자들은 "AI에서 점차 주도권을 넘겨받고" 싶어 했고, "모든 파라미터 변경에" 창의성이 있다고 했습니다.

어린이 연구 [27]의 열 살 참가자가 같은 걸 더 짧게 말합니다: **"코딩 트릭을 아는 팀원 같지만, 선장은 나다."** 18명 중 9명이 AI 제안을 명시적으로 거부했고, "루프 구조는 물어보고 변수는 내가 쓴다"는 아이도 있었어요.

## 동질화

웹 바이브 코딩 도구 6종을 걸어 보고 63개 자료를 분석한 논문 [28]은 "모두 같아 보이는" 문제에 이름을 붙입니다. 프롬프트(1단계)와 다듬기(4단계)가 "AI가 동질화된 디자인을 제안하고 비전문 창작자가 수락하는" 지점이고, 원인은 훈련 데이터만이 아니라 **마찰 없는 상호작용 자체**입니다 — "디자인과 렌더링의 여러 단계가 하나의 즉각적 사건으로 붕괴한다." 그 결과가 "충분히 좋음의 함정": 자기 정체성을 대변해서가 아니라 **모델의 기본값에 맞서 반복하는 비용이 너무 커서** 수락한다. 일본 소매점 사이트를 시키자 여백 많은 미니멀 디자인이 나오고, 모델은 그것을 "문화적 선호"라고 정당화했어요. !["일본 소매 체인의 랜딩 페이지"를 시킨 결과(가운데·오른쪽)와 실제 일본 전자상거래 사이트(왼쪽). 두 도구 모두 미니멀 레이아웃을 내놓고 그것을 "문화적 선호"라고 설명했다. 출처: Shin 외 (2026) Fig. 1 [28], CC BY 4.0](/wiki/vibe/fig-2603.13036-1.jpg)

![웹 바이브 코딩의 생애주기 — ① 아이디어 ② 프롬프트 ③ 코드 ④ 렌더링을 보고 다듬기 ⑤ 배포. 동질화가 끼어드는 지점은 ②와 ④. 출처: Shin 외 (2026) Fig. 2 [28], CC BY 4.0](/wiki/vibe/fig-2603.13036-2.png)

처방은 "생산적 마찰": 프롬프트를 협상의 시작으로, 코드 전에 무드보드 여러 개, 참조 자료 투입, 생성된 결과의 "표준 그림자·둥근 모서리"를 도구가 지적하기. Cursor에서는 이걸 사람이 직접 해야 합니다.

## 사람이 방향, AI가 실행

737명이 참여한 20개 실험 [17]. 일반인이 자연어로 GPT-5에게 지시해 SVG로 동물 그림을 15번 반복해 다듬었습니다.

- 사람이 이끌면 15번 뒤 품질이 오르고(+23%), **AI가 스스로 이끌면 내려갑니다**(r=−.23). 일부만 AI에 맡겨도 궤적이 틀어져 "이후 사람이 완전히 교정하지 못했습니다."
- 사람의 지시는 평균 17.7단어, 행동 중심이었습니다: "꼬리를 없애고 고양이가 뒷다리로 앉게, 앞발 두 개가 다 보이게." AI의 지시는 755단어의 묘사였고, 단어 수를 제한해도 나아지지 않았어요 — 문제는 길이가 아니라 **"무엇이 빠졌고 틀렸는지"를 보는 눈**입니다.
- 사람이 **선택(유지/되돌리기)** 만 맡아도 AI 지시의 품질이 회복됐습니다. 설계 원칙: "사람이 방향을 정하고, AI는 평가와 실행을 돕는다."
![사람이 방향, AI가 실행 — [17]의 결과를 도식화한 것(축은 개념적)](/wiki/vibe/direction.svg)

- GPT-5가 평가자가 되면 모든 것을 후하게 주고 AI가 만든 것을 선호했습니다. **미학 판정을 모델에 맡기지 마세요.**

## 소리·움직임 작업에서

우리 첫날 실습이 소리와 움직임을 잇는 것이라 따로 모았습니다.

- **LLM은 듣지 못합니다.** Sonic Pi 코드 13,500쌍으로 확인한 바, 코드 임베딩의 유사도와 실제 소리의 유사도는 상관이 없었어요(피어슨 0.016). 파라미터를 살짝 바꿔 코드 유사도가 0.99 이상이어도 소리는 제각각 달라졌고, 그 반대도 마찬가지였습니다 [31]. "세 가지 대안"이 글자로는 다르고 소리로는 같을 수 있다는 뜻입니다. **후보를 많이 만들어 귀로 고르세요.**
- **Max/MSP 사용자**: 패치 JSON을 직접 생성시키면 정답률 0.35, Python 메타프로그래밍(MaxPy)으로 시키면 0.46, Web Audio JS는 0.76이었습니다 [32]. "for 루프와 random()을 써라"는 한 줄이 노드 수를 두 배로 늘리며 "생산적 일탈"을 만들었어요 — FM 합성이 그렇게 발견됐듯. 비전문가는 "고장 난 코드를 고치기보다 다시 생성하는 게 쉽다"는 것도 이 논문의 관찰입니다.
- **오디오 반응 셰이더**: 마이크·MP3 → 32밴드 FFT → 스칼라 `u_audio` 하나를 모든 셰이더에 주입하고, GPT-4가 셰이더 집단을 변이·교배하게 한 시스템 [33]. "세계적 예술가" 역할 프롬프트가 더 대담한 결과를, "구조를 보존하라"가 컴파일 오류 감소를 가져왔고, 샌드박스 컴파일 후 5회 재시도로 오류를 3% 아래로 낮췄습니다. 사용자는 **큐레이터**만 합니다 — 이해를 포기하는 대신 접근을 얻는 거래예요.
![AI Co-Artist: 고른 셰이더 하나에서 GPT-4가 변이시킨 집단. 모두 마이크·음악의 FFT 값 하나(u_audio)에 반응한다. 출처: Yuksel & Sawaf (2025) Fig. 2 [33], CC BY-NC-ND 4.0](/wiki/vibe/fig-2512.08951-1.jpg)

- **XR·신체 인터랙션**: 구글 XR Labs는 저수준 센서 API와 게임 엔진 계층이 "LLM 추론에 맞지 않아" XR 바이브 코딩이 실패한다고 보고, 자연어 개념과 1:1로 맞춘 작은 어휘(user, hands, depth, physics)를 만들었습니다. 그러자 통과율이 70%에서 95%로 올랐어요 [34]. 예시가 우리 관심사와 겹칩니다: "손가락을 집으면 흩어지는 민들레", "내 마이크 소리에 춤추는 종이접기 말." 교훈은 **프레임워크 선택이 바이브 코딩의 성패를 정한다**는 것 — Cursor에게 ml5·p5.sound 같은 작은 어휘를 주는 이유입니다.
![Vibe Coding XR: 헤드셋 안에서 "예쁜 민들레를 만들어 줘" → Gemini의 추론과 코드를 검토 → 손가락으로 집으면 흩어지는 민들레. 출처: Du 외 (2026) Fig. 1 [34], CC BY 4.0](/wiki/vibe/fig-2603.24591-1.jpg)

- **기본 통계**: Software Heritage에 보관된 창작 코드 저장소 161만 개 중 p5.js가 70%. p5 스케치 17,875개를 분류하니 78%가 시간 기반이고 그중 60%가 인터랙티브였지만, **소리를 합성하는 것은 6.6%** 뿐이었습니다 [36]. 소리를 다루는 여러분은 소수이고, 그만큼 LLM의 훈련 데이터도 적다는 뜻입니다.

## 수업에서

> [!TIP]
> - 오늘의 단계 3("Cursor로 한 장 만들기")에서 **규칙 한 문장을 먼저 종이에 쓰고** 나서 프롬프트를 엽니다. 구현자 모드입니다 [25].
> - 첫 결과가 나오면 바로 다듬지 말고 **"다르게 세 가지"** 를 먼저 시킵니다 [14][24]. 그중 하나를 고르는 것이 오늘 첫 번째 미학적 결정입니다.
> - 소리를 다루는 사람은 후보를 다섯 개 만들어 **눈 감고** 고릅니다 [31].
> - 마무리 때 옆 사람에게 폰을 건네고 설명하지 않습니다. 설명 없이 되면 매핑이 맞은 것입니다.

## 전자문학의 목소리

바이브 코딩을 창작 방법론으로 직접 이론화한 드문 글이 2026년 ELO에 나왔습니다 [40]. 요한나 왈리야는 이것을 "AI와의 **정동적 소통 양식**"으로, 리듬·직관·정동을 "중심 작곡 원리"로 삼아 기존 디지털 텍스트를 재활용해 시와 인터랙티브 애니메이션으로 재매개하는 시학으로 읽습니다. 저작권이 "인간의 창의성, 알고리즘 과정, 기존 디지털 재료에 분산"된다는 주장은 우리 크리틱에서 나올 질문을 미리 던져 둔 것입니다.