Month: May 2006

인코딩을 모르는 문서 디코드하기

by

피드를 읽다가 BeautifulSoup 새 버전이 나왔다는 소식을 듣고, 뭐가 바뀌었는지 궁금해서
홈페이지를 가 봤습니다. 그런데, 전에 없던
cjkcodecs, iconvcodec에 대한 링크가 갑자기 생긴 것입니다.
오잉 BeautifulSoup에서 웬 cjkcodecs 링크람~ 하고 자세히 봤더니
옆에 chardet라는
인코딩을 자동으로 결정해 주는 라이브러리가 붙어있는 것입니다!

호오.. BeautifulSoup은 지금까지 취해왔던 “개떡같이 쓴 것도 찰떡같이 알아듣는다”를 충실히 지키기 위해, 이제 인코딩이 언급되어 있지 않은 문서도 마구 디코딩을 해 줄 장정인가봅니다;;

Mark Pilgrim이 만든 chardet는 작년 8월에 나온 것인데, 노가다로 일일이 디코딩해보고 결정하는 것이 아니라, 각 인코딩 별로 보통의 빈도에 대한 통계
자료를 기반으로 해서 결정한다고 합니다.
나온지는 제법 오래된 것인데, 참 신기하고 재미있네요.
이제 트랙백 받는 것도 chardet 붙여서 똑똑하게 받아 봐야겠습니다.
^.^; (통계자료는 모질라 안에 들어있는 것을 포팅한 것이라고 합니다.)

사고 조사는 두 단계로 이루어집니다

by

종종 공강 시간에 낮잠을 잘 때 켜 두는 내셔널지오그래픽채널의
《항공사고수사대》를 보다가, 뭔가 느낌이 오는 부분을 발견해서 기록으로
옮겨 봅니다. 흐흐. 요새는 TV에 재미있는게 참 많아요~ -O-

그 에피소드는 1990년의 British Airways 5390편 사고를 다루고 있는 시즌 2 에피소드 2 였습니다. 이 사고는 기장 앞의 창문이 뜯겨나가서 기장이 밖으로 튕겨나가고 부기장이 극적으로 비상착륙을 시켜서 결국엔 사망자 없이 무난히 마무리한 사건입니다. 그런데, 창문이 갑자기 뜯겨나간 이유가 조사가 진행되면서, 정비기사가 창을 고정하는 볼트 크기를 설계상의 크기가 아니라 다른 것을 끼운 것이 발단이 되어서, 상공에서 풀려서 사고가 생기게 되었다는 것이 밝혀졌습니다.

정비기사는 원래 끼워져 있던 볼트와 같은 크기의 볼트로 갈았을 뿐이라고 주장하며 전혀 문제가 없을 것이라고 했는데, 결국 그 비행기에는 원래부터 잘못된 볼트가 끼워져 있었고, 잘못된 볼트 크기에 맞게 정비기사가 역시나 또 작은 볼트를 끼운 것이었습니다.
다른 일반적인 사고에서는 정비기사 위로 직계 상사 몇명이 짤리면 그만이겠지만, 역시 우리의 항공사고수사대! 돈이 많이 드는 사업이니 만큼 철저한 조사를 합니다.

Accident investigation certain aircraft comprises two parts. First part is what’s happened and that’s usually well to the easy bit. And second part is why did it happen. — Stuart Culling (Accident Investigator, AAIB)
항공기 사고 조사는 두 단계로 이루어집니다. 첫 번째는 어떻게 일이 일어났는가를 조사하는 것인데, 보통은 쉬운 부분입니다. 두 번째 부분은 바로 왜 그런 일이 일어났는가를 조사하는 것입니다. – 스튜어트 컬링 (사고조사자, AAIB)

음.. 그러니까, 사고의 원인을 “정비기사가 볼트를 잘못 끼운 것”이나 “4년 전에 조립한 곳에서 잘못 끼운 것”이 아니라, 더 깊숙한 심리적인 원인을 분석했습니다. 조사자는 정비기사의 숙련도를 고려하여 자기의 책임으로 몰아가는 것처럼 느끼지 않게 최대한 배려하면서 어떤 경위로 정비기사가 그런 선택을 하게 되었는지 조사를 해서 결국은 더 깊은 원초적인 원인을 분석했습니다.

원래 항공기를 제작한 회사에서는 정비 매뉴얼에 모든 부품의 규격을 적어 두고
그에 따라 항상 확인하여 쓰도록 되어 있었지만, 실제로 정비창에서는 매뉴얼을
일일이 확인하여 작업하면 시간이 3배가 넘게 걸려서, 항공기의 스케줄에는
절대로 맞출 수가 없다는 것이었습니다. 또한, 인력 부족과 과도하게 빡빡한
항공 스케줄을 이유로 여러 사람이 반복적으로 안전을 확인해야 할 정비 공정
중에서 많은 부분을 정비기사 개인의 육감적인 판단에 맡기고 있었다고 합니다.
정비기사도 그런 부분에 대해서 상부에 얘기하고 싶었지만, 따로 따로 바쁘게
다른 시간에 떨어져서 일하다 보니 그런 기회가 적었다고 합니다.

결국 조사팀에서는 항공사에 품질관리 시스템을 점검하고, 기사들이 피드백을
주는 것을 장려하도록 했으며, 항공 당국에는 안전에 결정적인 영향을 주는
요소에 대해서 재직 중에도 계속 테스트를 하도록 권고했다고 합니다.

