종이상자의 작은일기장(1st)

Firefox

6개 발견
Firefox for Android 56을 기점으로, 파이어폭스가 조금씩 새 옷을 입기 시작했습니다. 그 시작은 로고였는데, Aurora와 Nightly가 통합되면서 새로 디자인된 Nightly의 로고였습니다.

위 처럼 생겼습니다. 기존 파이어폭스보단 새련되고, 꼬리가 강조된 느낌이 듭니다. 불여우 뒤로 바로 직전 Nightly 로고가 그려져있는 건 덤입니다.
그러던 Nightly가 아예 새롭게 다시 디자인되면서 많은 부분이 변했습니다. 다만 일부 요소는 남이있습니다.

위 화면은 디스플레이 크기를 작게로 설정하니 나타난 태블릿 UI입니다. 오직 파이어폭스 모바일에서만 디스플레이 크기를 작게 했을 때 태블릿 모드가 됩니다.
일단 검색어 및 주소 입력 창이 너비가 작아졌고, UI가 전체적으로 약간 하예졌으며, 탭이 각지게 변했습니다.
탭 관리 버튼도 달라졌는데, 회색 바탕에 글씨에서 바탕이 사라지고 검정색 테두리에 검정 글씨로 변경되었습니다.
그 외에도 자잘하게 요즘 UI로 변신한 모습입니다.
그런데 아직 Nightly 홈의 파비콘은 구버전 Nightly입니다.
(그건 그렇고 탭 페이지에 있는 여우가 너무 귀엽지 않나요?)

탭 페이지는 그대로인데 테두리가 주황색에서 파란색이 되었습니다. 색을 잘못 골랐는지 제 눈에는 이전이 훨씬 낫네요. 사생활 보호 탭은 여전히 보라색입니다.

검색/주소 탭은 좁아져서 이런 원래 휴대폰인 기기에선 쓰기가 꽤나 불편해졌습니다. 기능상의 변화점은 없습니다.

로딩 바는 움직이도록 바뀌었습니다. 더 빨라보이고, 더 시원한 느낌을 주는 게 인상적입니다.

여전히 HTML5TEST는 485점이네요. 참고로 PC는 490점이고 무슨 영문인지 이제는 ACID3 Test를 97점으로 통과합니다.(구버전에선 100점이었습니다.)

무튼, 이번 개편은 Aurora-Nightly 채널 통합을 기념하기도 하지만, 어떤 의미로는 Project Quantum(Servo 엔진의 일부 결과물을 Firefox에 적용)의 효과를 조금 더 보기 위한 자축일지도 모르겠습니다. 하지만 저번 Nightly 버전 중 하나는 크롬처럼 앱에서 바로 넘어가면 In-APP 탭을 지원하다가 사라진 적이 있는 걸 보면 여전히 모질라는 파이어폭스 UI에 대해 고민이 많은 것으로 보입니다.
앞으로 얼마나 변화할지, 어떻게 변화할지는 모르겠지만 여전히 응원해주고 싶은 브라우저입니다.

* 본 글은 매우 주관적으로 작성되었으며 영어 철자 오류 등 다양한 오류를 내포하고 있을 수 있습니다. 이런 오류에 관해서는 댓글 및 트위터 멘션으로 알려주세요. 빠른 시일 내에 고치겠습니다.
저작자 표시 비영리
신고
댓글 로드 중…

블로그 정보

고1의 시선으로 본 IT, 일상, 그리고 여러가지 이야기들.

최근에 게시된 글

2017년 4월 17일, 모질라 재단이 릴리즈 채널에 관한 중대한 변화사항을 발표했습니다.

