자바가 C(or C++?) 보다 8배 느리다?

leonid의 이미지

음 일단 프로젝트는 자바로 하기로 결정했습니다.
무엇보다도 자신에게 익숙한 언어로 프로그래밍을 하는 것이
가장 현명하다고 판단했어요.

제가 어디서 들어보니

자바의 수행 속도가 C(C++이었나)보다 8배가량 느리다고 하는군요.

이 말이 진실인지 헛소리인지 알려주세요.

헛소리였으면 좋겠네요.

익명 사용자의 이미지

둘 다 똑같은 능력이라고 봤을때 C가 절대 적으로 빠릅니다.
java는 class가 메모리에 저장되는 형태나 gc때문에 메모리관리도 최적화하기 힘들고요...
class,struct를 백만게정도 생성하는 테스트코드로 테스트 해보세요..

그런데 업계에서 java가 많이 쓰이는 이유는 '쉽기' 때문입니다.
또한 C는 메모리관리도 프로그래머가 직접 해줘야하기 때문에 잘못되면 성능이 크리티컬하게 다가오죠..

결론은 java나 c가 '잘'짜여졌을 때는 c가 빠를 수 밖에 없습니다.
그러나 java가 c보다 훨씬더 '잘'짜기가 '쉽'습니다.

paser2의 이미지

뭔 댓글이 무서울 정도로 많이 달려서 재밌게 봤네요

원 게시자가 제시한 문제는 이미 1페이지에서 나오더군요

진짜 문제는 타인의 생각을 존중하지 못하는 일부 사람들의 키워질이랑
익명 사용자가 너무 많아서 누가 누군기 모른다는 점인거 같습니다

잠탱이의 이미지

C에 성능튜닝이 내가 좋아하는 갈 길이라고 살아가다가 비지니스급 코드를 보고 C로는 안되겠다고 생각하고 Java로 전향하였습니다.
Java에 성능튜닝이 내가 좋아하는 길로 알고 있습니다.

Sun이 팔팔할때는 Pure Java라는 솔루션이 많이 중요하게 언급이 되었지만 Oracle이 팔팔하니 Pure Java는 아키텍처적인 부분에서 언급이죠.
레이싱 레이서들이 달리기 선수일 필요는 없죠.

멀티쓰레드와 쓰레드풀을 달았습니다. 계산량이 적고 자원소요성이 아니다보니, 기존에 Java보다 성능이 눈꼽만하게 증가하는데 만족해야 했습니다만 그래서 저는 Java를 선호합니다.
쓰레드 클래스와 쓰레드 모니터 클래스가 2개 더 생겼습니다.

package cool;

import java.util.List;

public class Speed_K2 {
static boolean c1 = true, c2 = true;

public static void main(String[] args) {
long start = 0, end = 0;//, elapsed;
try {
Thread.sleep(5000L);
} catch (InterruptedException e) {
}

for (int k = 0; k < 5; k++) {
start = System.currentTimeMillis();
if (end == 0)
end = start;
doo((int) ((end - start) / 1000));
end = System.currentTimeMillis();
System.out.println("Elapsed time:" + ((end - start) / 1000.));
}
}

static public int doo(int in) {
int i;
int count = 5;
int n = 50000000;
int sum = 0;

CalcWorker.speedManager = new ResultCorrector(count);
n = n + in;
List solverThreads = CalcWorker.startThreads(count, n, c1);
for (i = 0; i < count; i++) {
solverThreads.get(i).doCalc(i, c2);
c2 = !c2;//이게 골치. 전역 참조여서 쓰레드 모니터 클래스로 제어가 힘든 변수.
}
CalcWorker.speedManager.waitAll();
return sum;
}
}

package cool;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

