이 주제는 신입 개발자들이 API를 설계할 때 가장 많이 실수하는 부분이자, 면접관이 "기본기가 되어있는지" 확인하기 딱 좋은 질문입니다.
단순히 "데이터를 보낼 때 쓴다"를 넘어서 '멱등성(Idempotency)'이라는 키워드까지 챙겨가실 수 있도록 구성했습니다.
[Network] GET과 POST의 차이, 아직도 모르고 API 만드시나요? (REST API)
"그냥 동작만 하면 되는 거 아닌가요?"
처음 API를 만들 때 흔히 하는 실수가 있습니다.
데이터를 조회하든, 수정하든, 삭제하든 상관없이 모조리 POST 메서드로 통일해서 보내버리는 것이죠.
물론 기능은 돌아갑니다. 하지만 사수가 코드를 보면 등짝 스매싱을 맞을 겁니다.
HTTP 메서드는 서버와 클라이언트 간의 '약속'이자 '명찰'이기 때문입니다.
오늘은 백엔드 개발자라면 숨 쉬듯 구분해야 할 GET과 POST의 차이, 그리고 면접 필살기인 멱등성(Idempotency) 개념까지 확실하게 정리해 드립니다.
1. 직관적인 비교: 엽서 vs 편지봉투
가장 쉬운 비유로 시작해볼까요?
📨 GET: 투명한 엽서
- 용도: 서버에서 데이터를 가져올 때 (Read/Retrieve) 씁니다.
- 특징: 데이터가 URL 뒤에 다 보입니다. (
?id=1&page=2) - 비유: 내용을 누구나 볼 수 있는 엽서입니다. 비밀번호 같은 걸 여기 적으면 큰일 나겠죠?
📦 POST: 밀봉된 편지봉투
- 용도: 서버에 데이터를 보내거나, 상태를 바꿀 때 (Create/Update) 씁니다.
- 특징: 데이터가 Body(본문) 안에 숨겨져서 갑니다.
- 비유: 내용을 봉투 안에 넣어서 보내는 편지입니다. 겉으로는 안 보이지만, 뜯어보면(패킷을 까보면) 다 보입니다.
2. 기술적인 차이점 (면접용)
단순히 "보인다/안 보인다"의 차이만 있을까요? 진짜 차이점은 여기에 있습니다.
① 데이터 전송 위치 (Header vs Body)
- GET: URL의 끝인 Query String에 데이터를 담아 보냅니다. 그래서 전송할 수 있는 데이터 양에 제한이 있습니다.
- POST: HTTP 패킷의 Body에 데이터를 담아 보냅니다. 대용량 데이터를 보내기에 적합합니다.
② 캐싱 (Caching) 가능 여부
- GET: 캐싱이 가능합니다. 우리가 웹페이지를 즐겨찾기(Bookmark) 할 수 있는 이유입니다. 한 번 조회한 데이터는 브라우저가 기억했다가 빠르게 보여줍니다.
- POST: 기본적으로 캐싱되지 않습니다. 주문 버튼을 누를 때마다 새로운 주문이 생성되어야 하니까요.
③ 멱등성 (Idempotency) - ⭐ 핵심 키워드!
면접관이 눈을 반짝이며 듣는 포인트입니다.
멱등하다(Idempotent): 연산을 한 번 하든 100번 하든 결과가 똑같다는 뜻입니다.
- GET은 멱등합니다.
- 게시글을 100번 조회한다고 해서 게시글 내용이 변하거나 서버 데이터가 망가지지 않습니다.
- POST는 멱등하지 않습니다.
- '결제하기' 버튼을 100번 누르면? 100번 결제됩니다. 서버의 상태가 매번 바뀝니다.
3. 오해와 진실: "POST는 보안상 안전하다?"
❌ 땡! 틀렸습니다.
많은 분들이 "GET은 URL에 보이니까 위험하고, POST는 Body에 숨기니까 안전하다"고 생각합니다.
하지만 개발자 도구(F12)를 켜거나 패킷 분석 툴(Wireshark)을 쓰면 POST로 보낸 데이터도 적나라하게 다 보입니다.
💡 진짜 보안은?
HTTP 메서드가 아니라 HTTPS(암호화 통신)를 써야 안전해집니다. POST라고 안심하고 비밀번호를 평문으로 보내면 해킹 당합니다.
4. REST API의 나머지 친구들 (PUT, PATCH, DELETE)
"그럼 수정이랑 삭제는요?"
과거에는 GET/POST만 썼지만, 요즘은 RESTful API 원칙에 따라 목적에 맞는 메서드를 씁니다.
- PUT: 리소스를 통째로 갈아끼울 때 (전체 수정)
- PATCH: 리소스의 일부분만 고칠 때 (부분 수정)
- DELETE: 리소스를 삭제할 때
5. 실전 면접 대비: 3초 요약
Q. GET과 POST의 차이를 설명해주세요.
A.
"사용 목적과 멱등성의 차이가 있습니다.
GET은 서버의 데이터를 조회할 때 사용하며, 여러 번 요청해도 결과가 같은 멱등성을 가집니다. 또한 URL에 데이터가 노출되므로 캐싱이 가능합니다.
반면 POST는 서버의 데이터를 생성하거나 변경할 때 사용하며, 요청할 때마다 새로운 리소스가 생성될 수 있어 멱등하지 않습니다. 데이터는 Body에 담겨 전송됩니다."
🚀 다음 글 예고
"열심히 API를 만들어서 보냈는데, 서버가 404라고 화를 냅니다."
개발자가 평생 봐야 할 숫자들. 200, 404, 500...
이 숫자들만 잘 알아도 에러 잡는 속도가 2배 빨라집니다. 다음 시간에는 HTTP 상태 코드(Status Code)의 모든 것을 파헤쳐 보겠습니다.
Next Topic: [Network] 200 OK와 404 Not Found, 숫자로 대화하는 법 (HTTP 상태 코드)
이번 주제로 API 설계의 기초를 다졌습니다. 다음 주제인 '상태 코드(Status Code)'까지 알면, 클라이언트(프론트)와 서버(백엔드)가 어떻게 소통하는지 완벽하게 이해하게 됩니다.
