重い足でぬかるむ道を來た

무거운 발걸음으로 진창길을 걸어왔어

トゲのある藪をかき分けてきた

가시덤불을 헤치며

食べられそうな全てを食べた

먹을 수 있을 것 같은건 모두 먹었어

長いトンネルをくぐり拔けた時

긴 터널을 빠져나왔을 때

見慣れない色に包まれていった

낯선 풍경에 둘러싸여있었어

實はまだ始まったとこだった

실은 이제 막 시작한 참이었는데

「どうでもいい」とか　そんな言葉で汚れた

「아무래도 좋아」같은, 그런 말에 더러워졌어

心　今放て

지금 마음을 열어

春の歌　愛と希望より前に響く

봄의 노래가 사랑과 희망보다 먼저 울려퍼져

聞こえるか?　遠い空に映る君にも

들리니? 먼 하늘에 비치는 너에게도

平氣な顔でかなり無理してたこと

아무렇지도 않은 얼굴로 꽤 무리했던 일

叫びたいのに懸命に微笑んだこと

울부짖고 싶은데 힘껏 웃은 일

朝の光にさらされていく

아침햇빛에 바래져 가네

忘れかけた　本當は忘れたくない

잊어버렸어 사실은 잊고 싶지 않은데

君の名をなぞる

너의 이름을 그리네

春の歌　愛も希望もつくりはじめる

봄의 노래가 사랑도 희망도 만들기 시작하네

遮るな　何處までも續くこの道を

끝없이 이어지는 이 길을 막지마

步いていくよ　サルのままで孤り

원숭이인채 혼자서 걸어가네

幻じゃなく　步いていく

환상이 아니라 걸어가네

春の歌　愛と希望より前に響く

봄의 노래가 사랑과 희망보다 먼저 울려퍼져

聞こえるか？　遠い空に映る君にも

들리니? 먼 하늘에 비치는 너에게도

春の歌　愛も希望もつくりはじめる

봄의 노래가 사랑도 희망도 만들기 시작하네

遮るな　何處までも續くこの道を

끝없이 이어지는 이 길을 막지마

원래 음악을 들을 때 가사에 거의 신경을 쓰지 않는 편이지만 스피츠의 가사는 좋아한다. 이들의 가사는 주로 일상의 많은 감정의 교차를 불러일으키는 작은 순간을 세심하게 잡아내거나, 이해되는 수준의 감성적인 낱말을 덤덤하게 표현하는데 있어 수준급의 능력을 보여준다.

1. 터치 인터페이스 프로젝트에 대해, 스티브 잡스는 마이크로소프트의 태블릿 개발자가 스타일러스를 이용한 인터페이스가 미래라고 주장하는 것에 분노한 것이 계기가 되어 시작했다고 주장했으나, 조나단 아이브의 말은 전혀 달랐다. 아이브는 맥북 프로의 멀티터치 트랙패드를 만드는 도중 이를 스크린에 붙여보고나서 이 것이 굉장함을 직감했고, 스티브 잡스가 이 것을 거절할 것이 뻔했기 때문에 여가시간을 할애해가며 자신의 팀원들과 몰래 터치 인터페이스를 개발했다고 한다. 어느 정도 개발되었을 때, 개인적으로 잡스에게 이 것을 보여주었고, 다행히 만족하였다고.

2. 아이폰은 원래 휠 인터페이스를 이용해 개발하고 있었으나, 원하는 사용자에게 빠르게 전화를 걸 수가 없는 등 인터페이스에 문제가 많았다. 새로운 터치 인터페이스에 만족한 애플은 아이폰을 2가지 버전으로 개발하였는데, P1은 휠 인터페이스였고, P2는 터치 인터페이스였다. P1은 잘 만들어져있지만 인터페이스 한계가 분명했고, P2는 인터페이스가 혁신적이었으나 엔지니어링 이슈가 많이 남아있었다고 한다. 그 후의 결정은 우리가 잘 알고 있다.

PHP 5.4에서 주목할 만한 변경점

최근 PHP가 망할 조짐을 조금이라도 느끼고 있는지, 갑자기 사용자 의견을 적극적으로 반영해서 발 빠르게 작업을 하고 있는데 (시간 있고 관심 있으면 전체 목록을 참조), 그 중 아래 것들은 꽤 주목할 만하다.

