개발 과정에서 문서의 유효성 유지

나빌레라의 이미지

프로젝트 개발 과정에서 문서화는 다른 설명을 하지 않아도 개발자라면 누구나 인정할 정도로 매우 중요하다. UML을 비롯한 많은 모델링 언어들과 doxygen이나 javadoc 같은 자동 문서화 툴들이 있어 개발자의 문서화 작업을 도와준다. 문서화에 이용되는 많은 편하고 좋은 툴들이 있고 문서화의 중요성을 인정하지 않는 개발자가 거의 없음에도 대부분의 개발자들은 문서화 작업을 좋아하지 않는다. 그 이유에는 여러 가지가 있겠지만 나는 가장 큰 이유를 문서화 작업은 프로그래밍 작업이 다 끝난 다음에 몰아서 하기 때문이라고 본다. 보통 프로그래밍 작업이 끝나면 할일이 다 끝났다는 생각이 드는데 아직도 문서화라는 작업을 해야 하니 일에 의욕이 생기지 않는 것이다. 해결 방안이라면 아직 의욕이 남아있는 프로그래밍 과정 중간에 수시로 문서화를 하게하는 방법이 있을 것이다.

프로그램의 설계 작업 역시 중요한 문서화 작업이다. 물론 최초 문서화 작업 없이 머릿속에 작성해야 할 프로그램의 구조를 떠올리고 한 번에 코딩해 내는 천재들도 있다. 하지만 최소한 나는 그런 천재가 아니다. 오히려 머리가 아주 나쁜 편이기 때문에 열 몇 줄의 코드를 작성하더라도 그 전에 최소한 순서도 정도는 그리고 나야 제대로 된 프로그램을 작성할 수 있다. 그리고 그 보다 더 큰 규모의 프로그램을 작성해야 한다면 함수 관계도 혹은 UML로 클래스 다이어그램 정도는 그려놔야 안정적인 프로그래밍 작업을 할 수 있다. 여기 까지는 별 문제 없다. 오히려 모범적이라고 해야 할까나?

문제는 그 이후에 생긴다. 언제나 말하듯이 나는 천재가 아니다. 그러기 때문에 내가 최초 설계한 프로그램의 로직 구조는 100%의 확률로 수정되어야 한다. 물론 클래스 관계도 역시 언제나 수정된다. 그 수정 사항이 작은 범위에서 적은 빈도로 발생한다면 별 문제는 없을 것이다. 하지만 어떤 경우에는 너무 자주 그리고 매우 광범위하게 생기기도 한다. 또한 그런 경우에는 언제나 디버깅 혹은 테스트에 온 신경이 쏠려 있다. 그것도 아주 날카롭게. 그래서 상대적으로 덜 중요한(!) 설계 문서의 수정 따위는 뒷전으로 밀린다. '일단 코딩부터 마무리 하고 수정하자. 지금 수정하면 수정한지 얼마 지나지도 않아 또 수정한다.'라는 생각이 머릿속을 지배한다. 그 순간부터 내가 최초에 설계했던 문서는 실제 프로그램 소스코드와 일치하지 않게 된다. 문서의 유효성을 상실하게 되는 것이다.

위와 같은 일이 하루에 한 번 정도만 생긴다면 문서는 힘겹게라도 유효성을 유지(소스 코드의 내용과 일치)할 것이다. 하지만 실제 저런 일은 하루에 한 번만 일어나주지 않는다. 현실 세계는 우리가 기대하는 것만큼 아름답지 못하다. 하루에 몇 번씩 전체 소스 코드 여기저기에 수정이 가해지고 나면 이제는 문서를 수정하려고 해도 수정할 내용이 너무 많아져서 점점 문서를 수정하는데 아까운 시간을 점점 많이 투입하게 된다. 하루에 사용할 수 있는 시간은 한정되어 있고 개발자는 그 시간을 최대한 프로그래밍과 테스트에 사용하고 싶어 한다. 당장 눈에 보이는 결과에 영향을 미치지 않는 문서화는 최대한 짧게 끝내고 싶다. '에이 이렇게 된 김에 문서화는 나중에 몰아서 하지 뭐!'

