Omeka 컨텐츠 업데이트 에러 및 수정사항 미반영 문제 관련

edited April 2014 in OMEKA
Omeka에서 컨텐츠를 등록한 이후에 수정해야 될 사항이 생겨서 등록한 이미지나 텍스트를 수정했는데 브라우져상에서 수정된 사항이 반영이 되지 않아서 난감한 경우가 있습니다.
이때는 사용 중인 브라우져를 새로고침해서 페이지를 refresh 갱신하면 변경 사항이 적용된 화면이 나타나지만 그렇지 않은 경우도 있습니다.
그런 경우에는 브라우져의 옵션에 들어가서 환경설정에서 캐쉬 지우기 또는 임시 인터넷 파일을 삭제하면 제대로 보일 것입니다.

브라우져들은 보통 한번 들어간 사이트의 이미지들을 브라우져가 설정한 캐쉬 설정값의 제한 범위 내에서 캐쉬 저장소에 임시 저장해서 계속 갖고 있습니다. 
만약 화면에서 보이는 이미지가 변해야 되는데 페이지를 이동해 봐도 그대로 있다면 그것은 브라우져가 이미 그 이미지를 캐쉬에 저장하고 있는 상태인 것입니다.

브라우져가 캐쉬 설정을 하는 것은 이미 들어간 사이트를 재방문시 접근속도를 더 빨리 해주기 위한 것입니다.
물론 글을 수정하거나 삭제, 이미지 파일의 명칭을 변경(ex: 1.jpg -> 2.jpg)한다거나 삭제하면 브라우져는 기존과 변화된 상황을 바로 체크해서 해당 내역이 화면에 바로 반영되어 나타나도록 설계되어 있습니다.
하지만 이미지 파일 명칭은 그대로인데 관리자가 해당 이미지를 수정해서 예전 명칭 그대로 서버에 업로드해서 덮어쓰는 경우엔 브라우져는 변화된 상황을 바로 인지하지 못하고 기존에 캐쉬된 이미지를 보여주게 됩니다.

그래서, 포털이나 대형 사이트들은 보통 웹프로그래밍시 사용자가 수동으로 리프레쉬를 하지 않아도 자동으로 페이지 리프레쉬가 되게끔 설계를 합니다. 이렇게 되면 사용자들은 페이지 이동시마다 리프레쉬된 화면을 보게 됩니다.
Omeka의 페이지 갱신 관련 문제가 Omeka만의 문제인지 아니면 Nginx의 문제인지는 좀더 검토를 해봐야 할 것 같습니다.

어쨌든 Omeka는 아직까진 개선해야 할 사항들이 생각보다 매우 많은 시스템이고 커스터마이징(customizing)을 해야 될 경우 발생되는 품도 생각보다 많이 들 수 밖에 없는 시스템입니다. 특히 설계는 반응형 웹으로 설계되었지만 스마트폰으로 확인한 결과 이미지 처리 방식과 기술력이 스마트폰 등에서 반응형 웹을 제대로 구현하고 있는 AtoM과 비교했을 때 Omeka는 과연 반응형으로 설계한 것이 맞나 싶을 정도로 이미지 처리 방식과 기술이 엉망인 부분이 보입니다.