1. Function array dereferencing

원래 PHP는 황당하지만 이게 안 됐다.

function boo(){
    return array(1,2,3)
}

echo boo()[1];

이게 안 되어서 특정 변수에 함수 결과를 받아놓고 $var[1] 로 접근해야 했었는데, 이번에 드디어 이걸 지원하게 되어서 Array 반환 값이 존재하는 메서드 체이닝이 가능하게 되었다. 제안 및 패치는 2008년부터 있던 건데 허세 부리다가 인제야 정식으로 추가됨.

2. Allow <?= regardless of short_tags

본래 allow_short_tags 옵션이라는 것이 php.ini에 있었는데, XML 문법과 줄여 쓰는 PHP template 문법 (<?)가 겹쳤기 때문에 allow_short_tags를 키면 XML 문서를 해석할 때 많은 애로사항이 생겼었다. 하지만 그렇다고 이 옵션을 꺼버리면 <?= ?> 문법을 죄다 <?php echo … ?> 와 같이 사용해야 했기 때문에 불편하다. 5.4는 저 옵션에 상관없이 <?= ?>는 PHP가 파싱한다.

3. Array short syntax

framework이나 library를 쓰다 보면 PHP에서 제일 많이 쓰게 되는 것이 array일 것이다. 축약 문법을 몇 년 동안이나 고집스럽게 지원하지 않고 있다가, 이번에 드디어 축약 문법을 지원하게 되었다. 5.4에서 아래 코드는

$a = array(1, 2, 3);
$b = array('foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon');

이와 같이 표현할 수 있다.

$a = [1, 2, 3];
$b = ['foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon'];

웃긴 점은 세 가지 모두 아주 예전부터 제안이 오가던 것인데, 사용자들이 죄다 찬성해도 개발자 놈들이 껄떡거리면서 뻐기고 있다가 인제야 추가된다는 것. 이제 드디어 일이 정상적으로 돌아가는 느낌이다. 너무 늦은 것 같긴 하지만…

PC-9801 에뮬레이터용 음독폰트

소개

PC-9801은 일본에서 주로 사용되었던 컴퓨터 기종이며, 80~90년대에 이를 통해 많은 게임이 출시되었다. 국내에 수입된 대부분의 일본산 고전 게임은 PC-9801용으로 먼저 제작된 것들이 컨버전된 경우가 많았다.

최근 보면 국내에 수입된 도스판보다 PC-9801 버전이 더욱 즐기기 좋은 일이 있는데, 가령 숨겨진 기능이 원판에만 존재한다거나, 도스판으로 이식되면서 몇 가지 문제가 생겼다거나, 도스판은 도스박스 에뮬레이터가 정상적으로 구동시키지 못하는 데 비해 PC-9801판은 에뮬레이터로 꽤 잘 실행된다든지 하는 경우가 그 예이다. 이런 여러 가지 이유로, 종종 PC-9801용 일본판이 선호되기도 한다. ¹

여러가지 이유로 더 쾌적한 플레이를 위해 일본판을 선택할 경우, 일본어를 모른다면 플레이 시 많은 지장을 받게 된다. 이 음독폰트는 에뮬레이터 시스템에서 이용하는 폰트의 한자, 가타가나를 한국어 발음으로 치환한 폰트로, 이 폰트를 이용하는 것만으로 모든 한자와 가타가나가 한글로 보이게 된다. 단어에 있어서 한국어는 일본어와 동일한 단어를 많이 채택하였기 때문에, 이 음독폰트를 이용하는 것만으로도 상당히 게임 플레이에 도움이 된다.

제작은 Shift-JIS 폰트테이블을 구한 후, 수민이가 만든 한자-한글 변환기를 이용해 치환받은 데이터를 폰트파일 스펙에 맞게 다시 그려주는 프로그램을 구현하여 만들었다.

다운 받기

음독 폰트를 다운로드 받은 후, Anex86 이나 Neko Project II를 이용해서 해당 폰트를 선택해주면 게임에 바로 반영된다.

사용 결과

Pure REST vs Pragmatic REST

Nobody Understands REST or HTTP라는 글이 Hacker News 1면에 올라오고나서 여러가지 토론이 일어났다. 토론의 내용은 실용적인 관점에 있어 Pure RESTful interface가 유효한가에 대한 부분이 꽤 중요한 부분을 차지하고 있다.

