Fast Web Service #2 빠르다는 것은 무엇인가?

다즐링의 이미지

웹서비스에 대한 정의가 되었으니 빠르다는 것에 대해서 정의를 해야겠다.

대부분의 웹서비스는 고객이 대상이다. ( 크롤링 봇이나 RSS 등은 좀 제외해도 되겠다. ) 고객의 브라우저에서 빠르게 결과가 나오면 되는것이다.
하지만 인터넷세상에서 빠르다는 것은 매우 상대적인 개념인데 이유인즉슨 사람들의 상황이 다 다르기 때문이다.

아이폰을 을 이용하고 3G 를 통해서 웹페이지를 접속하는 사람과 빵빵한 I7 CPU 에 광랜을 통해 웹페이지를 보는 사람이 존재 가능한것이다.
심지어 아직도 모뎀을 이용해서 웹서비스를 사용하는 사람이 많은 것이 사실이다. 그래서 다음의 두가지 항목에 대해서 여러가지 변주가 존재한다.

프로세싱 파워 , 네트워크 접속

어떤 블로그를 보니 일반적인 고객은 3초내에 웹페이지가 떠야 페이지 이탈을 하지 않는 다고 한다. ( 많이 들어본 이야기일터라 굳이 출처를 명기하지는 않겠다 )

그럼 페이지가 뜬다는 것은 어떤 이야기인가? 다음의 시간의 합이라고 볼수 있다.

고객이 요청한 도메인을 찾는 시간 + 고객의 요청이 서버에 도달하는데 걸린시간 + 서버에서 처리하는데 걸린시간 + 처리결과가 도달하는데 걸린시간 + 브라우저에서 데이터를 파싱하고 보여주는 시간

상기 시간들의 합이 작다면 그리고 그 합이 어떤 네트워크든 3초이내라면 빠르다고 볼수 있을 것이다.

상기항목에서 처음의 항목은 dns 의 능력 혹은 설정에 따라 상이할 것이다.
하지만 대부분의 경우 dns 는 캐슁이 가능하고 local dns 에서 빠른 응답을 보장하는 것이 대부분 이고
( 게다가 windows 의 경우 자체 캐슁을 한다. )
웹 서비스 제공자가 통제 불가능한 것이 대부분이다.
( 혹은 통제 가능하더라도 많은 금액이 듬 ) 그러므로 제외하자.

두번째인 고객의 요청이 서버에 도달하는데 걸린 시간을 생각해보자.
이 부분은 고객의 요청의 갯수와 양에 비래한다. 그러면 요청수를 줄이는것이 시간을 줄이는 방법이 되겠다.

3,4,5번째의 시간에서 여러가지 고민할 거리가 많아진다.
여기서 생각해볼 꺼리가 많아진다. 점차 생각해보도록 하자.

댓글

liame의 이미지

재밌는 주제로 글을 쓰셔서 유심히 보고 있습니다.

댓글로 질문을 드려도 되는지 모르겠네요. 혹시 실례라면 죄송하구요.

성능을 정의할 때 보통 "응답시간(response time)", "시간당 처리량(throughput)", "자원 활용율(resource utilization") 을 얘기하고, 서버인 경우 특히 시간당 처리량이나 자원 활용율을 중요시하지 않나요?

예전에 유행처럼 성능에서 response time관점을 중요시 한 경우도 있지만, 요즘은 아닌거 같은데, 제가 잘못알고 있나요?

예를 들어 PLC( peak load control ) 같은게 위에서 언급하신 "요청수를 줄여서 시간을 줄이는 방법"이라고 생각되네요.

언제인지 모르겠지만 버튼을 누르면 화면에 "요청중입니다" 라는 팝업이 뜨고 서버에 로드가 많은 경우, "요청이 많아 처리할 수 없습니다."라는 메세지를 뿌리는 방식이 있었는데요.

이런 방식은 서버입장에서는 빠르게 요청을 처리한다고 할 수 있겠지만, 사용자 입장에서는 원하는 작업을 처리하지 못한 것이죠. 또, 여러 요청이 들어왔을 때, 어떤 요청을 처리할 지에 대한 기준을 사용자들이 납득할 수 있느냐 하는 것도 상당히 문제가 될거라 생각되는데 과연 이런 방식이 좋은가요?

