2007년 IEEE 존 폰 노이만 메달의 주인공이기도 한데, 여기서도 언급한 “최초의 현대식 개인용 컴퓨터를 만든 사람”으로 이번에 튜링 어워드를 수상하게 되었다. 사실 누군지 그때 보고 까먹어서(…) 다시 위키백과 C. Thacker 페이지를 봤다. 최초의 개인용 컴퓨터인 Xerox PARC에 있을 때 최초의 개인용 컴퓨터인 Alto를 만들었고, DEC에서 최초의 MP 워크스테이션 구현체인 Firefly를 만들면서, cache snooping 기반의 coherency protocol을 만들어냈다.^[1]

그리고 마이크로소프트 리서치에서 타블렛 PC를 만들어냈다고 한다.

한줄 논평: 거의 개인용 컴퓨팅 사를 쓰신 분인게 참 무섭군요(…).

1. 컴퓨터 구조 시간에 배우는 MESI 프로토콜과 비슷한데, I 상태가 없고 write-through로 구현되어 있음

책 제목이 참 괜찮게 한글화 된 듯하다. 그래서 산거지만(…)

일단 86 가지의 “팀 (행동) 유형”에 관해서 4 명의 저자들이 (어떻게 보면 굉장히) 가볍게 다룬다. 각 항목마다,

• 항목의 제목(과 그에 해당하는 원본 책의 제목)
• 그에 해당하는 사진 혹은 그림
• 수 단어 ~ 수 줄 수준의 간단한 어구 인용, 혹은 내용 요약
• 본 내용 1~3 페이지 정도.

의 형식으로 다룬다. 덕분에 지하철 2정거장 이동 –> (환승) –> 3정거장 이동인 출/퇴근 길에 끊기는 느낌없이 참 편안히 볼 수 있었다.

인상 깊은 항목이거나, 내가 재밌게 본 항목을 몇 개 인용해보겠다.

7번째 항목 내일(Mãnana)에서는 “막연한 내일”의 문제를 다룬다. “일을 끝내기 위한 긴박감을 느끼는 기간은 약 30일에서 90일”인데, 이에 해당하는 기간이 아니라 막연한 마감시한인 경우(저보다 긴 데드라인), 긴박감을 느낄 수 없다는 문제. 그래서 이걸 잘게 나눠서, 각 기간마다 결과물(프로토타입, 특정 기능집합 …)을 내놓게 해야한다고 설명한다.

이런 식으로 각 문제, 혹은 현상(?)을 가볍게 다루면서 86개의 항목이 나온다. 안 지루하고, 프로젝트 문제점을 지적하는 여러 책들에 비해 상대적으로 통찰력도 주는 느낌이고, 쪼개보기 좋아서 편하게 봤다.

유쾌하게 봤던 항목을 몇 개 꼽자면,

• 16, 대시보드 – 일종의 정보 방열판. 다만 정보과잉은 피할 것.
• 60, 음식++ – 팀원들이 모여서 식사를 하라. 심지어 음식을 만들어먹어라!^[1]
• 67, 십자 나사 – 좋은 아이디어라고 빨리 퍼지는 건 아니다. 이건 회사들어가기 전에 품었던 생각 중 일부를 실제로 실현하는데 걸린 시간을 생각하면 Orz
• 70, 브라운 운동 – 방향성을 응집성 있게 세우는 건 중요하다. 특히 초기에. C++은 한 명이 만들었다. linux도, python도, … 위원회가 만든 ada의 현재 운명은…(하략)
• 80, 해외 개발팀 함정 – L? 전자에서 일하던 친구 A군의 증언이랑 비교해서 생각하니, “이렇게 멍청하게 하는게 정말 실제 사례군”이란 느낌을 받았다

정도? 사실 나머지도 다 유쾌함; 실제 상황이라면 무진장 괴롭겠지만…

예전에 “초난감 기업의 조건”을 읽었을 때 느꼈던, “그래서 어쩌라고?”하는 느낌도 좀 덜해서 – 각 현상의 냄새에 관한 언급이 적절히 끼어들어가 있다 – 어느 정도 추천할만한 책인듯 싶다.

1. 미야자키 하야오 감독이 “센과 치히로의 행방불명”을 제작하던 때에, 돌아가면서 음식을 만들었다는데, 감독 자신도 국수를 만들어 내놨다고 한다;;;; 근데 책에는 센과 히치로라고 오타가 있다. 흑흑

Twitter(via FB):        00:06   00:22   00:24   00:12
Buzz:                   01:12   00:22   00:24   00:12
Google Reader(via FB):  01:19   00:26   00:24   00:12
GoogleReader:           00:20   01:13   00:24   00:12
Buzz(via Twitter)       09:06   19:08   08:40   02:06

2007년 3월 7일부터 2010년 3월 6일(토요일이라 실질적으론 전날인 5일까지)까지로 끝.
병무청 홈페이지에서 정말 끝난건가 싶어서(…) 뭔가 조회해보려고 했더니 가상 PC에선 거의 뭐가 안된다; 덤벼 싸우자!

유일하게 조회되는건 아직 데이터가 없다고 나온다. 이건 월요일되야 업데이트되나…^[1]

사실 전문연구요원 신분(?)을 벗어나 민간인(!)이 되는거라고해도 바뀌는거라곤 해외 나갈 때 절차가 단순화되는 거 밖에 없는듯하지만; 개인적으로 자축 겸, 정리 겸 해서 글을 쓴다.

ps. 뭔가 주특기(?)가 1713 전산기운용으로 나오는군. 대체 왜? 전문연 하면 그냥 소총수?던가 아닌가…

1. 사실 이거 캡쳐해서 넣으려고 했는데 ㅠㅠ