소프트웨어 프로젝트에서도, 많은 팀에서 프로젝트 일정에 쫓기다 보면, 우선
버그를 해결하고 나서는 그 버그가 뭔지 버그 트래커에 기록이 남으면 무척
다행이지만, 사실 상 많은 곳에서 그냥 “아차!”하고 남들 보기 전에 얼른
고치거나, 다른 사람이 만든 버그를 고친 경우에는 괜히 원망 한 번하고 끝납니다.
단순히 “잘못해서” “실수로” 라던지, “포인터를 잘못 접근해서” 같은 직접적인
이유 말고도, 근본적이고 기초적인 “모니터가 작아서 앞뒷 부분이 잘 안 보여서”
라던지 “의자가 불편해서 결국 치질에 걸리고, 자세를 자주 바꾸다보니 결국에
코드 집중도가 떨어진다” 같은 좀 더 사람에 초점을 맞춘 원인을
가끔씩은 분석하면 앞으로 발생할 여러 문제를 한꺼번에 잡아버릴 수도
있지 않을까 생각을 해 봤습니다.

원래 잘 돌아가던 코드를 그냥 다른 데 썼을 뿐인데,
그게 나중에 대형사고를 일으킨 경험을 해 본 적이 있는
게.. 엉뚱한데에 참 와닿네요 ^.^;;

인터넷 금융 공개 표준 프로토콜의 여러가지 구조

by

앞에서 살짜쿵 얘기해 보았던
〈인터넷 금융 서비스 플랫폼 문제의 현실적 대안〉에서 공개 표준 프로토콜을
도입하는 방법에 대해서 조금 더 자세하게 살펴 보겠습니다. 물론,
photon님께서 말씀하신
대로 단기적인 해결책은 우선 현재 돌아가는 형태 안에서 플러그인을
많이 쓰이는 대안 플랫폼들에 포팅하는 것이 되겠습니다. 장기적인 안을
고려하자면 여러 다른 형태도 고려해 봄 직 합니다.

자바스크립트 API로 표준화하기

이 방법은 자바스크립트 API를 “인증서를 확인하라”, “개인 인식 번호를
전송하라”, “송금 확인을 해서 싸인하라” 등의 기초적인 기능을 수행하도록
표준안을 만드는 것입니다. 그러니까, 세션 암호화 등의 밑에 깔리는
것들은 HTTPS를 이용하고, 인증서 확인과 관련된 것을 웹브라우저 플러그인으로
들어가거나 다른 방법으로 자바스크립트의 함수를 호출하는 것으로 해결을 하는
방법입니다. 도식화 하자면, (이 그림은 일반인의 이해를 돕기 위해 과하게
단순화를 한 것이며, 실제 구조를 정확하게 표시한 구조도가 아닙니다.)

자바스크립트 API로 표준화 구조

대충 모양은 이렇게 나오는데, 예를 들자면
W3C XMLHttpRequest
같이 자바스크립트 오브젝트를 정의하는 형태이면 적당할 듯 합니다.

자바스크립트 API를 그냥 중간전달자로만 활용하기

이 구조는 지금 이니텍과 소프트포럼에서 채택하고 있는 방식과 비슷한
것입니다. 정확히는 이니텍과 소프트포럼은 Active X 오브젝트나
플래시 오브젝트를 대신 경유하고 있지만, 경유하는 과정을 굉장히 단순하게
전달자로만 쓴다는 점에서는 비슷합니다.
원래는 128비트 암호화를 웹브라우저에서 HTTPS로 지원하지 않아서, 암호화를
하려다 보니 이런 형태를 띠게 되었습니다. 이 구조에서는, 자바스크립트
API를 제공하기는 하는데, 거의 의미없이 그냥 전달만 합니다. 안에
전달 받은 곳에 구체적인 프로그램 동작이나 사용자의 행위를 요구하는 것에
대한 정보가 암호화되어 저장됩니다.

이 경우에는 호출하는 방법도 물론 표준화를 해야겠지만, 매우 간단하기 때문에
별로 흉내내는 것도 어렵지는 않아지고 플랫폼에 따라서 선택적으로 취할 수도
있습니다. 자세한 내부 정보의 바이너리 포맷을 정하는 것이 표준화에서 중요한데,
RFC3261 SIP 같이 텍스트
기반의 프로토콜을 채택할 수도 있고,
RFC2138 RADIUS같이
바이너리 프로토콜을 채택할 수도 있습니다.

바닥부터 TCP또는 SSL기반의 프로토콜을 만들기

독일에서 쓰는
HBCI (Home Banking Computer Interface)에서 쓰는 방식입니다.
이 방식에서는 HTTP나
SMTP같이 아예
바닥부터 프로토콜을 새로 만들어 버립니다. 이렇게 되면, 꼭 웹브라우저에 의존할 필요가 없기 때문에,
플랫폼이 GUI 프로그램이 될 수도 있고, 텍스트 콘솔이 될 수도 있고,
웹 브라우저에 들어갈 수도 있고, 심지어 집 현관문에 붙은 인터폰에
들어갈 수도 있습니다. 구조를 보면 대략,

바닥부터 만든 프로토콜 구조

