양파맨의 겨울나기

애플앱스토어 정책이 국가별 계정으로 되어 있기 때문에, 외국스토어(미국홍콩일본 등) 을 이용해야 할 때 참 번거롭다.

이런 번거로움을 조금이나마 해결하기 위한 방법을 두가지 제시할까 한다.

0. 애플 앱스토어 계정 변경
appleid.apple.com 에서 변경할 수 있다. 

1. 개인도메인이 없는 사람
gmail을 활용한다. gmail계정이 있다는 가정하에 진행한다.
다른메일과는 다르게 gmail은 와일드카드를 지원한다.  (좀 더 자세한 내용은 여기(새창링크)서 확인할 수 있다.) 

간단하게 이야기 하면 [. +] (dot, plus) 두개의 활용이다.

• .은 .을 무시
• +는 +이후 문자열 무시

자신의 gmail계정을 testaccount@gmail 이라고 가정하자.
현재 gmail 계정이 있다면 애플앱스토어 계정을 아래와 같이 변경하자.

testaccount+us@gmail.com (미국)
testaccount+hk@gmail.com (홍콩)
testaccount+jp@gmail.com (일본)
testaccount+kr@gmail.com (한국)
..

+us 등과 같은 접미어는 본인 취향대로 넣어도 상관없다.

그럼 모두 testaccount@gmail.com 으로 메일이 온다. 각종 알림이나 프로모션, 구매영수증도 모두 한 메일함으로 들어온다. 여기 들어오는 메일을 각각의 주소로 라벨링 하여 관리하면 편리하다. (역시나 이곳(새창열기) 참조)


2. 개인도메인이 있는 사람
역시 구글의 도움을 받는다.
구글앱스에 가입하여 메일계정을 생성한다.

자신의 개인 도메인을 testdomain.kr 이라고 가정하자.

구글앱스에 아래와 같은 계정을 생성한다.
us@testdomain.kr
kr@testdomain.kr
jp@testdomain.kr

등등..

그리고 위 계정으로 도착하는 이메일들을 하나의 메일함으로 전달한다.
앱스토어 아이디 입력시 + 까지 쳐야하는 번거로움을 없앨 수 있다.


2-1. 응용
appstore@testdomain.kr 계정을 생성후 애플스토어 계정을 아래와 같이 등록
appstore+us@testdomain.kr 등등등

추후에 계정 잊어버리는 일은 좀 줄어들지 않을까. 각자 편한대로 써보자.

node.js

• 자바스크립트 기반. 정확히는 구글의 V8 엔진 기반. 서버사이드 자바스크립트.
• 멀티스레드는 지원하지 않음. 어차피 웹은 latency가 길기 때문에 차라리 싱글스레드를 이용한 이벤트 루프가 낫다.
• 자바스크립트 언어 자체가 논블로킹 IO를 지원하기 때문에 접속마다 스레드를 생성하는 방식보다 동시접속 성능면에서 우수하다. 특히나 long-lived 를 지원해야 하는 리얼타임 웹에서 제격이다.
• 파일IO 자체가 너무 느리기 때문에 디스크에서 데이터를 읽어 오는 사이에 다른 일을 할 수 있도록 비동기 IO를 구현하는 서버를 선택.

활용방안
- 

nodejs 채팅 데모
http://chat.nodejs.org/


nodejs 설치

yum 으로 설치
yum 으로 설치하기 위해 저장소를 추가해주자.



NodeJS 설치