public class CalcWorker extends Thread {
public static ResultCorrector speedManager;

private static List threadPool = Collections
. emptyList();

private static final int DO_NOTHING_STATUS = -2;
private static final int DO_WAIT_OR_DIE = -1;
private int workerNum = DO_NOTHING_STATUS;// -2 means first running.
private int differ;
private static int n;
private static boolean c1;
private boolean c2;

private List runningExList = new ArrayList();

private static void initThreadPool(int count) {
CalcWorker.threadPool = new ArrayList(count);
do {
CalcWorker worker = new CalcWorker();
worker.start();
CalcWorker.threadPool.add(worker);
} while (CalcWorker.threadPool.size() < count);
}

@Override
protected void finalize() throws Throwable {
this.destroyThreads();
super.finalize();
}

public synchronized void doCalc(int loverNum, boolean c2) {
this.differ = 0;
this.workerNum = loverNum;
this.c2 = c2;
this.notify();
}

@Override
public void run() {
try {
do {
if (this.workerNum != DO_NOTHING_STATUS) {
this.differ = CalcWorker.sum(this.differ, CalcWorker.n,
CalcWorker.c1, this.c2);
speedManager.summer(this.workerNum, this.differ);
}
this.workerNum = DO_WAIT_OR_DIE;// calcurate ended
synchronized (this) {
this.wait();
}
} while (this.workerNum != DO_WAIT_OR_DIE);
this.join();
} catch (InterruptedException e) {
this.runningExList.add(e);
}
}

private static int sum(int sum, int n, boolean c1, boolean c2) {
for (int j = 0; j < n; j++) {
if (c1 == true) {
if (c2 == true) {
sum++;
} else {
sum--;
}
}
}
return sum;
}

public static List startThreads(int count, int n, boolean c1) {
CalcWorker.n = n;
CalcWorker.c1 = c1;
if (CalcWorker.threadPool.isEmpty())
CalcWorker.initThreadPool(count);
return CalcWorker.threadPool;
}

private void destroyThreads() throws InterruptedException {
for (CalcWorker worker : CalcWorker.threadPool)
worker.doCalc(DO_WAIT_OR_DIE, this.c2);
if (!this.runningExList.isEmpty())
throw this.runningExList.get(0);
}
}

package cool;

public class ResultCorrector {

public static int sum;
private int workerNum;

public ResultCorrector(int count) {
this.workerNum = count;
}

public void waitAll() {
try {
while (this.workerNum > 0) {
synchronized (this) {
this.wait();
}
}
} catch (InterruptedException e) {
}
}

public void summer(int endedWorkerNum, int differ) {
synchronized (this) {
ResultCorrector.sum += differ;
this.workerNum--;
this.notify();
}
}
}

익명 사용자의 이미지

C랑 JAVA랑 항상 논쟁이 치열하군요 ㅋㅋㅋ
제가보기에는 성능상의 초점을 논하는것 보다는 사용상의 초점을 논하는게 맞지 않을까 싶은데요...
하지만 일단은 다른시각에서 보면...
연산속도가 느리다 빠르다보다는 메모리를 많이 잡아먹는다 안잡아먹는다는 결론이 나오지 않나 싶네요 ㅋ

그게 중요한게 아닐까요??

초보입문 개발자의 입장이아니라 스마트폰을 좋아하는 유저로써 시각을 바라봤습니다.

안드로이드 핸드폰들은 기본 스펙이 빵빵합니다.
아이폰은 그래픽성능은 몰라도 램의 성능은 안드로이드 폰의 1/2 or 4/1정도 수준입니다.

하지만 아무리 생각해봐도 구동성능은 아이폰이 훨씬 더 좋은 느낌을 받습니다.

솔직히 이런 판단은 비약일수도 있고 세부적인 os의 구동방식과 모든게 다르지만!
한가지 중요한점은 오브젝트C와 Java의 대립으로 볼수도 있구요,
가볍게 생각해서 핸드폰들의 메모리 스펙 차이만 봐도 느낄수있다고 생각됩니다.

그래서 제 결론은 연산속도가 빠르다 어쩐다 보다는....
메모리를 많이 차지한다로는 답이 나오지 않았나 싶습니다.

그리고 C와 JAVA는 서로 장점이 다른 언어입니다.
축구로 비교하면 왼쪽윙어 오른쪽윙어를 비교하는 수준이 아니라, 같은 공격수더라도 드리블형 공격수와 헤딩을 잘하는 타켓공격수정도의 차이랄까요?