야간개발팀에서 만들고 운영중인 VLAAH의 경우에도 1G때 개발 아키텍트인 민희가 여러모로 신경을 써서 HTTP 프로토콜을 거의 완전하게 이용하는 Pure RESTFul API를 선보인 바가 있다. 2G로 올라가면서 2G API가 아직 미구현인 부분이 꽤 있지만, 국내는 물론 세계적으로 통틀어보아도 이정도로 원칙적으로 완전하게 RESTful API를 구현한 사례는 거의 없다고 생각한다.

그러하다보니 야간개발팀에서도 이 부분에서 많은 논의가 있었고, 그 당시의 경험과 여러 개발 API를 만져본 나의 소감은 이러하다.

우리가 당시에 Pure REST API를 구현하면서 생길 가장 큰 걱정거리는 개발자 접근성이었다. Nobody Understands REST or HTTP을 읽어보면 알 수 있지만, Pure REST API는 HTTP Request Header를 적극적으로 활용한다. 받아올 데이터 형식도 헤더에 명시하고, 버전도 헤더에 명시한다. 엄연히 Request Header에 표준으로 존재하는 것을 쓰지 않고 URL에 버전명과 요청 포맷을 명시하는 것은 깔끔하지 못하기 때문이다.

하지만 세상에는 HTTP 프토토콜에 대한 이해도가 거의 없으면서 웹서비스를 개발하는 개발자들이 굉장히 많다. Request Header를 못고치는 개발자가 존재하냐는 의문이 들지만, 의외로 찾아보면 대다수의 개발자들은 자신이 개발하는 환경에 대한 이해도가 상당히 떨어지는 것을 알 수 있다. 이는 결국 개발자 접근성의 하락을 가져오고, 결국 손해는 플랫폼 홀더가 지게된다. 개발자들이 할 줄 모른다고 API를 가져다 쓰길 거부하기 때문이다. 많은 웹개발자들은 브라우저만으로 API를 테스트할 수 있기를 원하고 우리는 이에 대해 고민해야했다.

우리들은 여기서 가장 깔끔한 방법을 선택했는데, 브라우저로 API를 테스트하는 것을 포기하는 대신, 더 쉽게 이용할 수 있는 언어별 클라이언트를 만들어주기로 했다. 언어별 클라이언트 라이브러리가 있으면 브라우저를 통한 API 테스트를 할 필요도 없으며, 그렇기 때문에 Pure REST를 포기하지 않아도 되었기 때문이다.

하지만 이 방법의 가장 큰 문제는 비용이었다. 대부분의 메이저 언어에 대한 API를 만들어야했는데, 민희가 루비 Gem을 만들고, 강성훈님이 파이썬 라이브러리를 만들어주셨고, 여러 다른 분들의 도움이 있었지만 유지보수까지 생각하자니 비용이 너무 커졌다. 결국 2G로 업데이트시 프로토콜 업데이트를 하며 많은 것을 포기해야했었다.

그래서 나의 결론은 이렇다. 개발자가 이용하는 인터페이스일지라도, 개발자또한 사용자로 보며 지식수준을 최대한 넓게 커버할 수 있어야 한다. 하지만 이와 동시에 만드는 주체의 개발비용도 고려대상에 들어가야 한다. Pure를 조금 타협보는 대신, 다른 가치를 제공하는 것에 더 시간을 투자할 수 있다면 그것이 더 좋은 결과로 이어질 것이다. 다만, 몇가지 요소를 제외하면 실용적인 부분에서 많은 REST의 기본 원칙은 분명히 유효하다.

그래서 나의 REST 인터페이스에 대한 원칙은 최대한 지키되, 브라우저로 쉽게 테스트할 수 있도록 설계한다이다. 브라우저에서 지원하지 않는 PUT과 DELETE는 이용하지 않거나 우회법을 제공하고 ¹, 버전이나 데이터형식은 URL에 할당하여 브라우저 테스트를 가능하게 하는 것이다. Dropbox의 API 디자인도 이와 비슷한 생각을 가지고 있다.²

View high resolution

szymon:

Wi-fries - McDonalds ad by DDB Australia

단점과 장점은 있다/없다 가 아니라 크다/작다 이다.

