아침놀 Blog

이 블로그에도 굉~장히 많이 늦었지만 subversion 소스 트리를 사용하기로 하였다. 지뢰밭이나 다름없는 trunk는 이미 별도 테스트용으로 블로그를 만들어놓고 있으니, 이곳은 정식 배포를 위한 버전들을 관리하는 branches의 최신 버전용 소스 트리를 이용하기로 하였다. 즉, 앞으로 정식 배포를 위해 대기 중인 버전에서 문제가 발견되었을 때 이 블로그에서 재현된다면 여기서 바로 고쳐서 반영할 수 있게 되었다는 이야기고, 또한 새로운 버전으로 보다 쉽게 갈아탈 수 있게 된 것이기도 하다.

요즘 텍스트큐브 API 서비스--원하는 사람은 있지만 수요가 적어서 기업들이 하지 않는 그런 종류 + 공공성을 지닌 것들을 모아서, 각 블로그에 부하를 주기에 부담스러울 때 텍스트큐브 플러그인 형태로 중앙 서버에서 받아오는 서비스--를 개발하기 위해 CakePHP를 써보면서, 텍스트큐브 2.0 프레임웍은 절대 이런 느낌이 나지 않게(!) 해야 겠다는 생각을 하고 있다. -_-;

그 유명한 Ruby on Rails는 사실 설치조차 해본 적이 없고(ruby 언어만 조금 깨작거려봤다), Django가 나한테는 처음으로 제대로 써본 웹프레임웍이다. 0.96과 1.0 사이의 긴 기간 동안 개발 버전을 쓰면서 문서화가 덜 되어 있는 관계로 직접 소스코드를 뜯어보기도 하는 등의 불편함이 조금 있었지만, Python 언어 자체가 워낙 깔끔하고 특히 코딩스타일이 거의 똑같이 나올 수밖에 없게 되어 있어 프레임웍 소스를 이해하는 데 시간이 얼마 걸리지 않았다. 또한 프레임웍은 거의 라이브러리 같은 느낌으로 내가 필요하면 불러다(from django.x import y) 쓰면 되는 것이고, 프레임웍의 틀에 맞춰서 짜야 하는 부분은 url routing하는 것, db 연결을 위한 환경설정, view handler¹ 함수가 존재하게 하는 것뿐이었다.

그런데 CakePHP를 써보니, 일단 view 템플릿이 있어야만 controller가 동작했고 이 템플릿은 HTML을 기본 가정으로 깔고 있어서 디버그용 모드에서는 자동으로 request 수행 시간을 나타내는 HTML 주석이 붙는다. 문제는 동적으로 생성할 json 응답과 같은 곳에서도 붙기 때문에 이때는 강제로 디버그 모드를 꺼줘야 한다든지 하는 것이 일단 가장 처음에 했던 삽질이고, 하나의 컨트롤러 메소드에서 여러 형식(XML, JSON 등등)으로 출력을 낼 수 있게 하려고 각각마다 템플릿 파일명을 다르게 하려고 했더니, 기본 템플릿 파일이 없다면서 404 Not Found 에러가 뜬다든지 하는 것 또한 골때렸다.;; 게다가 DB 스키마도 직접 생성해주어야 했다. (뭐 경우에 따라 이건 장점일수도.)

사실 이런 기본 동작들을 재정의하거나 별도의 옵션 변수를 두거나 뭐 이런 식으로 해결할 수는 있긴 한데(혹자는 이걸 장점으로 표현하기도-_-), 문제는 Python에서, Django에서 할 수 있는 것보다 훨씬 귀찮고 더럽게 보인다는 점이다.

Model을 사용하는 것도 object와 record가 거의 1:1 매핑이 되는 Django와 달리 현재 컨트롤러의 인스턴스에 들어있는 모델 인스턴스 변수를 통해서 stateful하게 조작해야 하다보니 코드가 별로 깔끔하지 않았다. Django는 계속해서 model 부분은 재작성·리팩토링해왔기 때문에 지금은 상당히 복잡한 쿼리도 잘 추상화가 이루어져있기 때문에 대조적인 부분이라 할 수 있겠다.

CakePHP가 Django와 비교했을 때 가지는 장점이라면, 프레임웍을 다운받아서 압축 푼 디렉토리 자체에서 어플리케이션을 개발하고 이걸 다시 묶으면 그대로 배포 가능한 패키지가 된다는 것 정도인데, 이건 사실 프레임웍의 설계가 뛰어나서라기보다는 php 자체의 특성에 기인한 바가 크다. Python은 lib/site-packages라는 별도의 시스템 디렉토리에 각종 라이브러리와 모듈들을 넣고 이를 불러다 쓰는 방식이라면, php는 php 자체가 그냥 모든 기능을 함수로 다 가지고 있기 때문이다. 따라서 사실 배포용 프로그램을 만들 때 python이 좀더 고려해야 할 것이 많고, django의 경우도 웹호스팅에서 사용하려면 django가 사용하는 패키지들이 설치된 서버에서 fast-cgi로 돌리는 방법밖에 없다. 대신 Java와 같은 패키지 import 지시어가 있으므로 php처럼 autoload 함수를 작성하거나 일일이 include하지 않아도 되는 편리함이 있다.

