computer

9월에 두 행사에서 발표를 맡았습니다. 혹시 직접 만나서 물어보실 것이 있으시거나, 전해주시고 싶은 선물-ㅇ- 이 있으시면 오시면 좋을 것 같습니다. ^o^

9월 1일~3일: 대안언어축제에서 Io언어 튜토리얼을 1시간 30분 정도 진행합니다. Io 언어는 문법이 안 독특한 듯 하면서도, 독특하고 자유도가 별로인 것 같으면서도 굉장히 자유로운 재미있는 성질이 있는데요, 혼자 공부하기 귀찮으시면 오셔서 같이~ 물론, 대안언어축제의 다른 행사들도 ∑n=0,∞{정말정말} 재미있습니다. 요즘 참가신청을 받고 있으니 일정을 확인해 보시고 등록하세요~ (마감임박!)

9월 17일: KLDP 10주년 기념 컨퍼런스에서 “오픈소스 프로젝트에 참여하기”라는 제목으로 발표할 예정입니다. 그냥 사용자로써 종종 불편한 점을 패치해서 개발자들에게 보내주는 방법부터 개발자가 되기 위한 중간 과정, 개발자가 되고 나서 있는 여러 인간관계까지 다양한 상황에 대한 소개를 조금씩 해드리려고 합니다. 구글의 Greg Stein도 온다고 하니, 구글에 관심 있는 분들도 오시면 재미있을 것 같네요~ — 아마 Greg Stein의 발표는 그동안의 발표 내용으로 미루어보아 Python과 MySQL에 대한 내용이 주가 되지 않을까 생각합니다.

애자일 블로그에 올라온 프로그래머와 수학을 읽고 전에 경험했던 것을 짧게 써 봅니다.

프로그램을 하다보면, 뭔가 하고 있는 것이 비효율적인 것 같은 느낌이 약간은 들지만, 최적화가 충분히 되어있다고 느낄 때가 많습니다. 더 속도가 필요하다면, 더 빠른 언어와 여러 트릭을 동원해서 빠르게 하곤 합니다. 극단적인 경우를 예를 들어서, 항상 예제로 많이 쓰이는 피보나치 수열을 한 번 보겠습니다. 실제 프로그래밍이 피보나치 수열처럼 간단한 루틴일 리도 없고 그렇게 반복적으로 호출될 일은 없겠지만, 그래도 극단적인 예를 보면, 그 특징을 다른 곳에서 활용할 수 있을테니까요~

일반적으로 피보나치 수열 n번째를 구하는 루틴은 파이썬으로 이렇게 합니다.

만약 피보나치 수열의 200005번째 수 “주변”의 것이 정확할 필요는 없고 대충의 값이 필요해서 호출한다면, 제 컴퓨터에서는 대충 2.82초 정도가 걸립니다. 그런데, 이런 루틴이 적어도 초당 100번 이상은 호출되어야 하는 상황이 왔다고 치면 보통 이런 대안을 생각합니다.

• 파이썬이 느리니까 C로 하자!
• a, b는 터플이 묶였다가 풀리면서 메모리 할당을 하니까 따로 따로 하게 2줄로 분리해 보자.
• 내가 요새 어셈블리에 재미를 붙였는데, 어셈블리로 하면 레지스터도 충분히 활용하고 빠르지 않을까?
• 루프를 매번 돌리는 것은 비효율적이니까, 16번에 한번씩 돌게 풀어쓰면(unroll) 빨라질거야!

자.. 그런데, C로 하면 과연 얼마나 빨라질까요. 200005번째 피보나치 수는 64비트로 커버가 안 되는 수이기 때문에, 빅넘버 라이브러리를 쓰다보면 결국 시간이 제법 걸리고, 속도도 생각보다는 별로 빠르지 않습니다. 어셈블리로 하면? 과연 오늘 퇴근 할 수 있을까요..

여기서 경험많은 프로그래머는 알고리즘을 휙 보고, 이런 코드로 최적화를 합니다.

200005번째 수를 주는데 걸리는 시간이 눈깜짝할 새 입니다. 아이 그런데, 또 주변의 수가 더 필요해졌습니다. 그래서, 좀 더 많은 범위에서 캐시를 할 수 있게 데코레이터도 쓰고 해서 멋있는 캐시를 넣어서 정말 더 빨라졌습니다. 그랬더니 이제는 메모리를 너무 많이 먹습니다! 결국에는 캐시 관리 기능에 메모리가 얼마인지 보게도 만들어서, 이 프로그래머는 주변의 존경을 받습니다.

그러나, 이때 옆에서 보던 한 수학자가 종이에 뭘 끄적거리더니, 이렇게 하면 안 되겠냐고 조심스럽게 코드를 한손가락으로 톡톡 쳐줍니다.

