GET과 POST의 차이

다들 아시다시피 GET과 POST는 HTTP프로토콜을 이용해서 서버에 무언가를 전달할 때 사용하는 방식입니다. 웹개발자라면 당연히 알고 있어야 하는 사항이고 이걸 모르면 웹개발자체를 할 수가 없습니다. 상당히 기초적인 부분이긴 한데 잘 모르시는 분들도 있고 해서 미루고 미루던 포스팅을 이제야 합니다. ㅎㅎ GET과 POST 얘기를 하니까 예전 생각이 납니다. 예전이라고 해봤자 불과 2년밖에 되지 않았군요. 졸업을 앞두고 어떤 회사에 면접을 봤었는데 거기 이사님이 저에게 GET과 POST의 차이점이 뭐냐고 물었었는데 전 그땐 그게 무슨말인지도 몰랐죠. 떨어진 이유가 아마 그거이지 싶네요.. ㅎㅎㅎ(지금 생각하면 창피하군요)



어쨌든 처음 웹개발을 하게 되면 한번쯤은 생각하게 되는 문제 입니다. GET과 POST는 머가 다를까.... 하는.... 저도 처음엔 이게 상당히 궁금했습니다. 흔히 얘기하는 GET과 POST의 차이는 다음과 같습니다.(배울때 당시 이해하던 수준정도로만 적습니다.)

  • GET은 주소줄에 값이 ?뒤에 쌍으로 이어붙고 POST는 숨겨져서(body안에) 보내진다.
  • GET은 URL에 이어붙기 때문에 길이제한이 있어서 많은양의 데이터는 보내기 어렵고 POST는 많은 양의 보내기에도 적합하다.(역시 용량제한은 있지만)
  • 즉 http://url/bbslist.html?id=5&pagenum=2 같이 하는 것이 GET방식이고 form을 이용해서 submit을 하는 형태가 POST입니다.
처음 배울때 배운건 이정도뿐이었던 것 같습니다. 위 내용은 맞는말이긴 하지만 이로썬 해결안되는 문제가 있습니다. 그건 언제 GET을 쓰고 언제 POST를 써야 하는가에 대한 문제였습니다. 이건 신입일때 꽤 오랫동안 생각하고 있었던 문제이기도 하는데 딱히 가르쳐 주는 곳은 없었습니다. 지금와서 보면 책에 이에 대해 나와있는 책들이 상당히 많이 있습니다만 웹표준에서도 그러하듯이 현업의 개발에서는 "원래의 목적에 맞게 기술을 사용하고 있는가?"에 대해서는 크게 관심이 없고 "어떤 기술이든 기능을 구현할 수 있는가?"에만 관심을 가지는 것이 전반적으로 깔려있기 때문에 이런 부분에 대해서 관심을 가지는 개발자는 빈도수로 봤을때 그리 많지 않은 듯 합니다. 어쨌든 쉽게 말하면 클라이언트에서 서버로 데이터를 전송하려면 GET 아니면 POST밖에 없습니다.(사실 HTTP에는 PUT, DELETE등등 몇가지 더 있지만 그건 이글의 범주에서 벗어나서 언급하지 않습니다. 사실은 잘 몰라서 ㅡ..ㅡ HTTP 1.1 스펙 새창으로 열기 참조)

id를 넘겨서 게시판의 리스트를 가져온다고 하면 당연히 GET을 쓸 것이고 글을 작성한다고 하면 POST를 작성하는 것이 일반적입니다. 전달해야 될 양이 많을 경우에는 고민없이 POST를 쓰게 되지만 양이 많지 않은 경우에는 GET도 되고 POST도 되기 때문에 고민이 시작됩니다. GET을 써야하나 POST를 써야하나. GET을 쓰면 URL이 깔끔해 지는 효과도 있기 때문에 작은 양을 여러개 전달해야 할 경우에는 POST를 써야하는가 하는 고민을 하게됩니다.(상당히 명백한 차이인듯 하면서 실제로 개발하다보면 고민하게 되는 경우가 좀 있더군요. 저만 그런지 모르겠지만...)


Image by dbking 새창으로 열기 via Flickr 새창으로 열기

여기서 위의 언급한 차이점 외에 GET과 POST의 중요한 개념이 있습니다.