http://www.civilization5.com/

공개된 정보는 개략적인 발매일(올 가을)과 3 장의 스크린샷 뿐.

Updated: Steam 을 통해 공개된 정보에 따르면, 스팀 쪽으로는 2010년 9월 2일에 발매됨 — http://store.steampowered.com/app/50100/

공개된 스크린샷도 총 5개로 증가.

일단 공식 홈페이지를 통해 공개된 스샷 중 하나를 여기에도 올린다. 모든 권리는 Firaxis Games 에 있다. (All rights are reserved to Firaxis Games)

Civilization IV 보다 좀 더 “생동감이 더해진” 그래픽이 맘에 든다. 사실 나와주는 것만으로도 감사! ㅠㅠ

아마 Amazon.com 에선 해외 배송이 안될 듯 하지만, 모든 수단과 방법을 동원해서(…) 구매해야지 Orz

이번 설은 제주도에서 보냈다. 제주도에 있는 친가에서 3일간 보내고 서울로 귀환.

아들내미는 (대부분의) 내 친가/외가 친척들과는 처음 만나는 자리였는데, 아직 낯을 안가려서인지 인기 만점.
놀아주는 사람이 많아서인지 잘 보내다 왔다. 다만 귀성길의 비행기 안에서는, 내려가는 내내 울어서 안쓰러웠다. 귀경길엔 먹을 걸 찾아서 울지 않았음(…)

귀환길에 장염을 달고와서 (사실 오기 전부터 설사+구토 1번), 대략 만 40시간 정도 설사하고, 두 번 토하고 -_- 병원가서 약처방받고 만 이틀을 죽만 먹은 끝에 지금은 나은듯하다.
덕분에 서울에 잠시 방문한 ㅈㅎㅁ은 못 만나버림. Orz

신분 변경(?)

다가오는 3월 첫째 주에는 해외 여행도 맘대로 못 가던 신분을 탈피하게 된다. 길고 긴 1096일?

책읽기

최근 책 읽는 시간이 많이 줄었다. 1월달의 프로젝트 압박 탓 + 2월 달에는 설 때문에 앞 뒤로 이거저거 연결되서 귀찮아진듯.

복습의 의미로 두 권의 책을 읽고 있다. 하나는 TCP/IP Illustrated, 나머지 하나는 Linux Network Internals. 전자랑 후자가 다루는 레이어가 거의 안겹치고, 시대도 좀 많이 다른 탓에^[1] 여러모로 생각할 점이 많아서 좋다.
다만 최근에 집에 오면 피곤해서인지 종이책인 TCP/IP Illustrated는 진도가 더디다… Orz

Google Buzz

트위터의 단순성과는 좀 더 다른 흐름인 느낌. 사실 좀 더 취향? 구글이 뭔가 Google Wave와 FriendFeed, 그리고 gmail 을 잘 믹싱해서 꾸려나가기 시작한듯하다.
초반의  privacy 논란이 좀 안쓰럽긴하지만(…), 주변 사람들이 뛰어드는 정도(?)는 오히려 트위터 때 보다 빠른 느낌. 아마 메일 클라이언트에서 바로 연결되서 그런듯도 싶고…

다만 의식적으로(?) 트위터 연동은 좀 느리게 해놨단 느낌도 든다.

최근 글이 각 미디어(?)로 전파된 속도를 비교해보면, 대략

1. 트위터 (via Feed Burner)
2. 각 ping 서비스
3. 구글 리더(via ping service)
4. Google buzz
5. 구글 리더(via Feed Burner)
6. Twitter -> Buzz

순으로 글이 뜨는걸 확인할 수 있었다.

근데 1과 5의 속도 차이는 뭘까?(…)

Google Buzz 가 블로그를 정확히 어떤 방법으로 인지하는지가 좀 궁굼해지는군…

Updated: 날짜를 뭔가 엄한 걸 쓰고 있었음…

1. 전자는 지금은 유명을 달리한 스티븐슨 아저씨 책이다