아! 아.. 프로그래머는 뭔가 속은 기분이 들었습니다. 그래서 유심히 보니까, 실행해 보면 정확한 값이 나오지는 않았습니다. 그래서 따져보고 싶었지만 필요한 것은 그냥 대충 화면 좌표를 잡는 것이라 유효숫자 6개 정도만 하면 넘칠정도라는 사실에 슬펐습니다.

컴퓨터 전공 학생들은 대부분 4학년 되면, 적분기호를 까먹을 정도로 수학을 쓸 일이 없습니다. 그런데, 간단한 프로그래밍의 수준을 지나면 생각보다 훨씬 수학을 활용할 수 있는 일이 늘어나는 것 같습니다. 물론 굳이 수학 뿐만 아니라, 넓게 봐서 논리의 흐름과 여러가지 알고리즘적인 방법, 패턴 등이 있겠죠.

모니터 가까이에서 코드를 보고 있으면, 앞에서 본 C로 하면 무조건 제일 빠를거야!, 터플 때문에 괜히 메모리 할당하는 것을 줄이면 정말 빠를거야! 라는 생각을 늘 하게 되기에 마련이지만, 가끔은 좀 멀리서 최적화에 조바심을 내지 않으면서 코드를 볼 기회도 가져봄 직 할 것 같습니다.

“Real efficiency comes from elegant solutions, not optimized programs.
Optimization is always just a few correctness-preserving transformations
away.” – Jonathan Sobel, 《Is Scheme Faster than C?》에서

붙임: 중간에 든 예가 좀 과장이 심해서 죄송 -ㅇ-; 글의 원래의도가 피보나치 수열을 최적화하자는 것은 아닙니다. ^^;

한동안 새로 올라오는 RFC 목록을 안 보고 있다가, 오랜만에 한번 쑥~ 훑어 봤습니다. 아무래도 인터넷의 트렌드를 알려면 RFC 목록을 보는 것이 많은 도움이 되는군요. ^.^

작년엔 주로 SIP 같은 세션 프로토콜들과 그와 관련된 스트리밍 프로토콜들이 주종을 이루었는데, 올해에는 이제 그를 뒷받침해 줄 인프라망에 대한 것들이 많이 올라오는 분위기입니다.
BGP 같은 라우팅 프로토콜류에 관한 것들이 특히 많고,

Mobile IP의 라우팅 최적화, 3GPP와의 연결 가이드라인 같은 것들이 등장하고 있습니다.
그리고, DNAv4 같이
사용자망에서의 새로운 활용가능성을 더 높이기 위한
기존 프로토콜의 보완작업도 일어나고 있습니다.
이에 따라, 점점 동적인 네트워크가 강화되고, 모바일 네트워크를
제대로 지원해주기 위한 기반 작업들이 굉장히 빠르게
다가오고 있다는 느낌을 받을 수 있습니다.

SSH가 RFC로 등록된 것이 유닉스 개발자들에게는 가장 관심이 있을 만한 것일 듯 합니다.
RFC4150을
시작으로 구조, 인증, 키교환, 통신계층, DNS 등 거의 20~30개 정도 되는 RFC들이 우루루 들어왔습니다.
저자로는 SSH를 최초로 고안한 SSH Communications가 당연히 제1저자로 등록이 되어있고, 제2저자는 Cisco 직원이군요. RFC가 이제 IETF Proposed Standard로 등록이 되었으니, ssh 구현 간의 비호환성이 앞으로 많이 줄어들겠지만, 사실상 지금까지 크게 불편했던 점이 없었기 때문에 눈으로 볼 수 있는 변화는 별로 없을 것 같긴 합니다;;; 어쨌거나 표준화가 착실하게 되어서 등록된 점에서는 매우 환영할 일입니다.

그리고, 요새 네임스페이스와 관련한 것도 일상에 영향을 많이 주니 흥미롭습니다. ^^ RFC 4343으로 DNS 대소문자 구분에 대한 것이 등록되었습니다. 지금까지 표준안에서 DNS에서 대소문자 구분에 대한 규칙이 전혀 없었고, 심지어 아스키문자가 아닌 것도 프로토콜에 얼마든지 허용이 되었습니다. (\x00 마저!) 이런 것들에 대해서 존 파일에 쓰는 방법을 표준화 하고, 대소문자 구분을 안 한다는 사실을 처음으로 명문화 하였다고 합니다. –;

뉴질랜드 정부에서 URN 네임스페이스를 등록한 RFC 4350 도 재미있습니다. 개요에서 밝힌 목적은, 뉴질랜드 정부 기관과 기업, 개인들에게 개인 식별자를 제공하기 위한 것이라고 하는데, 예시를 보면 도메인 시스템과 비슷하게 계층구조로 정부에서 관리할 계획인 것 같습니다. 그래서 회사 이름과 지리정보, 국가에서 관리하는 여러 식별번호를 모두 URN으로 통합할 수 있게 되어, 고유식별번호를 교환할 때 매우 편리하게 되었습니다. 무슨 뜻인지 알 수가 없는 UUID만 떨렁 써놓고 표준이라고 주장하는 것을 이제 뉴질랜드에서는 보기 힘들겠군요. 🙂

