미디어위키

미디어위키

미디어위키의 로고.
미디어위키를 사용 중인 영어 위키백과의 대문 페이지
개발자	위키미디어 재단, 미디어위키 봉사자
발표일	2002년 1월 25일(2002-01-25)
안정화 버전	1.37.1
운영 체제	크로스 플랫폼
플랫폼	PHP
크기	최대 37MB
언어	445개 언어
종류	위키 소프트웨어
라이선스	GPLv2+
웹사이트	MediaWiki.org

미디어위키는 PHP 언어로 제작된 위키 소프트웨어이며, 이곳 L위키를 포함하여 전 세계적으로 많은 위키에 절찬리에 쓰이고 있는 위키엔진이다.비록 최적화, 관리용이성 등 부족한 점이 꽤 존재하지만 미디어위키 특유의 강력함을 뛰어넘는 엔진은 없다고 보면 된다. 이점은 개인위키 보다는 서비스형 위키에서 잘 드러난다.

미디어위키의 최초 버전은 2002년에 자유 콘텐츠 위키백과 백과사전의 요구를 충당하기 위해 이용되었다. 그 뒤로 내부 지식경영을 위한 저작물 관리 시스템으로서 수많은 회사들이 이용하기 시작했다. 특히 노벨은 이를 이용하여 트래픽이 높은 웹사이트 일부를 운영하고 있다. 수 천개의 웹사이트들이 미디어위키를 사용하고 있다. 일부 교육인도 협업 그룹 프로젝트를 위해 학생들에게 미디어위키를 이용하게 하고 있다.

미디어위키는 700개 이상의 구성 설정과 더불어 사용자가 세미클론 빠뜨리면 에러떠서 사이트가 터지는 설정 파일을 건드리면서 세세한 부분을 변경할 수 있으며하지만 미디어위키 설정 변경하는건 귀찮다 1,800개 이상의 확장 기능을 이용하여 다양한 기능을 추가하거나 제거할 수 있다. 600개가 넘는 자동화, 반자동화된 봇 프로그램과 기타 도구들이 개발되고 있으며 이는 미디어위키 사이트들의 편집을 도와 준다.

역사

매그너스 맨스케

위키백과가 2001년 1월 처음 시작했을 때에는 펄로 작성되었고 모든 위키 문서를 텍스트 파일로 저장하는 위키 소프트웨어 유스모드위키를 이용하여 구동되고 있었는데, 기능과 성능상의 한계를 느꼈다. 그래서 2001년 중순에 쾰른 대학교의 학생이자 개발자이며 위키백과 편집자이기도 했던 매그너스 맨스케(Magnus Manske)는 위키백과의 이용에 적합하면서, 유스모드위키를 대체할 새로운 소프트웨어의 개발에 착수하였다. 이 소프트웨어는 PHP로 작성되었고 모든 정보를 MySQL 데이터베이스에 저장하였다. 2002년 1월에 영어 위키백과에 포함된 뒤 당시 모든 언어의 위키백과에 점차 적용되었다. 이 버전의 소프트웨어는 제 2단계(phase II)로 불렀는데, 이는 제 1단계인 유스모드위키를 대체하는 것이다.

사용량이 늘면서 문제가 다시 불거지자 곧이어 리 대니얼 크로커(Lee Daniel Crocker)가 제3단계(Phase III) 소프트웨어를 작성하였다. 이 새로운 소프트웨어 또한 제2단계와 마찬가지로 MySQL 백엔드를 포함한 PHP로 작성되었으며, 제2단계 소프트웨어의 기본 인터페이스는 유지하되 더 나은 크기 조절을 가능케 했다. 이 버전은 2002년 7월까지 유지되었다.

위키미디어 재단은 2003년 7월 위키백과 기여자 대니얼 메이어(Daniel Mayer)가 "위키미디어"에 빗대어 미디어위키(MediaWiki)라는 이름을 이 소프트웨어에 사용할 것을 제안했다고 발표하였다.

미디어위키 개발의 혁신적인 부분들이 분류 시스템에 포함되어 2004년에 추가되었다. 구문 분석 기능이 2006년에 추가되었다. 플래그 리비전이 2008년에 추가되었다.

미디어위키의 과거 로고

미디어위키의 과거 로고는 플로랑스 드부아르가 찍은 꽃 사진을 에릭 묄러가 이용하여 제작하였으며, 이 로고는 원래 2003년 중순에 개최된 새로운 위키백과 로고를 위한 국제 로고 콘테스트에 제출된 것이었다. 이 로고는 3위를 차지하면서 위키백과 대신 위키미디어를 대표하도록 선정되었으며, 2위에 들어선 로고는 위키미디어 재단에 사용되었다. 해바라기 사진 주변의 이중 대괄호는 미디어위키가 다른 위키 문서로의 하이퍼링크를 이용하는데 쓰이는 문법을 상징한다.