이렇게 볼 수 있습니다. 바닥부터 만드니 만큼 호환성에 대한 테스트가
많이 이뤄져야 하고, 구현 작업에서 전반적인 작업량도 많습니다.

RPC 기반의 프로토콜

네트워크 부분을 신경쓰지 않고 그냥 서버를 호출할 수 있게 RPC
프로토콜을 활용하는 방법입니다. 인터넷을 경유하는 RPC 프로토콜로는
SOAP이나
XMLRPC 같은 것이 많이 쓰입니다.

RPC 기반의 프로토콜 구조

전체적인 구조는 이렇게, 클라이언트가 호출하는 RPC API를 정하고,
네트워크에서 돌아가는 RPC 클라이언트 – 서버 구간은 기존 표준을
활용하게 됩니다.
Blogger API 같은 것이 대표적인 RPC 기반 표준 API입니다.
SOAP와 XMLRPC 둘 다 밑에 HTTPS를 깔고 들어갈 수 있기 때문에,
암호화 채널에 대해서도 크게 복잡하지 않습니다.

표준 API만 정하고 SDK 제공

이 방법은 아예 프로토콜을 정하지 않고, 금융회사나 보안솔루션회사에서
제공해 주는 SDK(Software Development Kit)를 이용해서 최종
프로그램을 컴파일하는 방식입니다.
여기서 각 SDK의 API를 통일해서 표준 API만 지키면 아무 회사의
SDK라도 사용할 수 있게 하는 것입니다.

API만 표준화 한 구조

실제 예를 찾아보면, IETF Draft 상태인 Diameter API가 그런 비슷한
방법입니다. 이 표준안에서 정의된 API로 Sun과 Toshiba등의 회사에서
SDK를 만들었기 때문에 어느 회사의 라이브러리를 쓰느냐와 상관 없이
그냥 링크를 할 수 있습니다. (Diameter는 범용 표준 인증/과금 프로토콜인데,
TCP와 SCTP위에서 작동하는 바이너리 프로토콜입니다.) 물론, OpenGroup의
SUS (Single UNIX Specifications)도
그런 비슷한 것이긴 하지만, 용도가 좀 다르군요. ^^;

물론, 이렇게 되면, 제공되는 SDK가 네이티브 바이너리인 경우에는
플랫폼의 제약이 매우 심해지겠지만, 자바 클래스 라이브러리이거나
파이썬 모듈 같이 크로스플랫폼 포맷이라면 별 제약이 없을 수도
있습니다.

객관적이지 않은 편견을 드리지 않기 위해서, 각 방식의 장단점에 대해
제 주관적인 의견을 최대한 빼고 쓰려고 노력해서 설명을 해 봤습니다.
^^; 장기적인 대안은 아직 멀리 있는 뜬구름 잡는 얘기이기는 하지만
그래도 독일에서도 어떻게든 공개 표준이 있는 만큼, 우리도 영원히
못할 일은 아닌 듯 싶습니다.

인터넷 금융 서비스 플랫폼 문제의 현실적 대안

by

요즘 웹 표준에 옹호적인 커뮤니티들에서는 한 법대 교수님의 웹 페이지 국제 표준화를 위한
민원/소송 준비를 무척 반기며 들떠 있습니다. 그 동안에도
웹 표준과 관련된 운동은 몇 번 있기는 했지만, 엉뚱한 사람들
불러다가 토론 한 번하고 끝난다거나, 기업 사이트들의 느리디 느려서
언제 끝날지 모르는 프로젝트의 시작을 떠들썩하게 광고한 것으로
그쳐왔습니다.

이번 소송 준비에서는 그야말로 “끝장을 보겠다”고 선언을 하시고
진행을 하고 있기 때문에, 정말로 뭔가 뚜렷한 변화가 있지 않을까 하고
생각하고 있던 것들 중, 인터넷 금융 서비스에 대한 부분을 글로
옮겨 봅니다.

지금까지의 상황

그 동안에는 마이너 브라우저와 플랫폼에 대한 운동으로 어정쩡한 태도로
시작해서, 어정쩡하게 끝난 프리뱅크 같은 커뮤니티 기반의 움직임도
있었고, 공개소프트웨어 포탈에서
정부 지원으로 진행된
이니텍/경원대학교의 프로젝트 같은 것도 있었습니다.
현재 소비자 인터넷 금융 기술 시장의 거의 대부분을 차지하고 있는
소프트포럼과 이니텍은
해외수출이나 다양한 서버 플랫폼의 지원 등을 위해서
이미 오래 전에 기술적으로는
이미 거의 완성단계인 듯 합니다.

“플러그인 만들어 주세요”의 문제

현재 “웹 페이지 국제 표준화를 위한
민원/소송 준비” 모임에서도 지금까지 다른 운동이나 프로젝트에서
진행해 왔던 것처럼, 플러그인을 다른 플랫폼으로 포팅하는 것을 유도를
하려는 듯 보입니다. 그렇지만, “플러그인을 리눅스로 포팅해 주세요.”
류의 의견으로는 지금 당장의 승리라고 볼 수 있을 지는 몰라도, 또 다시
다른 어쩔 수 없는 마이너 사용자들을 낳을 수 밖에 없습니다.

플래시 기반 플러그인