프로그래밍 작업이 어느 정도 마무리 되어서 이제 윗분들(!!!)에게 개발 내용을 보고해야 하는 시점이 다가왔다. 윗분들은 소스코드를 보지 않는다. 결과와 문서를 볼 뿐이다. 문서화는 누가 하는가? 전문 테크니컬 라이터? 아니다. 개발자가 한다. 왜 개발자가 설계도 하고 프로그래밍도 하고 문서화도 해야 하는지는 잘 모르겠지만 아무튼 개발자에게 하라고 시킨다. 해야 한다. 개발자는 자기 할일이 다 끝난 것 같은데 문서화라는 작업을 또 해야 한다. 하기 싫다. 하지만 이미 이렇게 될 줄은 프로젝트를 시작 할 때부터 알고 있었다. 개발자는 문서화 작업을 하면서 생각한다. '이럴 줄 알았으면 코딩하면서 중간 중간 문서 만들껄.'

이야기는 반복된다. 이 악마스러운 뫼비우스의 띠 같은 연쇄에서 벗어나는 방법은 개발자들 누구나 다 잘 알고 있다. 실천하지 못할 뿐이다. 물론 이런 글을 두드리고 있는 나도 전혀 실천하지 못하고 있다.

나는 코딩할 때 코드에 주석을 많이 다는 편이다. 그리고 나중을 생각해 이왕이면 doxygen스타일로 주석을 달고 주석을 달 때마다 그때그때 doxygen을 돌려 제대로 문서가 생성되는지 확인하며 프로그래밍을 하는 것이 거의 습관화 되어 있다. 하지만 그것도 최초 코드를 작성할 때나 유효하지 이미 다 작성된 코드를 조금씩 수정하다 보면 그 수정한 코드를 설명한 주석까지 같이 수정하는 것을 잊게 된다. 결국 그런 작업이 누적되고 시간이 지나고 나면 달려 있는 주석과 그 밑에 있는 소스코드가 서로 다른 내용을 표현하고 있는 경우가 생긴다. 시간이 삼 개월쯤 지난 다음 그런 소스를 보고 있으면 나도 모르게 중얼 거린다.

"나 프로그래밍 더럽게 못하는 구나..."

주석을 포함한 설계 문서, 결과 문서가 실제 구현된 소스 코드와 그 내용이 일치하며 지속적으로 유효성을 유지하게 하는 것. 지금처럼 개발자가 이것저것 혼자서 다 해야 하는 상황에서는 정말 요원한 일이 아닐까?

댓글

brucewang의 이미지

개발 문서를 리뷰하는 분들이 계시다는 것도 좋은 회사를 다니고 있다는 증거의 하나가 아닐까 싶습니다. 그 검토의 수준이 어느정도인가도 중요하겠지만요. 어떤 경우는 문서화는 커녕 소스 코멘트 조차도 안 돼 있는것이 당연시 되는 회사도 있는것 같습니다. 프로그래머라면 소스만 보고 알 수 있어야 된다는 것이 이유지요.

문서화를 하는 경우도, 아직도 waterfall 개발 방식을 고수하는 분들 중 아주 극소수의 분들은 초기 설계 단계에 '완벽한' 설계가 되어야 한다는 것을 강조하지요. 실제로 초기 설계 그대로 릴리즈 되는 경우는 그분들 스스로도 경험해 보지 못한 것인데 말입니다.

저의 경우 '테크니컬 라이터' 분들께 문서화의 일부를 위임하는 것에 대해 적극적으로 찬성하는 바 입니다. 개발 문서는 개발자 자신 뿐 아니라 제 3자에게도 쉽게 이해 될 수 있어야 의미가 있는 것이기때문입니다. 테크니컬 라이터에게 구조와 흐름을 설명하고 그것이 문서화 된 것을 다시 개발 당사자가 함께 리뷰해서 '실제로 이후에 도움이 되는 문서' 를 만드는 것이 좋다고 생각합니다.

오래전 이런 생각을 어떤 분과 술자리에서 얘기 했더니, 자칭 프로그래머 출신이시라는 프라이드를 가지고 계시던 그 분은 '모든 문서는 개발자가' 처리해야 한다... 초기의 완벽설계... 이거 나중에 또 바꾸면 멍청한 개발자다.. 면서 더이상의 제 의견을 들어볼 생각도 안하시더군요.

