Extreme Programming?

geekforum의 이미지

세상 모든 일이 유행이 있듯이 프로그래밍에도 일종의 유행이 있지요? Structured Programming에서 Object Oriented Programming, 그리고 최근에는 Extreme Programming(XP)이란 말이 주위에서 종종 들립니다.

프로그래밍 방법론이란게 결국은 어떻게 하면 좀더 효율적으로 품질좋은 코드를 빠르게 생산할 수 있는가에 관한 고민일진대 간단한 문제는 아니죠? 프로그래머들이라면 아마 어떤 식으로든 이런 고민 한두번쯤은 해보셨을 거라 생각됩니다.

혹시 이 Extreme Programming 방법론이란 무엇인지, 어떤 장단점이 있는지.... 이를 실제로 개발시 적용시켜 보셨다면 귀중한 경험담도 한번 들어 봤으면 좋겠네요.

댓글

익명 사용자의 이미지

이글들을 읽다가 한가지 추가하고 싶은것이 생겼네요.
XP에서 가장 큰 두 줄기를 꼽자면 Pair Programming과
Test First Programming을 들 수 있을 겁니다.

아직 Pair Programming은 해 본 경험은 없지만 TestFirst
Programming은 파이썬과 자바로 해본 적이 있습니다.

무엇보다도 TestFirst Programming의 매력이라면 적절한 테스트 코드를 작성한 후에 그것들을 통과시킬 수 있는 실제 코드를 작성하면서 시간을 절약할 수 있다는 점과
또한 프로그램의 업데이트등에 두려움을 느끼지 않아서 좋다는 점등 일 것입니다.

하지만 전 또하나 강조하고 싶네요.

바로 "재미"라는 측면이죠.
TestFirst 프로그램은 정말 재미있습니다.
도저히 불가능해 보이는 것들을 쉽고 빠르게 해낼 수 있지요.

그리고 파이썬과 함께라면 더욱 재미있게 할 수 있지요.

LikeJAzz_의 이미지

약 한달전쯤에 제 홈페이지에 XP 에 관해서 간략하게 정리해둔적이 있습니다 .

초급문서이므로 XP 가 무언지 궁금하신분만 가볍게 읽어주시면 고맙겠습니다 ^^;

좀더 보충해서 2편을 조망간 올릴예정에 있구요 .

일단 한번 들러서 봐주세요 ^^; http://www.likejazz.com 입니다 .

정규현의 이미지

"무명"님께 감사드립니다.
아주 오랜만에 영양가 있고, 유익하며,
불필요한 논쟁 ( 서로의 자존심에 기반한 )이
아닌 생산적인 토론을 한것 같습니다.

디자인방법론이라는 새로운 용어에 대한
이해도 생겼네요.
다시한번 감사드립니다.

익명 사용자의 이미지

두분의 토론 내용에 감사드립니다.
새로운 프로그래밍 방법론 이라고 해서 이거 보고.
XP내용좀 보고.

두분의 토론 내용을 좀 보니. 개념이 잘 잡히네요.
XP소규모에 적합하다고 하지만. 매우 유용할 거 같네요
회사는 몰라도 학교나 연구실 같은데서 적용하면 좋을 것 같다는 생각이 많이 들어요.

암튼 감사.

정규현의 이미지

메소드-1은 한국전산원에서 의뢰해서 아더 앤더슨에서 개발한 공공 프로젝트 공식 개발방법론입니다.
공공프로젝트 수행시 의무적으로 사용해야 하는걸로
알고 있습니다. ( 혹시 공공 프로젝트 하시면서
메소드-1 말고 다른거 쓰신 경험 있스시면 제게
알려주세여~~~)

그리고 CBD가 반드시 XP하고 연관있는거라고
생각되지는 않는데요. XP자체에는 CBD에 대한
언급이 없을뿐더러, 반드시 CBD와 XP가 연관되야
하는 명확한 이유도 생각이 안나는데요...

