웹이 돌아가는 원리

앱을 만들다 보면 “프론트는 됐고 이제 백엔드”라는 말을 들어요. 하나였던 게 갑자기 둘로 갈리니까 어라 싶죠. 이 구분부터 잡으면 이후가 훨씬 쉬워져요.

프론트엔드는 사용자 눈에 보이고 직접 만지는 화면 쪽이에요. 버튼, 글자, 색깔, 배치처럼 우리가 화면에서 보는 전부가 여기죠. 식당으로 치면 홀이에요. 손님이 앉는 자리, 메뉴판, 인테리어처럼 겉으로 드러나는 부분이요.

사용자가 “예쁘다 / 불편하다”를 느끼는 건 대부분 프론트엔드예요.

바이브코딩으로 만드는 대부분의 첫 결과물이 프론트엔드예요. 화면이 뜨고 버튼이 눌리는 그 부분이죠. 그러다 “로그인 상태를 저장해야 해”, “데이터를 어딘가 보관해야 해” 같은 게 필요해지면, 그때 뒤쪽 영역인 백엔드가 등장해요.

화면은 다 만들었는데 “이건 백엔드가 있어야 돼요”라는 말을 들으면 살짝 당황스러워요. 눈에 보이는 건 다 됐는데 뭐가 더 필요하다는 걸까요.

백엔드는 화면 뒤에서 데이터를 저장·처리하고 로직을 돌리는 영역이에요. 눈엔 안 보이죠. 식당의 주방이에요. 손님은 주방을 못 보지만, 주문이 실제로 요리되는 곳은 거기잖아요. 로그인 정보 저장, 결제 처리, 데이터 보관 같은 ‘진짜 일’이 백엔드에서 벌어져요.

프론트엔드가 홀이면, 백엔드는 주방이에요. 둘이 붙어야 식당이 돌아가죠.

그래서 단순한 화면이나 소개 페이지는 백엔드 없이도 만들어요. 하지만 “사용자마다 데이터가 달라야 해”, “정보를 저장해둬야 해” 같은 순간 백엔드가 필요해져요. 요즘은 Supabase 같은 도구가 이 백엔드 부분을 많이 대신해줘서, 비전공자도 예전보다 훨씬 수월하게 붙여요.

“이건 서버에서 처리해요”라는 말을 들으면, 그 서버가 어디 있는 건지부터 아리송해요. 내 컴퓨터도 아닌 것 같고, 눈에 보이지도 않고요.

서버는 요청을 받아 처리하고 결과를 돌려주는 컴퓨터예요. 어딘가에 켜져 있는 컴퓨터라고 보면 돼요. 그리고 요청을 보내는 쪽, 그러니까 우리 브라우저나 앱을 클라이언트라고 불러요. 식당으로 치면 손님(클라이언트)이 주문하면 주방(서버)이 만들어 내주는 거죠.

모든 웹은 이 ‘요청 → 처리 → 응답’ 한 판의 반복이에요.

이 그림만 잡으면 많은 게 풀려요. API는 이 주문을 넣는 창구고, 상태 코드는 주방이 “됐어요 / 그런 메뉴 없어요”라고 답하는 신호예요. 서버가 늘 저 멀리 있는 것도 아니에요. 개발 중엔 내 컴퓨터를 임시 서버로 쓰는데, 그게 바로 localhost예요.

코드를 짜다 보면 “이 라이브러리 설치해”, “이건 프레임워크야” 같은 말이 섞여 나와요. 둘 다 남이 만든 코드를 가져다 쓰는 건데, 뭐가 다른지 헷갈리죠. 유명한 도구가 어느 쪽인지도 애매하고요.

차이는 ‘주도권’이에요. 라이브러리는 내가 필요할 때 골라서 부르는 도구 상자예요. 망치 쓰고 싶으면 망치를 꺼내듯, 내가 주도해요. 반면 프레임워크는 전체 틀이 이미 짜여 있고, 그 정해진 자리에 내 코드를 끼워 넣는 조립 키트예요. 이번엔 프레임워크가 주도하고 내 코드가 불려가죠.

“내가 부르면 라이브러리, 나를 부르면 프레임워크”라고 외우면 편해요.