ⓒ2017 Mo://a(Mozilla Foundation). From Mozilla Hacks.
Firefox 채널은 기존에 다음과 같은 절차로 출시되었습니다.
Nightly → Developer Edition(모바일 버전은 더 이전처럼 Aurora) → Beta / RC→ Release
그런데 이렇게 될 경우 Chrome과 비슷하긴 하지만(크롬의 경우 Canary → Dev → Beta → Release) 여전히 여러 버전을 챙겨줘야 하기도 하고, Developer Edition의 안정성이 떨어지는 문제점이 있었습니다.
사실 개인적인 입장에선 그다지 안정성이 떨어지진 않았는데요, 공식 입장은 그렇습니다. 따라서 추측으로써 하나라도 채널을 줄이고자 했던 것 같습니다.
왜냐하면 이제 다음과 같아지거든요.
Nightly(이전의 Aurora) → Beta & Developer Edition(별도로 분리. 하지만 이제 개발자 에디션이 Beta 기반이며 Aurora를 대체하지는 않습니다.) / RC → Release
그래서 이제 예전의 Nightly는 사라지게 되었습니다.

그러면서 Nightly가 Play스토어에 Aurora를 대체하며 나오게 되었고 명칭도 이전버전(↓)인 Nightly와는 달리 앞에 Firefox가 들어갔습니다.

패키지명은 신 Nightly가 org.mozilla.fennec_aurora
구 Nightly가 org.mozilla.fennec입니다.
따라서 구 Nightly는 자동으로 신 Nightly로 업데이트되지 않습니다.

같은 Firefox Nightly이고 버전도 똑같이 55a1이지만, 실제 구 Nightly 채널의 업데이트는 2017년 4월 30일까지만 이루어 졌고 이후 구 Aurora 채널로 이관되어 별도 앱이 되었습니다.

그런데 4월 30일 빌드가 6월 9일 빌드보다 불안정합니다.(-_-;;) 아무래도 곧 수정되겠지만, 앞으로 Aurora였던 Firefox의 안정성이 어떻게 될지가 심히 궁금해 집니다.

아무튼, 이번 결정이 좋은 변화로 기록되기를 바랍니다.

* 오류, 지적등의 사항을 댓글 및 트위터 멘션으로 받고 있습니다. 언제든지 자유롭게 지적해주세요.
저작자 표시 비영리
신고
댓글 로드 중…

블로그 정보

고1의 시선으로 본 IT, 일상, 그리고 여러가지 이야기들.

최근에 게시된 글