혹시 그 관계를 설명해주시면...

익명 사용자의 이미지

"Method-1" 은 원래 아서앤더슨이 갖고 있던

방법론이고, 한국 전산원에서 아서앤더슨에 의뢰해 이를 기반으로

만든 방법론이 "개발 방법론-1"이라고 알고 있습니다.

흔히 개발방법론-1 을 메쏘드원 이라고 부르기도 하던데...

제 기억이 정확하다면...

이 둘 사이에 약간의 차이가 있는 것으로 기억합니다.

저도 개발방법론-1 적용한 공공 프로젝트를 몇 건 수행했었는데...

제 생각에는 너무 많은 산출물(문서)를 요구하고 있다는 것이 단점인 것

같습니다.

솔직히 유지 보수를 위해서는 산출물이 필수적이지만..

제대로 산출물 관리하는 기관도 보기 힘들고, 유지 보수에 사용하지도

않고 있는 것이 현실인 것 같습니다.--- 바꿔 말하면 세금 낭비죠.

개발방법론-1에 지정된 내용대로 약식 문서를 만드는데

DFD 그리는 데에만 몇 주가 걸렸던 기억이 나네요.

소화하지 못하는 방법론은 경우에 따라서는 짐만 될 것 같네요.

익명 사용자의 이미지

제 생각에도.. XP와 CBD는 별 관계가 없는것 같은데요.
더구나 CBD는 디자인 방법론이죠.
어떻게 디자인 할것인가에 대한것과 어떻게 진행시켜 나갈것인가는
다른 문제죠..

메소드-1은 여기서 처음듣는데..
글 내용으로 보아..아마도.. 한국실정에 맞는 프로세스를 개발하려는
노력의 일환으로 나온것인듯 싶군요.
여러가지 이름들이 붙여진 프로세스들이 있지만..
그런것들은 쓰기 나름입니다. 혼용해서 쓸수도 있고..
자기 나름대로 고쳐 쓸수도 있겠죠..
어떤식으로든..사용하는 집단의 CMM 레벨을 높이는 방향으로..
나가는것이 정석입니다.

정규현의 이미지

덧붙여 메소드-1은 한국전산원에서 발주하는 모든 프로젝트에서 의무적으로
사용해야 하는 방법론입니다. 나온지도 꽤 됐고, 한국통신 ICIS나 최근의
인천신공항 프로젝트같은 대규모 공공 플젝은 모드 메소드-1을 적용하고 있습니다.

정규현의 이미지

CBD가 디자인방법론이라는것에 대해서는 좀 이의가 있습니다.
( 정확히 말해서 디자인방법론은 무엇이지요? )
CBD자체에는 컴포넌트를 어떤방식으로 디자인해라같은 것에 대해서는 나와있지
않습니다.

광주은행이나, 한미은행같은 금융권에 적용된 CBD를 보면 사실상 RUP와
거의 유사하다고 생각이 됩니다. ( 프로세스 하나하나에 전부다 번호가
매겨져 있습니다. 100, 110, 111 이런식으로 )

CBD에서 컴포넌트의 명확한 정의라거나, 혹은 컴포넌트 디자인방법에 대해서는
끌쎄요... 보지 못한것 같은데...

디자인방법론이라고 하면, 제가 이해하기에는 GoF 디자인패턴이나, J2EE 디자인패턴을
말씀하시는건 아닌지...

디자인패턴 디스크립션 랭귀지는 있긴 하지만, 디자인방법론이라하면 잘 이해가
안됩니다.

익명 사용자의 이미지