또는 미드필더와 공격수의 비교정도입니다. 같은 축구선수(언어)지만 다른 포지션(장점)을 갖는 두 언어를 비교하는건 풀리지 않는 숙제이며
지금 현재 시점에서는 넌센스가 아닐까 싶습니다.

익명 사용자의 이미지

참 쓸때 없는 것들로 싸우셨습니다 그려.

익명 사용자의 이미지

6년을 끌어오다니... 근성들이 대단하심...

익명 사용자의 이미지

2007년 엔지니어들은 과연 다들 좋은 근무 환경에서, 널널한 시간을 갖고, 갑의 쪼임이 없는, 프로그램의 실행시간이 가장 중요한, 최적화 100%의 프로젝트만 하시는 구만. 이 글들 쓰시는 분들. 코드 한줄 짜면서 깊이 있게 메모리, 실행 시간을 생각하는지. 그렇게 전문가들인지 과연 묻고 싶다. 다들 궤변들만 늘어놓고 있다는 것 밖에 모르겠다.

익명 사용자의 이미지

아는 만큼 보이는 법입니다.
최적화는 컴퓨팅 발전의 밑거름입니다.

조금 더 빠른 것을 가능하게 하고자 하는 노력을 우습게 보지 마시죠

mirheekl의 이미지

한 줄의 코드 차이가 수십억원 이상의 돈 차이를 만들어내는 영역들이 있습니다. 그런 곳들이 아직 많이 있기 때문에 C언어가 여전히 일정수준의 점유율을 유지하고 있는 것입니다.

--

익명 사용자의 이미지

일반적으로 같은 역할을 수행하는 코드라면, C가 빠릅니다. 누구도 반론 못합니다.
하지만 왜 이렇게 빠른 C 랭귀지가 있음에도 불구하고 계속 새로운 랭귀지가 나올까요?
당연히 그 이유는 모두가 아시겠지만, 보다 편리하게 개발할 수 있는, 기계 입장이 아닌 사람 입장의 랭귀지로 진화하고 있습니다.
(물론 스칼라 같이 퍼포먼스까지 보장하는 것도 있지만요)
이것과 더불어 'Time to market'이 되지 않으면 기업이 생존할 수 없습니다.
상황이 이러하니 당연히 분야마다, 그리고, 요구사항마다 다른 랭귀지로 구현이 되겠죠.
어떤 랭귀지로든 불가능은 없으니까요. 랭귀지는 거들 뿐..

익명 사용자의 이미지

위 글을 게시한 사람입니다.

위처럼 기술한 전제는,
Java도 진화해오면서 속도가 많이 좋아졌고
이는 한계효용의 포화 곡선 접점에 이르렀다? 정도로 생각하고 읽어주시면 감사하겠습니다.

예를 들자면 웹 페이지 로딩의 경우
사용자가 빠르다고 체감하는 인체 반응 속도 임계점이 200ms 안쪽이라고 합니다.
C로 구현해서 100ms 응답 속도가 나오고
Java로 구현해서 110ms 응답 속도가 나온다고 해서
그 누구도 C를 택할 사람은 없습니다.

이런 상황이라면 당연히 다른 요인들로 랭귀지를 선택하겠지요.

익명 사용자의 이미지

성지순례 하고 갑니다

익명 사용자의 이미지

이번엔 샤아가 왜 10배 빠른지 토론을 해보도록 합니다.

익명 사용자의 이미지

이제부터는 퍼포먼스비교는 의미없습니다.
하드스펙이 너무좋아졌습니다.

익명 사용자의 이미지

왜 Apach 같은 웹서버는 C로 만드는 걸까요??

익명 사용자의 이미지

C가 아직도 대세고 개발자들에게 익숙한데다가 속도가 빨라서 그렇죠.
웹서버를 자바로 만들어야할 특별한 이유가 있지 않은 이상 C언어로 만들겠죠.

* 그 특별한 이유에는 C언어에 익숙하지 않다는 것도 포함됩니다.
* 자바보다 C가 더 많이 사용되니 C가 대세임은 부정할 수 없는 사실입니다.

일부 자바 예찬론자들이 무리하게 자바가 빠르다고 주장하니 이렇게 ... 스레드가 산으로 가죠.ㅎㅎ

