1-1. 웹 서비스는 어떻게 작동할까?
라이프오브파이
VIBE CODING.
카테고리
- 바이브코딩
🧑🏻💻 Source : unsplash.com
1장. 웹 서비스는 어떻게 작동할까?
부제 : 눈에 보이는 세상과 보이지 않는 세상의 대화
우리가 매일 쓰는 앱, 사실은 "대화 중"
아침에 눈을 뜨자마자 인스타그램을 열어본다고 해봅시다. 피드가 열리고, 친구의 사진이 뜨고, 좋아요 버튼을 누르면 하트 색이 변하죠. 그 몇 초 사이에 스마트 폰에서는 무슨 일이 일어날까요? 사실, 그 짧은 순간 동안 여러분의 스마트폰은 인스타그램의 서버와 "대화"를 하고 있습니다.
스마트폰(혹은 브라우저)이 "이 사진들 좀 보여줘!"라고 요청(Request)을 보내면, 서버는 "알겠어, 여기에 네 친구 사진들이야."라며 응답(Response)을 보내주는 것이죠.
이 대화를 눈에 보이게 바꿔 표현하면 이렇게 됩니다.
[스마트 폰] → "사진 목록 좀 보여줘요!" ← "여기 있습니다! (사진 데이터 전달)"
이처럼 요청과 응답(Request & Response)이 오가는 구조가 모든 웹 서비스의 기본입니다. 우리가 '클릭한다', '검색한다', '로그인한다'는 모든 행동은 결국 서버와의 대화이자 데이터의 왕복인 셈입니다.
클라이언트와 서버 ― 두 세계의 협력
이제 이 대화의 주인공 두 명을 좀 더 알기 쉽게 정리해볼까요?
•
클라이언트(Client): 사용자가 직접 보는 쪽, 즉 스마트폰 앱이나 웹 브라우저 화면입니다.
•
서버(Server): 데이터를 저장하고 처리하는 보이지 않는 쪽, 즉 컴퓨터의 뒤편에서 일하는 두뇌입니다.
인스타그램을 예로 들면 이렇습니다.
역할 | 하는 일 | 예시 |
클라이언트 | 사용자가 보는 화면을 표시하고 입력을 받음 | 인스타그램 앱, 웹브라우저 |
서버 | 데이터를 보관하고 처리한 뒤 클라이언트에 전달 | 인스타그램 서버 (사진, 댓글, 좋아요 기록 저장) |
즉, 클라이언트는 "나 보여줘!", "이거 저장해줘!" 같은 일을 요청하고, 서버는 "여기 있어." 혹은 "저장 완료했어."라고 응답합니다. 이 둘의 관계를 식당 비유로 표현하면 아주 쉽습니다.
•
손님(클라이언트): 주문을 하는 사람
•
서버(Server): 주문을 받아 요리를 내주는 주방
•
메뉴판(API): 서로 어떤 주문이 가능한지 알려주는 규칙
손님이 주방에 직접 들어가서 요리를 만들지 않듯, 앱 사용자도 서버에 직접 접근하지 않습니다. 그 둘의 사이에는 일반적으로 API라는 메뉴판이 있어서 "이런 방식으로 주문하세요"라고 정해져 있죠. 물론 설계에 따 프론트에서 백엔드로 직접 접근도 가능합니다만, 보안상의 취약점을 야기하기도 합니다.
요청과 응답의 여정
웹 서비스의 작동 과정을 한 편의 여행처럼 따라가볼까요?
1.
2.
브라우저는 이 주소를 실제 서버의 위치(IP 주소)로 변환합니다.
3.
그 주소로 요청(Request)을 보냅니다.
4.
서버는 요청을 확인하고, 필요한 데이터를 데이터베이스에서 꺼냅니다.
5.
꺼낸 데이터를 응답(Response)으로 보내줍니다.
6.
브라우저는 받은 데이터를 HTML, CSS, JavaScript를 이용해 예쁜 화면으로 그려줍니다.
이 과정을 그림으로 나타내면 이렇게 됩니다.
[브라우저] → (요청) → [서버] → (데이터 조회) → [데이터베이스]
↓
[브라우저에 표시] ← (응답)
이 단순한 흐름이 바로 모든 웹 서비스의 기본 구동 원리입니다. 단 1초 안에 수십 번의 요청과 응답이 오가며 앱이 살아 움직이죠.
웹앱의 구동을 이해하는 세 가지 핵심 구성요소
웹 서비스의 구동에 관여하는 기본 개념은 크게 세 가지로 나눌 수 있습니다.
1.
프론트엔드 (Frontend) — 사용자가 보는 세상
HTML: 구조 (건물의 뼈대)
CSS: 스타일 (색, 옷, 인테리어)
JavaScript: 행동 (움직임, 반응)
2.
백엔드 (Backend) — 보이지 않는 세상
서버 로직: 요청을 처리하고 데이터를 가공
데이터베이스: 정보를 저장하고 불러옴
3.
API (Application Programming Interface) — 두 세상을 잇는 다리
프론트엔드와 백엔드가 서로 "언어를 맞춰서" 통신할 수 있도록 규칙을 정한 것
대부분의 경우에서 이 세 가지 개념들이 만나면, 하나의 웹 서비스가 완성됩니다. 즉, 프론트엔드가 사용하는 사람을 위한 화면이라면, 백엔드는 실제 서비스 구현을 위한 공간이죠.
'풀스택 서비스'라는 단어의 의미
풀스택이란, 화면을 그리는 프론트엔드부터 데이터를 처리하는 백엔드까지 하나의 흐름으로 개발할 수 있다는 뜻입니다.
즉, 단순히 화면만 만드는 개발자가 아니라, 그 화면이 데이터와 연결되어 실제로 작동하는 서비스 전체를 설계할 수 있는 개발자를 의미합니다. 다행히 바이브 코딩의 개념이 발전하고 관련된 도구들이 고도화됨에 따라 풀스택 서비스를 비개발자 한명이 모두 인공지능을 활용하여 개발하는 것이 가능한 세상이 되었습니다.
•
프론트엔드(Frontend): 사용자가 직접 보는 화면
•
백엔드(Backend): 데이터를 처리하고 보관하는 서버 혹은 컴퓨팅 자원
•
데이터베이스(Database): 정보를 저장하는 공간
이 세 부분이 하나로 연결되어 돌아가는 구조가 바로 풀스택(Full Stack)입니다.
프론트엔드는 왜 '리액트(React)'로?
이 책에서는 프론트엔드 기술로 React를 사용합니다. 그 이유는 단순합니다. React는 "화면을 쪼개고, 재사용하며, 데이터가 바뀌면 자동으로 갱신되는" 방식으로 현대적인 웹앱의 사고방식을 가장 잘 보여주기 때문입니다. 예를 들어 인스타그램의 피드처럼, 누군가 좋아요를 누르면 페이지 전체를 새로고침하지 않아도 좋아요 수만 즉시 바뀌는 화면이 있죠. 이런 '부분 갱신'과 '자동 반응형 업데이트'는 React의 핵심 철학인 컴포넌트(Component)와 상태(State) 덕분에 가능합니다.
쉽게 말해, React는 "사용자가 보는 화면을 효율적으로 관리하는 도구"입니다. 이러한 도구들은 프론트엔드 코드를 더 쉽고 효율적으로 작성할 수 있도록 도와주지만, 최종적으로는 브라우저가 이해할 수 있는 순수 자바스크립트 코드로 변환됩니다. 프론트엔드 개발을 위한 대표적인 라이브러리로는 Vue와 Angular 등이 있으며, 이 책에서는 그중에서도 최근 가장 널리 사용되는 React를 중심으로 설명할 예정입니다.
이 책에서는 프론트엔드 기술로 React를 사용합니다. 그 이유는 단순합니다. React는 "화면을 쪼개고, 재사용하며, 데이터가 바뀌면 자동으로 갱신되는" 방식으로 현대적인 웹앱의 사고방식을 가장 잘 보여주기 때문입니다. 예를 들어 인스타그램의 피드처럼, 누군가 좋아요를 누르면 페이지 전체를 새로고침하지 않아도 좋아요 수만 즉시 바뀌는 화면이 있죠. 이런 '부분 갱신'과 '자동 반응형 업데이트'는 React의 핵심 철학인 컴포넌트(Component)와 상태(State) 덕분에 가능합니다.
쉽게 말해, React는 "사용자가 보는 화면을 효율적으로 관리하는 도구"입니다. 이러한 도구들은 프론트엔드 코드를 더 쉽고 효율적으로 작성할 수 있도록 도와주지만, 최종적으로는 브라우저가 이해할 수 있는 순수 자바스크립트 코드로 변환됩니다. 프론트엔드 개발을 위한 대표적인 라이브러리로는 Vue와 Angular 등이 있으며, 이 책에서는 그중에서도 최근 가장 널리 사용되는 React를 중심으로 설명할 예정입니다.
백엔드와 데이터는 누가 담당할까?
React가 화면을 담당한다면, 서버와 데이터는 Node.js, Firebase, Supabase 같은 다양한 백엔드 도구들이 맡습니다. 이들은 모두 각 기능별 역할을 담당하며, 프론트엔드(React)로부터 오는 요청을 받아 데이터를 주고받거나 처리 및 저장을 담당합니다. 특히 예전에는 백엔드 서버를 각 기능(인증, 데이터베이스 등)별로 직접 구현해야 했지만 이제는 BaaS(Backend as a Service)라는 개념의 서비스들(Firebase, Supabase 등) 덕분에 매우 쉽게 바이브 코딩으로 백엔드 기능을 사용할 수 있게 되었습니다.
React가 화면을 담당한다면, 서버와 데이터는 Node.js, Firebase, Supabase 같은 다양한 백엔드 도구들이 맡습니다. 이들은 모두 각 기능별 역할을 담당하며, 프론트엔드(React)로부터 오는 요청을 받아 데이터를 주고받거나 처리 및 저장을 담당합니다. 특히 예전에는 백엔드 서버를 각 기능(인증, 데이터베이스 등)별로 직접 구현해야 했지만 이제는 BaaS(Backend as a Service)라는 개념의 서비스들(Firebase, Supabase 등) 덕분에 매우 쉽게 바이브 코딩으로 백엔드 기능을 사용할 수 있게 되었습니다.
이 둘을 이어주는 다리, API
프론트엔드와 백엔드는 일반적으로 서로 다른 언어를 사용합니다. 그래서 두 세계가 대화하기 위해선 API(Application Programming Interface)라는 중계자가 필요합니다. 클라이언트의 프론트엔드에서 사용자가 "데이터 주세요!"라고 요청하면, API가 그 요청을 서버 혹은 백엔드 서비스로 전달하고, 백엔드가 데이터를 찾아 "여기 있습니다!"라고 돌려주는 것이죠.
즉, 풀스택은 이렇게 요약할 수 있습니다.
[클라이언트 실행 화면] ⇄ [API] ⇄ [서버 로직] ⇄ [데이터베이스]
앞으로 우리가 배우게 될 것은 바로, 이 흐름을 "코딩 없이도 이해하며 구현" 하는 방식입니다.
정리 — 모든 서비스는 '대화'로 이루어진다
웹 서비스는 복잡해 보이지만, 본질은 단순합니다. 요청하고, 응답받고, 보여주는 일의 반복
프론트엔드가 사람의 말을 대신해 요청을 보내고, 백엔드가 컴퓨터의 언어로 응답을 처리하며, 데이터베이스가 그 기억을 저장합니다. 이 웹 서비스들의 각 요소가 어떻게 연결되어 있는지만 이해하면, 여러분은 이미 "코드를 몰라도 서비스 개발을 이해하는 사람", 즉 바이브 코더(Vibe Coder)가 된 것입니다.
요청하고, 응답받고, 보여주는 일의 반복
프론트엔드가 사람의 말을 대신해 요청을 보내고, 백엔드가 컴퓨터의 언어로 응답을 처리하며, 데이터베이스가 그 기억을 저장합니다. 이 웹 서비스들의 각 요소가 어떻게 연결되어 있는지만 이해하면, 여러분은 이미 "코드를 몰라도 서비스 개발을 이해하는 사람", 즉 바이브 코더(Vibe Coder)가 된 것입니다.
다음 장에서는 이 구조를 좀 더 자세히 들여다 볼 예정입니다. "브라우저의 세 축, HTML·CSS·JavaScript"가 어떻게 함께 움직이며 웹페이지의 화면을 완성하는지를 배워보겠습니다.
라이프오브파이
Subscribe to 'LIFEOFPI'
Subscribe to my site to be the first to receive notifications and emails about the latest updates, including new posts.
Join Slashpage and subscribe to 'LIFEOFPI'!
Join Slashpage and subscribe to 'LIFEOFPI'!
2
I
irenechey
API를 허가정도로 생각해도 될까요 넘 어려운 용어예요
라이프오브파이
아 API 는 한 프로그램이 다른 프로그램의 기능을 요청하기 위한 기능이라고 생각하시면 됩니다. 차후에 자세히 다룰 예정이에요. ^^
See latest comments