TIL - 20260527

juni·2026년 5월 27일

TIL

목록 보기

363/468

0527 풀스택 실무 기초 (1/N): HTTP와 클라이언트-서버 구조

✅ 1. 풀스택 개발에서 HTTP가 중요한 이유

HTTP(HyperText Transfer Protocol)는 웹에서 클라이언트와 서버가 데이터를 주고받기 위한 기본 통신 규칙입니다.
사용자가 브라우저에서 버튼을 누르거나 페이지를 이동하거나, React 앱에서 API를 호출하거나, NestJS 서버가 데이터를 응답하는 모든 과정의 중심에 HTTP가 있습니다.
풀스택 개발자는 프론트엔드 화면만 만들거나 백엔드 API만 만드는 것이 아니라, 브라우저 → 네트워크 → 서버 → DB → 응답 → 화면 반영의 전체 흐름을 이해해야 합니다.

➕ 1-1. 실무에서 HTTP를 모르면 생기는 문제

API가 실패했을 때 프론트 문제인지 백엔드 문제인지 구분하기 어렵습니다.
401, 403, 404, 500 같은 상태 코드의 의미를 제대로 판단하지 못합니다.
쿠키, 세션, JWT, CORS, 인증 문제를 해결하기 어렵습니다.
캐싱, SEO, 보안, 성능 최적화의 원리를 이해하기 어렵습니다.
장애가 발생했을 때 Network 탭과 서버 로그를 연결해서 분석하기 어렵습니다.

✅ 2. 클라이언트와 서버 구조

웹 서비스는 기본적으로 클라이언트(Client)와 서버(Server)가 서로 요청과 응답을 주고받는 구조로 동작합니다.

➕ 2-1. 클라이언트란?

클라이언트는 서버에 요청을 보내는 쪽입니다.
보통 사용자가 직접 사용하는 브라우저, 모바일 앱, 프론트엔드 애플리케이션을 의미합니다.
예시
- Chrome, Safari, Edge 같은 웹 브라우저
- React로 만든 웹 앱
- Android/iOS 앱
- Postman 같은 API 테스트 도구

➕ 2-2. 서버란?

서버는 클라이언트의 요청을 받아 처리하고 응답을 돌려주는 쪽입니다.
서버는 요청에 따라 HTML, CSS, JavaScript, 이미지, JSON 데이터 등을 반환합니다.
예시
- Nginx 웹 서버
- NestJS API 서버
- Spring Boot 서버
- Express 서버
- DB 서버
- 파일 서버

➕ 2-3. 기본 흐름

사용자
  ↓
브라우저 또는 React 앱
  ↓ HTTP 요청
Nginx / API 서버
  ↓
비즈니스 로직 처리
  ↓
DB 조회 또는 저장
  ↓
HTTP 응답
  ↓
브라우저 화면 반영

예를 들어 사용자가 상담 신청 버튼을 누르면 다음과 같은 흐름이 발생합니다.

1. 사용자가 상담 신청 폼 작성
2. React에서 POST /api/consult 요청 전송
3. NestJS 서버가 요청 데이터 검증
4. DB에 상담 신청 정보 저장
5. 서버가 성공 응답 반환
6. React에서 "신청이 완료되었습니다" 메시지 표시

✅ 3. HTTP 요청(Request)

HTTP 요청은 클라이언트가 서버에게 “이 작업을 해주세요”라고 보내는 메시지입니다.
요청에는 메서드, URL, 헤더, 바디 같은 정보가 포함됩니다.

➕ 3-1. HTTP 요청의 구성 요소

POST /api/consult HTTP/1.1
Host: www.example.com
Content-Type: application/json
Authorization: Bearer access-token

{
  "name": "홍길동",
  "phone": "01012345678",
  "model": "Galaxy S25"
}

위 요청은 다음 의미를 가집니다.

구성 요소	설명
`POST`	서버에 데이터를 생성하거나 전송하는 요청
`/api/consult`	요청 대상 URL
`Host`	요청하는 도메인
`Content-Type`	요청 바디의 데이터 형식
`Authorization`	인증 정보
JSON Body	서버로 보내는 실제 데이터

✅ 4. HTTP 메서드

HTTP 메서드는 클라이언트가 서버에게 어떤 작업을 요청하는지 나타냅니다.
실무에서는 주로 GET, POST, PUT, PATCH, DELETE를 사용합니다.

➕ 4-1. GET

서버에서 데이터를 조회할 때 사용합니다.
게시글 목록 조회, 상품 목록 조회, 이벤트 페이지 조회 등에 사용됩니다.
보통 요청 바디를 사용하지 않고, 필요한 값은 URL 쿼리 파라미터로 전달합니다.

GET /api/products?page=1&limit=20 HTTP/1.1