npm 설치 (http://npmjs.org/)


Hello world

오늘 메일을 확인하는데, "타인의 명의도용시도 차단 알림메일" 이 두 통 왔다.


실명인증을 차단해주는 서비스를 유료로 이용하고 있다. 요즘같은 시대에는 이런게 하나쯤 필요하다고 생각하여 꾸준히 사용중이다. 효과가 어느정도 되는지는 모르겠다.

이 메일을 보자마자 든 생각은, '암호화된 네이트 주민번호가 복호화 됐군.' 이었다. (물론 다른 경로로 유출된 민번이 정말 우연찮게도 갑자기 오늘 사용되었을 수도 있지만)

미투데이에 관련 글을 올렸더니 비번 푸는데 30초가 걸렸다고 하는 뉴스가 나왔다고 한다.
어떤 내용인지 예상은 가지만 그래도 한번 찾아봤다.

링크 : http://news.sbs.co.kr/section_news/news_read.jsp?news_id=N1000960683

요약하자면 SBS에서는 brute force 방식의 강제 대입식으로 비밀번호를 추출해낸 것이었다. 네이트의 정확한 암호화방식은 모르는 듯 하고 그냥 시청율을 위한 쇼라고 생각되지만 그나마 사람들에게 이번 사태의 위험성을 알리는데 일조했다고 생각하기에 까지는 않겠다.

웃긴건 뉴스 중간에 보안최고책임자라는 사람이 하는 말이다.

[강은성/SK커뮤니케이션즈 보안담당 이사 : 현재 기술로 보았을 때 이것은 안전합니다.]

이해는 한다. 정보를 주면 줄 수록 크래커에게도 힌트를 주는 것이니까. 하지만 현재 기술로 보았을 때, 안전한 영역은 없다. 털린쪽에서 안전하고 싶을 뿐이겠지.

개인정보 유출에서 최대 쟁점은 두가지 이다. 비밀번호와 주민등록번호.

주민번호야 여러가지 부서에서 사용해야 하기 때문에 복호화가 가능한 양방향 암호화를 했을 것이고, 비밀번호는 단방향 암호화를 사용했을 것 이다.

양방향이면 암호화 방식과 암호화에 사용된 key만 찾으면 풀 수 있다는 소리이다. 이미 언론등을 통해서 네이트가 주민번호에 128비트의 AES 암호화를 사용했다고 알려졌다. 게다가 주민번호는 숫자로만 구성되어 있다. 여기서 중요한건 AES 알고리즘으로 만들어진 문자열을 해독할 수 있는 iv와 key 가 함께 노출되었는가 아닌가인데, 노출되었을 가능성이 적다고 해도 안심할 수 없다. 운이 좋으면 짧은 시간내에 복호화가 가능하기 때문이다.

누가 주도하든 자꾸만 비밀번호 쪽으로만 이슈를 몰아가는것 같아 안타깝다. 바꾸면 그만인 비밀번호 보다는 바꿀 수도 없는 주민번호가 더 문제라고 생각된다. 대한민국 웹서비스의 대부분에는 아이디/비밀번호찾기 서비스가 있기 때문이다.

이름과 주민번호만 알 수 있다면 웬만한 사이트의 비밀번호 또는 비밀번호 변경권을 손쉽게 얻어낼 수 있고, 아이디를 다르게 사용하는 사용자의 아이디도 노출되게 된다. 크래커들도 바보가 아닌 이상 얻기 어려운 곳에 투자 하기 보다는 좀 더 똑똑한 방식을 통해서 자신들이 원하는 것을 얻어낼 것이다.

안타깝다. 언론과 SK컴즈 모두 올바른 시각으로, 올바른 방향으로 문제를 해결하려는 모습을 보여줬으면 좋겠다. 옥션도 잘 넘겼고 심지어는 우리 돈과 가장 밀접한 연관이 있는 농협조차 은근슬쩍 잘 넘어갔는데 네이트라고 다르겠냐만. 

NDC 발표. 라이브서비스조직에서 웹개발자로 잘살기 발표자료


발표가 끝나고 우울한 마음만 가득이었는데, 차근차근 이유를 생각해보자.

1. 사람들이 안왔다.
 - 사람들이 조금은 더 있어야 이야기할만한 내용들이 있었는데, 아마 여기서부터 조금 틀어지기 시작한듯.
2. 멋지게 보이고 싶었다.
 - 어떻게 보면 좀 더 나은 모습으로 보일 수 있었던 기회였는데, 제대로 잡지 못해 아쉬움이 크다.
3. 자기만족이 안되었다.
 - 매번 발표회나 크고작은 무대에 설 때면 그 무대에 나 스스로가 만족했느냐 못했느냐가 중요하다. 이번엔 전혀 만족하지 못하여 준비한 시간에 대한 제대로된 보상을 받지 못한 기분. 아마도 이게 제일 크지 않을까.
4. 대본을 제대로 외우지 못함.
5. 주제에 대한 스스로의 이야깃거리가 없었음
6. 짧은 시간동안 너무 많은 이야기를 말하려고 했음
7. 발표 전날 새벽까지 발표자료 수정을 하고 있었음
8. 나 자신조차 이 내용에 자신이 없었다.

사람이 한명이라도 있으면 최선을 다 해야 하는 것인데, 미안한 마음도 크다. 자기만족조차 되지 못했던 시간이어서 개인적으로는 많이 안타까웠고, 제대로 인정받지 못함에 안타까운 마음이다. 다음번에는 미리미리 주제를 잡고 스스로 만족할 만한 시간이 될 수 있도록 하는 반성의 시간이었다.

발표자료는 굳이 비공개로 돌릴 필요가 없어서 몇 가지 삭제 하고 공개한다. 

• 패스워드의 생성규칙 가이드
  

  ---

패스워드 생성 시, 패스워드 생성 가이드를 제공하는 것이 과연 보안에 어느 정도나 도움이 될까? 그 규칙 중에 특수문자를 넣어야 한다고 "권장"하는 것은 어떤가? 얼핏 봤을 때, 비밀번호에 특수문자가 들어간다면 꽤 강력해 보인다. 실제로도 패스워드에 특수문자가 섞여있다면 꽤 강력한 패스워드이다.

그런데, 이 패스워드 생성규칙을 사용자가 강제로 따라야 한다면 어떨까? 가령

1. 패스워드는 8자 이상 12자 미만으로 이루어져야 합니다.
2. 패스워드에는 특수문자가 필수로 들어가야 합니다.
3. 아이디와 같은 문자열은 사용할 수 없습니다.

와 같은 조항들 말이다. 크래커가 패스워드를 알아내기 위해서 무차별대입 공격을 시작하려 한다. 그런데 업체에서 저런 규칙을 사용자에게 강제화 했다. 이로 인해서 어디부터 시작해야 할지 모르던 크래커는 작업이 더 쉬워졌다. 크래커는 자신이 만든 툴에 아래 규칙을 적용하였다.

1. 자릿수 8자리 이상 12자리 이하
2. 대입 시 특수문자를 필수로 입력. 예) votmdnjem! , votmdnjem!@, qlqjs!@#
3. 아이디와 같은 문자열은 제거

이제 패스워드에 특수문자가 포함되지 않은 문자열들과 13자리이상의 문자열들. 가령 votmdnjemqlalfqjsgh 와 같은 문자열은 무차별대입 공격 시에 제외된다. 매우 많은 경우의 수를 제거해 주는 것이다. votmdnjemqlalfqjsgh 대신에 votmdnjem! 와 같은 문자열을 넣어볼 테니 말이다. 왜 일부러 규칙을 강제화하여 많은 경우의 수를 제거해주는가?

1억 개나 1억 100백 개나 많은 건 많은 거고, 안전한 건 똑같이 안전한거다. 문자가 24개 이던 34개 이던, 어차피 숫자가 무한대에 수렴한다면 굳이 특수문자를 포함할 필요는 없다. 그렇다면 왜 소위 전문가들은 특수문자를 강제화하는 것에 이리도 적극적인가?

• 무차별 대입 공격과 사회공학
  

  ---