사실, 현재 베타 단계인 PHP 5.3만 좀더 일찍 출시·대중화되었더라도 이런 불만의 많은 부분을 잠재울 수 있었을 것이다. namespace 지원, lambda 지원, static 메소드의 동적 바인딩 지원 등 이미 다른 OOP 언어에서는 기본적으로 지원되는 것들이 이제서야 도입되고 있기 때문이다. (하지만 수천개에 이르는 단일 네임스페이스 안의 기존 라이브러리 함수들은 어쩔;;...orz)

하여간 이래저래 웹프로그램을 가장 배포하기 편한 환경이 PHP이면서 제대로 된 규모있는 개발을 하기엔 가장 안 좋은 환경이 PHP이다보니 성가신 점이 많다. ㅠ_ㅠ

어제는 웹앱스콘에 다녀왔다. 대전에서 올라가는 것은 아니었지만 용인 수지 쪽에서 서울 올라가는 출퇴근길은 교통 정체가 항상 심하기 때문에 행사 시작 2시간 전에 출발하였는데 20분 정도 일찍 도착했다. 행사장 무선랜은 아주 잘 잡혔고 미투데이로 졸음을 달래며(...) 백엔드 세션을 들었다. 작년에는 무엇 때문이었는지 기억나진 않지만 아무튼 안 갔었고, 이번에는 휴학 중인 관계로 중간고사 기간인 다른 카이스트 학생들을 대신(?)하여 참석할 수 있었다;;

백엔드 세션에서 첫번째 순서는 니들웍스에서 활동하고 계시는--그러니까 너무 잘 아는(?)--최호진님의 PHP MVC 프레임워크인 CakePHP에 대한 소개였다. MVC 자체에 대한 개념은 이미 Django를 가지고 많이 써봐서 잘 알고 있었지만 PHP에서는 그것을 어떤 식으로 구현할 수 있을지, 텍스트큐브 2.0 프레임웍 때문에 많이 고민하고 있던 터라 아이디어의 단초를 얻는 데 꽤 도움이 되었다. (사실 CakePHP의 소스 구현은 대충 들여다봤었어도 그걸 사용하는 입장에서 어떤 모양의 코드가 나오는지는 거의 본 적이 없었기 때문이다.)

클라우드 컴퓨팅 세션을 진행하신 한재선님도 NexR 창업 무렵부터 이미 알고 있었던 사이라서 오랜만에 만나 반갑게 인사했다. (스팍스와 미니프로젝트를 잠깐 같이한 적이 있는데 그때 알게 되었다.) 아마존의 EC2나 구글앱스엔진이나 뭐 이미 다 들어본 것이긴 하지만 live demo로 직접 보여주니 한층 더 가깝게 느껴졌다. 한 가지, EC2에서 CentoOS였나 Fedora Core였나 둘 중 하나를 올렸던 것 같은데 Debian 계열도 지원하는지 궁금하다. 미리 세팅된 리눅스 이미지를 만들어서 등록해두면 서비스 요구량에 따라 동적으로 서버 인스턴스를 생성한다는 점과 사용한 만큼 요금을 낸다는 방식이 인상적이었다.

집단지성 프로그래밍의 경우 이미 그 책을 읽고 있었고, 동아리에서 개발 중인 검색엔진인 KSearch에 몇 가지 적용할 아이디어까지 있는 상태라서 생각보다 별로 흥미롭지는 않았다. 하지만 잘 모르는 사람들이나 서비스 기획자와 같은 분들한테는 나름 흥미있는 세미나였을 것 같다.

그러다가 간만에 일찍 일어난 탓에 너무 졸려서(...) 마침 도착하셨다는 inureyes님을 만나러 나왔다. 행사장 안팎에서 미투데이에서 미친으로 알고 있는 StudioEgo님, 하루하루님 등을 만날 수 있었고, 나중엔 대학 친구이자 병특 중인 재성이도 만날 수 있었다. 회사에서 다른 직원들과 함께 보내줬다고 하는데, 2년이나 일했다고 동갑내기인 이 친구가 벌써 대리 직함을 단 것이 재밌었다;; 발표 끝나고 나오신 호진님과 라이트닝토크에 참가하신 ETRI의 김승현님 등도 만났다. 어찌어찌 모여서 점심을 먹고 오랜만에 만난 니들웍스 분들과 이런저런 수다를 떠느라 막상 컨퍼런스는 별로 안 듣고 밖에서 돌아다니며 계속 놀았다;;

