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

1. cover story 2
마음까지 연결하는 협업 도구
위키를 활용한
협업 노하우
협업은 함께 코드를 작성하는 것만을 의미하는 것이 아니다. 누군가와 함께 일하는 모든 것을 의미한다. 협업이 중요한 이슈로 떠오르는 이유는 협업의 성
패가 곧 프로젝트의 성공 여부와도 밀접하게 연관되어 있기 때문이다. 특집 2부에서는 협업의 방법 중에 위키를 이용하여 어떻게 협업을 하고 프로젝트를
성공적으로 마무리 할 수 있는지 알아보자.
회사에서 여러 사람들과 함께 업무를 진행하다 보
면 잘못된 정보가 공유되거나 공유 자체가 되지 않아 업무에 혼
선이 발생하는 경우가 있다. 대화의 단절을 소재로 한 TV의 개그
코너를 보고 우리는 즐겁게 웃으며 주말을 보내지만 월요일이 되
면 개그 속 이야기가 현실이 된다.
협업은 여러 사람이 함께 일하는 모든 것을 의미한다. 보통 우
리는 기획자들 간의 협업, 개발자들 간의 협업 그리고 기획팀과
개발팀의 협업 등을 겪고 있다. 인터넷이 대중화된 지금에는 지
구 반대편에 있는 사람과 협업을 통해 소프트웨어를 개발하는 경
우도 잦아졌다. 이런 상황에서 협업을 어떻게 할 것인가는 매우
중요한 고민거리가 된다. 바로 옆에 있는 팀원과도 가끔 대화의
단절을 느끼기도 한다. 하물며 다른 팀이나 다른 회사, 다른 국가
의 사람과 협업한다는 것이 얼마나 어려울 지는 불 보듯 훤한 일
이다.
그렇다고 해서 일을 안 할 순 없지 않은가. 어찌 됐든 협업은
필수적인 요소가 되었다. 어떻게 하면 위키라는 아교를 이용하여
서로의 마음을 하나로 붙이고 올바른 협업을 할 수 있을지 살펴
보자.
용영환 xenonix@gmail.com｜새로운 프로그래밍 언어가
나오면 그에 따른 개발 도구가 등장한다. 웹 프로그래밍을 할
때 아직도 vi와 메모장을 고수하는 걸 보고 있자면 이 분야는 우리에게 위키가 필요한 이유
개발 도구에 큰 영향을 받지 않는 것 같다. 하지만, 다가올 미래
매주 월요일 아침. 출근하자마자 처음으로 하게 되는 업무는
에는 개발 언어보다 개발 도구를 잘 다루는 것이 더 중요할지도
모른다. 으레 주간 회의다. 지난주에 했던 일과 이번 주에 할 일을 이야기
124 m a s o

