codeheart 위치로그  |  태그  |  미디어로그  |  방명록
icon 분류 전체보기 에 해당하는 글74 개
2013.09.18   2012 나는 가수다 - 이젠 그랬으면 좋겠네 (박정현)
2013.09.18   호날두 해트트릭 동영상 (레알 6 : 1 갈라타사라이) UEFA 챔피언스리그 본선 조별리그 B조 1차전
2013.09.17   동양그룹 부도 위기설? (동양증권/동양종금)
2013.09.17   손석희 JTBC 뉴스9 로 앵커 복귀하다
2013.09.17   갑자기 인터넷 라디오가 안되는 경우 (지정한 프로토콜이 지원되지 않아서...)
2013.09.16   영화 '관상' 을 보고... (아주 약간의 스포)
2013.09.14   [powershell] 파워쉘 속성 튜토리얼 1
2013.09.14   Windows 8.1, 8, 7, Vista, Xp...
2013.09.14   iPhone 5S 등장. 아이폰 그리고 안드로이드폰
2013.09.14   윈도우8.1 익스플로러 11 사용 후기 (vs 크롬 29) 3


icon 2012 나는 가수다 - 이젠 그랬으면 좋겠네 (박정현)
카테고리 없음 | 2013. 9. 18. 20:50

 

 

참고로, 이 영상은 금일 있었던 명곡 BEST10 영상은 아니고 2012년 나는 가수다 영상입니다.

오늘 나는 가수다 명곡 BEST 10 에서

박정현의 이젠 그랬으면 좋겠네 (원곡 조용필)이 1등을 했다길래
간만에 박정현 노래를 들어보고자 찾아보았습니다.

 


arrow 트랙백 | 댓글



icon 호날두 해트트릭 동영상 (레알 6 : 1 갈라타사라이) UEFA 챔피언스리그 본선 조별리그 B조 1차전
잡담 | 2013. 9. 18. 12:35






arrow 트랙백 | 댓글



icon 동양그룹 부도 위기설? (동양증권/동양종금)
잡담 | 2013. 9. 17. 22:38

얼마전부터 동양그룹 부도 위기설이 흘러나오고 있다.


만기도래 기업어음이 7000억 가량, 

2012년 말 기준 부채비율은 1233.2% 정도 되고

동양그룹 지원 요청이 알려진 오리온의 주가 역시 악영향이 미치고 있다고 한다.


나도 동양종금을 이용하고 있어서 눈여겨 보고 있는데,


물론 동양그룹이 위기라고 해서 조급해할 필요까지는 없다.


최악의 경우라도 동양종금 같이 사용자가 많은 큰 회사를 정부가 넋놓고 두지는 않을 것이다.


여하튼 조심해서 나쁠 것은 없다.


CMA 라면 예금자 보호가 있으니 문제가 없을 거라 생각할 수도 있는데,


초기 CMA 종금형 상품이 아닌 상품들은 이러한 해당 사항이 없다.


자세히 알아보고 어느 정도 준비를 하는 것이 좋을 것 같다.


도움이 될까하여 CMA 상품 설명 관련 링크를 걸어둔다.


http://sdk4.tistory.com/257


arrow 트랙백 | 댓글



icon 손석희 JTBC 뉴스9 로 앵커 복귀하다
잡담 | 2013. 9. 17. 22:20

어제부로 종편 JTBC 뉴스9 에서 앵커로 복귀...


1999년 아침뉴스2000 이후로 14년만의 복귀라고 한다.


지난 5월 JTBC 보도 총괄 사장을 맡았다고 하던데


실망하는 사람들도 많지만,


네이버/다음 검색 순위에 JTBC 뉴스9, 손석희 키워드가 올라간 걸 보면...


간만에 브라운관에 복귀해서 그런지 환영하는 사람들이 더 많은 듯 하다.



이제서야 16일자 손석희 안철수 영상을 봤다.


다음 주소에서 볼 수 있다.


손석희 안철수 : http://news.jtbc.co.kr/Replay/news_replay.aspx?fcode=PR10000403


참고로 종편 JTBC 는 생방송을 인터넷으로 무료로 볼 수 있다.


생방송 : http://www.jtbc.co.kr/onair/onair.aspx?cloc=jtbc|header|guide



arrow 트랙백 | 댓글



icon 갑자기 인터넷 라디오가 안되는 경우 (지정한 프로토콜이 지원되지 않아서...)
잡담 | 2013. 9. 17. 21:50

'지정한 프로토콜이 지원되지 않아서 파일을 재생할 수 없습니다. [URL 열기] 대화 상자에서 URL을 입력한 경우 "http:"나 "rtsp:"등의 다른 전송 프로토콜을 사용하여 열어 보십시오." 


어느 날, 다음과 같은 에러 메시지가 뜨면서 라디오를 들을 수 없다면?


일부 PC 라디오 프로그램들은 Windows Media Player 를 내부적으로 사용한다.


(아마도 WMP SDK 나 OLE 를 사용해서 내부적으로 사용하고 있을 것이다)


따라서 Windows Media Player 에 문제가 있을 경우 정상 작동하지 않을 수 있다.


다음과 같은 명령어를 실행하는 것도 나쁘지 않다.


Windows + R 를 누른다. ( 혹은 시작 버튼 -> 실행을 누른다 )


다음과 같은 창이 뜰 것이다.


창안에 regsvr32 wmnetmgr.dll 과 같이 입력하고 엔터를 친다 ( 혹은 확인 버튼을 누른다 )