오페라 부스를 지키고 있던 분이 알고보니 태터툴즈 포럼 초창기 때 활동하셨던 JCrew님이라는 걸 알게 되어 반가웠다. 2년 동안 병역을 마치고 오페라 소프트웨어 한국지사에 입사하셨다고 한다. 건더기님이 떠나니 다시 돌아오는 분도 있는 것이 역시 만나고 헤어짐이란 계속 이어지는 것 같다. 오페라에서는 하나의 프로젝트 팀이라도 세계 각지에 흩어져있는 지사 직원들이 모이기도 한다면서 국제적인(?) 회사 생활을 한다고 하셨다. 옆에서 같이 부스를 지키고 있던 분은 무려 스웨덴(!) 분이었는데 러시아 여행 때 만난 한국인 누나가 교환학생 생활을 하던 린셰핑 지역에 80명 규모의 오페라 사무실이 있어 거기에 근무하고 있다고 했다. (스톡홀름에도 사무실이 있긴 한데 2명 뿐이라고...-_-)

조엘스폴스키의 강연을 중간부터 들었는데, 이건 뭐 '이런 건 아니다'라고 까고 '이런 식으로 해야 한다'라는 느낌?; 말이 좀 빠른 편이었지만 생각보다 영어가 잘 들려서 별다른 무리 없이 재밌게 들을 수 있었다. 적절하게 재미있게 긴장감있게 진행하는 걸 보니 꽤나 타고난 이야기꾼인 것 같다. 끝나고 사인회가 있었는데 미리부터 조엘을 추적(?)하여 따라간 덕분에 일찍 사인받고 사진도 찍을 수 있었다. 이제 이 책의 소장가치가 한층 높아지겠지;;

여기저기 돌아다니면서 오랜만에 꼬날님도 만났고(꼬날님표 그 해맑고 큼직한 웃음은 여전하시다) 저번에 온라인 상으로 약속한 대로 enswer 명함도 받았다. 그 외에 태터워크샵에 참가하기도 했었던 미니보드 개발자님도 만나고, 얼마 전 IIS7 RewriteModule 테스트 과정 중 웹검색을 통해 홈페이지를 방문해서 질문한 것으로 알게 된 마이크로소프트의 김대우님과도 반갑게 인사를 나누었다.

론치패드 때는 다 보진 못하고 vlaah의 발표만 유심히 보았는데, 플래시 애니메이션으로 만든 감각적인 슬라이드와 발표자로 나오신 shinvee님의 vlaah 색깔 머리 염색이 인상적이었다. 하지만 빡빡한 시간 제약 때문에 너무 긴장하신 탓인지 조금 버벅거리시는 것 같은 느낌도 있었다.;; 이걸 보면서 재성이와 vlaah 서비스 자체에서 노는 것보다 Open API를 통해 외부 서비스와 연동한 취양 정보 수집·가공의 형태로 진화시키면 비즈니스 모델도 만들고 괜찮지 않을까 싶다는 얘기를 했다. 문자로 연락은 주고받았지만 아쉽게 홍민희님과는 엇갈려서 만나보지 못했다; (언제 한 번 강남에서 밥이나 한끼? -_-)

그리고 이어진 라이트닝토크에서 가장 인상적이었던 건 오픈웹 소송을 진행 중이신 김기창 교수님. 생각했던 것보다(?) 젊어 보이시는 분이었다. 오픈웹 소송 자체보다도, hwp 포맷을 폐쇄적으로 비공개하고 시장 독점적 지위를 가지고 있는 한소프트에 대한 소송을 차후 준비할 것이라는 얘기가 사람들 사이에서 반향을 불러일으켰다. 사실 나도 이에 대해 안 좋은 기억이 있는데, 과학고 시절 기숙사관리프로그램(-_-)을 만들면서 hwp 포맷을 XML 형태로 만든 것인 hml이라는 포맷을 이용했었다. 그런데 당시 쓰이던 한글2002와 한글2002SE의 hml 포맷이 상호 호환이 안 되어 두 버전에 대한 코드를 중복 작성해야 했던 것이다. (심지어 한글2002SE에서 저장한 hml 파일을 한글2002에서 열면 아예 프로그램이 죽었다. orz) 포맷에 대한 정보가 없었기 때문에 직접 xml을 뜯어보면서 대충 치환하는 식으로 프로그램을 짤 수밖에 없었다. 하지만 이미 마이크로소프트조차 docx뿐만 아니라 doc 포맷까지 스펙 문서를 공개한 것을 보면 이미 워드프로세서는 포맷에 대한 독점권이 아닌 워드프로세서의 기능에 따른 차별화가 곧 전략이 되고 있음을 알 수 있다. 아무튼 이런 독점을 깨기 위한 소송을 준비하겠다는 일종의 선전 포고와도 같은 것이었다.

