Your web-browser is very outdated, and as such, this website may not display properly. Please consider upgrading to a modern, faster and more secure browser. Click here to do so.
엔하 위키니 미러니 뭐니 하면서 난리통이 벌어지는 근본적인 이유는 엔하위키 서비스가 불안정하고 느렸기 때문이다.
엔하위키가 기반하고 있는 위키 엔진인 모니위키는 엔하위키의 규모를 수용하기에 적합하지 않다. 중소규모의 위키 서비스를 운영하기에는 부족함이 없지만 일정 이상 규모를 수용하기에 확장성(scalability)에 대한 대비가 잘 되어 있지 않기 때문이다. 모니위키 기반 사이트 중에서 엔하위키 다음으로 크다는 노스모크도 항목의 수는 7500개 정도로 엔하위키(19만 개)에 훨씬 못 미친다. 엔하위키의 규모가 계속해서 커지면서 모니위키의 확장성에 대한 문제가 불거지게 된 셈이다.
서비스의 처리 능력을 올리는 방법은 두 가지가 있는데, 하나는 scale-up이고 다른 하나는 scale-out이다. scale-up은 시스템 하나의 성능을 더욱 이끌어내는 방향으로 전개된다. 예를 들면 서버의 CPU를 더 좋은 것으로 바꾸거나 메모리를 더 많이 단다거나 서버 소프트웨어를 최적화하는 방식이다. 가장 간단하다. 서버의 성능이 좋으면 처리 능력이 높아지는 것은 당연하기 때문이다. 반면 scale-out은 서버 대수를 늘리는 식으로 처리 능력을 높인다. scale-up이 수직적 확장이라면 scale-out은 수평적 확장인 셈이다. 하지만 어떤 서비스든 단지 서버 더 갖다 놓는다고 바로 효과를 볼 수 있는 건 아니다. 소프트웨어가 여러 대의 서버에 부하를 분산시킬 수 있도록 설계되어 있어야 하기 때문이다.
모니위키는 여기서 문제가 발생한다. 수많은 설치형 PHP 소프트웨어가 그렇지만 모니위키 역시 한 대의 서버에서 동작하는 것을 전제로 만들어졌다. 모니위키의 수평적 확장을 가로막는 가장 큰 장애물은 모니위키의 파일 기반 DB 시스템이다. 모니위키는 DBMS가 아닌 자체적인 파일 기반의 DB를 사용한다. 그러다 보니 인덱스가 없어서 전체 문서 목록을 직렬화(serialize)해서 파일로 저장시켜 놓고 매 요청마다 그걸 다시 읽어들이는 비효율적인 구현도 있고 DB 성능을 전적으로 IO 캐쉬나 파일 시스템 성능에 의존해야 하는 등의 문제도 있지만 일반적인 DBMS처럼 간편하게 복제(replication)나 샤딩(sharding)을 통해 확장할 수 없다는 점도 문제다. 즉 DB 자체나 DB에 걸리는 로드를 수평적으로 분할할 수 있는 장치가 없다는 거다. 그리고 DB 쓰기 작업을 트랜잭션 단위로 묶을 수도 없기 때문에 파일 시스템 기반의 lock으로 동시성 제어를 해야 하는 문제도 있다. 즉 모니위키를 수평적으로 어떻게 확장하더라도 DB를 현재 시스템처럼 하나의 공유 자원으로 놓으면 병목이 발생하게 된다. DB도 수평적 확장이 가능하도록 모니위키의 DB 시스템을 전면적으로 뜯어고치더라도 구현에 드는 코스트나 리스크가 클 것이다. (사실 DB 확장이 필요할 정도로 DB 부하가 많은지는 모르겠고 정확한 건 직접 재어 봐야 알겠지만 엔하위키의 성능 문제에 DB가 차지하는 비중이 크다고 예상하고 있다)
엔하위키는 지금처럼 (조금 느리긴 해도) 한 대의 서버로 유지될 수도 있다. 하지만 서비스의 규모는 계속해서 불어나고 있고 게다가 미러가 제 구실을 못하게 되면서 추가적인 트래픽이 더 유입될 수도 있다. 엔하위키에 대한 사람들의 관심이 갑자기 확 꺼지지 않는 한 언젠가 한계가 올 거라는 말이다. 그럴 경우 더 좋고 비싼 서버로 호스팅을 옮기는 선택지가 있을 수 있겠지만 역시 한계가 올 것이다. scale-out을 하자니 소프트웨어를 적합한 구조로 전면적으로 뜯어고쳐야 한다. 그럼 어떻게 하는 것이 좋을까? 모니위키는 개발자 wkpark님이 거의 혼자 관리하고 계시는데다 2010년 이후부터 그다지 활발하게 개발되고 있지는 않은 것 같다. 원 개발자의 도움이 없는 상황에서 기존 구조를 크게 뜯어고치지 않고 고쳐 써야 한다면 캐싱을 적극적으로 활용하게 만드는 것이 좋은 방법이 될 수도 있다. 보니까 기본적인 위키 포매팅에 대한 캐싱부터 없던데 거기서부터 캐싱을 통해 IO나 CPU 부하를 줄여 나가면 어느 정도 효과가 있을 듯.
딴 얘기긴 하지만 현재 벌어지고 있는 일과 관련해서 엔하의 여론은 지나치게 감정적이라 이성적인 논의를 할 수 있는 상황이 아닌 듯하다. 엔하 쪽에 하고 싶은 말은 많지만, 이거 하나만 지적하고 싶다. 클리앙 등 몇몇 사이트서 억측을 퍼뜨려 엔하에 대한 비난 여론을 만들고 있다고 여기는 듯한데 (그중에는 엔하 미러 측에서 그 여론을 몰고 있다고 보는 시각도 있지만 어불성설) 엔하 미러를 차단하든 말든 상호 간에 논의를 훨씬 원만하게 진행할 방법도 많았을 텐데 엔하는 지금까지 미러 측의 문의를 무시하고 일방적으로 크롤링을 차단하면서 쓸데없이 일을 키워 왔다. 일을 이런 식으로 처리하는데 억측이 안 생기기를 바란 건가?
7 notes
Google이 Reader 서비스 중단한다고 발표하면서 한바탕 폭풍이 일었다. 사실 나도 오래 써 온 입장이고 Google의 결정에 배신감을 느끼면서도 한편으로 그렇게 할 수 밖에 없었던 이유가 있지 않을까 하고 생각해본다.
사실 나는 RSS 리더의 포맷 자체에 회의적이다. 돌이켜보면 RSS 리더는 노이즈가 많다는 점에서 트위터와 비슷했다. 처음에 지인 내지 관심있는 뉴스 사이트와 블로그들을 하나하나씩 구독하기 시작한다. 하지만 구독 수가 많아지면서 순식간에 감당이 안 될 정도로 포스팅의 홍수가 불어나버리기 시작한다. 모든 정보에는 노이즈가 있는 법. 나는 RSS 리더를 쓰면서 어느새부터 정보와 노이즈를 골라내는 노동(?)에 피로를 느끼기 시작했다. 결국 RSS 리더 본연의 기능이 아닌, 관심있는 특정 블로그에 새 글이 올라왔는지 여부를 보는 정도로 제한적으로만 활용하게 되었다.
사실 나만 이런 것도 아닐 것이다. 우리의 시간은 한정되어 있고 현대 사회는 정보 과잉의 시대이기 때문이다. 결국 제대로 활용하려면 구독 수를 제한적으로 유지하거나 스스로 정보에서 노이즈를 걸러 내야 한다. 등록한 피드를 모두 취합(aggregate)해주는 RSS 리더는 과연 매체로서 일정 이상의 가치를 전달했다고 평가할 수 있을까? 그나마 가장 많은 사용자들이 사용했다는 Google Reader의 운명을 보면 아닌 것 같기도.
2 notes
이라는 내용으로 트위터와 페이스북에 글을 썼다. 일부러 자극적인 제목을 달았는데 (악의는 없다!) 조금 더 부연할 필요가 있을 것 같다. 혹시 ‘멍청한’이라는 표현에 기분 상하셨다면 사과드린다. 사실 개인적인 불평에 기반한 분석이긴 하지만 실제로 많은 개발자들이 저지르고 있는 잘못된 관행(practice)이기도 하다. 그러므로 혹시 스마트폰 앱 개발을 하고 계신 분이라면 주의깊게 읽어 주셨으면 좋겠다. 스마트폰 앱이라고 했지만 개인적으로 안드로이드 플랫폼에서 개발을 하고 있기 때문에 안드로이드를 기준으로 한다.
별 기능도 없는데 용량 10MB씩 넘어가는 앱
사실 간단한 이유다. 덩치가 크지 않고 기능도 간단한 앱이 용량이 비정상적으로 많은 것은 UI 요소의 대부분을 이미지 파일로 만들었기 때문이다. 이는 [텍스트를 이미지 안에 박아넣은 앱]의 문제와도 관련이 있다. 더불어서 앱을 장식하는 것은 자유지만 많은 사용자들이 여전히 내장 메모리가 256MB가 채 되지 않는 스마트폰을 사용하고 있다는 사실을 상기할 필요가 있다.
백 버튼을 누르면 종료하겠냐고 물어보는 앱
백 버튼의 동작을 재정의하면 시스템의 일관성을 해치기 때문이다. 안드로이드의 GUI 가이드라인에 따르면 정말로 필요한 경우가 아니라면 백 버튼의 동작을 바꾸지 말라고 권고하고 있다. 사실 백 버튼 뿐만이 아니다. 기본 동작이 맘에 들지 않는다고 하더라도 바꾸지 않는 것이 좋다. 해당 플랫폼 위에서 동작하는 어플리케이션들 간의 공통적인 약속이기 때문이다. 시스템의 맥락을 이해해야 좋은 앱을 만들 수 있다.
텍스트를 이미지 안에 박아넣은 앱
불필요하게 텍스트를 이미지 파일로 박아넣으면 여러가지 문제가 생긴다.
앱의 용량이 커진다. 일반 텍스트로 구현할 수 있는 것을 비트맵 이미지로 넣어버리면 앱의 용량이 커지게 된다. 위에서 말했다시피 앱의 용량은 가능하면 작게 유지하는 것이 좋다.
국제화(internationalization)가 힘들어진다. 만약 앱의 지원 언어를 추가해야 한다면 똑같은 이미지에서 텍스트만 바꾼 비트맵 이미지를 하나 더 만들어야 한다. 즉 또다시 앱 용량의 증가로 이어진다.
결정적 문제. 이미지 안에 포함된 텍스트는 시스템의 접근성(accessibility) 프레임워크가 접근하지 못한다. 주요 모바일 OS들은 시각 장애인을 위해 화면에 표시된 텍스트를 TTS(Text-to-speech)로 소리내어 읽어주는 접근성 기능을 탑재하고 있다. 하지만 텍스트를 이미지로 만들어버리면 시스템은 그것을 읽어줄 수가 없게 된다. 당신의 앱을 시각 장애인이 이용할 수도 있다는 사실을 잊으면 안 된다.
(한국어, 영어 막론하고) 맞춤법 개판인 앱
앱의 품격이 떨어진다. 웃음거리가 되거나 심하면 AYBABTU 같은 밈(meme)이 될 수도 있다. 최소한 맞춤법 검사기 정도는 돌려보는 것이 좋지 않을까. 전세계를 대상으로 런칭하는데 영어에 자신이 없다면 주변의 영어 능통자에게 도움을 받는 것이 좋다.
특정 해상도 전용 앱
여러 해상도에서 테스트하지 않았거나 의도적으로 특정 해상도 이외를 배제하는 경우. 앱을 디자인함에 있어서 특정 해상도에 맞추는 것은 절대적으로 피해야 할 행동이다. 다양한 해상도와 디스플레이 밀도로 이루어져 있는 플랫폼 생태계를 정면에서 부정하는 것이나 다름없다. 여러 해상도를 고려해서 앱을 디자인하는 것이 기본적인 원칙이다.
이 외에 iOS로 만든 앱의 UI를 안드로이드에도 똑같이 적용하는 행위를 개인적으로 좋아하지 않는다. 각 플랫폼마다 UI 철학이 다르고 가이드라인의 차이가 있다. 그런데 하나의 OS에 맞춰진 UI 스타일을 다른 플랫폼에 일률적으로 적용하는 것은 옳지 않다고 생각한다. 안드로이드의 UI 가이드라인에서도 그러지 말라고 명시하고 있기도 하고. 일전에 최재형 님이 컨벤션을 적용할 수 없다면 차라리 제 3의 길을 찾는 것이 낫다고 이야기하신 적이 있는데 개인적으로 여기에 강하게 동의한다.
결국 하고 싶은 말은 이거다.
플랫폼마다 존재하는 GUI 가이드라인은 위에서 언급한 문제를 피하기 위해서 설계되었다. 심지어 가이드라인은 워딩(wording) 규칙까지 정의하고 있기도 하다. 사실 GUI 가이드라인만 잘 지켜도 절반 이상은 간다고 생각한다. 물론 당신의 앱의 아이덴티티도 중요하지만 그것은 플랫폼의 맥락 안에서 고려되고 적용되어야 한다고 본다. 일관적이고 하자 없는 사용자 경험이야말로 무엇보다 중요하다.
3 notes
Page 1 of 4