설계가 변경되면서 문서도 수정되어야 하는 부분은 정말 힘든 것 같습니다. 오히려 비효율적이 아닐까 하는 생각이 드네요. 스케치는 필요하지만 양식화된 문서화는 시간을 투자한 만큼의 잇점이 없지 않을까 생각합니다.

QA, TechincalWriter, Developer 이 세 분야를 개발자 혼자 담당해야 하는 조직의 경우라면 저는 모듈에 대한 설명은 간단한 목적/in/out/기타kB 등으로 충분하고 그 대신 테스트 결과에 역점을 두는것이 좋지 않을까 생각하는데...

사실 제 자신은 회사의 시스템과 제 생각이 많이 달라도 뭐라고 의의를 제기하지는 못합니다... ^^

-------------------------------------------------
$yes 4 8 15 16 23 42

-------------------------------------------------
$yes 4 8 15 16 23 42

DwYoon의 이미지

의의 -> 이의(異議)

moc.soolge.nooynowead

brucewang의 이미지

어라, 제 글중에 오타나 띄어쓰기 잘못된게 그것 뿐만은 아닌데요. 더 찾아봐 주세요.

-------------------------------------------------
$yes 4 8 15 16 23 42

-------------------------------------------------
$yes 4 8 15 16 23 42

xyhan의 이미지

저는 3년차 ERP 개발자 입니다.. 업무의 특성상 문서가 굉장히 중요합니다..

업무정의 문서 - > 기술정의 문서 -> 개발

업무 정의 문서를 보고 개발을 위한 테크니컬 문서를 만들고 최종적으로 그 테크니컬 문서를 가지고 개발을 합니다.

하지만.. 업무 문서는 계발이 진행되면서 계속 변하지만.. 테크니컬 문서는 업무가 변하는 속도를 따라 잡지 못하고 뒤로 갈수록
쓸모 업게 되어 버려지게 됩니다..
업무 문서가 한줄 변하면 테크니컬 문서는 열줄이 수정되야되고 개발자는 백라인 정도 수정해야 되죠.. 하지만 프로그램은 반드시 개발이 되야
되기 때문에 수정이 되지만 테크니컬 문서는 중간서 부터는 관리의 필요성이 없게 되어서 수정이 안되게 됩니다..
그리고 실질적으로 제대로된 개발 관련한 테크니컬 문서를 작성하는 분들의 능력이 요구조건을 만족하지 못하는
경향이 있어서 테크니컬 문서자체가 그다지 효용이 없습니다.

결과적으로 유지보수 단계에 가서는 소스를 보고 수정하게 되지
테크니컬 문서를 참고해서 소스를 수정을 하는 일은 거이 불가능 하지 않을까요..

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

============================================================

선한 인간이냐 악한 인간이냐는 그사람의 의지에 달렸다. -에픽테토스-
의지 노력 기다림은 성공의 주춧돌이다. -파스퇴르-

============================================================

brucewang의 이미지

네... 그런 상황일 수록 최초에 정성들여 만든 테크니컬 문서가 의미가 있게끔 하는 것이 중요하다고 생각합니다. 결국에 사용하지 않고, 그 대신 (문서참조 대신) 다른 방법으로 (소스 보기) 할 것이라면 그 최초의 노력은 그 선의에도 불구하고 결국 프로젝트 기간을 잡아먹은게 됩니다. 단지 산출물로서의 의미만 있는 것이죠.

"나빌레라"님의 글은, 그 점을 관조한 상황에서부터 이야기 되는 것이 아닐까 하는 생각이 드네요. 그렇죠?

제 개인적으로 기술문서는 형식상의 '산출물'들 뿐만 아니라, 예를들어 프로토콜의 변경 내역에 대한 간단한 코멘트 등 사소한 기록도 해당한다고 생각합니다.

어떤 개발 조직에 새로운 사람이 투입/대체 된 경우, 소스만 볼 때 보다는 '실제적으로 도움이 되는' 전체적인 플로우나, 기본정보에 대한 문서가 더 기존 지식을 더 쉽게 유도 할 수 있습니다. 특히나, CVS,SVN 같은 형상관리 시스템을 사용하지 않거나, 혹은 사용하는데 팀마다 별도로 관리해서 다른 조직의 어떤 기능을 사용할 때 결국은 human network을 통해야 한다거나 하는 경우..... 이 경우를 잠시 생각 해 보면,

