바이브코딩 프론트엔드 개념, 기기로 가는 코드와 서버에 둘 코드

바이브코딩 프론트엔드 개념을 비개발자 눈높이로 한 번에 훑습니다. AI가 리액트, 타입스크립트, npm, shadcn/ui, Electron 같은 이름을 꺼내며 의견을 물을 때 무엇을 뜻하는지, 그리고 그 모든 판단의 바탕이 되는 기준 하나, "이 코드가 사용자 기기로 내려가는가, 서버에 남는가"를 예약 페이지 예시로 설명합니다.

바이브코딩 프론트엔드 개념의 기준 하나

기술 이름을 외울 필요는 없습니다. AI가 쓴 코드가 사용자 기기로 전송되는지, 서버와 데이터베이스에 남는지 구분할 수 있으면 충분합니다. 어디서 어떤 기술이 왜 쓰이는지 알면, AI가 "어떻게 할까요?" 하고 물을 때 "알아서 해 줘"로 불안하게 넘기지 않아도 됩니다. 아래에 나오는 기술은 가장 많이 쓰이는 것 위주이고, 다른 선택지도 많습니다.

웹은 세 곳으로 나뉜다

웹 서비스는 세 지점으로 나눠 보면 정리가 됩니다.

• 사용자의 컴퓨터나 휴대폰 같은 기기(클라이언트)
• 웹 서비스의 서버
• 데이터를 쌓아 두는 데이터베이스

프론트엔드는 이 가운데 첫 번째, 사용자 기기에서 동작하는 영역입니다. AI가 자주 꺼내는 HTML, CSS, 자바스크립트, 리액트, 타입스크립트는 대부분 프론트엔드 기술입니다. 서버와 호스팅 쪽 구조는 "바이브코딩 서버", 전체 개발 순서는 "웹 개발 과정" 글에서 따로 다룹니다.

웹페이지 하나는 파일 세 개

"예약하기" 버튼이 있는 예약 페이지를 예로 듭니다. 브라우저는 이 페이지를 띄울 때 파일 세 종류를 받아 옵니다.

• HTML: 제목, 버튼, 예약 목록이 어디에 있는지 뼈대를 만듭니다.
• CSS: 색과 글꼴 같은 디자인을 입힙니다. 빼면 글자와 버튼만 남은 뼈대가 됩니다.
• 자바스크립트: 버튼을 누르면 목록에 한 줄이 추가되는 것 같은 동작을 만듭니다. 빼면 화면은 그대로인데 버튼을 눌러도 아무 일도 일어나지 않습니다.

세 파일을 직접 만들어 보는 방법은 "HTML CSS 자바스크립트 차이" 글에 있습니다. 여기서 중요한 건 다른 점입니다. 서버가 화면을 완성해 보내는 게 아니라, 각 파일이 그대로 사용자 기기로 내려와 브라우저 안에서 조립됩니다. 세 파일의 코드 전체가 사용자 기기 안에 있다는 뜻입니다.

크롬 개발자 도구로 직접 확인하기

사용자 기기로 내려온 코드는 누구나 볼 수 있습니다. 크롬 개발자 도구(웹페이지의 구성 요소와 코드를 확인하는 창)로 1분이면 확인됩니다.

1. 크롬에서 아무 웹페이지나 엽니다.
2. 윈도우는 F12, 맥은 Cmd+Option+I를 눌러 개발자 도구를 엽니다. 페이지 빈 곳을 오른쪽 클릭해 "검사"를 눌러도 됩니다.
   • 확인: 화면 옆이나 아래에 개발자 도구 창이 나타난다.
3. 위쪽 탭에서 "Sources"(소스)를 누릅니다.
   • 확인: 이 페이지가 받아 온 파일 목록이 보인다.
4. 목록에서 .js로 끝나는 자바스크립트 파일 하나를 엽니다.
   • 확인: 버튼을 눌렀을 때 실행되는 코드 같은 내용이 그대로 보인다. 개발자 도구에서는 이 코드를 고쳐 실행해 볼 수도 있다.

마음만 먹으면 누구나 이 코드를 읽고 바꿀 수 있다는 것, 이게 뒤에 나올 보안 이야기의 출발점입니다. 그래서 프론트엔드 코드는 원칙적으로 데이터베이스에 직접 손대지 않고 서버를 거쳐 접근하게 짭니다.

리액트가 자꾸 추천되는 이유

세 파일만으로도 화면은 다 만들 수 있습니다. 문제는 페이지가 커질 때 생깁니다. 예약 페이지 맨 위에 "남은 자리 3석"이 있고 아래에 예약 목록이 있다고 해 봅시다. 예약 하나를 취소하니 목록에서는 한 줄이 지워졌는데 남은 자리 숫자는 그대로입니다. 두 요소가 같은 데이터를 각자 따로 들고 있어서입니다.

리액트(React)는 화면을 버튼, 목록, 숫자 같은 작은 단위로 나눕니다. 이 단위를 컴포넌트라고 부릅니다. 데이터는 한 곳에만 두고, 바뀌면 그 데이터를 쓰는 컴포넌트들이 자동으로 다시 그려집니다. 데이터와 화면이 어긋나지 않게 맞춰 주는 도구입니다.

