[협업 도구] 위키를 활용한 협업 노하우

3,963 views

Published on

월간 마이크로소프트웨어 2007년 8월호 특집기사에 기고한 글입니다.

Published in: Business
1 Comment
10 Likes
Statistics
Notes
No Downloads
Views
Total views
3,963
On SlideShare
0
From Embeds
0
Number of Embeds
53
Actions
Shares
0
Downloads
0
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

[협업 도구] 위키를 활용한 협업 노하우

  1. 1. cover story 2 마음까지 연결하는 협업 도구 위키를 활용한 협업 노하우 협업은 함께 코드를 작성하는 것만을 의미하는 것이 아니다. 누군가와 함께 일하는 모든 것을 의미한다. 협업이 중요한 이슈로 떠오르는 이유는 협업의 성 패가 곧 프로젝트의 성공 여부와도 밀접하게 연관되어 있기 때문이다. 특집 2부에서는 협업의 방법 중에 위키를 이용하여 어떻게 협업을 하고 프로젝트를 성공적으로 마무리 할 수 있는지 알아보자. 회사에서 여러 사람들과 함께 업무를 진행하다 보 면 잘못된 정보가 공유되거나 공유 자체가 되지 않아 업무에 혼 선이 발생하는 경우가 있다. 대화의 단절을 소재로 한 TV의 개그 코너를 보고 우리는 즐겁게 웃으며 주말을 보내지만 월요일이 되 면 개그 속 이야기가 현실이 된다. 협업은 여러 사람이 함께 일하는 모든 것을 의미한다. 보통 우 리는 기획자들 간의 협업, 개발자들 간의 협업 그리고 기획팀과 개발팀의 협업 등을 겪고 있다. 인터넷이 대중화된 지금에는 지 구 반대편에 있는 사람과 협업을 통해 소프트웨어를 개발하는 경 우도 잦아졌다. 이런 상황에서 협업을 어떻게 할 것인가는 매우 중요한 고민거리가 된다. 바로 옆에 있는 팀원과도 가끔 대화의 단절을 느끼기도 한다. 하물며 다른 팀이나 다른 회사, 다른 국가 의 사람과 협업한다는 것이 얼마나 어려울 지는 불 보듯 훤한 일 이다. 그렇다고 해서 일을 안 할 순 없지 않은가. 어찌 됐든 협업은 필수적인 요소가 되었다. 어떻게 하면 위키라는 아교를 이용하여 서로의 마음을 하나로 붙이고 올바른 협업을 할 수 있을지 살펴 보자. 용영환 xenonix@gmail.com|새로운 프로그래밍 언어가 나오면 그에 따른 개발 도구가 등장한다. 웹 프로그래밍을 할 때 아직도 vi와 메모장을 고수하는 걸 보고 있자면 이 분야는 우리에게 위키가 필요한 이유 개발 도구에 큰 영향을 받지 않는 것 같다. 하지만, 다가올 미래 매주 월요일 아침. 출근하자마자 처음으로 하게 되는 업무는 에는 개발 언어보다 개발 도구를 잘 다루는 것이 더 중요할지도 모른다. 으레 주간 회의다. 지난주에 했던 일과 이번 주에 할 일을 이야기124 m a s o
  2. 2. 한다. 나의 업무 노트는 어느새 글자들로 빼곡하다. 회의를 마치 ∙ 문서를 구성원들과 함께 편집하거나 공유할 수 있으면 좋겠다.고 본격적인 업무에 들어가기 전에 업무 노트에 기록한 회의 내 ∙ 많은 문서를 체계적으로 관리할 수 있으면 좋겠다.용을 정리한다. 나뿐만 아니라 팀원들이 각자 회의 내용을 정리하느라 바쁘다. 하루에 두세 번씩 회의라도 하는 날이면 이런 일 이러한 요구사항을 반영한 소프트웨어가 있다면 얼마를 지불을 반복하느라 하루를 다 보내고 퇴근 시간이 될 무렵이나 되어 하더라도 구입하겠다는 생각을 해본 적이 있다면 위키를 사용해야 실제 업무를 시작할 수 있게 된다. 보길 권한다. 이런 일들은 우리의 일상 속에서 수도 없이 겪게 된다. 업무효율이라고는 찾아볼 수 없는 우리네 현실이다. NHN에 입사하기 위키란 무엇인가전 필자가 근무했었던 회사에서는 문서 정리 시간의 낭비를 줄이 위키는 HTML보다 간단한 마크업 언어(markup language)기 위해 정리에 능숙한 한 사람이 회의록을 작성하여 이메일로 를 이용하여 문서를 공동으로 작성하고 관리할 수 있도록 해 주공유하도록 했다. 그 외 사람들은 각자 업무에 집중할 수 있고 잘 는 방식이다. 별도의 위키 문법을 사용하여 문서를 편집하며 출정리된 회의록을 이메일로 전달 받을 수 있었기에 모두들 만족스 력할 때에는 HTML 로 변환되어 보여 지기 때문에 작성하는 사러워 했다. 하지만 이렇게 이메일로 문서를 공유하는 방법은 몇 람과 보는 사람 모두에게 좋은 문서 환경을 제공한다. 그 밖에도가지 문제점을 가지고 있다. 다음과 같은 장점들을 가지고 있다.● 정보 흐름의 단방향성 ∙ 언제 어디서나 가능하다. 문서를 작성한 사람이 모든 것을 알거나 이해하고 있다고 보장 ∙ 한 문서 여러 사람이 함께 편집할 수 있다.할 수는 없다. 다른 구성원들이 더 잘 알고 있는 부분도 있을 수 ∙ 최근 편집된 문서를 알 수 있다.있지만 반영되기 어렵다. 물론 나에게 전달된 문서를 변경하여 ∙ 문서 편집 기록을 남길 수 있다.다시 이메일로 전송할 수도 있겠지만 바쁜 업무로 인해 문서를 보 ∙ 문서를 검색할 수 있다.는 것만도 벅찬 상황에서 수정본을 재전송한다는 것은 쉽지 않은일이다. 그렇다면 잘못 된 내용이 문서로 남을 가능성도 있으며 ● 언제 어디서나문서를 작성하지 않는 다른 구성원들은 무관심해질 수도 있다. 위키는 웹 기반의 소프트웨어다. 블로그나 웹사이트처럼 웹 서 버에 위키 소프트웨어를 설치한 후에 웹브라우저로 접속하면 사● 문서 관리의 어려움 용할 수 있다. 그 덕분에 인터넷이 연결된 곳이라면 언제 어디서 앞선 문제들을 해결하고 수정본을 이메일로 교환하여 문서의 든 위키를 사용할 수 있다. 만약 웹 서버를 소유하고 있지 않다면최종본을 만들었다고 해도 문제는 여전히 남는다. 오늘 주고받은 웹호스팅 서비스를 이용해 위키를 설치하거나 PC용 위키를 설이메일만 해도 수 십여 통에 달한다. 일주일쯤 지난 후에 전에 완 치하여 사용하면 된다. 최근에는 위키 온라인 서비스까지 등장했성했던 문서를 이메일 수신함을 뒤져 찾는 것은 생각보다 복잡한 기 때문에 설치 과정 없이 서비스에 가입하기만 하면 위키를 사일이기 될 것이기 때문이다. 수정본을 여러 번 주고받다 보 어느 용할 수도 있다.것이 최종본인지 알기 어려울 것이다. 맨 마지막에 도착한 이메일이 최종본인지 제목에‘최종본’ 이라고 쓰여 있는 것이 최종본 ● 문서 동시 편집인지 도무지 확신하기 어려울 것이다. 여러 사람이 함께 문서를 열어 보거나 편집을 할 수 있다. 만약 동시에 같은 문서를 편집하려 한다면 적절하게 문서를 보호하면효과적인 문서 관리의 요구사항 서 편집할 수 있는 장치가 마련되어 있다. 예를 들면 무전기처럼 어느 회사든 문서를 작성하고 공유하는데 들이는 소요비용을 한 사람이 편집을 하고 있을 때 다른 사람들은 내용을 볼 수만 있최소화하면서 효과적으로 공유할 수 있는 방법을 고민하고 있을 고 편집이 완료되면 다른 사람이 편집 권한을 얻어 문서를 이어것이다. 업무의 특성에 따라 조금씩 차이는 있을 수 있겠지만 기 작성하는 것이다.본적으로는 다음사항들이 공통적인 요구사항이 된다. ● 문서 편집 기록∙ 언제 어디서나 문서를 작성할 수 있으면 좋겠다. 위키는 문서가 처음 생성된 시점부터 현재 어떻게 내용이 변경 m a s o 125
  3. 3. cover story 2_위키를 활용한 협업 노하우 되어 왔는지를 모두 기록하고 있다. 형상 관리와 같은 이 기능은 수개월 전의 문서와 현재 문서가 어떻게 바뀌었는지 비교해 볼 마이크로소프트웨어 협업을 위한 위키 활용 수 있고 필요에 따라 예전 문서로 되돌아 갈 수 있도록 해준다. [협업을 위한 [위키]는 여러 사람이 함께 이는 문서를 작성하는 이에게 원본에 대한 부담을 덜어주므로 마 위키 활용] 분서를 작업할 수 있다. 음 편하게 내용을 편집 할 수 있게 해준다. 그리고 변경된 내용을 추적할 수 있으므로 잘못 작성된 문서에 대한 문제점도 쉽게 찾 을 수 있다. 위키 ● 최근 문서 알림 위키의 장점 협업 [위키의 장점]을 문서의 양이 많아지다 보면 누가 언제 어떤 문서를 편집했는지 [협업]에도 좋은가? 협업이란 알아보자. 확인하는 것이 어려워진다. 위키는 일반적으로 최근 편집된 문서 의 목록을 제공한다. 또한 위키에 따라 최근 변경 글 정보를 이메 <그림 1> 위키 문서 간 연관 관계 일로 전송해 주거나 RSS로 제공하기 때문에 위키에 접속하지 않 더라도 언제 누구에 의해 어떤 문서가 변경되는지 알 수 있다. 위키에 생각을 적고 공유 한다 이러한 장점으로 인해 다양한 분야에서 위키를 협업의 도구로 소프트웨어를 만들기 전에 가장 먼저 해야 할 일은 좋은 아이 활용하고 있다. 디어를 수집하고, 결정된 아이디어를 구체화하는 것이다. 이는 프로젝트의 첫 단추를 꿰는 것인 만큼 매우 중요하다(SI 업체라 협업을 위한 위키 활용법 면 요구사항을 분석하고 정리하는 단계다). 어떠한 서비스를 기 위키가 아무리 좋다하더라도 위키를 어떻게 사용해야 할지 모 획하는데 있어 아이디어가 많다는 것은 그만큼 좋은 서비스가 될 른다면 불필요한 도구로만 느껴질 것이다. 필자가 처음 위키를 가능성이 높다는 것과도 일맥상통한다. 하지만 아이디어는 순간 접했을 때 이것을 어떻게 사용해야 하는지 감을 잡을 수 없었다. 떠올랐다가 사라지는 휘발성이기 때문에 바로 정리해 두지 않으 문서를 작성하는데 사용하는 것이라고 하는데 어떻게 작성해야 면 잊혀 지기 십상이다. 그럴 때 위키를 메모장처럼 사용하면 된 하는지, 위키에 문서를 작성하면 무엇이 좋은지 이해가되질 않았 다. 인터넷을 접속할 수 있는 곳을 찾아 위키에 생각을 적는다. 다. 위키는 사용해 보지 않고서는 그 특성을 이해하기 어렵다. 위 어떻게 적든 상관없다. 몇 가지 위키 문법만 알고 있다면 아무 키가 우리 팀에 필요한 도구라는 생각이 든다면 지금 바로 설치 렇게나 적은 문서도 잘 정리되어 출력되기 때문이다. 만약 회사 하고 문서를 만들어봐야 한다. 에서 업무를 하거나 쉬는 시간에 신문을 보고 동료와 이야기를 하다가도 좋은 생각이 떠올랐다면 위키를 열고 적으면 된다. 필 위키를 시작하다 자는 <리스트 1>과 같이 위키에‘생각의 정리’분류를 만들어 생 필자가 처음 사용했던 위키는 모니위키(http://sourceforge. 각을 정리하고 있다. net/projects/moniwiki/)다. 국내에서 개발되었고 KLDP 위키 (http://wiki.kldp.org/wiki.php)에도 사용되고 있을 정도로 <리스트 1> 생각의 정리 대중적이었다. 또, PHP로 개발되었기 때문에 설치가 쉽다는 점 생각의 정리# ∙ 효과적인 회의방법 도 선택하게 된 이유 중 하나였다. 설치 방법은 내려 받은 파일 ∙ 회사 블로그 운영 방안 의 압축을 풀고 웹 계정에 업로드하여 브라우저로 접속하기만 ∙ 피로와 졸음의 원인과 해결 방법 ∙ 블로그 서비스 아이디어 수집 하면 된다. 위키에서는 단어에 링크를 걸어 문서를 생성한다. 단어에 링크 를 생성하는 방법은 위키에 따라 차이가 있지만 일반적으로 <그 <리스트 2> <리스트 1>의 위키 문법 림 1>과 같이 [ ]로 감싸면 된다. 이 단어들은 문서의 연결 고리 === 생각의 정리 === * 효과적인 회의방법 역할을 하여 작은 조각으로 이루어진 문서들을 거대한 하나의 문 * 회사 블로그 운영 방안 서로 만들어 준다. * 피로와 졸음의 원인과 해결 방법 * 블로그 서비스 아이디어 수집126 m a s o
  4. 4. 신규 프로젝트 사내 위키 [쇼핑몰 개발 [프로젝트] 블로그 개발 프로젝트] [사내 자원] 프로젝트 [플로그 개발 [사내 일정] 프로젝트] 위키 기획안 일정 쇼핑몰 개발 프로젝트 서버 자원<그림 2> 생각을 적는다 [기획안] [일정] [투입 인력] 회사나 커뮤니티에서 위키를 설치해 두고 <그림 2>와 같이 구 [서버 자원] 투입 인력성원들의 생각을 자유롭게 적는다. 꼬리에 꼬리를 물고 계속해서생각을 적다 보면 어느새 그 양은 방대해지고 그동안 생각지 못 <그림 3> 사내 위키 문서 구조했던 것들이 떠오르기도 한다. 만약 더 좋은 생각을 갖고 있다면 <리스트 3>과 같이 문서를 편 위키에서 개발 문서 작성하기집하여 덧붙이면 된다. 이때 들여쓰기를 하여 생각의 연관성을 개발 과정에서 작성되는 문서를 위키에 작성하거나 정리하게유지하는 것이 좋다. 결정이 필요한 사안인 경우 의사 표현을 할 되면 개발에 대한 문서 공유가 쉽고 개발이 완료된 이후에도 문수도 있다. 위키에서 이러한 과정을 반복하면서 아이디어를 확장 서를 쉽게 관리할 수 있다. <그림 3>에서 [쇼핑몰 개발 프로젝트]하고 구체화 시킨다. 문서를 프로젝트 매니저가 생성하였다면 [기획안], [일정], [투 입 인력], [서버 자원] 등의 문서는 각 담당자들이 작성하면 된 <리스트 3> <리스트 1>에 생각을 덧붙인 ∙생각의 정리∙ 다. 이 외에도 여러 가지 설계도들도 작성해야 할 텐데 위키에 생각의 정리# ∙ 효과적인 회의방법 는 다이어그램을 직접 그리지 못하므로 파일을 첨부하는 것으 ∙ 회의는 짧게, 정리는 명확하게 로 최신 문서가 무엇인지를 프로젝트에 참여 구성원들에게 알 ∙ 회사 블로그 운영 방안 릴 수 있다. ∙ 회사의 소식을 매주 월요일 블로그에 적는 건 어떨까요? ∙ 좋은 생각입니다. 구성원들은 각자 PC 안에 프로젝트 관련 문서들을 쌓아둘 필 ∙ 회사 소식뿐 아니라 우리 팀원들의 소개 글도 적어요~. 요 없이 문서가 필요한 경우 위키에 접속하여 열람하면 된다. 문 ∙ 피로와 졸음의 원인과 해결 방법 서 작성자 또한 구성원들에게 별도로 공지를 하지 않고 위키에 ∙ 커피도 중독이 되면 효과 없다고 합니다. ∙ 업무 중 쉬는 시간에 산책을 하는 게 좋겠습니다. 최신 문서를 갱신하기만 하면 되므로 업무의 부담이 한결 줄어든 ∙ 신규 웹서비스 아이디어 수집 ∙ 블로그 서비스 문서 변경 통보 문서 변경 통보 ∙ UCC 서비스 위키 시스템 ∙ 친구 만들기 서비스 ∙ 사람과 사람을 연결하는 새로운 개념의 서비스가 좋을 것 같아요. 일정위키로 업무 공유하기 문서 작성 위키는 생각을 공유하는 것 외에도 업무 일지를 작성하거나 사 프로젝트 매니저 기획서 그래픽 디자이너내의 다양한 문서를 정리하는 데도 좋은 역할을 한다. 필자는 본 시안인이 갖고 있는 컴퓨터의 자원이나 소프트웨어 구입 목록, 가입한 인터넷 서비스 계정 목록 등을 위키에 문서로 관리하고 있다. 설계도회사라면 서버 목록이나 사내 IP 목록, 사원 정보, 프로젝트 개발 기획자 소프트웨어 개발자일정 등을 위키에 정리하여 공유하는 것이다. <그림 3>처럼 사내위키에 업무에 관련된 문서들을 작성하면 된다. <그림 4> 위키에서의 문서 작성 협업 m a s o 127
  5. 5. cover story 2_위키를 활용한 협업 노하우 다. 이는 위키가 자동으로 최근 변경된 문서를 이메일이나 RSS 만약 버그 내용이 복잡한 경우 <표 1>의 두 번째 행처럼 [첨부 로 보내주기 때문이다. 파일 추가 오류]에 링크를 걸어 문서를 새로 열고 자세한 내용 을 적으면 된다. 그러면 <그림 6>과 같이 위키 문서가 구성되는 위키에서 소스 코드 공유하기 것이다. 형상 관리 소프트웨어를 사용하더라도 경우에 따라 소스 코드 를 따로 공유해야 하는 경우가 발생한다. 예를 들면 형상 관리를 사내 위키 할 만큼 큰 소스 코드는 아니고 필요한 경우 Copy&Paste를 위 [프로젝트] 해 어딘가에 작성해 두면 좋을만한 그런 소스코드들 말이다. 위 버그 리포트 [사내 자원] 키는 소스 코드를 작성할 수 있도록 <code html></code> 같은 문 [사내 일정] [개발팀] 법을 지원한다. 그러면 <그림 3>의 사내 위키를 <그림 5>와 같이 [버그 리포트] 첨부 파일 오류 확장할 수 있을 것이다. 사내 위키 [첨부 파일 오류] 개발팀 [프로젝트] 공통 소스 코드 [공통 소스 코드] <그림 6> 버그 리포트 작성 [사내 자원] [개발 일정] [회원 인증 코드] [사내 일정] [개발팀 연락망] [DBMS 연동 코드] [개발팀] 용도에 맞는 위키 선택하기 지금까지 생각을 적고 일정을 수립하고 프로젝트를 완료하는 과정에서 위키를 어떻게 활용할 수 있는지 간단히 살펴보았다. 회원 인증 코드 DBMS 연동 코드 이처럼 사내 또는 팀 내에서 위키를 사용하면 구성원 간에 정보 를 좀 더 쉽게 공유할 수 있을 것이다. 위키를 사용하기로 결심했으나 위키 종류가 너무 많아 고민이 된다. 위키도 선택하는 요령이 필요하다. 자세한 비교 내용은 http://en.wikipedia.org/ wiki/Comparison_of_wiki_software <그림 5> 위키에서의 소스 코드 공유 를 참고하길 바란다. 위키에서 버그 리포트 작성하기 웹사이트를 만드는데 좋은 PmWiki 소프트웨어를 다 만들었다 하더라도 개발이 완료된 것은 아니 웹사이트 http://www.pmwiki.org/wiki/PmWiki/PmWiki 다. 소프트웨어 품질 관리(QA) 과정이 남아 있으며 이후에도 버 개발 언어 PHP 그 리포트를 작성하고 오류를 수정해야만 한다. 이 과정에서도 데이터베이스 파일 비용 무료 위키를 사용하면 도움이 된다. 이제는 프로젝트 매니저와 기획 특징 웹 애플리케이션 컨퍼런스 2007(http://www.webapps 자, 프로그래머뿐 아니라 테스터들에게도 위키가 필요한 도구가 con.com)의 행사 웹사이트가 PmWiki로 개발 되는 것이다. 위키에는 HTML의 Table을 작성할 수 있는 문법 을 제공한다. <표 1>과 같이 테스터들은 버그 목록을 위키에 테이 다양한 템플릿과 플러그인을 제공하는 DokuWiki 블로 작성하면 개발자들은 테이블의 버그를 하나씩 지워나가는 웹사이트 http://wiki.splitbrain.org/wiki:dokuwiki 것이다. 개발 언어 PHP 데이터베이스 파일 날짜 버그 내용 진행 상태 비용 무료 2007/07/10 로그인이 안 됨. 수정 완료 특징 템플릿과 플러그인이 다양하게 제공되기 때문에 개인 또는 소규 2007/07/13 [첨부 파일 추가 오류] 수정 중 모 그룹에서 많이 사용. 2007/07/15 첫 화면에 CSS 가 잘못 되어 있음. <표 1> 위키를 이용한 버그 목록128 m a s o
  6. 6. 위키 백과에 사용되는 대용량 위키 MediaWiki 위드 프로세스서를 사용하듯 쉬운 서비스형 위키 스프링 노트웹사이트 http://www.mediawiki.org/wiki/MediaWiki/ko 웹사이트 http://springnote.com/개발 언어 PHP 비용 무료데이터베이스 MySQL , PostgreSQL 특징 웹사이트에 가입 후 사용하는 서비스형 위키. 쉬운 인터페이스를비용 무료 제공하며 다양한 편집 기능을 제공.특징 특징위키 백과와 같은 대용량 시스템에 사용.SVN 과 연동되는 개발용 위키 TracWiki 위키의 잠재력웹사이트 http://trac.edgewall.org/wiki/TracWiki 해외로 출장을 떠나 사내 위키에 보고서를 작성하였더니 본사개발 언어 Python 에 있는 동료가 보고서의 오류를 정정해 주는 모습은 이제 우리데이터베이스 Clearsilver, SQLite, PostgreSQL, MySQL 일상이 되어가고 있다. 문서를 PC 에 저장하지 않고 인터넷 공간비용 무료 에 저장하는 시대로 변화하고 있는 지금 위키를 잘 활용하는 것특징 오픈 개발 그룹에서 버전 관리와 문서 관리 용도로 사용. 이 경쟁력이 될 수 있다.Java 기반의 엔터프라이즈 위키 Confluence 위키는 분명 협업의 중요한 도구로 사용되고 있다. 아직도 위웹사이트 http://www.atlassian.com/software/confluence/ 키를 사용해 보지 않았거나 도입을 주저하고 있다면 이번 기회에개발 언어 Java 꼭 한번 사용해 보길 바란다. 위키로 인해 얻는 긍정적 효과가 크데이터베이스 PostgreSQL, MySQL, Oracle, DB2, MS SQL Server 다는 것을 느낄 수 있을 것이다.비용 유료 (단, 개인 또는 오픈소스 커뮤니티 한해 무료 라이센스 발급)특징 대규모 오픈소스 커뮤니티나 기업에서 문서 공유를 위해 사용. 위키 문법 비교 <출처 : http://www.wikimatrix.org> DokuWiki MoniWiki PmWiki MediaWiki 내부 링크 [[a Link]] CamelCaseLink or “free link” [ ] [[page name]] [[a link|with title]] [[namespace:link]] [[free link]] ==FreeLink [[page name | link text]] [[link|With a Title]] [wiki:PageName show name] [[link text -> page name]] KLDPWiki:FrontPage [[page name #anchor]][[a link]] [page name] == PageName [wiki:KLDPWiki:FrontPage front page] 외부 링크 [[http://example.com]] http://google.com/ or http://.... [http://example.org [[http://example.com|With a Title]] [http://google.com/ Google] or [[http://... | link text]] The title] file://///server/share/file [[link text -> http://...]] 헤드라인 = = = = = = Level 1 = = = = = = = Level 1 = ! Level 1 = =Section= = = = = = = Level 2 = = = = = = = Level 2 = = !! Level 2 = = =Subsection= = = = = = = Level 3 = = = = = = = Level 3 = = = !!! Level 3 = = = =Sub- = = = Level 4 = = = = = = = Level 4 = = = = subsection= = = = = = Level 5 = = = = = = = Level 5 = = = = = 진하게 **bold** ’ bold’ ’’ ’’ ’ bold’ ’’ ’’ ’ bold’ ’’ ’’ 기울임 //italics// ’ ’italic’ ’ ’ ’italic’ ’ ’ ’italic’ ’ 밑줄 __underlined__ __underline__ {+underlined+} <u>underlined</u> 취소선 <del>strikethrough</del> ~~strike~~ {-strikethrough-} <s>strikethrough</s> 이미지 {{local.jpg}} http://foo.bar/foo.jpg 또는 http://foo.bar/foo.jpg [[Image:wiki.png]] {{http://foo.bar/baz.jpg}} attachment:foo.jpg Attach:foo.jpg [[Attachment(foo.jpg)]] 글머리표 * item 1 * Item 1 * Item 1 * Item 1 * item 1.1 * Item 1.1 ** Item 1.1 ** Item 1.2 * item 2 * Item 2 * Item 2 * Item 2 문단번호 - item 1 1. Item 1 # Item 1 # Item 1 - item 1.1 a. Item 1.a ## Item 1.1 ## Item 1.2 - item 2 1. Item 2 # Item 2 # Item 2 I. Item 2.I 1. Item 3 I.#48 Item 3. with“value=48”attribute m a s o 129

×