arrow 트랙백 | 댓글



icon 영화 '관상' 을 보고... (아주 약간의 스포)
잡담 | 2013. 9. 16. 00:58




사극물을 그렇게 좋아하지 않고,


제목도 '관상' 이라...


그리 끌리지 않았지만.. 볼 것이 마땅치 않아 보긴 했다.


하지만 생각보다 재미있었고 볼 만 했다.


'관상'이라는 소재를 이용하여 사극물에 적절한 픽션을 섞으면서,


당시의 권력 다툼을 보여주는 작품으로,


권력에는 절대악과 절대선도 없다는 것을 말해주는 작품이다.


무엇보다 유명 주연 배우들의 캐릭터성을 잘 이끌어내었다.


작년(?)에도 별 기대없이 '광해'라는 사극물 영화를 본 적이 있다.


작품성도 있으면서 이병헌의 의외의 재미있는 호연이 돋보였던 작품인데,


'관상'이란 작품도 작품성에서는 다소 부족할 지는 몰라도 다양한 캐릭터를


볼 수 있다는 점에서 재밌게 즐기기에는 더 낫다고 생각이 든다.


(개인적으로 '광해'란 작품은 뒤늦게 표절시비가 있어서 아쉽게 생각한다만...)



arrow 트랙백 | 댓글



icon [powershell] 파워쉘 속성 튜토리얼
개발/Script | 2013. 9. 14. 20:44

powershell 3.0 으로 테스트하였습니다.


PowerShell 은 좀 더 발전된 쉘 스크립팅을 지원한다.

텍스트 기반이 아닌 오브젝트 기반이며, 이로써 더 강력한 기능을 쉽게 가능하게 해준다.

이 점이 장점이 될지는 지켜봐야 하겠지만, 비-리눅스 개발자라면 메리트가 충분히 있어 보인다.


이와 같은 shell script 말고 ruby, python 을 shell script 처럼 사용하는 경우도 많지만,

shell script 가 파일경로 및 디렉토리 구조에 대해 쉽게 사용될 수 있도록 특화되어 있기 때문에

익숙하기만 하면 더 짧은 코드로 작성이 가능하다.


powershell 은 윈도우 쉘 답게 명령어에 대소문자를 가리지 않는다.

파라메터 규칙은 보통 -option 과 같은 방식을 따른다.

cmd shell 에서 보통 /option 과 같이 하는 것과 대조된다.

(아마도 윈도우 개발자들도 요즘은 linux 스타일 path 구분자 / 을 사용하는 경우가 많아서 그런게 아닐까 싶다)

이는 unix 계열의 구형 옵션 방식과 유사하다. (요즘은 거의 GNU style 로 통일되는 듯 싶지만)



[[출력해보기]]

echo 'hello'


write-host 'hello'


$your_name = 'name'

write-host "hello ${your_name}"


write-host "hello" ${your_name}

사실 echo 와 write-host 는 엄밀히 다르다.

write-host 가 cmd 의 echo 와 같으며, echo 는 복잡한 개체를 표시할 때 title column 이 표시되는 특징이 있다.