실무 예시
- 상품 목록 조회
- 상담 신청 목록 조회
- 이벤트 상세 조회
- 사용자 프로필 조회

➕ 4-2. POST

서버에 새로운 데이터를 생성하거나 특정 작업을 요청할 때 사용합니다.
회원가입, 로그인, 상담 신청, 주문 생성 등에 사용됩니다.

POST /api/consult HTTP/1.1
Content-Type: application/json

{
  "name": "홍길동",
  "phone": "01012345678"
}

실무 예시
- 회원가입
- 로그인
- 상담 신청 등록
- 주문 생성
- 파일 업로드

➕ 4-3. PUT

기존 데이터를 전체 수정할 때 사용합니다.
리소스 전체를 새 데이터로 교체하는 의미가 강합니다.

PUT /api/users/1 HTTP/1.1
Content-Type: application/json

{
  "name": "홍길동",
  "phone": "01099998888",
  "email": "test@example.com"
}

주의할 점
- PUT은 전체 수정의 의미가 강하므로 빠진 필드가 있으면 기존 값이 사라지는 구조로 설계될 수 있습니다.
- 실무에서는 부분 수정이 많아서 PATCH를 더 자주 사용하는 경우도 많습니다.

➕ 4-4. PATCH

기존 데이터의 일부만 수정할 때 사용합니다.

PATCH /api/users/1 HTTP/1.1
Content-Type: application/json

{
  "phone": "01099998888"
}

실무 예시
- 회원 전화번호 수정
- 상담 상태 변경
- 주문 상태 변경
- 관리자 메모 수정

➕ 4-5. DELETE

서버의 데이터를 삭제할 때 사용합니다.

DELETE /api/products/10 HTTP/1.1

실무 예시
- 상품 삭제
- 배너 삭제
- 게시글 삭제
- 관리자 계정 삭제
주의할 점
- 실무에서는 실제 DB에서 바로 삭제하는 물리 삭제보다, deletedAt이나 isDeleted 값을 사용하는 소프트 삭제를 쓰는 경우가 많습니다.
- 삭제는 복구가 어려울 수 있으므로 관리자 권한 체크와 로그 기록이 중요합니다.

✅ 5. HTTP 응답(Response)

HTTP 응답은 서버가 클라이언트의 요청을 처리한 결과를 돌려주는 메시지입니다.
응답에는 상태 코드, 헤더, 바디가 포함됩니다.

➕ 5-1. HTTP 응답 예시

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 101,
  "message": "상담 신청이 완료되었습니다."
}

위 응답은 다음 의미를 가집니다.

구성 요소	설명
`201 Created`	새로운 데이터가 생성됨
`Content-Type`	응답 데이터 형식
JSON Body	클라이언트에게 전달할 실제 데이터

✅ 6. HTTP 상태 코드

HTTP 상태 코드는 서버가 요청을 어떻게 처리했는지 알려주는 숫자입니다.
풀스택 개발자는 상태 코드를 보고 문제 위치를 빠르게 추측할 수 있어야 합니다.

➕ 6-1. 2xx 성공

요청이 정상적으로 처리되었음을 의미합니다.

상태 코드	의미	실무 예시
`200 OK`	요청 성공	목록 조회 성공
`201 Created`	생성 성공	상담 신청 등록 성공
`204 No Content`	성공했지만 응답 본문 없음	삭제 성공

➕ 6-2. 3xx 리다이렉션

요청한 리소스가 다른 위치로 이동했음을 의미합니다.

상태 코드	의미	실무 예시
`301 Moved Permanently`	영구 이동	HTTP → HTTPS 리다이렉트
`302 Found`	임시 이동	로그인 후 이전 페이지 이동
`304 Not Modified`	변경 없음	브라우저 캐시 사용

➕ 6-3. 4xx 클라이언트 오류

클라이언트 요청에 문제가 있음을 의미합니다.
프론트엔드에서 잘못된 데이터를 보냈거나, 인증이 없거나, 권한이 부족한 경우 자주 발생합니다.

상태 코드	의미	실무 예시
`400 Bad Request`	잘못된 요청	필수 값 누락
`401 Unauthorized`	인증 필요	로그인하지 않음
`403 Forbidden`	권한 없음	일반 사용자가 관리자 API 접근
`404 Not Found`	리소스 없음	없는 페이지 또는 API 호출
`409 Conflict`	충돌	이미 가입된 이메일
`422 Unprocessable Entity`	검증 실패	전화번호 형식 오류

➕ 6-4. 5xx 서버 오류

서버 내부에서 문제가 발생했음을 의미합니다.
백엔드 코드, DB, 외부 API, 서버 설정 문제일 가능성이 높습니다.