그래서 유명한 도구도 이 기준으로 갈려요. 화면 조각을 골라 쓰는 성격이 강하면 라이브러리에 가깝고(예: React를 라이브러리로 보는 이유), 폴더 구조·규칙까지 정해주면 프레임워크(예: Next.js·Astro)라고 불러요. 처음엔 이 경계가 흐릿하게 느껴져도 괜찮아요. 쓰다 보면 “아, 이건 나를 부르네” 하고 감이 와요.

AI에게 화면을 맡기면 “이건 컴포넌트로 빼자”는 말을 자주 해요. 화면을 ‘뺀다’니, 처음 들으면 무슨 소린가 싶죠. 사실 이건 정리 정돈에 가까운 개념이에요.

컴포넌트는 화면을 이루는 재사용 가능한 조각이에요. 버튼 하나, 카드 하나, 상단 메뉴 하나가 각각 컴포넌트가 될 수 있어요. 레고 블록을 떠올리면 쉬워요. 같은 모양 블록을 여러 자리에 끼워서 큰 걸 조립하잖아요. 화면도 이 조각들을 조립해서 만들어요.

장점은 ‘한 번 만들어 여러 곳에 쓰고, 고칠 땐 한 곳만 고친다’예요.

그래서 “컴포넌트로 빼자”는 건, 반복되는 화면 조각을 하나로 만들어 재사용하자는 뜻이에요. 버튼 스타일을 바꾸고 싶을 때 스무 군데를 다 손대는 대신, 버튼 컴포넌트 하나만 고치면 전부 바뀌죠. 바이브코딩에서 이 개념을 알면 AI에게 “이 부분 컴포넌트로 정리해줘” 하고 더 정확히 시킬 수 있어요.

폼에 잔뜩 입력하다 실수로 새로고침했는데 전부 날아간 경험, 다들 있죠. “왜 방금 친 게 다 사라져요?” 이 억울한 순간에 등장하는 개념이 상태예요.

상태는 화면이 지금 기억하고 있는 값이에요. 입력창에 친 글자, 토글의 켜짐/꺼짐, 장바구니에 담은 개수 같은 것들이요. 화면의 단기 기억이라고 보면 돼요. 문제는 이 기억이 대개 임시라는 거예요. 새로고침하면 기억을 잃고 처음 상태로 돌아가요.

“화면이 지금 뭘 기억하고 있나?”를 다루는 게 상태예요.

그래서 값을 오래 남기려면 상태만으로는 부족하고, 데이터베이스 같은 진짜 저장소가 필요해요. 상태는 ‘지금 이 순간의 기억’, 데이터베이스는 ‘영구 보관’이에요. 바이브코딩에서 “왜 값이 안 남아요?” 하는 버그의 상당수가 이 둘을 헷갈리는 데서 와요. 상태에만 담아두고 저장은 안 한 거죠.

인터넷에서 브라우저와 서버가 대화하려면 공통의 약속이 필요해요. “이렇게 요청하면 이렇게 답한다”는 규칙, 그게 HTTP예요.

HTTPS는 여기에 자물쇠를 채운 버전이에요. 끝에 붙은 S가 Secure(보안)예요. 주고받는 내용을 암호화해서, 중간에 누가 가로채도 못 읽게 해요. 주소창의 자물쇠 아이콘이 그 표시예요.

지금은 HTTPS가 사실상 기본이에요. 로그인·결제가 있는 사이트라면 필수고요. 바이브코딩으로 API를 붙일 때 “http와 https가 섞였다”는 에러를 만나기도 하는데, 대개 한쪽을 https로 맞추면 풀려요.

API 문서를 열면 “이 엔드포인트로 요청하세요” 같은 안내가 나와요. 엔드포인트라는 말이 낯설어서, 이게 주소인지 명령인지 감이 잘 안 오죠.

엔드포인트는 API에서 특정 기능에 접근하는 하나하나의 주소예요. API가 큰 건물이라면, 엔드포인트는 그 안의 부서별 창구 번호죠. ‘3번 창구는 발급, 5번 창구는 조회’처럼요. 회원 정보를 가져오는 주소, 결제를 요청하는 주소가 각각 따로 있고, 필요한 기능의 주소로 요청을 보내는 거예요.

