목차

Wiki/바이브 코딩

이미 있던 이름들

  1. 1브리콜라주 — Turkle & Papert, 1990 [37]
  2. 2최종사용자 프로그래밍 — Ko 외, 2011 [39]
  3. 3캐주얼 크리에이터 — Compton & Mateas, 2015 [38]
  4. 4수업에서
  5. 52025년의 두 이름

이미 있던 이름들

바이브 코딩을 처음 접한 예술가가 "이건 코딩이 아니지 않나?"라고 느낀다면, 그 느낌에는 30년 된 이름이 있습니다. 세 편의 고전을 읽으면 바이브 코딩은 새 태도가 아니라 오래된 태도에 새 도구가 붙은 것으로 보여요.

브리콜라주 — Turkle & Papert, 1990 [37]

셰리 터클과 시모어 페퍼트는 Logo와 Lego로 프로그래밍을 배우는 아이들과 대학생을 관찰하고, 두 가지 스타일을 구분했습니다. 플래너는 문제를 쪼개 모듈로 설계한 뒤 짓고, 브리콜뢰르는 "붓질 사이에 물러서서 보는 화가처럼" 재료를 만지며 협상하고 재배치합니다.

"플래너에게 실수는 헛디딤이고, 브리콜뢰르는 중간 궤도 수정으로 항해한다. 플래너에게 프로그램은 미리 계획한 통제의 도구이고, 브리콜뢰르는 목표가 있지만 기계와의 협업이라는 정신으로 그것을 실현한다. 플래너에게 프로그램을 돌아가게 하는 것은 '할 말을 하는 것'이고, 브리콜뢰르에게는 독백보다 대화에 가깝다."

아홉 살 앤의 방법은 그대로 바이브 코딩 루프입니다: "단순한 작동하는 프로그램을 만들고 조금씩 고쳐 간다. 검은 새 한 마리로 시작한다. 날게 한다. 색을 준다. … 매 단계에서 그는 부분이 아니라 완성품의 한 버전을 갖고 있다." 저자들은 "앤은 컴퓨터를 프로그래밍하지만 화가처럼 생각하고 있다"고 씁니다. 그리고 못 박아요: 브리콜라주는 "더 나은 형태로 가는 단계가 아니라 일을 조직하는 한 방식"이라고. 결과의 질이 아니라 과정이 다를 뿐이라고.

1990년에 은유였던 "대화"가 2025년에 문자 그대로가 됐습니다. 한 가지 긴장은 남아요. 이 논문의 브리콜뢰르들은 남이 만든 블랙박스를 싫어했습니다("전부 뜯어보고 싶었다"). 생성된 코드는 역사상 가장 큰 블랙박스죠. 다만 같은 논문이 탈출구도 줍니다 — 브리콜뢰르는 남의 프로그램은 "사람을 알아 가듯 행동을 통해 알아 가는" 데 만족한다고. 실제로 시각화 연구의 참가자들이 생성 코드를 다룬 방식이 정확히 그것이었습니다 [29].

최종사용자 프로그래밍 — Ko 외, 2011 [39]

ACM Computing Surveys의 44쪽짜리 리뷰는 "프로그램이 목적이 아니라 수단인" 사람들을 다룹니다. 2012년 미국에 전문 프로그래머는 300만 명 미만이지만 스프레드시트·데이터베이스를 쓰는 사람은 5500만 명이라는 통계로 시작하고, 첫 번째 표에 "예술가: Processing 같은 언어로 인터랙티브 아트를 만든다" 를 올려 둡니다.

이 리뷰가 20년 전에 관찰한 것이 바이브 코딩 연구에서 그대로 재발견됩니다.

  • 요구사항은 만들면서 드러난다: "취미가들의 땜질(tinkering)은 정해진 끝 없이 기술을 재구성한다"; "요구사항은 실험을 통해, 무엇을 할 수 있는지 보면서 진화한다." → 바이브 코딩의 "점진적 요구 명확화" [7], "출력을 보기 전에는 생각도 못 한 것들이 많다" [13].
  • 과신: 스프레드시트 사용자의 값 판단 중 5~23%가 틀렸고, "틀린 값을 맞다고 하는 쪽이 맞는 값을 틀리다고 하는 쪽보다 훨씬 많았다." 즉각적 출력은 정확성 피드백 없이 과신만 키운다. → 이제 AI도 "다 했다"고 주장하는 두 번째 과신 주체가 됐습니다 [11][29].
  • 기회주의적 디버깅: "돌아가는 것처럼 보일 때까지 코드를 고친다"는 방식은 "추가 오류로 이어진다." → 에이전트의 "기능 고치기 부작용" [30], 초보의 "주사위 굴리기" [13].
  • 관심 투자: 사람은 이익·비용·위험을 저울질해 노력을 배분한다. 꼼꼼한 사전 분석이 "반복 조정보다 관심을 잘못 쓰는 것"일 수 있다. → 위키가 "테스트 단계"를 따로 두지 않고 만드는 루프 안에 확인 습관을 심는 이유.