특수문자가 포함된 패스워드는 강력하다. 하지만, 이 강력함이라는 것은 무차별대입 공격(brute force)에나 강력한 방법이고, 키로거와 같은 악성코드가 설치된 PC라면 특수문자 할아버지가 들어간 패스워드 라고 해도 전혀 안전하지 않다.

현재의(2011년) 많은 인터넷 사이트들은 이 무차별대입 공격법에 어떻게 대응하고 있는가? 올바르지 않은 입력이 N 회 시도되면 접속차단 또는 캡챠와 같은 기술을 사용하여 자동공격을 차단하고 있다. 굳이 특문 포함이라는 극약 처방을 하지 않아도, 이런 방식으로 무차별대입 공격을 대부분 차단할 수 있다.

요즘 크래커들은 옛날과 같이 무식한 무차별대입법을 사용하여 일하지 않는다. 패스워드에 이름, 생년월일, 전화번호, 휴대전화번호 등과 같이 쉽게 알아낼 수 있는 여러 가지 정보들의 우선순위를 높여 대입해본다. 안되면 이들을 조합하여 넣어본다. 그리고 안되면 또 다른 방법을 사용한다. 가령 사회공학기법 같은. 그럼 100명 중에 적어도, 최소 한 명 이상은 걸린다. 열 명까지도 걸릴 수 있지 않을까 생각해본다. 운이 좋으면 30명도 걸릴 수 있지 않을까?

주제와는 조금 벗어나지만, 실제로 메신저로 돈 빌리기 사기나 전화피싱과 같은 사회공학기법에 낚이는 사람들이 많은 걸 보면 이게 어렵지 않다는 것을 어느 정도 유추할 수 있다. (약 10년 전에 세이클럽 계정이 털린 적이 있다. 세이클럽 디자인폼으로 메일이 도착했는데, 거기서 비밀번호를 묻기에 그냥 나도 모르게 입력해버렸다. 그리고 난 아바타 캐시를 털렸다.)

소위 전문가들은, 이런 사회공학기법들 때문에 특수문자가 필수로 들어가야 한다고 말한다. 사용자들이 유추하기 쉬운 패스워드를 사용하기 때문에 특수문자를 강제화하는 규칙을 넣는다는 것이다. 그러면 이런 상황에서 사용자들은 회원가입시에 어떤 행동을 취할까.

1. 자신이 자주 사용하는 비밀번호를 넣고 회원가입 버튼을 누른다.
2. 그럼 경고창이 뜨겠지. "특수문자가 필수임ㅋㅋ" 
3. 그렇게 되면 사용자는 짜증을 낸다.
4. 그리고 기존 비밀번호에 ! 또는 !@ 등을 추가해서 회원가입을 완료할 것이다.

안 그럴까? (평범한) 주변 사람 다섯 명을 불러놓고 테스트를 해보면 적어도 두 명은 이런 행동을 취할 거라 확신한다.

• 패스워드 생성규칙의 강제화
  

  ---

특수문자를 강제화 하는 것이 그리 안전하지 않다는 것은 그들도 잘 알고 있을 것이다.(아닌가?) 그럼 왜 관리자들은 패스워드를 강제화 하는 건가? 보안을 생각한 것도 물론 있겠지만, 더욱 큰 것은 아마 관리자 자신들의 심리적 안정감 때문 아닐까?

'사용자들에게 이렇게 시켰으니 적어도 1234와 같은 비밀번호를 사용하지 않겠지'
'유추하기 어려운 강력한(특문이 포함된) 패스워드이니 쉽게 깨지지 않겠지'
'난 보안을 지키기 위해서 최선을 다했어. 해킹 당해도 내책임 아님'

위와 같은 자기 위안들 말이다.

"소프트웨어 누가 이렇게 개떡같이 만들었어"라는 책이 있다. ( 원제목은 Why Software Sucks )
여기서 너무 많이 강화된 보안을 사용자들이 어떻게 생각하고 있는지 잘 이야기 해주고 있다. 외우기 어려운 패스워드를 메모지에 적어놓고 다닌다든가, 강화된 보안 시스템이 귀찮아서 문에다 벽돌을 받치고 누구나 쉽게 드나들 수 있도록 환경을 바꾼다든가 하는 그런 것들 말이다.

패스워드가 기억하기 어려워지거나 너무 자주 바뀌면 쪽지나, 스마트폰에 저장해두게 된다. 아니면 자신이 늘 사용하던 패스워드 한 글자를 특문으로 변경한다든가, 그냥 특문 하나를 더 붙일 뿐이다. 이런 강제적인 규칙들은 오히려 보안성을 떨어뜨릴 수도 있고, 최악에는 사용자들이 떨어져 나가게 된다.

사용성과 보안은 트레이드오프관계에 있다. 보안성을 높이면 사용성이 떨어지고, 사용성을 높이면 보안성이 떨어질 수밖에 없다. 이 둘의 관계를 잘 절충하여 모두 윈윈 할 방법이 요즘 조금씩 제안되고 있지만, 그래도 여전히 이런 불편을 완전히 없앨 수는 없다.

보안을 위해서 어느 정도 사용성 저하는 감수해야 하겠지만, 무턱대고 보안성만을 강조하여 사용자들을 불편하게 만드는 것은 한 번쯤 다시 생각해봐야 할 문제가 아닐까 한다.

"패스워드는 꼭 복잡성을 만족해야 한다." 정말 그런가? 적어도 규칙의 강제화는 답이 아니라고 생각한다.

클로저에 대한 설명은 어렵다. 어렵기 때문에 명확하게 이건 이거다 라고 이야기 하기 힘들다. 이야기 한다 해도 이해하기 위해서는 수많은 배경지식이 필요하다. 아무리 설명을 해봐야 사람들이 이미 알고 있던 부분들이 모두 다르기 때문에 설득을 해야 하는 수준이다. 인터넷에서 클로저에 대한 글들을 찾아봐도 모두 마찬가지이다.

