학습 목표

흐름 — 개념 바이브 코딩과 검증 → 도구 코딩 에이전트 → 사례 네 유형과 대표작 → 실습 프롬프트 실행 → 창작 레퍼런스에서 첫 화면으로

Karpathy가 이 방식에 ‘vibe coding’이라는 이름을 붙였다

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

"내가 '바이브 코딩'이라 부르는 새로운 코딩이 있다. 완전히 분위기에 몸을 맡기고, 기하급수적 발전을 받아들이고, 코드가 존재한다는 사실 자체를 잊어버리는 것이다."

— Andrej Karpathy (OpenAI 창립 멤버 · 전 Tesla AI 디렉터), X, 2025-02-02

그가 묘사한 방식은 간단했다. 화면을 보고, 원하는 것을 말하고, 실행하고, 오류가 나면 오류 문장을 다시 건넨다. 다만 코드를 읽지 않는 이런 방식은 “만들고 버릴 주말 프로젝트” 정도에 알맞다고 선을 그었다.

널리 퍼졌지만, 뜻이 하나로 굳은 말은 아니다

바이브 코딩은 빠르게 확산되고 있다.

같은 ‘AI 생성 코드’라도 사람이 이해하고 검토했는지에 따라 작업의 성격과 책임이 달라진다.

모든 AI 코딩이 바이브 코딩은 아니다

— Simon Willison(2025-03). 생성 속도와 결과의 신뢰성은 별개의 문제다. 오늘은 빠르게 만들되 브라우저 화면·오류·실행 결과를 근거로 확인한다.

"금방 만든다"와 "내 것이 된다"는 다른 말이다

업계 관찰도 같은 말을 한다. Addy Osmani의 “70% 문제”는 첫 70%보다 디테일·예외·완성도를 다루는 마지막 30%가 더 어렵다는 설명이다. METR의 무작위 대조 실험(2025)에서는 자신이 잘 아는 오픈소스 저장소를 다룬 숙련 개발자들이 당시 AI 도구를 쓸 때 평균 19% 느려졌다. 모든 작업의 결론이 아니라, 도구를 쓴다고 자동으로 빨라지는 것은 아니라는 경고다.

강한 모델보다, 좋은 작업 방식까지 함께 필요하다

모델은 바뀌어도 충분한 맥락을 주고, 실행 결과를 근거로 판단하는 작업 방식은 남는다. 구체적인 반복 순서는 첫 작품 뒤에서 직접 적용한다.

하는 일은 비슷하고, 작업 화면이 다르다

셋 다 핵심은 같다 — 설명만 하는 챗봇이 아니라, 파일과 실행 도구를 사용해 결과를 만드는 에이전트다. 핵심 의도는 재사용할 수 있지만 폴더 연결·권한 승인·미리보기 방식은 도구마다 다르다. OpenAI Codex 공식 안내(2026) · Anthropic Claude Code Platforms(2026) · Google Antigravity 공식 안내(2026)

폴더를 열고, 만들고, 실행하고, 화면까지 확인한다

모델이 보이지 않으면 앱·CLI를 업데이트하고 계정의 제공 범위를 확인한다. 플랜과 배포 시점에 따라 선택지가 다를 수 있다. 출처: OpenAI · GPT-5.6 in ChatGPT / Codex 공식 문서(2026-08 확인)

대화하면서 코드의 변경과 실행 과정을 이어 간다

처음에는 기본값 또는 Sonnet으로 시작하고, 막히는 문제에서만 더 강한 모델로 바꾸면 된다. 모델과 제공 범위는 계정·실행 환경에 따라 달라질 수 있다. 출처: Anthropic · Claude model lineup / Claude Code model configuration(2026-08 확인)

여러 프로젝트의 에이전트를 한 화면에서 관리한다

처음에는 가장 빠른 Gemini Flash로 시작하고, 복잡해지면 Pro나 다른 추론 모델을 시험한다. 모델 제공 범위는 플랜에 따라 달라진다. 출처: Google Antigravity · Models / Features 공식 문서(2026-08 확인)

두 개의 단축키 — F와 H

설정은 새로고침 뒤에도 유지되도록 브라우저 저장소나 설정 파일에 남길 수 있다. 전체화면·패널 숨김·설정 복원처럼 작품을 다시 켰을 때 같은 상태로 돌아오는 기능이 전시 운영에 중요하다.