상태 코드	의미	실무 예시
`500 Internal Server Error`	서버 내부 오류	예외 처리 누락
`502 Bad Gateway`	게이트웨이 오류	Nginx가 API 서버와 통신 실패
`503 Service Unavailable`	서비스 이용 불가	서버 점검 또는 과부하
`504 Gateway Timeout`	응답 시간 초과	API 서버 응답 지연

✅ 7. HTTP 헤더

HTTP 헤더는 요청이나 응답에 대한 부가 정보를 담는 영역입니다.
인증, 캐싱, 데이터 형식, 브라우저 정책, 보안 설정에 많이 사용됩니다.

➕ 7-1. 자주 쓰는 요청 헤더

Content-Type: application/json
Authorization: Bearer access-token
Cookie: sessionId=abc123
User-Agent: Mozilla/5.0
Referer: https://www.example.com/event

헤더	설명
`Content-Type`	요청 바디 데이터 형식
`Authorization`	JWT 같은 인증 토큰
`Cookie`	세션, 추적 정보 등
`User-Agent`	브라우저/OS 정보
`Referer`	이전 페이지 주소

➕ 7-2. 자주 쓰는 응답 헤더

Content-Type: application/json
Set-Cookie: sessionId=abc123; HttpOnly; Secure
Cache-Control: no-store
Access-Control-Allow-Origin: https://www.example.com

헤더	설명
`Set-Cookie`	브라우저에 쿠키 저장
`Cache-Control`	캐싱 정책
`Access-Control-Allow-Origin`	CORS 허용 출처
`Content-Type`	응답 데이터 형식

✅ 8. 프론트엔드에서 API 호출 흐름

React에서는 fetch, axios, React Query 등을 사용해 서버 API를 호출합니다.
API 호출은 단순히 URL을 부르는 것이 아니라, 요청 데이터, 상태 코드, 에러 처리, 로딩 상태까지 함께 관리해야 합니다.

➕ 8-1. fetch 예시

async function submitConsult() {
  const response = await fetch("/api/consult", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      name: "홍길동",
      phone: "01012345678",
      model: "Galaxy S25",
    }),
  });

  if (!response.ok) {
    throw new Error("상담 신청에 실패했습니다.");
  }

  return response.json();
}

➕ 8-2. axios 예시

import axios from "axios";

async function submitConsult() {
  const response = await axios.post("/api/consult", {
    name: "홍길동",
    phone: "01012345678",
    model: "Galaxy S25",
  });

  return response.data;
}

실무에서 같이 처리할 것
- 로딩 상태
- 성공 메시지
- 실패 메시지
- 필수 입력값 검증
- 중복 클릭 방지
- 인증 만료 처리
- 서버 에러 로깅

✅ 9. 백엔드에서 요청을 처리하는 흐름

NestJS 같은 백엔드 프레임워크는 클라이언트 요청을 Controller에서 받고, Service에서 비즈니스 로직을 처리한 뒤 응답을 반환합니다.

➕ 9-1. NestJS Controller 예시

import { Body, Controller, Post } from '@nestjs/common';

@Controller('consult')
export class ConsultController {
  @Post()
  createConsult(@Body() body: { name: string; phone: string; model: string }) {
    return {
      message: '상담 신청이 완료되었습니다.',
      data: body,
    };
  }
}

➕ 9-2. 실무적인 처리 흐름

1. Controller에서 요청 받기
2. DTO로 요청 데이터 검증
3. Service에서 비즈니스 로직 처리
4. Repository 또는 ORM으로 DB 저장
5. 결과를 Controller로 반환
6. 클라이언트에 JSON 응답

실무에서는 Controller에 모든 코드를 몰아넣지 않고, 역할을 나누는 것이 중요합니다.

Controller: HTTP 요청/응답 담당
Service: 비즈니스 로직 담당
Repository/ORM: DB 접근 담당
DTO: 요청 데이터 검증 담당
Entity: DB 테이블 구조 표현

✅ 10. 브라우저 Network 탭으로 HTTP 확인하기

Chrome DevTools의 Network 탭은 HTTP 요청과 응답을 확인하는 가장 기본적인 도구입니다.
프론트엔드와 백엔드 문제를 구분할 때 반드시 확인해야 합니다.

➕ 10-1. 확인할 항목

요청 URL이 맞는가?
HTTP 메서드가 맞는가?
상태 코드가 무엇인가?
Request Payload가 정상인가?
Response Body에 어떤 에러가 들어있는가?
Authorization 헤더나 Cookie가 정상적으로 포함되었는가?
CORS 에러가 발생했는가?
요청 시간이 너무 오래 걸리지 않는가?

➕ 10-2. 문제 판단 예시