다즐링의 이미지

고객의 관점에서 그게 서비스가 되는건 아니죠.

그리고 서버의 경우 시간당 처리량이나 자원활용율 이런건 아무 의미가 없습니다.

response time 이 제일 중요합니다.

고객이 불만을 느끼지 않고 빨리 떠서 빨리 활용이 이루어지고 그걸로 빨리 돈을 버는게 목적인거죠.

그리고 처리량을 줄인다는 이야기는 실제로 쓸데 없는 트래픽이나 요청을 줄이는 방법이지 서비스가 안된다는 이야기는 아닙니다.

그런식으로 서비스 하던 시대는 지났죠.

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

liame의 이미지

응답에 필요한 데이터를 먼저 처리해서 응답을 보내고,

나머지 일은 나중에 처리하는 방식을 말씀하시는 것인가요?

예를 들어 고객 가입시 필수 데이터를 저장후 응답을 보내고, 가입 축하 이메일은 다른 쓰레드가 처리하는 방식같은?

response time을 줄일 수 있는 예를 좀 들어주시면 쉽게 이해할 수 있을 것 같은데요.

소타의 이미지

웹서버의 응답 속도를 빨리 하는 방법으로 좋은 예를 들어주셨네요.
이 글의 시리즈에서 말하는 성능은 웹서버 데몬의 응답 속도가 아니라 사용자의 클릭 후 얼마나 빨리 사용자가 원하는 컨텐츠를 빨리 전달하느냐인 것 같습니다.
웹페이지의 성능은 웹서버의 속도보다 다른 요인이 많이 작용합니다. 웹서버에서 HTML을 빨리 주는 것도 중요하지만 좀 더 빨리 준다고 사용자 화면에 항상 그만큼 빨리 뜨는건 아니니까요.

가입 페이지는 좀 느려도 상관없다고 생각합니다. 가입 페이지 submit이 좀 느려도 여기까지 온 사람은 대부분 기다립니다. 하지만 가입 페이지까지 가는데 느리면 망하는거죠.

liame의 이미지

프로세스에 대한 얘기인가요?

예를 가입 페이지로 들어서 저도 같은 걸로 ^^;

가입을 3단계의 페이지로 처리한다면 1단계, 2단계에서는 되도록 처리하지 말고 마지막 단계에서 처리하는 방식이나 1단계 2단계를 없애고 하나의 페이지로 처리하는 방식을 말씀하시는 것인가요?

소타의 이미지

웹서비스의 성능은 실제로 어떻게 되든 상관없이, 사실은 느리더라도 사용자가 볼 때 빠르다라고 느끼게 만드는 것
우훟 레드썬

김정균의 이미지

response time 도 중요하지만.. 조금 더 나아가면.. browser randering 시간도 꽤 중요합니다. 요즘 같이 한 페이지에 컨텐츠가 많고, table / layer / css / js 등등의 복합적인 구조는 browser randering을 엄청나게 잡아먹는 경우가 많습니다.

즉, DB tuning을 아무리 잘하더라도.. query가 엉망이면 쉽게 망가지듯이.. 서버/네트워크 부분을 아무리 잘 처리해 놓더라도 browser randering이 꽝이면.. 그냥 꽥 인것이죠. :-)

요즘은 이런 경우가 많이 개선이 되었는데, 예전 광고 대행 업체를 끼고 웹페이지에 광고를 개제할 경우, 외부 javascript를 imbed하는 경우가 있었는데, 이 경우 외부 javascript가 제대로 응답을 못해서 page를 띄우는데 지연이 되고 하던 문제가 많았습니다. 이런 경우가 대표적인 경우가 될 수 있는 것이죠.

response time도 중요하지만, 요즘의 웹의 형태는 html coding 역시 굉장히 중요한 부분이 되었습니다. 더군다나 browser engine의 종류도 많아졌죠. (예전에는 ie/gecko 만 신경쓰면 되었는데..)

다즐링의 이미지

흐흐 당연히 이제 그부분 들어가려고 하고 있었죠 ㅠㅠ;

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

김정균의 이미지

ㅎㅎ 댓글 달다 보니 계속 침범할 것 같군요. 앞으로 나올 내용을 미리 토할 것 같아 삭제하고 기다리겠습니다. :-) 재미있어욤.. :-)

