Daily Dev Q&A: GET vs POST (개념 및 데이터 흐름)

Topic (오늘의 주제)

HTTP Method: GET vs POST (개념 및 데이터 흐름)

Why (왜 사용하는가? 왜 중요한가?)

• 실무: API를 설계할 때 "조회"인지 "등록/수정"인지에 따라 명확히 구분해 써야 합니다. 잘못 사용하면 비밀번호가 주소창에 노출되거나(GET으로 로그인 시), 캐싱이 안 되어 성능이 떨어지는(POST로 단순 조회 시) 문제가 발생합니다.
• 구조적 의미: RESTful API 설계의 기초가 됩니다. HTTP 프로토콜의 의도(Semantics)에 맞게 사용하여 웹의 장점(캐싱, 북마크 등)을 최대한 활용하게 합니다.
• 면접 의도: 단순히 "GET은 가져오고 POST는 보낸다"를 넘어, 데이터 전송 위치(Body vs URL), 멱등성(Idempotence), 캐싱 가능 여부 등 기술적 차이를 명확히 아는지 봅니다.

Core Concept (핵심 개념 정리)

비교 항목	GET	POST
개념 정의	서버로부터 리소스를 **조회(Read)**하기 위해 요청.	서버에 리소스를 **생성(Create)**하거나 데이터를 처리하기 위해 요청.
데이터 위치	**URL (Query String)**에 포함. (예: ?name=apple&price=100)	HTTP Message Body에 포함. (보이지 않게 내부 전송)
데이터 크기	브라우저/서버마다 URL 길이 제한이 있음. (대용량 불가)	제한 없음. (대용량 데이터 전송 가능)
보안	URL에 데이터가 다 노출됨. (민감 정보 전송 금지)	Body에 숨겨지지만 암호화는 아님. (HTTPS 필수)
캐싱/북마크	가능. (같은 URL은 캐시된 데이터 사용)	불가능. (매번 새로운 처리를 수행)
멱등성	O (Yes). 여러 번 수행해도 결과가 같음.	X (No). 수행할 때마다 새로운 리소스가 생성될 수 있음.

Data Flow (데이터 흐름 분석)

1. GET 요청의 흐름 (예: 검색)

1. Client: 사용자가 검색창에 '사과' 입력 후 엔터.
2. Request: 브라우저가 URL 뒤에 ?keyword=사과를 붙여 헤더(Header)를 생성. (GET /search?keyword=사과 HTTP/1.1)
3. Transport: 패킷이 서버로 전송. (Body는 비어있음)
4. Server: URL의 Query String을 파싱하여 키워드 획득.
5. Response: DB 조회 후 결과를 HTML이나 JSON으로 반환. (브라우저는 이 URL을 방문 기록에 저장하고 캐싱함)

2. POST 요청의 흐름 (예: 회원가입)

1. Client: 사용자가 ID, 비번 입력 후 '가입' 버튼 클릭.
2. Request: 브라우저가 입력 데이터를 JSON이나 Form Data 형태로 만들어 Body에 담음. (POST /join HTTP/1.1 + Body: {id: "user", pw: "123"})
3. Transport: 패킷 전송. (URL에는 데이터가 안 보임)
4. Server: Body의 데이터를 읽어(@RequestBody 등) DB에 저장(INSERT).
5. Response: "가입 성공" 응답 반환. (브라우저는 이를 캐싱하지 않음. 새로고침 시 "양식을 다시 제출하시겠습니까?" 경고 뜸)

Interview Answer Version (면접 답변식 요약)

"GET은 서버의 리소스를 조회할 때 사용하며, 데이터를 URL의 Query String에 담아 전송합니다. 이 때문에 캐싱이 가능하고 멱등성을 가집니다.

반면 POST는 리소스를 생성하거나 데이터를 처리할 때 사용하며, 데이터를 HTTP Body에 담아 전송합니다. 데이터 크기에 제한이 없고, 멱등성이 보장되지 않아 요청할 때마다 새로운 리소스가 생성되거나 상태가 변경될 수 있습니다."

Practical Tip (사용시 주의할 점 or 활용 예)

1. Spring Controller에서의 처리 차이

• GET: URL 파라미터는 주로 **@RequestParam**이나 **@ModelAttribute**로 받습니다.
•  

  @GetMapping("/members")
  public List<Member> getMembers(@RequestParam String name) { ... }
  

• Java
• POST: Body에 담긴 데이터(JSON 등)는 주로 **@RequestBody**로 객체에 매핑하여 받습니다.
• Java

  @PostMapping("/members")
  public void saveMember(@RequestBody MemberDto dto) { ... }
  

2. POST가 더 보안에 강력하다는 오해

• "POST는 데이터가 안 보이니까 안전하다"는 반은 맞고 반은 틀립니다.
• URL에 노출되지 않을 뿐, HTTP Body도 패킷을 가로채면 평문으로 다 보입니다.
• **반드시 HTTPS(SSL)**를 적용해서 Body 내용을 암호화해야 진짜 안전합니다.

3. 애매할 땐? (검색 조건이 너무 많을 때)

• 원칙적으로 검색(조회)은 GET을 써야 하지만, 필터 조건이 너무 많아 URL 길이 제한(브라우저마다 다름, 보통 2000자 내외)을 넘을 것 같으면 예외적으로 POST를 사용하여 Body에 검색 조건을 담아 보내기도 합니다. (Elasticsearch 검색 API 등도 POST를 지원함)

예상 꼬리질문 정리

1. Q: 멱등성(Idempotence)이란 무엇이며, GET과 POST는 어떻게 다른가요?
   • 핵심 키워드: 연산을 여러 번 적용해도 결과가 달라지지 않는 성질. GET은 100번 조회해도 서버 상태가 안 변하지만(멱등), POST는 100번 요청하면 글이 100개 써짐(멱등 X).
2. Q: PUT과 PATCH의 차이점은 무엇인가요? (POST와 연결)
   • 핵심 키워드: 둘 다 수정에 쓰이지만, PUT은 리소스 전체 교체 (없으면 생성, 멱등함), PATCH는 리소스 일부 변경 (멱등하지 않을 수 있음).
3. Q: HTTP 상태 코드 중 200(OK)과 201(Created)은 언제 쓰이나요?
   • 핵심 키워드: GET 성공 시 주로 200, POST로 리소스 생성 성공 시 주로 201을 반환하여 명확히 구분함.