바이브 코딩으로 노션 클론은 쏟아지는데 왜 포토샵은 없을까

요즘 X 타임라인을 보면 하루에도 몇 개씩 “AI한테 시켜서 만든 노션 클론” 같은 자랑 글이 올라옵니다. Codex, Cursor, Antigravity 같은 도구들이 쏟아지면서 진입장벽도 빠르게 무너지고 있죠. 그런데 이상한 점이 하나 있습니다. CRUD 앱은 그렇게 많이 나오는데, 포토샵 같은 복잡한 크리에이티브 소프트웨어는 바이브 코딩으로 만들어졌다는 얘기가 거의 없습니다. 왜일까요?

바이브 코딩이 잘 통하는 영역의 공통점

지금까지 바이브 코딩으로 성공한 사례들을 한 번 정리해보면 패턴이 보입니다. 노션 클론, 트렐로 클론, 간단한 SaaS 대시보드, 랜딩페이지, 채팅 앱. 이런 것들이 공통적으로 가진 특징은 “이미 잘 정리된 추상화 위에서 동작한다”는 점입니다.

React 컴포넌트 트리, REST API, 데이터베이스 CRUD. 이 세 가지로 거의 모든 게 표현 가능한 영역이거든요. AI 모델은 인터넷에 떠다니는 수십만 개의 비슷한 코드를 학습했고, 그래서 “Todo 앱 만들어줘"라는 한 줄에서 시작해도 그럴듯한 결과물을 뽑아냅니다.

ForrestKnight가 작년 10월에 올린 영상 “Everything You Need to Know About Coding with AI"가 16만 회 넘게 재생된 것도 비슷한 맥락입니다. 사람들이 AI 코딩에 환호하는 건 대부분 이 “표준화된 추상화” 안에서의 생산성 향상이지, 새로운 영역의 정복이 아닙니다.

포토샵이 바이브 코딩되지 않는 진짜 이유

자, 그러면 포토샵을 한번 생각해봅시다. 포토샵 안에는 뭐가 들어있을까요. 픽셀 단위 이미지 처리 엔진, GPU 셰이더 파이프라인, 색공간 변환 알고리즘, 레이어 블렌딩 수학, 브러시 엔진의 압력 곡선과 보간 처리, 실시간 미리보기를 위한 캐싱 시스템, 그리고 수십 년 쌓인 파일 포맷 호환성.

이건 단순히 “함수가 많다"의 문제가 아닙니다. 각 모듈이 서로 강하게 결합되어 있고, 성능 제약이 도메인 지식과 얽혀 있는 영역입니다. 가우시안 블러 하나를 만들려고 해도 단순 컨볼루션으로는 속도가 안 나오니까 분리 가능한 커널로 분해해야 하고, 큰 이미지에서는 타일 단위로 잘라서 멀티스레드로 처리해야 하고, GPU로 옮길 땐 또 메모리 전송 비용을 고려해야 합니다.

AI 모델한테 “포토샵 같은 거 만들어줘"라고 하면 어디서부터 막힐까요. 첫 번째 막히는 지점은 아키텍처 결정입니다. Electron으로 갈지, 네이티브로 갈지, 렌더링 엔진을 Skia 위에 올릴지 직접 만들지. 이런 결정은 단순히 “최선의 선택"이 있는 게 아니라 제품 비전, 팀 역량, 타깃 플랫폼이 얽힌 트레이드오프거든요.

코드 생성 ≠ 도메인 지식

여기서 핵심을 짚고 가야 합니다. AI 코딩 도구가 잘하는 건 “이미 누군가 해결한 문제의 패턴을 재조립”하는 것입니다. 그런데 크리에이티브 소프트웨어는 패턴 재조립으로 안 됩니다.

예를 들어 어도비가 30년에 걸쳐 다듬어온 “선택 영역 가장자리 보정” 알고리즘 같은 건 논문 한두 편에 다 안 담겨 있습니다. 실제 사용자 피드백, 수십만 장의 테스트 이미지, 그리고 베테랑 엔지니어들의 직관이 코드 곳곳에 박혀 있죠. 이런 암묵지는 GitHub 검색으로 안 나옵니다.

Zen van Riel의 “Unbeatable Local AI Coding Workflow” 영상이 20만 회 넘게 재생되고 있지만, 그 영상에서 다루는 것도 결국 CRUD나 자동화 스크립트 수준입니다. 바이브 코딩의 천장이 거기 있다는 걸 영상 자체가 보여주고 있는 셈이에요.

그렇다면 AI는 영영 못 만드는가

물론 그렇진 않습니다. 다만 접근 방식이 달라져야 할 뿐입니다. 지금 어도비, Figma, 그리고 Runway 같은 회사들이 하고 있는 건 “AI가 처음부터 끝까지 만드는 것"이 아니라 “기존 크리에이티브 소프트웨어 안에 AI 기능을 박아 넣는 것”입니다. 생성형 채우기, 자동 마스킹, 스타일 전이. 이런 것들은 기존 엔진이라는 단단한 뼈대 위에서 AI가 한 부품으로 일하는 형태입니다.

진짜로 새로운 크리에이티브 소프트웨어가 바이브 코딩으로 나오려면 몇 가지가 더 필요합니다. AI가 GPU 셰이더 코드의 성능 특성을 이해하고, 메모리 레이아웃을 직접 설계할 수 있어야 하고, 무엇보다 “이 기능이 사용자에게 실제로 어떻게 느껴지는가"라는 감각을 가져야 합니다. 마지막 항목은 지금 모델들의 가장 큰 약점입니다.

결국 우리가 봐야 할 것

바이브 코딩 데모에 너무 흥분하지도, 너무 비웃지도 않는 게 좋습니다. 지금 잘 되는 건 진짜 잘 되는 거고, 안 되는 건 한동안 안 될 거니까요. 중요한 건 “내가 만들려는 것이 패턴 재조립으로 해결되는 영역인가, 아니면 도메인 지식과 성능 제약이 얽힌 영역인가”를 정확히 가르는 안목입니다.

만약 여러분이 만들고 싶은 게 후자 쪽이라면, AI 코딩 도구는 “전체를 대신 만들어주는 마법사"가 아니라 “잘 짜인 뼈대 위에서 부품을 빠르게 만들어주는 조수"로 쓰는 게 맞습니다. 그래서 다시 질문이 돌아옵니다. 여러분이 지금 만들고 있는 것은 어느 쪽인가요?