- 회원들이 추천해주신 좋은 글들을 따로 모아놓는 공간입니다.
- 추천글은 매주 자문단의 투표로 선정됩니다.
Date | 16/03/24 17:06:08 |
Name | ![]() |
File #1 | stat.png (170.4 KB), Download : 34 |
Subject | 최근 국내 PC 웹브라우저 점유율의 변화 |
최근 2년간의 국내 PC 웹브라우저의 점유율을 살펴본다면? 첨부된 이미지와 같이 국내에서도 크롬의 점유율이 점점 높아지고 있는 상황입니다. 생각보다 크롬의 점유율이 꽤 높게 나오는 것 같지요? 34%에 육박하는 점유율 자체도 상당히 높지만, 그보다 중요한 것은 변화의 추이입니다. 1년만 지나고 봐도 점유율이 확 바뀌는 느낌이 정도로 빠르게 변화가 일어나는 추세입니다. IE8의 가파른 하향세도 눈에 띕니다. 이 추이는 Windows XP의 점유율 하락과 관계가 있습니다. XP에서는 IE9 이상의 버전 설치가 불가능하기 때문에 IE8 사용자가 많았거든요. 2014년 초에 IE10이 급격히 하락하고 IE11이 급격하게 올라가는 것은, Windows 사용자들의 자동 업데이트에 IE11이 탑재된 영향입니다. 언젠가부터 윈도우의 자동 업데이트에 IE가 포함되고 있기 때문에 IE9, IE10보다 IE11이 훨씬 많습니다. 사라지지 않고 오랫동안 남는건 IE7과 IE8인데, 7은 실제 사용자를 찾아보기가 거의 어렵고 최후의 보루인 IE8의 사용자는 꾸준히 줄어들고 있는 상황이라고 볼 수 있겠습니다. 위의 통계는 스탯카운터(http://gs.statcounter.com) 라는 사이트에서 가져온 것인데요. 세계적으로 꽤 공신력이 있는 사이트라고 할 수 있습니다. 이 분야의 양대산맥은 넷애플리케이션스(넷마켓쉐어)와 스탯카운터인데요. 넷애플리케이션스는 오랫동안 이 분야의 탑을 지켜왔지만, 외부에 데이터를 공개하지 않는 유료 서비스입니다. 반면에 스탯카운터는 새롭게 등장했고, 무료로 서비스하고 있기에 많이 인용되는 데이터지요. 통계 데이터도 꽤나 상이한 편입니다. 넷애플리케이션스에서는 통계가 보수적으로 잡히고, 스탯카운터에서는 파격적으로 잡힙니다. 넷애플리케이션스쪽은 변화의 추이가 너무 늦게 반영되는 느낌이고, 스탯카운터는 너무 앞서나가는듯한 모양새랄까요? 그러다보니 그 차이가 극명하게 드러나서 우스운 느낌마저도 듭니다. 2016-03-09 [베타뉴스] 마이크로소프트 IE와 엣지, 5월 구글 크롬에게 1위 자리 내놓나 (넷애플리케이션스 데이터 반영) http://betanews.heraldcorp.com/article/628600 2011-12-16 [IT World] 크롬 15, No.1 웹 브라우저 등극 : 스탯카운터 조사 http://www.itworld.co.kr/print/73318 둘 다 똑같이 크롬이 IE를 제치고 세계 1위 브라우저가 되었다는 내용인데, 하나는 기사작성이 2011년이고, 하나는 2016년입니다. 4년이 넘게 차이가 나네요 ㅎㅎ 이렇게 데이터의 수치가 다르기 때문에 입맞에 맞게 소스를 선택하시면 됩니다. IE의 통계가 높게나와야 유리한 경우라면 넷애플리케이션스 통계를, 크롬이 높게 나와야 유리하면 스탯카운터 통계를 쓰시면 되겠네요 ㅎㅎ 양사의 통계가 서로 다르긴 합니다만, 추이가 반영되는 시기가 다를 뿐 추이의 변화는 일치합니다. 그렇게 본다면 앞으로 넷애플리케이션스의 통계에서도 IE가 다시 크롬을 추월할일은 향후 4년간은 일어나지 않을 것이라는 점을 예상할 수 있습니다. 원래 브라우저 점유율의 변화는 오르내리거나 하지않고 꾸준하게 곡선을 그리는 편입니다. 특별한 일이 있지 않는 이상 사용자들의 패턴이 급격하게 변화하지는 않거든요. 위의 그래프의 곡선이 매끄럽지 않고 다소 거칠게 꺾이는 것은 스탯카운터의 국내 환경 수집 데이터의 양이나 정확도가 떨어지기 때문이라고 볼 수 있습니다. 이 때문에 아직까지도 스탯카운터의 국내 통계를 평가절하하는 분들도 있는데요. 사실 3년전만 하더라도 스탯카운터의 국내 통계는 신뢰하기 어려울 정도로 불안정하게 통계 데이터가 나타났습니다만 데이터 수집을 늘려가면서 지금은 상당히 믿을만한 데이터를 확보하고 있는 것으로 저는 생각합니다. 오히려 국내의 다른 통계기관들의 데이터가 더 신뢰하기 어려운 경우가 많습니다. 가장 이용량이 많은 상위 사이트중에 금융권, 쇼핑몰, 이통사, 정부기관 사이트가 포함되어있기 때문인데, 이런 사이트들은 ActiveX나 공인인증서의 사용으로 다른 브라우저를 쓰던 사용자들도 IE로 브라우저를 바꿔 접속하게 되기 마련이니까요. 이런 사이트들을 제외하고 데이터를 수집하지 않으면 통계의 결과가 왜곡됩니다. 그런면에서 본다면 실제 우리나라 사용자들의 실제 브라우저 점유율에 가장 근접한 통계를 가지고 있는 업체는 네이버, 다음, 구글일것으로 생각합니다. 구글은 데스크탑 사용자는 적기는 하지만 google analytics를 사용하고 있는 업체가 워낙 많으니까요. 홍차넷에서도 크롬의 점유율은 상당히 높게 나오는 편입니다. 최근 2개월 간의 홍차넷 브라우저 점유율 통계를 Google Analytics에서 보면 다음과 같은데요. ![]() 이 통계는 데스크탑 only 통계는 아니고 모바일과 통합한 통계라서 Safari가 높게 나옵니다. 아이폰 사용자들이 Safari를 쓰니까요. 모바일 크롬의 점유율도 크롬에 포함되어 있기는 합니다만, 그런걸 감안해서 보더라도 크롬이 상당히 높은 점유율을 가지고 있음을 볼 수 있습니다. * 수박이두통에게보린님에 의해서 티타임 게시판으로부터 게시물 복사되었습니다 (2016-04-01 10:48) * 관리사유 : 추천 게시판으로 복사합니다. 5
이 게시판에 등록된 Toby님의 최근 게시물 |
최근에 아톰 시피유 기반의 태블릿을 하나 구매했는데 램이 4기가 임에도 불구하고 윈도우에 크롬 브라우저 환경이면 정상적인 서핑이 되지 않는 수준의 퍼포먼스를 보여주던구요. 특히나 브라우저 상에서 동영상을 재생하는 상황이 오면 최악의 결과를 보여주었구요. 반면 익스플로러는 깔끔하게 돌아가는 상황이 나왔어요. 엣지는 아직 페이지가 제대로 표현이 안되는 사이트가 너무 많구요.
계속해서 평균 이상되는 컴퓨터만 써오면서 크롬을 쓰니 잘 몰랐던 부분이었던 것 같은데 크롬은 더 이상 빠르고 가벼움을 추구하는 브라우저는 아닌 것 같았습니다. 무... 더 보기
계속해서 평균 이상되는 컴퓨터만 써오면서 크롬을 쓰니 잘 몰랐던 부분이었던 것 같은데 크롬은 더 이상 빠르고 가벼움을 추구하는 브라우저는 아닌 것 같았습니다. 무... 더 보기
최근에 아톰 시피유 기반의 태블릿을 하나 구매했는데 램이 4기가 임에도 불구하고 윈도우에 크롬 브라우저 환경이면 정상적인 서핑이 되지 않는 수준의 퍼포먼스를 보여주던구요. 특히나 브라우저 상에서 동영상을 재생하는 상황이 오면 최악의 결과를 보여주었구요. 반면 익스플로러는 깔끔하게 돌아가는 상황이 나왔어요. 엣지는 아직 페이지가 제대로 표현이 안되는 사이트가 너무 많구요.
계속해서 평균 이상되는 컴퓨터만 써오면서 크롬을 쓰니 잘 몰랐던 부분이었던 것 같은데 크롬은 더 이상 빠르고 가벼움을 추구하는 브라우저는 아닌 것 같았습니다. 무겁고 화면 활용이 좋은 브라우저 정도가 맞을 것 같습니다. 셀러론 이상의 시피유+4기가 이상의 램만 되어도 문제가 되지 않는 문제이기 때문에 큰 상관이 없을 수 있겠지만 크롬북이나 태블릿 시장에서의 브라우저 경쟁력이 떨어질 것 같다는 생각이 들었습니다.
계속해서 평균 이상되는 컴퓨터만 써오면서 크롬을 쓰니 잘 몰랐던 부분이었던 것 같은데 크롬은 더 이상 빠르고 가벼움을 추구하는 브라우저는 아닌 것 같았습니다. 무겁고 화면 활용이 좋은 브라우저 정도가 맞을 것 같습니다. 셀러론 이상의 시피유+4기가 이상의 램만 되어도 문제가 되지 않는 문제이기 때문에 큰 상관이 없을 수 있겠지만 크롬북이나 태블릿 시장에서의 브라우저 경쟁력이 떨어질 것 같다는 생각이 들었습니다.
Servo의 특징은 레이아웃 엔진부터 시작해서 브라우저의 각 부분이 모두 멀티스레드로 동작하고 전부 모듈화가 되어 있다는 점인데요
렌더러 부분도 예외가 아닙니다. 그런데... 여기에 GPU가 결합되면서 어마어마한 퍼포먼스를 내고 있죠. 타 브라우저들도 GPU를 활용하고는 있지만 미진한 점이 많습니다
http://m.youtube.com/watch?v=u0hYIRQRiws
CSS로 표현된 페이지를 실시간 랜더링하고 있는 겁니다(...)
... 더 보기
렌더러 부분도 예외가 아닙니다. 그런데... 여기에 GPU가 결합되면서 어마어마한 퍼포먼스를 내고 있죠. 타 브라우저들도 GPU를 활용하고는 있지만 미진한 점이 많습니다
http://m.youtube.com/watch?v=u0hYIRQRiws
Chrome vs Firefox vs Safari vs Servo WebRender
CSS로 표현된 페이지를 실시간 랜더링하고 있는 겁니다(...)
... 더 보기
Servo의 특징은 레이아웃 엔진부터 시작해서 브라우저의 각 부분이 모두 멀티스레드로 동작하고 전부 모듈화가 되어 있다는 점인데요
렌더러 부분도 예외가 아닙니다. 그런데... 여기에 GPU가 결합되면서 어마어마한 퍼포먼스를 내고 있죠. 타 브라우저들도 GPU를 활용하고는 있지만 미진한 점이 많습니다
http://m.youtube.com/watch?v=u0hYIRQRiws
CSS로 표현된 페이지를 실시간 랜더링하고 있는 겁니다(...)
HTML+CSS로 게임엔진도 만들 수 있을거라는 전망..
모질라에서도 성능에 고무되어 차후 파이어폭스에 서보 웹랜더를 사용하겠다고 한 걸로 알고 있습니다.
아마 다른 부분들도 이후에 완성되면 이용하게 돠겠죠
렌더러 부분도 예외가 아닙니다. 그런데... 여기에 GPU가 결합되면서 어마어마한 퍼포먼스를 내고 있죠. 타 브라우저들도 GPU를 활용하고는 있지만 미진한 점이 많습니다
http://m.youtube.com/watch?v=u0hYIRQRiws
Chrome vs Firefox vs Safari vs Servo WebRender
CSS로 표현된 페이지를 실시간 랜더링하고 있는 겁니다(...)
HTML+CSS로 게임엔진도 만들 수 있을거라는 전망..
모질라에서도 성능에 고무되어 차후 파이어폭스에 서보 웹랜더를 사용하겠다고 한 걸로 알고 있습니다.
아마 다른 부분들도 이후에 완성되면 이용하게 돠겠죠
아직은 먼 훗날의 일이기는 합니다
Rust 프로그램이 C로 작성된 이종 코드와 문제없이 연동이 되기는 합니다만, 서로 다른 표준 런타임을 사용한다는 문제는 여전히 있어서... 통합에 약간 품이 들기도 하고, 랜더러가 제 성능을 내려면 레이아웃 엔진에서 각 오브젝트의 위치 같은 걸 제때 알려줘야 하는데 옛 브라우저 엔진들은 그게 안 됩니다.
다른 브라우저들은 싱글스레드 알고리즘 기반하고 있어서, 대부분 코어 하나가 한 프레임을 맡아서 처리하는 식으로 병렬화가 됩니다. 이런 식으로는 많은 오브젝트가 존재하거나 하면 개별 처... 더 보기
Rust 프로그램이 C로 작성된 이종 코드와 문제없이 연동이 되기는 합니다만, 서로 다른 표준 런타임을 사용한다는 문제는 여전히 있어서... 통합에 약간 품이 들기도 하고, 랜더러가 제 성능을 내려면 레이아웃 엔진에서 각 오브젝트의 위치 같은 걸 제때 알려줘야 하는데 옛 브라우저 엔진들은 그게 안 됩니다.
다른 브라우저들은 싱글스레드 알고리즘 기반하고 있어서, 대부분 코어 하나가 한 프레임을 맡아서 처리하는 식으로 병렬화가 됩니다. 이런 식으로는 많은 오브젝트가 존재하거나 하면 개별 처... 더 보기
아직은 먼 훗날의 일이기는 합니다
Rust 프로그램이 C로 작성된 이종 코드와 문제없이 연동이 되기는 합니다만, 서로 다른 표준 런타임을 사용한다는 문제는 여전히 있어서... 통합에 약간 품이 들기도 하고, 랜더러가 제 성능을 내려면 레이아웃 엔진에서 각 오브젝트의 위치 같은 걸 제때 알려줘야 하는데 옛 브라우저 엔진들은 그게 안 됩니다.
다른 브라우저들은 싱글스레드 알고리즘 기반하고 있어서, 대부분 코어 하나가 한 프레임을 맡아서 처리하는 식으로 병렬화가 됩니다. 이런 식으로는 많은 오브젝트가 존재하거나 하면 개별 처리시간이 늘어서 프레임레이트가 떨어지게 마련이고, 싱글스레드보다 빠르긴 한데 암달의 법칙에 의해 금방 성능향상이 정체됩니다.
반면 서보는 같은 프레임 내의 오브젝트들의 위치도 서로 다른 스레드에서 각자 계산하여 처리하기 때문에, 개인 PC에서 사용하는 정도의 코어 숫자에서는 성능이 거의 선형 스케일링이 되고 있어요
Rust 프로그램이 C로 작성된 이종 코드와 문제없이 연동이 되기는 합니다만, 서로 다른 표준 런타임을 사용한다는 문제는 여전히 있어서... 통합에 약간 품이 들기도 하고, 랜더러가 제 성능을 내려면 레이아웃 엔진에서 각 오브젝트의 위치 같은 걸 제때 알려줘야 하는데 옛 브라우저 엔진들은 그게 안 됩니다.
다른 브라우저들은 싱글스레드 알고리즘 기반하고 있어서, 대부분 코어 하나가 한 프레임을 맡아서 처리하는 식으로 병렬화가 됩니다. 이런 식으로는 많은 오브젝트가 존재하거나 하면 개별 처리시간이 늘어서 프레임레이트가 떨어지게 마련이고, 싱글스레드보다 빠르긴 한데 암달의 법칙에 의해 금방 성능향상이 정체됩니다.
반면 서보는 같은 프레임 내의 오브젝트들의 위치도 서로 다른 스레드에서 각자 계산하여 처리하기 때문에, 개인 PC에서 사용하는 정도의 코어 숫자에서는 성능이 거의 선형 스케일링이 되고 있어요
어떠한 경우에도 공유 데이터의 오염을 막는 Memory Safety를 컴파일 단계에서 보장하는 Rust 의 특징 덕분이지요. 물론 Servo 정도 프로젝트는 최적화된 퍼포먼스를 위해 unsafe 코드로 작성된 부분도 많지만 그 경우에도 개발자들 스스로가 라이브러리나 함수 단위에서 Safety 가 유지되도록 설계합니다.
왜 Safety 가 중요하냐면, C나 c++같은 unsafe default 언어에서는 병렬성 확보가 어렵습니다. 이 데이터가 수정 가능한지, 공유되어 있는지 등의 정보를 따로 필드를 만들어서 하나하나 추적하면서 ... 더 보기
왜 Safety 가 중요하냐면, C나 c++같은 unsafe default 언어에서는 병렬성 확보가 어렵습니다. 이 데이터가 수정 가능한지, 공유되어 있는지 등의 정보를 따로 필드를 만들어서 하나하나 추적하면서 ... 더 보기
어떠한 경우에도 공유 데이터의 오염을 막는 Memory Safety를 컴파일 단계에서 보장하는 Rust 의 특징 덕분이지요. 물론 Servo 정도 프로젝트는 최적화된 퍼포먼스를 위해 unsafe 코드로 작성된 부분도 많지만 그 경우에도 개발자들 스스로가 라이브러리나 함수 단위에서 Safety 가 유지되도록 설계합니다.
왜 Safety 가 중요하냐면, C나 c++같은 unsafe default 언어에서는 병렬성 확보가 어렵습니다. 이 데이터가 수정 가능한지, 공유되어 있는지 등의 정보를 따로 필드를 만들어서 하나하나 추적하면서 실행하면 병렬성 확보가 가능은 한데 최적화와 거리가 멀어져 버립니다. 그렇다고 그런 정보 없이 빠른 코드를 작성하려 하면 거의 틀림없이 골치아픈 버그가 생깁니다. 멀티 스레드 프로그램은 검증하기가 훨씬 어렵습니다.
Rust 는 이를 피하기 위해 설계된 언어답게, 아예 싱글스레드 프로그램에서부터 강력한 제약을 걸어서 이를 우회합니다. 변수를 선언하면 값을 다시는 바꿀 수 없고, 바꿔야만 하는 변수는 명시적으로 mutable이라고 적어야 하지요. mutable 변수는 aliasing이 불가능하도록 컴파일 단계에서 보장이 됩니다.싱글 스레드에서 안전한 Rust 코드는 멀티 스레드에서도 안전한 코드가 되지요.
Rust 도 아직 최적화나 언어 기능에서 완벽이라고 하기엔 갈 길이 멀지만, 그래도 현재 임베디드에서부터 최종사용자 응용프로그램에 이르기까지 C/C++을 거의 전 영역에서 대체 가능한 거의 유일한 industry-ready 언어가 아닐까 합니다.
왜 Safety 가 중요하냐면, C나 c++같은 unsafe default 언어에서는 병렬성 확보가 어렵습니다. 이 데이터가 수정 가능한지, 공유되어 있는지 등의 정보를 따로 필드를 만들어서 하나하나 추적하면서 실행하면 병렬성 확보가 가능은 한데 최적화와 거리가 멀어져 버립니다. 그렇다고 그런 정보 없이 빠른 코드를 작성하려 하면 거의 틀림없이 골치아픈 버그가 생깁니다. 멀티 스레드 프로그램은 검증하기가 훨씬 어렵습니다.
Rust 는 이를 피하기 위해 설계된 언어답게, 아예 싱글스레드 프로그램에서부터 강력한 제약을 걸어서 이를 우회합니다. 변수를 선언하면 값을 다시는 바꿀 수 없고, 바꿔야만 하는 변수는 명시적으로 mutable이라고 적어야 하지요. mutable 변수는 aliasing이 불가능하도록 컴파일 단계에서 보장이 됩니다.싱글 스레드에서 안전한 Rust 코드는 멀티 스레드에서도 안전한 코드가 되지요.
Rust 도 아직 최적화나 언어 기능에서 완벽이라고 하기엔 갈 길이 멀지만, 그래도 현재 임베디드에서부터 최종사용자 응용프로그램에 이르기까지 C/C++을 거의 전 영역에서 대체 가능한 거의 유일한 industry-ready 언어가 아닐까 합니다.
목록 |
|