GET은 가져오는 것이고 POST는 수행하는 것입니다.

이 개념만 잘 생각하고 있으면 상황에 따라서 어느정도 선택을 할 수 있습니다.(물론 그래도 좀 고민되는 예외상황들은 있게 마련이죠.) 좀 자세히 설명하면 GET은 Select적인 성향을 가지고 있습니다. GET은 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태등을 바꾸지 않습니다. 게시판의 리스트라던지 글보기 기능 같은 것이 이에 해당하죠.(방문자의 로그를 남긴다거나 글읽은 횟수를 올려준다거나 하는건 예외입니다.) 반면에 POST는 서버의 값이나 상태를 바꾸기 위해서 사용합니다. 글쓰기를 하면 글의 내용이 디비에 저장이 되고 수정을 하면 디비값이 수정이 되죠. 이럴 경우에 POST를 사용합니다.



이 얘기를 하면 어느곳에서곤 반드시 예시로 나오는 것이 Google의 Accelerator 사건입니다.(대표적으로 예를 들게 이거밖에 없나봅니다. 항상 거론되는걸 보면...) Accelerator라는 것은 그이름대로 웹서핑의 속도를 향상시킬 목적으로 구글이 발표한 것이었습니다. 어떤 웹사이트에 갔을때 페이지에 있는 URL등을 Accelerator가 미리 모두 클릭해봐서 사용자가 해당 URL로 이동하기 전에 이미지등의 미리 받아놓을 수 있는 것들을 받아놓는 역할을 해서 웹서핑의 체감속도를 높여주는 것이 목적이었습니다. 캐시때문에 한번 방문한 사이트는 더 빨리 뜨는 것을 이용한 것이죠.

구글러들은 위에서 언급한 GET과 POST의 개념을 확실히 이해하고 이를 당연하다고 생각하는 사람들이었을 테니 이것이 문제가 될꺼라고는 전혀 생각지 못한듯 합니다. 하지만 현실은 그렇지 않죠. 실제 많은 개발자들은 GET과 POST를 용도구분없이 혼용해서 사용했고 Delete같은 곳에도 GET방식을 편의대로 이용한 것입니다. Accelerator는 이것을 구분하지 못하니 URL만 보였다 싶으면 냅다 클릭을 해댄 것이고 사용자가 클립한 것이 아닌 Bot이 직접 URL로 접근해버리자 해당 데이터들은 Delete를 수행해버려서 메일이나 게시글이 마구 지워지는 사태가 발생하였습니다. 좋은 의도였는데 상당히 안좋은 결과가 되었죠. 우리가 모두 이걸 지켰다면 훨씬 좋은 웹 환경이 됐을 텐데요.



그리고 가져오는 곳에 GET을 사용해야 하는 이유가 하나 더 있습니다. 얼마전에도 관련해서 포스팅한 적이 있지만 웹의 핵심이라고 할 수 있는 Link문제입니다. 기본적으로 웹에서 모든 리소스는 Link할 수 있는 URL을 가지고 있어야 합니다.(퍼머링크(permalink)1퍼머링크라면 더 좋겠지만 꼭 퍼머링크가 아니라고 하더라도) 그래야 Link를 할 수 있으니까요. 쉽게 말하면 어떤 페이지를 보고 있을때 다른 사람한테 그 주소를 주기 위해서 주소창의 URL을 복사해서 줄 수 있어야 한다는 것입니다. POST를 할 결우에는 값이 내부적으로 전달되기 때문에 URL만 전달할 수 없죠. 글을 저장하는 경우에는 URL을 제공할 필요가 없기 때문에 POST를 해도 상관이 없는 것이고요.

다른 것들에서도 그렇듯이 GET과 POST도 그냥 만들어진 것이 아니기 때문에 스펙에 정의된 용도대로 사용한다면 위에 언급한대로 부가적으로 얻을 수 있는 이익이 많이 있고 전체 웹을 생각해도 올바르다고 생각합니다.
Footnote.
  1. 는 인터넷에서 특정 페이지의 고유한 URL 주소를 뜻한다. 이 주소는 어떤 상황에도 관계없이 항상 동일한 내용을 가지는 페이지로 링크된다는 의미에서, 고유(permanent)한 주소라는 뜻의 permanent link를 줄여 만든 말이다. 한국어로 고유링크, 고유주소 등으로 부르기도 한다. - Wikipedia 발췌 - [Back]