미디어위키의 기존 로고는 비트맵 형식의 이미지라 대형 포스터 등 큰 크기에 사용하기 곤란한 문제, 사실적인 이미지라 작은 크기에서 사용할 수 없는 문제, 이미 다양한 스타일로 사용되어 기념일 로고 등에 사용하기 위한 로고 변형이 어려운 문제 등 여러 문제가 제기되었다. 또한, 2010년대 후반부터 디자인 트렌드는 머니멀리즘이 되었는데, 그에 반해 미디어위키의 로고는 사실적인 디자인이라 요즈음의 디자인 트렌드에 맞지 않는 부분이 있었다. 그래서 위키미디어 프로젝트 이용자들을 대상으로 새로운 로고를 공모했으며, 공모전 끝에 현재의 로고로 로고를 변경하기로 확장지었다. 마침내 한국 시간 기준 2021년 4월 1일(...) 만우절에 정보상자에 나와있는 현재의 로고로 로고가 변경되었음을 발표하였다.

확장 기능

이 부분의 본문은 미디어위키/확장기능입니다.

미디어위키의 강력함을 드러내는 핵심. 확장기능을 통해 미디어위키는 더욱 강력해지며, 확장 기능을 많이 사용한 위키 사이트는 기능 면에서 강력한 기능을 보여준다.

라이선스

미디어위키 소프트웨어 자체는 GNU 일반 공중 사용 허가서 버전 2 이후 버전에 따라 배포되는 자유 및 오픈 소스 소프트웨어이다. 미디어위키 공식 홈페이지에 있는 관련 문서는 대부분의 위키미디어 재단 계열 위키가 그렇듯 크리에이티브 커먼즈 라이선스 BY-SA 3.0 및 일부 퍼블릭 도메인으로 배포된다. 미디어위키 개발은 일반적으로 오픈 소스 미디어 포맷의 이용을 선호한다.

확장 기능의 경우 확장 기능 각자의 라이선스가 있으며, GPL로 배포되는 경우도 있지만, MIT 라이선스 등 GPL 보다 더 느슨한 라이선스로 배포되는 경우 또한 존재한다.

장점

강력한 기능

기본적으로 현재 공개되어 있는 위키 엔진 중에서 강력한 기능을 제공하며 확장기능을 통한 확장성 또한 뛰어나다. 게다가 부족한 기능이 있으면 확장기능을 사용하여 넣으면 된다. 결과적으로 많은 서비스 지향 위키가 미디어위키를 사용하고 있으며 L위키도 예외는 아니다.

한국어 지원

프로그램 자체의 한국어 지원 또한 좋은 편이다. 거의 모든 UI가 번역된 편이며, 확장기능도 위키미디어 관활 확장기능 같은 경우에는 번역이 잘 되어 있다. 특히 위백같은 위키미디어 관활 위키에 사용하는 확장기능의 경우 한국어화가 평타 이상은 잘 되어 있을 가능성이 높다. 한국어 위키백과의 이용자들이 번역에 참여하기 때문.

단점

문법의 복잡함

미디어위키의 위키 문법은 HTML 태그에서 파생된 문법이 많으며, 한술 더 떠서 직접 HTML 태그를 써야하는 경우 또한 존재한다. HTML 마크업의 복잡함을 극복하기 위해 만든게 위키 마크업인데 미디어위키는 일부에서는 여전히 HTML 태그를 쓴다. 특히, 미디어위키의 표 문법은 직관적이지 않기로 악명높다. 오죽했으면 표 문법을 생성해주는 사이트까지 나왔다 간단한 표야 어찌어찌 작성이 되겠지만, 셀 합치기 같은 고급 적인 기능을 사용하게 되면 답이 없다. 특히나 고급 적인 기능에 해당하는 문법은 전부 영어라서 한국인이 외우기 힘들다.

L위키에서 표를 만드는데 어려움이 있다면 시각 편집기를 사용하거나 전술한 표 생성기를 이용하자.

위키백과 등의 미디어위키 사이트에서는 틀 등을 이용해 복잡한 문법 문제를 커버하고 있다.

한줄 강제 개행 문제

한줄 강제 개행이 빈번하게 일어나는 한국 인터넷 환경에서 주로 발생하는 단점. 미디어위키는 한줄 강제 개행을 개행으로 인식하지 않으며, 두줄 개행만 개행으로 인식한다. 물론 <br>태그를 쓰면 한줄 강제개행이 되지만, 번거로운건 사실. 위지위그 에디터인 시각편집기 또한 엔터를 한번 누르면 두줄 강제개행이 되며 한줄 강제개행을 원한다면 원본 편집에 가서 수정해 주어야 한다.

관리자 페이지의 부재와 그로 인한 골때리는 관리 용이성

미디어위키의 강력한 관리 기능을 부정할 수는 없지만, 관리 용이성이 상당히 골때린다. 관리 페이지를 제공하는 XE 등과는 다르게 미디어위키는 일관된 관리 페이지를 제공하지 않는다. 엔진의 설정은 LocalSettings.php 일명 로컬셋팅 파일에 의존하는데 설정 파일을 잘못 건드리는 순간 에러가 나는 위키를 볼 수 있을 것이다.특히 끝에 실수로 세미클론 빼뜨렸을때 사용자 권한 그룹을 추가하거나 제거하는 등의 행위는 로컬셋팅을 건드려야 하며 확장기능도 로컬셋팅에서 확장기능을 호출을 해줘야 한다.