처음 웹 브라우저의 시대를 연 건 누구도 부정하지 않는 '모자이크'이겠죠. 이게 발전을 거듭하고 거듭한 결과가 Trident 엔진 및 EdgeHTML이라는 것을 생각하면 상상이 가실 지 모르겠습니다.(아, 물론 Microsoft사에서 모자이크 엔진을 사용하여 Internet Explorer를 팔 때 마다 로열티를 주기로 했지만 무료로 뿌려서 한 푼도 못 받았다는 이야기와, Internet Explorer 6.0에 실려있던 Based on 'Mosaic' 문구에 근거해 이야기 하는 겁니다. 어쨌든 IE 엔진의 근간은 Mosaic와 깊은 연관이 있고 Microsoft Edge의 근간은 IE 웹 렌더링 엔진인 Trident 엔진이니까요.)
아무튼 모자이크 이후 Netscape가 등장하고, Microsoft Internet Explorer가 등장해 Netscape를 반 쯤 죽여놓는(;;) 동안 Netscape는 자신의 웹브라우저를 오픈소스화 해 Mozilla Application Suite를 제작하도록 만듭니다.
이 과정에서 Mozilla 재단의 연구진들이 발로 짠 듯한 소스코드에 경악, 대대적으로 뜯어고쳤다는 이야기도 유명한 이야기죠.
그러다가 Netscape는 저물고 새로운 브라우저 경쟁의 시작은 Firefox가 올렸습니다. 그 전에도 KHTML(컹커러 - K Desktop Environment의 웹 브라우저 프로그램이었던 프로그램. 현재는 KHTML의 한계로 qtWebkit을 사용한 ReKonq가 기본 프로그램입니다. 아마 Redifined + 컹커러 라는 작명센스가 아닐까, 조심스럽게 추측해 봅니다.) 기반의 컹커러 계열 웹 브라우저나 Presto 기반의 Opera  브라우저는 있었지만 그 당시에나 지금에나 KHTML은 덜그덕 거리면서 간신히 돌아가던 렌더링 엔진이라 경쟁상대는 커녕 목숨부지도 힘겨운 상황이었고, Opera 브라우저는 여전히 소수의 마니아들이 좋아하는 웹 브라우저임을 고려하면 Firefox가 확실히 한 역할 했다고 볼 수 있겠죠.
Firefox의 어느 버전은 기네스북에 '가장 많이 다운로드 된 웹 브라우저'로 기록된 것으로 기억되는데, 그 때가 막 Google 등 타 업체들이 웹 브라우저 개발에 나설 때였던 것 같습니다.
그러나 이렇게 기네스북 기록까지 세우던 Firefox는 어느 인터넷 회사빠르고 강력한 웹 브라우저가 출시되면서 점유율도, HTML 5 반영 속도도(심지어 HTML5를 논의하게 된 계기가 Firefox를 비롯한 새 브라우저들의 웹 표준 논의였고 이 선봉장이 Firefox였음을 생각하면 안타까운 일입니다.) 느려지고, 속도까지 따라잡지 못하는 상황에 가장 낡은 엔진인 Gecko(Opera는 Presto를 버린 대신 Google이 Webkit에서 포크한 Blink를 사용하고, Chrome은 Webkit에서 포크한 Blink를 만들어 쓰고, Safari는 기존 Webkit을 크게 바꾼 Webkit2를 만들어 사용중이며 마지막 남은 IE 조차 Windows 10을 통해 Gecko보다 오래된 Trident를 완전히 뜯어고친 EdgeHTML을 사용합니다. 즉, Gecko는 큰 뜯어고침 없이 개발되어 왔음을 보면 다른 모든 브라우저에 비해 오래된 엔진입니다.)을 사용하면서 그 느린 엔진에게 브라우저 처리까지 맡기는 등, 발목이 줄줄히 잡히는 상황이 오게 됩니다.
그러다가 결국 Mozilla 재단은 살아남기 위해 Webkit, EdgeHTML 브라우저들과 같은 멀티 프로세싱 및 샌드박스 효과(혹은 기능)이 추가된 e10s 프로젝트를 시작합니다.
하지만 오래된 Gecko의 코드는 싱글 프로세싱에 최적화 되어 있었기에, 축적된 많은 코드들을 멀티 프로세싱에 맞게 바꾸는 것은 쉽지 않은 작업이 되었습니다. 오래된 코드, 부가기능 호환성, 여러가지 새로운 트랜드나 개발 편의성에는 좀 뒤떨어지는 프로그래밍 언어... 이런 많은 것들이 발목을 잡습니다.
그럼에도 불구하고 모질라 재단은 불굴의 의지로 e10s 완성에 거의 성공합니다.
현재 거의 적용되어 있으며 곧 완성될 예정인 것으로 알고 있습니다.
* 1~2년간 이 e10s에 집중하기 위해 많은 부수 프로젝트들인 Persona, Shumway등을 중단했을 지도 모르는 일 입니다.
e10s가 마무리 단계이기 때문에 곧 있으면 타 브라우저들의 속도도 어느정도 따라잡는 등 여러가지 이점을 조금씩 발휘해 나가고 있음에도 이들의 도전은 끝이 아닙니다.
이번엔 아예 자신들이 자체 제작한 프로그래밍 언어 Rust를 만들고 이를 바탕으로 Servo라는 브라우저 엔진을 개발하게 됩니다.

△ 2017년 1월 7일에 캡쳐한 Servo 공식 누리집. 2016년 7월의 렌더링 결과가 나와있습니다. ©2014-2017 Servo Project, Mozilla Foundation.
Servo는 삼성전자도 관여하고 있으며, Mozilla측은 나중에 이 결과물 일부를 Firefox에 적용해 속도를 비약적으로 향상시킬 것이라고 합니다. 이름은 Project Quantum.
한국의 모 텔레콤 회사의 5G 슬로건인 Everything is Alive - Quantum과는 다른 이야기입니다.
이 Servo는 Rust 프로그래밍 언어의 완성이 늦어지면서 덩달아 늦어지기도 했고, 한 두달 정도 개발이 안되던 시기도 있었으나 우여곡절 끝에 Servo Nightly가 mac OS와 Linux 한정으로 배포되었습니다.