2009/03/31 22:53 2009/03/31 22:53
크리에이티브 커먼즈 라이센스
Creative Commons License

Trackback URL : http://blog.outsider.ne.kr/trackback/312

Comments List

  1. 무심코 지나쳤던, 누구나 안다고 생각하지만 정작 물어보면 제대로 답하지 못한 부분인데 좋은 설명 감사합니다. 저도 좋은 참고가 됐네요 :-)

    1. 참고되셨다니 다행입니다. ^^
      말씀하신대로 아주 기초적인 내용인데 딱히 시원하게 설명해주지도 않았던 부분이죠. 의외로 이런 부분에서 혼동하고 있는 사람이 많다는 생각이 들더군요.

  2. 좋은 글 감사합니다.
    어렴풋이만 알고 있던 부분인데, 이렇게 명확히 정리를 해주시니 좋군요.

    1. 감사합니다. ^^
      저도 할때마다 약간씩 헷갈리는 부분이어서요.. ㅎ

  3. 질문하나 드릴께요..
    get은 cache가 가능하고, post는 cache가 원천적으로 불가능한가요?
    post 기반에서 cache를 사용할려고 하는데, 방법이 있는지요?

    1. 흠... 어려운 질문이군요 ㅡ..ㅡ
      저도 캐시에 대해서 자세히는 몰라서(꽤나 복잡하죠.. ㅎ)....

      브라우저의 캐시에 대해서 말씀하시는 것 같은데요 제가 아는 범위내에서만 말씀드리면 캐시를 get이냐 post냐로 하지는 않는 걸로 알고 있습니다. 캐시는 리소스단위로 진행됩니다. css, 이미지, js같은 스테틱한 리소스에 대해서 캐시하고 Fiddler같은 툴로 HTTP를 보면 304 not modified라고 나오는 것이 캐시되 리소스에 대해서 조건부 GET요청을 날린 것이죠.

      아시는 내용을 적은 건지 모르겠지만 100% 맞는 내용을 적은 건지는 저도 좀 확신이 없네요 ^^
      어떤 것을 위해서 그런지 모르겠지만 post값에 따라 수행이 달라지는 post요청을 cache한다는 것 자체가 약간 무리가 아닌가 생각이 듭니다.

  4. 좋은 정보를 배우고 가네요...
    그리고 Cache문제는 Post, Get 둘 다 캐시가 됩니다.
    서버에서 http헤더를 어떻게 넣어주느냐에 따라 달린거죠.
    Post로 Cache를 하더라도 파일 변경 여부를 구분만 한다면 Cache를 구현할 수 있습니다. 세션에 부가 정보를 기록하고 선택적으로 Modified 여부를 날려주면 구현은 가능할 것 같네요.

    1. 저 질문 받고 캐시에 대해서는 약간 헷갈리고 있습니다. ㅎㅎ
      그럼 Post를 캐시하면 조건부Get요청을 보고 선택적으로 서버세어 modifed여부를 날려준다는 것인가요? 그렇게 하려면 브라우저에서 Modified여부를 확인하려는고 서버에 조건부GET을 요청할 때 서버가 판단할 수 있는 어떤 정보를 담아서 날려야 하지 않을까요?

  5. db injection관련 글타래 읽다가 문득 궁금해져서 찾다가 여기까지 왔네요.
    저도 웹에 관련된건 학교에서 수업시간에 배운게 전부라서
    get은 url에 표시되고 post는 표시 안된다... 밖에...;
    좋은글 잘 읽고 갑니다 ^^

    1. 잘 읽으셨다니 감사합니다.
      블로그 운영하기 시작하신지 얼마 안되셨나봐요. 잘 운영하세요. ^^

  6. 잘 읽었습니다 ㅎㅎ 좋은 정보네요

    1. 감사합니다. 도움되셨다니 다행이네요 ㅎ

  7. 좋은글 잘보았습니다.
    이렇게 생각해보니 달라지는군요 ..

    1. 감사합니다. 기초적이지만 중요한 개념이죠 ㅎ

  8. 잘읽었습니다! 감사합니다 :)

    1. 예 댓글 감사합니다. ^^

  9. 현업의 개발에서는 "원래의 목적에 맞게 기술을 사용하고 있는가?"에 대해서는 크게 관심이 없고 "어떤 기술이든 기능을 구현할 수 있는가?"에만 관심을 가지는 것이 전반적으로 깔려있기 때문... 이 글이 엄청 공감 가는군요^^

    좋은 글 잘 보고 감니다. 큰 도움이 되었습니다.

    1. 현업에서는 많이 깔려있죠.. ㅎ 그래도 요즘은 달라진 부분도 꽤 있는것 같기도 합니다. 목적에 맞게 썼을때에 주는 이점도 분명이 있고요. 잘 보아주셨다니 감사합니다. ^^

  10. 좋은글 잘 읽었습니다. 초보자가 읽기에도 매우 좋네요. 감사합니다.

    1. 감사합니다. ㅎㅎㅎ HTTP는 웹의 근간이라 너무 중요하죠... (스펙도 한번 봐야되는데 잘 안되네요... ㅎ)

  11. 글 잘 읽었습니다.
    GET, POST 이번에 개발하는 사이트에서는 꼭 염두해서 개발해봐야겠습니다. ^^
    좋은 글 잘 감사합니다. 자주 들려야겠어요! ㅎㅎ

    1. 예... GET/POST는 웹개발의 핵심이라 중요하죠. 사실 이 생각으로 고민하기 시작하면 많은 부분에서 메서드 선택을 쉽게 할 수 있습니다.

  12. 감사합니다
    공부를 위해 출처 밝히고 스크랩 해가겠습니다.

    1. 예 ^^

  13. 좋은글 잘 보고 갑니다 ^^

    (permanant -> permanent 태클아님 ^^)

    1. 아~ 그러네요.. 수정했습니다. ㅎㅎ

  14. 생활코딩 HTML 수업에 링크 걸고 소개했습니다. 좋은 글 고맙습니다. :)
    http://opentutorials.org/course/11/14 새창으로 열기

    1. 앗 egoing 님께서 직접....
      생활코딩 보면서 참 많이 감탄하고 있습니다. 멋지세요~~

    2. nodejs를 전파하고 계신 Outside님에 비하면 별거 아니죠. 언제 기회가 된다면 꼭 모시고 nodejs 수업 해보고 싶습니다. ^^

    3. 앗... 생활코딩이 더 멋지신데.. ㅎㅎㅎ
      저라도 괜찮으시다면 언제든 가능하지만 사실 제가 말로 설명하는걸 잘 못해서.. ^^;;;

    4. 그럼 조만간 한번 찾아 뵐께요. 수업이 아니라도 가볍게 차나 마시면서 이야기 나누고 싶습니다. :)

    5. 예.. 저도 좋습니다. ㅎㅎㅎㅎ
      사실 수업(?)보다는 그냥 뵙는게 더 편하죠... 트위터나 메일로 연락주셔도 좋구요 ㅎ

  15. 처음했던 고민들 이제서야 다시 생각해보게 됩니다. 좋은글입니다.

    1. 감사합니다...

Leave a Reply

Facebook Comments

  • Categories

    List (923)
    BlaBlaBla~ (127)
    JAVA (165)
    Scala (55)
    .NET (21)
    PHP (1)
    Database (31)
    Programming (150)
    Publishing (41)
    Javascript (132)
    node.js (89)
    CoffeeScript (10)
    Ruby on Rails (11)
    RIA (10)
    Web 2.0 & Semantic (47)
    Ubuntu (6)
    Mobile (23)
    Cloud (4)
  • Tag Cloud

  • Calendar

    «   2013/05   »
          1 2 3 4
    5 6 7 8 9 10 11
    12 13 14 15 16 17 18
    19 20 21 22 23 24 25
    26 27 28 29 30 31  
  • Archives

  • My Books

    NODE.JS 프로그래밍
  • Recent Posts

  • Recent Comments

  • Recent Trackbacks

  • Recent My Delicious

  • Site Stats

    • Total hits: 2491103
    • Today: 2663
    • Yesterday: 2983
  • 4352

    3303

    0

    -30 days

    today : 2663

    Google PageRank Checker Powered by  MyPagerank.Net