그리고, 재작년부터 선풍적인 인기를 끌고 있는
SPF가 드디어 RFC로 등록되었군요. 비록 EXPERIMENTAL 트랙으로 들어가기는 했지만, 그래도 공감을 이끌어낸 뒤 표준화되어 결국 RFC 등록이 되었다는 점에서, “SPF는 단순한 꼼수가 아니냐!”고 무시해버리기는 힘들게 되었습니다. SPF 만세 -O-;

보안과 관련한 것들은 꾸준히 증가하고 있는데, 이번에는 TLS가 RFC 4346에서 1.1로 업데이트됐습니다. (RFC 4346의 제2저자의 소속이 재미있습니다. -O-;;;) TLS 1.0과의 차이점은 그동안 꾸준히 제기되어 왔던 CBC 패턴 분석 공격에 대응하기 위해서 IV (Initialization Vector)를 명시적으로 지정하게 되었고, 간단한 에러 처리 규칙이 몇 가지 바뀌었습니다. TLS 1.0의 내부 버전이 SSL 3.1이라는 사실을 기억하면, TLS 1.1의 버전이 뭐가 될 것인가도 상당히 궁금해 지는데요, RFC 내용을 보면 SSL 3.2로 한다고 합니다. (프로토콜 내부의 핸드셰이킹을 위한 버전 번호)

그리고 IPSec도 RFC 4301에서 업데이트 되었습니다. 성능 향상과 구현의 단순화를 위해 처리 모델을 바꾸고, SPD (Security Policy Database)의 유연성을 확보한 것이 주요한 변경사항인 듯 합니다. 그리고, 일본의 블럭 싸이퍼인 Camellia가 RFC 4312에서 Standards Track으로 승격되면서 IPSec에서 사용가능하게 되었습니다. (SEED는 RFC 4169에서 Proposed Standard)

그 외에 재미있는 것:

• RFC 4217: FTP를 TLS위에서 쓰도록 확장
• RFC 4226: HOTP(HMAC-Based One-Time Password) – HMAC을 이용한 일회용 암호 알고리즘
• RFC 4227: BEEP 블럭에서의 SOAP 활용
• RFC 4215: 3GPP에서의 IPv6 전환에 대한 분석
• RFC 4510: 오랜만의 LDAP 프로토콜 업데이트. LDAPv3

덴마크에서 2008년 1월부터 공개 표준(Open Standard)를 법적으로 의무화한다고 합니다.
공개 표준화가 슬슬 여러 국가에서 채택이 되고 있는 가운데, 덴마크에서 거의 최초로 법적으로 광범위하게 강제화 하게 된 것입니다.

이번에 덴마크에서 공개 표준을 주로 노린 부분은 문서 파일 포맷에 주안점을 둔 것 같이 보입니다. 위 뉴스의 (비공식) 영어번역을 보면, 의회의 안의 결정 안에서 이런 법의 도입 목적은 “모든 시민들에게 공공 기관에서 제공하는 모든 디지털 정보를 자유롭게 주고 받을 수 있는 민주적인 권리를 모든 공공 기관에서 사용되는 IT 기술에 대해 적용하려는 정치적인 작업”을 하는 것이라고 합니다. 최근 우리나라에서 고질적인 정부의 표준 무개념에 대한 개선 노력이 눈물겹게 이뤄지고 있는 것을 생각해 보면, 오랫동안의 차별에 무기력하게 익숙해져 있었던 자아를 반성하게 됩니다. ^.^;

그 외에도, △ 대민 서비스와 업무를 위해 공공기관이 구입하는 소프트웨어에 대한 정책적 결정 △ 공개 경쟁의 촉진 △ 여러 단계의 기관들 끼리의 시스템 통합을 위한 공개 표준 채택 △ 공개 표준을 공적으로 관리함에 따른 장기적 관점에서의 경제적 혜택 등을 언급하고 있습니다.

우리나라에서도 지금처럼 단순히 공개 표준을 모른체하며 99%가 쓴다는 고가의 단일회사 제품을 나머지 1%에게도 쓰도록 강요하는 상황이 속히 개선되어서, 초고속 인터넷 (게임) 강국 그러면서 조바심 내지 말고 느긋하고 여유있는 멋진 발전을 이루었으면 좋겠습니다.

장기간의 개발 과정 끝에 드디어 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에 멘터로 지원해서 지원자 심사 목록을 보면서 느낀 팁(?)을 누설해 볼까 합니다. 이제 학생 지원이 하루 밖에 남지 않았지만, 혹시 아직 안 내셨거나, 내셨더라도 수정의 여지가 있으므로.. 🙂

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

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

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

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

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

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

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

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

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

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

주제를 잘 정하자

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

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