△ Servo의 Nightly 배포 페이지. Windows 및 Android의 버그트래커 링크가 살포시 걸려있습니다. 참고로 Servo 웹사이트 하단에서 볼 수 있는 Servo Blog 링크를 통해 그 주의 변경점 등을 알 수 있으며 Feed 구독도 가능합니다. ©2014-2017 Servo Project, Mozilla Foundation
Windows용의 경우 제가 썼을 때는 렌더링이 완료된 직후 하얗게 변하거나 키보드 입력이 느린 문제, Servo에 적용된 browser.html이 제대로 작동하지 않는 문제가 있긴 했지만 기존 Firefox에 비해 좀 빠른 속도와(현재의 Firefox와 비교해도 빠릅니다. 심지어 Firefox Nightly보다도요. Github 웹사이트를 가지고 비교했습니다.) 정작 Firefox로 열어본 Browser.html의 UI를 보고 이 브라우저는 출시만 되면 인기를 끌 가능성이 있다고 보았습니다.
그건 그렇고, 어째 남의 브라우저에서 새 브라우저 UI를 볼 수 있다는 게 재미있습니다. 예시에선 Firefox라 같은 재단 소속이라고 치고, Chrome에서도 실행이 됩니다.
역시 HTML로 만든 UI라 그럴까요. 파일 자체 확장자가 .html 이던데요.
아무튼 당시의 문제들은 거의 해결이 되어서 2017.01.07 토요일 기준으로 체크리스트 내의 버그들은 모두 해결했다는 표시가 붙어있습니다.
시간이 되면 다시 설치해 봐야겠습니다.
(참고로 해당 스레드에서 msi 설치파일을 제공합니다. 아직 불안정한 만큼 실행에 시간이 걸리니 인내심을 가지고 커피 한 잔 드시고 오세요. 대신 실행 후 속도가 빠르다는 점에서 등가교환같다는 생각은 덤입니다.)
Android용은 Samsung Internet Browser(그러니까 갤럭시 제품군에 사용하는 인터넷 브라우저)에 들어갈 예정이라는 소문도 돌았었는데요, 그에 비해 Servo의 Android용 개발은 Windows용에 비해 많이 진척도가 떨어져보입니다. 일단 Browser.html(UI)의 모바일 용 개발이 되어있지 않고, 일부 기능은 Native API, 즉 Android 자체 API를 써야만 가능하다는 문제점이 있어 개발이 지연되는 측면도 있는 모양입니다. 현재 Servo 개발자들이 공식으로 올린 Servo Apk 파일을 이용해 실행해 보면 곧이어 강제종료된다는 사실만 알 수 있을 뿐입니다. 게다가 버그 리스트에 보면 키보드 지원도 안 됩니다.
Windows 버전은 버그 수정이 꾸준히 진행된 결과 곧 있으면 mac OS, Linux와 같이 Nightly 배포 페이지에 공개될 것만 같지만, Android용을 만나보는 것은 좀 더 시간이 지나야 겠죠?

오늘은 차세대 브라우저 렌더링 엔진인 Servo(서보)에 대해서 알아보았는데요, 앞으로 Servo가 완성되어 모두 앞에 당당히 Chrome보다 빠른 브라우저로써 모습을 보였으면 좋겠습니다.


 * 본 글은 Mozilla의 공식 입장과는 관련이 없으며, 주장 및 글 세부 보충설명 중에 오류가 있을 수 있어 공신력있는 정보는 아니니, 인용 등 참고시에는 가급적 타 사이트를 이용해 주시고 혹여나 정확히 알고 있는 사실이나 덧붙이고 싶으신 내용이 있으면 트위터 멘션 및 댓글로 알려주시면 수정하겠습니다.(물론, 수정시 출처는 남기겠습니다.)
저작자 표시 비영리
신고
댓글 로드 중…

블로그 정보

고1의 시선으로 본 IT, 일상, 그리고 여러가지 이야기들.

최근에 게시된 글