그리고 거의 대부분의 서버들이 C로 만들어져 있습니다. 궁금하시면 리눅스 배포판에서 jre 필요로 하는 서버가 있는지 조사해보면 알터.

익명 사용자의 이미지

C++03때나 자바가 우세했지
C++11, C++14가 나온 지금은 C++이 더 편리한 듯합니다.

shint의 이미지


CUDA 가 제일 빠릅니다. ㅡ_ㅡ;;

CUDA > Assembly > C > Java 속도

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

DarkSide의 이미지

CUDA는 C로 구현합니다.
CUDA로 구현할 수 있는 시스템이 빠른 것이겠죠.

익명 사용자의 이미지


2006/09/01 -> 2015/09/11 (만9년10일 내년 요맘때 누군가 10년기원 글이라도 올려줄지..)

소셜과 스마트가 세상을 뒤덮는 지난 10 여년 동안에도 개발자들 형편은 낳아진게 없구려..

훌륭한 개발자를 꿈구며, 부끄럽지 않은 솔루션 만들어 보겠다며 밤을 지새우던 개발자가

서릿발 내린 머리로 지금은 단어조차 잊혀저가는 IT붐어 1세대 동료들과 함께 오늘도..

indra의 이미지

거의 10년 전 글이 어느 분께서 댓글 다셔서 메인으로 끌올 당했네요.
예전에 읽어 본 기억은 있지만 중간 중간 올려주신 새로운 댓글들도 많이 읽어보고..
지금은 개발로 먹고 사는 처지는 아니지만.. 돌이켜보면 많은 생각을 하게 합니다..
10년전쯤의 생각과 지금의 생각을 비교해보면 역시 언어의 우위나 일장일단을 캐내어 blame성 댓글을 유발하는 소모전에 치중하기 보다는..
전체적으로 프로젝트를 살펴 적절한 언어를 선택하는 것을 다 같이 토론해 보는 것이 더 발전적이지 않을까 하네요..
물론 위의 어느 분께서 말씀하셨듯이 언어의 선택과 퍼포먼스가 집약적으로 필요한 분야가 있기는 하지만.. 모두가 core 개발자는 아닐테니까요..
또한 그런 분야에서 일하시는 분들의 노고도 깎아내릴 생각은 전혀 없습니다.. 오히려 존경스럽지요.. 그런 분들의 노고가 발판이 되어 지금이 있을테니까요..
예전 netbsd 메일링리스트에서 P6코어의 memcpy()의 최적화를 놓고 설전을 벌이던 스레드가 문득 생각나는 하루입니다.
엔지니어로서, 개발자로서, 기획자로서.. 또는.. 더 나아가 어떤 회사의 오너로서.. 어떤 시야를 가져야 하는지 깊게 생각해봐야 할 것 같습니다..

익명 사용자의 이미지

자바자체가가 C언어로 만든 언어인데 C보단 빠를 수 없겠죠. 별도의 가상머신 띄우고, 거기서 코드 변환해 읽어들이는거 제외해도
자바가 클래스 바탕 언어라서 함수 하나 호출해도 객체 주소를 먼저 따고 거기서 멤버함수 주소 찾아서 호출하는 단계를 거치니
바로 함수주소 찾아서 호출하는 c보다는 이론상으로도 느릴 수 밖에 없음.
그리고 언어 뭐가 좋다 하는건 진짜 멍청한 순위비교임. 둘다 하는게 좋고요. 자바가 휘어잡는 체계에선 자바를 배워야 살아남을 수 있죠.
가령 정부 웹은 자바바탕 jsp로 돌아가는데 자바언어를 모르면 채용도 안되겠죠.

그리고 자바 이론은 그냥 객체지향 이론이에요.
C, C++ 배우고 자바 배우면 좋습니다. 이론 부분은 식은죽 먹기로 배울 수 있습니다.
C++과 95프로 유사해요. 자료형이 조금 다르고 일부 키워드가 다른거 제외하고 완전 붕어빵임. 물론 자바에 맞는 api 익히는 시간이 걸리겠지만요.
자바는 포인터 부분을 없애버려서 조금 답답한 느낌이 있습니다. -> 이 부호가 사라짐. .만 써요.
그리고 강사분들도 메모리 주소, 포인터 이런 개념을 안쓰고 설명하니 왠지 설명이 오히려 더 장황해진 느낌이 들기도 함.