오픈소셜이나 오픈ID, 매시업, 제로보드, 웹표준 커뮤니티에 대한 이야기들은 이미 익히(..) 잘 알고 있는 것들이라 복습과 정리하는 정도였을 뿐 뭔가 크게 새로 깨달았다든지 배운 것은 없는 것 같다. 다만 Hadoop에 대한 내용은 얼핏 수박 겉핥기식으로만 들어봤던 것이라 앞으로 이쪽을 필요로 하게 되어 접근한다면 어떻게 시작해야 할지 감을 잡을 수 있게 해주었다. 여자개발자모임은 혹시나 했더니 역시나 김창준님의 강력한 지지가 있었던 모양인데, 이건 다음 달 말에 있을 P-CAMP와 대안언어축제 때 보다 자세히(?) 알 수 있을 것 같다. =3

아무튼 이번 컨퍼런스에서 백엔드 쪽의 주요 이슈는 역시 분산처리라고 할 수 있겠다. 프레임웍 도입은 이미 충분히 주류에 편입되었다고 볼 수 있겠고, 대량의 사용자 데이터로부터 유의미한 가치있는 정보를 뽑아내기 위한 방법들이 점점 낮은 비용으로, 오픈소스로 사용할 수 있게 됨으로써 생길 수 있는 다양한 기회와 가능성, 그리고 what/how to do들에 대한 이야기들이었다. 하지만 아직도 한국에서는 open 자체에 대한 이슈가 여러 곳에서 조금씩 발목을 잡고 있음과 동시에 그래도 점점 나아지고 있다는 것도 느낄 수 있었다. 앞으로도 이 컨퍼런스가 잘 이어져서 웹의 발전이라는 두루뭉실하고 거창한 목표에 한 보탬이 되길 바란다. :)

왜 무조건 영어로 먼저 입력하게 하는가.에 대한 반론글.

IME¹는 기본적으로 운영체제에 종속된 기술이고 그 상태 전환은 온전히 사용자에게 달려있다. 비밀번호 입력란이나 단축키를 사용하는 게임을 즐길 때와 같이 특수한 상황에서는 보통 해당 소프트웨어나 운영체제 스스로 IME를 꺼서 무조건 ASCII 영문으로만 입력하게 하는 경우가 있긴 하지만, 그런 경우 아예 애초부터 한글 등의 비ASCII 문자가 입력될 필요가 없고 입력되었을 때 사후 처리가 곤란해질 수 있는 경우(특히 비밀번호)이기 때문이다. 하지만 검색어, 이름, 댓글 입력란처럼 한글과 영문이 모두 사용될 수 있는 곳은 사용자가 선택한 IME 상태를 그대로 존중해주는 것이 원칙이다.

또한 IME 환경은 한중일과 같이 복잡한 입력기가 필요한 동아시아 문화권뿐만 아니라 유럽권에서도 자체 키보드 배열을 사용하고 있기 때문에 PC의 de facto standard인 미국식 영문 자판과 유럽식 키배열을 함께 사용하고 있는 경우가 있을 수 있고, 베트남과 같이 윈도우가 제공하는 입력기가 아닌 자체적으로 개발한 입력기 프로그램을 붙여 쓰는 경우도 있는 등 각 사용자마다 그 환경이 매우 큰 차이를 보인다.

분명한 건, 일반적으로 웹페이지에서는 비밀번호 입력이 아니라면 IME 상태를 변경하지 말아야 한다. 일반적인 GUI 환경의 프로그램들은 이러한 텍스트 입력란에서 사용자의 명시적 행동 없이 IME 상태 변경을 하지 않고 있는데, 웹브라우저의 Form 요소를 사용할 때도 당연히 이러한 전제를 무의식적으로 깔고 사용하게 마련이다. 이럴 때 자기가 예상하지 못했던 결과가 나타나면 사용자 입장에서는 불쾌함을 느낄 수 있다.

물론 한글 사용을 장려하자는 기본적인 취지는 좋지만(필자도 세벌식을 쓰는 등 나름대로 컴퓨터 환경에서 어떻게 하면 더 한글을 '잘' 쓸 수 있을지 많은 생각을 해왔고, 한글 입력을 지원하지 않는 게임인 Supreme Commander에서 멀티플레이 중 한글 채팅을 가능하게 하기 위해 한글입력기 플러그인을 만들고, PuTTY의 개선 버전인 dPuTTY를 통해 한글 IME 관련 동작을 개선하는 등의 노력을 한 바 있다.), 보다 큰 시야에서 기술을 바라보는 관점이 아쉽다. 생명복제 기술이 있다고 해서 그것을 남용하면 안 되듯이, 일부 운영체제·웹브라우저 환경에서 IME 상태 변경을 지원한다고 해서 그것을 필요 이상으로 남용해서는 안 되는 것이다.