[[현재 폴더 모든 파일명앞에 'value = ' 을 붙여 출력하는 방법 #1]]

foreach($item in gci) { write-host 'value =' $item}


foreach($item in gci | select name) { write-host 'value =' $item.name}

foreach($item in gci | select *) { write-host 'value =' $item.name}


gci 는 Get-ChildItem 의 약자이자 alias 명령어로

dir 및 ls 과 유사하지만, 결과물을 item 목록으로 준다고 보면 된다.(오브젝트 기반 스크립트이므로)

select 는 그 목록 개별 레코드 중 특정 컬럼(오브젝트)만 취하는 것이다.

( bash 으로 하려면 복잡해진다. grep/awk 등 텍스트 파싱을 위한 여러 조합이 나올 것이다 )


object 기반이기 때문에 gci 의 결과물은 객체라 봐도 무방하다.

그래서 $item.name 같이 특정 컬럼(오브젝트)에 멤버 변수처럼 접근하는 것도 가능하다.



[[현재 폴더 모든 파일명앞에 'value = ' 을 붙여 출력하는 방법 #2]]

gci | ForEach-Object{write-host 'value =' $_}

gci | foreach{write-host 'value =' $_}

gci | %{write-host 'value =' $_}

이는 다소 독특한 방법인데, gci 의 출력(파일 리스트)의 요소 각각에 대해서 무언가 다른 작업을 해주는 것이다. ruby 의 .each{ 와 비슷한데 $_ 는 그 해당 요소 하나를 의미한다. 위에서는 $item 이라 보면 된다. % 는 축약형으로 사실은 ForEach-Object 이다. foreach 로도 사용할 수 있다.
(하지만, foreach(...) {} 과 같은 문법을 ForEach-Object 로는 대체할 수 없다!)

이 방법이 foreach(...) {...} 방식보다 쉘스크립트에 더 적합한 것 같다.


[[현재 폴더 모든 파일명 중에 'vim' 이라는 글자가 들어간 경우만 출력하는 방법]]

foreach($item in gci) { if($item.name -like '*vim*') { write-host $item} }


foreach($item in gci) { if($item.name.contains('vim')) { write-host $item} }


gci | %{if($_.name -like '*vim*') { write-host $_ }}



[[오브젝트 멤버 보기]]

python 의 dir. ruby 의 .methods 같은 기능이다.

powershell 은 객체지향이므로 이런 것을 알아두면 공부할 때 도움이 된다.


"text" | get-member // "text" 객체의 member 보기


[string] | get-member // string 타입의 member 보기



/* method 목록만 보기 */


// 맨위에 Name ===== 과 같은 헤더 컬럼명이 생략되는 방법

[string].GetMethods() | select name


// 맨위에 Name ===== 과 같은 헤더 컬럼명이 생략되는 방법(들)

[string].GetMethods() | %{$_.name}


[string].GetMethods() | %{write-host $_.name}


[string].GetMethods() | ft -hide


ft -hide 는 Format-Table -hidetableheaders 의 줄임 명령이다.



arrow 트랙백 | 댓글



icon Windows 8.1, 8, 7, Vista, Xp...
컴퓨터 | 2013. 9. 14. 17:31

먼저, 주관적인 견해임을 말씀드립니다.



윈도우7는 사용자 관점에서 훌륭한 OS 입니다.


그렇다면, 사용자 층이 적은 Windows 8 은 별로인가?


아직도 점유율이 높은 Windows XP 는 역대 최고의 MS 운영체제인가?


여러 관점에서 볼 일이긴 합니다.


[자사 OS 끼리 비교하자면]


내가 볼 때 윈도우는 일반 사용자용 윈도우도 NT 커널로 넘어간 후로 충분히 훌륭하다고 봅니다.


윈도우7 은 그 간 OS 들이 욕을 먹었던 것과 달리 상당히 호평을 받았음에도 불구하고 처음 점유율은 좋지 않았습니다. 최고의 OS(?) Windows XP 가 팀킬을 하고 있었기 때문입니다.

하지만 Windows XP 도 처음엔 욕을 먹었던 것을 기억해야 합니다.

Windows 95, 98 에 비해 너무 무겁다... 하지만 시대가 지난 지금은 너무 가벼워서 탈입니다.

게다가 Windows 95, 98 같은 비-NT(DOS) 기반 OS 의 경우에는 안정성 까지 최악이었죠.

윈도우Vista 역시 비운의 OS 입니다.

분명 UI 측면에서 현대 윈도우 버젼의 근간이 되는 많은 변화를 주었지만, 확실히 성능상 문제가 있었습니다. UI 를 거의 이어받고 성능을 획기적으로 개선한 Windows 7 이 호평을 받은 것은 당연합니다.


하지만, Windows 8 은 홀짝 순서에 따라 과연 망작일까? 시작 버튼, 시작 메뉴를 없앤 것은 과연 잘한 선택일까? 이 부분은 잘 모르겠습니다. 결과론 적인것이라, 너무 MS가 앞서 나가서 사용자가 적응하지 못할 것일수도 있고, 완전한 오판일 수도 있습니다.

그 부분만을 제외하고 본다면 Windows 8 은 상당히 좋습니다. 안정적일 뿐더러, Windows 7 보다도 더 빠르고, 메모리도 더 적습니다. 태블릿용으로 나온 OS 라 작정하고 만든 느낌은 듭니다.

확실히 데스크탑 사용자로서는 큰 메리트가 없는 것은 사실입니다.

제 생각은 윈도우7 에 만족한다면 굳이 바꿀 필요는 없지만, 그렇다고 망작은 아니란 생각입니다.

확실히 쾌적함에 있어서는 윈도우 8 에서 더 만족을 했기 때문입니다.


윈도우8.1 프리뷰를 써본 결과, 윈도우8에서 지적되었던 시작버튼이 부활되었습니다.

그리고 시작화면으로 가지 않아도 컴퓨터를 부팅하거나 종료할 수 있습니다.

(여전히, 사용자 입장에서는 오른쪽 버튼을 마구 눌러서 탐구해봐야 하는 몇가지 단점이 보입니다)

사실 8.1 은 MS 가 8에서 사용자 입장을 반영하려고 만든 패치로 보이지만, 여전히 MS 의 똥고집이 보이기도 합니다. 시작 버튼은 살렸지만, 시작 메뉴를 살리지는 않았습니다.

결국 어떻게 버튼 버튼 모양만 생긴 꼴입니다. 그래서 8.1 역시 8 처럼 보급시키기에는 다소 무리가 있어 보입니다. 제 생각으로는 Windows 9 로 넘어가기 전에 사용자들의 사용자 경험의 반응을 다시 한번 확인해보려고 고집을 부리는 것 같습니다. 몇년을 더 두고 봐야겠네요.

그 것을 제외한다면, 윈도우8.1 은 (아직 프리뷰라 잔버그가 있지만) 윈도우8보다도 더 쾌적해졌습니다. 게다가 한 번 리뷰했던 익스플로러11 의 성능은 정말 만족스럽니다.

(다만, OS 자체를 놓고 보자면 익스플로러11 에 대해서는 생략하는 게 맞겟죠)


[비 MS OS 과 비교하자면...]


(주로 개발자겠지만) 혹자는 유닉스 계열(Linux, BSD 포함)과 비교하여 떨어지는 안정성 및 성능을 내세우며, 특히 OS 는 돈을 받고 팔면 안된다고까지 주장합니다.

공정성 문제가 항상 대두되기는 하지만... 그렇다고 리눅스 계열이 다 무료봉사하는 것은 아닙니다.

리눅스 계열도 돈을 받고 팔고 서포트 비용을 받기도 합니다. 역으로 생각해보면 윈도우 가격도 서포트 비용이라 간주하면 됩니다.


 - 역사를 본다면 UNIX 계열과 NT 계열을 그 근간이 다릅니다.

UNIX 계열은 더 오래되었으며, 당시 컴퓨터들은 지금과 같이 빠른 컴퓨터가 아니었습니다.

당연하게도 UNIX 는 GUI 보다는 CLI(Command Line Interface)를 강조하며,

이를 가지고 더 많은 일을 하는 쪽으로 발전되었습니다.

UNIX 의 쉘 역시 발전을 거듭했으며, 쉘을 통해 각종 실행파일을 연동해 더욱 강력한 일을

해낼 수 있습니다.


 - 하지만, NT 의 전신인 DOS 는 CLI 가 근간이긴 하지만 일반 사용자를 대상으로 하는 OS 이며,

일반 사용자는 당시 UNIX 해커들과 달리 그런 조합적인 쉘 스크립트를 작성하거나 사용할 여력이 되지 않습니다. 쉘 자체의 기능도 상대적으로 조악할 뿐더러 수행되는 CLI 어플리케이션의 기능들도

UNIX 처럼 여러 어플리케이션의 조합을 의도한 것이 아니라, 한 어플리케이션이 가능한 많은 일을 할 수 있도록 하는 식으로 개발되었습니다.


 - Windows 2000 부터 사용자 OS 에 도입된 NT 계열은 비록 GUI 기반 OS 기는 해도, DOS 이후의 호환성을 계속 유지할 수 밖에 없습니다. 따라서 조악할 쉘은 지속되었습니다.

하지만 XP 부터 시험적으로 powershell 이라는 것을 도입하여 기존의 CMD(COMMAND) shell 을 벗어나고자 한 노력은 보입니다. Vista 혹은 7 부터는 기본 탑재가 되었고 현재 버전 3은 8 부터 기본 탑재된 것 같습니다. 사실 powershell 이 좋냐 bash, tcsh 이 좋냐를 따지자는 것은 아닙니다.

powershell 역시 매우 훌륭한 쉘이지만, 그렇다고 CMD 기반하에 운영되던 모든 콘솔 어플리케이션의 생태계마저 바꿀 수는 없는 노릇입니다. 점차 바뀔 수도 있겠지만, 단기간에 그러한 문화를 바꿀 수는 없습니다. 게다가 윈도우는 일반 사용자를 위해 Console 이 아닌 GUI 위주의 설계 패턴을 따르는 어플리케이션만이 나오다 보니, UNIX 개발자에게 그 것은 매우 비생산적인 것으로 비춰지기 일쑤입니다.


 - UNIX 해커들을 유저로 받아들이고 발전한 UNIX 계열 OS 와 일반 사용자들을 유저로 받아들이고 발전한 Windows 를 직접적으로 좋다 그르다라고 판단해서는 안된다고 생각됩니다.

일부 골수 UNIX 파워 유저들이 주장하는 논리도 분명 일리는 있지만, 개발자와 사용자 간의 UX 에 대해 느끼는 편안함/익숙함은 분명 다를 수 밖에 없기 때문에 태생부터가 다른 두 OS 를 직접 비교할 수가 없습니다.


 - 윈도우가 CLI 에서 약점을 보이지만, 유닉스 계열은 GUI 에서 약점을 보인다고 생각합니다.

(Mac OS X 는 X 시리즈 이후로 UNIX 계열 BSD 기반으로 가면서 그 두 장점을 잘 조합시킨 것으로 보이지만, 많이 써보지 않은 입장에서 굳이 언급하지는 않겠습니다.)

유닉스 계열은 대부분의 개발자들이 쉘에 대해서 편안함을 느끼기에 역으로 GUI 프로그램이 도태된 측면이 있습니다. 혹자는 유닉스(X window 가 구시대적이긴 하지만)가 부족해서가 아니다, 맘만 먹으면 더 좋게 가능하다. 라고 말하지만, 따지고 보면 NT 의 powershell 을 써봤는지 묻고 싶습니다. 설사 그게 아니더라도 개발자로서 CLI 조합적인 쉘의 구현이 어려운지 묻고 싶습니다. (MS 개발자들이 바보가 아닌이상)

결국 인정해야 된다고 봅니다. 양 계열의 장단점은 기술적 차이가 아니라 사용 문화의 차이점에서 비롯되는 것을.


[결론]

- 기존 윈도우8 유저들

그냥 넘어가면 됩니다. 좀 더 쾌적하고, 익스플로러11은 확실히 빨라졌습니다.

데스크탑 모드로 바로 부팅할 수도 있습니다.

StartIsBack 이나 Start8 을 그대로 쓰신다면 또한 그냥 넘어가시면 됩니다. (8.1 지원하는대로)

다만, ActiveX 같은 고질적인 OS 버젼 업시 생기는 호환성 이슈는 고려하셔야 합니다.

제 경우 VirtualBox 같은 것을 통해 전 버젼 OS 를 가상으로 돌리니 이러한 점은 별로 중요하지 않더군요.


- 기존 윈도우7 유저들

기존 윈도우7 유저들의 입장에서 시작 메뉴가 없어진 것에 불만만 없다면, 넘어갈 만 합니다.

확실히 쾌적합니다. 쓰고는 싶은데 시작 메뉴가 아쉽다면 StartIsBack 이나 Start8 같은 시작 메뉴를 되살리는 어플리케이션을 구입(!)하시면 7 이랑 똑같이 쓰실 수도 있습니다. 무료의 시작 메뉴 되살리는 프로그램도 있습니다. 다만, 퀄리티가 다소 떨어집니다.


- 기존 윈도우Vista 유저들

Vista 는 정말 최악입니다. 일단 윈도우7로 넘어가셔야 할 것 같습니다.


- 기존 윈도우XP 유저들

PC 가 고사양이라면 7, 8 로 넘어가시는게 좋겠지만 그렇지 않다면 그냥 쓰셔도 무방합니다.

하지만 XP 의 주력은 32bit XP 기 때문에 언젠가 메모리 문제를 해결하기 위해서라도 넘어가야 된다고 생각합니다.(물론 7,8의 64bit 버젼. XP 64bit 도 있긴 한데 더 불안정함)

게임 호환성 문제의 경우에는 알아서 해야 합니다.


arrow 트랙백 | 댓글



icon iPhone 5S 등장. 아이폰 그리고 안드로이드폰
컴퓨터 | 2013. 9. 14. 15:40

2013년 9월 11일 경, 아이폰5S 가 공개되었다.

보안 관리에 실패하여 이미 알려진 스펙 거의 그대로 나온 거 말고 신선한 점은 없었다.

아래는 아이폰5S 와 경쟁사들의 안드로이드폰 스펙이다.

 


iPhone 5S Galaxy S4 LG G2 HTC One Moto X Xperia Z1
Maker Apple Samsung LG HTC Google Sony
Body Size (mm) 123.8 x 58.6 x 7.6 136.6 x 69.8 x 7.9 138.5 x 70.9 x 8.9 137.4 x 68.2 x 9.3 129.3 x 65.3 x 10.4 144 x 74 x 8.5
Body Weight (g) 112 130 143 143 130 170
Display Size 4-inch 5-inch 5.2-inch 4.7-inch 4.7-inch 5-inch
Display Type LCD Super AMOLED LCD LCD AMOLED TFT
Display Resolution 1136 x 640 1920 x 1080 1920 x 1080 1920 x 1080 1280 x 720 1920 x 1080
Display PPI 326 441 424 469 312 441
CPU A7 64-bit
M7 motion coprocessor
Snapdragon 600 /
Exynos 5 Octa
Snapdragon 800 Snapdragon 600 X8 System Snapdragon 800
RAM 1GB (?) 2GB 2GB 2GB 2GB 2GB
Storage 16/32/64GB 16/32/64GB 16/32GB 32/64GB 16/32GB 16GB
MicroSD No Yes No No No Yes
Camera (F/B) 8MP/1.2MP 13MP/2MP 13MP/2.1MP 4MP/2.1MP 10MP/2MP 20.7MP/2MP
Wi-Fi 802.11 a/b/g/n 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac
Bluetooth 4 4 4 4 4 4
GPS Yes Yes Yes Yes Yes Yes
LTE Yes Yes Yes Yes Yes Yes
NFC No Yes Yes Yes Yes Yes
Battery 1440mAh (?) 2600mAh 3000mAh 2300mAh 2200mAh 3000mAh
Battery standby 250 hours 370 hours N/A 480 hours 576 hours 880 hours
Fingerprint scan Yes No No No No No
Body material Aluminium Polycarbonate Polycarbonate Aluminium Polycarbonate Polycarbonate
OS iOS 7 Android 4.2.2 Android 4.2.2 Android 4.2.2 Android 4.2.2 Android 4.3

출처(수정됨)

이 것을 보면 아이폰은 스펙이 매우 별로인 것으로 보인다.

아이폰 5 에서 실망했지만, 5S 에서는 더 실망했다고 볼 수도 있다.

(물론 CPU/GPU 성능이 나쁘다는 것은 아니다)

 

애초에 아이폰의 독주가 처음부터 오래갈 거라 생각하지도 않았다.

개방정책의 안드로이드가 결국 점유율에서 앞설 수밖에 없다.

과거 IBM PC 와 APPLE PC 와의 전례만 봐도 그렇다.

APPLE PC 는 IBM PC 의 공개 정책에 밀려 점유율을 혹사당했다.

 

하지만, 안드로이드 점유율이 높다고 해서 회사의 이득이 큰 것도 아닐 것이다.

폐쇄 정책과 개방 정책은 장단점이 있기 때문에 일단 논외로 봐야 될 것 같다.

 

아이폰 램과 배터리 스펙은 공개되지 않았지만 대개 추정치는 맞았기 때문에 이번에도 벗어나지 않을 것이다. 화면이 작고 폰이 작으니까 배터리가 다른 폰에 비해 적은 것은 이해가 간다. 램 1GB 라는 것은 애플이 충분히 테스트해보고 내린 결론이므로 불안감과 안드로이드 한계 때문에 무작정 늘리는 안드로이드와 비교하여 나쁘다고 볼 수 없다. 안드로이드 플랫폼은 Linux 위의 자바 기반 플랫폼이므로 대부분의 어플리케이션이 자바로 개발되어있다. 자바 앱이 Native Object C 로 짜여진 아이폰 앱보다 메모리를 더 먹는 것은 어쩔 수 없다. 게다가, 애플의 폐쇄 정책은 여기서 빛을 발한다. 폐쇄 정책을 지향할 수 밖에 없는 콘솔 게임기(예. XBOX360/PS3)를 예로 보자. 현대 PC 스펙에 비해 훨씬 떨어짐에도 불구하고 같은 성능 대비 훨씬 우월한 퀄리티를 자랑한다. 프로그램을 만들어 본 사람이면 알겠지만, 하드웨어 스펙이 정해진 코딩을 하는 것과 알 수 없는 것을 코딩하는 것과는 천지차이다. 코드양을 줄일 수 있을 뿐더러, 불필요한 리소스의 양을 줄일 수 있다. 이 것은 적은 메모리와 스토리지 양으로도 더 고성능을 낼 수 있음을 의미한다.

 

아이폰은 (안드로이드폰만 써보고 아이폰을) 써보지 않은 사람이 욕하지만,

안드로이드폰은 (아이폰을 썼다가 안드로이드폰을) 써본 사람이 욕한다고 한다.

 

확실히 아이폰을 썼을 때는 안드로이드폰의 자유도 때문에 끌리는 점도 있었다.

하지만 괴랄같은 안드로이드의 배터리 효율성 때문에 위젯도 결국 안쓰게 되고, WIFI, GPS, 동기화도 일일이 수동으로 끄고 절약 모드로 전환하는 것을 보면 과연 이게 사용자 편의성인가? 하고 되묻게 된다. 오히려 아이폰의 심플함이 (최소한 모바일에서는) 더욱 사용자 편의성을 높여주는 작용을 하는 것 같다. 아이폰은 배터리를 오래 지속하려고, 옵션을 끄는 노력을 거의 하지도 않았다. 사실 거의 차이 없기도 했다. 이 것도 노하우가 아닌가 싶다.

 

PS. 스펙만 보면 위의 안드로이드폰의 배터리 대기 시간이 훨씬 길다.

하지만, S사 G...S3 을 써보며 느낀 점이지만, 안드로이드폰은 뻥튀기 스펙이라는 것이다.

최대한 벤치마크는 옵션을 다 끈 상태에서 측정할 것이다. 자유도 높은 안드로이드 폰이 뻥튀기 되기 쉽상인 원인이다. 스펙으로는 대기 시간이 더 긴데, 실상 더 짧은 경우가 많다.

(요즘은 안드로이드 배터리 용량이 더 늘어나서 장담하긴 힘들지만)

 

안드로이드폰은 절전 관리, 보안성, 불필요한 셋업으로 인한 시간 낭비, 파편화 등 아이폰에서는 유저가 생각하지 않아도 될 문제들이 많다.

 

안드로이드폰의 단점을 부각했지만, 아이폰도 문제가 있다.

지나친 폐쇄성이 어플리케이션 패치를 방해하고, 가격도 비싸다.

보수적인 결단으로 인해 화면 사이즈에 대해서도 말이 많다.

개인적으로 태블릿이 있기에 불만은 없다.

하지만, 태블릿이 없고 게임을 자주 하는 사용자로서는 불만을 가질만도 하다.

제품 자체의 단점이라기 보다는 라인업의 적은 애플의 문제라고 봐야하겠지만...

 

이러한 것을 조율할 것으로 기대됐던 윈도폰은 생각보다 보급 진척이 너무 늦어졌다.

스마트폰의 발전이 안정기에 왔기 때문에 사람들의 호기심도 많이 줄어들었지만, 그만큼 생활에 밀접하게 다가왔다고 볼 수도 있다. 각 플랫폼들은 한쪽으로 쏠림없이 안정적으로 서로를 경쟁하며 발전하길 바랄 뿐이다.


arrow 트랙백 | 댓글



icon 윈도우8.1 익스플로러 11 사용 후기 (vs 크롬 29)
컴퓨터 | 2013. 9. 14. 02:07

객관적 벤치마킹이 아닌 것을 감안하고 읽어주세요.

 

CPU: i7-3610QM

RAM: 8GB

HDD: Intel SSD 320 160GB

 

[성능면]

1. 3D 오브젝트 렌더링 (아직, 별로 중요하지 않음)

- 이 건 이미 익스플로러9 부터 당시 크롬보다 우세했다고 본다.

 

2. 페이지 갱신

- 이 부분은 10에서 많이 따라잡았지만, MS 얘기와 달리 여전히 크롬보다 느린 것은 사실이었다.

하지만, (체감상으로) 익스플로러 11은 확실히 크롬(v29)보다 빠르다.

 

3. 스타트업 (스타트 홈페이지 동일하게 하여 테스트)

- 스타트업 속도는 크롬29가 몇 초 정도 걸리는 데 반해,

익스플로러11는 1초 안에 페이지까지 뜬다.

 

4. 메모리

- 크롬은 초반 버전부터 메모리 괴물이었다. 여전히 크롬이 거의 2배 가량 메모리를 먹는다.

물론 둘다 동일하게 애드온을 모두 제거한 후 테스트 했다.

 

5. 쾌적함

- 크롬은 성능을 위해? 메모리를 많이 사용하는 메커니즘을 사용하는 듯 하지만, 이 것이 사용상의 무거움을 가져다 주지 않나 싶다. 쾌적함은 단순히 페이지가 빨리 뜨는 것을 의미하는 것은 아니다. 웹UI 반응속도 및 스크롤링 등 인터랙션에 있어서 반응이 빨리 오는 것을 여기서 쾌적하다고 표현하였다. 대표적으로 쾌적함이 나쁜 예로 안드로이드 크롬인데, PC 크롬과 많은 코드를 공유하지는 않겠지만 분명 어떤 식으로든 메커니즘을 공유했을 것이다. 램이 적은 안드로이드 기기에서의 반응성은 정말 최악이다.(그나마 최근에 업뎃으로 약간 빨라지긴 했지만 안드로이드 기본 브라우저보다는 확실히 버벅인다) 페이지 로딩은 기본 브라우저보다 훨씬 더 빠름에도 불구하고 느리다고 악평을 받고 있다. 그 이유는 스크롤링 등의 반응성이 매우 느리기 때문이다. PC 크롬은 그 정도는 아니라서 심각하지 않다고 볼 수도 있다. 게다가 그동안 페이지 갱신 속도가 익스플로러 대비 압도적인 우위었기에 사람들이 여기에 대한 불만을 잘 표시하지 않았을 뿐더러 느끼기도 힘들었을 수 있다. 아이러니하게도 PC 파워 유저(혹은 개발자)들이 이 점에 대해 일반 사용자보다 더 둔감했다(반MS의 이유로). 하지만 그림이나 객체가 많은 페이지에서의 스크롤링 및 버튼 반응성을 보면 확실히 버벅이는 것을 알 수 있다. 가장 간단하게 차이점을 느껴보려면 글자가 많은 웹사이트에서 텍스트 드래그를 계속 해보자. 크롬은 버벅이면서 뒤늦게 마우스를 따라오는 반면, 익스프롤러는 반응이 거의 즉시적이다. 사실 이 건 불확실한 기억으로는 익스플로러 6 혹은 7 시절에도 이 부분은 크롬이 더 느렸던 것 같다. 그럼에도 불구하고 압도적인 JavaScript 파싱 성능으로 인해 이 점을 간과한 듯 싶다.

 

- 이러한 점이 왜 발생하나 생각해보자. 브라우저는 크게 두가지 구현부로 분리해 생각해볼 수 있다. 파싱과 렌더링. 파싱(HTML,CSS,JavaScript등을 파싱)은 크롬이 빨랐지만, 렌더링은 확실히 익스플로러가 빨랐다(이 건 이미 9이나 10에서도 빨랐다). 문제는 익스프로러11이 렌더링 뿐 아니라 이제 파싱에서도 근접(혹은 역전. 정밀한 벤치마크 비교 필요)한 것이다. 따라서 크롬이 파싱 능력만 가지고 익스플로러를 제압하기에는 이제 무리가 왔다고 생각한다.

 크롬은 사파리 브라우저처럼 웹킷 라이브러리를 사용한다. 웹킷의 JavaScript 엔진만 자체 V8 엔진으로 대체해 사용하는 것이지 렌더링은 사실상 웹킷 코드 그대로다. 그래서 크롬은 렌더링 성능에서 익스플로러에서 확실히 밀린다. 렌더링 모듈의 성능은 플랫폼에 상당히 의존적인데, 웹킷은 크로스 플랫폼 라이브러리인 것도 이유가 될 것 같다. 게다가 웹킷의 개발 주도를 현재는 애플쪽(사파리)에서 하고 있는데, 다른 애플 프로그램들이 윈도우에서 돌아가는 것을 생각해보자. 과거 iTunes 를 켜봤다면 엄청나게 느린 반응성에 화가 났을지도 모른다.

 크롬 같은 웹킷 기반 브라우저의 렌더링 성능의 문제에 대해서는, 그림이 많은 페이지나 오브젝트가 매우 동적인 페이지에서는 크롬이 이미 익스프로러9 때부터 밀리기 시작했다. 사람들은 MS 가 주도하는 벤치마킹에서만 익스플로러가 빨랐으니 큰 의미를 부여하지 않았다. 여하튼, 이러한 렌더링 이슈 떄문인지는 모르겠으나 크롬은 웹킷에서 벗어나 렌더링 부도 Blink 라는 엔진을 웹킷에서 fork 한 후 자체 개발하여 사용한다고 한다는 얘기를 들었다. 렌더링 쪽도 자체개발해서 웹킷의 그늘을 점차 벗어나야 익스플로러에 대항할 수 있다는 것을 깨달은 듯 싶다.

 이제 크롬 옹호자들이 익스플로러를 무작정 비판하는 모습을 보는 것은 힘든 일이 아니다. 하지만, 익스플로러11 에 대해서는 더 이상 성능가지고는 그럴 수가 없다고 본다. 이제 남은 유일한 장점은 애드온 및 동기화의 편리함이다. 익스플로러10에 대해서도 같은 이슈로 ie vs chrome 논쟁이 많았다. 이번 건도 마찬가지로 실제 벤치마킹에서 누가 우월할지는 잘 모르겠다. 크롬 옹호자들은 일부 ie 가 앞서는 벤치마킹의 호구 조사를 통해 MS 가 했다는 사실까지 알아낼 것이다. 다만, MS 주도가 아닌 Benchmark 역시 Chrome 진영에 유리하게 짜여져있을 수 있다는 사실 역시 간과해서는 안된다.

 

[확장 기능면]

1. 즐겨찾기 동기화

- 크롬은 구글 계정과 연동하여 자체적인 즐겨찾기 동기화를 지원한다.

익스플로러도 버전 10부터 외부 프로그램(MS SkyDrive, MS Live Mesh, XMarks...)을 통하지 않고 동기화를 지원한다. 문제는 윈도우8 부터 지원한다는 것이 문제다. (내가 알기로) 윈도우7용 익스프롤러10은 이러한 방식으로 동기화를 지원하지 않는다.

 

2. 애드온

애드온은 익스플로러의 경우 기존 버젼과 같이 계속 Native 한 방식으로 지원한다.

이는 크롬이 JavaScript 와 같은 방법으로만 제한하고, store 를 통해 받을 수 있게 한 것과 비교해 불편하고 다소 위험하다. 마치 ActiveX 처럼.

 

 

[견해]

 현재 윈도우8.1 이 정식이 아닌 만큼 익스플로러11의 안정성 및 호환성을 토대로 평가하지는 않겠다. 어차피 MS는 항상 새로운 버젼 출시에는 항상 잡음이 있어 왔으니까.

 

 우선, 버전 11 은 MS 가 구글 크롬에 사실상 빼앗긴 브라우저 왕좌자리를 되찾고자 노력한 흔적이 보인다. 익스플로러9, 10에서도 많이 개선이 있어왔고 MS 크롬보다 빠르다고 주장했지만, 실상 일반적인 웹페이지 로딩에 있어서 더 느렸던 것은 사실이다. 하지만 이번만큼은 11이 확실히 빠르다고 느낄할 만하다.

 

 아쉬운 것은 크롬이 초기에 속도로 부각되서 뜬 측면만 인지하지 않았나 싶다.

현재 크롬의 특징은 어떤 OS 에서도 거의 같은 동작을 하며(Windows XP, VISTA, 7, 8, 8.1 및 Linux, MacOS X), 즐겨찾기 동기화 기능 마저 구글 계정과 연동되어 기본적으로 내장되어 있다. 애드온 역시 Store 를 통해 쉽게 설치하고 동기화된다.

즉, 어느 PC 에서나 같은 계정이면 동일한 브라우저 인 것 처럼 사용할 수 있다는 점이 강점이다. 오히려 지금으로서는 크롬을 속도 때문에 쓰는 것이 아니게 되어버렸다.

 

 하지만, MS 는 팀 간의 소통이 되지 않은 탓인지 익스프롤러9, 10, 11 에서 속도는 개선되었을지언정 그러한 사용자 편의성 및 확장성에 대해서는 거의 신경쓰지 않은 듯 싶다.

이제 익스플로러 성능 측면에서 충분히 개선을 했으니 이제 이러한 점을 신경쓸때다.

개인적으로 익스프롤러12 에서는 최소한 다음과 같은 것을 기대한다.

 

1. MS 계정 연동에 따른 자체적인 즐겨찾기 동기화.

하위OS 버젼도 폭넓게 지원하여 집에서나 회사에서나 문제없이 동기화되는 환경.

 

2. 윈도우 뿐 아니라, 아이폰/패드 및 안드로이드의 익스플로러 지원.

성능이 다소 느리더라도, 윈도우 익스플로러의 즐겨찾기라도 호환될 수 있는 브라우저가 제공되면 좋을 것 같다.

 

3. 안정적이고 편리한 Store 기반 애드온 설치(및 애드온 동기화는 보너스).

이 중 윈도우8 부터 등장한 Store 때문에 최신 브라우저가 이와 같은 기능을 이전 OS (XP, 7) 까지 지원하는 것을 기대하는 것은 무리일지도 모른다. 하지만, 최소한 다음 브라우저부터는 이전 OS (XP는 이미 글렀고, 8부터라도) 를 버리는 일은 없어야 하지 않을까.

사람들이 속도에 이미 충분히 만족하는 정도가 됐다면 더 빠르고 느리고는 크게 중요하지 않다고 본다. 오히려 브라우징 환경이 매우 중요하다고 본다.

 

[선택]

 의외겠지만, 개인적으로 선택하자면 익스플로러11이 더 쾌적한 느낌임에도 불구하고,

아직은 크롬을 쓸 것이다. ActiveX 문제로 결제할 때를 제외한다면 말이다. 

 윗 글만 보면 성능상에서는 익스플로러가 우세하고, 기능적인 면에서만 크롬이 아직 낫다고 판단한 것처럼 글을 썼기에 익스플로러11 을 선택할 것이라 생각할 수도 있겠지만, 사실 성능이란 것은 상향 평준화가 되어 큰 불만이 없다. 따라서 그 외적인 측면이 강하게 작용했다.

 다만, 익스플로러가 즐겨찾기 동기화만 잘 해결되도 다시 갈아탈 조건은 충분해졌다. 크롬은 익스플로러와 달리 완전한 자체 기술이 아니다. 이 점 때문에 지금까지와 다르게 앞으로는 성능 개선에서 분명히 더딜 것이라 판단된다. MS 가 보다 현명한 선택을 하길 기대할 뿐이다. (옛날처럼 (일부 사람들이) M$ 가 싫어서 구글을 쓸 정도로 구글이 선한 기업도 아니고, 요즘은 MS 보다 구글이 더 잘나간다. 애초에 그런 이유로 크롬을 선택하는 것은 합리적이지도 않다.)



arrow 트랙백 | 댓글



[PREV] [1][2][3][4][5][6][7][8] [NEXT]
관리자  |   글쓰기
BLOG main image
code heart story
분류 전체보기 (74)
생활 (0)
잡담 (8)
컴퓨터 (11)
개발 (52)
Total :
Today :
Yesterday :
rss
위치로그 : 태그 : 방명록 : 관리자
코드하트's Blog is powered by Daum / Designed by plyfly.net