의외로 많은 사람들이 하는 실수이고 나도 자주하는 실수이지만, “이러이러한 단점이 있기 때문에 안됩니다.” 는 바람직하지 못한 논리전개이다. “이러이러한 단점이 있는데, 이것은 저러저러한 장점에 비해 꽤 큰 손실이기 때문에 안됩니다.”가 되어야 된다.

크기를 생각하지 않으면 단점이 더 큰 것을 골라놓고 장점이 있으니 괜찮다고 하고, 장점이 더 큰 것을 반대하면서 단점이 있으니 안된다고 하게 된다. 즉, 손해인 선택을 할 위험이 커진다. 모두가 장점도 있고 단점도 있다. 우리는 그 중에서 장점이 큰 것을 골라야 한다.

View high resolution

믿음.

믿음에는 조건이 없어야 한다. “무조건 믿는다”와 “믿는다”는 같은 말이다. 믿고 싶을 때만 믿고 아닐 땐 아니라고 생각하는 건 믿는 것이 아니다. 믿음이란 본래 그렇게 맹목적인 것이다. 조금 멍청해보이지만, 때로는 믿음으로 이루어내는 혁신과 가치가 존재하기도 한다.

그러니 믿을 사람을 찾으라는 말의 무게는 매우 무거운 것이다. 위의 말에 동의하지 않으며 타인에게 쉽게쉽게 믿는다고 이야기해왔다면, 필시 많은 사람에게 상처를 주어왔을 것이다. 어떤 똑똑한 사람들은 아무도 믿지 않지만, 어떤 똑똑한 사람들은 믿음으로 발생할 수 있는 실패의 중압감을 충분히 준비하며 믿음을 가진다. 나는 후자가 매력적이다.

프로젝트를 처음 시작할 때 서로의 영역에 대해 확실히 정해두자.

여럿이 프로젝트를 함에 있어서 각자의 영역에 대해 위치를 잡아두고 이에 대한 서로의 결정력에 대한 존중을 미리 약속하는 일은 굉장히 중요하다. 이에 대해 서로 이야기해놓지 않으면, 여러 영역에 걸쳐 서로간의 선택이 충돌할 때 많은 낭비가 발생하게 된다.

첫째로, 결정과 책임의 관계는 뗄레야 뗄 수 없는 관계임에도 이런 약속이 없다면, 어떤 영역에서 누군가는 책임지지도 않을 생각이면서 반드시 결정에 영향을 끼치려고 하는 케이스가 존재하게 된다. 하지만 미리 약속하지 않는다면, 이에 대해 제지할 수 없다. 프로젝트의 비즈니스에 관심을 끊은 사람이 수익 모델을 논하고, 개발에 손톱만큼도 참여하지 않는 사람이 사용 언어에 대해 논한다고 생각해보자. 끔찍한 일이다.

둘째로, 팀 내 정치가 아주 빈번하게 발생하게 된다. 누구든지 어느 영역이든 자신이 하고자 하는 데로 할 수 있기 때문에, 주변 사람들을 꼬시고 몰래 음모를 꾸미는 일을 하게 된다. 누군가 이에 대해 지적해봐야 자신들은 정치를 의도한 것이 아니라고 둘러대지만, 정치를 의도하고 하는 사람이 어디있겠는가. 뭐 좋은 단어라고…

셋째로, 별로 중요하지도 않은 주제로 오랜 시간 씨름을 하게 된다. 사람의 취향이란 것이 영원히 안맞는 경우가 매우 많고, 우리가 결정을 내리는 대부분은 객관적인 것이 아닌 상당수가 주관적 취향이 반영된 결과이다. 대화로 해결되지 않는 영역이 존재한다는 말이다. 각자의 영역의 책임 한계가 없다면, 종종 누군가는 모든 분야에 자신의 취향을 관철시키려 노력한다. 하지만 모두가 맞는 취향이란게 어떻게 존재한단 말인가. 결국 쓸데없는 이슈거리를 늘려 프로젝트를 산으로 가게 하는 주범이 된다.

물론 각자의 영역이라는게 모호한 부분이 있고, 그런 이유로 비교적 확실하게 정함에도 많은 부분에서 위와같은 일이 전혀 안일어난다고 장담할 수는 없다. 하지만, 적어도 정상적인 속도로 일을 진행하게 하는 데는 많은 도움이 된다.