¶ 23권 — 지식관리시스템 자체 구축하기: SaaS에서 자체 Wiki로
← 시리즈 로드맵 목차 · ↔ 1권과 짝을 이루는 심화 트랙
Confluence 같은 SaaS 위키의 한계가 드러날 때 자체 구축 위키(XWiki/Wiki.js/Outline)로 전환할지 판단하고, 실제 이관·운영 원칙을 다룬다.
¶ SaaS Wiki의 한계는 언제 드러나는가
한계는 크게 네 지점에서 나타난다.
- 비용 구조(사용자 수·저장 용량 단위 과금)
- 데이터 주권과 규제 준수
- 커스터마이징과 벤더 종속
- 보안 통제 범위(망분리·VPN 전용 접근 등)
이 네 신호 중 두 개 이상이 뚜렷하면 전환을 구체적으로 검토할 시점이다.
¶ 어떤 자체 Wiki를 선택할 것인가
세 프로젝트는 성격이 뚜렷이 다르다.
| 제품 | 특징 | 적합한 상황 |
|---|---|---|
| XWiki | 페이지 안에 구조화된 데이터를 저장하고 서버 사이드 스크립트로 확장 가능 | 세밀한 권한 체계와 상용 지원이 필요한 전사 규모 조직 |
| Wiki.js | Docker·Node.js로 손쉽게 설치, Markdown 중심 편집과 Git 연동 | 개발팀 중심의 가벼운 운영 |
| Outline | 실시간 공동 편집 경험과 미니멀한 UI가 강점 | 라이선스가 BSL 1.1이라 상업적 이용에는 제약 있음 |
¶ 구축과 이관 절차
Confluence에서 이관할 때 XML·HTML 내보내기는 페이지 트리와 첨부파일을 보존한다. 하지만 이관 전에 다음과 같은 손실·제약을 반드시 인지해야 한다.
- 사용자 계정 정보가 포함되지 않아 작성자 이력이 그대로 넘어가지 않는다.
- 세밀한 권한 체계가 대상 플랫폼에 동일하게 매핑되지 않는다.
- 매크로·레이아웃은 깨지거나 단순 텍스트로만 남는다.
권장 절차는 다음 여섯 단계다.
- 활성 스페이스 우선순위 매기기
- 1~2개 스페이스로 시범 이관
- 권한 그룹 매핑표 수립
- 자동 변환 후 사람이 검수
- 병행 운영
- 검증 완료 후 전환 공지
¶ 이관 이후 운영 원칙
이관 이후에는 다음 운영 원칙을 지킨다.
- 권한은 그룹 단위로 관리하고, "명시적으로 허용하지 않으면 거부"하는 화이트리스트 방식으로 사고를 줄인다.
- 템플릿은 반복되는 문서 유형별로 미리 만든다.
- 스페이스마다 담당자를 지정한다.
- 분기 1회 이상 오래된 문서 점검일을 정례화한다.
¶ 라이선스·비용 비교
| 제품 | 라이선스 | 비용 특징 |
|---|---|---|
| XWiki | LGPL v2.1 | 완전한 오픈소스, 라이선스 비용 없음 |
| Wiki.js | AGPLv3 | 완전한 오픈소스, 라이선스 비용 없음 |
| Outline | BSL 1.1 | 상업적 이용 시 계약·법무 검토 필요 |
| Confluence Data Center | 자체 호스팅형 유료 라이선스 | 2026년 3월 신규 판매 종료 예정 |
Confluence Data Center의 신규 판매 종료는 XWiki·Wiki.js 같은 순수 오픈소스 대안의 상대적 매력을 높이는 배경이 된다.
¶ 참고할 만한 사례
한화그룹은 사내 플랫폼(HONE)의 관리자·사용자 가이드 문서 체계를 XWiki 기반으로 운영한다. 해외 ITSM 기업 EasyVista는 위키 서버 손상·백업 실패 경험 이후 관리형 지원을 조건으로 XWiki를 선택해 공개 지식베이스를 운영하고 있다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.