Mozilla Support는 그동안 Mozilla Firefox, Firefox OS, Firefox Marketplace 및 Mozilla Focus(iOS용 광고차단 프로그램), Webmaker 등 다양한 Mozilla 제품군에 대한 도움말을 제공해 왔습니다. 번역은 대부분 자원봉사자들 몫이였지만 그동안 별 문제 없이 많은 사람들에게 소소한 도움이 되는 도움말이었죠.
그런데 이 Mozilla Support의 플랫폼이 옮겨질 예정이라고 합니다.
여기까지는 별 문제가 없었습니다. Mozilla 제품군을 번역하는 일을 맡는 프로그램이 Pontoon(정확하지는 않습니다.)으로 바뀌면서 조금 더 편리해지는 등 '자원봉사자'를 위한 플랫폼으로 변화했다는 선례가 있어 다들 문제가 없으리라 생각했습니다.
오히려 개선될 것이라고 생각했겠죠. 하지만 공헌자 포럼에 올린 vesper 씨의 글에서 사람들은 불안감을 느끼게 되었습니다.
- 새로 옮기는 플랫폼의 사용선례를 볼 때 기존 포럼보다 느리다는 점
- 자원봉사자들이 활동하기 어려운 플랫폼이라는 점
- 기존 플랫폼에서 개선되는 점이 있는 지 의구심이 드는 개편이라는 점
등의 문제점이 계속해서 여러 기여자에 의해 제기되고 있습니다.
한 사용자는 근거로, 자신의 ISP(Internet Service Provider)가 게시판을 새로 바꿀 시스템으로 변경했는 데, 이전보다 느려졌다며 속도 문제가 우려된다고 지적했습니다.
또 어떤 사용자는 현재의 플랫폼인 Kitsune이 공헌자에게는 더 편하다며 새 플랫폼에 대한 거부반응을 보여주기도 했습니다.
물론, 새 플랫폼이 좋고 나쁘고는 직접 수정 후 도입이 되어야 알 수 있는 부분이겠지만, 일방적으로 자원봉사자들의 생각을 무시하고 진행한 부분은 분명 일 처리에 있어 문제가 있는 부분입니다.
더군다나 Mozilla Support는 영어 외 타 언어에 대해 대부분 자원봉사자가 도움말을 번역한다는 점에서 훨씬 치명적입니다.
최악의 경우 자원봉사자들이 떨어져 나가면서 번역이 업데이트가 안되고, 유용하지 않은 도움말이 될 가능성도 높아집니다.
저 또한 1명의 자원봉사자로써 걱정이 됩니다.
현재 옮길 예정인 시스템의 DEMO를 살펴보니 번역 도구에 대한 어떠한 내용도 없고, 편집 조차도 불편해 보였습니다.
어떤 사용자는 다시 SVN, Git와 같은 repository 기반 저장소에 번역을 업데이트하는 식의 방식으로 되돌아가는 것이기 때문에 반대한다는 내용도 있었던 걸로 보아(위 링크된 스레드와는 달리, 새 플랫폼 적용시 어떤 점을 개선해야할 지 묻는 스레드가 따로 있습니다.) 방식도 구형, UI는 신형, 속도는 구형보다도 못함이라는 웹밖에 모른다는 재단이 생각한 방법일 것 같진 않은 결과가 나왔기에 다들 반대하고 있는 듯 합니다.
주로 외국의 자원봉사자들이 반발하고 있다는 점에서, 국내 모질라 커뮤니티에서의 움직임도 필요할 것으로 보이며
이들의 반발에 Mozilla가 뒤로 한걸음 움직일 수 있을 지가 관건입니다.
개인적으로 인력 지출을 줄이려는 Mozilla가 한 걸음 물러나 편리한 방법으로 Mozilla 재단에 기여하는 그 날이 왔으면 좋겠습니다.
* 본 주장은 오류, 문제점등을 다수 내포할 수 있으며 이에 대한 문의는 댓글로 부탁드립니다. 감사합니다!
저작자 표시 비영리
신고
댓글 로드 중…

블로그 정보

고1의 시선으로 본 IT, 일상, 그리고 여러가지 이야기들.