얼마 전, 모 서비스 가입을 할 때도 비슷한 것을 느꼈었다. 휴대전화 번호를 입력하기 위해 3칸으로 나누어진 텍스트 입력상자들이 있었는데, 내 휴대전화 번호가 xxx-yyyy-zzzz와 같이 3-4-4자리였고 나는 당연히 xxx 입력 -> 탭 -> yyyy 입력 -> 탭 -> zzzz 입력 이런 식으로 하려고 했다. 우선 첫 번째 문제는 xxx를 입력하면 자동으로 다음 입력칸으로 넘어가는 스크립트가 들어있어 yyyy를 zzzz 입력해야 할 칸에 입력하게 되었다는 것이 문제였고, 그 다음은 두 번째 칸에 yyyy를 입력하는데 3글자를 넣으니 자동으로 다음 칸으로 넘어가버려서 매우 당황했었다는 것이다. 알고보니 yyyyzzzz 순서대로 다 치고 나면 yyy-yzzzz로 입력되었다가 스크립트가 알아서 두번째 칸에 4자리를 넣어주는 방식이었는데 매우 불쾌한 경험이었다.

나를 기분나쁘게 한 사실은 다음 입력칸으로 이동하는 데 사용하는 탭키의 사용을 내 동의 없이 마음대로 가로챘다는 것과, 어차피 서버에서 받을 때 validation해야 하는 부분을 굳이 웹페이지 자체에서 올바른 형태로 보여지게 만들려고 사용자의 예상을 깨는 동작을 보여주고 있다는 것이다.

분명히 그 가입 페이지를 만든 사람은 사용자들이 탭을 누를 필요가 없고 자동으로 양식을 맞춰주니까 더 좋아할 것이라고 생각했겠지만 실제로는 그렇지 않다는 것. 물론 일부 사용자들은 이런 자동화된 방식을 더 좋아할 수도 있겠지만, 기본적으로 User Interface 설계는 사용자의 예상을 최대한 깨지 않는 방향이 올바른 접근이다. 또한 모든, 혹은 거의 대부분의 웹사이트나 프로그램에서 휴대전화 번호를 입력할 때 위와 동일한 동작을 보인다면 모르겠지만 일반적으로 사용자의 선택에 두는 경우가 많고(특히 해외사이트들은 거의 다 그렇다), 이런 상황을 인지하고 있는 사용자에게는 일관성을 깨뜨리는 것이 된다.

같은 관점에서, 한글 입력을 장려한답시고 웹페이지의 IME 상태를 강제로 바꾸는 일은 사용자가 원래 사용하던 패턴을 깨는 매우 나쁜 UI 설계이다. 게다가 이 방식은 모든 운영체제와 웹브라우저에서 동작하는 것도 아니어서 일관성 원칙 또한 깨뜨린다. 기술에 대한 잘못된 이해와 오용이 불러올 수 있는 하나의 대표적인 사례로 남지 않을까 싶다.

ps. 원글에 달린 반응들 중에 한글 상태일 때와 영문 상태일 때 커서 모양을 다르게 하면 좋지 않을까 하는 의견들이 보인다. 사실 90년대 후반 잠시 반짝했던 워드프로세서 중 삼성에서 만든 훈민정음에서 해당 기능을 지원했었다. 한글 상태면 커서가 검정색이었고, 영문 상태면 빨간색으로 나와서 한영 상태를 바로 알 수 있게 해준 것이다. 이 아이디어가 윈도우 자체나 다른 소프트웨어에서 널리 받아들여지지 않은 것이 매우 아쉽다. (혹시 특허가 걸려 있었을까?)

ps2. 찾아보니 아주 언론 기사까지 떴다. 잘들 놀고 있네 -_-

드디어 Daybreakin 서버의 업그레이드 작업이 거의 완료되었다. 아직 완벽하게 복구가 끝난 것은 아니지만 이곳에서 호스팅하는 주요 웹사이트들은 모두 정상 작동하는 것 같(?)다. 이번 업그레이드를 통해 메모리가 1GB에서 3GB로 늘어났고, 320GB짜리 하드디스크가 추가 장착되었다.