모두가 이건 이거다 라고 설명을 하고 있지만 이해는 쉽지 않다. 자바스크립트에 이 클로저라는 녀석은 C언어에서 포인터를 배울때 만큼이나 날 혼란스럽게 한다. 이건가 싶으면 저거고, 저건가 싶으면 또 이것인 클로저를 잊지 않기 위해서라도 잠시 정리를 해둔다.

짧으면서도 설명하기 쉬운 아래 코드조각을 보자.

sayAlice() 를 실행하고, 리턴받은 함수를 또 바로 실행하고 있다. Step by Step 으로 확인해보자.

 
 

아래 단계를 따라가면서 조사식의 saylAlert 과 alice가 어떻게 변하는지 살펴보자. 

4번 단계가 실행 될 때, 내부의 alice 변수를 참조한다.
sayAlert 변수에 할당된 익명 함수가 선언된 다음에서야 alice 변수에 문자열이 할당 되었다. 이건 함수 내부에 선언된 함수 내부에서 부모함수(?)의 변수에 접근(참조) 할 수 있다는 것을 의미한다. 그리고 이 부분이 클로저가 만들어졌다고 볼 수 있다. 그리고 함수가 끝나서 지역변수들은 사라져야 함에도 불구하고 alice 지역변수는 계속하여 살아있는다. 클로저 때문이다.

좀 더 긴 예제인데, 간략하게 줄였다. 브라우저에서 실행하여 Step by Step 으로 보자.






여기서 6번이 중요포인트인데, 익명함수에 진입 할 때, num의 값이 40으로 확인 할 수 있다는 것이다. 기본적으로 num은 newClosure의 지역변수 이기 때문에 함수의 생명주기가 끝남과 동시에 소멸되어야 하는 변수이다. 하지만 클로저가 생성됨으로 인해서 이 변수는 그대로 살아있게 된다. 불필요한 메모리 릭을 방지하기 위하여, 이 변수를 사용한 뒤에 더이상 필요 없다는 판단이 들면 alert('num: ' + num); 문장 뒤에 num = null; 을 추가 시켜주자. 

인터넷익스플로러가 7 버전 까지 나왔을 때, 파이어폭스는 한창 강세를 보이고 있었다. 파이어폭스의 점유율을 의식하여 부랴부랴 7 버전을 내 놓았으니 말이다.

언제부터인가 IE6를 버리고 파이어폭스를 쓰기 시작했는데, 그 때가 아마 본격적으로 웹개발을 시작하고 얼마 안돼서였을거다. 당시 파이어폭스의 확장기능에 한창 매료 되어서 헤어나올 수가 없었다. 그중 단연 최고는 파이어버그 라는 개발자도구 였다.

원하는 곳의 DOM 구조를 바로 파악할 수 있고, 파일을 변경할 필요 없이 실시간으로 수정하며 적용된 모습을 볼 수 있었다. CSS 수정, 적용이 바로바로 가능했고, 페이지 로딩속도 및 HTTP status 코드는 물론이고, 자바스크립트 디버깅까지 지원하여 이게 없으면 개발이 불가능할 정도였다.

파이어폭스가 버전업데이트가 되어서 파이어버그가 동작하지 않으면 파이어폭스 업데이트를 미룰 정도였다. (나말고도 많은 사람들이 그랬을거다) 1.4 버전인지 1.5 버전까지 사용하고, 요즘엔 잘 사용하지 않고 있어서 어떻게 발전 하였는지 잘 모르겠다. 

파이어폭스에서는 제대로 개발을 할 수 없는 환경으로 터전을 옮기고 나서 IE 에서 돌아가는 여러가지 개발자도구를 찾아서 사용해보았다. 파이어버그에 비하면 턱없이 부족한 툴 들이었지만, 어쩔 수 없이 불편함을 감수하고 사용했다.

그러다가 IE8 버전이 나오고, 새로이 추가된 개발자 도구 라는 것을 보고 커다란 발전에 기쁨의 눈물을 흘렸었다.

Dom 셀렉터, CSS 선택수정, 중단점을 삽입할 수 있는 자바스크립트 디버깅, 콘솔창 추가로 개발환경이 무척이나 편리해졌다. 이는 IE9으로 오면서 더욱 강력해 졌는데, 이에 대해서 소개를 해볼까 한다. (자바스크립트와 콘솔 위주로 감)


콘솔창

인터넷익스플로러를 실행하고 F12 를 누르면 아래와 같은 개발자 도구가 열린다.

왼쪽 탭에는 HTML, CSS, 콘솔, 스크립트 등등이 있고, 이 선택에 따라서 오른쪽 탭 영역의 UI가 변경된다. 콘솔탭을 선택하면 빈 화면이 덩그러니 나타나는데, 맨 하단에 보면 뭔가를 입력할 수 있는 입력창이 존재한다.


여긴 자바스크립트나 기타 DOM객체를 직접 입력하여 확인해 볼 수 있는 공간이다. 실제로 사이트가 전부 로드된 상태에서 콘솔창에 관련 객체 이름을 써 넣기만 하면 그에 따른 정보가 출력된다.


테스트 페이지로 만든 곳의 this 객체 정보를 호출해봤다. 단지 this 라고만 입력했을 뿐인데, 현재 document의 this객체에 대한 정보가 나타난다.

테스트 페이지에 아래와 같은 HTML 태그를 추가했다.
그리고 콘솔창에서 위 엘리먼트에 대한 객체 정보를 호출해보았다.


표준 HTML DOM method인 getElementById() 를 사용하여 객체를 호출하거나, 그냥 ID 값만을 입력하여 객체에 대한 정보를 확인할 수 있다.