만일 어떤 프로토콜이 처음에 "START" 라는 문자열을 보내고 "|A|B|C|" 형태로 주고 받는 형태였다가, 어느날 갑자기 "|A|B|C|\r\n" 으로 보내져야 하는데, 다른 조직에서 받은 소스 코드에는 새로 변경된 프로토콜 내용이 없고 기존 프로토콜에 대해서 구현이 되어 있거나 하는 경우... 새로 온 사람은 하루아침에 바보가 되어 버립니다. 기존에 계신 분들한테는 1초면 해결 할 수 있는 문제인데도 말이죠. 이때 아주 간단한 코멘트 문서라도 있어야 하고, '언제나 접근 가능해야 하고' '소스와 유사 시점으로 동시에 update' 되어야.... 좋.죠...

전 단지, 산출물에 해당하는 그 방대한 테크니컬 문서의 경우 개발자에게 모두 부담을 주거나, 매번 변경하는데에는 다소 무리가 없지 않나 하는 생각이 듭니다....

사실, 이 글은 제 원래 답변에 달아야 하는데... 마침 xyhan 님께서 좋은 보충 기회를 주셔서 여기에... ^^

-------------------------------------------------
$yes 4 8 15 16 23 42

-------------------------------------------------
$yes 4 8 15 16 23 42

meteors의 이미지

소스 코드가 문서처럼 읽을 수 있도록 되어야겠죠.

당연히 클래스 이름이나 함수 이름, 변수 이름 자체가 쉽게 읽을 수 있어야 하고 길게 풀어써야 하고..

또 어느 단계까지는 세부 코드나 API, Library, System Call이 아닌 프로그래머가 만든 함수만을 부르는 단계가 있고 그 함수들의 이름이 명확해서 읽을 수 있는 형태가 되어야 별도의 문서화를 할 필요가 없어질 것으로 보입니다.

academic의 이미지

개발하기도 바쁜데 문서화까지 따로 하긴 현실적으로 어렵지 않나요?

설계와 개발과 문서화가 유기적으로 통합된 툴을 적극적으로 활용하는 수밖에 없다고 봅니다.

단지 그런 툴은 없거나 있다해도 비싸고...

게다가 따로 공부까지 해야한다는 문제가 있습니다.

쩝... 쉬운게 하나도 없네요.

--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

lieps의 이미지

개발하기도 바쁜데 문서화까지 따로 하는 현실입니다 :)
일반적으로 "갑" 에서는 실제로 무엇인가의 결과물은 문서 입니다.
코드는 부가적인; 아니 당연히 되어야 하는 것이지요.

말씀하신 설계와 개발과 문서화가 유기적으로 통합된 툴을 사용할 가능성도 상당히 낮습니다.
대부분의 정형화된 '갑'은 자기들만의 고유한 문서포맷을 가지고 있습니다.
그 형식에 맞추어서 해줄 수 밖에 없어요 ㅜㅜ

유기적으로 통합된 툴을 사용하여 나온 결과물은 그저 부수적으로 유지보수를 위한
참고문서의 역활만을 할 뿐입니다.(나쁘다는 것이 아니라, 갑에게는 필요없는 문서라는 얘깁니다.)

안타까운 현실이지요.

---
To solve an interesting problem,
start by finding a problem that is interesting to you.

---
To solve an interesting problem,
start by finding a problem that is interesting to you.

academic의 이미지

말씀하시는 바는 알겠고, 당연히 동의합니다만...

제가 명확하게 말을 하지 않아서 말씀드리려던 포인트랑은 좀 다르게 표현된 것 같습니다.

죄송합니다.

'개발하기도 바쁜데 따로 제대로 된 문서화까지 하긴 현실적으로 어렵지 않나요?'로 수정해야겠네요.

말씀하시는 문서화를 갑 때문에라도 해야 한다는 것은 맞습니다만,

갑 때문에 억지로 하는 문서화는 제대로 된 문서화이기가 쉽지 않죠.

그리고...

갑의 고유한 문서포맷에 맞추기 힘들다면 그건 제가 말한 유기적인 툴이 아닙니다.