디자인 패턴을 얘기한것이 아닙니다.
제가 언급했던 디자인 방법론이라는것은..
디자인이 바뀔 수 있는 유무형의 전략적 결정을 모두 포괄하고 있기때문에..
디자인 패턴, CBD같은 개념이 모두 그 범주안에 포함이 됩니다.
OO뿐아니라 가령, Structured design에서도.. 해쉬테이블을 사용할것인지..
function set을 만들어 포인터 테이블에 넣을것인지.. 이러한 결정사항들이
디자인 방법론에 해당됩니다.. 기계의 퍼포먼스를 우선시 할것이냐..
메모리를 적게 차지하게 할것이냐.. 사람이 읽기 쉽게 할것이냐..등등에
따라 디자인이 바뀌게 될텐데.. 그러한 결정사항 또한 디자인 방법론에
포함이 됩니다..
디자인 방법론이 superset이고, CBD가 subset이라고 말씀드리면.. 이해를
하시겠는지요?

그리고 CBD는 OO에 기반을 두고 있는데..(이에 대해선 논란이 많죠..
전통적인 OO기법에 회의를 느껴 새롭게 등장한것이 CBD였기 때문인데
어쨋든 CBD가 OO인가 아닌가 하는 문제는 논외로 치더라도.. 그것이
OO에서 탄생한것만큼은 사실입니다..)
OO에 잘 들어맞는 공인된 프로세스로 RUP가 있기때문에..
당연히 CBD를 이끌어가는 프로세스로 RUP가 채택이 되는경우가 많은것입니다.
프로세스는 쓰기 나름입니다.
예를들어 CBD 를 쓰면서도 프로세스로 전통적인 Waterfall모델을 사용할수도 있습니다.
(어설픈 RUP보다는 확실한 Waterfall모델이 훨씬 낫습니다..그래서 그런 프로세스를
적용하는 기업내 팀조직의 자질을 거론했던 것이고요..)
어느 프로세스를 선택하느냐의 문제는 된다/안된다의 문제가 아니라
적합하다/부적합하다의 문제일뿐입니다.

CBD얘기가 나오면.. 바늘에 실 따라 가듯이 RUP를 레퍼런스하기때문에..
마치 CBD가 RUP인가..아니면 모종의 관계가 있을까 하는 생각을 가지는것 같은데..
그것은 위에서 말했듯이 CBD에는 RUP가 '적합'하기 때문입니다..

정규현의 이미지

CBD가 RUP와 유사하다고 말한 의도는 일단 아니었습니다.
하지만 님의 말씀을 듣고 보니, 맞다는 생각이 드는군요.
( CBD의 프로세스로 RUP말고도 Catalysis같은 XP비스끄무리한
방법론채택의 경우도 본적이 있습니다. )

그러면 디자인방법론이라고 하면, 공식적인 용어인지
아니면, 님 고유의 용어인지 말씀해주시면 감사하겠습니다.
( 확실히 디자인패턴과 같은 것과는 연관이 없는것 같습니다. )

익명 사용자의 이미지

제가 만들어낸 말은 아니고.. 어느책에 나와 있던 말입니다.
죄송합니다만..정확한 출처는 기억이 나질 않는군요.
아마도 공식 용어로 정착이 되지 않은 단어라 혼란이 있었던듯 싶습니다만..
오해는 풀린것 같군요.

익명 사용자의 이미지

component-based programming은 왜 빼먹죠 --;

리눅스에서 컴퍼넌트만 생각하면...
거의 전무하다는 아쉬움이 들던데...
대화에서 조차 찾기 어렵군요 --;

익명 사용자의 이미지

수많은 방법론중..이례적으로 XP는 프로그래밍 그 자체를
상당히 중시하고 있습니다.
반복과 피드백으로 설계의 정형성이 어느정도 보장된다는
철학이죠.
그래서 해커성향을 지닌 사람들에게는 업무진행시 가장
적합한 방법론이라고도 볼 수 있습니다.
물론.. 거대한 프로젝트에서는 XP보다는 RUP가 더 적합할 수
있겠죠..
어느것이든 쓰는 사람과 팀의 자질 나름이겠지만..

익명 사용자의 이미지

대개의..(저의 생각으로는 전부.) 한명의
실력 있는 프로그래머가 있고 다른 좀 공부가
필요한(저 같은 경우이겠죠?^.^) 프로그래머들이
있을때 효율이 좋습니다.