사물 속에 남은 시간을 상상한다

보이지 않는 것들에 대한 질문

지구와 우주는 어떻게 생겨났을까. 우리는 어디에서 와서 어디로 가는가. 내가 보지 못한 것을 상상하고 느끼는 일은 막연하고 두렵지만, 그래서 더 궁금하다.

산의 돌탑을 보면 돌마다 누군가의 소원은 남고, 사람은 사라졌다는 생각을 한다. 선산의 이름 모를 조상 비석과 장군석·문신석, 그 위에 자란 지의류와 이끼를 보며 잊힌 사람과 시간, 보이지 않는 이야기를 상상한다.

돌에 쌓인 시간

퇴적암을 조각하며 지층의 결이나 화석을 만나면, 오래전 모래가 켜켜이 쌓여 돌이 되고 그 긴 시간이 지금 내 앞까지 왔다는 생각을 한다.

“오랜 시간이 나 때문에 이 멀리까지 왔구나. 잘해야겠다.”

그래서 AI로 사물에 숨은 이야기를 표현하고, 하나의 사물이 품은 여러 시간과 모습을 보여주려 한다. 모든 것은 끊임없이 변하고 관계에 따라 달라진다. 그럼에도 무엇이 남는가 — 그 질문이 작업의 시작이다.

네 유형, 네 대표작 — 작품의 주된 작동 방식으로 나눈다

정립된 학술 장르표가 아니라 이 강의에서 작품을 읽기 위한 네 가지 렌즈다. 한 작품은 여러 성격을 함께 가질 수 있지만, 오늘은 가장 두드러지는 작동 방식 하나로 읽는다.

명암을 주사위의 눈으로 번역한다

1

입력

카메라·영상·이미지를 작은 격자로 나누고, 각 칸의 밝기를 잰다.

2

변환 규칙

어두운 칸은 1, 밝은 칸은 6이 보이도록 밝기를 주사위 눈 수로 바꾼다.

3

출력

각 주사위가 해당 면으로 굴러가며 관객의 상을 새로운 재료로 되비춘다.

핵심은 명암을 다른 시각 단위로 치환하는 규칙이다. 같은 구조에서 주사위를 단추·바둑돌·꽃잎으로 바꾸면 다른 연작이 시작된다.

주사위 거울의 전체 제작 브리프

생각나는 순서대로 쓴 이 요청을 Codex에 통째로 건넨다. 먼저 첫 버전을 열어 보고, 마음에 안 드는 곳을 하나씩 다시 말한다. 짧은 수업 실습은 실습 자료의 간소화 레시피를 사용한다. 카메라는 localhost·HTTPS에서 열고, 권한이 없을 때는 데모 패턴이 나오게 한다.

말로 맡기되, 눈으로 확인한다

• 원본을 보존하고 복사본에서 작업하며, 삭제·초기화 요청은 바로 승인하지 않는다.
• 결과는 브라우저에서 직접 열어 화면으로 판단하고, 에러가 나면 에러 문장을 그대로 붙여넣는다.

프롬프트는 한 방의 주문이 아니라 대화의 시작이다 — 이 루프를 실습 내내 돌린다.

WebGL — 브라우저가 GPU로 3D를 그리는 통로

• WebGL은 브라우저와 GPU를 잇는 바닥 기술이고, Three.js는 그 위에서 3D 작업을 쉽게 해주는 도구다.
• 이번 프롬프트는 설치 없는 단일 파일이 목표이므로 WebGL을 직접 쓰고, 같은 주사위를 한꺼번에 그리는 인스턴싱으로 개수를 늘린다.

생각나는 대로 말해도 작품이 시작된다

이 긴 브리프의 핵심은 세 가지 문제다

표면 샘플링·점 대응·보간은 형상을 계산하는 일, WebGL은 그 결과를 빠르게 그리는 일이다. 세 번째 문제에는 카메라 영상을 몸의 측정값으로 바꾸는 도구가 필요하다. 이제 MediaPipe를 살펴본다.

웹캠은 영상을 보내고, MediaPipe는 몸의 점을 찾는다