API가 ‘창구 전체’라면, 엔드포인트는 ‘그중 어느 창구냐’예요.

그래서 API 연동은 대부분 이 흐름이에요. 문서에서 필요한 엔드포인트(주소)를 찾고 → 거기로 요청을 보내고 → 돌아온 JSON 응답을 화면에 쓰는 거죠. 엔드포인트가 주소라는 것만 잡으면, “여기로 요청 보내”라는 말이 훨씬 편하게 들려요.

웹사이트는 주소마다 다른 화면을 보여줘요. /about은 소개, /posts/1은 첫 글처럼요. 이 주소와 화면을 이어주는 규칙이 라우팅이에요.

어렵게 들리지만 원리는 안내판과 같아요. “이 주소로 오면 이 화면”이라고 미리 정해두는 거죠. 사용자가 링크를 누르면 라우팅이 맞는 페이지로 길을 잡아줘요.

바이브코딩에선 대개 파일이 곧 주소가 돼요. 요즘 프레임워크는 특정 폴더에 파일을 만들면 그게 자동으로 하나의 주소가 되거든요. 그래서 “페이지 추가해줘”라는 말이 실제로는 라우팅을 하나 늘리는 일이에요.

바이브코딩에서 “이 기능 API로 붙여줘”라는 말을 정말 자주 쓰게 돼요. 날씨, 지도, 결제, AI까지, 웬만한 건 이미 누가 만들어 뒀고, 우리는 그걸 API로 불러다 쓰기만 하면 되거든요.

핵심은 이거예요. API는 남이 만든 기능을 쓰기 위한 정해진 창구예요. 내가 규칙에 맞게 요청을 보내면, 상대가 규칙에 맞게 답을 돌려줘요. 주방이 어떻게 요리하는지 몰라도 종업원에게 주문만 제대로 하면 음식이 나오는 것처럼, API도 내부를 몰라도 사용법(문서)만 알면 쓸 수 있어요.

API의 매력은 안을 몰라도 쓸 수 있다는 것이에요. 바이브코딩이 강한 지점이 바로 여기죠.

그래서 비전공자도 AI 도움을 받아 지도나 결제 기능을 며칠 만에 붙이곤 해요. 다만 창구를 쓰려면 대개 API 키(신분증 같은 것)가 필요하고, 요청 횟수에 제한이나 요금이 붙는 경우가 많아요. 이 두 가지만 미리 알아두면 API는 생각보다 무섭지 않아요.

API 응답을 처음 열어보면 중괄호와 따옴표가 잔뜩 든 텍스트가 나와요. 코드 같기도 하고 아닌 것 같기도 하고. 이게 뭔가 싶은데, 대부분 JSON이에요.

JSON은 데이터를 주고받을 때 쓰는 표준 형식이에요. "이름": "값" 이런 쌍으로 정보를 적어요. 핵심은 사람도 읽을 수 있고, 거의 모든 프로그램이 알아듣는다는 거예요. 나라마다 언어는 달라도 국제 서식은 똑같이 알아보는 것처럼, JSON은 프로그램들 사이의 공통 서식이에요.

그래서 API가 돌려주는 데이터는 십중팔구 JSON이에요.

바이브코딩에서 데이터를 다루면 이 형식을 계속 만나요. 엔드포인트로 요청을 보내면 JSON이 돌아오고, 그중 필요한 값을 꺼내 화면에 뿌리는 식이죠. 처음엔 중괄호가 복잡해 보여도, “이름과 값이 짝지어진 목록”이라고 생각하면 눈에 금방 들어와요.

“데이터를 저장하는 곳”이라는 말은 누구나 알아요. 그런데 막상 Supabase 같은 도구를 켜면 table, row, schema 같은 단어가 쏟아지죠. 저장한다는 개념은 알겠는데, 세팅 화면부터 어라 싶어져요.

데이터베이스는 데이터를 구조에 맞춰 저장하고 꺼내 쓰는 창고예요. 잘 정리된 엑셀 캐비닛을 떠올리면 돼요. 시트(테이블)를 만들고, 그 안에 행(row)으로 데이터를 한 줄씩 쌓아요. ‘회원’ 테이블엔 회원들이, ‘주문’ 테이블엔 주문들이 줄줄이 들어가는 식이죠. 표 구조(schema)를 먼저 정하는 게 낯설 뿐, 개념은 엑셀과 크게 다르지 않아요.