몇몇 팀장님들이 이 처방을 쓰고 약발이 잘 들어
좋아했더랩니다.

하지만 전 xp에서 test-first programming만을

개인적으로 사용하는데요... (즉 테스트 코드부터

발생합니다....)

저의 경우에는 RUP의 사이클을 좀 축소 해서 설계-구현을 왔다 갔다 쓰는...극단적으로 쓰는 정도군요...

하지만 모든 것이 그러하듯이 직접 몸으로 느끼지
않는 한 알수 없습니다..즉 침묵할지어다..(하느님
죄송합니다.T_T)

저도 kent beck사마께 신탁을 받고 싶은 어린 양입니다..ㅋㅋㅋ;

근데.. 메소드-1은 어떤 방법인가요? url은요?

-맹수.dimhazy@hitel.net

python? 글쎄요..아직 python으로 만줄이 넘지 못해
말씀 드리기 모 합니다만... 닷넷에서는 C#를 자바에서 자바가 가장 쓸만하더군요..T_T

이제 언어의 세세한 부분에서 프로그래밍을 논할때는
지나지 않았나요?

익명 사용자의 이미지

저도 XP 에 관심이 많은데..

책이 여러권이더군요

XP : installed 가 먼저인가요?

뭐 부터 읽어야 할지..

서지원_의 이미지

extreme programming explained(by Kent Beck)를 보세요.

조기태의 이미지

XP Instilled 아닐까요?
ㅡ.ㅡ

june8th_의 이미지

저도 어디선가 주워듣고선, XP책을 하나 사서 읽고 있습니다.
하는 일의 성격상, 소규모 프로젝트는 하게 될 거 같지 않고,
pair programming이라는 게 재밌을 거 같아, 함 읽어보고 해볼까 하는데,
같이 할 사람이 없네요.. -_-;

요즘은 왜 이리 재미가 없는지 쯥.

익명 사용자의 이미지

맞습니다.

정규현의 이미지

아래 추가
쓰고나서 보니 좀더 생각이 나서...

담당 클라이언트가 개발팀과 밀착해있어야 합니다.
정기적으로 요구사항 던져주고, 회의나 하는 그런식으로 해서는 절대로 프로젝트 제대로 진행안됩니다.

이를 위해서 개발요구사항을 반드시 클라이언트가
이해하고 있어야 합니다. 절대로 개발자들이
클라이언트와 대화할때 이해하지 못할 기술용어를
사용해서는 안됩니다. 개발자의 눈높이는 반드시
클라이언트와 맞아야 합니다.

프로젝트 킥오프시에 대충 전체적으로 해야할일들에
대해 ( 기술적인 테스크가 아니라 비즈니스 적인
테스크 ) 개략적으로 리스트를 작성합니다.
각 테스크는 대략 최대 3일내의 시간에 완성될수
있어야 합니다. ( 개발/단위테스트완료까지 )

이 묶음을 가지고 전체개발기간을 구성하는
몇개의 이터레이션으로 분배합니다. ( 이터레이션
역시 너무 길면 안됩니다. 길어야 2주정도? )

그리구서 각 테스크별로 담당할 개발자를 선정하고
개발을 시작하죠...

여기서 중요한 사항은
중간에 개발자 교체는 가능한한 발생하지 말아야 한다는 겁니다. 가능한한 초기멤버로 끝까지 가는것이
최상이며, 막판에 시간없다고 멤버를 추가 투입하는
"미친짓"은 절대 해서는 안됩니다.

상당수의 웹에이전시나 여러 대형SI업체에서
그런짓을 하곤 하는데, 프로젝막판에 개발자추가
투입은 프로젝트기간을 오히려 더 연장시키고
코드를 스파게티화시키며, 팀웍을 엉망으로
만드는 부작용만 초래한다는 사실을 명심해야 합니다.

익명 사용자의 이미지