카메라는 픽셀만 보내고, MediaPipe는 랜드마크와 모델별 보조 출력—손잡이 분류, 가시성·존재 점수, 마스크, 표정 계수 등—을 돌려준다. 아직 작품의 반응은 없다. 이미지·수치 출처: Google AI Edge · Hand/Pose/Face Landmarker 공식 문서(2026)

무엇을 읽을지에 따라 인식 모델을 고른다

독립형 손·포즈·얼굴 모델과 통합형 파이프라인은 점 개수와 보조 출력이 다를 수 있다. 공통점은 측정 결과이지 감정이나 의도를 자동으로 확정한 답이 아니라는 것이다. 출처: Google AI Edge · MediaPipe Tasks 공식 문서(2026)

좌표를 몸짓으로, 몸짓을 작품의 변화로 번역한다

1

좌표

손·몸·얼굴 점의 위치를 받는다.

2

계산

점 사이 거리·각도·속도를 구한다.

3

몸짓

핀치·팔 벌림·눈 감기처럼 의미 있는 움직임으로 묶는다.

4

작품의 값

힘·크기·색·속도·소리에 연결한다.

MediaPipe는 몸에 관한 측정 결과를 준다. 그 값을 몸짓으로 해석하고, 어떤 작품 변화에 연결하며, 튀는 값을 부드럽게 만드는 일이 작가의 인터랙션 설계다. 카메라가 없거나 권한이 거절될 때를 위한 마우스 입력도 함께 둔다.

먼저, 전시 동안 무엇이 어떻게 변할지 말한다

AI가 모르는 법칙은 논문과 GitHub에서 찾게 한다

지금 모습을 보고, 다음 순간을 만든다

미리 만든 영상을 재생하는 것이 아니다. 바로 전 순간의 상태와 주변 이웃이 다음 순간을 바꾼다. 이 작품은 그 계산을 반복해 화면을 갱신한다.

움직인다고 모두 시뮬레이션은 아니다

세 범주는 완전히 배타적이지 않다. 생성 작업이 상태와 변화 규칙을 가진 가상의 생태계를 모델링하면 시뮬레이션이 될 수 있다. Lichen은 실제 지의류를 예측하는 과학 모형이 아니라, 성장·경쟁·노화·죽음을 규칙으로 만든 인공생명 시뮬레이션이다. Langton(1989) · Galanter(2003)

무엇을 만들지보다, 어떤 법칙으로 움직일지 정한다

검색을 시작할 때는 세포자동자·반응–확산·L-system / 안정 유체 / 입자·강체·연체·천 / Boids·에이전트 기반 모델 같은 이름을 함께 쓴다. 논문과 코드가 정확성을 자동으로 보증하지는 않으므로 가정·한계·라이선스를 확인한다. Turing(1952) · Lindenmayer(1968) · Reynolds(1987) · Stam(1999)

논문은 법칙을, GitHub는 구현을 보여준다

논문에서 확인할 것

무엇을 상태로 두었는지, 어떤 가정을 했는지, 무엇까지 설명하고 무엇은 설명하지 못하는지 읽는다.

저장소에서 확인할 것

그 모델을 어떤 알고리즘과 시간 간격으로 구현했는지, 실행 예시에서 어떤 움직임이 나오는지 확인한다.

코드가 모델을 의도대로 구현했는지는 검증, 모델이 표현하려는 대상과 맞는지는 타당화의 문제다. GitHub의 별점은 둘 다 보증하지 않는다.

같은 코드라도 규칙값이 달라지면 다른 군락이 된다

균사체 Mycelium — 가는 실가지

엽상 Foliose — 나이테 로제트

각축 Rivalry — 영역 전쟁

포자우림 Spores — 조밀 증식

화면에 보이는 네 배양실은 같은 코드에 성장 확률·수명·경쟁성 같은 값을 다르게 넣은 결과다. 매개변수 몇 개가 가지의 굵기, 군락의 밀도, 서로 밀어내는 방식과 남는 흔적을 크게 바꾼다.

마우스와 손짓을 서로 다른 입력으로 연결한다

• 카메라 영상은 들어오지만 랜드마크 인식이 실패하면 움직임 감지로, 카메라가 없거나 권한이 거절되면 마우스와 자율 생장으로 이어진다.
• 브라우저 안에서 상태가 계속 계산되므로 전시 내내 같은 화면을 반복 재생하지 않는다.