진짜 희한한건 자바스크립트 이론입니다. 이건 기존 C++, 자바와 다른 완전 쇼킹한 언어임. ㅋㅋ 특히 함수가 완전히 굉장히 쇼킹해짐.

익명_사용자의 이미지

> 자바자체가가 C언어로 만든 언어인데 C보단 빠를 수 없겠죠.
자바라는 언어는 그냥 스펙입니다. 구현물이 아닙니다. 자바언어를 구현한 java vm들중에 가장 널리쓰이는 오라클 java vm(hotspot)은 C++로 짜여져있습니다.

> 바로 함수주소 찾아서 호출하는 c보다는 이론상으로도 느릴 수 밖에 없음.
항상 꼭 그런것만은 아닙니다. 이것은 c++도 마찬가지인데, virtual과 dynamic typing등을 많이 쓰면 컴파일러들이 함수 호출주소를 컴파일타임에 쉽게 예측하지 못하기에,
branch prediction이 쉽지않아 CPU cycle이 낭비될수도 있습니다. 하지만 이것들도 인텔이나 AMD같은 하드웨어 제조사들이
지속적으로 기능을 추가해가서 개선되가고 있습니다. 가령 https://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_indirect_jumps

다시말하자면, 함수주소를 동적으로 찾는것은 CPU레벨에서의 최적화에 단점
최적화를 좀 어렵게 만드는 부분이 있기에 성능저하가 나타날수 있는것이지, 마치 함수호출할때마다 정말 동적으로 맵같은 자료구조에서 함수주소를 찾고 그런것은 아닙니다.
그리고 정말 예측하기 어려운 virtual이 아닌이상, 컴파일러가 최대한 함수주소를 정적으로 바인딩합니다.
그리고 이것 마저도 하드웨어 제조사들이 점프 히스토리나 테그같은것을 cpu cache에 추가함으로서 점점 차이가 적어지고있습니다.
자바에서 성능저하가 많이 일어나는 부분중의 하나는 가비지 컬렉션입니다.

그리고 여태까지는 정적컴파일러들이 동적컴파일러들보다 더 성능이 좋은 실행파일들을 생성하고 있습니다만, 그 격차도 점점 줄어들고 있다고 봅니다.
이것은 꼭 단순히 성능비교만 할수 있는것은 아닌데, JIT는 정적컴파일링이 제공하지 못하는 부분들을 제공할수 있기때문입니다.

여기부터는 서명입니다.
"저는 인터넷에서 숨어서 정확한 의견을 피력하는 자들과 말을 섞습니다."

가끔은의 이미지

자바나 C# 같은 경우 실시간응답이 중요한 온라인프로그램인데 가끔씩 되도 않게 오래 걸리는 경우를 볼 수 있습니다.
아마도 가비지 콜렉션 때문이 아닌가 하는 생각이 듭니다(느낌이라 아닐수도 있고)
실시간응답이 중요한 온라인성 프로그램은 언어 선택 시 가능한 C 로 하는것이 좋다는 생각입니다.

OWL의 이미지

요즘은 속도는 컴퓨터 다 받쳐줘서 어떤 기능을 구현할때 어떤언어로 짜면 더 편할지가 더 중요한거 아닌가?? 싶네요.

lalupo20의 이미지

씨로 할 수 있는 최대한, 자바로 할 수 있는 최대한을 해야하지 않나 싶네요

문재앙의 이미지

단순 코드는 크게 차이가 없지만 메모리를 많이 사용하거나 인터페이스를 접근하거나 데이터 베이스 접근시 부터는 속도가 눈에 띠게 느려지기 시작합니다
c#도 마찬가지 입니다 게다가 vc보다 델파이나 c++builder가 2~15배 빠릅니다
더 빠른 툴이 있죠

페이지

댓글 달기

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.