클라이언트의 눈높이.. 가슴에 와닿는군요.. -_-;;;

정규현의 이미지

잘 알지는 못하지만, 이전에 프로젝트에 적용해 본 경험으로 말씀드립니다.

RUP나 메소드-1, 이노베이터처럼 엄밀한 체계에 따른 개발방법론은 아닙니다. 일반적으로 프로젝트기간 3개월안쪽, 투입인력이 10명이 안되는 소형프로젝트에
적합한 방법론입니다.

XP Installed같은 XP 관련 서적에 보면 여러가지
사항들이 나오는데, 전 다음과 같은 사항들이
핵심적이라고 봅니다.

1. 개발자 각각이 할수 있는 일의 양이 처음부터
정해지는게 아니라, 각 스테이지가 지날때마다
결과를 보고 산정합니다. ( 따라서 반드시
여러개의 스테이지로 구성되야 겠죠? )
첫 스테이지 출발시점에는 일단 각각의 기본
능력치 ( 개발자 A : 10본/day, 개발자 B :
7본/day 이런식으로... )로 시작하고
첫 스테이지가 종료되면 각자의 확실한 능력치
가 나옵니다. 이걸 기반으로 개발을 진행하는거죠.

10년경력자라도 최신 프로그래밍 기술에 따른
것이면 3년차보다도 생산성이 떨어질수 있습니다.

따라서 현재같이 그사람의 년차로 그 사람의
생산성을 가늠하는 것이 아니라, 실제 개발
생산성으로 하게되기 때문에, 훨씬 더 프로젝트
에 대한 예측이 정확해지게 됩니다.

2. Pair Programming은 한국환경에서 비현실적인
관계로 제외하겠습니다. XP의 핵심요소가운데
하나라고 생각하긴 하지만, 실제 필드에서는
거의 불가능한 일입니다...
( 수치적으로도 생산성 20~30% 향상을 위해서
인건비를 2배를 들여야 한다는 말을 클라이언트
에게 설득시키기가 대단히 어렵습니다. )

3. 칼렌다 데이가 아니라 워크 데이로 계산하는것
정말 별거 아니지만, 실제 프로젝트 진행시에
대부분의 PM들이 간과하는 요소입니다.
개발자도 사람이고, 적정하게 쉬어주어야
개발이 제대로 진행될수 있습니다.
휴일없이 하루 열몇시간 개발시키셔 뽑아야
되는 프로젝트라면 그건 Death March Project
입니다.
( 비즈니스상의 요구로 불가피한 경우도 없지
않긴 한데, 거의 대부분의 경우 경험없는
기획자가 일정을 잘못 산정한 데서 나옵니다.
거기에 더해서 경직된 의사결정구조도
한몫합니다. 처음 도입하는 기술로
프로젝을 진행하면 당연히 기간예측이 애매해
지는게 당연합니다. 그런데 기업에서는 그걸
처음부터 정확하게 기간 예측을 하라고
요구하는 코메디를 합니다. 나중가면
서로 곤란해지죠... )

4. 코드 작성시부터 테스트를 염두에 두고
코드를 작성합니다. 자바의 경우 JUnit같은 툴을
이용해서 코드작성시부터 테스트코드를 껴서
만듭니다. 에러는 초기단계에 잡을수록 좋기땜시..

핵심요소가 10여가지 정도 되는데, 제가 공력이
부족해서 인지, 실 프로젝트에서는 이정도가
핵심이었다고 봅니다.

참고로 XP는 세밀한 도큐먼트 같은것에 대한
언급은 없습니다. ( 제가 이해하는한 )
따라서 대형프로젝트에 무모하게 도입하려는
만용은 부리지 마시기 바랍니다.

익명 사용자의 이미지

일단 기간이 3개월이라는 제한은 없습니다. 그게 적당한 기간이라는 것도 없구요..
XP를 사용한 성공적인 예로 알려진 Crysler Comprehensive Compensation(C3) System도 속도 최적화에만 1개월이 넘게 걸렸습니다.