최근에 게시된 글

지금으로부터 약 5년 전(그러니까 공교롭게도 제가 티스토리 블로그를 열게되는 그 시점 즈음에) 플래시를 HTML5로 변환한다는, 꿈이 커보이는 한 프로젝트가 시작했습니다.
하지만 플래시는 독점기술인데다가 이미 있는 오픈소스 플래시 플레이어들은 모두 한 두개씩 나사가 빠진듯한 모습을 보여주곤 했습니다. 즉, 참조 조차 힘들었다는 거죠. 물론 HTML5로 변환해내는 것이 목표이니 좀 많이 다르지만요.
그럼에도 불구하고 굴지의 Mozilla는 그렇게 유지가 힘들다는 그 프로그램의 유지보수를 해내더니, Shumway도 3년 간 계속 개발했습니다. 그것도 꾸준히.
그러나 2013년 경 불거진 플래시의 랜섬웨어 문제.

출처: 나무위키
이로 인해 모질라 측도 고민을 거듭합니다. 하지만 랜섬웨어 문제가 본격적으로 어도비 플래시 환경에서 문제가 된다는 내용이 공론화 된 건 2015년입니다.
그 때 즈음 해서 Windows에선 플래시를 Windows Update 패키지와 Internet Explorer에 기본탑재해버려서 더 공론화 되기 쉬운 환경이었죠.
그렇게 플래시 퇴출 운동이 시작되고, 어도비 사도 플래시를 비권장하게 됩니다.
물론 Google Chrome, Mozilla Firefox 측도 플래시 컨텐츠의 재생을 제한하겠다는 입장을 밝혔었죠.
이 과정에서 보안 취약점이 많은 플래시를 굳이 개발도 난항을 겪는 Shumway로 대체시킬 필요 없이, 곧 퇴출운동에 따라 많은 플래시 컨텐츠들이 사라질 거라 예상했기에 Shumway가 개발중단될 수 있지 않았나 싶습니다.
하지만 우리나라의 웹 환경 특성상 아쉬운 사람이 더 많겠죠. 외국에도 그런 분들이 꽤 계셨나 봅니다.
Shumway 공식 깃허브 에서도 4월10월 두 차례에 걸쳐 프로젝트의 생사 여부를 묻는 글이 올라왔습니다.
이에 답글을 잘 살펴보면 '아니었으면 좋겠네요'부터, 팩트폭격 관련된 기사를 찾아주시는 분도 보입니다.
하지만 그러한 염원에도 Bugzilla에 등록된 'Mozilla Gravyard'로 이전하는 이슈 글을 보면 Shumway는 현재  Mozilla의 제품 개발 우선 순위에서 밀려나 있고, Mozilla  공식 깃허브에는 소스코드가 남아 있겠지만, 현재 열리는
Issues 들을 처리할 생각이 없다.
라고 답했습니다.
즉, 플래시 퇴출운동 시작→모질라 재단 내에서 제품 개발 우선순위가 뒤로 밀림→개발중단의 절차를 거치게 되었다는 것인데,
'지금은' 우선순위가 뒤로 밀려있다는 것이기에 올해 다시 개발될 가능성 또한 있습니다.
왜 올해 냐면, 2017년 Adobe가 Linux용 플래시 플레이어에 대한 지원을 종료한다고 밝혔기 때문입니다.
그러니 아직 일말의 희망은 있음을 생각해서,
글 제목처럼 '끝내' 버리지 않기를 바랍니다.

* 본 글은 그저 의견을 이야기할 뿐인 글입니다. 다만 잘못된 논리, 오류 등 다양한 지적을 받고 있으니 언제든 댓글 / 트위터(@lego37yoon) 멘션 부탁드립니다.
저작자 표시 비영리
신고
댓글 로드 중…

블로그 정보

고1의 시선으로 본 IT, 일상, 그리고 여러가지 이야기들.

최근에 게시된 글

지지난 해[각주:1] 모질라 썬더버드가 모질라 재단에서 분리된다는 소식이 ZDNet 코리아를 통해 국내에 전해졌습니다. 그 뒤 보드나라에서는 모질라 썬더버드가 아예 중단 될 가능성 또한 커 보인다는 이야기도 했었죠.