우선, 플래시로
플러그인을 포팅하는 것에 대해서 논하자면, 플래시는
생각보다 그렇게 공식 지원 플랫폼이 많지 않기 때문에, 또다른 소외를
낳을 수 밖에 없습니다. 즉, 윈도우, 리눅스, 맥 사용자는 전혀 불편함을
느끼지 않을 지 몰라도, FreeBSD, NetBSD 또는 리눅스라도 CPU가
MIPS나
UltraSPARC
같은 것인 경우에는 공식적으로 플래시가 지원되지 않습니다.
또한, 플래시의 가장 큰 문제점은 하드웨어 접근이 어렵다는 점입니다.
인증서 관련 작업은 특성상 비정규 USB 장치까지 접근을 해야하기 때문에,
순수 플래시로는 구현이 어려우며, 특히 전송 채널 암호화 같은 것은
플래시로 반응성이 제대로 나올 수 있을지도 의문입니다.

XPCOM 기반 플러그인과 ABI 문제

그 다음으로, 모질라 계열의 클라이언트 측 API인
XPCOM을 쓰는 플러그인은
우선, 모질라 계열의 브라우저들을 지원할 수는 있겠지만, 결국에는
여러 이유로 네이티브 라이브러리가 들어갈 수 밖에 없습니다. 즉,
플러그인 제작사의 네이티브 라이브러리가 지원되는 플랫폼에 한해서 지원이
가능하기 때문에, 사실상 플랫폼이 굉장히 제한될 수 밖에 없습니다.
오픈소스 플랫폼의 ABI(Application Binary Interface)가 상당히 다양하다는
것이 바로 그 이유입니다. 즉, 주요 오픈소스 운영체제인 Linux,
FreeBSD,
OpenBSD,
NetBSD,
OpenDarwin
만 따져도 벌써 5개인데, 여기에 각각 아키텍처가
6개씩이라고 치면 5*6=30, 그리고 각 플랫폼 별로 호환되지 않는 널리 쓰이는
libc 버전이 3개씩이라고 치면 30*3=90, 게다가 gtk, libX11, libcrypto등의
기타 라이브러리들 중에 5가지 정도의 버전 조합이 널리 쓰인다고 치면
90*5=450. 즉, 플러그인을 배포할 때 무려 450가지 아키텍처와 플랫폼 조합을
배포하고 테스트하고 관리해야 한다는 말이 됩니다. 게다가, 플랫폼 별로
브라우저도 또 3~4가지씩은 있고.. 450가지 중 많이 쓰이는 3가지 정도의 환경만
지원한다고 선언을 하면, 물론 구글 서비스 같은 곳에서는 통하겠지만,
마이너를 왜 차별하냐고 선언한 서비스가 별로 차이나지도 않는 마이너들을
또 다른 조건으로 차별하는 일은 설득력이 별로 없을 것입니다. 수치 산정에
좀 무리를 하긴 했지만, 앞으로 더 희한한 상황이 올 지도 모릅니다.

“플러그인”의 역할

그럼, 플러그인은 과연 무슨 역할을 하는 것일까요. 우선, 가장 기본적으로
오프라인의 사람이 온라인의 이 사람이란 것을 증명하는 “신원 증명” 역할이
가장 주된 것입니다. 또한, SSL/TLS과 비슷한 역할을 수행해서, 다른 사람들이
통신 내용을 중간에서 보지 못하고, 변조하지 못하도록 하는 “채널 암호화”
기능도 지원합니다. 그리고, 송금이나 가입, 대출신청 등의 중요한 작업에서
사용자에게 내용을 확인하게 한 뒤에, 그에 대해서 싸인을 하게 하는
“부인 방지” 기능도 중요합니다. 사실 “신원 증명”이나 “채널 암호화”는 HTTPS 같은 것으로도 충분히 가능하지만, 바로 이 “부인 방지” 때문에 아직도 별도의 플러그인이 필요한 것입니다.

공개 표준 프로토콜

그래서 대안으로 생각할 만한 것은, 공개 표준 프로토콜을 수립하는 것입니다.
즉, 현재와 같은 웹브라우저에서 HTML을 통한 통신이든,
SOAP 같은 표준 RPC 프로토콜이나
별도의 프로토콜을 마련하든간에 플러그인 구현과 전혀 상관 없이, 서버는 서버대로
표준을 지키고, 클라이언트는 클라이언트 대로 표준을 지키면 제대로 서비스를
쓸 수 있도록 하는 것입니다. 우선 이렇게 되면, 굳이 은행이나 보안관련 회사들이
플러그인을 구현해 줄 필요 없이, 표준에만 맞으면 누구든 플러그인을 만들어서
팔아도 되고, 공짜로 줘도 되고, 혼자 써도 되고 여러가지 스스로의 환경에
맞는 선택을 할 수 있게 됩니다. 특히, 오픈소스 클라이언트가 나오면, 사용자가
자기 플랫폼에 맞게 컴파일을 할 수 있기 때문에, 아무리 특이한 플랫폼이
나오더라도 어떻게든 해 볼 수는 있는 여지가 있습니다. 또한, 이로써 얻을 수
있는 다른 이익으로는 똑같은 서버로 같은 기능을 PC외에도 손전화, PDA, 타블렛PC
또는 심지어 인터넷 뱅킹만 되는 전용 단말기까지도 쓸 수 있게 됩니다. 따라서,
인터넷 금융이 좀 더 자유롭고 잠재적인 발전 가능성을 얻게 됩니다.