또 하나 중요한 관찰: "자기를 위한 웹페이지에서 남을 위한 웹페이지로 넘어가는 순간 활동의 성격이 바뀐다." 검증 없이 짜 맞춘 코드가 갑자기 엄격한 관심을 요구하게 됩니다. 첫날 시제작과 12월 전시작의 차이가 이것입니다.

캐주얼 크리에이터 — Compton & Mateas, 2015 [38]

케이트 컴프턴은 Spore 생물 제작기, Picbreeder 같은 도구를 보고 "빠르고, 자신 있고, 즐겁게 가능성 공간을 탐색해 놀라운 인공물을 만들거나 발견하게 하고, 자부심·소유감·창의감을 주는" 시스템을 캐주얼 크리에이터라 불렀습니다. 핵심은 자기목적성(autotelic) — 과제 완수가 아니라 탐색의 즐거움이 목적이라는 것. "결과물은 완성 후 버려질 수도 있다!"

이 논문의 문장들은 Cursor 앞에 앉은 예술가의 심리를 그대로 묘사합니다.

  • "캐주얼 사용자는 완전한 통제가 필요 없으므로 통제의 상실을 속도·힘·놀라움과 기꺼이 교환한다."
  • 쇤의 성찰적 실천: "본다, 움직인다, 다시 본다 — 이 순환은 머릿속에서 탈신체적으로 일어날 수 없고 인공물과의 대화 속에서 실연되어야 한다."
  • 디자인 패턴: 빈 캔버스 없음(첫 수가 가장 어려우니 "제안을 받아들이거나 버리거나"로 줄인다), 돌연변이 쇼핑(편집 대신 근처 대안들을 둘러본다), 의미 있는 것을 조작(z-스케일이 아니라 "bloom"을 만지게 한다), 합창단(변형을 한꺼번에 보여 준다).

그리고 경고 하나 — "오트밀 천 그릇": 컴퓨터에게는 서로 다르지만 사람에게는 똑같아 보이는 인공물들. 2015년의 이 이름이 2026년에 "디자인 동질화"로 재등장합니다 [28]. 처방도 같아요: 첫 번째 그럴듯한 결과를 받아들이지 말고 여러 변형을 나란히 보라.

이 논문의 기준으로 보면 LLM 코드 생성은 꽤 나쁜 캐주얼 크리에이터입니다 — 가능성 공간이 "고장 난 인공물을 배제할 만큼 좁지" 않고, 피드백이 즉각적이지 않고(30초 대기), 기본 출력이 오트밀이니까요. 그래서 예술가가 도구 주위에 무엇을 덧붙여야 하는지(제약, 빠른 미리보기, 나란한 변형)를 알려 주는 체크리스트로도 읽힙니다.

수업에서

2025년의 두 이름

co-drifting — 크링스 등은 실무자 10명을 인터뷰하고 Copilot식 "co-piloting"(사람이 이끌고 AI가 돕는다, 효율·정확·재사용)과 Cursor·v0·bolt식 "co-drifting"(사람과 AI가 함께 표류한다, 탐색·창발·놀라움, "코드는 창작의 잔여물")을 나눕니다. 한 참가자: "스크립트를 저장하는 게 아니라 흐름을 저장한다." 이들은 바이브 코딩을 "전문가와 비개발자 모두를 위한 표현적 최종사용자 개발"이라 부르고, 프로그래밍을 "표현적이고 사변적인 실천"으로 다시 생각하자고 제안합니다 [9].

인터페이스 평탄화 — 진(Jin)은 미디어 이론으로 읽습니다. GUI·CLI·API가 하나의 프롬프트 상자로 납작해지지만, 그 아래에는 원격 GPU·프로토콜·모델 제공자라는 더 두꺼운 층이 생기고 통제는 사라지는 게 아니라 그쪽으로 이동한다고. "프로그래밍 언어의 상징적 역량이 사유화되고, 예전엔 커뮤니티와 교육기관에 분산돼 있던 전문성이 독점 시스템에 집중된다" [10]. Processing과 Arduino IDE를 이 계보 안에 두는 것도 이 논문입니다. 12월 이후에도 작품이 돌아가려면 어느 층에 의존하고 있는지 알아야 한다는 뜻으로 읽으면 됩니다.

《2026 오픈서킷 부산: 아트앤테크 프랙티스》 수업 자료 · 글·기획 배준형