프로젝트 - 5주차(post과 get차이,http 구조,Page Slice, Redis단순나열)

YoungSun·2026년 2월 1일

[25-2] 프로젝트 트랙

목록 보기
5/6

목차
1. Post vs get
2. HTTP 요청은 어떻게 구성될까
3. Page vs Slice
4. Redis (단순 나열)

1. HTTP 구조를 다시 보게 된 이유(Post vs get)

HTTP를 처음 배울 때 GET과 POST는 이렇게 배웠다.
GET은 조회, POST는 생성.

그런데 실제 코드를 보다 보니 이상했다.
GET의 query parameter와 POST의 request body는 모양이 거의 같다.
키-값 쌍이고, 서버에서는 결국 같은 DTO로 바인딩된다.

그렇다면 정말 차이는 URI에 노출되느냐, 안 되느냐뿐일까?
이 의문에서 이 글을 쓰기 시작했다.

HTTP 요청의 기본 구조부터 다시 보기

HTTP 요청은 크게 세 부분으로 나뉜다.

  • Request Line (Method + URI + Version)
  • Headers
  • Body

URI는 요청 장소
Body는 요청 내용

GET 요청에서 Query는 왜 URI에 붙을까

GET 요청은 “오늘 학식 뭐임?”과 비슷하다.
본질적으로 조회하기 위한 요청이란 뜻이다.

학식이 있을 수도 있고, 없을 수도 있지만
질문 자체는 정보 확인에 초점이 맞춰져 있다.

만들어줘 x
이미 있는거 확인 해줘 o
URI 자체가 캐시의 키가 되고, 히스토리가 된다.
Query parameter는 호출 대상을 특정하기 위한 조건 표현에 가깝다.

URI로 캐시가 이뤄지는건 처음알았다.
Body도 이론적으로는 캐시가 가능하지만,
HTTP 캐시가 신뢰하도록 설계된 조건은 아니라고 함.

POST 요청에서 Body는 어떤 의미를 가질까

POST는 조회가 아니라 처리 를 요청하는 방식이다.

“오늘 학식 뭐임?”을 물어 보고
맛이 없으면
“싸이버거 하나요” 라고 주문하는 상황에 가깝다.

이때 중요한 건 주문 내용 그 자체다.
그래서 POST 요청의 핵심 정보는 URI가 아니라 Body에 담긴다.
Body는 “무엇을 어떻게 처리해 달라는지”를 설명한다.
이 Body 안에는 생성할 데이터가 들어갈 수도 있고,
복잡한 조건이나 상태 변경 요청이 들어갈 수도 있다.

이런 요청은 결과가 매번 같을 필요도 없음
같은 요청을 다시 보낸다고 해서 같은 결과가 나온다는 보장없음
그래서 POST 요청은 기본적으로 캐시를 전제로 하지 않는다.
Body가 캐시의 기준이 되지 않는 이유도 여기에 있다.
Body는 리소스를 식별하기 위한 정보라기보다
서버에 전달되는 행위의 내용에 가깝기 때문이다.

2. HTTP 요청은 어떻게 구성될까

post과 get 를 헷갈리는 나에게
GPT는 http에 대해 좀 더 공부하라 가이드 해줬다
API 명세서를 작성하면서 명확하지 않은 부분을 명확하게 하려 노력했다

GET 예시