이 콘솔창에서는 다른 콘솔창과 마찬가지로 페이지에 설정된 자바스크립트를 실행시킬 수 있는데, 방법은 매우 간단하다.

 
위와 같은 자바스크립트 코드를 추가하고, 콘솔창에 함수 이름을 입력하면 바로 실행이 된다.

여기 콘솔창에서 사용할 수 있는 여러가지 내장함수들이 존재 하는데, 이는 IE8은 물론이고 웹킷, 모질라계열에서도 비슷한 동작을 한다.

window.console.log	console.log("로깅용 메시지")	로그 : 로깅용 메시지
window.console.error	console.error("에러 메시지")	: 에러 메시지
window.console.info	console.info("정보 메시지")	: 정보 메시지
window.console.warn	console.warn("경고 메시지")	: 경고 메시지
window.console.dir	console.dir(오브젝트)	오브젝트 내용이 출력
window.console.assert	console.assert(식, "메시지")	식이 틀릴 경우 메시지가 출력
window.console.clear	console.clear()	콘솔창의 내용을 모두 삭제함

콘솔창에서 사용할 수 있는 내장함수는 위와 같고, 각각 실행 하였을 때 나타나는 메시지 이다. 실제로 아래와 같은 코드를 작성하여 테스트를 해봤다.

결과창을 보면, 우리가 예상한 결과와 동일하게 출력된 모습을 볼 수 있다. console, 또는 window.console 이라고 입력하면 console에 포함된 메소드들이 출력되니 직접 입력해서 확인 해보자.

** 참고로 console.dir 은 IE9 에서 지원하는 신규메소드로 IE8에서 동작하지 않는다. console.dir(object); 로 실행 하며, 객체의 내용을 좀 더 상세하기 표현해 준다.

기존에 alert 과 document.write, iframe 등으로 디버깅을 하던 불편함은 콘솔창을 사용하면 말끔히 해결된다. 초반엔 익숙하지 않기 때문에 어색하겠지만 지속적으로 사용해보면 예전으로 다시 돌아가기 힘들어질 것이다. 

사용하지 않고 있던 사람들이라면 이번 기회에 한번 사용해보자. 이러한 콘솔창은 IE8 이상, 크롬, 사파리, 파이어폭스 에서 기본적으로 지원하고 있다.


2부. IE9으로 디버깅 하기 (2) - 자바스크립트 디버깅

IE9이 출시 되었습니다. 물론 꽤 오래전에 출시되었죠. 베타버전부터 사용중 이었고, 정식버전이 출시되기를 꽤 기다렸습니다. 기다렸던만큼 출시된 정식버전 IE9은 꽤 높은 완성도가 높았습니다.

기존에 있었지만 부각되지 않았던 기능들, 그리고 새롭게 추가된 기능들을 위주로 하여 IE9을 알아보겠습니다.

1. 주소창 검색

IE8에서 IE9으로 넘어오게 되면서 전반적인 UI가 변경되어 매우 심플해졌는데요, 가장 크게 변경된 부분은 주소창과 검색창의 통합입니다.

기존에는 웹사이트 주소를 입력하는 주소창과 검색을 담당하는 검색창이 분리되어 있었습니다. 기존에 검색창은 검색제안이나 비주얼서치 등의 새로운 기술을 내놓음에도 불구하고 접근성의 문제로 자주 쓰이지 않았죠.

 

이번 주소/검색창의 통합으로 검색제안이나 비주얼서치 등이 좀 더 부각되었으면 하는 바람입니다.
(링크 비주얼서치/검색제안 보러가기)

부가기능 갤러리에 가보시면 검색과 관련된 좀 더 많은 애드온들을 찾아 볼 수 있습니다. 한번 찾아가셔서 기존에 추가 되어 있는 Bing 이외에 구글이나 네이버등을 추가하여 좀 더 편리한 주소창 검색을 이용해보세요.
(링크 부가기능 갤러리 보러가기)

2. 사이트 고정 (1)

---

IE9은 아쉽게도 윈도우 XP 이하 에서는 제공되지 않습니다. 윈도우 비스타 SP1 이상에서 설치하여 사용할 수 있는데, 윈도우7을 사용중이라면 IE9과의 시너지 효과가 매우 커집니다.

IE9 에서는 사이트 고정이라는 새로운 기능을 내놓았는데요, 사이트를 주소표시줄에 고정시켜놓고, 필요할 때 마우스 원클릭으로 접속 할 수 있도록 하는 기능입니다.

윈도우7 시작표시줄에 joinsmsn 사이트를 고정시켰습니다. 파비콘이 아이콘이 되어 원클릭 접속이 가능합니다. 이는 기존에 사이트바로가기와 크게 다른 점은 없는데요, 나중에 설명드릴 사이트 점프 기능에서 차이점이 드러납니다.

사이트고정 기능으로 사이트에 접속하게 되면, 위 이미지에서 보이시는 것과 같이 이 창은 joinsmsn 을 위한 사이트 입니다. 라고 파비콘으로 표시를 해줍니다. 좀 더 깔끔한 모습을 원하신다면 파비콘의 크기를 64*64 사이즈로 변경해주세요.

고정방법은 여러가지가 있지만 가장 간단한건 고정시키고 싶은 사이트에 접속 한 뒤 그 사이트가 열려있는 탭을 작업표시줄로 잡아끄는 것 입니다.

작업표시줄에 등록이 되면 사이트의 파비콘이 아이콘이 되며, 사이트 접속시 고정된 사이트임을 알려주게 됩니다.

2. 사이트 고정 (2)
사이트를 고정하게 되면 보너스 기능을 하나 더 사용할 수 있습니다. 이건 웹사이트에서 지원을 해 주어야 하는 내용이지만, 지원만 된다면 서비스를 좀 더 편리하게 사용할 수 있습니다. 바로 점프리스트 기능입니다.