모질라 썬더버드는 어쩌다가 이렇게 궁지에 내몰리게 된 걸까요? 원인을 추측해 보았습니다.

* 본 내용은 어디까지나 자료 등에 근거한 '추측' 글일 뿐입니다. 따라서 해당 내용을 너무 믿지는 마시길 바랍니다.

일단, 이메일(E-mail, 전자우편) 시장 자체는 줄거나 늘지 않았습니다. 그저 현상 유지만 되고 있는 상황이지요. 물론 2010년 대 이후 모바일 시장을 공략하게 되면서 my.com과 같은 모바일 전용 메일 서비스도 등장하고는 있지만, 그것이 추세가 되지는 못했습니다. 실제로 그나마 알려진 서비스는 방금 전 언급한 my.com 뿐입니다.

다만 원래부터 이메일 시장은 그렇게 큰 시장도 아니었고, 많은 업체도 경쟁할 필요가 없었기에 서비스가 늘어나는 것 보다는 현재 현존하는 서비스들 끼리 메일 클라이언트와 서버를 개선하는 데에만 몰두하거나 메일 서비스를 하지 않는 기업들은 이메일 앱을 만들면서[각주:2] 모바일 시장에 대응했습니다.

하지만 원래 PC 시장에서 비지니스 작업에 주로 이용되었던 이메일이 모바일 시장으로 옮겨가면서 PC 시장에서 이메일 클라이언트의 필요성은 낮아졌습니다. 게다가 HTML 5 등 웹 시장의 발전으로 웹 클라이언트 들도 엄청나게 발전하여 굳이 이메일 클라이언트를 사용할 필요성도 떨어졌습니다.[각주:3] 그렇다 보니 아예 시장 자체가 엄청나게 축소가 되버렸는데, 모바일 시장이 발전되는 동안 Mozilla Thunderbird는 모바일용 Firefox처럼 모바일용 메일 앱을 만들지 않았습니다.

그렇다 보니 Mozilla Thunderbird는 여전히 Linux, Mac, 그리고 Windows용 메일 클라이언트로만 남아있게 된 겁니다.

그나마 다행인 것은 Windows 용 이메일 클라이언트가 거의 전멸에 가까운 시점에서 남아있는 거의 유일한 유명 이메일 클라이언트 이기에 Windows 시장에서는 어느정도 버틸 수 있으리라 생각된다는 점입니다.

정작 오픈소스 재단의 일반적인 상황 상 Linux용 지원이 활발하기 때문에 Windows 보다는 mac os, Linux 쪽에 주력하게 되어 포화된 시장에서 경쟁하는 것이 부담감으로 작용할 수 밖에 없긴 하지만요.

실제로 Mozilla 재단 측도 현재 Mozilla Thunderbird의 개발이 재단의 세금(즉, 부담이 된다는 의미)과 같은 존재라고 말했으며, Servo 코드 부분 적용 및 e10s 등으로 새로운 도약을 준비하는 Mozilla Firefox와는 달리 적은 Thunderbird 개발자와 기여자들로는 그런 새 기능을 집어넣을 시간조차 없어 Gecko 엔진의 변경점을 따라가는 데에만 거의 모든 시간을 투자하고 있어 비효율적이라고 생각한다고 했습니다.

이는 제가 보기에도 비효율적인 구조입니다. 어떤 메일 앱도 Webkit 변경점을 따라가느라 기능이나 UI를 제대로 개선하지 못하는 앱은 거의 없습니다. [각주:4] 이래서는 차라리 이러한 변경점을 조금 늦게 따라가는 한이 있더라도 제대로된 메일앱을 만드는 것이 더 낫죠. 모질라 재단 측도 그렇게 생각했던 모양입니다.