화면의 상태가 ‘순간의 기억’이라면, 데이터베이스는 ‘영구 보관’이에요.

그래서 “새로고침해도 값이 남아야 해”, “사용자마다 데이터가 달라야 해” 같은 순간 데이터베이스가 필요해져요. 요즘은 Supabase·Firebase 같은 도구가 서버 없이도 DB를 붙이게 해줘서, 비전공자도 표 몇 개 만드는 감각만 잡으면 충분히 다뤄요.

로그인을 붙이려고 보면 세션, 토큰, 쿠키, 인증… 비슷비슷한 말이 한꺼번에 쏟아져요. 다 로그인 얘기 같은데 뭐가 뭔지 헷갈리죠. 하나로 꿰면 의외로 단순해요.

인증은 ‘너 진짜 그 사람 맞아?‘를 확인하고, 그 확인 상태를 계속 유지하는 장치예요. 콘서트 입장 팔찌를 떠올려봐요. 입구에서 신분을 한 번 확인하고 팔찌를 채우면, 안에서 이동할 땐 팔찌만 보고 통과시켜주잖아요. 로그인도 똑같아요. 아이디·비번으로 한 번 확인한 뒤, 이후엔 ‘증표’로 계속 통과시켜요.

그 증표를 서버가 기억하는 방식이 세션, 사용자에게 쥐여주는 방식이 토큰이에요.

그래서 세션·토큰은 인증이라는 큰 개념 아래의 ‘팔찌를 다루는 두 방법’이에요. 참고로 여기서 말하는 ‘토큰’은 AI가 글을 세는 토큰과 이름만 같고 완전히 다른 거예요. 그리고 이 로그인을 직접 구현하는 대신, 구글·카카오 계정을 빌려 쓰는 방법이 OAuth예요.

HTTP는 좀 건망증이 있어요. 요청 하나하나를 따로 봐서, 방금 로그인한 사람도 다음 페이지에선 몰라봐요. 쿠키와 세션은 이 건망증을 메우는 장치예요.

쿠키는 브라우저에 저장하는 작은 쪽지예요. 서버가 “너 아까 그 사람 맞지?”를 확인할 표식을 담아둬요. 세션은 그 표식으로 사용자를 알아보는 서버 쪽 방식이고요. 둘이 짝을 이뤄 로그인 상태를 페이지 너머로 이어줘요.

그래서 “로그인이 자꾸 풀려요” 같은 문제는 대개 여기서 나요. 쿠키 만료 시간이 짧거나 설정이 어긋난 경우죠. 바이브코딩으로 로그인을 붙이면 한 번쯤 만나게 되는 이름이에요.

바이브코딩으로 뭔가 만들면 처음엔 내 컴퓨터(로컬)에서만 돌아가요. 주소창에 localhost가 떠 있는 그 상태죠. 이건 나만 볼 수 있어요. 친구에게 링크를 보내도 안 열려요.

배포는 이걸 세상에 내보내는 일이에요. 코드를 서버에 올려서 진짜 주소(도메인)로 아무나 접속할 수 있게 만드는 거죠. 요즘은 도구가 좋아져서, 버튼 몇 번이면 배포가 끝나는 서비스도 많아요. 저도 사이드 프로젝트는 대부분 이런 서비스로 무료로 올려두고 써요.

배포는 개업이에요. 나만 먹던 요리를 손님 앞에 내놓는 순간이죠.

그리고 여기서 그 유명한 말이 나와요. “로컬에선 되는데요.” 내 컴퓨터엔 있던 설정이나 파일이 서버엔 없어서, 배포하자마자 안 되는 일이 자주 생기거든요. 대부분 원인은 환경 차이예요. 그래서 배포는 한 번으로 끝이 아니라, 올리고 → 확인하고 → 고치는 과정을 몇 번 반복하게 돼요. 처음엔 다 그래요.

앱을 세상에 내보내려고 알아보면 ‘배포’와 ‘호스팅’이 같이 나와요. 둘 다 “인터넷에 올린다”는 얘기 같은데 뭐가 다른지 헷갈리죠. 사실 하나는 행위, 하나는 공간이에요.

