생각보다 쉬웠지만, 아무것도 몰라도 되는 건 아니었다.

디자이너가 AI로 서비스를 만들 때 마주하는 5가지 시스템 구조

최근 '바이브코딩(Vibe Coding)'의 흐름을 타며 직접 서비스를 기획하고 배포까지 해보았다.

시작은 놀라웠다. 프롬프트 몇 줄에 그럴싸한 화면이 나왔고, 예전 같으면 개발 리소스 문제로 시작조차 못 했을 아이디어를 단 며칠 만에 실체화할 수 있었다. AI가 아이디어와 구현 사이의 진입장벽을 거의 허물어버린 셈이다.

하지만 내 컴퓨터 안에서 돌던 결과물을 실제로 배포하려 하자, 전혀 다른 벽에 부딪혔다. 서비스는 화면만으로 작동하지 않기 때문이다. 결과물을 서버에 올려야 하고, 유저 데이터를 저장해야 하며, 로그인 인증을 붙여야 했다. 그 과정에서 Next.js, Vercel, Supabase 같은 낯선 기술 용어들이 쏟아졌다.

단순히 "AI가 코드를 짜줬다"는 것만으로는 해결되지 않는 지점이었다. 무엇이 어디에 어떻게 연결되어 있는지, 그 관계를 모르면 에러 메시지 앞에서 방향을 잡을 수 없었다.

결론은 명확했다.

바이브코딩은 '구현의 언어'를 자연어로 바꿔주었을 뿐, 서비스가 굴러가기 위한 '소프트웨어의 뼈대' 자체를 없애준 것은 아니었다. 개발자 수준으로 코드를 깊게 파고들 필요는 없지만, 적어도 이 뼈대가 어떻게 생겼는지는 알아야 끝까지 갈 수 있었다.

직접 부딪히며 알게 된 5가지 핵심 레이어(Layer)

실제 서비스를 만들며 마주친 낯선 개념들은, 뜯어보면 결국 서비스가 세상에 나오기 위해 반드시 거쳐야 하는 5개의 층(Layer)을 의미했다.

01. UI와 인터랙션의 뼈대 : 프레임워크 (Framework)

디자인된 화면을 실제 코드로 구현하고, 페이지 간의 이동과 서버 통신 같은 기능이 작동하도록 뼈대를 잡아주는 도구다.

과거에는 HTML/CSS/JS를 파편화하여 작업하다가, 화면 조립을 돕는 React가 등장했다. 하지만 페이지 라우팅이나 검색 엔진 최적화(SEO) 등 실무적인 설정이 너무 까다로웠다. 그래서 현재는 UI부터 서버 기능까지 한 번에 다루는 풀스택 프레임워크인 'Next.js'가 사실상 업계 표준(De facto)이 되었다. v0, Bolt 같은 AI 도구들이 뱉어내는 코드의 기본값도 대부분 Next.js다.

대표 주자 = Next.js
이 외에도 Nuxt.js, SvelteKit, Remix, Astro 등이 있다.

02. 세상과 연결되는 창구 : 배포 플랫폼 (Deployment)

내 PC에서만 돌아가던 로컬 코드를 인터넷 위에 올려, 누구나 URL을 치고 들어올 수 있게 만드는 과정이다.

예전에는 서버 컴퓨터를 직접 임대하고 복잡한 명령어로 코드를 업로드했다. 요즘은 Git 저장소만 연동해 두면, 코드가 수정될 때마다 알아서 빌드하고 배포해 주는 플랫폼을 쓴다. 특히 Next.js를 만든 회사가 Vercel이기에 둘의 호환성은 완벽에 가깝다. 바이브코딩 생태계에서 "배포한다"는 말은 곧 "Vercel에 올린다"는 말과 동의어처럼 쓰인다.

대표 주자 = Vercel
이 외에도 Netlify, Cloudflare Pages, AWS Amplify 등이 있다.

03. 서비스에 생명력을 불어넣는 곳 : BaaS (Backend as a Service)

유저의 정보, 게시글, 이미지 등 동적인 데이터를 저장하고 불러오는 백엔드 시스템이다. 그저 '보여주기만 하는 화면'과 '실제로 작동하는 프로덕트'의 차이가 바로 여기서 갈린다.

과거에는 백엔드 개발자가 서버, DB, 인증 시스템을 밑바닥부터 구축해야 했다. 이제는 로그인(Auth), 데이터베이스, 스토리지 기능을 세트로 제공하는 BaaS를 활용한다. 최근에는 오픈소스 기반에 확장성이 뛰어난 Supabase가 대세로 자리 잡았다. Figma Make 시연 영상에서 데이터베이스 연결을 강조한 이유도 여기에 있다. 데이터가 돌지 않으면 서비스는 살아 숨 쉴 수 없기 때문이다.

대표 주자 = Supabase
이 외에도 Firebase, Appwrite 등이 있다.

04. 거인의 어깨 위에 서는 법 : 패키지 매니저 (Package Manager)

전 세계의 수많은 개발자들이 미리 만들어둔 유용한 기능(패키지)을 내 프로젝트에 쉽게 설치하고 관리하는 도구다.

과거에는 남의 코드를 복사해서 붙여넣거나 파일을 일일이 다운로드해야 했다. 이제는 터미널에 npm install [패키지명] 한 줄을 입력하는 것으로 끝난다. 바이브코딩을 하다 보면 AI가 가장 많이 시키는 명령어가 바로 이것이다. 이 개념을 모르면 "패키지가 없어서 에러가 났습니다"라는 AI의 대답을 이해할 수 없다.