404 Not Found
- 프론트에서 호출한 URL이 잘못되었거나, 백엔드 라우트가 존재하지 않을 수 있습니다.
401 Unauthorized
- 로그인 토큰이 없거나 만료되었을 수 있습니다.
403 Forbidden
- 로그인은 했지만 해당 API를 사용할 권한이 없을 수 있습니다.
500 Internal Server Error
- 백엔드 코드, DB, 외부 API 쪽 문제일 가능성이 높습니다.
CORS error
- 브라우저 보안 정책상 다른 출처의 API 호출이 차단된 것입니다.
- 서버에서 허용할 Origin, Method, Header를 설정해야 합니다.

✅ 11. 실무 체크리스트

➕ 11-1. API 설계 전 확인

이 API는 어떤 리소스를 다루는가?
조회, 생성, 수정, 삭제 중 어떤 작업인가?
어떤 HTTP 메서드가 적절한가?
URL 이름이 직관적인가?
요청 데이터 구조가 명확한가?
성공 응답과 실패 응답 형식이 정리되어 있는가?
인증이 필요한 API인가?
관리자 권한이 필요한 API인가?

➕ 11-2. API 오류 발생 시 확인

브라우저 Network 탭에서 상태 코드 확인
요청 URL과 메서드 확인
Request Payload 확인
Response Body 확인
백엔드 로그 확인
DB 연결 및 쿼리 확인
외부 API 호출 여부 확인
최근 배포 변경사항 확인

➕ 11-3. 좋은 API 응답 형식 예시

{
  "success": true,
  "message": "상담 신청이 완료되었습니다.",
  "data": {
    "id": 101
  }
}

{
  "success": false,
  "message": "전화번호 형식이 올바르지 않습니다.",
  "errorCode": "INVALID_PHONE_NUMBER"
}

성공/실패 응답 형식이 일정하면 프론트엔드에서 에러 처리와 UI 표시가 쉬워집니다.

📌 요약

HTTP는 클라이언트와 서버가 데이터를 주고받기 위한 웹의 기본 통신 규칙입니다.
풀스택 개발자는 브라우저, React, NestJS, DB가 HTTP 요청과 응답을 통해 어떻게 연결되는지 이해해야 합니다.
HTTP 요청은 메서드, URL, 헤더, 바디로 구성되고, HTTP 응답은 상태 코드, 헤더, 바디로 구성됩니다.
GET, POST, PUT, PATCH, DELETE는 실무 API 설계에서 가장 자주 사용하는 HTTP 메서드입니다.
상태 코드는 문제 원인을 빠르게 파악하는 핵심 단서입니다. 특히 401, 403, 404, 500, 502는 반드시 익숙해져야 합니다.
프론트엔드에서는 Network 탭을 통해 요청 URL, 메서드, 상태 코드, 요청/응답 데이터를 확인해야 합니다.
백엔드에서는 Controller, Service, DTO, Repository/ORM의 역할을 나누어 HTTP 요청을 처리하는 구조를 만드는 것이 중요합니다.

juni

이전 포스트

TIL - 20260526

다음 포스트

TIL - 20260527

TIL

0527 풀스택 실무 기초 (1/N): HTTP와 클라이언트-서버 구조

✅ 1. 풀스택 개발에서 HTTP가 중요한 이유

➕ 1-1. 실무에서 HTTP를 모르면 생기는 문제

✅ 2. 클라이언트와 서버 구조

➕ 2-1. 클라이언트란?

➕ 2-2. 서버란?

➕ 2-3. 기본 흐름

✅ 3. HTTP 요청(Request)

➕ 3-1. HTTP 요청의 구성 요소

✅ 4. HTTP 메서드

➕ 4-1. GET

➕ 4-2. POST

➕ 4-3. PUT

➕ 4-4. PATCH

➕ 4-5. DELETE

✅ 5. HTTP 응답(Response)

➕ 5-1. HTTP 응답 예시

✅ 6. HTTP 상태 코드

➕ 6-1. 2xx 성공

➕ 6-2. 3xx 리다이렉션

➕ 6-3. 4xx 클라이언트 오류

➕ 6-4. 5xx 서버 오류

✅ 7. HTTP 헤더

➕ 7-1. 자주 쓰는 요청 헤더

➕ 7-2. 자주 쓰는 응답 헤더

✅ 8. 프론트엔드에서 API 호출 흐름

➕ 8-1. fetch 예시

➕ 8-2. axios 예시

✅ 9. 백엔드에서 요청을 처리하는 흐름

➕ 9-1. NestJS Controller 예시

➕ 9-2. 실무적인 처리 흐름

✅ 10. 브라우저 Network 탭으로 HTTP 확인하기

➕ 10-1. 확인할 항목

➕ 10-2. 문제 판단 예시

✅ 11. 실무 체크리스트

➕ 11-1. API 설계 전 확인

➕ 11-2. API 오류 발생 시 확인

➕ 11-3. 좋은 API 응답 형식 예시

📌 요약

TIL - 20260526

TIL - 20260528

0개의 댓글