얼마 전 모기업으로부터 홈페이지를 퍼블리싱하기 위한 문서 제작을 의뢰 받았습니다. 고객은 HTML 문서가 아닌 마크다운(markdown) 형식의 문서로 제작해 줄 것을 주문했습니다. 이러한 과제는 경험이 풍부한 한샘으로서는 큰 문제가 아니었으며, “위키” 시스템을 통해 고객과 사내 내부 작업자 간의 소통과 협업이 자유롭게 이루어져 모두가 만족하는 결과물을 완성할 수 있었습니다. (참고1)
1. 시스템개발팀에서 마크다운 문서 제작을 재조명하는 글을 게재한 바 있습니다. (Markdown – 인사이더 또는 아웃사이더, https://hansem.com/opinion-markdown/ 참고)
이 글에서는 다루고자 하는 것은 위키를 원고 작성 툴로 선택하게 된 배경입니다. 조금 더 보태자면 작업 구성원 모두에 적합한 협업 도구로서의 위키, 그리고 이번 과제의 최종 결과물인 마크다운으로 변환을 수월하게 할 수 있었던 위키 시스템의 구조적 특징에 대해 살펴보고자 합니다. 엄밀히 말하자면 이번 이야기는 위키를 포함하고 있는 컨플루언스 (참고2) 시스템 관한 것입니다.
2. “컨플루언스”는 호주 소재 아틀라시안 회사의 콘텐츠 기반 협업 툴입니다. 이 글은 이 컨플루언스 시스템 사용을 바탕으로 작성했으며, 여기서 사용한 “위키” 또는 “위키 시스템”은 컨플루언스 시스템에 포함된 위키 언어 기반의 편집기를 말합니다. “위키피디아”와 같은 백과사전식 위키와 컨플루언스 내 위키는 편집 방법은 동일하지만 문서 구조화와 관련한 기능상의 차이가 있기 때문에 구분할 필요가 있습니다.
gulpe
MD Div.
마크다운이라는 최종 산출을 위한 기술적 사안은 이미 해결했거나 곧바로 대응 가능한 인력과 노하우를 보유하고 있었기 때문에 이번 과제 진행에 있어서는 아래 3가지를 해결하는 것이 시급했습니다.
- 협업을 위한 원고의 작성 툴 선정
- 고객 및 내부 담당자 간의 실시간 데이터 공유와 원활만 커뮤니케이션
- 보안성 확보
첫째, 원고 작성을 어디에서 어떤 형식으로 하는 것일 좋을까?
[실태]
- 홈페이지 오픈이 머지 않았다. 즉 작업 기간은 짧다.
- 한 문서 내에 기획, 영업, 전문 기술, 정책 등 다루어야 하는 분야가 많고, 그만큼 라이터도 많다. 그러나 편집기를 다루는 능력은 천차만별이다.
- 주로 MS-Word와 같은 위지윅 기반 에디터에 익숙해져 있다. 마크다운 문법이 쉽고 단순하다지만 낯설다.
- 라이터가 마크다운 문법을 직접 적용한다는 것은 휴먼 에러 발생 가능성을 내포하고 있다.
[요구]
- 위지윅 기반으로 작성이 쉬워야 한다.(위키 문법3, 마크업/다운 문법 비교)
(그렇다면, 모두에게 익숙한 Office 제품을 사용하면 되지 않을까? 주 에디터로 채택하지 않은 이유는 아래 둘째 항목의 [실태]를 참고하세요.) - 그리하여, 편집 수준이 다양한 라이터가 작업하더라도 결과물로서 문서 구조는 동일해야 한다.
- 문서 구조가 동일해야 마크다운 변환(파싱)이 용이하고, 에러 발생을 줄인다.
3. 위키 문법도 마크다운 문법만큼 쉽습니다. 또한, 위키는 MS-WORD와 같이 위지윅 기반으로 문서를 작성할 수 있기 때문에 문법을 직접 인용할 필요가 없습니다.
컨플루언스 위키 편집 화면 [화면 출처: curvc]
둘째, 라이터, 엔지니어 등 여러 담당자가 실시간으로 데이터를 확인, 수정, 공유하려면?
[실태]
- 실시간 공동 작업을 위해서는 기존 혹은 현재의 통상적인 작업 프로세스인 “로컬 에디터(Office)
메일(배포) 리뷰 취합 메일 로컬 에디터(Office)”는 비효율적이다. - 위 사이클은 작업 시간도 오래 걸리고, 메일 수신 누락 등으로 제시간에 실제 담당자에 전달되지 않을 수 있다.
- 문의 발생 시 담당자에게 전달하기 위한 문서를 생성해야 하고, 또는 메일에 직접 문의하고 답을 받았을 때는 수많은 메일에서 일별/주제어 등으로 일일이 찾아야 한다.
[요구]
- 작업 일정, 공지, 첨부 데이터, 문서 버전 등 한 공간에서 파악할 수 있어야 한다.
- 문서가 변경(수정, 삭제, 이동, 질의 응답)되면 메신저나 메일로 실시간 알림을 받을 수 있어야 한다.
- 문서가 버전별로 관리되어 작업 히스토리 파악이 쉬워야 한다. 가능하면 이전 버전으로, 이전 버전에서 최신 버전으로 복원도 가능해야 한다.
한 프로젝트 내에서 일정, 라이팅(편집), 데이터 공유, 알림, 찾기를 모두 처리할 수 있습니다. [화면 출처: atlassian]
각 상황별 피드백도 쉽게 주고 받을 수 있습니다. [화면 출처: atlassian]
셋째, 이외에도 사용자 접근 제한 등을 통해 보안을 확보하려면?
협업, 파싱, 변환, 보안, 사후관리 등 작업 시에 요구되는 이 모든 사안을 고객과 한샘 담당자 모두에게 충족할 수 있는 것이 바로 위키를 사용하는 것이었습니다. 이미 언급했지만 실제적으로는 “위키피디아”와 같은 통상의 백과사전식 위키 편집 시스템이 아닌 콘텐츠 기반 협업 시스템인 “컨플루언스”입니다. (참고4)
4. 컨플루언스는 위에서 소개한 기능 외에도 매크로 확장(플러그인), 타 시스템과 연동 등 막강한 기능을 가지고 있습니다. 그만큼 라이선스 구입비와 유지 보수비가 너무 비싼 게 단점입니다.
여기까지가 고객과 협의를 통해 위키(컨플루언스)를 원고 작성 툴로 선택하게 된 배경입니다. 어떤 과제가 발생하면 일반적인 “오피스-메일-오피스”라는 단방향성 프로세스만 따를 것이 아니라, 필요에 따라 복수 담당자의 동시 작업을 고려한 협업 시스템을 사용을 시도해 보는 것도 좋을 것 같습니다.
덧붙여, 이처럼 협업을 위해 위키(컨플루언스) 사용이 최선 선택이기도 했지만, 실제 담당자로서 관심은 위키(컨플루언스)에서 작업한 문서가 최종 결과물인 마크다운 문서로의 변환이 과연 용이할 것인가에 있었습니다. 물론 이 작업은 시스템개발팀의 몫이지만…(이미 성공적으로 마무리했음을 서두에 밝혔습니다.^^)
이 관점에서 컨플루언스 시스템에서 눈여겨 볼 만한 부분은, 프로젝트의 페이지 구성을 최종 결과물인 문서의 차례(H1, H2, H3, H4 …)와 동일하게 구성할 수 있다는 점입니다. 마크다운 생성(파싱)이나 홈페이지 퍼블리싱 시, (종이)책 출판 문서 생성 시 이 구조를 그대로 가져와 활용할 수 있습니다. 시스템개발팀 담당자도 이와 같은 페이지 구조화가 마크다운으로 변환할 때 정말로 많은 도움이 되었다고 합니다. 참고로 위키피디아와 같은 일반적인 위키에서는 페이지 계층화가 지원되지 않습니다.
컨플루언스 페이지 구조 그대로 다른 문서로 변환할 수 있습니다. [화면 출처(일부분 캡처): atlassian]
또한 워드로 내보내고 수정 후 시스템으로 가져오기가 용이해 온라인과 오프라인을 오가며 작업할 수 있습니다. 이러한 컨플루언스 시스템 특징을 잘 살린다면, 인디자인과 같은 출판 전문 툴 수준까지는 아니겠지만 시스템상에서 동시 작업이 필요로 했던 작업을 마침과 동시에 종이/웹 출판이 가능한 수준의 문서로 편집하는 것도 기대해 볼 수 있을 것 같습니다.