2. 한다. 나의 업무 노트는 어느새 글자들로 빼곡하다. 회의를 마치 ∙ 문서를 구성원들과 함께 편집하거나 공유할 수 있으면 좋겠다.
고 본격적인 업무에 들어가기 전에 업무 노트에 기록한 회의 내 ∙ 많은 문서를 체계적으로 관리할 수 있으면 좋겠다.
용을 정리한다. 나뿐만 아니라 팀원들이 각자 회의 내용을 정리
하느라 바쁘다. 하루에 두세 번씩 회의라도 하는 날이면 이런 일 이러한 요구사항을 반영한 소프트웨어가 있다면 얼마를 지불
을 반복하느라 하루를 다 보내고 퇴근 시간이 될 무렵이나 되어 하더라도 구입하겠다는 생각을 해본 적이 있다면 위키를 사용해
야 실제 업무를 시작할 수 있게 된다. 보길 권한다.
이런 일들은 우리의 일상 속에서 수도 없이 겪게 된다. 업무효
율이라고는 찾아볼 수 없는 우리네 현실이다. NHN에 입사하기 위키란 무엇인가
전 필자가 근무했었던 회사에서는 문서 정리 시간의 낭비를 줄이 위키는 HTML보다 간단한 마크업 언어(markup language)
기 위해 정리에 능숙한 한 사람이 회의록을 작성하여 이메일로 를 이용하여 문서를 공동으로 작성하고 관리할 수 있도록 해 주
공유하도록 했다. 그 외 사람들은 각자 업무에 집중할 수 있고 잘 는 방식이다. 별도의 위키 문법을 사용하여 문서를 편집하며 출
정리된 회의록을 이메일로 전달 받을 수 있었기에 모두들 만족스 력할 때에는 HTML 로 변환되어 보여 지기 때문에 작성하는 사
러워 했다. 하지만 이렇게 이메일로 문서를 공유하는 방법은 몇 람과 보는 사람 모두에게 좋은 문서 환경을 제공한다. 그 밖에도
가지 문제점을 가지고 있다. 다음과 같은 장점들을 가지고 있다.
● 정보 흐름의 단방향성 ∙ 언제 어디서나 가능하다.
문서를 작성한 사람이 모든 것을 알거나 이해하고 있다고 보장 ∙ 한 문서 여러 사람이 함께 편집할 수 있다.
할 수는 없다. 다른 구성원들이 더 잘 알고 있는 부분도 있을 수 ∙ 최근 편집된 문서를 알 수 있다.
있지만 반영되기 어렵다. 물론 나에게 전달된 문서를 변경하여 ∙ 문서 편집 기록을 남길 수 있다.
다시 이메일로 전송할 수도 있겠지만 바쁜 업무로 인해 문서를 보 ∙ 문서를 검색할 수 있다.
는 것만도 벅찬 상황에서 수정본을 재전송한다는 것은 쉽지 않은
일이다. 그렇다면 잘못 된 내용이 문서로 남을 가능성도 있으며 ● 언제 어디서나
문서를 작성하지 않는 다른 구성원들은 무관심해질 수도 있다. 위키는 웹 기반의 소프트웨어다. 블로그나 웹사이트처럼 웹 서
버에 위키 소프트웨어를 설치한 후에 웹브라우저로 접속하면 사
● 문서 관리의 어려움 용할 수 있다. 그 덕분에 인터넷이 연결된 곳이라면 언제 어디서
앞선 문제들을 해결하고 수정본을 이메일로 교환하여 문서의 든 위키를 사용할 수 있다. 만약 웹 서버를 소유하고 있지 않다면
최종본을 만들었다고 해도 문제는 여전히 남는다. 오늘 주고받은 웹호스팅 서비스를 이용해 위키를 설치하거나 PC용 위키를 설
이메일만 해도 수 십여 통에 달한다. 일주일쯤 지난 후에 전에 완 치하여 사용하면 된다. 최근에는 위키 온라인 서비스까지 등장했
성했던 문서를 이메일 수신함을 뒤져 찾는 것은 생각보다 복잡한 기 때문에 설치 과정 없이 서비스에 가입하기만 하면 위키를 사
일이기 될 것이기 때문이다. 수정본을 여러 번 주고받다 보 어느 용할 수도 있다.
것이 최종본인지 알기 어려울 것이다. 맨 마지막에 도착한 이메
일이 최종본인지 제목에‘최종본’
이라고 쓰여 있는 것이 최종본 ● 문서 동시 편집
인지 도무지 확신하기 어려울 것이다. 여러 사람이 함께 문서를 열어 보거나 편집을 할 수 있다. 만약
동시에 같은 문서를 편집하려 한다면 적절하게 문서를 보호하면
효과적인 문서 관리의 요구사항 서 편집할 수 있는 장치가 마련되어 있다. 예를 들면 무전기처럼
어느 회사든 문서를 작성하고 공유하는데 들이는 소요비용을 한 사람이 편집을 하고 있을 때 다른 사람들은 내용을 볼 수만 있
최소화하면서 효과적으로 공유할 수 있는 방법을 고민하고 있을 고 편집이 완료되면 다른 사람이 편집 권한을 얻어 문서를 이어
것이다. 업무의 특성에 따라 조금씩 차이는 있을 수 있겠지만 기 작성하는 것이다.
본적으로는 다음사항들이 공통적인 요구사항이 된다.
● 문서 편집 기록
∙ 언제 어디서나 문서를 작성할 수 있으면 좋겠다. 위키는 문서가 처음 생성된 시점부터 현재 어떻게 내용이 변경
m a s o 125

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. 신규 프로젝트
사내 위키
[쇼핑몰 개발
[프로젝트] 블로그 개발
프로젝트]
[사내 자원] 프로젝트
[플로그 개발
[사내 일정]
프로젝트]
위키
기획안
일정
쇼핑몰 개발
프로젝트 서버 자원
<그림 2> 생각을 적는다 [기획안]
[일정]
[투입 인력]
회사나 커뮤니티에서 위키를 설치해 두고 <그림 2>와 같이 구 [서버 자원] 투입 인력
성원들의 생각을 자유롭게 적는다. 꼬리에 꼬리를 물고 계속해서
생각을 적다 보면 어느새 그 양은 방대해지고 그동안 생각지 못 <그림 3> 사내 위키 문서 구조
했던 것들이 떠오르기도 한다.
만약 더 좋은 생각을 갖고 있다면 <리스트 3>과 같이 문서를 편 위키에서 개발 문서 작성하기
집하여 덧붙이면 된다. 이때 들여쓰기를 하여 생각의 연관성을 개발 과정에서 작성되는 문서를 위키에 작성하거나 정리하게
유지하는 것이 좋다. 결정이 필요한 사안인 경우 의사 표현을 할 되면 개발에 대한 문서 공유가 쉽고 개발이 완료된 이후에도 문
수도 있다. 위키에서 이러한 과정을 반복하면서 아이디어를 확장 서를 쉽게 관리할 수 있다. <그림 3>에서 [쇼핑몰 개발 프로젝트]
하고 구체화 시킨다. 문서를 프로젝트 매니저가 생성하였다면 [기획안], [일정], [투
입 인력], [서버 자원] 등의 문서는 각 담당자들이 작성하면 된
<리스트 3> <리스트 1>에 생각을 덧붙인 ∙생각의 정리∙
다. 이 외에도 여러 가지 설계도들도 작성해야 할 텐데 위키에
생각의 정리#
∙ 효과적인 회의방법 는 다이어그램을 직접 그리지 못하므로 파일을 첨부하는 것으
∙ 회의는 짧게, 정리는 명확하게 로 최신 문서가 무엇인지를 프로젝트에 참여 구성원들에게 알
∙ 회사 블로그 운영 방안
릴 수 있다.
∙ 회사의 소식을 매주 월요일 블로그에 적는 건 어떨까요?
∙ 좋은 생각입니다. 구성원들은 각자 PC 안에 프로젝트 관련 문서들을 쌓아둘 필
∙ 회사 소식뿐 아니라 우리 팀원들의 소개 글도 적어요~. 요 없이 문서가 필요한 경우 위키에 접속하여 열람하면 된다. 문
∙ 피로와 졸음의 원인과 해결 방법
서 작성자 또한 구성원들에게 별도로 공지를 하지 않고 위키에
∙ 커피도 중독이 되면 효과 없다고 합니다.
∙ 업무 중 쉬는 시간에 산책을 하는 게 좋겠습니다. 최신 문서를 갱신하기만 하면 되므로 업무의 부담이 한결 줄어든
∙ 신규 웹서비스 아이디어 수집
∙ 블로그 서비스
문서 변경 통보 문서 변경 통보
∙ UCC 서비스 위키 시스템
∙ 친구 만들기 서비스
∙ 사람과 사람을 연결하는 새로운 개념의 서비스가 좋을 것 같아요.
일정
위키로 업무 공유하기 문서 작성
위키는 생각을 공유하는 것 외에도 업무 일지를 작성하거나 사 프로젝트 매니저 기획서 그래픽 디자이너
내의 다양한 문서를 정리하는 데도 좋은 역할을 한다. 필자는 본
시안
인이 갖고 있는 컴퓨터의 자원이나 소프트웨어 구입 목록, 가입
한 인터넷 서비스 계정 목록 등을 위키에 문서로 관리하고 있다. 설계도
회사라면 서버 목록이나 사내 IP 목록, 사원 정보, 프로젝트 개발 기획자
소프트웨어 개발자
일정 등을 위키에 정리하여 공유하는 것이다. <그림 3>처럼 사내
위키에 업무에 관련된 문서들을 작성하면 된다. <그림 4> 위키에서의 문서 작성 협업
m a s o 127

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. 위키 백과에 사용되는 대용량 위키 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