물론 보시는 분에 따라, Mozilla Thunderbird가 현재 ESR(장기 지원 채널)로 옮겨갔고, 정책을 변경해서 멋진 메일앱을 만드는 데 집중한다면 재단 내에서도 별 문제가 없지 않을까, 하고 생각하시는 분들이 더 많을 거라고 생각합니다. 사실 이 부분이 저도 그렇게 잘 이해되지는 않아서 글을 쓴 거고요. 그러나 아마 모질라 내의 개발자들은 해당 변경사항을 따라가야 보안에도 취약하지 않고 더 빠른 로딩속도를 가진 메일 앱을 만들 수 있기 때문에 이러한 결정을 내리지 않았나 싶습니다. 당장은 Mozilla Thunderbird 코드에 기여 및 주관할 개발자가 별로 없으니까요.

이를 보시고 Mozilla Thunderbird에 더 많은 개발자를 할당하면 안되냐는 질문이 올 수 있지만, Mozilla 재단은 현재 Firefox OS, Shumway, Persona 등 많은 서비스를 중단하면서까지 Firefox의 새 버전 개발에 총력을 기울이고 있는 상황입니다. 왜냐하면 Firefox가 점점 요즘 세대 브라우저에서 뒤쳐지고 있기 때문이죠. 아무리 멋지구리하고 잘 돌아가는 확장기능이 있더라도, 사람들의 요구를 충족시키지 못하는 웹 브라우저는 사용하는 사람이 없을 테니까요. 프로그램 시장에서 점유율은 TV 시청율과 거의 같다고 보시면 될 것 같습니다. 물론 취미로 만드는 프로그램은 예외이지만, 적어도 거대한 오픈소스 프로젝트에 있어서는 사용하는 사람이 많아야 그 프로그램의 버그를 알고 고친다던지, 유지보수가 수월해지기 때문에 이게 중요한 편입니다. 아무튼 그러한 이유로 Mozilla 내에서 Thunderbird를 개선하고 주도할 개발자가 적은데, 새로 고용하기에는 Mozilla 재단에 한계가 있습니다. 비영리 단체인 만큼 모금과 Firefox 내 탑재된 약간의 광고, 굿즈, 후원 등으로 재단을 유지하고 있기에 계속해서 개발자를 영입할 수는 없는 노릇입니다.

이런 한계점에 달한 시점에서 Thunderbird 재단을 별도로 분리하게 되면 Mozilla 재단 내 한계점에서 벗어날 수 있게 되고, 조금 더 여유있는 비영리 재단에 들어가 개발 진척 속도를 올릴 수 있습니다. 또한, Mozilla 재단 스스로에게도 Thunderbird를 신경 쓸 필요가 없으니 Firefox, Webmaker 등의 개발, 지원에 총력을 기울일 수 있어 도움이 되죠.

그런 의미에서 재단 분리 소식은 (한 편으로는 조금 아쉬운 이야기 이지만) 기대가 되기도 하는데요, 새로운 재단 산하에 들어가거나 새 재단을 만든 후에는 OpenOffice가 다시 살아나듯 다시 옛 유명세를 되찾기를 기원합니다.


* 초보자 주제에 감히 글을 적은 터라 오류도 많고, 억지스러운 주장도 들어있을 것으로 생각됩니다. 언제든 댓글로 지적 바랍니다. 감사합니다.


  1. 2015년 [본문으로]
  2. 예를 들면, Dropbox의 Mailbox(지원 종료.), 다음의 쏠메일(추후 다음 메일 앱과 동일한 UI를 가지게 되긴 했지만, 여전히 독립 메일 앱입니다.) 등. [본문으로]
  3. 사실 웹으로 만든 이메일 클라이언트 들이 너무 강력해진 탓에 PC용 이메일 클라이언트를 만들 필요성이 없어진 것이 가장 큰 이유입니다. 모바일에서는 여전히 건재하다는 것이 그것을 보여주고 있죠. [본문으로]
  4. Mozilla Thunderbird는 Gecko엔진(Firefox의 웹 렌더링 엔진)을 사용하지만, 대부분의 메일 앱은 기껏해야 Webkit 내지 Blink 엔진을 사용합니다. [본문으로]
신고
댓글 로드 중…

블로그 정보

고1의 시선으로 본 IT, 일상, 그리고 여러가지 이야기들.

최근에 게시된 글

티스토리 툴바