어쨌든 처음 웹개발을 하게 되면 한번쯤은 생각하게 되는 문제 입니다. GET과 POST는 머가 다를까.... 하는.... 저도 처음엔 이게 상당히 궁금했습니다. 흔히 얘기하는 GET과 POST의 차이는 다음과 같습니다.(배울때 당시 이해하던 수준정도로만 적습니다.)
- GET은 주소줄에 값이 ?뒤에 쌍으로 이어붙고 POST는 숨겨져서(body안에) 보내진다.
- GET은 URL에 이어붙기 때문에 길이제한이 있어서 많은양의 데이터는 보내기 어렵고 POST는 많은 양의 보내기에도 적합하다.(역시 용량제한은 있지만)
- 즉 http://url/bbslist.html?id=5&pagenum=2 같이 하는 것이 GET방식이고 form을 이용해서 submit을 하는 형태가 POST입니다.
id를 넘겨서 게시판의 리스트를 가져온다고 하면 당연히 GET을 쓸 것이고 글을 작성한다고 하면 POST를 작성하는 것이 일반적입니다. 전달해야 될 양이 많을 경우에는 고민없이 POST를 쓰게 되지만 양이 많지 않은 경우에는 GET도 되고 POST도 되기 때문에 고민이 시작됩니다. GET을 써야하나 POST를 써야하나. GET을 쓰면 URL이 깔끔해 지는 효과도 있기 때문에 작은 양을 여러개 전달해야 할 경우에는 POST를 써야하는가 하는 고민을 하게됩니다.(상당히 명백한 차이인듯 하면서 실제로 개발하다보면 고민하게 되는 경우가 좀 있더군요. 저만 그런지 모르겠지만...)
여기서 위의 언급한 차이점 외에 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도 그냥 만들어진 것이 아니기 때문에 스펙에 정의된 용도대로 사용한다면 위에 언급한대로 부가적으로 얻을 수 있는 이익이 많이 있고 전체 웹을 생각해도 올바르다고 생각합니다.
- 는 인터넷에서 특정 페이지의 고유한 URL 주소를 뜻한다. 이 주소는 어떤 상황에도 관계없이 항상 동일한 내용을 가지는 페이지로 링크된다는 의미에서, 고유(permanent)한 주소라는 뜻의 permanent link를 줄여 만든 말이다. 한국어로 고유링크, 고유주소 등으로 부르기도 한다. - Wikipedia 발췌 - [Back]
무심코 지나쳤던, 누구나 안다고 생각하지만 정작 물어보면 제대로 답하지 못한 부분인데 좋은 설명 감사합니다. 저도 좋은 참고가 됐네요 :-)
참고되셨다니 다행입니다. ^^
말씀하신대로 아주 기초적인 내용인데 딱히 시원하게 설명해주지도 않았던 부분이죠. 의외로 이런 부분에서 혼동하고 있는 사람이 많다는 생각이 들더군요.
좋은 글 감사합니다.
어렴풋이만 알고 있던 부분인데, 이렇게 명확히 정리를 해주시니 좋군요.
감사합니다. ^^
저도 할때마다 약간씩 헷갈리는 부분이어서요.. ㅎ
질문하나 드릴께요..
get은 cache가 가능하고, post는 cache가 원천적으로 불가능한가요?
post 기반에서 cache를 사용할려고 하는데, 방법이 있는지요?
흠... 어려운 질문이군요 ㅡ..ㅡ
저도 캐시에 대해서 자세히는 몰라서(꽤나 복잡하죠.. ㅎ)....
브라우저의 캐시에 대해서 말씀하시는 것 같은데요 제가 아는 범위내에서만 말씀드리면 캐시를 get이냐 post냐로 하지는 않는 걸로 알고 있습니다. 캐시는 리소스단위로 진행됩니다. css, 이미지, js같은 스테틱한 리소스에 대해서 캐시하고 Fiddler같은 툴로 HTTP를 보면 304 not modified라고 나오는 것이 캐시되 리소스에 대해서 조건부 GET요청을 날린 것이죠.
아시는 내용을 적은 건지 모르겠지만 100% 맞는 내용을 적은 건지는 저도 좀 확신이 없네요 ^^
어떤 것을 위해서 그런지 모르겠지만 post값에 따라 수행이 달라지는 post요청을 cache한다는 것 자체가 약간 무리가 아닌가 생각이 듭니다.
좋은 정보를 배우고 가네요...
그리고 Cache문제는 Post, Get 둘 다 캐시가 됩니다.
서버에서 http헤더를 어떻게 넣어주느냐에 따라 달린거죠.
Post로 Cache를 하더라도 파일 변경 여부를 구분만 한다면 Cache를 구현할 수 있습니다. 세션에 부가 정보를 기록하고 선택적으로 Modified 여부를 날려주면 구현은 가능할 것 같네요.
저 질문 받고 캐시에 대해서는 약간 헷갈리고 있습니다. ㅎㅎ
그럼 Post를 캐시하면 조건부Get요청을 보고 선택적으로 서버세어 modifed여부를 날려준다는 것인가요? 그렇게 하려면 브라우저에서 Modified여부를 확인하려는고 서버에 조건부GET을 요청할 때 서버가 판단할 수 있는 어떤 정보를 담아서 날려야 하지 않을까요?
db injection관련 글타래 읽다가 문득 궁금해져서 찾다가 여기까지 왔네요.
저도 웹에 관련된건 학교에서 수업시간에 배운게 전부라서
get은 url에 표시되고 post는 표시 안된다... 밖에...;
좋은글 잘 읽고 갑니다 ^^
잘 읽으셨다니 감사합니다.
블로그 운영하기 시작하신지 얼마 안되셨나봐요. 잘 운영하세요. ^^
잘 읽었습니다 ㅎㅎ 좋은 정보네요
감사합니다. 도움되셨다니 다행이네요 ㅎ
좋은글 잘보았습니다.
이렇게 생각해보니 달라지는군요 ..
감사합니다. 기초적이지만 중요한 개념이죠 ㅎ
잘읽었습니다! 감사합니다 :)
예 댓글 감사합니다. ^^
현업의 개발에서는 "원래의 목적에 맞게 기술을 사용하고 있는가?"에 대해서는 크게 관심이 없고 "어떤 기술이든 기능을 구현할 수 있는가?"에만 관심을 가지는 것이 전반적으로 깔려있기 때문... 이 글이 엄청 공감 가는군요^^
좋은 글 잘 보고 감니다. 큰 도움이 되었습니다.
현업에서는 많이 깔려있죠.. ㅎ 그래도 요즘은 달라진 부분도 꽤 있는것 같기도 합니다. 목적에 맞게 썼을때에 주는 이점도 분명이 있고요. 잘 보아주셨다니 감사합니다. ^^
좋은글 잘 읽었습니다. 초보자가 읽기에도 매우 좋네요. 감사합니다.
감사합니다. ㅎㅎㅎ HTTP는 웹의 근간이라 너무 중요하죠... (스펙도 한번 봐야되는데 잘 안되네요... ㅎ)
글 잘 읽었습니다.
GET, POST 이번에 개발하는 사이트에서는 꼭 염두해서 개발해봐야겠습니다. ^^
좋은 글 잘 감사합니다. 자주 들려야겠어요! ㅎㅎ
예... GET/POST는 웹개발의 핵심이라 중요하죠. 사실 이 생각으로 고민하기 시작하면 많은 부분에서 메서드 선택을 쉽게 할 수 있습니다.
감사합니다
공부를 위해 출처 밝히고 스크랩 해가겠습니다.
예 ^^
좋은글 잘 보고 갑니다 ^^
(permanant -> permanent 태클아님 ^^)
아~ 그러네요.. 수정했습니다. ㅎㅎ
생활코딩 HTML 수업에 링크 걸고 소개했습니다. 좋은 글 고맙습니다. :)
http://opentutorials.org/course/11/14
앗 egoing 님께서 직접....
생활코딩 보면서 참 많이 감탄하고 있습니다. 멋지세요~~
nodejs를 전파하고 계신 Outside님에 비하면 별거 아니죠. 언제 기회가 된다면 꼭 모시고 nodejs 수업 해보고 싶습니다. ^^
앗... 생활코딩이 더 멋지신데.. ㅎㅎㅎ
저라도 괜찮으시다면 언제든 가능하지만 사실 제가 말로 설명하는걸 잘 못해서.. ^^;;;
그럼 조만간 한번 찾아 뵐께요. 수업이 아니라도 가볍게 차나 마시면서 이야기 나누고 싶습니다. :)
예.. 저도 좋습니다. ㅎㅎㅎㅎ
사실 수업(?)보다는 그냥 뵙는게 더 편하죠... 트위터나 메일로 연락주셔도 좋구요 ㅎ
처음했던 고민들 이제서야 다시 생각해보게 됩니다. 좋은글입니다.
감사합니다...
좋은정보입니다. 감사합니다.
네.. ㅎㅎㅎ
생활코딩 보고 왔어요~
목적에 맞게 기술을 사용하고 있는가라는 말이 마음에 남네요~.~!
명심해야 될 듯^^
괜히 "GET" "POST"라고 지어진 게 아니네요
다 의미가 있는 말이 였어요...
글 너무 잘 읽었습니다!!!
실제로 하면 꽤 어려운 부분이기도 합니다. ^^
보통 메소드를 구분해서 사용하는게 맞는데 보통 개발자들은 get post로 모든 작업을 하죠 그래서 웹방화벽 같은 장비도 보면 대부분 get post 메소드만 정상적으로 판단하고 다른 options 나 delete 등과같은 메소드는 정상적이지 않은 메소드로 판단하게끔 디폴트로 설정되있습니다 메소드를 정확하게 용도에맞게 구분한다면 보안측면에서도 강화가 될수 있다고 판단됩니다
PUT이나 DELETE를 사용하는 건 이 글의 범위를 벗어나긴 하지만 GET과 POST를 이해하고 구분해서 사용하는게 중요하다는데 동의합니다.
WAF가 get과 post만 정상 메소드로 식별하는건 개발자들이 get과 post로 모든 작업을 해서가 아닙니다..
options나 delete, put 등의 메소드는 사용자입장에서는 아무 필요가 없는 메소드이기 때문입니다.
불필요한 메소드를 비활성화, 차단하지 않으면 PHP injection, ASP injection, eval 함수 실행 등
코드주입 및 WebShell 업로드 공격으로부터 위험해지기 때문입니다.
내용 잘 보고 감니다. 개념 이해하는데 정말 많은 도움이 되었습니다.
네 방문해 주셔서 감사합니다. ^^
오랜만에 정말 좋은글 보고 갑니다
쉽다면 쉬운 내용이지만 저한테는 그 무엇보다 유용한 정보였습니다.
어려운 내용은 아니지만 꼭 이해해야 하는 부분중 하나죠 ^^
이제 웹서버에 대해 입문하기 시작한 초보블로거입니다 ㅎㅎ
GET과 POST의 명확한 설명 감사합니다 ㅎ 제 블로그에는 앞으로 임베디드 관련해서 웹서버를 임베디드 보드에 구현하고 클라이언트인 웹브라우저로 제어하는 것을 만들어서 포스팅 할 건데요 앞으로 많은 교류가 있었으면 좋겠습니다 ㅎㅎ
공부 목적으로 스크립해갈게요 ㅎㅎ
안녕하세요. ㅎㅎ 블로그를 시작하셨다니 꾸준히 좋은 정보를 공유해 주셨으면 좋겠네요. 라즈베리파이도 나오고 하니까 요즘은 임베디드도 흥미롭더라구요. ㅎ
감사합니다.
사실 POST와 GET의 차이에 대해서 무엇인지 의문을 가졌는데
글을 읽고 의문이 사라졌네요 ^^
의문을 해결해 주셔서 감사합니다.
해결되셨다니 잘 됐네요 ^^
친절한 설명 감사드립니다~!
많은 도움이 되었습니다.
네 ^^
좋은정보 감사합니다. 공유할게요^^
좋은저보 감사합니다
대단하시네요.. 매번 블로그에 와서 눈팅만 하지만...
정말 많이 알고 계신것 같습니다.
많이 보고 배우고 갑니다.
궁금한게 많아서 이것저것 해보는 편입니다. 그러고 보니 이 글도 시작한지 2년정도 되서 쓴 글이네요.
늘 헷갈렸던 것인데, 알기 쉽게 설명해 주셔서 감사합니다.
감사합니다. 덕분에 유용한 정보 습득했습니다.^^
좋은 글 너무 감사합니다. 현재 웹을 공부한는 컴퓨터공학도입니다.
google Accelerator 사건에서 delete 부분을 GET으로 사용해서 왜 사건이 발생했는지 정확히 설명해주실수 있나요..? GET은 가져오는것인데 Delete를 왜 수행하는 것인지 잘 모르겠습니다.구글에 accelerator 사건이라 쳐봐도 잘 나오지를 않네요;;ㅜㅜ
요즘은 이런 일이 많지 않고 너무 오래된 사건이라서 그런가 봅니다.
구글은 당연히 HTTP 스펙을 이해하고 있었고 GET은 가져오는 용도로 생각하고 Acceerlator를 구현한 것인데 당시에 많은 웹사이트 개발자들이 모두 HTTP 스펙을 이해하고 있는 것은 아니므로 삭제기능도 GET으로 구현한 곳이 많았던 것입니다. 예를 들면 삭제버튼이 POST나 DELETE 메서드가 아니라 `/delete?id=XXX`같은 URL을 GET으로 보내면 지워지도록 구현한 것입니다.
그래서 Accerlator가 적용되자 이런 걸 다 찾아서 지우고 다니기 시작했던 것입니다.
감사합니다 이해가 바로 되네요.
좋은글이라 출처 남기고 스크랩 해갈게요
이런 한 좋은글 남겨주셔서 감사합니다.
그러면 방문자의 로그를남기는것들에 대해선 GET인가요 POST인가요
로그라면 POST죠. GET은 명득이어야 하는데 로그는 여러번 남기면 로그도 여러개가 생기니까요.
설명 너무 잘 해주셔서 초보가 이해하기 너무 좋습니다.
출처표시하고 제 블로그에 퍼갈께요~^^
저도 초보지만..의아한 부분이 있어서 댓글 남깁니다. 오래 전 글이지만 답글보니까 추가되었으면 해서요 ㅎㅎ
1. get방식은 쿼리스트링(위에서 말한 물음표)으로 보내고, post는 body안에 보내진다고 했는데, 제가 알기론 body가 아니라 html의 header에 포함되는 것으로 알고 있습니다. 별 차이 아닌 것 같지만 내부 로직을 이해하는데 큰 차이가 있지요. 추가적으로 get방식은 url을 타고 쿼리스트링으로 값이 전달되기에 보안에 굉장히 취약합니다.
2. 쿼리스트링으로 보내는게 get이고, form을 이용해 submit하는 것이 post라고 하셨는데 조금 잘못된 설명인 것 같습니다. form으로 전송하는건 get과 post모두 가능합니다. 참고로 method는 기본값이 get입니다.
음...
1번은 이해를 못했습니다. POST를 할 때 어떤 부분이 헤더에 들어간다는 애기신가요? 해당 부분에 대한 설명은 잘못된 건 없는것 같습니다.
2. 이부분은 말씀하신대로 제가 너무 퉁쳐서 설명한게 맞는것 같습니다. form으로도 GET, POST(외 다른 메서드도) 다 가능한게 맞습니다. 저 설명에서는 보통 form을 POST로 처리하는 경우가 더 많으므로 form으로 퉁쳐서 설명하긴 했네요.
안녕하세요. 지나가는+공부하는 학생입니다.
post방식의 요청 메시지 구조를 보면
요청라인, 헤더, 공백, 바디의 순서로 나뉘어있으며
요청라인에 '메소드방식' 'URL' 'http버전'이 들어가고
헤더에는 date나 content-type등의 정보가 들어가고
바디에 요청 파라미터 정보가 들어가는 것으로 알고있습니다.
다음 링크를 참고했습니다.
http://dololak.tistory.com/142
https://zetawiki.com/wiki/GET_%EB%B0%A9%EC%8B%9D,_POST_%EB%B0%A9%EC%8B%9D
좋은 포스트 감사합니다.
get은 가져오는 것이고 post는 수행하는 것이다. 가슴에 와닿는 말이네요.
많은 도움 되었습니다. 감사합니다.
좋은 것 배우고 갑니다.
감사합니다.
좋은글 잘 읽고갑니다 거의 십년전 글이지만 아직도 저같은 사람에게 도움이 되네요 :) 안그래도 지금 회사에서 get이랑 post가 헷갈려서 혼자 끙끙 앓고있었습니다ㅠㅠ 다시한번 감사드리고 건필하세요!
안녕하세요! 너무 좋은 설명 감사드립니다. 이해가 너무 잘되네요.
읽는 도중에 잘 이해가 되지 않는 부분이 있는데...
GET을 쓰면 URL이 깔끔해 지는 효과도 있기 때문에
-> 이부분이 잘 이해가 안되는데, get 방식에서는 URL 뒤쪽에 ?와 파라미터들이 덕지덕지 붙어서 전달되는데, 왜 GET을 쓰면 URL이 깔끔해지나요? POST가 더 깔끔하다고 생각되는데...
음... 지금 보니 저도 어색한 느낌인데 8년전에 쓴글이라 제가 의도한 정확한 의미가 좀 애매하긴 하네요. 지금 읽어보면서 생각해 보면 POST를 쓰는 경우 URL에 대한 테스트나 확인을 할 때 바디에 데이터를 주어야 해서 복잡해지는 부분이 있습니다. GET으로 하면 브라우저나 CURL에서나 바로 해볼 수 있으므로 간단해 지는 부분이 있어서 그부분에서 깔끔해 진다고 쓴것 같습니다.
지나가는 과객이 한말씀 올립니다.
wireshark로 찍어보면 GET하구 POST차이 확실히 아실수 있습니다.
먼저 GET은
GET /status.html?age=12&name=james HTTP/1.1 <= 여기에 파라메터가 날라갑니다.
Host: 192.168.0.22
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Referer: http://192.168.0.22/
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
즉, Http 헤더에 파라미터를 전송을 할려면 제한이 되겠지요? 255바이트인가 1024인가 뭐 그럴겁니다.
다음 POST
POST /status.html HTTP/1.1
Host: 192.168.0.22
Connection: keep-alive
Accept: application/json, text/javascript, */*; q=0.01
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
Referer: http://192.168.0.22/
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
age=12&name=james <=여기가 http바디이며 이진데이타든 텍스트든 어떤사이즈의 데이타도 보낼수 있게 됩니다.
작은데이타를 보낼때는 GET이나 POST로 보내거나 상관없겠지만
당연히 이미지같은 바이너리 파일을 서버로 올리거나 데이타가 많아지면 POST를 써야 겠지요?
안녕하세요. 학생때 봤던 글인데 취직하고 나서도 이해가 잘 되지않아 구글링을 한참 해서 찾아왔네요 ㅎㅎ 지금 보니 이해가 되는 것 같습니다.
제가 실무에서 사용하다보니 궁금한게 생겼는데, 그렇가면 json을 리턴할때 get을 허용하는것과 허용하지 않는것의 차이는 무엇일까요? 아직 경험이 많이 없어서 구글링도 잘 못하겠고 이해하기가 약간 힘이들어서요ㅠㅠ
질문을 제가 정확히는 이해못하겠지만 GET을 허용하는 것과 JSON을 리턴하는 것은 완전히 다른 얘깁니다. GET은 이 글에서 설명한 대로고 JSON응 응답할 것인지 아닌지는 요청 헤더의 accept에 따라 달라집니다. content negotiation에 대해서 찾아보시면 도움이 될 겁니다.
평소에 많이 햇갈렸던 정보인데 덕분에 정리가 되었습니다.
좋은글 감사합니다.
단순히 client가 server에게 사진 또는 json 형태의 결과값을 요청하는것은 GET을 사용해야하는건가요..?
네 그럴때는 GET을 쓰시면 됩니다.
공부하다가 제일 의문이였던 점이였는데, 개념 설명만 봐서는 get이고 post고 마음대로 쓰면 되는 것 아니야?라고 생각했다가 구글의 사례보고 확실히 이해가 되었습니다 !!!!!정말 감사해요
안녕하세요! 저는 안드로이드 개발자인데 서버랑 get, post 할 때 어떤 차이점이 있는가 궁금했는데 확실히 이해하고 갑니다. 덕분에 잘 정리하고 가네요.
혹시 링크를 블로그 게시글에 써서 개인소장해도 될까요? 나중에 헷갈릴 때 쉽게 찾아서 보고싶어서요 히히
네 CCL 하에서 사용하시면 됩니다.