호스팅은 내 앱을 인터넷에 24시간 띄워둘 공간을 빌리는 거예요. 오프라인 가게로 치면 점포 자리를 임대하는 셈이죠. 배포가 “가게를 여는 행위(개업)“라면, 호스팅은 “그 가게가 들어설 점포”예요. 물건을 진열해도(배포) 점포(호스팅)가 있어야 손님이 찾아오잖아요.

배포는 동사, 호스팅은 명사에 가까워요. 올리는 것과 올려둘 자리의 차이죠.

다행히 요즘은 이 둘이 거의 붙어 다녀요. Vercel·Netlify 같은 서비스는 호스팅 공간을 주면서 배포까지 버튼 몇 번으로 해줘요. 그래서 비전공자도 점포 계약과 개업을 한 번에 끝내는 느낌으로 올려요. 사이드 프로젝트는 이런 서비스의 무료 등급으로도 충분히 굴릴 수 있어요.

내 사이트에 예쁜 주소를 달고 싶어 도메인을 샀어요. 그런데 연결하려니 “DNS 레코드를 설정하세요”라는 안내가 나오죠. 도메인은 알겠는데 DNS는 또 뭔가 싶어 여기서 다들 한 번 막혀요.

도메인은 사이트의 이름 주소, DNS는 그 이름을 실제 서버 위치로 안내하는 주소록이에요. 사람은 naver.com 같은 이름을 외우지만, 컴퓨터는 숫자로 된 실제 위치를 써요. 도메인이 ‘강남 스타벅스’라는 상호라면, DNS는 그 상호를 실제 좌표로 찾아주는 내비예요. 우리가 이름만 치면, DNS가 뒤에서 진짜 서버로 안내하는 거죠.

도메인은 ‘이름’, DNS는 ‘그 이름이 어디를 가리키는지 적어둔 장부’예요.

그래서 “DNS 레코드 설정”은 “이 도메인이 내 서버를 가리키게 장부에 적는 일”이에요. 보통 호스팅 서비스가 알려주는 값을 도메인 구매처에 그대로 넣으면 돼요. 한 가지 유의할 건, 이 장부가 전 세계에 퍼지는 데 시간이 좀 걸려서 연결이 바로 안 될 수 있다는 거예요. 몇 시간 기다리면 대개 풀려요.

바이브코딩으로 뭔가 만들면 주소창에 localhost:3000 같은 게 떠요. 신나서 친구에게 링크를 보냈는데 “안 열려”라는 답이 오죠. 나는 잘 보이는데 왜일까요. 여기서 localhost를 알아야 해요.

localhost는 지금 쓰는 내 컴퓨터 자신을 가리키는 주소예요. 내 방 안에서만 들리는 방송 같은 거죠. 나는 또렷이 듣지만, 문 밖(인터넷)에선 아무도 못 들어요. 그래서 localhost 주소는 내 컴퓨터에서만 열리고, 다른 사람에겐 절대 안 열려요. 고장이 아니라 원래 그런 거예요.

localhost는 ‘개발 중 나만 보는 무대 리허설’이에요.

그럼 남에게 보여주려면? 리허설을 끝내고 진짜 무대에 올려야죠. 그게 배포예요. 내 컴퓨터가 아니라 인터넷상의 서버에 올려서, 누구나 접속할 수 있는 진짜 주소를 갖는 거예요. “localhost는 나만, 배포하면 모두”라고 기억하면 헷갈리지 않아요.

앱을 쓰다 보면 화면에 ‘404’나 ‘500’ 같은 숫자가 뜰 때가 있어요. 뭔가 잘못된 건 알겠는데 이 숫자가 무슨 뜻인지 몰라 막막하죠. 사실 이건 서버가 보내는 짧은 신호예요.

상태 코드는 요청이 어떻게 됐는지를 서버가 숫자로 알려주는 신호예요. 신호등처럼 보면 돼요. 200은 초록불, 잘 됐다는 뜻이에요. 그리고 문제가 생기면 빨간불 계열 숫자가 오죠. 404는 “찾는 페이지가 없어요”, 500은 “서버 쪽에서 뭔가 터졌어요”예요.