보안 관점에서의 공개 표준 프로토콜

프로토콜이 공개되는 것에 대해, 일반적인 금융회사의 반응은 아마도 “보안에
취약하지 않겠느냐.”일 것입니다. 그렇지만, 사소한 하나의 보안 사건도
치명적인 금융의 특성상, 오히려 더 프로토콜을 공개해야 할 필요가 있습니다.
즉, 아무리 암호화를 하고 이런 저런 장치를 해 봐야, 결국에는
리버스 엔지니어링이나
스니핑을 통한 추측과 분석을 통해서, 디지털 컴퓨터 상의 구현인 한은
보안 결함은 뭐든 공격을 받을 가능성이 있기 마련입니다. 게다가,
금융 서비스에 대한 공격이라면, 그냥 돈 받고 해외로 도망가는 사람은
법적인 처벌도 신경을 안 쓸 것이기 때문에, 아무리 리버스 엔지니어링으로
불법으로 규정하려고 해도 법적으로 제재할 방법이 없습니다.
그렇지만, 간단하게 정의된 공개 표준 프로토콜은 결국 넓은 전문가
집단에서의 평가를 받을 수가 있으며, 보안적 위험성에 대해서도
어느 정도 위험성을 미리 느끼고 방어를 위한 수단을 공개적으로 여러 겹
마련할 수가 있습니다.

금융 회사로서의 입장

아무리 좋아도, 금융 회사로서는 새로운 시스템의 도입이 쉽지는 않은데,
금융 회사의 입장에서 얻을 수 있는 이득을 예상해 보겠습니다.
우선, 금융 회사는 클라이언트 측 보안 솔루션을 공급하는 회사와
서버측 솔루션을 공급하는 회사를 분리할 수 있는 자유가 생깁니다.
또한, 리눅스 사용자들이 매일같이 지원해달라고 아우성을 쳐도, 표준을
지키니까 표준 프로토콜을 지원하는 클라이언트를 쓰라고 대답하면 되기
때문에, 공짜로 새로운 플랫폼 지원을 얻을 수가 있습니다. 아무래도 더
중요한 것은 보안상 한 회사에 지나치게 의존할 수 밖에 없었던 것을,
공개 프로토콜로 하게 되면 양쪽을 분리해서 생각할 수 있고, 외부에
위탁할 수 있는 방법도 생기므로 보안 감사가 훨씬 더 쉬워집니다.

보안기술회사로서의 입장

보안기술회사도 중요한 당사자로서 손해만 있다면, 이런 움직임에
참여할 수가 없겠지요. 그러나, 보안기술회사라도 공개 표준이 도입되는
것이 나쁘지만은 않습니다. 공개 표준이 도입되면, 포팅이 훨씬 자유로워지기
때문에, 잠재적인 새로운 플랫폼이 늘어납니다. 따라서, 굳이 금융회사의
적극적인 리드가 없더라도 다른 플랫폼으로 포팅해서 그 쪽에서 벌일
수 있는 시장이 확보됩니다. 그리고, 당장에 이런 일이 생기면 서버쪽에서
작업해야 할 것이 꽤 있기 때문에, 프로젝트가 생겨서 좋겠죠. 🙂
물론, 잠재적인 금융사고에 대해 폐쇄적인 프로토콜에서 생기는 문제보다
공개 프로토콜에서 생기는 문제가 발견하기 쉽기 때문에, 미래의 금융사고에
대한 예측가능성 면에서도 유리하다고 볼 수 있습니다.

정부로서의 입장

정부는 계속 늘어나고 있는 MS의 데스크탑 운영체제 점유율에 때문에
외화 유출과, 독점사에 대한 지나친 의존성을 피할 수 있다는 점에서
당연히 여러 플랫폼을 장려하는 것이 더 안전합니다. 또한, 플러그인을
포팅하는 것으로 해결하면, 지속적으로 발생하는 마이너 플랫폼 때문에
이런 저런 민원이 생기고, 제대로 지원하는지 감시 하는 데에 쓰이는
노력을 많이 줄일 수 있겠습니다.

오픈소스 사용자로서의 입장

당연히 좋지 않겠어요? ^^;

제대로 된 보안을 위해

현재 국내 소비자 인터넷 금융 서비스는 사용자들에게 강제로 관리자 권한을
요구해서 바이러스/웜 감염 위험에 노출시키고, 많은 네이티브 소프트웨어 설치를
요구함으로써 중간자 공격에 의한 심각한 보안 위험을 방치하고 있습니다.
게다가, 지원하는 플랫폼을 획일화해서, 한 회사의 독점을 계속 더 촉진시키는
역할까지도 수행하고 있습니다.
한편, 어설픈 키보드 안전 플러그인은 사실상 완벽하게 동작할 수가 없는
것이 자명한데, 사용자에게 마치 안전한 것 같은 인식을 심어줘서 오히려
위험합니다.
결국, 정보의 위치와 흐름을 고려해 볼 때, 해결하는 방법은 비밀번호를 컴퓨터의
통제에서 벗겨내는 방법 밖에 없습니다. USB 장치가 요즘 사용자 권한에게도
많은 기능을 제공하는 쪽으로 발전하고 있는 것을 보면, USB 장치를 통한
적절한 키 관리/사인 등이 결국 좀 더 나은 해결책이 아닐까 합니다.
물론 비싼 장치를 배포해야하는 부담이 있긴 하지만, 사용자들이 하드웨어를
받을 때는 지불하려는 성향이 훨씬 높다는 것을 생각해 보면, 뭐 크게
문제가 되지는 않을 것 같고요. 🙂
USB 장치를 접근하는 것만 허용하면, 어설픈 보안을 하느라 관리자 권한을
요구하는 것이나, 엄청나게 깔아대는 플러그인도 별로 많이 필요가 없어질
것입니다. (드라이버를 깔아야하는 문제는 생기지만요;;)