GET /학식?date=2026-02-01 HTTP/1.1
Host: 학교식당[.com](http://school.example.com/)
Accept: application/json

POST 예시

POST /orders HTTP/1.1
Host: 맘스터치.com
Content-Type: application/json

{
  "menu": "싸이버거",
  "quantity": 1
}

전체적인 구조는 다음과 같다

  • Request Line (요청의 정체) : [Method][URI] [HTTP Version]
  • Headers (부가 정보 설명서) :content-type,Authorization, Cookie, Cache-Control,Origin / Host 등등 ,,,
  • Body (실제 데이터) :

Headers

Body를 어떻게 처리할지 설명해주는 곳임

Accept: application/json → json 형태로 응답 받을꺼임
Content-Type: application/json → json 형태로 요청 보낼꺼임
Cache-Control : 이 요청/응답이 캐시되어도 됨or 안됨
Origin : 이 요청은 여기서 왔다
Authorization : "나는 인증된 요청임" [토큰(JWT, OAuth 등) 기반]
Cookie : 서버가 이전에 브라우저에게 맡겨 둔 상태 정보

  • 세션 로그인 할때 쓰는거임
  • JSESSIONID=abc123

CORS 에러가 나는 이유
크롬에서 이 요청이 신뢰할 수 있는지 판단하기 위해
OPTIONS 요청(Preflight) 을 서버에 먼저 보낸다
Authorization , Content-Type: application/json ,Origin 다를때 등등
지겨운 에러의 원인을 하나 알아간다

3.Page vs Slice

한 번에 많은 데이터를 조회 -> 속도 이슈
이 문제를 찾아보다 보면 보통 두 가지 선택지가 나온다.

Page vs Slice

Page는
학과 공지사항 홈페이지 처럼 page로 구분된다

Slice는
인스타그램 처럼 무한 스크롤 가능하다

  • Page
    → 전체 개수를 알아야 해서 count 쿼리가 필요
  • Slice
    → 전체 개수 몰라도 되고, 다음 페이지 존재 여부만 판단

그럼 대용량에서는 count 쿼리 오래걸리니 무조건 Slice가 좋은 거 아님?

Page 쓰는이유

Page의 목적은 정확한 정보 제공이다.

  • 데이터의 전체 규모 파악
  • 정교한 탐색
  • 검색 엔진 최적화

이게 중요한 서비스에서 Page가 사용된다

예를 들어
3달 전에 사진을 다시 보고 싶은 상황을 생각해보자.

Page라면
페이지를 기준으로 빠르게 이동할 수 있다.

반면 Slice라면
무한 스크롤을 계속 내려야 하고,
중간에 새로고침이라도 되면 처음부터 다시 내려야 한다.

또 무조건 느리지 않다
카운트 쿼리를 특정 주기마다 캐싱하거나,
인덱스 활용하면 충분히 빠르게 검색 가능하다고 한다(출처gpt,젬미니)

Slice

  • 전체가 몇 개인지는 중요하지 않다
  • 다음 데이터가 있느냐만 중요하다

정리

Page는 정확한 탐색을 위한 선택
Slice는 성능을 위한 선택

데이터가 많아진다고 해서
무조건 Slice를 써야 하는 건 아니다.

사용자가 무엇을 알고 싶어 하는지에 따라 다름

4. Redis (단순 나열)

1. In-memory database

주요특징

  • 1ms 단위 → 디스크 대비 빠른 응답속도
  • 휘발성 데이터
  • 다양한 데이터 타입 제공

Memcached

  • cache

redis

  • 캐쉬
  • 세션
  • Leader board

2. Remote Dictionary Server

key - value 시스템

백업 방식

  • RDB ( Snapshot )

    • 특정 시간에 DB에 저장 / 실행 주기가 긴 백업 방식

  • AOF (Append Only File) :

    • 모든 쓰기 명령에 로그를 남김
    • 디스크 쓰기작업에 빈번함

RDB 생성할때 or AOF rewrite(재작성) 과정에서:

process fork 방식
백업 시점 프로세스를 복제(fork)해서 중간마다 저장
메모리 사용률 급등할수있음 모니터링 반드시 필요

기본은 RDB를 사용
단순 캐쉬작업 RDB , AOF 둘다 끄고 사용함

Single Thread

여러 처리를 동시에 받아도 하나씩 처리함

데이터 일관성 보장 , Lock 사용 안함

(Redis : 초당 10만건 까지 가능)

Redis 6.0부터 Threaded I/O 도입되어 네트워크 입출력은 멀티 스레드로 처리함
하지만 명령어 처리는 여전히 싱글 스레드

활용 사례

Cache :

Session Store : TTL 사용함 , was에 세션 저장 x

Pub/Sub : 1 메시지 → 여러 Subscriber (확성기)

Message Queue : 지금 당장 처리하지 않아도 되는 일을 줄 세워 두는 중간 저장소

Geospatial :

Leader board : 순위 정보를 빠르게 얻을 수 있음

Message Queue , Pub/Sub 패턴 내용은 너무 많아서 패쓰
공부할게 또 늘었다

profile
YoungSun
이전 포스트

프로젝트 - 4주차(DIP)

다음 포스트

프로젝트 - 6주차(N+1문제)

0개의 댓글