페이스북을 사이트 고정시켜놓고, 아이콘에서 오른쪽 버튼 혹은 왼쪽클릭 후 잡고 끌면 위와 같은 메뉴가 나타납니다. 페이스북 같은 경우는 뉴스나 메시지, 이벤트 등의 메뉴로 바로 갈 수 있고, 트위터나 위 이미지의 joinsmsn 에서도 기능을 제공하고 있습니다. 

IE8에서 웹슬라이스 라는 기능을 제공했었습니다. 신기능이지만 잘 사용하지 않는 기능중 하나죠. 개인적으로 이 기능도 웹슬라이스의 뒤를 따르지 않을까 걱정도 되지만 이런 기능들이 잘 활성화 되면 좀 더 웹을 편리하게 사용할 수 있을 텐데 말이죠. 기능의 활성화를 빌어봅니다.

조만간 사이트에 점프리스트 추가 하기를 포스팅 할 예정입니다. (매우 간단합니다.)

3. 보안 강화

MS에서 IE8 출시부터 강조했던 것이 하나 있는데, 바로 보안입니다. IE8 에서는 XSS필터, ClickJacking방지, 탭색변경, 스마트주소표시줄, 스마트스크린 등의 보안 기능을 대거 추가 하였고, 내부적으로 메모리 보호에 강화된 점을 내세웠죠. IE9 에서도 물론 보안 강화를 갖고 나왔습니다. 이미 IE8에서 웬만한건 추가 했기 때문에 특별한 것은 없고, 눈에 띄는 거라면 추적방지 기능과 엑티브액스 필터링 정도 입니다.

여기서 B라는 회사가 광고속에 삽입한 쿠키가 제 3사 쿠키입니다. (** 쿠키는 웹상에서 활동하는 정보를 갖고 있을 수 있는 일종의 임시파일 입니다.)

이러한 제 3사 쿠키의 활동을 막는 것이 추적방지기능 입니다. 이 추적방지 기능은 IE8에도 제3사쿠키방지 라는 옵션으로 제공되던 보안서비스이지만, 이를 좀 더 강화 했습니다.