예전에 했던 작업을 동면에서 깨워, 다시 진행해야하는 상황이 되었다(이미 2.x주 전의 얘기). 그래서 요즘 C++ + ActionScript(2.0; Flash 으로 작업하고 있는데, 나는 플래시 저작툴 라이센스가 하나도 없어서 MotionTwin 의 툴셋을 쓰고 있다. 덤으로 ASUnit 2.5 도 다시 끄집어 내서 사용 중.

예전에 Flex 로 액션스크립트 테스트를 한다는 글을 읽고, 다음에 이 쪽을 또하면 이용해보자란 생각을 했었다. 그렇지만 여전히 ActionScript 2.0 (≠Flex SDK)라서, 이걸 사용하는건 불가능.

일단 현재 테스트하는 환경/상태는 다음과 같다.

• 수 개의 .as 파일에 대해, 이 파일 중 변경 사항이 있으면^[1] , msbuild 를 실행시켜서 .swf 를 빌드해낸다.
• msbuild는 .swf를 빌드하고, 이걸 특정 디렉토리로 복사한다.
• python으로 작성한 웹 서버는 특정 디렉토리에 있는 파일들을 서비스하게 동작.
• 웹 페이지 하나에 .swf 들을 embed 로 연결하고, 이 페이지에 http meta tag 중 refresh 태그를 이용해서 30초마다 다시 실행

그리고 조그맣게 띄워놓은 웹 브라우져로 실행 결과를 지켜보고 있다. 그러니까 아직 CI 툴에 붙일 수 없는 상태(=커맨드라인 실행이 불가능한 수준).

이에 대한 앞으로의 개선책(?)은 아래 정도. 처음 두 개는 @oscarplex 님의 조언을 듣고 정리한 것.

• 테스트 결과를 받는 (python) 웹 서버를 하나 짜고, 이 서버가 정해진 형태로 유닛테스트 이름과, 결과를 받아서 (xml) 파일로 내보내는 방법
• (웹브라우져에서) 출력하는 부분을 API hooking해서 내보내는 방법
• 웹브라우져에서 드래그&복사는 되는걸로 봐서, 이걸 어떻게 자동화해버리는 방법

사실 1이 간단해보이는데(AS 2.0 통신용의 각종 모듈은 다 짜놨으니), 이거 다음주에 전달해주고나면 끝날지도 모르는데?^[2]

고향에 놋북 들고왔으면 후다닥 짜버리면 땡인데 안들고왔으니 Orz.

ps. 사실 시간이 한 4주쯤 여유가 있으면 Python으로 ActionScript 코드 토해내게 짜버리고 싶다(…).

1. 사실 파일 변경 시간(mtime)이 정해진 몇 개의 .swf 보다 최신인 파일이 있다면
2. 하지만 난 2 년 쯤 전에도 이 생각을 했지

게임 서버는 대부분의 경우 “게임 제작 시작”과 동시에 작성되기 시작하는 경우는 거의 없다. 그래서 엔진을 사서 얻을 수 있는 이익 중 하나인 “시간 단축”으로 인한 효과가 적거나 없다. 물론 상대적으로 안정화된 코드 베이스를 빨리 얻을 수 있다는 이점은 존재 한다.

2. 게임 서버 구조에 대한 컨센서스가 없다.

게임 클라이언트는 각 모듈들 – 게임 로직, 렌더링, AI, … – 이 어느 정도 잘 분해되어 있다 – 적어도 그런 종류의 고민이 많이 끝난 상태다. 하지만 서버의 경우 게임 로직과 게임 서버 자체의 구동을 위한 아랫 단의 구분이 성능 저하없이 잘 이루어져 있는 경우가 드물다. 그래서 이런 서버용 게임 엔진은 시장에 나와 있는 예가 거의 없다. 내가 아는 범위 내에서는 DarkStar 프로젝트와, BigWorld Technology의 BigWorld Server 정도 밖에 없다. 그리고 이 범위 내에서, 상업적으로 충분한 성공을 거둔 게임(eg: 연간 1m USD 이상의 매출)은 없다.

그리고 각 프로젝트마다 실제 서버 구조 차이는 꽤나 컸다 – 내가 본 사용 서버 코드만 4개가 넘는데, 각자 다른 구조를 차용하고 있고, 기본적인 도구 수준에서나 같은 모습을 볼 수 있다. 하지만 DarkStar 는 일단 단일 구조로 나왔고, 커스터마이징이 가능하긴하지만 전체 구현 자체는 MMORPG 를 노린 것으로 보인다. 그렇기에 충분히 큰 시장을 가지지 못했다고 생각된다.

3. Java 사용의 문제

* Java GC가 신뢰할 정도로 빠른가? 분명히 Java는 서버 어플리케이션의 throughput 면에서는 만족할 만한 성능을 내고 있고, 이런 분야 – 각종 트랜잭션 기반 금융 업무, 웹 페이지 렌더링 … – 에서는 거대한 시장을 이끌고 있다.

하지만 반응 속도 면에서, 최소한 일정 수준 이상의 반응 속도가 필수적인 게임 서버에서도 이게 보장되는가?^[1]  게임 서버에 가장 많은 부하가 걸릴 시간 – 메모리가 가장 모자라서 GC가 강제화라도 되어야할 시점 – 에 GC가 “한꺼번에” 일어나면 반응성의 문제가 생길 수 밖에 없다.

이건 약간 샛길로 새는 얘긴데, GC 문제는 C#에서도 역시 나타날 수 있다. 최근 런칭한 마비노기 영웅전 서버가 어느 정도 예측가능한 주기(<1일)로 비정기 점검(…을 가장한 서버 셧다운 넘기기)하는게 GC문제가 아닐까 의심 중이다. GC로 메모리가 모자라면 아주 일정한 수순을 거쳐서 서버가 죽게 된다.

1. GC로 반응(지연) 시간 증가

2. 큐에 작업이 쌓임

3. 더욱더 메모리가 필요해져서 GC 가 필요해짐

4. 악순환 시작. 실제 작업 로드를 내리는데 CPU가 사용되는게 아니라 GC에 들어감

5. 서버 사망

* 예전에 Rica 가 언급했던 서버/클라이언트 코드 공유 문제. 코드 생성기로 “우회”할 수는 있지만, 서버/클라이언트 코드 공유로 시스템 전체에서 중복을 제거하는 것도 무시못할 부분인데, 이 부분에서는 Java로 게임 클라이언트를 짜는게 거의 불가능한 상황^[2] 을 생각하면 좀 암울하다.

* Java 나 C# 류의 언어는 확실히 생산성이 높다. http://www.codinghorror.com/blog/archives/000299.html 참고. 하지만 여기서 말하는 “Write his own” 항들을 게임 서버에서는 적어도 현재로는 필요하기에 사실상 다 하고 있다. 혹은 게임 서버/서버 용 라이브러리가 있거나..

4. Java 가 새 하드웨어 기술을 잘 따라잡고는 있는가?

적어도 게임 쪽에서는 아니라고 생각한다. 게임 서버는 그렇게 “현재의 기술”만 가지고 만들어지질 않는다. 한 예로 DarkStar 가 타겟으로 잡았던 MMO 시장의 한 게임을 들어보자. EVE Online 이라는 게임이 있는데, 이 게임의 서버 구조는 어느 정도 알려져 있다 (참조: EVE Online’s Server Model)

이 게임은 서버 군(혹은 shard 란 명칭으로 흔히 부르는 그것)이라는 개념이 없다. 모든 사용자는 “하나의 논리적인 서버”에 들어가는 형태다. 이걸 가능하게 한 기술은 InfiniBand 라고 부르는 네트웍 기술덕인데, CPU 버스 수준의 통신 속도+지연 시간을 보장하는 네트웍 장치다(다만 point-to-point). 이런 상대적으로 low-level 한 기술을 나오는 즉시 사용하기에는 Java 언어 자체의 변경 속도가 느리다. 그렇다고 이걸 C/C++ 로 만든 드라이버를 작성하고, 이걸 DarkStar 같은 녀석 밑단에 JNI 연결하기엔 배보다 배꼽이 커질 것 같다. 게다가 이쯤 되면 프로그래밍 모델이 우리가 흔히 보는 UMA가 아니라 NUMA 모델에 가까워진다. 그것도 non-cc NUMA… Java는 아직 NUMA 에서 GC 구현조차 실험적 상태(experimental) 이다.

또다른 예로, 32bit –> 64 bit 넘어가던 시절에 만들어진 모 게임이 있다. 이 게임의 경우 64bit 운영체제가 시장에 나올 즈음을 타겟팅해서 작성되었는데, 출시가 늦어지면서(…), .dll 의 메모리 모델이 좀 다른 점을 이용해서, 공유 메모리 비슷한 형태로(…) 32bit 응용 프로그램이 쓸 수 있는 물리 메모리보다 더 많은 물리 메모리를 쓸 수 있게 수정해서 출시했다고 한다.^[3] 이런 low-level 한 시스템 프로그래밍을 DarkStar 같은데 연동하는건 절대로 쉬운 일이 아닐 거다.

물론 Java 가 새 기술을 따라잡으면, Java codebase 전체가 쉽게 이동한다는 장점은 있다. 그렇지만 Java 의 현재 가장 큰 시장은 게임 서버가 아니기에, 이 쪽으로의 이동이 빠를리는 없다 – 적어도 현재 시점에선 그렇게 보인다.

5. 이식성 문제나 하드웨어 호환성 문제는 서버 프로그래밍에서는 큰 이슈가 아니다

타겟 하드웨어와 타겟 OS를 정해놓고 작업할 수 있기에, Java 의 장점이라는 이식성/호환성 문제는 아예 이슈거리가 되질 않는다. 오히려 타겟 하드웨어에 맞는 최적화를 “손 쉽게” 쓸 수 없는 Java 의 문제가 생긴다.

6. DarkStar 는 모든걸 만들어야 했다

DarkStar 의 실패 원인 중 하나는, DarkStar 의 “기능”으로 소개한 것 중 중요한 것들은 3rd party library로 있는 애들이 많다는 거다. 혹은, 시장이 될만한 MMOG 제작사들이 이미 인-하우스 툴이 갖춰졌을 시점이라는 것.

DISCLAIMER: 이 글은 rein 의 개인적인 견해이며, 소속 기관 어디와의 연관성도 없음을 밝혀둔다. 또한 이 글의 각 사실 관계에 관해서는 현재 알고 있는 바에만 기초했으며, 이걸 사용해서 얻어지는 직/간접적인 결과에 대해서는 rein은 아무런 책임이 없음을 밝힌다.

1. 물론 클라이언트에서 이런 반응 속도를 속이기 위한 각종 테크닉을 사용한다. 사용자의 입력에 대한 일단의 액션을 보여주고, 최종적인 결과 처리는 서버의 판단 후에 반영된다거나(이럼 RTT 만큼의 시간은 걸린다).
2. Java 용 게임 클라이언트 라이브러리의 수는 C++용 게임 클라이언트 라이브러리 수와 order-of-magnitude 의 차이가 난다. 질 적인 면에서는 그 성숙도에서 엄청난 차이가 날 게 틀림이 없음에야…
3. 이건 PAE 같은 CPU 확장 기능을 이용하면 32 bit OS 라도 16GiB~32GiB 수준의 메모리를 쓸 수 있어서 가능한 것

Project Dark Star 의 포럼 공지에 따르면,

Today is a difficult day for all of us associated with Project Darkstar. Regretfully, we must inform our community members that Sun Labs engineering effort is no longer being applied to Darkstar development. You will hear from the individual engineers about what this means for them, but the organized lab project will not be moving forward.

One of the reasons that we developed Project Darkstar as an open source project was to allow the community to continue if the research objectives of the core team were changed. We will be maintaining the source repositories and the projectdarkstar.com site for as long as we can, but we are also investigating other homes for both the code and the supporting content.

As interesting as the technology development has been with Project Darkstar, I must say that I found the building of the community around that technology one of the most satisfying and interesting experiences of my professional life. I hope that the community will continue, and personally plan on at least observing and perhaps contributing (as an individual) to that continuation. Thank you all, and my very best wishes going forward. To the core team, I can only say that it was an honor and a privileged to work with you on this project and this technology.

간략히 요약하자면, “썬 에서는 더 이상 다크스타에 자원을 투입하지 않을 예정. 공시적인 개발은 더 없다. 웹 사이트와 소스 저장소는 가능한 유지 할 것이며, 코드와 지원 자료를 위한 공간을 찾는 중이다.”.

예전에 이 프로젝트 다크스타의 테크 데모를 봤지만 그 때 느낌으로도 “이거 망하겠네”였는데, 약 2년 반 정도 지난 지금, 프로젝트가 내려지는걸 보고있으니 기분이 좀 묘하긴하다.

내가 생각하는 실패 이유에 관해선 곧 글을 하나 더 써보기로 하겠다.

ps. 프로젝트 다크스타의 github 이름은 red-dwarf. Dark star 가 (겨우) red-dwarf가 되어버리다니… 참 의미심장하다?

1. 2009년 12월 27일을 끝으로 만료된 rein.kr 도메인을 구입했다 – 물론 만료 후 한 달이 지나야 다른 사람이 등록할 수 있기에 어제 구입. 구매할 때 상당히 많은 개인정보를 요구하는건 유감이지만 — .kr 도메인이 아니고서야 한국 내에서 살 이유가 없으니 – 어쨌든 도메인 주소가 대폭 짧아졌다.

여기까지 해서 http://rein.upnl.org/wordpress 를 http://rein.kr/wordpress/ 로 이전.

2. 도메인 주소가 짧아지고나니, wordpress 라는 블로그 디렉토리 이름이 묘하게 길어보이기 시작(…).

집에 돌아와서 mod_rewrite 를 열어 수정을 했다. 뭐가 문제였는지는 모르겠지만, top-level 주소는 제대로 redirection^[1] 되던데, 나머지 주소들 – 그러니까 WordPress 에서 사용하는 archives/post-name tags/tagname 같은 대부분의 주소들 – 은 제대로 redirection 이 안되서 어젯밤은 GG 치고 자러 갔다.

3. 오전에 병원가려고 준비하다가 mod_rewrite 대신에 mod_alias 를 쓰면 되겠다 싶어서 간단히 proof-of-concpets 코드만 짜고 병원 행.

오후에 잠시 난 짬을 써서 주소를 옮겼다.

설정은 다음 코드를 이용.

이걸로  http://rein.kr/wordpress 를 http://rein.kr/blog 로 전환. 하지만 rein.upnl.org/blog 로 직접 접근해오는 경우는 웹 브라우져 주소창에는 여전히 이전 주소로 찍힌다.

4. 301 redirect 될 주소에 도메인 주소까지 명시적으로 줘봤다. 잘 된다!

이제 rein.upnl.org/wordpress 로 접속해와도 rein.kr/blog 로 간다

이제 블로그 내부 데이터에 박혀있는 – 그러니까 각 글들의 링크, 사진 주소 등등 – 데이터를 rein.kr 기반으로 옮기면 끝.

여기까지가 현재 상태.

남은 문제:

• Google 검색 정보 옮기기: WebMaster 툴에서 내가 upnl.org 는 소유하고 있는게 아니라고 거부한다
• upnl.org 를 내껄로 위장(?)하기?
• 구글 커스텀 검색이 rein.upnl.org 기반 페이지로 가려고 시도함. 어디서 바꾸지?^[2]

과연 언제다 해결?

2010-01-31 13:42 – 블로그 각 글에서 rein.upnl.org 사용되는 것 rein.kr 로 이동. 이제 메타데이터 테이블 고쳐야?

1. HTTP 301 응답; permanently moved 이용
2. 물론 저기로 가봐야 다시 돌아오게 아파치 설정을 고쳐서 별 문제는 안생김

기대에 비해서 좀 아쉽게 나온듯 해서 간단히 글로 정리해보겠다.

Pros.

생각보다 더 큰 화면이다. 7~8” 수준일 거라고 생각했는데 좀 더 큰 기계가 나온듯. 이 정도 크기에 애플 데모처럼 웹 서핑이 충분히 빠르다면 “집에서 쓰겠다고” 넷북 살 일은 적어도 나에겐 안생기겠다.

프로그래밍을 할 수 있을 정도로 serious 한 장비를 사거나, 아예 딱 가볍게 나온 장비(=iPad)를 살 듯

빠르고 3G 연결을 지원한다. 전용 프로세서를 만들어버린 애플. 2D 가속이 좀 더 쎄다는데, 3D 는 솔직히 모바일 장비에서 사용하기엔 아직 시간이 더 필요할 것 같다.^[1] 웹서핑 + 이북리더 + …아이폰 기능 일부를 합친 건 멋있음.

싸다. 정말 싸다. 물론 액세서리가 꽤나 많이 필요할 것 같긴하지만, 기본 가격만 놓고보면 소득이 있고/전자제품에 조금이라도 익숙한 직장인은 거의 부담가지 않을 수준에 가까운 듯 하다.

잡지류에 대한 (현재 상태로는) 최상의 플랫폼이다. 컬러가 되고, 무선 통신이 된다는 점에서 최고. Kindle DX를 쓰면서 아마존에 구독가능한 잡지 리스트가 꽤나 제한적인거에 의아해했는데, Kindle/Kindle DX가 컬러를 지원하지 않아서 무의미한 잡지가 많아서라고 생각된다. 그런 점에서 iPad가 좋긴한듯…

Cons.

UI를 이해할 수 없다. 10”나 되어버리면 한 손으로 잡고 다른 한 손으로 조작하는게 전혀 쉽지 않다. 지금 내가 사용 중인 Kindle DX랑 거의 같은 form factor로 나오게 되는데(다만 iPad 가 100g쯤 더 무겁다), 킨들 DX도 한 손으로 오래 보고 있으면 – 특히 왔다갔다거리는 시내버스 안 같은 곳 – 꽤나 힘들어서 손을 바꾸게 된다. 근데 과연 여기서 iPhone / iPod touch 에서 보여줬던 양손 + 멀티터치의 장점을 살릴 수 있을까? 10”나 되는 대화면은 절대 양손으로 잡은채로 전 영역을 다 사용하면서 커버할 수 있는 영역이 아니다.

차라리 MS Courier 데모 영상이 UI 면에선 더 끌림 – 거의 고정된 공간에서 한 손으로만 사용하는 예시. 다만 MS Research 는 정말 최고의 연구(결과)를 내지만, MS 구현에서 엄해지는 꼴을 워낙 많이 봐서…(심지어 youtube 댓글에도 그런게 보이더라…)

여전히 Adobe Flash 를 지원하지 않는다. 이건 여러모로 “정략적”이라고 생각되지만. 왜냐하면 웹 앱 수준 말고는 전부 “설치해서” 사용해야하는데, 그 경계에 있는 플래시를 애플이 전략적/정량적으로 막아놓은 거라고 생각한다. CPU 파워를 생각하면(적어도 데모에서) 플래시를 지원못할리가 없는데 지원 안하는 것이 애플의 전략이라고 생각한다. 그래야 애플이 직접 통제할 수 없는 애플리케이션 마켓(여러가지 의미로)이 안 생기거든…

“랜덤여신의 폐인 모드”의 최근 글에 따르면, 구글처럼 창의적인 회사는 이걸 뚫고 VoIP 지원(…이라기엔 좀 미약해도)을 시작했다고 한다.

다만 애플이 XBox 나 PlayStaion 같은 현재의 정책 — 하드웨어는 싸게 팔고, 소프트웨어 판매 이윤의 일부를 가져가는 형식 — 을 쓴다면, 이건 한동안 지원되지 않을 거다. 그래서 Adobe 는 아이폰 앱을 바로 만드는 기능을 추가하고있고 / 이건 애플에서도 반대하기는 커녕 환영할듯…

출판사들은? 잡지사들은? 내가 얘네 런칭 행사에 당연히 할 거라고 생각한 것 중에 하나는 “우리는 이 출판사, 이 잡지사와 계약해서  … 들을 바로 구독할 수 있습니다!” 같은 멘트였다. 하지만 이런건 없음. 이북리더로(특히 잡지와 주간지류)도 꽤나 훌륭한 플랫폼이 될꺼라고 생각했는데, 명확히 지지하는? 대형 출판사/잡지사가 없는듯하다? 직접 빛을 생성하는 디스플레이라 오래 보는게 편할 것도 아닌데, 당장 어떤 잡지를 볼 수 있게 해주는 지도 얘기 안하는건 좀 실망.

4:3 화면. 아직 4:3 화면을 고수하는 이유가 뭘까? form factor가 미적이지 못한가? 아니면 16:9 로 화면을 출력하고 나머지는 UI에 할당하라는 배려냐?

App 지원. Legacy 지원을 단박에 자르길 잘하는 애플이지만, 이번엔 iPhone 앱을 업고 간다. 근데 아이폰 앱 중에서 iPad 에도 유용할 녀석이 얼마나 될지는 좀 의문. 개발자들의 “개발 부하”만 올려놨다는 느낌이다.

1. 3D 성능을 올리기위한 각종 기술이 상대적으로 전력/계산량 비가 안좋다

일부 디렉토리가 접근이 안된다거나, 특정 그림/사진이 안보인다거나, 링크가 잠시(?) 접근이 안된다거나 할 수 있는 상황.

주말까지 간헐적으로 문제가(혹은 폭발적으로?) 생길 예정..

<IfModule mod_alias.c>
    Redirect 301 /wordpress /blog
</IfModule>

로 일단 수정. 과연 이걸로 끝?

그런데 소켓 정책 파일(flash socket policy file)을 얻어오지 못하는 게 아닌가?^[1]

한참 고민하고 + 코드 리뷰하고 나서야 문제를 파악했는데, 내 C++ 코드나, ActionScript 적응단 문제가 아니라 Adobe 에서 제공하는 flashsocketpolicyd 의 python 구현체 일부에 문제가 있는 코드가 있었다.

IPv6 (AF_INT6) 로 소켓을 열어보고, 안되면 IPv4 (AF_INET) 로 소켓을 여는 구현인데, 문제는 Windows 나  일부 UNIX 구현체 들 중 일부는, IPv6 소켓이 IPv6 스택만 지원하는 형태로 여는 게 기본 값이라는 것. 덕분에 IPv4 스택을 이용하는 클라이언트 프로그램(=flash player) 랑 통신 못하는 것. 야 임마 ㅠㅠ

이게 예전에는 잘 되었던 이유는, WinSock을 사용하는 경우, 듀얼 스택 자체를 XP/2003 서버까지 지원하지 않았고 예전에는 Windows Server 2003(x64) 에서 작업했기 때문. 덕분에 try 에서 항상 예외가 나서 IPv4 소켓을 생성했기에 잘 돌았지만, Vista x64를 쓰는 지금에 와서 빵 터진 듯 Orz

듀얼 스택 지원 부분을 저렇게 안일하게 구현하면 안되지. 아무리 reference code 수준이 될까 말까한 거라곤 해도 이건 좀 아니지 않나?

1. 게다가 예전에도 언급했지만, 소켓 정책 서버에서 파일을 못 가져오면, 처음 붙는 소켓에 또 요청을 날리기에 C++ 서버는 예상치 못한 XML 요청을 받게 된다. =_=

이번 주 업무량에 + α를 더해준 버그들을 소개해보겠다.

C++ 삽질

작년 끝 무렵에 팀에 합류한 후배 i 군이 서버 군을 대상으로 테스트를 돌리는 툴을 만들었다. 이걸로 몇몇 서버를 테스트했는데, 타이머 이벤트 처리하는 부분에서 메모리 릭이 생기거나 크래쉬가 나는 것이다 Orz. 덕분에 어제 야근.

삽질했던 이유는, 기존에 별도 라이브러리였던 타이머 구현체를, 기본 라이브러리 안으로 가져오면서 boost 의존성을 뺐는데, 이때 boost::shared_ptr 를 코어에서 빼내었다. 근데 이 새 구현체에서 스마트 포인터의 의미적인 부분(semantics)을 완전히 동등하게 구현한 게 아니라서 특정 경우엔 메모리가 새거나, 프로그램이 죽거나 한 것.

결국 긴 시간의 코드 리뷰 + 약간의 의미 바로잡기 + 약간 긴 테스트로 수정 완료.

Python 삽질

내가 작업하는 프로젝트 하나의 결과물인 바이너리와 몇 가지 도구를 다른 팀에 건sp주게 되었다. 근데 여기에는 Python 으로 작성한 몇 가지 도구가 있는데, 이걸 그냥 주자니 파일이 너무 많아서, py2exe 로 하나로 합쳐봤다. 이제 일어난 문제…

1. 툴 중에 다른 프로그램들을 로컬 혹은 리모트에 띄워 주는 툴이 있다
2. 이 툴을 실행 시켰 더니 프로세스를 계속해서 실행해서 윈도우즈 서버가 사망^[1]
3. 문제를 찾아보니 py2exe 결과물에선 sys.executable 이 py2exe 의 출력과 동등하게 되고
4. 내가 짠 툴에서는 .py 확장자인 녀석을 실행할 때, 실행 바이너리를 sys.executable 을 썼고
5. 덕분에 py2exe 결과물은 자기 자신을 무한 fork()…

Orz.

사실 이 문제는 python subprocess의 win32 구현체가 CreateProcess를 써서 생기는 건데 흑흑. 그냥 ld 처럼 해주면 안 되겠니?

이건 아직 해결은 안 하고 미뤄뒀지만, 해결하려면 i 군 말마따나 python.exe 로 .py 를 실행하게 하지 말고, 저것도 py2exe로 바꿔놓고 해야 할듯함?

덤으로, 이제까지 이런게 있는 줄도 몰랐는데(…), isinstance 란 내장 함수가 있더라. 나 이거 때문에 try: … except: 로 짠거 몇 개 있는데…

이게 프로그래머의 삽질 + 인생인가? 흑흑

1. 이건 결과적으론 *nix 류에서 결과 검사 없이 fork() 하는 코드 비슷하게 되어버렸다

일단 토요일은 잤고 Orz, 일요일엔 집 근처에 “커피와글”이란 이름의 작은 카페를 갔다. 여러 우여곡절끝에 닫았다가 다시 개장한거라 원두가 종류별로 있는게 아니어서 아쉬웠지만, 아내랑 아들이랑 같이 다녀왔음.

여전히 아기자기한 소품에, 괜찮은 드립 커피를 마실 수 있어서 좋았음. 간만에 와플(와플 + 생크림 + 바닐라 아이스크림) 도 먹었음…

아들은 유모차를 처음으로 타서 신기한듯하다가 가는 사이(약 15분?)에 잠들어버렸더라;;; 근데 도착하더니 깨서 두리번두리번; 작년 봄~여름 사이에 한창 갔던 카페라 그런지, 바리스타 한 분이 아내를 알아보고

“그 때 뱃속에 있던 애네요~”

하고 맞이해주더라. 역시 이런 점에서 동네 카페가 좋은가?

가서 간단한 개념 증명(proof of concept) 코드를 짜고 / 간단한 서베이를 한 듯… 근데 책은 읽으려고보니 안가져왔더라 /먼산

아들내미는 얌전히 앉아있다가, 잉잉대서 가서 좀 안아주고 하다가 결국 집으로 갔다. 근데 한 한 시간은 얌전히 앉아있던듯? 하지만 나중에 사진을 찍은걸 보니 뚱한 표정이긴 하다 흐흐.

다음 주 모 프로젝트 허들이랑, 모’ 프로젝트 결과물 이전이랑, 모’’ 프로젝트 수정작업이 남아있지만 뭐 적당히 재충전은 된듯하니 어떻게 되겠지(…)

jacking 님이 “책상 위 모습을 사진 찍어서 트랙백을 쏴보자”는 글을 썼다. (아래는 그 글 인용)

어제 트위터에 올라온 글을 보니 그래픽 디자이너의 일하는 자리를 찍은 사진을 투고하는 이벤트를 하더군요.
그 글을 보니 회사에서 프로그래머의 책상 위는 어떤 모습을 하고 있을지 궁금하더군요.
혹시 자신의 자리를 사진을 찍어서 올릴 수 있는 분들은 트랙백이나 덧글을 통해서 자신의 자리를 구경 시켜주세요

라 쓰셨길래 예전에 찍은 사진이지만 링크.^[1]

작년 8월(2009/08)에 찍은 사진인데, 지금은 왼쪽 안 보이는 부분에 앉은뱅이 책장을 올려버리고, 그 밑에 데탑을 보관 중.
저 사진에서 살짝 보이는 베어본을 없애버리고(…), 데스크탑 머신이 3 대가 되어버려서 –_- 어쩔 도리 없이 책상 밑 공간 늘리고(이건 PP 할 때도 편함) 데스크탑 컴퓨터 들을 주욱 늘어놓았다.

그리고 왼쪽에 보이는 17” 모니터는 모니터 높이가 안 맞아서 모니터 바꿔가면 볼 때 “시각적으로 덜컹” 하는 느낌을 받아서 밑에 책 몇 권 깔고 윗쪽 높이를 맞춰놓았다. 예전 사진이라 없지만 아내 사진도 책상 위에 하나 있고, 아기 용품 두느라(…) 집에서 회사로 옮긴 피규어도 올라가있고, 연필 꽂이용으로 쓰고 있는 알라딘 머그컵도 올라가 있다(…). 그거 빼곤 그대로임…

프로그래머라고 해도 모니터만 보면 사는건 아니고, 생각을 정리하거나, 다른 프로그래머랑 얘기할 때는 종이와 연필이 더 편할 때도 많아서 텍스트 패드 하나 올려놓고 쓰고 있다. 여튼 내가 쓰는 도구는 (물리적으로는),

• 컴퓨터 2 대 (1 대는 사무용)
• 17” + 24” 모니터 (1대는 역시 사무용)
• KVM으로 물린 리얼포스 101키(영문) + 로지텍 MX510
• 약간의 종이와 연필(…), 벽에 가끔 달아놓는데 쓰는 자석

으로 끝인듯하다.

다른 프로그래머 분들의 사진도 매우 보고싶은 상태가 되었음. 여러분, 어서 트래백을 쏩시다!(…)

1. 사진은 이전 사진 그대로 게재

…를 올해 목표로 하고 진행해보려 한다. 왠지 좀 많아보이지만(…) 처음 두 개는 지금도 적당히 하고 있으니까 잘 되야하겠지?

올해에도 예전에 만들어놓은 WordPress Annual Stats 를 가지고 글감으로 써 먹었다.

일단 쓴 글 수 총 108개.

1, 2 월 날려먹고, 그 이후로는 거의 10~14개 수준의 글을 썼다.

다만 댓글 수(615개)는 그에 비례하지 않는다는게 문제지만;;

9월에 아이가 태어난 덕에 잠시 댓글 수가 폭주하고(…) 올해는 전체적으로 잠잠했다 – 그러니까 변방 웹로그.

작년과 비교해보면 비참한 현실을 볼 수 있다. 글 수 309 개 vs. 108 개, 댓글 수 1522개 vs. 615개.

전체적으로 작년 보다 글도 적게 썼고, 그에 따라 댓글도 적게 달렸다 정도? 내년에는 2009년 보다는 많이 써야겠지;;

그리고 내가 쓴 글들은 다음과 같은 태그를 주로 달았다.

Programming, 잡담, C++, 책, Windows 관련된 글을 주로 쓴 듯 하다. 결국엔 프로그래밍? 인 듯.

실질적으론 이런 모양.

• Programming    54
• 잡담    31
• C++    19
• 책    15
• Windows    11
• Web, Blog, 회사 각  10
• 멀티스레딩, Test, WordPress    8
• Google, twitter  7
• Kindle, svn    6
• Python    5
• git, 다국어    4
• Mac, live writer    3
• 기타    33

결국 프로그래머의 잡담 로그라는 본연의 이미지대로(…)

개인적으로는 결혼식을 했고, 신혼 여행도 다녀오고, 아들이 태어났다. 그리고 오늘 아들이 100일을 맞았다.

회사에서는 프로젝트 2개를 추가로 하게 되었고, 하나는 일단 끝맺음했음. 개인적으로 현재는 10일 연휴의 7일차(…).

그리고 수 많은 아쉬운 일들 — 내가 지지 했던 두 명의 대통령이 사망한 것 — 을 포함해서, 입에 담기도 싫은 몇 가지 정책들을 보면서 괴로워하고, 앞으로 뭐가 일어날지 머리가 아프다.

1월에 세웠던 한 해 목표를 보고 생각하자면,

legacy code를 가지고 TDD 하는건 절반의 성공 절반의 실패. 하나는 어느 정도 진행했으나, 하나는 결국 포기하고 갈아엎어버렸음(…).

제대로된 mock framework을 붙이는건 결국 개인적인 수준에서 끝났고, 팀 코드 수준에서는 아직 멀었음.

결국 내년에도 계속해야?

이제 몇 시간 남지 않은 시간이지만, 본 블로그에 방문하는 여러분들에게도 지난 한 해 괴로웠던 일, 슬펐던 일 갈무리하시고, 즐거웠던 일 떠올리면서 새 해를 맞이해봅시다

알라딘 밀어주기란 글을 읽고^[1] 바로 결제를 시도해보니 잘 된다. 덕분에 5.6만어치의 책을 샀다는건 비밀

플랫폼 다양성이 커지면서, 그러니까 단순히 PC 용 OS 다변화나 웹 브라우져 다변화 이상으로, 일반적인 사람들 — IT 종사자들이 좀 더 트렌디하기야 하겠지만 — 이 쓰는 플랫폼 (하드웨어 + OS + Web Browser 일체) 이 다양해지고 있다는건 요즈음 들어 대부분의 사람들이 “느끼게”되는 일이다. 근데 알라딘은 예전의 검색 API 공개나, TTB  및 TTB2 를 놓고 볼 때 정말 “기술적인” 트렌드는 잘 따라가는 느낌이다.

집에서 노트북으로 책 고르고 PC에서 결제하려면 무진장 귀찮았는데, 게다가 요즘은 Windows 7쓴다고 VM 띄우고 XP  에서 결제하느라 귀찮음 3배 모드였는데 참으로 좋은 일인듯. 예전에 Yes24 에서 알라딘으로 넘어갔던게  ”Firefox 에서 페이지 렌더링이 개판”이라는 이유였는데 — 물론 지금은 yes24도 IE  외에서도 잘 렌더링함 — 이젠 더더욱 알라딘 쓸 이유가 늘어가네요. 요즘 아마존에서 질러대서 상대적으로 덜 지르고 있지만…

웹 표준성이나 웹 접근성 이슈랑은 별개로, “편하게 쓰게 해준다”는 이유 하나만으로 알라딘의 이번 non-active-x 접근법을 매우 환영한다!

ps. 사실 비슷한 이유에서 cgv 안가고 메가박스를 가고 있기도 함. 회사에서 코엑스가 매우 가깝기도 하지만;;

1. 해당 블로그 글의 논조는 나랑 좀 안맞지만 그건 별개로 치고