공개 프로토콜의 시대

이미 Flickr, Amazon같은 인터넷 기반의 서비스 뿐만 아니라,
해외의 큰 규모의 은행들도 API를 공개해서 오픈소스 프로그램에서 쓸 수 있게하고 있습니다.
이제 열만한 것은 열어서, 열린 것들끼리의 카테시안 프러덕트를 최대한
활용하는 다양성의 시대가 되고 있습니다.
온몸을 항상 천으로 똘똘 두르고 있으면, 상처가 곪아도 안 보이고 발견하기도
힘들 뿐더러, 장갑 낀 손으로 다른 사람과 악수하면 사람들과 친해질 수도
없습니다. 어느 정도 얼굴도 보여주고 맨손도 느낄 수 있어야 공기도 통하고
좋겠지요.

FreeBSD에서 rrdtool에서 한글 쓰기

by

rrdtool은 버전 1.2로 올라가면서 트루타입 글꼴을 직접 그리는 것으로 완전히 전환을 하는 덕에, 라틴이 아닌 글자를 그릴 수 있는 기능이 들어갔습니다. 그렇지만, 이 기능이 mbstowcs(3)을
이용해서 멀티바이트 문자열을 와이드캐릭터 문자열로 바꿨기 때문에,
와이드캐릭터가 유니코드가 아닌 플랫폼에서는 엉뚱한 글자가 출력되는
버그가 있었습니다.

POSIX 표준에서는 wchar_t에 글자를 유니코드로 저장하는 것을 강제로 하지 않고 있기 때문에, FreeBSD나 MacOS X 같은 플랫폼들은 wchar_t에 각 인코딩에서 가장 표현력이 높은 단순한 내부 형태로 저장하고 있습니다. 예를 들어 EUC-KR에서 ‘한’은 C7 D1인데, 이것을 리눅스와 솔라리스에서는 ‘한’의 유니코드 표현인 D55C로 저장하지만, FreeBSD에서는 C7D1로 저장합니다. 따라서, mbstowcs를 유니코드가 출력이 된다고 가정하고 쓰는 것은 잘못된 사용이라, FreeBSD에서 한글을 못 쓰게 된 것입니다.

그래서, 마침 그냥 주말에 시험전증후군의 영향으로 산만해진 틈을 타서, 학교 중도 잔여좌석 그래프를 그리는 rrd 그래프를 하나 그려 보면서, 제목과 범례에 한글로 나오게 패치를 해 봤습니다. –;

흐흐.. 패치는 그냥 일단은 mbstowcs를 매크로로 덮어버리는 방법으로;;
업스트림하기 위해서는 automake에 iconv 검출하는 부분을 넣어 줘야하는데.. 이거 참 automake를 오랜만에 보려니 머리가 아찔한게 –;;;; ㅠ.ㅠ.ㅠ

— 그러나 — 패치를 다 하고 보니, FreeBSD에서도 UTF-8 로캘을 쓰면 wchar_t에 유니코드로 저장을 하기 때문에, 알고 보면 setlocale만 제대로 하게 패치하면 되는 것이었는데.. 괜히 오바해서 엉뚱한 것까지 해버렸네요 -O-;; 그래도 혹시나 euc-kr 쓰시는 분들을 위해;; _-_

코-크 제로를 조심하자~

by

오늘 식량 조달을 위해서 수퍼마켓에 갔다가 새까만 색 포장의
콜라가 나왔길래, 원래 라이트는 손도 안 대고 있었지만, 코-크 라이트랑 다른 것인가 해서
한 번 사 봤습니다. 이름은 코-크 제로. 라이트와 같이
사람이 소화할 수 있는 열량 영양소를 모두 없애서 0 kcal로 맞춘 것이라는데.. 뭐 하여간 칼로리는
크게 신경은 안 쓰지만 그냥 무슨 맛인가 궁금해서~

그런데, 이게 콜라를 마신 뒤에 두 시간 정도 지나니까
이거 시험도 얼마 남지 않았는데 머리가 아픈 것입니다.
좀처럼 머리 아픈 일이 드물어서, 집에 두통약류는 전혀
취급하지 않는데 갑자기 머리가 아파서 참 곤란하군요.
그래서 역학조사를 아침부터 먹은 것을 자세히 조사해 봤는데,
그 때 코-크 제로의 성분에 그 의심되는 물질이..

원재료명: 탄산가스, 카라멜색소, 인산, 아스파탐, 안식향산나트륨, 향료, 아세설팜칼륨, 구연산삼나트륨, 천연카페인, 페닐알라닌 함유