liame의 이미지

렌더링이 아니라 통신 구간이 아닌가요?

저는 렌더링이라고 하면 화면에 그리는 시간이라고 생각하고 있었는데요.

예로 들자면 Button과 Image같은 거요. Image가 통신 부하량이 많긴하지만 클라이언트에서 처리하는 게 적어서 rendering time이 적다고 알고 있습니다. 1000개 정도 찍어 보면( image는 동일한 이미지로 ) 버튼은 위에서 부터 차례로 그려지는게 눈에 보이고 이미지는 거의 동시에 그려집니다.

뱀다리 : rendering이 아닌가요?

소타의 이미지

버튼을 많이 표시하는 테스트는 무의미합니다. 실제로 그런 웹페이지는 거의 없습니다.
어떤 언어로 루프 0~1000000 까지 돌리고 C보다 빠르다! 라고 하는 것 같은 실용성 없는 테스트입니다. 아무것도 바꾸지 못하죠..

동일한 이미지가 아니라 다른 이미지로 테스트를 해야합니다.
다른 이미지 1000개가 표시되는 웹페이지도 거의 없지만 존재는 하죠.

예를 들어
사용자가 프로필 이미지를 입력할 수 있는 서비스가 있고,
댓글을 달면 프로필 이미지가 함께 표시되는 게시판이 있을 때,
어떤 글에 1000명의 사람들이 댓글을 달았고 댓글은 한꺼번에 표시됩니다.

이런 상황에서 이 웹페이지가 다 그려지려면 많은 시간이 소요되고 웹서버의 부담도 엄청납니다. 시간과 부담을 줄이기 위해서는 여러 방향에서 다양항 방법으로 해결을 시도해야 합니다.
이미지 서빙 시 expire 헤더를 준다. (side effect 이미지가 변경될 때 즉시 반영되게 하기 위해서 이미지의 URL이 프로필 이미지 변경시마다 달라지게 한다)
웹브라우저가 한 서버에 연결할 수 있는 세션수가 적기 때문에 이걸 피하기 위해 keep-alive를 끄거나 다른 포트 또는 다른 서버에 웹서버를 띄워서 세션을 늘려서 동시에 처리할 수 있는 수를 늘린다. 돈 많으면 CDN~
이 외에도 보이는 부분만 일단 이미지를 가져온다던지 자잘하게 튜닝할 부분이 많죠.

javascript 얘기는 문서를 그리는데 필요한 javascript는 피해야 한다는 것 입니다. DOM을 구성하는 시점에 어떤 내용의 JS라도 동작하게 되면 그 이전까지 include해야 했던 모든 JS파일이 전송되기 전에는 화면에 표시되지 않습니다. 그냥 하얗게 있게 되는데 사용자가 볼 때는 이유는 상관없고 그냥 느린것처럼 보이게 됩니다. 다 튜닝해놔도 이것땜에 느리게 보이는 거죠.

liame의 이미지

답글이 논지에서 벗어난것 같은데, 렌더링 타임에 대한 것을 말하기 위한 "예" 일뿐입니다.

이미지가 1000개 라도 렌더링 타임은 짧습니다. 통신 구간이 길어질 뿐이죠.

혹시 렌더링 타임에 request에 대한 서버 응답시간이 포함된 개념인가요?

저는 렉더링하는 시간에 대해 질문드린 건데 답변은 대부분 통신량(통신횟수?)을 줄이는 얘기 뿐이라서요.( 자바스크립트 예도 전송되지 전에 화면에 표시되지 않는다는 것은 네트웍에 대한 이슈로 봐야 하지 않나요? )

소타의 이미지

웹페이지는 원격의 자원이고 다수의 원격의 자원을 포함하고 있습니다. 이걸 그리는데 네트웍 타임을 고려하지 않고 웹페이지의 성능을 얘기하자면 할 얘기가 별로 없습니다.
렌더링 자체의 성능만 따지면 브라우저 엔진 벤치마킹 얘기가 되겠네요. 이 얘긴 별로 하고 싶지 않아서;; 버튼, 이미지 예도 브라우저 등 사용자의 환경에 따라 성능이 다를것 같습니다.