꼭 리액트여야 하는 건 아닙니다. 다만 AI는 사람들이 가장 많이 쓰고 자료가 많은 리액트를 추천하는 경향이 강합니다. 다른 기술을 고를 만한 이유가 따로 없다면 리액트로 가는 편이 무난합니다.

타입스크립트는 실행 전에 걸러 준다

컴포넌트가 많아지면 서로 데이터를 잘못 넘기는 일이 생깁니다. 예약 목록 컴포넌트는 이름과 예약 시간을 받기로 했는데, 다른 컴포넌트가 예약 시간 자리에 전화번호를 넘기는 식입니다. 자바스크립트는 실행하기 전까지 이런 오류를 알려 주지 않아서, 사용자가 깨진 화면을 먼저 보게 됩니다.

타입스크립트(TypeScript)로 "예약 시간 칸에는 시간, 이름 칸에는 글자"처럼 미리 정해 두면, 맞지 않는 코드에 편집기가 바로 빨간 밑줄을 긋습니다. AI가 쓴 코드를 한 줄씩 다 읽지 않아도 어긋난 곳을 먼저 걸러 주는 셈입니다. AI에게 고쳐 달라고 할 때 타입스크립트 오류가 어떻게 쓰이는지는 "바이브 코딩 실력 차이" 글에서 다룹니다.

npm, 빌드, 번들

브라우저는 HTML, CSS, 자바스크립트만 읽습니다. 리액트와 타입스크립트로 쓴 코드는 그대로는 실행되지 않으니 중간 과정이 필요합니다.

• npm: 다른 사람이 만들어 둔 코드 묶음(패키지)을 설치하는 도구입니다. 어떤 패키지를 어떤 버전으로 깔았는지 기록해서, 내 컴퓨터와 배포 서버에 똑같은 패키지가 깔리게 해 줍니다.
• 빌드: 리액트⁠·타입스크립트 코드를 브라우저가 읽는 자바스크립트로 바꾸고, 사용자 기기로 보낼 코드를 몇 개 파일로 묶는 단계입니다. Vite 같은 번들러가 이 일을 합니다.
• 번들: 빌드로 묶인 파일입니다. 이 번들이 사용자 기기로 전송돼야 예약 페이지가 동작합니다.

shadcn/ui: 컴포넌트를 내 프로젝트로 가져오기

기능이 늘면 예약하기 버튼, 이름 입력칸, 예약 확인 팝업 같은 요소를 계속 만들어야 합니다. 전부 직접 만들면 손이 많이 가고, 키보드만으로 조작하는 기능 같은 접근성이 빠지기 쉽습니다. 그러면 마우스를 쓰기 어려운 사용자는 팝업에 닿지도 못합니다.

그래서 남이 만든 컴포넌트 라이브러리를 npm으로 설치해 씁니다. 그런데 코드가 설치된 패키지 안에 들어 있어서, 버튼 모양이나 동작을 내 페이지에 맞게 고치려면 우회하는 코드를 따로 짜야 합니다.

shadcn/ui는 라이브러리를 통째로 설치하는 대신 버튼 같은 컴포넌트 코드를 내 프로젝트 안에 파일로 넣어 줍니다. 동작을 바꾸고 싶으면 그 파일을 직접 고치면 됩니다. 접근성을 고려해 만든 컴포넌트를 쓰면서도 내 디자인에 맞게 손볼 수 있어, 요즘 가장 많이 쓰이는 방식입니다.

휴대폰 앱과 데스크톱 앱

리액트 네이티브와 Expo

휴대폰 앱은 보통 안드로이드는 코틀린이나 자바, iOS는 스위프트나 오브젝티브 C로 따로 만들어 같은 앱을 두 번 만들어야 합니다. 리액트 네이티브(React Native)를 쓰면 웹에서 쓰던 리액트 방식으로 두 앱을 함께 만듭니다. 웹페이지를 앱 안에 띄우는 게 아니라, 리액트 컴포넌트를 안드로이드와 iOS 각각의 화면 요소로 바꿔 보여 줍니다. 그래서 웹의 div 대신 View 같은 컴포넌트를 씁니다. AI가 Expo를 언급하면 리액트 네이티브 앱을 쉽게 만들고 배포하게 돕는 프레임워크라고 보면 됩니다.

Electron

데스크톱 앱도 윈도우, 맥OS마다 따로 만들어야 하는 문제가 있습니다. Electron을 쓰면 HTML, CSS, 자바스크립트로 윈도우⁠·맥OS·리눅스 앱을 같은 코드로 만듭니다. 크롬의 바탕인 크로미움(Chromium)과 컴퓨터에서 자바스크립트를 실행하는 Node.js를 앱 안에 함께 넣는 구조입니다. VS Code도 Electron으로 만든 앱입니다. 브라우저를 통째로 넣다 보니 Electron 앱은 설치 용량이 100MB를 넘는 경우가 많습니다.

보안: 비밀 키와 데이터베이스 자물쇠

앱이라도 비밀은 꺼낼 수 있다