일곱 차례 시도에서 방향을 바꾼 네 순간

완성된 지시문이 처음부터 있었던 게 아니다. 제일 어려운 건 "살아있는 느낌이 아니다"를 말로 설명하는 일이었다. AI는 시도를 만들고 작가는 판정한다 — 원한 것은 그림이 아니라 살아있음이었고, 그 판정 기준이 작가의 몫이다.

바위에 자라는 것 — 준비된 프롬프트를 통째로

• 실습 자료의 주사위 예제가 어디까지 만들어졌는지 먼저 열어 보고, 이어서 ‘바위에 자라는 것’ 프롬프트를 통째로 붙여넣는다.
• 목표는 포자 한 알이 가장자리에서 자라고, 안쪽은 삭아 자국이 되는 Lichen의 축소판이다. 카메라 없이도 돌아가는 자율 모드를 요구한다.
• 완성되면 바꿔 볼 곳 — 색 계열(산호빛), 자랄 한계, 자국이 남는 시간.

완성 예시 — 같은 프롬프트라도 모델과 수정 과정에 따라 결과가 다르다. 화면을 열고 한 가지씩 고친다.

최종 작품의 출발점 — “지느러미를 천처럼 계산해줘”

베타가 검은 물속을 헤엄치는 웹페이지를 만들어줘. 참고 사진 8장을 같이 줄게. 핵심은 지느러미야. 그냥 이미지가 흔들리는 것처럼 보이게 하지 말고, 진짜 천처럼 계산해줘. 지느러미 뿌리는 몸에 붙어 있고 끝으로 갈수록 부드럽게 흔들리고, 몸이 움직이면 그 힘이 천에 전달되게 해줘.

크고 우아하게 천천히 계속 헤엄쳤으면 좋겠고, 추진할 때는 타탁-타탁 움직인 다음 잠깐 활강하는 리듬이 있었으면 좋겠어. 손을 내밀면 호기심을 보이고, 급하게 다가가면 놀라 달아나고, 가까이 오래 있으면 따라오거나 먹이를 먹게 해줘.

색과 빛은 참고 사진처럼 비단결 광택이 살아나야 하고, 검은 물속에 떠 있는 느낌이 나야 해. 설치 없이 브라우저에서 바로 열리는 HTML 파일 하나로 만들고, 화면 아래에는 폴리곤 수, FPS, 지느러미가 얼마나 늘어나는지 보여주는 수치를 띄워줘. H키로 설정창을 숨기고 F키로 전체화면이 되게 해줘.

이것은 한 번에 완성한 주문이 아니라 첫 제작 방향이다. 참고 사진은 복제 대상이 아니라 형태·색·광택을 판정하는 기준이었고, 이후 모델과 화면을 보며 계속 다시 지시했다.

코드로만 만든 물고기는 물고기답지 않았다

1

프로시저럴 형태

몸통과 지느러미를 수식과 기본 메시로 바로 만들었다.

2

화면으로 판정

몸과 꼬리의 연결, 비례와 실루엣이 실제 베타의 느낌과 달랐다.

3

제작 방법을 바꿈

형태를 계속 손코딩하기보다 사진을 기준으로 3D 초안을 만들기로 했다.

바이브 코딩은 틀린 첫 결과를 감추는 방법이 아니다. 왜 아닌지 화면에서 판단하고, 다음 제작 도구를 바꾸는 과정까지 작품 제작에 포함된다.

기술적 몰입은 환경의 조건, 현존감은 관객의 경험

한국어 ‘몰입감’은 심리적으로 빠져드는 경험도 뜻하지만, 여기서는 시스템이 감각과 행동을 얼마나 일관되게 둘러싸는지 말한다. 화면 기반 작품은 VR보다 범위가 작아도 공간의 연속성·빠른 반응·믿을 만한 행동으로 현존감을 만들 수 있다. Slater & Wilbur(1997) · Slater(2009)

이 작품에서는 다섯 가지 일관성을 점검했다

