🌐 웹의 기본 개념과 HTTP 완전 정복

 

목차

 

 

백엔드 개발을 시작하려면 가장 먼저 이해해야 할 것이 바로 웹의 동작 원리입니다.

우리가 매일 사용하는 웹 서비스가 어떻게 작동하는지, 클라이언트와 서버가 어떻게 소통하는지 알아야 견고한 백엔드를 설계할 수 있죠.

 

이번 글에서는 웹의 기본 개념부터 HTTP, 그리고 현대 웹 개발의 핵심인 RESTful API까지 차근차근 정리해보겠습니다.

---

🌐 웹은 어떻게 작동할까?

웹(Web)은 World Wide Web의 줄임말로, 인터넷상에서 정보를 공유하기 위한 시스템입니다.

웹의 핵심은 HTTP(HyperText Transfer Protocol)라는 통신 규약을 통해 데이터를 주고받는다는 점이에요.

 

즉, 우리가 브라우저에서 웹사이트를 볼 때마다 HTTP 요청을 보내고 응답을 받는 과정을 반복하고 있는 셈입니다.

---

🔄 클라이언트-서버 모델이란?

웹은 기본적으로 클라이언트-서버 구조(Client-Server Model)로 작동합니다.

• 클라이언트(Client): 웹 브라우저나 모바일 앱처럼 서비스를 요청하는 쪽
• 서버(Server): 요청을 받고, 처리한 후 응답을 돌려주는 쪽

사용자가 웹 브라우저에서 URL을 입력하면 클라이언트는 HTTP 요청을 서버에 보내고, 서버는 처리 결과(HTML, JSON 등)를 응답합니다.

 

📦 비유하자면?

• 클라이언트는 레스토랑의 손님
• 서버는 주방에 주문을 넣고 요리를 내어주는 종업원
• DB는 재료를 보관하는 창고 

클라이언트 - 서버 구조

---

📡 HTTP 요청/응답 구조와 메서드

HTTP는 클라이언트와 서버가 데이터를 주고받기 위한 규칙입니다.

모든 HTTP 통신은 요청(Request)과 응답(Response) 쌍으로 이루어져요.

 

HTTP 요청 예시

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

{
  "name": "김개발",
  "email": "dev@example.com"
}

요청 구성 요소

• 요청 라인: HTTP 메서드 + URL 경로 + HTTP 버전
• 헤더: 요청에 대한 추가 정보
• 바디: 서버에 전송할 데이터 (GET 요청에는 보통 없음)

HTTP 응답 구조

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/users/123

{
  "id": 123,
  "name": "김개발",
  "email": "dev@example.com",  
  "created_at": "2025-01-15T10:00:00Z"
}

주요 HTTP 메서드

메서드	설명
GET	데이터를 조회할 때 사용
POST	데이터를 새로 생성할 때 사용
PUT	전체 데이터를 수정할 때 사용
PATCH	일부 데이터를 수정할 때 사용
DELETE	데이터를 삭제할 때 사용

---

📊 HTTP 상태코드

서버는 응답과 함께 HTTP 상태 코드를 보내 클라이언트에게 결과를 알려줍니다.

200번 대는 성공, 400번대는 클라이언트 오류, 500번대는 서버 오류를 나타냅니다.

주요 상태 코드

상태 코드	의미
200 OK	요청이 성공적으로 처리됨
201 Created	리소스 생성 성공
204 No Content	응답 본문 없음 (예: 삭제 성공)
400 Bad Request	잘못된 요청
401 Unauthorized	인증 실패
403 Forbidden	권한 없음
404 Not Found	존재하지 않는 리소스
500 Internal Server Error	서버 내부 오류

상태 코드만 잘 읽어도 문제를 빠르게 파악할 수 있어요!

---

🎯 RESTful API란?

REST(Representational State Transfer)는 웹의 기본 원칙에 따라 API를 설계하는 방식입니다.

REST 스타일을 따르는 API를 RESTful API라고 부릅니다.

 

REST 설계의 핵심 원칙

1. 자원(Resource) 기반

• URL은 자원을 표현해야 함
• 예: /users, /products/1, /posts/12/comments

2. HTTP 메서드를 통한 행위 표현

• GET /users → 사용자 목록 조회
• POST /users → 사용자 생성
• DELETE /users/1 → 사용자 삭제

3. 무상태성(Stateless)

• 서버는 클라이언트의 상태를 저장하지 않음
• 각 요청은 독립적이어야 함

4. 표준 응답 형식(JSON)

• 응답은 일관된 구조(JSON)를 갖도록 설계

💡 RESTful하지 않은 예

❌ GET /createUser?id=1
❌ POST /getUserList  
❌ GET /deleteUser?id=123

⭕ POST /users
⭕ GET /users
⭕ DELETE /users/123

---

📚 API 문서화 방법

실제 프로젝트에서는 개발자 간의 협업을 위해 API를 문서화하는 것이 매우 중요합니다.

API 명세가 명확하면, 개발자뿐 아니라 QA, 프론트엔드, 기획자도 이해하기 쉬워요.

Swagger (OpenAPI)

• 가장 널리 사용되는 문서화 도구
• 코드에 어노테이션을 추가하면 문서가 자동 생성됨
• YAML 또는 JSON 기반

paths:
  /users:
    get:
      summary: Get user list
      responses:
        '200':
          description: Success

 

Spring Rest Docs

• 테스트 코드 기반으로 API 문서를 생성
• 테스트가 통과해야만 문서가 만들어져 신뢰도가 높음
• Spring 기반 프로젝트에서 많이 사용됨

mockMvc.perform(get("/users"))
  .andDo(document("get-users",
    responseFields(
      fieldWithPath("[].id").description("사용자 ID"),
      fieldWithPath("[].name").description("사용자 이름")
    )
  ));

---

🧡 마무리하며

이번 글에서는 백엔드 개발의 기초 중 기초인 웹의 구조와 HTTP에 대해 알아보았습니다.

 

✏️  핵심 포인트 정리

• 클라이언트-서버 모델: 요청과 응답의 기본 구조
• HTTP 메서드: 각 메서드의 목적에 맞는 사용법
• 상태코드: 적절한 상태코드로 명확한 응답 전달
• RESTful API: 일관되고 예측 가능한 API 설계 원칙
• API 문서화: 개발자 친화적인 문서 작성의 중요성

 

이 개념들을 정확히 이해하면, 실제 API를 설계하거나 디버깅할 때 큰 도움이 됩니다.

다음 글에서는 실제 API를 구현하며 이 개념들이 어떻게 활용되는지 구체적으로 살펴볼 예정입니다.

 

궁금한 점이나 의견은 댓글로 남겨주세요! 🚀