일단, 탄산가스, 카라멜색소, 인산, 카페인, 구연산삼나트륨은 다른 탄산음료에서도 쉽게 볼 수 있는 재료이고, 페닐알라닌은 음료에 늘 등장하는 맛내는 아미노산이고, 안식향산나트륨은 널리 사용되는 방부제이기 때문에, 특별한 것은 없습니다. 주목할 것은 아스파탐과 아세설팜칼륨! 아스파탐과 아세설팜칼륨 둘 다 FDA에서 승인한 안전한 합성감미료라고 합니다. 그렇지만, 둘 다 인터넷에서 검색만 해 봐도 쉽게 찾을 수 있는 논란이 많은 재료임을 알 수 있습니다. 그러나, 국내의 몇몇 자료들은 마치 인류 모두가 항상 마시고 있는 DHMO(Dihydrogenmonoxide)가 소량이 목에 걸려도 호흡 곤란에 빠질 수도 있고 산성비의 주 성분이며, 기체 상태일 때에는 닿기만 해도 피부에 심각한 손상을 입힐 수도 있다는 조크를 그대로 흉내내고 있습니다.

그래서, 여러 논란 중에서 그대로 받아들일 수 있는 것은 거의 없었지만, 그래도 그 중에 설득력이 있는 것을 좀 추려 보면, 95년에 발표된 자료에 따르면 주로 신경계에 관련이 많은 부작용이 92건 보고되었다고 합니다. 즉, 제가 머리 아픈 이유가 제로에 들어있는 아스파탐의 영향이라고 의심을 할 수도 있겠는데, 좀 더 정확한 조사를 위해서 내일 콜라만 빼고 나머지는 똑같이 한번 먹어보고 그 다음날에는 다른 음식과 콜라를 마셔봐야겠습니다. –;

그렇지만, 아스파탐이 단기간 복용이 바로 반응을 보이지는 않는다는 연구도 여러가지가 나와있긴 하더군요. 하여간 그래도, 아스파탐이 10%정도는 소장에서 메탄올로 분해가 된다는 사실이 썩 기분이 좋지는 않습니다.

한편, 아세설팜칼륨(Acesulfame Potassium) (국내 자료)도 또 다른 합성감미료입니다.
그런데, 이놈은 아스파탐에 비해서 널리 사용되지 않아서 그런지, 크게 부작용에 대한 보고는 별로 나오지 않은 듯 보입니다. 암을 유발할 확률은 적다고 하고 두통과의 연관성도 크게 없는 듯 하네요. 아세설팜칼륨과 아스파탐을 같이 섞으면 설탕과 매우 가까운 맛을 낸다는 이유로 2000년대 들어서 많이 사용되고 있는 것 같습니다.

하여간.. 다음부터는 새로 나온 것을 봐도 꼭 확인해 보고 먹어야겠습니다. ^^;

추가: 아스파탐은 원래 다이어트 코크에도 포함되어 있었던 물질입니다. 원래 라이트를 잘 드셨던 분들은, 제로를 마신다고 해서 특별히 머리가 아파지지는 않을 확률이 높겠네요~

뻔한 부탁은 하지 말자

by

channy님의 말씀에 따르면, 제주도에서는 뭍에서 놀러와서는 놀아달라고 재워달라고 먹여달라고 하는 사람들이 너무 많아서 뭍으로 다시 돌아가는 사람들도 제법 있다고 합니다.

어느 출판사 편집자 글에서는 문학 작품을 출판하는 사람들은 상당수가 지인들이 무심코 던진 “책 나오면 한 부 주세요 ^^”류의 부탁에 많은 책을 보내고도, 책이 한 권도 안 팔리고 인세도 기대하지 않는 경우가 허다하다고 합니다.

Vim 7 릴리스

by

장기간의 개발 과정 끝에 드디어 vim 7이 릴리스 됐습니다. 수년간 vim 6.x를 보고 있어서, 이제 6에 나름대로 조금 지겨워지려는 중에~ 7이 나와서 뭔가 신선해진 기분? ;;;;

6에 대한 주요 변경사항은 이렇다고 합니다.

  • 50개 언어에 대한 문법 검사 제공
  • Omni completion이라는 똑똑한 자동완성 제공
  • 탭 페이징 제공 (각각이 창 분할이 가능) — 진형군의 블로그 참조
  • Undo 기능을 여러 갈래로 할 수 있음
  • Vim 스크립트가 파이썬의 list와 dict같은 타입을 지원하기 시작 (이제 느리지 않아질지도!)
  • Vim 스크립트 프로파일링
  • 유니코드 지원 강화
  • 괄호 맞춰서 하이라이트하기
  • 번역판 매뉴얼 지원
  • 모든 플랫폼에서 내장 grep 지원, 압축파일도 검색가능!
  • 원격 디렉토리, zip, tar 아카이브 브라우징 가능
  • 멀티바이트 텍스트 인쇄 지원

여기서 그냥 제목만 봐서 좀 아리송한 omni completion은 예전의 키워드 자동 완성기능보다 좀 똑똑한 다른 일반 IDE에서 제공하는 자동 완성과 비슷한 놈입니다.

요렇게, ctrl-x ctrl-o를 누르면 tags에서 검색해서 결과를 보여주는데, 그런대로 괜찮군요. ^.^; 파이썬, HTML, CSS, 루비 등도 지원됩니다.

그 외에 FreeBSD에서 euc-kr locale에서 한글 위에서 커서가 제대로 안 움직이는 문제점이 수정된 것도 vim 7부터 반영되어 있습니다.