원래 이 업그레이드를 하게 된 가장 큰 이유는 Ubuntu 6.06을 최초로 설치했던 것을 6.10, 7.04, 7.10으로 계속 업그레이드해오다가 8.04로 넘어가려니까 /boot 파티션 용량이 모자라서(...) 업그레이드에 실패했고, parted 프로그램을 이용해 파티셔닝을 다시 할까 하다가 파티션 구조가 좀 답답하게 잡혀 있어서 그냥 확 엎어버리기로 했던 것. 그리고 Ubuntu보다는 Debian이 서버용으로는 아무래도 더 나은 것 같아(뭐라고 객관적인 근거를 대기는 좀 그렇고 데비안이 워낙 안정적이라고 하다보니..) 이쪽으로 새로 설치해버렸다.

Debian의 경우 현재 4.0r4까지 stable release가 나와 있지만 패키지 버전들이 좀 낮다는 게 단점이었다. 하지만 주변을 수소문해보니 lenny testing 버전도 안정적이고 쓸 만하다고 해서 그쪽 패키지 버전들을 알아봤는데 Python 2.5 + Trac 0.11.1 + Django 1.0 + PHP 5.2.6 등 각종 최신 패키지들을 모두 가지고 있었다. (특히 Trac은 업데이트 빠르다는 Ubuntu의 8.04 릴리즈에서도 0.11까지는 올라가지 않았을 정도.) 그래서 이걸로 콜~

하드웨어 업그레이드만 하면 부품을 그냥 호스팅회사로 택배부쳐버리면 되지만 OS 재설치 작업 및 특히 백업데이터를 새 하드에 옮겼다가 다시 가져오고 파티셔닝하는 것을 작업의뢰서로 남겨주기보다는 직접 하는 게 낫겠다 싶어서(또 간단한 상태 확인이나 리부팅이 아닌 OS 재설치 정도를 요청하면 유료 서비스가 된다는 점도 있고) 처음으로(!) IDC에 가봤다.;;;

내 서버는 분당 KT IDC에 있는데, 야탑역 4번 출구로 나와 왼쪽으로 꺾어 주욱 직진하면 코리아 디자인 센터 바로 앞에 생각보다(?) 작고 뚱뚱한 건물이 하나 있는데 그것이 바로 IDC다. 들어가면 방문자 등록을 하고 방문 회사의 부서와 담당자 이름까지 적어야 한다. 그러고나면 신분증을 맡기고 방문카드를 받게 되는데 이게 없으면 나오지도 못하게 되어있다; 카드 찍고 들어가면 첫 방문인 경우 지문 등록을 하고, 지문 인식기를 통과하면 엘레베이터를 탈 수 있는데 이것 또한 방문 카드가 있어야만 작동 가능하다. 엘레베이터에서 내려서 조금 걸어가면 바로 영화에서나 보던 그런 서버 랙들이 잔뜩 있는 방이 나오는데 여기 들어갈 때도 역시 방문카드와 방문카드에 적힌 별도 비밀번호가 있어야 한다. (실제로는 영화에서보다 더 좁고 더 많고 더 덥고 더 시끄럽다. -_-)

호스팅 회사라서 더 그런지는 모르겠지만 생각보다 좁은 공간 안에 최대한 많은 서버들을 우겨넣느라(...) 통로는 사람 하나가 딱 지나갈 수 있을 정도였다. 아무튼 수많은 서버들로 둘러쌓인--아마 반경 4~5m 이내에 서버 100개는 족히 될 듯--작은 공간이 하나 있고 여기에 콘솔과 인터넷 연결 가능한 PC 몇 대, 하드웨어 점검·교체 작업 등을 위한 작업대가 놓여져 있다. 아무튼 인솔해준 담당 엔지니어 분이랑 서버를 꺼내러 갔는데 하여간 정말 서버가 많았다;;; 중간중간 에어컨 시설이 되어 있는지 시원한 바람이 느껴지는 곳도 있었지만 워낙 많은 컴퓨터가 있었기 때문에 긴팔 입고 있기에는 살짝 더운 정도. 내가 쓰는 호스팅회사의 경우 렌탈서버 상품을 신청하면 직접 조립해서 2U짜리 서버를 만들어주는데 오히려 얘네들은 비교적 조용했지만 유명 업체들에서 만든 것으로 보이는 1U짜리 서버들은 정말 시끄러웠다. 애초부터 가정용이 아니라 IDC용이라 그런지 소음 따위는 전혀 신경쓰지 않고 만든 것 같다. 작업대 뒤쪽에 있는 랙 윗부분에 그런 서버들이 몇 개 있었는데 그 소음 때문에 평상시 목소리로는 대화가 힘들 정도였으니 뭐.;;

