POST 방식
웹 개발 처음 들어가면, 생각보다 빨리 한 번 크게 식은땀 나는 순간이 오더라고요. 저는 그게 로그인 폼이었습니다. 신나게 HTML로 폼 만들고 전송 버튼 눌렀는데, 주소창에 ?id=my_id&password=1234 이런 식으로 아이디랑 비번이 그대로 찍히는 거예요. “어… 이거 맞아?” 싶어서 순간 멍해졌습니다.
그때 처음 제대로 체감했어요. 클라이언트랑 서버가 “대화”하는 방식, 그러니까 HTTP 메서드가 그냥 용어가 아니라 진짜 중요한 약속이구나 하고요. 오늘은 그때의 저처럼 막 시작한 분들 기준으로, 중요한 데이터를 서버에 안전하게 보내고 서버 상태까지 바꾸는 POST 방식이 어떻게 돌아가는지 편하게 풀어볼게요.
POST 방식의 기본 이해
POST 방식이란 무엇인가요?
POST는 클라이언트(대부분은 웹 브라우저죠)가 서버에 “새로운 거 하나 만들어 주세요” 또는 “기존 거 좀 바꿔 주세요” 하고 요청할 때 쓰는 방식이에요. HTTP(HyperText Transfer Protocol)라는 약속 안에 들어있는 표준이고, RFC 7231 같은 문서에도 정의돼 있습니다. 인스타에 사진 올리기, 카페에 댓글 달기, 쇼핑몰에서 주문 완료하기 같은 것들이 전부 POST로 많이 돌아가요.
POST의 제일 큰 특징은 데이터를 URL에 붙이는 게 아니라, HTTP 요청의 본문(Request Body)에 담아서 보낸다는 점입니다. 아까 로그인 폼 삽질처럼 주소창에 민감한 값이 그대로 노출되는 일은 확 줄어들죠. 이게 POST를 떠올릴 때 가장 직관적인 포인트라고 보시면 됩니다.
POST 방식의 주요 특징
데이터를 본문에 담아 보내는 구조 때문에, POST는 실무에서 꽤 중요한 성질들을 같이 가져갑니다. 이걸 알아야 “아 이건 POST 써야겠다”가 감으로라도 잡혀요.
첫째, 보안성이 상대적으로 높습니다. 비밀번호나 주민등록번호 같은 민감한 정보가 URL에 박히는 걸 막아주니까요. URL에 들어가면 브라우저 방문 기록에도 남고, 서버 로그에도 남고, 공유하다가 그대로 새는 경우도 생깁니다. 다만 POST가 만능 방패는 아니에요. 중간에서 패킷 훔쳐보는 공격 같은 건 POST도 똑같이 당합니다. 그래서 진짜 중요한 건 HTTPS(SSL, TLS)로 통신 자체를 암호화하는 겁니다.
둘째, 데이터 크기에 거의 제한이 없습니다. GET은 URL 길이 제한(브라우저마다 다르지만 흔히 2,048자 얘기 많이 하죠) 때문에 긴 데이터 보내기 빡셉니다. POST는 본문을 쓰니까 훨씬 여유가 있어요. 긴 글, 복잡한 설정값, 파일 업로드 같은 것도 여기로 많이 갑니다. 파일 업로드가 끼면 보통 POST로 가는 게 마음 편하더라고요.
셋째, 브라우저의 행동이 GET이랑 다릅니다. POST는 서버 상태를 바꾸는 요청이라 브라우저도 조심해요. 캐시로 저장하지도 않고, 방문 기록이나 북마크로 남기기도 애매합니다. 쇼핑몰 결제 끝나고 새로고침(F5) 눌렀을 때 경고창 뜨는 거 본 적 있으시죠?
> “폼을 다시 제출하시겠습니까?”
이게 같은 POST가 또 날아가서 중복 주문 나는 걸 막으려는 안전장치라고 보시면 됩니다.
POST 요청 데이터 전송
POST로 보낼 때는 서버한테 “내가 지금 이런 형식으로 보냈으니까 이렇게 해석해 주세요”를 같이 알려줘야 합니다. 소포 보낼 때 ‘유리’ 스티커 붙이는 느낌이랑 비슷해요. 이 역할을 하는 게 HTTP 헤더의 Content-Type입니다. 서버는 이 값을 보고 Request Body를 어떻게 파싱할지 결정해요. 실무에서 자주 보는 형식 세 가지는 이렇습니다.
| Content-Type | 설명 | 주요 사용처 |
|---|---|---|
application/x-www-form-urlencoded |
가장 전통적인 방식입니다. key=value 쌍을 &로 이어 붙인 문자열로 전송해요. 한글이나 특수문자는 URL 인코딩됩니다. |
일반적인 HTML <form> 제출 기본값 |
multipart/form-data |
데이터를 여러 파트로 나눠서 보내고, 각 파트는 경계(Boundary)로 구분됩니다. 텍스트랑 파일을 같이 보낼 때 유용합니다. |
파일 업로드가 있는 폼 |
application/json |
JSON(JavaScript Object Notation) 텍스트로 데이터를 만들어 보냅니다. 구조가 복잡해져도 사람이 읽기 편해서 API 통신에서 정말 많이 씁니다. | 현대 웹 서비스 API 통신 (앱-서버 연동) |
POST 방식은 언제 사용해야 할까요?
OWASP(Open Web Application Security Project)에서도 이런 식으로 권고합니다.
> 서버의 상태를 바꾸는 모든 작업은 반드시 POST 메서드를 사용해야 합니다.
이게 왜 중요하냐면, 사용자가 악성 링크 한 번 잘못 눌러서 정보가 바뀌거나 삭제되는 CSRF(사이트 간 요청 위조) 같은 공격이 실제로 터지거든요. 그래서 기준을 하나만 잡고 가면 편합니다.
“이 요청이 서버에 저장된 데이터를 바꾸나?” 여기에 “네”라고 답할 수 있으면 POST 쪽으로 가는 게 맞습니다.
예를 들어 제가 토이 프로젝트로 ‘나만의 맛집 지도’ 만들 때, 사용자가 맛집을 새로 등록하는 기능은 POST로 처리했어요. 식당 이름, 주소, 별점, 리뷰를 JSON으로 묶어서 /restaurants로 POST 요청을 보내면 서버가 DB에 새 레코드를 생성(Create)하는 식이죠.
POST는 보통 이런 상황에서 씁니다.
새로운 데이터를 생성할 때 회원가입, 새 글 작성, 사진 업로드, 상품 등록 등
기존 데이터를 수정할 때 프로필 변경, 게시글 수정 등 (엄밀히는 PUT, PATCH가 더 맞는 경우도 많지만 POST도 널리 씁니다)
로그인, 결제처럼 민감한 데이터를 전송할 때 URL 노출을 막아야 하니까요
전송할 데이터가 많거나 파일이 포함될 때 GET의 길이 제한 피하려고요
GET, POST 방식 비교
POST를 제대로 이해하려면, 단짝이자 라이벌인 GET이랑 같이 보면 제일 빨리 감이 옵니다.
POST 방식 이해를 위한 GET 방식
GET 방식은 데이터를 주소창 끝에 ?key=value&key2=value2 형태로 붙여서 보냅니다. 이걸 쿼리 스트링(Query String)이라고 부르죠. 그래서 검색 결과 페이지를 링크로 공유하거나 즐겨찾기 해두기 편합니다.
GET은 이름 그대로 서버에서 무언가를 가져오기(GET) 위한 메서드라서, 서버 데이터 조회(Read)에 주로 씁니다. 웹툰 목록 보기, 상품 상세 보기 같은 게 전형적인 GET이에요. 그리고 같은 요청을 여러 번 보내도 서버 상태가 바뀌지 않으니까 GET은 ‘안전하다(safe)’고 표현합니다.
GET, POST 방식 차이
GET이랑 POST를 상황에 맞게 구분해서 쓰는 게 웹 개발 첫 단추라고 봐도 됩니다. 둘 다 기본이지만 목적이 완전히 달라요. 표로 보면 이런 느낌입니다.
| 구분 | GET 방식 | POST 방식 |
|---|---|---|
| 주요 목적 | 서버 데이터 조회 (Read) | 서버 데이터 생성 (Create), 수정 (Update) |
| 데이터 전송 위치 | URL의 쿼리 스트링 (주소창에 노출) | HTTP 요청 본문 (Request Body) |
| 데이터 크기 | 작음 (URL 길이 제한, 약 2048자) | 거의 무제한 (서버 설정에 따름) |
| 보안성 | 낮음 (데이터가 그대로 노출됨) | 상대적으로 높음 (데이터가 숨겨짐) |
| 멱등성(Idempotency) | 보장됨 (여러 번 요청해도 결과 동일) | 보장되지 않음 (요청마다 새 데이터 생성 가능) |
| 캐싱(Caching) | 가능 (속도 향상에 유리) | 불가능 |
| 북마크/방문기록 | 가능 / 남음 | 불가능 / 남지 않음 |
정리하면 간단합니다. 읽기(조회)면 GET이고, 쓰기(생성/수정)처럼 서버에 변화를 주면 POST로 가는 게 기본 설계예요. 처음엔 헷갈려도, 프로젝트 하나만 제대로 만들어보면 금방 손에 익습니다.
—
FAQ
Q1: POST 요청으로도 데이터를 조회할 수 있나요?
A: 기술적으로는 가능합니다. 검색 조건이 너무 복잡해서 URL에 담기 애매할 때, POST 본문에 조건을 넣어서 조회하는 경우도 있긴 해요. 다만 이건 HTTP 메서드가 원래 의도한 방향이랑은 좀 어긋납니다. 특별한 이유가 없으면 GET을 쓰는 게 표준 약속이고, 조회는 GET이 캐싱 같은 성능 이점도 챙기기 좋습니다.
Q2: POST 방식은 GET 방식보다 항상 안전한가요?
A: “항상”은 아닙니다. URL에 노출이 안 되니까 GET보다 상대적으로 안전한 건 맞아요. 근데 HTTPS가 아닌 일반 HTTP면, 중간에서 통신 엿보는 스니핑으로 POST 본문도 그대로 털릴 수 있습니다. 그래서 POST를 쓰더라도 HTTPS는 거의 필수라고 보시면 돼요.
Q3: URL 길이 제한은 왜 GET 방식에만 실질적으로 적용되나요?
A: 이건 HTTP 규격이 “URL은 몇 글자까지”를 딱 잘라 정한 게 아니라, 브라우저(크롬, 사파리 등)나 서버(Apache 같은)가 처리 한계 때문에 자체적으로 제한을 둔 쪽에 가깝습니다. GET은 데이터를 URL에 싣는 구조라 제한을 정면으로 맞고, POST는 본문(Body)에 싣기 때문에 그 제한이랑은 별개로 더 많이 보낼 수 있는 거죠.
Q4: 멱등성(Idempotency)이 정확히 무엇을 의미하며 왜 중요한가요?
A: 같은 요청을 여러 번 보내도 결과가 한 번 보낸 것과 같게 유지되는 성질을 말합니다. 예를 들어 “5번 게시물 보여줘” 같은 GET은 100번 보내도 그냥 5번이 보일 뿐 서버 상태가 안 바뀌죠. 반대로 “게시물 등록” 같은 POST는 보낼 때마다 새 글이 생길 수 있어서 멱등성이 없습니다. 네트워크가 불안정해서 요청이 두 번 날아가면 결제나 주문 같은 건 진짜 사고로 이어질 수 있으니, 이 감각은 실무에서 꽤 중요합니다.
Q5: 파일 업로드 시 왜 multipart/form-data를 사용해야 하나요?
A: 글자는 텍스트지만, 사진이나 영상은 이진(binary) 데이터라서요. application/x-www-form-urlencoded는 텍스트 전송에 맞춰져 있어서 파일을 제대로 담기 어렵습니다. multipart/form-data는 요청 본문을 여러 파트로 쪼개서 한 칸에는 텍스트, 다른 칸에는 파일을 넣는 식으로 보낼 수 있게 해줘요. 파일이 끼면 이걸로 가는 게 정석입니다.
안녕하세요, 코드 치는 게 일상인 12년 차 백엔드 개발자입니다. 😉
복잡해 보이는 API 공식 문서, 제가 초보자 눈높이에서 아주 쉽게 풀어드릴게요.
막히는 게 있다면 언제든 물어보세요. 같이 삽질하며 성장해 봅시다! 💪