JS의 예도 이벤트가 생기기 전까지 구성된 DOM이라도 부분적으로 화면에 표시할 수는 있을텐데 대부분의 웹브라우저는 그렇게 하지 않습니다. 렌더링 이슈라고도 볼 수 있죠. 개인적인 의견이므로 따로 이 주장에 대해서는 따로 얘기하지 않겠습니다.

dhunter의 이미지

liame 님이 좋은 컴퓨터를 쓰시는 것 같습니다.

실제로는 한 페이지에 이미지가 1000장쯤 되면 더 이상 무시할 수 없는 랜더링 타임이 될 때도 많습니다.
JPEG 랜더링도 공짜가 아니니까요.

KLDP같은데서는 보기 어려운 이야기입니다만 사진을 주요 컨텐츠로 하는 사이트 (처자 사진, 그림...) 에서는 실제로 그런 일이 날 수 있습니다.

아니면, '이미지'를 '플래시'로 바꾸면 0의 갯수를 하나 줄여도 랜더링 타임이 무의미하다고는 생각하지 않으시겠지요?

또는... 제 500MHz짜리 핸드폰 브라우저라면 어떨까요.

from bzImage
It's blue paper

from bzImage
It's blue paper

liame의 이미지

이미지 렌더링 타임이 적다가 요지가 아니고요.

Button과 비교할 때 그리는 시간의 차이가 있다. "그 시간이 렌더링 타임이 아니냐"를 전달하고 싶었던 것입니다.

아, 그리고 이미지 렌더링 타임이 Button과 비교할 때 짧다는 것 뿐이지 렌더링 타임이 가장 짧다고 얘기하고 싶은 것도 아닙니다.

플래시를 언급하셨는데 제가 지금 silverlight로 개발 중인데, 처음 접하고 두달 정도 밖에 안되었는데도 왜 이런 걸 쓰나 하는 생각밖에 안드네요.( RIA라고 하는 것들이 무겁긴 무겁나 봅니다. )

제가 아직 미숙해서 그렇다고 위안 삼는 중입니다.

김정균의 이미지

해당 부분은 통신 구간이 맞지만.. 이 통신 구간 때문에 randering (ㅎㅎ 사전 찾아 보니 제가 오타네요) 시간이 지연이 됨을 의마하는 것입니다.

제가 하고 싶은 표현을 좀더 까발리자면.. 예전에는 이 외부 url을 script tag로 직접 사용했었는데, 이게 문제가 되어서 iframe 이용을 많이 하게 되었고, 요즘은 local script에 rpc 통신을 하는 식으로 randering 시간에 영향을 주지 않도록 변화하고 있습니다.

이런 이유로, 통신 구간이지만 randering으로 표현을 한 것입니다.

tael의 이미지

아.. 죄송합니다만, 렌더링의 스펠링은 rendering입니다. 사전찾아보고 오셨는데도 습관이되서 그러신지 위에 써두신것과 똑같이 randering 이라고 쓰셨네요..
그리고 위에 imbed 라고 되어있는 부분은 embed를 의미한게 아니신지요?
스펠의 압박이랑 별개로 그냥 '렌더링' 이라고 하는게 보기가 더 좋은 것 같습니다.

- TaeL

liame의 이미지

빠르다는 것에 대한 정의를 하셨는데, 정량적이지 못한 것 같습니다.

혹시 정량적인 기준이나 측정 방법이 있나요?

단순히 3초를 넘기면 안된다 인가요?( 정적 페이지를 띄우는 것과 복잡한 서비스 결과 페이지가 동일한 기준으로 평가한다는 것은 웬지 이상하네요. )

아니면 빠르면 빠를 수록 좋다?( 하드웨어나 환경적 요소는 고려 대상이 안되나요? )

WebService에 대한 성능 평가를 위한 팩터가 있으면 좋겠네요.

쉽게 질문드리면,

"A라는 웹서비스는 얼마나 빨라야 하는가?"

에 대한 답을 구하는 법을 알고 싶습니다.

다즐링의 이미지

고객이 객관적인 ( 정량적인 ) 경우를 본적이 없습니다.

최대한 빨라야한다고 생각합니다.

------------------------------------------------------------------------------------------------
Life is in 다즐링

------------------------------------------------------------------------------------------------
Life is in 다즐링

liame의 이미지