드디어 2년여 동안 고이 박혀있던(...) 날뷁서버(...)의 본 모습을 볼 수 있었다. 자체 제작한 것으로 보이는 2U짜리 케이스에 데스크탑용 메인보드를 이용해 만든 것인데 공간 활용을 잘 해서 그리 크지는 않았다. 2U으로 만들 수밖에 없었던 가장 큰 이유는 아마 메인보드 구조와 CPU 쿨러 때문이 아닐까 싶다. (사실 스팍스 동방에서도 2U 이상 서버들을 주로 써왔는데 1U짜리는 도대체 어떻게 쿨러를 다는지 궁금하다-_-) 조립 서버라고 하면 왠지 신뢰성이 떨어질 것 같지만 상당히 많은 서버가 이렇게 운영되고 있었고 내 서버 또한 하드웨어적인 문제가 발생했던 적은 한 번도 없으니 조합을 잘 맞춘 듯하다. (호스팅회사에서 상품 출시 전에 그 하드웨어 조합으로 엄청난 부하 테스트를 거친다고 한다. 예를 들면 1주일 내내 풀로드 가동시키기 등.)

아무튼 RAM과 하드디스크 장착은 금방 끝났고, 부팅해서 적당히 마운트해준 다음(집에서 미리 ext3로 파티션 나눠서 포맷해갔기 때문에 쉬웠다) 백업 데이터들을 옮겼다. 역시 네트워크로 옮기는 것보다 내부 하드로 복사하는 게 훨씬 빠르다;; 10분만에 백업 끝내고 드디어 데비안 설치. 설치야 뭐 이미 여러 번 해봤으니 자세한 내용은 생략. 파티셔닝은 앞으로 업그레이드할 때 용량 걱정할 일 없도록 간단하게 나눠주었다. 이때 옆에 있던 컴퓨터로 집 컴퓨터에 원격접속해서 미투데이에 글 하나 남겨주고; (담당 엔지니어가 항상 옆에 있는 건 아니고 서버 꺼내는 등의 작업만 도와주고 나머지는 내가 거기서 알아서 하면 된다. 사실 이럴 때 IDC 테러하면 어떻게 될까 하는 상상도.. 뒤에 있는 랙 몇 개 랜선만 주르륵 뽑아도 아마 난리날 거다. ㅋㅋ 물론 감시카메라 같은 거 다 있겠지만.)

작업 다 끝났다고 생각하고 담당 엔지니어 분을 불렀는데 가만보니 sshd가 안 깔려있어서 네트워크 설정 바꿔서 깔아주느라 삽질. (공인IP는 그 랙에서만 쓸 수 있고 작업대에서는 별도 사설IP를 쓴다.) 우분투에서는 /etc/init.d/networking restart로 되는데 여기선 ifdown, ifup으로 해줘야 했다. 어쨌든 이렇게 해서 다시 랙에 장착한 후 PuTTY로 접속 확인한 다음 집으로 돌아왔다. (dPuTTY를 소개해주고 싶었지만 그게 이 서버에 있었던 관계로...-_-)

생전 처음 해보는 IDC 구경(...)이라 긴장도 되고 정말 말로만 듣던 게 실제로 보니 이렇구나 하는 감탄도 했지만 정말 거기서 매일 들락날락하는 직원분들은 꽤나 괴로울 것 같다. 냉방이 잘 되어 있어서 열기는 큰 문제가 안 되나 그 엄청난 컴퓨터들이 뿜어내는 팬 공기와 소음은 정말 거기에 몇 시간만 있다가는 노이로제에 걸리게 할 정도다. 집에 돌아와서도 한동안 한 것도 없는데 괜히 피곤한 것 같고 머리가 아플 정도였으니... 그래도 담당자 분이 굉장히 친절하게 잘 해주셔서 별다른 문제 없이 작업을 끝낼 수 있었다. (중간에 어디서 오셨냐고 물어보길래 그냥 학생이라고 했더니 어디 과냐고 해서 카이스트라고 하자 명함 교환을 하자셨었다.;; 서버 조립을 취미삼아 하다가 IDC에서 일하게 되셨단다.)

조만간 CPU도 듀얼코어급으로 업그레이드할 생각인데 그러면 좀더 쓸만한 서버가 될 것 같다. 최근 들어 Apache의 CPU 사용량이 많이 늘어나 작업 중 버벅이는 경우가 종종 있었는데 그런 것도 줄어들 수 있을 듯. 서버야, 달려라;;

daybreaker.info가 운영되고 있는 제 개인 서버의 하드웨어 업그레이드 및 OS 재설치 작업으로 인해 오늘 혹은 내일 중으로 몇 시간 정도 접속이 안 될 수 있습니다. 이런 작업을 처음 해보는 거라서 정확히 얼마가 걸린다고 얘기해드리지는 못하겠군요.;; 최대한 빨리 끝낼 수 있도록 하겠습니다.

※ 아래 영문으로 먼저 작성한 글의 한글 버전입니다.

이번 구글코리아의 태터앤컴퍼니 인수건과 관련, 오해하기 쉬운 몇 가지 사실들을 정리하고자 합니다.