대표 주자 = npm (Node Package Manager)
이 외에도 yarn, pnpm, bun 등이 있다.

5. 모든 변화의 궤적 : 버전 관리 (Version Control)

코드가 언제, 어떻게, 누구에 의해 바뀌었는지 기록하고, 에러가 났을 때 과거로 안전하게 롤백(Rollback)할 수 있게 해주는 시스템이다.

파일명 뒤에 '최종', '진짜_최종'을 붙여가며 백업하던 시절은 지났다. 지금은 Git이라는 시스템으로 코드의 변경 이력을 추적하고, 이를 클라우드 저장소인 GitHub에 올려두는 것이 전 세계 개발자들의 공통된 약속이다. 앞서 언급한 Vercel의 자동 배포 역시, 이 GitHub에 새로운 코드가 올라오는 것을 감지하면서 시작된다.

대표 주자: Git & GitHub
이 외에도: GitLab, Bitbucket 등이 있다.

이 다섯 가지 기술의 내부 원리를 전부 외울 필요는 전혀 없다. 중요한 것은, 서비스가 결코 화면 하나로 끝나는 것이 아니라 이 5개의 층이 톱니바퀴처럼 맞물려 돌아간다는 '감각'을 갖는 것이다.

왜 디자이너도 이 '구조'를 알아야 할까

오해를 막기 위해 다시 강조하지만, 이 글의 메시지는 "디자이너도 코딩을 배워서 개발자가 되라"가 아니다.

솔직히 말해 단순히 에러를 고치는 수준이라면, 터미널에 뜬 붉은색 오류 메시지를 복사해서 Claude나 ChatGPT에 붙여넣기만 해도 90% 이상은 해결된다. 개념을 몰라도 눈앞의 허들은 넘을 수 있다.

그러나 시스템의 구조를 아는 것과 모르는 것의 진짜 차이는 '설계의 해상도'에서 드러난다.

서비스를 기획하고 디자인할 때, "이 인터랙션은 프론트엔드에서 처리할지 서버를 거칠지", "데이터베이스 구조를 어떻게 잡아야 추후 확장이 용이할지", "이 화면이 실제로 작동하려면 백엔드에서 어떤 값이 넘어져 와야 하는지"를 판단할 수 있느냐 없느냐의 차이다.

AI는 지시받은 일을 기가 막히게 해내지만, '무엇을 지시할 것인가'를 결정하는 것은 결국 인간의 몫이다.

더 나아가, 이러한 흐름은 비단 코딩에만 국한되지 않는다. 최근 업계에서는 '바이브 디자인(Vibe Design)'이라는 개념이 부상하고 있다. 자연어로 원하는 분위기나 목표를 설명하면 AI가 UI를 직조해 내는 방식이다.

구글이 AI 네이티브 디자인 도구 'Stitch'를 발표하며 이 용어를 전면에 내세웠고, Figma 역시 'Make' 기능을 통해 디자인에서 코드로, 다시 앱으로 이어지는 경계를 허물고 있다.

하지만 기억해야 한다. 바이브 디자인으로 뽑아낸 그 수려한 화면조차 결국 앞서 정리한 5개의 레이어 위에서 돌아간다. 구조를 아는 디자이너는 단순히 '예쁜 화면'을 그리는 데서 멈추지 않고, '이 화면이 온전한 서비스로 작동하기 위해 무엇이 필요한가'를 디자인에 담아낸다.

화면만 그리는 사람과 서비스의 뼈대를 꿰뚫어 보는 사람, AI 시대가 고도화될수록 이 둘의 격차는 비교할 수 없을 만큼 벌어질 것이다.

일단 한 번, 끝까지 만들어 보라

솔직히 고백하자면, 나 역시 직접 부딪혀보기 전까지는 Next.js나 Vercel 같은 단어들이 그저 뜬구름 잡는 외계어처럼 느껴졌다. 글로만 읽어서는 절대 와닿지 않는다.

하지만 아주 작고 볼품없는 서비스라도 좋으니 직접 처음부터 끝까지 만들어보면 세상이 다르게 보인다. 에러 메시지에 Supabase라는 단어가 섞여 있으면 "아, 이건 화면 문제가 아니라 데이터 쪽 문제구나" 하고 감을 잡게 되고, 수정한 화면이 반영되지 않으면 "GitHub에 코드가 제대로 푸시(Push)되었나?" 하고 흐름을 추적할 줄 알게 된다. 코드를 읽는 능력이 생긴 것이 아니라, 서비스가 흐르는 길이 보이기 시작한 것이다.

복잡한 코드 문법이나 알고리즘은 잊어버려도 좋다. 그건 지치지 않는 AI가 훨씬 더 잘한다. 하지만 내 서비스가 어떤 층으로 구성되어 있고 지금 데이터가 어디서 막혀 있는지를 짚어내는 직관은, 오직 직접 흙먼지를 뒤집어쓰며 배포해 본 사람만이 가질 수 있다.

바이브코딩이든 바이브 디자인이든, 도구의 이름과 형태는 앞으로도 계속 바뀔 것이다. 하지만 서비스가 세상에 나오는 본질적인 구조(화면, 데이터, 배포)는 쉽게 변하지 않는다. 이 단단한 뼈대를 한 번만 내 것으로 만들어 둔다면, 앞으로 어떤 압도적인 AI 도구가 등장하더라도 흔들림 없이 그 도구를 지휘할 수 있을 것이다.