pair programming의 양으로의 생산성은 숙달되었을 때 각각 프로그래밍 할 때보다 80~90% 정도로 알려져 있습니다. 대신 품질이 20% 정도 향상되어(acceptance test 통과 비율) 그것으로 원래와 큰 차이가 없게 됩니다.

물론.. 돈이 급해서 문제가 좀 있더라도 미리 받고 나중에 유지보수라고 계속 고치는 개발사나 빠른 시일안에 실적을 올리겠다는 고객사들의 한국식 행태로는 적용되기 어렵겠죠.. 고객도 품질에 대한 것을 기간보다 더 중요하게 생각하고 개발하는 쪽도 그렇게 생각해야 pair programming을 할 수 있다고 생각됩니다.

pair programming을 하면 프로그래머를 1년이면 전원 교체가 가능하다고 합니다. 조금씩 조금씩 인원이 추가되는 것을 수용하기가 쉽습니다. 그래도 원래 있던 프로그래머보다 많은 인원을 한꺼번에 투입하면 대책이 없겠죠.. ^^

문서의 사용 목적은 정보의 전달과 나중에 프로그램의 수정을 하기 위한 것입니다. XP에서는 정보의 전달은 pair programming을 통해서 하고.. 수정은 test code와 refactoring을 통해 깨끗하고 이해하기 쉽고 의도가 명확하게 드러난 source code를 통해 이해를 할 수 있기 때문에 부가적인 문서가 많이 필요 없습니다. 걸레같은 소스 코드에 문서를 던져준들 나중에 처음 보는 사람이 무슨 수로 수정을 할 수 있겠습니까..
문서 작성은 이해하는데 도움이 많이 되는 경우에만 작성하라고 권장하고 있습니다.

대형 프로젝트에는 문서를 통한 정보의 전달이 반드시 필요하기 때문에 XP를 적용하기 어렵습니다. 적은 인원으로는 pair programming을 통해서 할 수 있지만 많은 인원은 문서가 아니면 전달하기가 너무 어려우니까요..

익명 사용자의 이미지

요즘 성인물계도 XP...

eXtreme hard Porno

익명 사용자의 이미지

Structured Programming, Object Oriented Programming하고

Extreme Programming하고는 좀 다른 종류 아닌가요? ^^

백일몽의 이미지

프로그램 개발론 아닌가여??
마소에서 잠깐 읽어 본것도 같은데

10명 이내의 소규모 팀에서 효율적인 개발 방법이라고 읽은 기억이 납니다만...

익명 사용자의 이미지

에공 어쩌다 처음인지..
XP만 봐도 두드러기..
XP가 싫다는말은 아니구.. 요즘 하두 떠들어서..
방법론에도 XP가 나왔군요..
무척 궁금합니다..

궁극,최고,극도...의 의미를 가지는 말인데..

익명 사용자의 이미지

까막_의 이미지

XP.. 윈도보다 방법론이 먼저나왔지요.

쉽게 말하면. 있는데로 다 쪼개놓고 하나하나 만들어 나가는 방법이라고 볼 수 있습니다.
그걸 하나씩 합쳐나가서 전체적인 프로그램을 완성시키는 거죠.

Python에 적용시키기 좋다. 라는 말이 있더군요.

허허... 공부해볼만한 주제인듯.

Let's be engineers!

익명 사용자의 이미지

음.. 디바이드 앤 퀀커(-_-;) 방식 인가요...

익명 사용자의 이미지

아..
그렇군요.. 감사..

제 경우는 Python보담.. 옜적 Z-80으로 했던 기계어(내지 어셈블리)가 퍼뜩 떠오르는군요.

느낌상.. Top-Down방식의 개발과 상반되는 Bottom-Up방식의 개발방법론 같은데 맞는지요?

...

역시 모르는게 더 많은지라.. 에공..
언제 하산할꼬~~

댓글 달기

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