그런 툴은 문서화하는 부담을 줄여주지 못하죠.

--
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

----
academic은 제 고등학교 때 동아리 이름입니다.
academic, 아주 가끔은 저도 이랬으면 좋겠습니다.

박영만의 이미지

"현실 세계는 우리가 기대하는 것만큼 아름답지 못하다." 라는 말이 참 와닿습니다. -_-

handan의 이미지

저도 그런 고민 많이 했습니다.
주로 문서의 유효화에 대해 고민을 했었고요.

그래서, UML 을 이용한 MDA 를 알게 되었을 때 굉장히 기뻤었지요.
개발문서에서 결과물이 바로 나오는 것이 이론적으로나마 가능하다는 것을 알게 되었으니까요.
하지만, 아직까지 MDA 는 시장의 주류가 아니고 오히려 UML 을 더 적게 쓰는 것이 옳다라는 주장이 더 힘을 얻는 듯 해서 슬프다는 생각마저 가지게 되었습니다.

뭐 언젠가는 좀 더 재미난 세상이 되지 않을까 하는 생각에 계속 이런 저런 시도는 계속 해보는 중입니다.

unipro의 이미지

정리하고 비슷한 것 같네요. 저의 경우는 정리를 하는 목적이 필요할 때 쉽게 찾아서 쓰기 위함입니다. 그런데 때때로 정리에 들어가는 비용이 찾아서 활용하는 비용을 넘어서는 경우가 발생합니다. 그럼 정리를 하는 이유가 없는 셈이 됩니다. 그래서 정리를 유효하게 하는 것도 중요하지만, 필요한 정리를 선별하는 것도 중요한 항목인 듯 합니다. 예들들어, 대부분의 것은 시간에 비례해서 다시 활용될 가능성이 줄어들더군요. 따라서 오래된 자료는 꼼꼼히 정리하지 않고 대충 관련 항목에 쳐박아 버립니다. 또한 임계점이 존재해서 어느 정도 정리가 끝나면 더 꼼꼼히 정리해도 활용하는데 드는 이득이 별로 늘어나지 않게 됩니다. 이 경우는 과감히 그 임계점에서 정리를 끝내야하는게 좋더군요.

개발 문서의 유효성을 유지하는 것도 중요하지만, 문서화를 하는데 드는 비용이 그것을 활용하는 비용을 넘어선다면 그 문서에 작성하는 것을 고려해봐야 할 듯 싶습니다. 대다수의 개발자는 결국에는 소스로 말하고 듣고 합니다. 제 생각에는 문서는 프로젝트의 개략적인 설명, 소스의 전체적인 구성과 흐름, 그리고 모호한 부분(예를들어, 소스에는 없는 가정들)을 명확히 하는 정도면 되지 않을까요? 나머지는 소스가 말해줄테니까요.

----
내 블로그: http://unipro.tistory.com

내 블로그: http://unipro.tistory.com

neolha의 이미지

갑에 의해 억지로 만드는 산출물이 아닌 경우에도 문서화는 그 자체로도 비용이 발생합니다.
따라서 trade off 를 잘 따져볼 필요가 있는 거 같습니다.
저의 경우 문서화는 대부분 커뮤니케이션을 위한 도구로 사용하게 됩니다.
혼자 개발하는 경우에도 과거의 나와 오늘의 나 사이의 잃어버린 기억들을 연결해 주는
소중한 매개체 역할을 문서가 담당해 주죠.
머릿 속에 너무나 확고한 내용은 별달리 문서화를 안 하거나 다시 기억해 내 수 있는 정도로만
문서화를 합니다.
아마도 처음부터 완벽한 문서화 작업을 하라는 압박을 겸험하게 되면서
개발자들이 문서화 작업 자체를 괴물처럼 느끼게 되어버린게 아닐까요..?

cats96의 이미지

프로그래밍 언어도 언어입니다.
개발자가 사용하는 언어...
일반인들이 알아볼 필요는없겠죠.
다른 개발자도 그것을 코드 한줄한줄 이해할필요도 없습니다.
다만 구조, 기능, 흐름 등을 설명하는 개요문서는 필요하다고 봅니다.

댓글 달기

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