웹의 구조
프론트엔드, 백엔드, 서버, 서버리스
프론트엔드와 백엔드
웹 앱은 크게 두 부분으로 나뉜다. 프론트엔드(Frontend)는 사용자가 직접 보고 만지는 화면이다. 버튼, 입력창, 이미지, 애니메이션 — 브라우저에서 보이는 모든 것이 프론트엔드다.
백엔드(Backend)는 사용자 눈에 보이지 않는다. 데이터를 저장하고, 로그인을 처리하고, 결제를 실행하고, AI API를 호출하는 일 — 모두 백엔드에서 일어난다.
🍽️ 레스토랑 비유
프론트엔드 = 홀(dining area) — 손님이 앉고, 메뉴를 보고, 음식을 받는 공간. 인테리어, 조명, 테이블 배치가 사용자 경험을 결정한다.
백엔드 = 주방(kitchen) — 손님 눈에 안 보이지만 실제 요리가 만들어지는 곳. 재료 관리, 조리 순서, 위생 규칙이 품질을 결정한다.
API = 주문서 — 홀과 주방 사이를 오가는 의사소통 수단. “테이블 3번, 파스타 1개”처럼 정해진 형식으로 요청과 응답이 오간다.
API — 프론트엔드와 백엔드의 대화
API(Application Programming Interface)는 프론트엔드와 백엔드가 대화하는 규칙이다. 프론트엔드가 “이 사용자의 데이터를 줘”라고 요청하면, 백엔드가 정해진 형식으로 응답한다.
바이브 코딩에서 가장 흔한 실수 중 하나가 API 설계를 AI에게 통째로 맡기는 것이다. AI는 “돌아가는” API를 만들어주지만, 일관성 없는 API는 앱이 커질수록 혼란을 만든다.
💡 바이브 코딩 팁
{ success, data, error } 형식으로 통일해줘”라고 지시하면 일관성 있는 API가 나온다.URL과 라우팅
URL(Uniform Resource Locator)은 웹의 주소 체계다. myapp.com/dashboard에서 /dashboard 부분이 라우트(route)다. 이 주소에 따라 어떤 페이지를 보여줄지 결정하는 것을 라우팅(routing)이라 한다.
Next.js에서는 파일 구조가 곧 라우팅이다. app/dashboard/page.js 파일을 만들면 자동으로 /dashboard 주소가 생긴다. 별도의 설정이 필요 없다.
서버와 서버리스
서버(Server)는 24시간 켜져 있는 컴퓨터다. 사용자가 앱에 접속하면 이 컴퓨터가 요청을 받아 처리한다. 직접 서버를 운영하면 모든 것을 통제할 수 있지만, 관리 부담이 크다. 트래픽이 몰리면 서버가 다운될 수 있고, 보안 업데이트도 직접 해야 한다.
서버리스(Serverless)는 서버가 없다는 뜻이 아니다. 서버 관리를 클라우드 업체(AWS, Google Cloud, Vercel 등)에게 맡기는 것이다. 요청이 올 때만 함수가 실행되고, 안 쓰면 비용이 0원이다. 트래픽이 갑자기 10배로 늘어도 자동으로 확장된다.
🏠 비유: 자가 vs 에어비앤비
서버 = 자기 집 소유 — 내 마음대로 고치고 바꿀 수 있지만, 수도관이 터져도 내가 고쳐야 한다.
서버리스 = 에어비앤비 — 관리는 호스트가 해주고, 나는 필요할 때만 쓰고 비용을 낸다. 대신 벽지 색깔은 못 바꾼다.
💡 바이브 코딩에서는?
배포(Deploy)
배포란 내 컴퓨터에서만 돌아가는 앱을 인터넷에 올려서 누구나 접속할 수 있게 만드는 것이다. Replit은 “Deploy” 버튼 하나로 이 과정을 해결한다. Vercel은 GitHub에 코드를 올리면 자동으로 배포된다.
도메인(Domain)은 앱의 인터넷 주소다. 배포하면 myapp.replit.app 같은 주소가 생기고, 원하면 myapp.com 같은 커스텀 도메인을 연결할 수 있다.