시스템 메시지 또한 미디어위키 이름공간에서 수정을 해주는 방식인데 하는데 어떤 미디어위키 문서가 어떤 역할을 하고 싶은지 보고 싶다는 우선 메뉴얼 부터 정독해야 하는데 영어가 안될 경우 참 곤란해진다. 물론 이건 타 위키의 사용 방식을 보고 흉내내면 어느정도 커버가 되겠지만...

일반적인 관리 행위를 할때도 마찬가지. 사용자 차단, 관리자 등 특수 문서에서 관리를 하는 방식인데 이게 일단은 특수 문서 이름을 외우고 있어야 한다. 이용자를 차단할 경우 XE는 관리자 페이지를 뒤져서 차단이라는 메뉴를 찾아 차단하면 되지만, 미디어위키는 특수:차단 문서를 일일이 찾아서 이용자들을 차단해야 한다.

또한 미디어위키는 성능 최적화가 영 좋지는 않아, 예산은 적은데 서버는 자원은 빡빡하게 먹는 사이트 서버 관리자의 유지보수를 골떼리게 한다. 당장 미디어위키 업그레이드로 인해 물 먹은 사용자 또한 있을 정도.

성능 문제

미디어위키는 PHP라는 프로그래밍 언어로 만들어진 엔진인데 PHP는 인터프리터를 사용한 언어라서 태생상 성능이 썩 좋지 못한 언어이며, 게다가 미디어위키 엔진 자체도 강력함을 대가로 성능을 희생하는 형태로 만들어져 있다. 게다가 미디어위키를 제대로 사용하려면 몇개의 확장 기능은 사실상 필수이며, 위키백과를 흉내내어 강력한 기능의 위키를 만들고 싶다면 두자릿수 넘는 형태의 확장기능을 떡칠해야 하는데, 당연히 확장기능을 많이 설치할 수록 프로그램이 무거워진다. 그렇다고 확장기능 없이 깡통으로 사용하기에는 기능상 문제로 거의 불가능한 수준. 위키의 필수 기능인 각주 기능조차 확장기능으로 뺀 엔진이 미디어위키이며, 그 외 스팸 방지를 위해 필요한 캡챠나 악성 다중계정 사용자를 잡아내는데 필요한 체크유저 기능 또한 확장기능이다. 악성 사용 방지를 위해 토르 IP 편집을 막아주는 기능 또한 확장기능이고...

이 때문에 미디어위키는 캐싱 기술을 사용하여야 한다. 당연히 미디어위키 최적화 가이드에 캐시를 사용하라는 말이 빠지지 않고 나오며, 위키미디어 서비스 또한 Memcached, Varnish 등 각종 캐시 기술을 떡칠해서 운영하고 있다.

X-Forwarded-For 인식 문제

CDN 등을 쓰는 환경에서 생기는 문제로 X-Forwarded-For(이하 XFF) 헤더의 맨 앞은 보통 클라이언트 IP가 오는 것이 정석이고, 따라서 이를 클라이언트 IP로 인식시켜야 하지만 미디어위키는 XFF의 맨 앞을 클라이언트 IP로 인식하지 않는다. 미디어위키가 XFF를 읽는 방식은 맨 뒤에서 부터 읽는 것으로 보이며, 다만 설정 파일에 입력된 IP 주소와 대역은 건너뛴 다음 클라이언트 IP를 확정하는 방식이다.

이는 CDN이나 varnish 같은 리버스 프록시 등을 쓰는 사람한테는 불편하기 짝이 없는 방식이다. XFF의 맨 앞의 인식하지 않고 제멋대로 맨 뒤를 인식하니 설정 파일에 관련 값을 집어넣지 않으면 무조건 CDN이나 서버의 IP로 기록이 된다.

이런식으로 X-Forwarded-For를 처리하는 것은 X-Forwarded-For 헤더 스푸핑 공격 때문이다. 이 때문에 보안을 위해서는 맨 뒤에서 읽은 다음 신뢰할 수 있는 IP면 앞으로 가고 그렇지 않으면 해당 IP를 진짜 IP로 처리하는 방법이 쓰이며, 미디어위키도 이 방법을 채택했을 뿐이다.

기타

• Common.js 등에 넣은 자바스크립트는 리소스로더를 걸러내진 다음 출력이 되는데, 1.35 버전 이하에서는 구형 자바스크립트 문법 기반이라 ES6 등의 최신 문법 지원이 안되었다. 1.36 버전부터 리소스로더가 최신 자바스크립트를 지원하게 되었다.

외부 링크

• 미디어위키 홈페이지
• (영어) 미디어위키 소스포지더 이상 사용되지 않는다. 현재 미디어위키는 자체적으로 운영하는 깃 저장소를 통해 관리되며, 미러 목적의 깃허브 저장소가 있다.
• (영어) 개발자인 위키미디어 재단이 제공하는 미디어위키 안내
• (영어) 미디어위키 개발 블로그

참조주

이 문서의 일부 내용은 한국어 위키백과의 미디어위키 29416827판에서 파생되었습니다.