현실은 그렇지만, 합리적으로 만들어진 정량적이 기준이 있다면 그런 고객도 설득할 수 있지 않을까요?

결국은 workload 밖에 없는 건가요? 좀더 논리적인 팩터가 있으면 좋겠다고 생각이 들었는데...

소타의 이미지

웹서비스에 대한 정량적인 기준이 존재할 수 없다고 생각합니다. case by case이고 해당 서비스의 모든 웹페이지마다 점수가 다를 겁니다.
아무리 합리적인 기준이 있더라도 제가 고객이라면 그걸 안믿을 것 같네요. 개발보다 확장성이 보장되는 상태로 시스템이 유지되는것이 중요합니다. 문제는 네트웍 상황, 클라이언트의 환경, 사용자 증가에 따라서 계속해서 변화하니까요.

dhunter의 이미지

학술적이고 통계적인 영역에서 다룰 이야기 같은데 논문 찾아보시는게 더 좋을것 같네요.
실제로 그 부분에 대해서도 아쉬우나마 연구가 이루어진걸로 알고 있습니다.

from bzImage
It's blue paper

from bzImage
It's blue paper

이응준의 이미지

사고의 흐름에 방해를 받지 않으려면 응답시간이 1초 미만이어야 한다고 합니다.

관련논문:
* Response time in man-computer conversational transactions
* THE INFORMATION VISUALIZER, AN INFORMATION WORKSPACE

김정균의 이미지

윗분 말씀대로 정량적인 기준이라는 것은 그저 "최대한 빨리" 밖에 없습니다.

예를 들어 로딩에 10초가 걸리는 경우가 있다면.. 단순히 10초후에 randering을 하는 경우와, 10초 동안에 무언가를 처리해 주고 있음을 알리면서 randering하는 경우는 같은 10초이지만 받아들여지는 입장에서는 굉장한 차이를 보일 수 있기 때문입니다.

또한 contents의 질에 따라서.. 3초이상이 용납안되던 것이 그 이상으로 연장 시킬 수도 있겠죠. 그래서 정량적인 것을 논하기는 힘이 든다고 봅니다.

jinoos의 이미지

최근 동향상 두가지 방향으로 정량해야 한다고 생각합니다.

Frontend (Browser Side) - Backend (Server Side)

Backend는 가볍게 RT를 기준으로 SLA를 서비스 별로 정해두고 페이지에 필요한 Content들의 Response를
완료하는데 어느정도의 시간을 가지겠다 라는 Target을 정하는 절차가 있어야 하며, 이것은 서비스들 별로
특성이 있기에 Full Contents RT를 얼마다 라고 규정하기 보다, 각자에 맏겨야 한다고 봅니다. (FF의 YSlow
같은 툴로 층정이 가능합니다). 다만 이것이 1초, 1.5초, 2초 등과 같이 명확하게 떨어질수 있는 정량
데이터 이여야 하겠지요.

Frontend 단은 좀더 복잡해 지는데 BE의 RT와 FE의 Randering Time을 고려해야 합니다. 일다느 Onload()
함수를 이용한 페이지 총 로딩 시간을 계산하고 BE의 RT를 비교하는 정도가 될것 같습니다. 이것도 역시
정략정 데이터 처리가 가능합니다. 몇초 이런식으로요. Full loading Time 정도가 되겠네요.

어찌되었든, 유저 입장에서는 페이지 로딩과 렌더링이 끝나서 본격적으로 데이터를 사용하기 시작하는
시점이 가장 중요하지만, 측정에서 반영까지는 적지않은 난관이 발생하기도 합니다. 최근의 WEB 2.0의
동향상 Page에서 Transaction이 지속적으로 이루어져, 어디까지를 페이지 로딩 완료라고 봐야 하느냐의
문제도 있으며, 페이지 로딩을 위한 브라우져 단의 부하가 많을때, 이것을 누가 해결해 줘야 하느냐도
현재 시점에서 명확하지 않나 싶고요.

KLDP의 특성을 고려해서 BE (Server Side) 쪽만 먼저 훓어 봤으면 좋겠네요. Frontend 까지 가면 좀 골치가... ㅋㅋ

목적을 찾아서... jiNoos

cnhppy의 이미지

cnhppy의 이미지

??

cnhppy의 이미지

..

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.