앞자리만 봐도 감이 와요. 4로 시작하면 요청한 쪽 문제, 5로 시작하면 서버 쪽 문제예요.

이 규칙 하나만 알아도 디버깅 방향이 잡혀요. 404가 뜨면 주소(엔드포인트)가 틀렸나 보고, 500이 뜨면 서버 코드나 설정을 의심하는 식이죠. AI에게 물을 때도 “500 에러가 나요”라고 숫자를 정확히 전하면, 훨씬 빠르게 원인을 좁혀줘요.

바이브코딩하다 마주치는 가장 유명한 벽 중 하나가 이거예요. 코드는 분명 맞는 것 같은데 “blocked by CORS policy”라는 빨간 에러가 뜨죠. 대체 뭘 잘못했나 싶어 한참 헤매게 돼요.

CORS는 다른 출처(도메인)의 요청을 브라우저가 기본적으로 막는 보안 규칙이에요. 아파트 출입 통제를 떠올려봐요. 등록된 주민은 그냥 통과지만, 낯선 외부인은 경비가 막아서잖아요. 브라우저도 똑같이, 내 사이트가 허락되지 않은 다른 서버에 요청을 보내면 “너 여기 출입 등록됐어?” 하고 막아요. 사용자를 지키기 위한 안전장치죠.

그래서 CORS는 대개 내 코드 잘못이 아니라, 서버 쪽 ‘허용 설정’의 문제예요.

해결의 방향은 서버가 “이 출처는 허용”이라고 응답에 표시해주는 거예요. 비전공자라면 원리를 깊이 팔 필요는 없어요. “CORS 에러 = 출처가 허용 안 됨”이라는 것만 알면, AI에게 “CORS 허용 설정 추가해줘” 하고 정확히 시킬 수 있어요. 이 한 줄을 아느냐가 삽질 시간을 크게 줄여줘요.

분명 코드를 고쳤는데 화면이 그대로일 때가 있어요. 저장도 했고 새로고침도 했는데 옛날 화면이 계속 나오죠. 귀신이 곡할 노릇 같지만, 범인은 대개 캐시예요.

캐시는 자주 쓰는 데이터를 가까이 미리 저장해두고, 다음에 빠르게 꺼내 쓰는 임시 저장소예요. 책상 위에 자주 보는 책을 꺼내 둔 것과 같아요. 매번 서고까지 걸어가는 대신 손 닿는 곳에서 바로 집는 거죠. 덕분에 사이트가 빨라져요. 브라우저·서버 곳곳에 이런 캐시가 있어요.

속도를 위한 좋은 장치지만, 가끔 ‘옛날 것을 계속 보여주는’ 부작용이 있어요.

그래서 바뀐 게 화면에 안 보이면 강력 새로고침으로 캐시를 비우는 게 첫 처방이에요. 이걸 알면 “왜 안 바뀌지?” 하고 코드를 헛되이 뒤지는 시간을 아껴요. 참고로 가까운 서버에 콘텐츠를 미리 저장해 빠르게 주는 배포 뒤의 장치들도 이 캐시 원리를 써요.

PC에서 잘 만든 화면을 폰으로 열었더니 글자가 삐져나오고 배치가 엉망일 때가 있어요. 분명 컴퓨터에선 멀쩡했는데 말이죠. 이때 필요한 개념이 반응형이에요.

반응형은 화면 크기에 맞춰 레이아웃이 자동으로 바뀌게 만드는 방식이에요. 물을 떠올리면 쉬워요. 큰 컵에 담으면 크게, 작은 컵에 담으면 작게, 그 모양에 딱 맞춰 담기잖아요. 반응형 화면도 똑같이 PC에선 넓게 펼치고, 폰에선 좁게 접어서 어디서든 보기 좋게 맞춰줘요.

요즘은 방문자 상당수가 폰으로 봐요. 그래서 반응형은 선택이 아니라 기본이에요.

바이브코딩에서 “폰에서 깨져요”라는 상황을 만나면, AI에게 “모바일 반응형으로 맞춰줘”라고 하면 대부분 정리해줘요. 처음부터 “반응형으로 만들어줘”라고 못박아 시작하면 이 문제를 아예 줄일 수 있고요. 단어 하나 아는 것만으로 재작업이 확 줄어드는 지점이에요.