아래 링크에 접속하여 외부 사이트에서 제공되는 블랙리스트 사이트를 IE9에 추가할 수 있습니다.
(링크 http://iegallery.com/kr/trackingprotectionlists/default.aspx)

의외로 제3사쿠키를 활용하는 사이트들이 많이 있습니다. 스스로도 개인정보 보호에 힘써주세요.

4. 자주 방문하는 사이트

about:blank 라는 문구가 낯이 익으신 분들은 저처럼 성격이 좀 급하신 분들 아닐까 합니다. 웹사이트의 시작페이지로 about:blank 를 넣으면 브라우저가 실행됨과 동시에 빈페이지가 뜨기 때문에 조금이나마 쾌적한 인터넷 환경을 만들 수 있습니다.

IE9 에서는 about:Tabs 라는 시작페이지를 공식적으로 지원하기 시작했습니다. 브라우저를 실행하면 방문했던 페이지들을 빈도수 별로 리스트업하여 보여줍니다.

 

어떤 브라우저 툴바에서도 비슷한 기능을 지원하는 것으로 알고 있는데요, IE9 에서는 자체적으로 지원하니 더이상 툴바에 의존하지 않아도 됩니다.


5. 성능
빠릅니다. 많이 빨라졌습니다. IE9 사용하시다가 IE8 이하 버전으로 못돌아갑니다. 자바스크립트 성능 향상이니, 뭐니 어려운 말 하지 않겠습니다. 설치하셔도 후회하지 않으실 겁니다. 은행권이나, 기타 대형 포털들에서도 무리없이 사용 가능하니, 망설이고 계시다면 한번 설치해보시는게 어떨까요.


6. 아쉬움
A. 확장기능
- IE9이 아무리 빨리지고, 보안성이 향상 되어도, 절대 안쓰는 사람들이 있습니다. 그 사람들이 꼽는 가장 큰 이유는 아무래도 확장기능 이 아닐까 합니다. 얼마 없기도 없을뿐더러 그나마도 찾기가 매우 어렵습니다. 윈도우모바일6.5 이하버전의 스마트폰을 사용하는 기분입니다.

아, 확장기능이 있기는 합니다. 다만 그 이름이 액티브엑스 라는게 문제지만요.

B. 부가기능
- 웹슬라이스나, 검색제안 등이 활성화가 안되는 것이 많이 아쉽습니다. 사용하기 어려운 것도 아니고, 만들기 어려운 것도 아닌데 의외로 많은 분들이 모르고, 쓰지 않습니다. 무엇이 문제일까요. 개발자스러운 접근방식? 검색제안 같은 것은 주소창과 검색창이 합쳐진 지금은 조금 기대가 됩니다만 웹슬라이스는 도무지 답이 없네요.

C. HTML5
- IE9의 특징 중 하나로 꼽는 것이 웹표준지원, HTML5의 지원 입니다. 하지만 이 지원 수준을 보면 참담합니다. 


다른건 봐야 머리만 아프니, 점수만 공개합니다. 일반 사용자야 브라우저를 사용하는데 HTML5 지원 미지원 여부가 뭐 그리 큰 차이겠냐만 개발자들에게는 참담합니다. 지원되지 않는 것들은 어떤 방식으로 구현을 해야 할지, 고민부터 앞섭니다. 

타 브라우저에 비해서 업데이트도 쉽지 않은데 말이죠.

7. 끝

언제나 이런 것을 선호한다. 지극적인 제목, 뭔가 있어 보이는 제목. 이런 것들로부터 독서의 욕구를 느낀다. 물론 이와는 다르게 누군가의 추천에 의해서도 다음 독서의 타겟이 정해지기도 한다. 하지만 어떤 경우에도 해당되지 않는 부류들의 책이 있는데, 그 중 하나가 자기계발서 이다. 이렇게 저렇게 하라는 자기계발서를 그다지 좋아하는 편은 아니고, 또 자기계발서를 단지 추천만으로 읽기엔 그다지 내키지 않는 부분(링크)도 있다. 개인적으로 자기계발서는 판타지나 무협지처럼 이도 저도 아니고 그냥 뭔가 읽고 싶어서 보는 경우에 속한다. 하지만 이 책은 예외로 추천을 통해 접하게 되었다.

http://xrath.com/ 의 rath 형으로부터 추천 받은 책이고, 이 형은 애자일 컨설팅의 김창준 님으로부터 추천을 받았다고 한다. 김창준님이 추천했다고 하는 말을 듣고 바로 읽기 시작했다. 결론부터 말하자면 자기계발서이다. 여느 책과 마찬가지로 이래라 저래라 시키지만 정작 따라 하기는 정말 힘들다. 그럼에도 이 책은 추천할 만 하다. 보자, 지금부터.

대부분의 사람들은 자신들의 인생에서 이루어야 하는 몇 가지 목표를 갖고 살아간다. 물론 목표 없이 하루하루를 살아가는 사람도 있지만, 이런 사람들 조차 살면서 한번쯤은 목표를 세워 실천하려 노력해 봤을 정도로 많은 사람들이 목표를 가지고(또는 가졌었거나) 살아간다. 목표를 가졌었는데 지금 제대로 실천하지 못하는 사람들의 특징이 있는데 바로 목표의 계획을 너무 상세하게 설계 하려 한다는 점이다.

목표의 설계는 삶을 사는데 있어서 꼭 필요하다. 목표는 개개인의 삶에 어떤 동기를 부여해 주고, 이 동기 라는 것은 새로운 일에 도전하여 무엇인가를 성취하거나, 혹은 현재 삶을 유지하게 하는데 있어서 매우 중요하다.

결국 목표라는 것은 삶의 동기부여를 위해 이에 대한 계획을 세우고, 실천하는 것이다. 성공하는 삶을 위해 목표를 치밀하게 계획하여 삶을 살고 있다. 이러면서 우리는 점점 목표설계중독자로 변해간다. 

나는 지금 "목표는 중요하지만 버려야 한다." 라는 역설적인 주장을 하려 하고 있다. 물론 이것은 내 주장이라기 보다 이 책에서 말하고 있는 내용이다.

책은 목표를 버리라고 우리를 설득하며 시작한다. "수많은 성공한 사람들은 목표지향적 삶을 살았는데, 목표를 버리라니." 이런 생각을 하고 책을 펼치게 된다. 그리고는 곧 목표를 버리라고 하는 것이 진짜로 목표 를 버리는 것이 아님을 알고는 조금 더 흥미를 갖게 된다.

책은 여덟개의 작은 챕터를 통해서 목표 없는 삶을 살라고 말하고 있다.  아니 정확하게 말하자면 목표를 버리고 테마를 정해서 삶을 살라고 말하고 있다. 상세한 목표를 느슨한 목표로 변경하고, 이 느슨한 목표를 테마로 정해라. 다음 몇몇 문장은 이 책의 내용을 잘 축약하여 나타내고 있다.
 

위 문장들이 너무 길다면 다음 한문장으로 이 책의 주제를 나타낼 수 있다.

빙빙 돌려 말해왔는데, 주제는 상세한 지도대신 나침반을 사용하여 삶을 살라는 것이다. 

나는 초등학교(그 때는 국민학교) 시절, 막연히 컴퓨터로 먹고 살아야 겠다고 생각했고, 그에따른 별다른 계획들은 없었다. 중학교 시절 선생님이 나에게 뭐가 되고 싶냐고 물었을 때 어물거리며 전산관련일을 하고 싶다고 답했지만 어느 대학 어느 학과를 나와서 어디에 취직하고 어떤 일을 할 것이다.'라는 상세한 계획은 없었다. 

심지어 어떤 직업군을 택할 것인지에 대한 생각도 없었고 전산과 전자과 컴퓨터과가 모두 동일한 학과인줄 알았다. 난 왜 그런 계획을 미리부터 세우지 않고 알아보지 않고 살았을까. 라며 스스로를 자책하던 시절이 있었는데, 지금 컴퓨터를 하면서 만족할 만한 생활을 하고있는것을 보면 그래도 그렇게 나쁘지는 않았던 것 같다.

다만 문제는 목적을 달성하여 지금까지 사용하던 나침반이 더이상 필요가 없어진 것인데, 이를 위해서 조만간 또다른 나침반을 마련해야 할 것 같다.

얼마전 jquery mobile 알파버전이 릴리즈 되었습니다. 그리고 지금 알파2 버전이  최종버전 입니다.

• 모바일용 게시판으로 변환
• 디시인사이드 로그인 가능
• 디시인사이드 게시물 작성 가능
• 디시인사이드 댓글 작성 가능
• 루리웹 로그인 가능
• 루리웹 게시물 작성 가능
• 루리웹 댓글 작성 가능

1983년도 2월생과 3월 생에게는 한 달이라는 시간. 그 이상의 큰 차이점이 있다.

바로 대한민국에 존재하는 "빠른" 이라는 개념이 그것인데, 한달로 생기는 이 빠른이라는 차이가 결정짓는 인생의 요소들은 실로 어마어마하다고 할 수 있다.

물론 모든 2월생과 3월생이 차이가 나는 것은 아니다. 1월 2월에 태어남에도 불구하고 "혜택" 을 받지 못한 아이들도 많이 있고 또, 4월생임에도 불구하고 부모님의 노력(?) 으로 한학년 일찍 학교에 들어가는 경우도 있다. 음력을 이용해서 말이다.

'일년을 이익보자.' 라는 생각이 우리의 부모님들을 이렇게 만들었을까.

아웃라이어(OUTLIERS) 카테고리 자기계발 지은이 말콤 글래드웰 (김영사, 2009년) 상세보기

말콤글래드웰은 자신의 저서 "아웃라이어" 에서 이야기 하고 있다. "캐나다에서 프로하키선수가 되려거든 1월달에 태어나라." (사실 정확히 이런 이야기를 한것은 아니지만 요약하자면 말이다.)

10살의 아이를 놓고 신체적 비교를 해보면 같은해 1월생은 12월생보다 신체적으로 발달이 빠르다는 것이다. 이에 대한 근거로 프로 하키선수들의 생일들을 모두 찾아 비교해보고, 그 지역의 주니어 하키선수들의 생일을 찾아 표로 만들어 제시했다.

이는 비단 하키선수들의 체력비교에만 국한되지 않는다. 도서 "아웃라이어" 에 따르면 상반기에 태어난 아이의 성적이 하반기에 태어난 아이들의 그것보다 최대 12%정도 높다는 연구결과도 나와있다고 한다.

이 학업성취도와 관련한 내용은 유치원시기부터 밀접한 연관성을 맺는데 몇 개월 앞서 태어난 아이는 좀 더 듣고, 좀 더 보고, 부모님과 함께하는 시간이 좀 더 많기 때문에 익숙함에 있어서 뒤늦게 태어난 아이들을 앞선다. 여기서 교사들은 익숙해서 잘 하는 것과 정말 똑똑해서 잘 하는 것을 혼동하게 되는데, 어찌되었든 결과적으로는 잘하는 아이를 좀 더 똑똑하고, 우수한 아이로 평가한다. 이러한 현상은 초등교육에 진학해서도 마찬가지의 결과를 낳고, 이는 곧 우열반으로 가려져 잘하는 아이들은 점점 더 잘하는 아이로 만들어지고, 이 격차는 점점 더 심해진다.이는 피그말리온 효과와도 어느정도 관련이 있다고 볼수 있다.

"아웃라이어" 에서는  "있는자는 더 풍족하게 되고, 없는자는 더 빼앗기리라." 라고 이야기 하고 이를 마태복음 효과라  이야기 한다.

다시 1983년도 2월생과 3월생의 차이로 돌아가보자. 학업성취능력 또한 인생을 결정하는 요소들 중 하나이기도 하지만 정말 큰 차이 중 하나가 대한민국에 있다. 바로 대학진학을 위해서라면 누구나 응시해야 하는 대학수학능력시험. 수능시험이다. 실제로 83년도에 태어난 학생들이 응시한 01년도(02학번)의 시험과 83년 빠른 학생들이 응시한 00년도(01학번)의 시험의 난이도 차이는 실제로 엄청났다. (참고자료 링크)

01년도와 02년도 모두 난이도 조절이 실패한 대표적 수능으로 꼽고 있는데 그 이유가 01년도는 너무 쉬워서, 02년도는 너무 어려워서이니 그 사이의 공백은 다른 어떤 경우보다 심했을 것으로 예상한다.
실제로 02년도 수능 응시자들은 생각보다 낮게 나온 점수 때문에 많은 수험생들이 대학교에 하양지원을 했던 것으로 기억한다.

시험이 쉽고 어렵고의 차이로 인해 가장 큰 영향을 받는 것은 상위 20% 하위 20%를 제외한 나머지 60%의 학생들이다. 이들은 시험 난이도에 가장 큰 영향을 받는 학생들로, 시험이 어려울 경우 조금 유리하고, 시험이 쉬울 경우엔 조금 불리하다. 이 중간 계층들은 대부분이 실수가 잦고, 광범위한 범위와 기본 개념이 약하다. 때문에 차라리 어려운 편이 상위권 학생들과 조금이나마 격차를 줄일 수 있다.

때문에 01년도 수능 응시생들은 많은 수의 학생들이 손해를 보았고, 02년도의 수능 응시생들은 01년도에 비해 비교적 많은 학생들이 이득을 보았다.

01년도에 수능시험에 응시한 학생들 중 빠른 83년도 생이 있다면, 이 학생들은 환경조건 때문에 60%의 그룹에 속할 가능성이 높다. 이들이 "빠른" 이 아닌 정상적인 계단을 밟아왔다면 결과가 달라졌을까? 같은해의 후반기에 태어난 아이들에 비해서 여러가지 면에서 좀 더 혜택을 받았을 수도 있다. 그리고 좀 더 나은 대학에 진학하여 다른 삶을 살았을 수도 있다. 이런 점을 생각해본다면, "빠른" 아이들은 과연 일년을 이득 본 것이었을까?

"아웃라이어" 에서는 이와 같은 마태복음 효과에 대한 이야기를 비롯하여, 환경에 영향을 받아 천재가 된 사람들, 그리고 그 반대로 천재이면서도 환경의 영향을 받아 빛을 보지 못한 사람들의 이야기를 풀어내고 있다.

마태복음효과가 궁금하고, 두 천재의 전혀 다른 길이 궁금하고, 아시아인이 수학을 더 잘하는 이유 따위가 궁금하다면 한번 이 책을 펼쳐보는 것도 나쁘지 않겠다.

이 책을 읽기 시직하는 것이 당신 성공의 시작일지 혹시 모르겠다.

$.fn.Alert = function() {
	return alert(this[0].id);
}

이걸 유효범위로 만들기 위해 아래와 같이 수정한다.

(function($) {
    $.fn.Alert = function() {
	return alert(this[0].id);
    }
})(jQuery);

이렇게 되면 $ (여기서는 jQuery) 변수를 익명함수의 인자값으로 넘기고, 익명함수는 jQuery 를 $로 받아서 플러그인에서는 계속 $를 사용할 수 있다.