우선 텍스트큐브¹는 오픈소스 블로깅 도구로서 TNF²와 그 핵심 조직인 Needlworks³가 개발하였고, TNC가 스폰싱을 해오고 있습니다. TNC 구성원들 중에도 물론 이 오픈소스 프로젝트에 기여하신 분들이 있습니다.

이번 인수에 텍스트큐브 및 그 개발자 그룹인 TNF/Needlworks는 포함되지 않고, TNC가 텍스트큐브를 바탕으로 개발한 서비스형 블로그인 텍스트큐브닷컴이 그 대상입니다. 따라서 이번 소식을 언급할 때 텍스트큐브 뒤에 '닷컴'을 표기하는 것은 이 두 프로젝트를 구분하는 데 아주 중요한 요소입니다. 혼란을 피하기 위해 두 프로젝트를 모두 언급해야 할 경우 오픈소스 프로젝트 텍스트큐브 뒤에 '.org'를 붙이는 것도 좋겠습니다.

텍스트큐브는 원래 태터툴즈로 알려져 있었고, 정재훈님이 최초로 개발하셨지만 당시에는 오픈소스가 아니었습니다. 노정석님이 TNC를 설립하고 태터툴즈 1.0을 발표하시면서 오픈소스화되었고, 저는 그때부터 참여하기 시작했지요. TNC는 태터툴즈와 그 후신인 텍스트큐브를 이용해 티스토리와 텍스트큐브닷컴을 개발하여 각각 다음과 구글에 피인수되었습니다. 이번에는 회사 전체와 이올린 등 모든 서비스가 함께 인수되었습니다.

태터툴즈는 현재 '프로젝트 태터툴즈'를 뜻하고, 태터툴즈라는 블로그 소프트웨어는 텍스트큐브로 이름이 바뀌었습니다. 프로젝트 태터툴즈는 TTXML⁴을 통한 데이터 호환성을 갖춘 소프트웨어들의 집합을 의미하는데, 지금 현재에는 태터툴즈·텍스트큐브로부터 파생된 프로그램들 외에는 지원하는 프로그램들이 없습니다. 물론 나중엔 그렇게 되길 바라고 있지만요.

한편 TNC는 워드프레스의 아키스멧에 비견할 수 있는 안티스팸 API인 이올린 안티스팸 서비스를 텍스트큐브 플러그인 형태로 제공해오고 있습니다.

니들웍스와 저는 TNC와 긴밀한 관계를 가지고 있지만 인수 협상의 내용은 보안 문제로 저한테도 알려지지 않아서 저도 거의 모릅니다. 앞으로 TTXML/TTSKIN 등의 규격 표준화 작업이나 프리미엄 스폰서가 구글로 바뀌는 등의 변화는 있을 수 있겠지만, TNF/Needlworks는 비영리단체로, 텍스트큐브는 오픈소스 프로젝트로 계속 남아있을 것입니다. 설치형 사용자 분들은 걱정하지 않으셔도 됩니다. :)

추가: 티스토리의 경우 현재 다음에서 완전히 인수하여 운영하는 서비스로, 프로젝트 태터툴즈의 일원으로서 표준화 논의 등에는 참여할 수 있지만 이번 인수와는 전혀 관련이 없습니다.

고등학교 때 정말 수박 겉핥기 수준으로 C++을 다뤄보긴 했지만, 그동안 학교 수업들 및 개인 프로젝트 등을 진행하며 본격적으로 쓸 일이 없었기에 따로 공부하지도 않았던 C++에 대해 살펴보고 있다.

미투데이에서도 언급했었지만, 어쨌든 OOP 언어로서 지대한 위치를 가지고 있는 C++을 공부해보니 Java를 통해 OOP 언어들을 접한 나로서는 너무나 당연한 것이 당연한 것이 아닌 게 꽤나 많았다.

아직 그 깊고 깊은 템플릿의 세계까지는 가지 않았지만, 몇 가지 특이할 만한 것으로는 다음과 같은 것들을 들 수 있겠다.

• virtual로 선언하지 않은 메소드들은 파생클래스 객체라고 해도 부모클래스 타입으로 접근하면 부모클래스의 것으로만 접근이 된다. 즉, 파생클래스가 완전하게 override할 수 있기를 원한다면(Java는 이게 기본이다) virtual 한정자를 선언해줘야 한다. 다시 말해, virtual을 사용하지 않았다면, 인스턴스가 실제로 어떤 클래스인지 관계 없이 현재 사용하는 타입의 정보만 사용해서 접근한다는 뜻이 된다.
  사실 옛날에 프로그래밍 언어 수업을 들을 때 vtable이라는 개념을 배우면서 대충 알고 있긴 했지만 언어 사용자의 입장에서 보니까 또 느