빛은 물속인데 움직임은 공중 같거나, 손을 내밀었는데 한참 뒤 반응하거나, 물고기의 성격이 순간마다 바뀌면 세계가 깨진다. 이 작품에서는 화려한 그래픽보다 서로 모순되지 않는 작은 법칙들이 물고기를 같은 공간에 존재하는 대상으로 느끼게 한다.

사진으로 3D를 만들고, Blender에서 최적화를 했다.

프로시저럴 형태가 어색해 Tripo의 이미지→3D로 모델을 만들었다. 하지만 원본은 정점이 너무 많아 실시간 지느러미 물리에 무거웠다. Blender에서 폴리곤을 줄이고 몸통·지느러미를 여덟 파트로 나눈 뒤 GLB로 다시 가져왔다. 이 Blender 작업을 말로 맡길 때 사용한 연결이 다음 장의 MCP다.

MCP는 코딩 에이전트와 Blender 사이의 연결 규칙이다

실제 지시의 형태
“이 모델을 웹 실시간 시뮬레이션용으로 정리해줘. 폴리곤을 줄이고, 지느러미를 각각 분리하고, UV와 법선을 확인한 뒤 GLB로 내보내줘.”

MCP(Model Context Protocol)는 AI 에이전트가 외부 앱의 데이터와 기능을 공통 형식으로 발견하고 호출하게 하는 연결 규약이다. 이 작업에서는 Blender 서버·애드온이 공개한 기능만 사용할 수 있으며, 버전·권한·구현에 따라 범위가 달라진다. 실행 결과를 판정하고 다시 지시하는 일은 사람의 몫이다.

이 작품이 정한 물고기 행동을 작은 규칙으로 나눈다

웹캠의 손 좌표는 그대로 쓰면 떨린다. 검출 사이의 위치를 부드럽게 이어 물리 입력으로 사용했다. 여섯 반응은 학습한 인공지능이 아니라 작가가 정한 행동 규칙이다.

참고 사진의 느낌을 팔레트와 빛으로 다시 만든다

참고 · 청록

결과 · 비단

참고 · 금빛

결과 · 금빛

참고 · 연보라

결과 · 연보라

참고 · 불꽃

결과 · 불꽃

눈으로 “좋다·이상하다”를 판단하면서도 HUD의 정점·삼각형·FPS·지느러미 늘어남을 함께 봤다. 제작 기록 화면은 41,622 정점·82,080 삼각형·약 60 FPS를 보이지만, 성능 수치는 같은 기기·브라우저·해상도에서 비교할 때만 의미가 있다. 참고 이미지를 외부에 배포할 때는 원출처와 이용 조건도 따로 기록한다.

완성작이 아니라, 마음에 드는 한 부분을 고른다

베낄 대상을 고르는 일이 아니다. 내가 가져오고 싶은 감각과 관계를 찾는 일이다. 왜 좋은지 정확히 설명하지 못해도 “이게 제일 마음에 든다”는 선택이 있으면 다음 대화를 시작할 수 있다.

창작은 익숙한 재료를 다른 관계로 연결하는 데서 시작한다

기존 움직임에 돌을 만지며 느낀 시간과 지의류에 대한 생각을 연결하고, 관객의 행동과 화면의 의미를 바꾸면 다른 작품이 시작된다. 나의 경험을 더했다고 모든 재사용이 허용되는 것은 아니므로, 이용 조건과 출처도 함께 남긴다.

느낌과 나의 이야기를 한 번에 건넨다

기술 이름을 몰라도 된다. 코딩 에이전트가 필요한 기술을 제안하거나 작은 프로토타입을 만들면, 화면을 본 뒤 원하는 것부터 하나씩 고쳐 나간다.

먼저 띄우고, 한 가지 관계만 만든다

소리·API·여러 장면·세부 설정은 나중이다. 같은 동작을 세 번 반복해 매번 반응하고 콘솔 오류가 없으면 첫 버전은 통과다.

“이건 아닌데”를 다음 버전으로 바꾼다

기술은 작품의 요구가 생긴 뒤 찾는다

기능을 붙일수록 인터넷 지연·비용·권한·비밀 키·연결 실패도 작품의 조건이 된다. 추가한 기술만큼 실패할 때의 장면도 함께 설계한다.

브라우저의 화면을 전시 가능한 작품으로 바꾼다