구글 Summer of Code 필승전략(?)

by

구글 Summer of Code에 멘터로 지원해서 지원자 심사 목록을 보면서 느낀 팁(?)을 누설해 볼까 합니다. 이제 학생 지원이 하루 밖에 남지 않았지만, 혹시 아직 안 내셨거나, 내셨더라도 수정의 여지가 있으므로.. 🙂

자기 경력을 매력적으로 쓴다

자기 경력을 소개할 때, 자기가 프로젝트를 할 능력이 있다는 것을 쓰고, 심사할 멘터들이 알 만한 것들을 가급적이면 많이 언급합니다. 같은 프로젝트에 지원한 지원자들도 제법 있기 때문에, 멘터들은 지원자가 그 말아먹지 않고 해 낼 것인가에 관심이 많습니다. 따라서, 가급적이면 멘터들에게 좋지 않게 보일만한 경력은 최대한 숨기고, 관련 프로젝트 경력을 많이 씁니다. 예를 들어서, 구글 조건에서는 학생이면 된다고 써 있지만, 자기 소개에 곧 취업할 것이라고 쓰면, 멘터들이 그것 가지고도 자기들끼리 원래 취지에 맞춰서 생각을 하고 프로젝트 하다가 회사 도망가지 않을까 생각하고 그렇게 됩니다;;

프로젝트 일정을 현실감있게 상세하게 쓴다

2주짜리 프로젝트를 3달한다고 낸 지원자나, 1년짜리 프로젝트로 보이는 것을 2달만에 다 한다고 낸 지원서는 받아들여지기 힘듭니다. 프로젝트를 짧은 세부기간으로 나누어서, 각 날짜별로 어느 부분까지 한다는 것을 현실적인 기준에 맞게 쓰고, 각 기간별로 예상되는 어려운 점 같은 것을 곁들이면 더욱 좋겠습니다.

해당 제안에 대해 잘 알고 있다는 냄새를 풍긴다

어떤 지원자는 단순히 각 프로젝트의 idea 페이지를 보고서, 순진하게 그냥 해 보겠다고 지원서를 내기도 합니다. 그런데, 프로젝트 측에서 심사할 때에는, 성공 가능성이 높은 사람들을 뽑아야, 멘터 자원을 낭비하지 않을 수 있기 때문에, 아무래도 성공 가능성도 중요한 척도로 작용합니다. 따라서, 해당 범위에 대해서 기존에 인터넷에 널려있는 여러 자료들을 미리 조사하고, 비슷한 사례에 대해 연구해서, 잠재적인 난관이나 해당 목표를 수행해서 얻을 수 있는 이점들을 쓰면 좋습니다. 게다가, 다른 사람들의 실패 사례같은 것을 보고 어떻게 극복하겠는가를 곁들인다면 금상첨화겠죠.

인터넷 인생에 빨간줄을 긋지 말자

몇몇 지원자의 지원서 밑에 달린 멘터들의 숨겨진 답글에 보면, “이 지원자는 작년에 코딩 안 하고 놀기만 하다가, 결국 망했다. 코드 품질도 별로 좋지 않다.” 이런 식의 악평이 달려 있기도 합니다. 해당 지원이 아무리 좋아도, 이런 답글이 한 번 달리면 다른 사람들이 전혀 믿을 마음이 나지 않습니다. 다른 지원자들도 충분히 많으니까요.. 그래서, 결국은 인터넷 세상은 좁으니 착하게 살자. -O- 가 적용이 됩니다.;;

커뮤니티에 미리 이름을 알리자

사람은 아무래도 나쁜 놈만 아니라면, 익숙한 사람에게 호감을
느낄 수 밖에 없고, 이미 몇 번 본 사람에게 뒤에서 나쁜 얘기를
할 확률은 확실히 줄어듭니다. 따라서, 메일링 리스트나, 관련
뉴스그룹을 통해서 해당 커뮤니티에서 활동하고 있는 멘터들에게
자기가 지원하려고 하는 이슈나 다른 관련 이슈들 밑에 답글을
다는 등의 방법으로 이름을 알리면 큰 도움이 됩니다.
게다가 그런 토론 중에 자기 관련 이슈에 대한 얘기에서 나오는
기존 개발자들의 얘기를 통해 관련된 새로운 아이디어를 얻을
수도 있고, 자기 지원서에 대한 생각을 더욱 정제할 수 있는
기회가 됩니다.

주제를 잘 정하자

앞에서 언급한 것들을 아무리 잘 하더라도, 주제가 엉뚱한 것이라면 선발되기가 힘들겠죠. 주제는 기존 개발자들이 하기 귀찮아 하는 듯 하면서도, 작은 2~3개월의 프로젝트로 한정지을 수 있는 명확한 범위의 작업이어야 합니다. 그리고, 구석진 이슈가 아니라, 기존의 개발자들이 목말라 하는 기능이지만, 자기들이 직접 구현하기에는 시간이 없는 틈새시장을 노려야 합니다. 물론, 이런 것은 각 프로젝트마다 판단 기준이 다를 수 있기 때문에, 모든 프로젝트에 적용되는 기준은 없겠지만요.. ^^;

혹시나 국내에서도 SoC 지원하신 분이 계시면, 꼭 통과해서 외화벌이(;;)하시길 빌며;; 건승을 빕니다. -O-;