Omeka는 시스템을 알면 알수록 불안한 면들이 속속 드러나고 있습니다.
일반 사용자들에게는 AtoM 보다는 Omeka가 더 다루기 불편하고 까다로운 시스템일 수 있어서 걱정입니다.
만약 어느 기관이나 단체가 Omeka를 쓰려고 한다면 많은 부분에서 커스터마이징이 필요하고 비용도 만만치 않게 들 것 같습니다.
만일 커스터마이징을 하지 않는다면 화면 구성도 Omeka에서 제공하는 기본 디자인 테마를 써야 하므로 아주 기초적이고 유치한 디자인을 감수해야만 합니다.
또, Omeka는 AtoM 처럼 사이트 관리자가 웹페이지 상에서 직접 화면 내용을 Translate 해서 원하는 언어로 보여줄 수 있는 도구 자체가 제공되지 않으므로 한글화 번역을 직접 시행해야 합니다. 
전체 번역을 하려고 한다면 그 전에 Omeka 시스템의 상세 구조와 기능을 알고 있어야 가능하므로 작업이 더 힘들고 오래 걸릴 수도 있습니다.
또한, 등록한 이미지들을 네이버의 사진 앨범 자료실처럼 근사하게 보여주고 싶다면 Omeka를 쓰겠다는 생각을 아예 접는 것이 나을 수도 있습니다.
그것을 커스터마이징하느니 시스템을 새로 만드는 것이 더 빠를 수도 있습니다. Omeka의 이미지 재처리는 제가 보기에는 걸음마 단계입니다. 현재는 작게 만들던가 크게 만들던가 하는 기초적인 수준일 뿐입니다.
전시/출판을 강조하고 있는 소프트웨어이면서도 이미지 재처리 같은 디테일한 부분은 왜 설계 단계에서 심각하게 고려를 하지 않았는지 의문이 듭니다.
Wordpress가 Omeka를 보면 "그저 웃지요"라고 할 것 같습니다.
게다가 더 큰 문제는 브라우져간의 호환성 문제입니다. Chrome/Firefox에서의 Omeka 화면과 Internet Explorer의 Omeka 화면은 전혀 같지가 않습니다. 이는 커스터마이징을 위해 CSS 관련 소스파일을 열어봤을 때 바로 알게 되었습니다.
css 구성이 IE에는 적용되지 않는 스크립트가 너무 많습니다.
예를 들어 Omeka에서 기본 설정한 어떤 수평 라인은 크롬이나 파이어폭스 화면에서는 잘 보이지만 IE에서는 도무지 보이지가 않습니다. 브라우져 버젼의 문제인가 해서 여러 버젼에서 확인해 봤지만 보이지 않거나 깨져서 나오는 경우가 많았습니다. 더 재밌는 사실은 IE 브라우져 버젼마다 천차만별의 화면이 나타났다는 점입니다. 
Wordpress가 좀 그런 경향이 있는데 대부분의 오픈소스 소프트웨어 시스템들이 크롬이나 파이어폭스를 쓰는 사람에겐 관대하지만 IE 쓰는 사람에게는 "아예 최신 버젼을 깔아서 쓰던가 아예 쓰지 말던가"라고 직접적인 표현은 하지 않아도 알아서 포기하게 만드는 경향이 강합니다.
여전히 Omeka를 이용해서 사이트를 구축하고 있지만 아무래도 현재 대부분의 사용자들은 IE를 사용하기 때문에 기본 CSS 방식은 IE에서 잘 표현될 수 있도록 구성하고 있습니다.

그저 더블린코어를 활용한 자료관리 및 이용 측면으로만 본다면 Omeka는 괜찮은 프로그램이긴 하나 전시/출판을 통해 이용자들에게 뭔가 느낌있고 강렬하게 어필하려고 한다면 아직은 시기상조인 것 같습니다.
Omeka는 앞으로 충분한 시간을 갖고 더 많은 버젼업을 하면서 더 많은 개선이 이뤄져야 정말 쓸만한 프로그램이 될 것 같습니다.

그리고, 웹기반의 여러 오픈소스 소프트웨어들을 접해본 결과 MS의 Internet Explorer(IE)는 정말 애물단지라는 것을 뼈져리게 느꼈습니다.
IE 6,7,8,9,10,11 모두 같은 회사에서 만든 같은 제품인데 버젼에 따라서 화면이 다르게 구현되는 IE를 보고 있으면 정말 욕이 절로 나옵니다.
예를 들어 Archivematica의 경우 크롬이나 파이어폭스에선 로컬 디렉토리 저장소 위치가 스크립트를 통해 구현되는데 IE에서는 에러만 발생할 뿐 나타나지 않습니다.
어쨌든 사용자들이 그냥 크롬이나 파이어폭스를 주 웹브라우져로 쓰면 한방에 문제가 해결되겠지만 대부분의 사용자들이 IE를 사용하는 상황에선 이를 무시할 수도 없어서 실무에서 난감한 점이 많습니다. 빅브라더는 그래서 참 무섭습니다.

오픈소스 진영의 노력은 예나 지금이나 여전히 다윗과 골리앗의 싸움입니다.
Atom, Archivematica, Omeka, Dspace 등등..
그것이 뭐던 간에 여전히 골리앗과 싸우고 있는 형국입니다.
Omeka가 MS처럼 영리를 추구하고 버젼별로 구입할 수 있도록 라이센스 정책을 도입했다면 이미 이러한 시스템상의 여러가지 문제점이나 오류들은 발견되지 않았을 것입니다. 그만큼 완전하고 완성된 모습으로 사용자들을 맞이했겠지만 그랬다면 더 이상 오픈소스일 수는 없을 것입니다.
오픈소스 무료 소프트웨어이기 때문에 갖고 있는 한계성은 우리가 이해해야만 할 것입니다.

현재로선 이들 오픈소스 소프트웨어들이 골리앗과의 싸움에서 매번 눌리고 있는 상황이지만 다윗의 수가 많아지면 많아질수록 골리앗과 전투할 수 있는 여건이 갖춰질 것입니다.
이는 모든 오픈소스 소프트웨어들의 숙명인 것 같습니다.






Comments

  • 위에서 설명한 Omeka는 Nginx 웹서버 기반하에서 테스트되었습니다. Apache에서도 테스트가 되는 대로 알려드리겠습니다.
Sign In or Register to comment.