1. 브라우저만으로는 아무고또 모타죠
처음 JavaScript를 배우면 보통 이런 것들을 만든다.
- 버튼 클릭 이벤트
- DOM 수정
- 애니메이션
- 입력값 처리
이걸 보면 자연스럽게
JavaScript는 화면을 움직이는 언어라고 생각하기 쉽다.
하지만 실제 웹 서비스는 전혀 다른 구조 위에서 움직인다.
예를 들어 이런 기능들을 생각해보자.
- 로그인
- 게시글 목록
- 댓글 작성
- 좋아요
- 상품 주문
이 데이터들은 브라우저 안에 존재하지 않고
모두 서버에 저장되어 있다.
그래서 브라우저는 항상 이런 행동을 한다.
서버에게 요청
→ 데이터 받아오기
→ 화면에 표시즉 브라우저는 사실 데이터를 가져오는 창구에 가깝다.
조금 다른 비유로 생각해보면 이해가 쉽다.
브라우저를 식당 손님이라고 생각해보자.
손님(브라우저)
→ 주문 요청
→ 주방(서버)
→ 요리 제작
→ 음식 전달손님은 요리를 만들 수 없고,
주문하는 것만 할 수 있다.
웹도 똑같다.
브라우저는 데이터를 만들지도 못하고,
저장하지도 못하고,
관리하지도 못한다.
이 역할은 모두 서버가 담당한다.
예를 들어 우리가 어떤 사이트에서 게시글 목록을 본다고 생각해보자.
브라우저는 서버에게 이런 요청을 보낸다.
GET /posts그러면 서버는 이런 데이터를 반환한다.
[
{ "id": 1, "title": "Hello" },
{ "id": 2, "title": "World" }
]그리고 브라우저는 이 데이터를 받아서 화면에 렌더링한다.
결국 웹은 우리가 처음 생각했던 것처럼
화면 → 기능이 구조가 아니라
요청 → 응답 → 화면이 구조로 움직인다.
그래서 웹을 이해할 때는 화면보다 먼저 통신 구조를 이해하는 것이 중요하다.
이제 자연스럽게 다음 질문이 생긴다.
브라우저는 어떤 방식으로 서버에게 요청을 보내는 걸까?
이 질문의 답이 바로 다음에서 등장하는 HTTP다.
2. 웹은 결국 요청과 응답으로 움직인다
앞에서 브라우저는 데이터를 직접 만들거나 저장하지 못한다고 이야기했다.
그래서 브라우저는 항상 서버에게 요청을 보내고, 응답을 받는 방식으로 동작한다.
이때 등장하는 것이 바로 HTTP다.
HTTP는 HyperText Transfer Protocol의 약자로
브라우저와 서버가 데이터를 주고받을 때 사용하는 통신 규칙이다.
조금 쉽게 말하면 브라우저와 서버가
서로 대화할 때 사용하는 약속된 방식이라고 볼 수 있다.
웹에서 어떤 일이 일어나든 결국 이 구조 안에서 움직인다.
브라우저 → 요청(Request)
서버 → 처리
서버 → 응답(Response)
브라우저 → 화면 표시이 흐름은 우리가 웹에서 하는 거의 모든 행동에 적용된다.
- 페이지를 열 때
- 데이터를 조회할 때
- 게시글을 작성할 때
- 댓글을 수정하거나 삭제할 때
이 모든 과정은 결국 요청과 응답의 반복이다.
그래서 웹을 이해할 때는
페이지나 화면보다 먼저 통신 구조를 이해하는 것이 중요하다.
그리고 여기서 한 가지 질문이 자연스럽게 생긴다.
브라우저는 서버에게 단순히 요청만 보내는 것이 아니라
여러 종류의 행동을 요청할 수 있다.
예를 들어
- 데이터를 가져오는 요청
- 새로운 데이터를 만드는 요청
- 데이터를 수정하는 요청
- 데이터를 삭제하는 요청
같은 것들이다.
그렇다면 브라우저는 이런 다양한 행동을 어떻게 구분해서 요청할까?
이 질문의 답이 바로 다음에서 등장하는 HTTP 메서드다.
3. 같은 주소 다른 행동: HTTP 메서드
웹에서 서버에게 요청을 보낼 때는 항상 URL이 존재한다.
예를 들어 이런 주소가 있다고 가정해보자.
/posts이 주소는 게시글과 관련된 자원을 의미한다.
하지만 우리는 이 주소에 대해 여러 가지 행동을 할 수 있다.
게시글 목록을 조회할 수도 있고
새로운 게시글을 만들 수도 있고
게시글을 수정할 수도 있고
게시글을 삭제할 수도 있다.
이때 등장하는 것이 바로 HTTP 메서드다.
HTTP 메서드는 같은 주소라도
어떤 행동을 요청하는지 구분하는 역할을 한다.
GET: 데이터를 가져오는 요청
GET은 데이터를 조회할 때 사용하는 메서드다.
예를 들어 게시글 목록을 가져오는 요청은 이렇게 표현된다.
GET /posts이 요청의 의미는 단순하다.
/posts에 있는 데이터를 보내주세요GET 요청은 서버의 데이터를 변경하지 않고
데이터를 조회할 때 사용된다.
POST: 새로운 데이터를 만드는 요청
POST는 새로운 데이터를 생성할 때 사용하는 메서드다.
예를 들어 새로운 게시글을 작성할 때는 이런 요청이 만들어진다.
POST /posts이 요청은 보통 본문(body)에 데이터를 담아 서버로 보낸다.
{
"title": "Hello",
"content": "First post"
}서버는 이 데이터를 받아서 새로운 게시글을 생성한다.
PUT과 PATCH: 데이터를 수정하는 요청
데이터를 수정할 때는 PUT과 PATCH를 사용한다.
두 메서드는 비슷해 보이지만 역할이 다르다.
- PUT → 데이터를 전체 교체
- PATCH → 일부만 수정
예를 들어 게시글을 수정하는 요청은 이렇게 보낼 수 있다.
PATCH /posts/1이 요청은 게시글 일부 정보를 수정한다는 의미다.
DELETE: 데이터를 삭제하는 요청
DELETE는 데이터를 삭제할 때 사용하는 메서드다.
예를 들어 게시글 하나를 삭제하는 요청은 이렇게 표현된다.
DELETE /posts/1이 요청의 의미는 간단하다.
id가 1인 게시글을 삭제해주세요이처럼 HTTP 메서드는 같은 URL이라도
어떤 행동을 할 것인지 구분하는 역할을 한다.
정리하면 다음과 같다.
- GET: 조회
- POST: 생성
- PUT: 전체 수정
- PATCH: 부분 수정
- DELETE: 삭제
그래서 웹 API를 설계할 때는
URL + HTTP 메서드 조합으로 동작을 정의한다.
이제 여기서 또 하나의 궁금증이 생긴다.
우리가 요청을 보냈을 때
서버는 요청이 성공했는지 실패했는지 어떻게 알려줄까?
이 역할을 하는 것이 바로 다음에서 등장하는 HTTP 상태 코드다.
4. 열려라 상태창: HTTP 상태 코드
요청의 결과를 알려주는 숫자
브라우저가 서버에게 요청을 보내면
서버는 단순히 데이터만 보내는 것이 아니라 요청의 처리 결과도 함께 알려준다.
이때 사용하는 것이 HTTP 상태 코드다.
HTTP 상태 코드는 요청이
성공했는지, 문제가 있었는지, 혹은 다른 처리가 필요한지를 나타내는 숫자다.
브라우저는 이 코드를 보고 요청 결과를 판단한다.
대표적인 상태 코드
예를 들어 어떤 페이지를 요청했을 때
서버는 이런 응답을 보낼 수 있다.
200 OK이 코드는 요청이 정상적으로 처리되었다는 의미다.
하지만 항상 성공하는 것은 아니다.
요청한 데이터가 없거나, 서버에 문제가 생길 수도 있다.
예를 들어 이런 경우가 있다.
404 Not Found이 코드는 요청한 자원을 서버에서 찾을 수 없을 때 반환된다.
또는 서버 내부에서 오류가 발생하면 이런 응답이 돌아올 수도 있다.
500 Internal Server ErrorHTTP 상태 코드는
요청이 어떻게 처리되었는지 알려주는 신호 역할을 한다.
상태 코드는 보통 첫 번째 숫자로 큰 의미를 구분한다.
- 2xx → 요청 성공
- 4xx → 클라이언트 요청 문제
- 5xx → 서버 오류
그래서 브라우저나 JavaScript 코드에서는
이 상태 코드를 확인해서 성공 처리나 오류 처리를 분기하게 된다.
웹 개발을 하다 보면 이 숫자들을 굉장히 자주 보게 된다.
특히 개발자 도구의 Network 탭에서 쉽게 확인할 수 있다.
그렇다면 서버와 통신할 때
URL은 어떤 기준으로 설계해야 할까?
이 질문에서 등장하는 개념이 바로 REST API다.
5. 로마에선 로마법, URL에선 REST API
규칙 없는 URL, 복잡복잡의 지름길
서버와 통신할 때는 항상 URL을 사용한다.
예를 들어 게시글과 관련된 기능을 만든다고 가정해보자.
규칙 없이 API를 만든다면 URL이 이런 식으로 만들어질 수도 있다.
/getPosts
/createPost
/updatePost
/deletePost이 방식도 동작은 하지만
URL이 행동 중심으로 설계되어 있어 구조가 점점 복잡해질 수 있다.
기능이 많아질수록
/getUserPosts
/createUserPost
/deleteUserPost처럼 URL이 계속 늘어나게 된다.
그래서 웹에서는 API를 설계할 때
일관된 규칙을 사용하는 접근 방식이 필요해졌다.
여기서 등장한 개념이 바로 REST다.
자원을 기준으로 URL을 설계하는 방식: REST
REST는 Representational State Transfer의 약자로
웹에서 API를 설계할 때 사용하는 규칙이다.
REST의 핵심 아이디어는 단순하다.
URL은 자원을 표현한다.
예를 들어 게시글 API라면 URL은 이렇게 표현된다.
/posts
/posts/1여기서 /posts는 게시글이라는 자원(resource)을 의미하고
/posts/1은 id가 1인 게시글을 의미한다.
즉 REST에서는 URL이 데이터의 대상을 표현한다.
행동은 URL이 아니라 HTTP 메서드가 담당
REST 구조에서는 행동을 URL에 넣지 않는다.
대신 HTTP 메서드가 그 역할을 담당한다.
예를 들어 게시글 API는 이렇게 표현할 수 있다.
GET /posts
POST /posts
PATCH /posts/1
DELETE /posts/1여기서 /posts는 게시글이라는 자원을 나타내고
각 요청의 행동은 HTTP 메서드가 결정한다.
그래서 REST API는 보통 이런 구조로 정리한다.
- URL → 자원
- HTTP 메서드 → 행동
이 방식의 장점은 API 구조가 일관되고 이해하기 쉬워진다는 점이다.
그래서 대부분의 웹 서비스는
이와 같은 REST 방식으로 API를 설계한다.
그렇다면 서버는 이런 요청에 대해
어떤 형식으로 데이터를 응답할까?
이때 등장하는 것이 바로 JSON이다.
6. 서버와 브라우저의 PAPAGO: JSON
서로 다른 환경이 데이터를 주고받는 문제
브라우저와 서버는 서로 다른 환경에서 동작한다.
- 브라우저 → JavaScript
- 서버 → 다양한 언어 (Java, Python, Node.js 등)
서로 사용하는 언어가 다르기 때문에
데이터를 그대로 보내면 서로 이해하지 못할 가능성이 생긴다.
예를 들어 JavaScript 객체는 이렇게 생겼다.
const post = {
id: 1,
title: "Hello",
};하지만 이 객체 구조는 JavaScript 문법이다.
서버가 다른 언어로 만들어져 있다면
이 객체를 그대로 이해하기 어렵다.
그래서 웹에서는 데이터를 주고받을 때
모두가 이해할 수 있는 공통 형식을 사용한다.
이 역할을 하는 것이 바로 JSON이다.
데이터를 표현하는 공통 형식: JSON
JSON은 JavaScript Object Notation의 약자로
데이터를 표현하기 위한 텍스트 기반 데이터 형식이다.
JSON의 구조는 JavaScript 객체와 매우 비슷하다.
예를 들어 이런 JSON 데이터가 있을 수 있다.
{
"id": 1,
"title": "Hello"
}이 구조는 언어와 상관없이
텍스트 형태로 데이터를 표현한다.
그래서 브라우저든 서버든
같은 방식으로 데이터를 읽을 수 있다.
즉 JSON은 웹에서 데이터를 주고받을 때 사용하는
공통 언어라고 볼 수 있다.
서버 응답은 대부분 JSON
웹 API를 호출하면
서버는 보통 JSON 형식으로 데이터를 응답한다.
예를 들어 게시글 목록 요청을 보내면
이런 응답이 돌아올 수 있다.
[
{ "id": 1, "title": "Hello" },
{ "id": 2, "title": "World" }
]브라우저는 이 JSON 데이터를 받아서
JavaScript에서 사용할 수 있는 형태로 변환한 뒤
화면에 렌더링한다.
그렇다면 여기서 한 가지 궁금증이 생긴다.
JSON은 텍스트 기반 데이터 형식이다.
하지만 JavaScript에서는 보통 객체 형태로 데이터를 다룬다.
그렇다면 우리는 객체와 JSON 변환을 어떻게 해야 할까?
이 역할을 하는 것이 바로 다음에서 등장하는
JSON.stringify와 JSON.parse다.
7. 객체와 문자열 사이를 오가는 두 개의 문
앞에서 JSON은 텍스트 기반 데이터 형식이라고 했다.
하지만 JavaScript에서는 보통 데이터를 객체 형태로 다룬다.
예를 들어 이런 데이터가 있다고 해보자.
const post = {
id: 1,
title: "Hello",
};이 객체는 JavaScript에서는 바로 사용할 수 있지만
서버와 통신할 때는 JSON 문자열 형태로 변환해야 한다.
반대로 서버에서 받은 JSON 데이터는
JavaScript에서 사용하려면 객체 형태로 변환해야 한다.
이 변환을 담당하는 것이 바로
JSON.stringify와 JSON.parse다.
객체를 JSON 문자열로: JSON.stringify
JSON.stringify는 JavaScript 객체를
JSON 문자열로 변환하는 함수다.
예를 들어 이런 객체가 있다고 해보자.
const post = {
id: 1,
title: "Hello",
};이 객체를 JSON 문자열로 변환하면 이렇게 된다.
JSON.stringify(post);결과는 다음과 같다.
{ "id": 1, "title": "Hello" }이 문자열은 JSON 형식의 데이터이기 때문에
서버로 전송할 수 있다.
그래서 새로운 데이터를 서버로 보낼 때
보통 이런 코드가 등장한다.
fetch("/posts", {
method: "POST",
body: JSON.stringify(post),
});즉 객체 → JSON 문자열 변환을 담당하는 것이
JSON.stringify다.
JSON 문자열을 객체로 바꾸는 JSON.parse
반대로 서버에서 데이터를 받으면
JSON 문자열을 JavaScript 객체로 변환해야 한다.
이때 사용하는 것이 JSON.parse다.
예를 들어 이런 JSON 데이터가 있다고 해보자.
{ "id": 1, "title": "Hello" }이 데이터를 JavaScript에서 사용하려면
이렇게 변환한다.
JSON.parse(`{"id":1,"title":"Hello"}`);그러면 결과는 다시 객체 형태가 된다.
{
id: 1,
title: "Hello"
}그래서 JSON.parse는
JSON 문자열 → JavaScript 객체 변환을 담당한다.
두 함수의 역할 정리
정리하면 이 두 함수는 서로 반대 역할을 한다.
- JSON.stringify : 객체 → JSON 문자열
- JSON.parse : JSON 문자열 → 객체
웹 통신에서는 객체와 JSON 사이의 변환이 반복적으로 발생한다.
- 데이터를 보낼 때 →
JSON.stringify - 데이터를 받을 때 →
JSON.parse
이 과정을 이해하면
브라우저와 서버 사이의 데이터 흐름이 훨씬 명확해진다.
이제 실제 통신이 어떻게 이루어지는지
브라우저 개발자 도구에서 직접 확인해보자.
8. 진짜 통신은 Network 탭에
지금까지 HTTP, REST API, JSON 같은 개념을 살펴봤다.
하지만 웹에서 실제 통신이 어떻게 이루어지는지는 브라우저 개발자 도구에서 직접 확인할 수 있다.
요청과 응답을 직접 확인하는 곳
브라우저에는 개발자 도구(Developer Tools)라는 기능이 있다.
여기에는 웹 페이지의 동작을 확인할 수 있는 여러 탭이 있는데, 그중 하나가 Network 탭이다.
Network 탭은 브라우저가 서버와 주고받는 모든 요청과 응답을 기록한다.
예를 들어 어떤 웹 페이지를 열면 브라우저는 자동으로 여러 요청을 보낸다.
- HTML 요청
- CSS 요청
- JavaScript 요청
- 이미지 요청
- API 요청
이 요청들은 모두 Network 탭에 기록된다.
요청과 응답의 정보가 모두 보인다.
Network 탭에서 하나의 요청을 선택하면
서버와 통신하면서 오간 여러 정보를 확인할 수 있다.
대표적으로 다음과 같은 것들이 보인다.
- 요청 URL
- HTTP 메서드
- HTTP 상태 코드
- 응답 데이터
예를 들어 API 요청을 확인하면
서버가 반환한 JSON 데이터도 직접 볼 수 있다.
그래서 웹 개발을 하다 보면 Network 탭은
가장 자주 확인하게 되는 도구 중 하나가 된다.
지금까지 살펴본 것들의 연결고리
지금까지 살펴본 개념들은 사실 모두 Network 탭에서 확인할 수 있다.
예를 들어 어떤 API 요청을 보면 다음과 같은 정보가 보인다.
GET /posts
Status: 200
Response: JSON 데이터여기에서 우리가 앞에서 배운 것들이 모두 등장한다.
- HTTP 메서드
- HTTP 상태 코드
- JSON 응답
즉 Network 탭은 웹 통신이 실제로 어떻게 이루어지는지 보여주는 창이라고 볼 수 있다.
이제 우리는
- 웹이 요청과 응답 구조로 움직인다는 것
- HTTP 메서드로 요청의 행동을 구분한다는 것
- 상태 코드로 요청 결과를 확인한다는 것
- JSON으로 데이터를 주고받는다는 것
까지 살펴봤다.
9. 핵심정리
웹은 단순히 화면을 보여주는 기술이 아니라
브라우저와 서버가 요청과 응답을 주고받는 통신 구조 위에서 동작한다.
브라우저는 서버에게 요청을 보내고
서버는 요청을 처리한 뒤 응답을 반환한다.
이때 브라우저와 서버가 통신할 때 사용하는 규칙이 HTTP다.
HTTP에서는 같은 URL이라도
HTTP 메서드를 통해 요청의 행동을 구분한다.
대표적으로 다음과 같은 메서드들이 있다.
- GET → 데이터 조회
- POST → 데이터 생성
- PUT → 전체 수정
- PATCH → 부분 수정
- DELETE → 데이터 삭제
요청이 처리되면 서버는 HTTP 상태 코드를 통해
요청 결과가 성공인지 실패인지 알려준다.
대표적인 상태 코드 범주는 다음과 같다.
- 2xx → 요청 성공
- 4xx → 클라이언트 요청 오류
- 5xx → 서버 오류
또한 웹에서는 데이터를 주고받을 때
JSON이라는 텍스트 기반 데이터 형식을 사용한다.
JavaScript에서는 JSON 데이터를 다루기 위해
다음 두 가지 변환을 사용한다.
- JSON.stringify: JavaScript 객체 → JSON 문자열
- JSON.parse: JSON 문자열 → JavaScript 객체
마지막으로 브라우저의 Network 탭을 사용하면
이러한 통신 과정을 실제로 확인할 수 있다.
- 요청 URL
- HTTP 메서드
- HTTP 상태 코드
- JSON 응답
즉 웹은 요청 → 처리 → 응답 이라는 흐름 위에서 움직이며
HTTP, REST API, JSON 같은 개념들은 모두
이 통신 구조를 이해하기 위한 핵심 요소들이다.
이 구조를 이해하면 브라우저와 서버 사이에서
데이터가 어떻게 오가는지 훨씬 명확하게 보이기 시작한다.