웹이든 휴대폰 앱이든 데스크톱 앱이든 화면 코드는 전부 사용자 기기로 내려갑니다. 앱은 설치 파일이라는 형태로 내려갈 뿐입니다. 개발자 도구가 없으니 앱 코드에는 비밀 키를 넣어도 될 것 같지만, 설치 파일을 받은 사람은 누구나 그 안의 문자열을 꺼낼 수 있습니다. 그러면 남이 그 키로 AI 서비스를 쓰고 요금은 앱을 만든 사람에게 청구됩니다.

그래서 비밀 키를 쓰는 코드는 반드시 서버에 둡니다. 서버에서만 실행되는 코드는 사용자 기기로 전송되지 않습니다.

공개 키는 현관 키, 비밀 키는 마스터 키

바이브코딩으로 만든 앱은 화면 코드가 데이터베이스에 바로 연결되는 경우가 많습니다. 이때 Supabase 같은 데이터베이스 서비스의 키가 화면 코드에 들어갑니다. 그래서 Supabase는 키를 두 종류로 나눕니다.

• 공개 키(publishable, 예전 이름 anon): 화면 코드에 넣도록 만든 현관 키입니다. 누구나 볼 수 있고, 로비까지만 들어가게 합니다.
• 비밀 키(secret, 예전 이름 service_role): 모든 문을 여는 마스터 키입니다. 화면 코드에는 절대 넣지 않고 서버에만 둡니다.

RLS는 방마다 거는 자물쇠

방마다 문을 잠가 두지 않으면 현관 키 하나로 모든 방이 열립니다. 누군가 요청을 직접 보내 다른 사람 예약의 결제 상태를 "결제 완료"로 바꿀 수도 있습니다. 그래서 데이터베이스의 표마다, 줄마다 누가 읽고 쓸 수 있는지 자물쇠를 거는데 이것이 RLS(Row Level Security)입니다. AI가 RLS를 꺼내면 "데이터베이스 자물쇠 설정"이라고 이해하면 됩니다.

실제로 사고가 난 사례도 있습니다.

• 2025년 Lovable로 만든 앱들을 조사한 보안 공개(Matt Palmer)에서는 RLS 설정이 빠진 앱이 여럿 발견됐고, 한 앱은 결제하지 않고도 결제 완료 기록을 저장할 수 있었습니다.
• 2026년 2월 보안회사 Wiz는 AI 에이전트 소셜 네트워크 Moltbook이 웹사이트 자바스크립트에 Supabase 공개 키를 넣은 채 RLS를 걸지 않아, 누구나 데이터베이스 전체를 읽고 쓸 수 있었다고 공개했습니다. API 인증 토큰 약 150만 개와 이메일 주소 약 3만 5천 개가 노출됐습니다. Wiz는 RLS가 제대로 설정돼 있었다면 공개 키는 노출돼도 안전했다고 짚었습니다.

예약하기 버튼 하나로 다시 따라가기

• 예약 페이지를 열면 HTML, CSS, 자바스크립트 파일이 사용자 기기로 전송됩니다.
• 화면은 리액트 컴포넌트로 나뉘어 있습니다.
• 컴포넌트끼리 주고받는 데이터는 타입스크립트가 미리 검사했습니다.
• 빌드가 컴포넌트들을 번들로 묶어 보냈습니다.
• 휴대폰 앱이면 리액트 네이티브로, 데스크톱 앱이면 Electron으로 만든 앱을 사용자가 설치한 것입니다.
• 여기까지가 사용자 기기, 곧 클라이언트 쪽입니다.
• 비밀 키를 쓰는 코드는 웹이든 앱이든 서버 쪽에 둡니다.
• 화면 코드가 데이터베이스에 바로 붙는다면 RLS 자물쇠를 한 번 더 확인합니다.

바이브코딩이라는 말을 처음 쓴 안드레이 카파시(Andrej Karpathy)는 2025년 메뉴 사진 앱 MenuGen을 바이브코딩으로 만든 뒤 블로그에 이렇게 적었습니다. 리액트로 화면을 빠르게 완성해 80% 끝났다고 느꼈는데, 실제로는 20%에 가까웠다는 것입니다. 남은 일은 API 키, 배포, 로그인, 결제였고 모두 서버 쪽이었습니다. AI는 화면을 누구보다 빨리 만듭니다. 어떤 코드를 사용자 기기로 보내고 어떤 코드를 서버와 데이터베이스에 남길지는 두 영역의 차이를 아는 사람이 정해야 합니다.

AI에게 바로 쓸 수 있는 점검 요청

만든 서비스가 있다면 아래 문장을 코딩 에이전트에게 그대로 보내 점검받을 수 있습니다.

이 프로젝트에서 사용자 기기(브라우저·앱)로 전송되는 코드에 비밀 키나 secret 값이 들어 있는지 찾아 줘.
있으면 서버 쪽 코드로 옮기고 환경 변수로 바꿔 줘.
Supabase를 쓴다면 모든 테이블에 RLS가 켜져 있는지, 정책이 본인 데이터만 읽고 쓰게 되어 있는지 표로 정리해 줘.