깜빡하고 적지 않았었는데, 고등학교 동기 친구 아버지가 돌아가셨던 일도 사실은 2008년을 돌아볼 때 사람의 재인식에 함께 영향을 준 사건이다.

그런데 지난 토요일 또다른 죽음이 찾아왔다. 우리 어머니께서 지금 사는 아파트에 이사온 후로 근 2년 이상 아주 가까이 지내오시던 같은 라인에 사시는 분이 결국 암으로 세상을 떠나신 것이다. 횡경막 암으로 시작하여 항암치료만 6~7회 이상 이어지고 잠시 괜찮아졌을 때는 어머니와 함께 동네 뒷산에 함께 오르기도 하셨었다. 나이는 50대 중반이니 아직 한창 사실 나이고, 공무원이신 남편분과 아들 2명(나한테는 형들)이 있는데 두 형 모두 아직 결혼은 못한 상태였다.

같은 라인에 살면서 자주 만났기 때문에 그집 가족들하고 우리집 가족들하고도 잘 알고 있는 사이다. 이사올 당시 예비신자셨던 그분을 어머니께서 자주 왕래하시며 독실한 신자로 이끌어주기도 했고, 말기 암환자의 고통을 함께 나누기도 했는데 나 또한 요 근래 계속 집에서 지냈으므로 이런 전후 사정을 잘 알고 있었다.

며칠 전에 『뇌, 생각의 출현』이란 책을 다 읽었다. 우주의 탄생과 원자, 분자를 거쳐 DNA가 만들어지고 세포를 이루며 이것이 점점 진화해나가면서 어떻게 뇌가 변화되었는지에 따라 우리가 말하는 의식의 정체가 무엇인지 쓴 과학교양서적이자 기나긴 에세이라고 요약할 수 있을 것이다. 예전에도 해봤던 질문이지만 우리의 의식, 혹은 자아 인식, 더 나아가 영혼이라고 불리는 그 무엇이 단순히 뇌의 특정한 활동 상태의 스냅샷에 지나지 않을 것인가 하는 골치아픈 이야기가 다시 떠오르기도 했다. 정신병자는 영혼이 고장난 것일까 뇌가 고장난 것일까 같은 문제와 마찬가지로. 얼마 전 본 영화 「지구가 멈추는 날」에서 클라투가 '인간이 죽으면 단지 다른 형태로 변화될 뿐'이라고 표현한 것도 떠오른다.

갑자기 연속으로 두 차례의 장례에 조문을 다녀오면서, 그전에는 막연히 '과학적 관점'에서 죽음이란 별다른 특별한 것이 아닐 수도 있다는 생각을 했던 것이 많이 바뀌었다. 어떤 사람이 죽었을 때, 단지 그 사람의 육체가 지구의 거대한 순환 시스템을 구성하는 원소로 분해되는 이상의 것이 있다는 사실 말이다. 영혼이 존재하든 존재하지 않든, 돌아가신 분의 영혼이 천국에 가시든 윤회로 다른 곳에 태어나시든 간에, 어쨌든 지금 현실에 살아있는 우리들과 더이상 만날 수 없고 의사소통할 수 없다는 것은 분명히 사람에게 있어 안타까운 일이라는 것이다.

그리고 무엇보다 영정사진을 보며 언젠가 나도 우리 부모님이 돌아가시면 저렇게 해야 할 텐데라는—인간이 가진 강력한 능력 중 하나인 감정 이입 덕분에—슬퍼하지 않을 수 없었다. 이쯤 가면 더이상 죽음에 대해 과학과 논리로만 설명되지 않는 듯하다. 내가 근 몇 년 동안 흘려본 슬픔의 눈물보다 많은 양을 이날 흘렸던 것 같다.

조문과 연도를 마치고 그집 작은형과 인사하는데 갑자기 나를 와락 껴앉으며 흐느꼈다. 와줘서 정말 고맙다고.

이번 연말연시를 지나면서 그동안 막연하게 뉴스와 영화로만 접했던 죽음에 대해서 완전히 새롭게 느끼게 되었다. 여전히 과학적으로 죽음을 설명하는 논리에는 변함이 없겠지만, 그 이면에 남은 사람들이 느끼는 감정에 대해 눈을 떴다고나 할까. 집안에 다행히 돈이 좀 있었는지 남편분이 마지막까지 산삼주사까지 놓으며 가능한 모든 방법을 다 동원했지만 그래도 말기암과 죽음 앞에선 아무런 소용이 없었다.

세상사 덧없고 허무한 일이라는 것과 동시에, 유한하기 때문에 더욱 재미있게 살 수 있는 가치가 있는 것이 아닌가 하는 이중적인 생각이 들었다.

RSS를 둘러보다가 재미있는 책을 발견했다. (원래 이벤트 같은 거 당첨운이 없어서 잘 안 하는데 한번 해본다.)

Dreaming in Code

제목만 봐도 끌리지 않는가? 끌린다면 필시 개발자일 것이다. ㅋㅋ

학부 3학년 때 소프트웨어공학개론 수업을 들었다가 완전히 데여서 그 학기 다른 과목 학점 다 말아먹으면서까지 하루 10시간 조모임의 결과물로 나온 300페이지가 넘는 UML 다이어그램 종류별로 다 그렸던 엄청난 보고서 대신 시험 문제 한두 개 차이로 학점이 결정나버리는 뼈아픈 경험을 하고, 나름 성공적이라는 텍스트큐브 프로젝트에 직접 개발자로 참여하면서 여러 문제점을 인식하고 있지만 여러 원인으로 인해 해결할 마땅한 방법이 없는 상황에서, 과연 어떻게 하는 것이 더 나은 소프트웨어를 개발할 수 있는 일일까 하는 의문을 가지지 않을 수 없는 것이다.

책 소개에서도 언급한 것처럼 실력이 뛰어난 개발자만 있다고 '좋은' 소프트웨어가 나오지는 않는다. 사실 텍스트큐브도 이를 개발하는 니들웍스 멤버분들의 실력이나 열정은 누구에게도 뒤지지 않으나 오픈소스이기에 겪는 한계점이 있다. 지역적으로 멀리 떨어진 사람들이 온라인만으로 의사소통하면서 사용자의 입맛에 맞는 제품을 만들어낸다는 건 절대로 쉽지 않은 일이다.

그나마 비교적 사용자 친화적이라고 볼 수 있는 대표적 오픈소스 프로젝트인 Ubuntu나 Firefox는 재단이나 회사 형태로 풀타임으로 각 분야 전문가들을 고용하고 있기에 가능한 것 같다. 제로보드XE도 최근의 공지글을 보면 NHN 오픈UI 기술팀의 협조로 UI와 디자인 개선이 계속해서 이루어지고 있음을 볼 수 있는데, 텍스트큐브의 경우 이러한 사용자 관점의 기획이나 전문 UI 디자인 인력이 전무하다.

뭐, 내가 그런 필요 분야들을 공부해서 하고 싶은 생각도 있지만, 사용자들이, 세상이 짬짬이 공부해서 만족할만한 결과물이 나올 때까지 기다려줄지는 별도의 문제다. 과연 이런 과정들을 어떻게 겪었고, 어떻게 극복했고 또 어떻게 실패했는지 다른 사람들의 경험담을 들어보고 싶다.

소프트웨어공학에서 오픈소스 개발방법론들을 한창 연구했었다고 들었는데, 오히려 오픈소스에 직접 참여하고 있는 학생 입장에서 그런 방면으로 읽어볼 만한 자료는 많지 않은 것 같다. 소프트웨어공학개론 수업 덕분에 매우 안 좋은 추억이 남아있지만 그래도 팀단위 프로젝트가 살아남는 길은 발전적인 소프트웨어공학에 있다고 보기 때문에 이 책에서 그런 내용도 소개될지 궁금하다.

ps. 언젠가 텍스트큐브로도 이런 책을 낼 수 있게 될까?

연말이면 으레 하는 블로그 포스팅. :)

동아리 세미나로 정신없이 시작한 겨울방학과 스웨덴 출국준비로 어수선하게 시작했던 2008년은 여유롭고 평화롭게 글을 쓰며 지나가고 있다. 2004년 11월 말에 이 블로그를 시작했으니 벌써 이 블로그를 운영한 지도 만 4년이 넘었다. 그때부터 쓴 글들은 아직까지 하나도 빠짐없이 그대로 유지하고 있다. (물론 특정한 플러그인이나 태터툴즈 시절의 커스터마이징에 의존했던 부분들은 제대로 서식 처리가 안 되는 것들이 있긴 하지만 내용 자체는 살아있으니.) 이 기록들이 쌓이고 시간이 지나면서 초창기에 쓴 글들을 보면 부끄럽기도 하지만 그 자체도 나의 일부로서 받아들여야 할 것이다.

시간축을 중심으로 하는 블로그를 통해 올해의 나를 기억하는 키워드를 꼽아본다면 사람에 대한 재인식과 나 자신에 대한 재확인이라고 말할 수 있겠다.

사람에 대한 재인식

예전에는 영화나 드라마를 보면 줄거리 자체에 집중하거나 그 작품의 소재, 혹은 얼마나 스펙타클한지와 같은 특수효과 등에 주안점을 두었지만, 요즘은 배우들의 심리묘사에 집중하는 편이다. (최근 방영 중인 드라마 '스타의 연인'이 그런 점에서 내 욕구를 잘 충족시키는 듯하다.) 예전에는 감흥을 느끼지 못했던 사람들의 표정 변화가 새롭게 인식되고 있는 것이다.

스웨덴 교환학생 생활을 하면서 전세계의 내 또래 젊은이들은 어떤 모습을 하고 어떤 생각을 하고 살아가는지 간접적으로나마 느껴보고, 다양한 사람들을 만나면서 사람을 보는 눈이 조금 더 넓어졌다고나 할까. 11월 말에 있었던 대안언어축제 & P-CAMP에서 현업 개발자·중간관리자 분들과 밤새도록 이야기를 나누면서 막연하게 '일보다 사람'이라고 알고만 있던 것들이 현장에서 어떻게 적용되고 어떻게 보여지는지 알 수 있었던 것도 이에 한몫했다.

원래는 구글에서 인턴을 하려고 했지만 아쉽게 기회가 닿지 않아 집에서 푹 쉬게 된 가을엔 또다른 수확이 있었다. 5년 넘게 과학고·카이스트의 기숙사 생활에 해외 교환학생까지 하느라 오랜 시간 함께하지 못했던 가족들과의 관계를 더욱 돈독히 할 수 있었던 것. 중학생 시절에는 이해하지 못했던 부모님의 세계를 더 자세히 들여다보았으며, 종교적인 문제부터 여자친구 문제와 금전 문제에 이르기까지 다양한 주제로 더욱 성숙된 이야기들을 함께 다루면서 동반자적 관계를 더욱 발전시켰다. 물리적으로 가까이 지내면서 그동안 가져보지 못했던 감정들을 다시 꽃피울 수 있었다. 우리 가족이 이 사회의 조류 속에서 어떤 위치에 있는가, 또 나는 우리 가족에서 어떤 위치에 있는가를 돌아보고 앞으로의 생애 설계를 가족과 함께할 수 있음도 확인했다.

나 자신에 대한 재확인

스웨덴 교환학생 생활은 그동안 거의 제대로 써볼 기회가 없었던 내 영어 실력을 확인하는 기회가 되었다. 그리고 이제 영어만 통하는 곳이면 어떻게든 살아남을 수는 있겠다는 자신감도 얻었다. 내가 고급 영어를 구사한다거나 한국어 말하듯 영어가 술술술 흘러나오는 건 아니지만, 외국인과 대화를 시작하는 데에 대한 두려움이 없어졌고 영어로 된 긴 텍스트(소설 같은)를 읽는 것에 대한 부담도 많이 줄었다. 이를 통해 내가 그동안 영어를 적어도 '헛공부'한 건 아니라는 사실을 확인했다.

또 하나 중요한 줄기는 텍스트큐브 프로젝트다. 올해의 키워드로 많이 뽑히는 변화, Change, Transition, 이들이 아주 잘 들어맞는 상황이다. 변방의 자그마한 오픈소스 프로젝트였던 텍스트큐브가 3년째에 접어들면서 구글의 태터앤컴퍼니 인수로 많은 변화를 겪고 있는데 그 과정에서 '어쨌든 3년 동안 한 우물만 팠더니 그래도 뭔가 건질 만한 건 나오더라'하는, 내 관심에 대한 대가를 확인하고 있다. 아직 학부 졸업도 하지 않은 학생 신분이기에 더욱 크게 다가왔는지 모르겠지만, 제주대학교 강의라든지 구글맵 파트너데이 발표 등 굵직한 일에 직접 참여하면서, 이런 일들을 통해 여러 경로로 내 능력을 사기 위한 제안도 받아보고 하면서 나 자신에 대한 자신감을 어느 정도 얻었다.

게다가 출판사를 통해 직접 책을 쓰기로 하고 출판 계약을 하게 되면서 지금까지 살아오면서 경험하지 못했던 새로운 길을 개척한 것도 큰 수확이 아닐 수 없다. 경기 불황의 여파로 이 책이 얼마나 팔릴지에 대한 고민 때문에 출판사하고 책의 출판 형태나 구성에 대해 계속해서 고민 중이라서 쉽사리 책이 나올 수 있을지는 모르겠지만 어쨌든 내가 가진 또 하나의 다른 가능성을 열어보고 인정받은 셈이니까.

한편 이에 따라 새로운 과제로 남은 것은 정말로 내 전문성을 객관적으로 인정받기 위해서 어떤 것들을 준비해야 하는지, 또 앞으로 더 멀리 나아가기 위해서 절제와 겸손의 미덕을 갖추는 것들이겠다. 또한 내가 삶의 목표 중 하나로 삼고 있는—내 능력을 활용하여 사람들에게 가치를 주는 것—을 잘 실현하기 위해서 무엇을 버리고 무엇을 취해야 하는지 판단하는 것도.

그리고, 아직도 지적 사춘기는 현재진행형이다. 막연한 공상과 사고실험을 넘어 좀더 현실적으로 휴학 기간을 활용해 다양한 책들을 접하면서 느끼는 것들이 있는데, 아직 정리할 단계는 아닌 것 같지만 내 삶을 지탱하기 위한 나름의 인식 체계는 조금씩이나마 그 틀을 잡아가는 것 같다.

2009년을 바라보며

광우병 촛불집회, 국회 파행 운영, 미국발 경제한파 등 사회적으로는 큰 변화를 겪고 그동안 쌓여온 부작용들이 한꺼번에 표출되고 있는 2008년이지만 다행히 나 개인의 삶은 더욱더 큰 희망을 품을 수 있게 해준 해였다. 앞으로 2009년에는 어떤 일들이 벌어질지 더욱더 흥미진진하지 않을 수 없다. 당분간은 학업을 계속하겠지만 그 와중에 또 어떤 재미난 기회들이 나를 찾아올지 기대된다. 단 한 가지 걸리는 게 있다면 대한민국 남자들이라면 누구나 하는 병역 의무에 대한 고민일 것이다. (결국 입영통지서가 집으로 날아오고...ㅠㅠ)

노정석님이 WoC WDay에서 발표하신 것처럼 아직 인생의 굴곡을 별로 겪어보지 않은 탓에 지나치게 미래에 대한 희망만으로 가득차있는 것일지도 모르지만, 어쨌든 아직 나는 20대의 시작에 서있고 이 축복받은 시간들을 기왕이면 희망차게 보내면 좋지 않겠는가.

지난 9월 12일 textcube.com을 서비스하던 TNC가 구글에 인수된 후 두번째로 맞는 웹2.0 서비스의 대기업 인수합병 소식이다. TNC도 그렇고 미투데이도 그렇고 추가적인 펀딩이나 지속성에 대한 우려의 목소리가 들리는가 싶더니 결국 인수합병을 통해 살아남는 방향으로 간 것 같다.

• 미투데이 CEO 만박님의 포스팅

일단 돌아가는 모양새를 봤을 때 NHN이 첫눈처럼 서비스를 중단해버린다든지 하는 일은 당분간 일어날 것 같지 않으므로, 사용자 입장에서 보다 안정적인 미투데이 서비스를 기대하고 있다. 첫눈의 경우는 NHN의 핵심역량인 검색서비스와 정면으로 대치되는 것이었고 사실상 인력 인수의 느낌이 짙었기 때문에 서비스를 살려두기 어려웠을 것이지만, 미투데이의 경우는 NHN에 네이버 회원들에게 잘만 접근시켜 준다면 모바일 SNS라는 점에서 새로운 수익원으로 부상할 가능성이 높기 때문에 그렇지는 않을 것이다.

저번 구글맵 파트너데이 끝나고 돌아올 때 수만님과 흥석님이 분당까지 데려다주셔서 이런저런 이야기를 했었고 그 전에도 수만님하고는 다른 오프모임 자리에서 만나뵈었던 적이 몇번 있었는데, 참 편안하게 정말 만들고 싶은 서비스를 만드시는 분들이라고 생각한다. 인력까지 그대로 흡수한다고 하니 두 분과 미투데이 팀이 NHN이라는 대기업 환경에서 어떤 면모를 보여주실지 기대된다.

개인적으로도 미투데이의 서비스는 정말 괜찮다고 생각했는데, 역시 수익이 나기 위한 회원수를 어떻게 뛰어넘는가가 관건이었다. 주변 친구들에게 미투데이를 소개시켜보기도 했는데 다들 '어, 이런 것도 있었네!'라면서 꽤 괜찮게 보지만, 워낙 포탈에 익숙해진 사람들은 가입하고 나서 '뭘 해야 될 지 모르겠다'라거나 '서비스는 괜찮은데 왜 홍보를 안 했지?'라는 반응이 나왔다.

소프트웨어를 개발하고, 서비스를 기획하는 여러 사람들과 만나면서 느낀 것 중에 하나는, 결과가 어찌되었건 의도는 '사용자들에게 이러이러한 새로운 가치를 제공해서 님도 보고 뽕도 따고'인데 서비스를 아무리 잘 만들어도 근본적으로 사용자들이 새로운 것을 써보고 모험하는 데에 대한 장벽이 있어서 쉽지 않다는 것이다. 소위 말하는 캐즘을 어떻게 뛰어넘을 것인가, tipping point에 도달할 수 있을 것인가가 이런 데서 나오는 이야기일 것이다.

미투데이가 앞으로 NHN이 가진 엄청난 수의 회원들에게 잘 노출된다면 그러한 캐즘을 뛰어넘는 것은 시간 문제다. 다만 몇몇 블로거 분들이 우려하시는 것처럼 미투데이의 고유한 '미친' 문화가 그러한 규모에서도 잘 유지될 수 있을지가 조금 걱정이다. 아쨌든 난 미투데이 계속 쓸 거다. :)

그동안 개발했던 구글맵 플러그인을 바탕으로, 구글코리아 지도팀의 초청을 받아 구글맵 파트너데이에 참석했다. 이미 정규님을 통해 물밑 작업(?)이 좀 있었고, 해당 부분 개발을 내가 맡았기 때문에 발표자로 참석하게 되었다.

발표 내용은 대충 왜 구글맵을 파트너로 선택했는지(가장 먼저 구글맵을 이용해 위치정보 기능을 구현했는지), 텍스트큐브가 어떤 특징들이 있었기 때문에 구글맵 도입의 가치를 더할 수 있었는지, 지금까지 구현된 구글맵 플러그인 시연 및 향후 로드맵과 위치정보 서비스와 블로그 결합에 대한 의미를 짚어보는 정도로 구성했다. 아무래도 구글측에서 파트너 협업 사례라는 주제로 초청했으니, 지난 태터캠프 때 같은 소재로 발표한 것에서 구글맵 도입이 어떤 효과를 가져왔는가에 대한 이야기에 좀더 무게를 실어주었다.

행사장은 코엑스 인터컨티넨탈 호텔이었는데, 구글맵에서 이걸 검색하면 같은 블럭 안에 있는 다른 호텔인 '그랜드 인터컨티넨탈 호텔'이 나오기 때문에 전날 서둘러 수정했다(...)는 비화도 들을 수 있었고, 때마침 다음에서도 새 지도서비스 오픈과 관련하여 간담회 형태로 그 호텔에서 행사를 했던지라 그쪽 행사를 보고 오신 분들도 있었다. (스팍스 출신인 권범준 선배님한테 물어보니 좀더 시간이 지나면 검색 결과가 더 좋아질 거라고 한다.)

커다란 볼룸에서 백여명 이상의 업계 관계자들이 있는 자리였는데, 막상 이런 데서 발표하려니 긴장이 되긴 되었다;; 개발자보다는 어느 정도 사업상 결정권이 있는 사람들 및 개발팀장급 이상 되는 사람들이 모인지라 geek한 분위기라기보다는 비즈니스 미팅 같은 느낌이 더 강했다. 어떻게 보면 TNF 활동을 통해 나를 업계(...)에 알릴 수 있는 좋은 기회였다고 볼 수도 있겠지만 어쨌든 발표자로서 긴장이 안 될 수는 없는 법. 게다가 나만 맥을 썼기 때문에 미리 가서 노트북 세팅하느라 좀 삽질도 하고 그래서인지 혹시나 잘못될까봐 더욱 긴장되었다;

다행히 발표 중 별다른 사고 없이 매끄럽게 진행되었고, 나 자신은 무척 떨렸지만 다른 분들 얘기 들어보니 원래 자기가 떨어도 실제 목소리에선 그런 티가 별로 안 나기 때문에 괜찮았다고 한다. (정말일까? -_- 사실 발표 어떻게 했는지도 모르겠다. 그나마 다행인 건 하려고 했던 얘기는 적어도 다 했다는 것.) 발표 후에 이런저런 분들이 찾아와서 명함 교환을 했는데, 아직도 오픈소스 커뮤니티라는 인식보다는 TNF를 회사인 줄 아는 분들이 많았다.;; (난 아직 졸업도 안 한 학부생인데...ㅋㅋ)

어쨌든 그런 큰 행사에서 직접 발표를 해보는 것도 좋은 경험이 된 것 같다. 다음부터는 이런 규모의 청중을 두고 발표할 때 좀더 안 떨고(?) 할 수 있을 것이다. 대부분 경영 쪽 관계자분들이 많아서 좀 지루했을 수도 있지만 사실 나는 내 발표 뒤에 이어진 API 설명 세션이 가장 재미있었다. 반은 아는 내용이었지만 Flash에서 동작하는 API나 Static Map API는 응용할 꺼리가 많을 것 같았다. (현재 텍스트큐브의 구글맵 플러그인을 이용해 포스트에 지도를 삽입하면 RSS 리더에서는 API Key 인증 문제로 볼 수 없는데 이것을 해결할 때 사용할 수 있을 듯.)

한 가지 느낀 점은, 마케팅 담당하는 분들이 정말 괜히 마케팅하는 게 아니구나 싶다는 것. 곳곳에서 업계에 쌓은 인맥을 과시(?)하는 모습을 볼 수 있었는데 나같으면 과연 그렇게 많은 사람들을 일일이 기억하고 있을 수 있을지;;; 아무튼 그런 사람들도 참 대단한 것 같다. 나중에 혹시나 회사 차릴 일 있으면 발이 넓은 사람을 잘 찾아 심어두는 게 중요하겠다는 생각도 들었다.

또 하나 인상적이었던 점은, 구글이 했던 모든 프레젠테이션에서 구글의 회사 비전인 '가능한 모든 정보를 사람들이 쉽게 찾아 이용할 수 있게 만든다'라는 이야기가 빠지지 않았다는 점이다. 그만큼 대외적으로나 대내적으로 이런 비전을 잘 공유하고 있고, 또한 그러려고 노력하고 있다는 사실을 알 수 있었다. 구글이 그 회사 직원들도 스스로 자부심을 느끼고 겉으로도 사람들에게 상당히 좋은 이미지를 유지하고 있는 것이 바로 이러한 비전을 계속 반복해서 알리고 있기 때문이 아닐까 싶다.

자, 그럼 앞으로 구글맵을 가지고 또 뭘 해볼까?

아래의 태터캠프 후기 글에서도 언급했지만 스킨 규격에 대한 내 생각을 한번 죽 정리해보고자 한다.

기존 스킨 규격의 특징

• 각종 치환자와 블록 태그들의 집합체.
• 드림위버나 나모 같은 위지윅 에디터에서 바로 편집할 수 있다. HTML을 가장 높은 자유도로 편집 가능.

TTSKIN 2.0 (draft)의 특징

• 치환자 및 블록 태그 최소화, HTML의 자유도를 거의 없앰.
• CSS Selector만 맞추면 디자인과 마크업을 분리할 수 있다. (웹표준 기반의 개발방법론에서 스킨 규격은 publisher의 역할이라고 볼 수 있다.)
• 각 서비스가 큼지막한 치환 영역을 '알아서' 렌더링한다. 스킨이 같아도 각 서비스가 원하는 기능을 맘대로 집어넣을 수 있는 여지가 많다.

기존 스킨의 문제점

• 여러 서비스에서 같은 규격을 사용하다보니, 각자가 원하는 기능을 추가하기 위해선 치환자를 추가해야 하는데 어떤 형식으로 만들어야 하는지에 대한 정의가 없기 때문에 통일성이 없다. (고로 스킨을 다 따로 만들어야 한다)
• 치환자 및 블록 태그의 종류가 너무 많고, 어떤 것은 html 태그 덩어리를 생성하고 어떤 것은 단순한 문자열이나 숫자만 생성하고, 또 어떤 것은 특정 html 태그 안의 속성을 생성하기도 하는 등 사용법이 다 달라 이미 있는 스킨을 고치기는 비교적 쉬워도 새로 만들기는 어렵다.

TTSKIN 2.0의 문제점

• 디자이너가 편집 결과물을 직접 보면서 작업하기 힘들다.
• 순수한 웹표준 기반 개발방법론에 익숙하지 않은 사람들은 '이게 뭥미?' 상태.
• HTML에 대한 지나친 제약?

개발자(스킨 규격을 해석하는 소프트웨어를 만드는 사람들)가 원하는 것

• 해석 속도가 빠르게 나오도록 구현할 수 있어야 한다.
• php 코드 등이 실행될 여지를 없애서 보안성을 높여야 한다.
• 여러 서비스에서 서로 다른 기능을 구현하더라도 하나의 스펙으로 추상화하여 다같이 통용될 수 있다면 멋질 것이다. (새로운 기능 추가에 대한 확장성이 뛰어나야 한다)

디자이너(스킨 규격을 이용해 스킨을 만드는 사람들)가 원하는 것

• 일단 무조건 만들기 쉬운 게 짱. 이해하기 쉬워야 한다.
• 만들면서 레퍼런스를 복잡하게 뒤질 필요가 없으면 좋겠다. (외울 것이 적어야 한다)
• 실제 스킨이 적용된 결과를 바로바로 보면서 작업할 수 있어야 한다.
• HTML과 CSS를 최대한 맘대로 건드릴 수 있으면 좋겠다.

사용자가 원하는 것

• 기존에 있는 스킨 가지고 내가 원하는 그 무엇(위젯이 될 수도 있고, 라이선스 표시 같은 것이 될 수도 있고)을 쉽게 넣을 수 있었으면 좋겠다.
• 비록 개발자나 디자이너 수준은 아니더라도 좀 쉽게 내맘대로 조작하면 좋겠다.
• 하나의 스킨 가지고 여러 곳에 복사해서 써먹을 수 있으면 좋겠다.

Trade-off가 일어나는 부분

• HTML에 대한 자유도 vs. 서비스 독립성
• 뛰어난 확장성을 가진 규격 vs. 디자이너들의 이해도

몇 가지 대안들

• Django Template처럼 간단한 프로그래밍이 가능한 템플릿 엔진을 도입한다.
  • 기존에 있는 것을 쓰기엔 무거워 보이고, 직접 구현하기에도 만만하지 않음.
  • 확장성도 뛰어나고 HTML 자유도도 높지만 역시 디자이너들의 이해도 문제가 걸림.
• 기존 스킨 규격에서 치환자들만 다시 정리한다.
  • 어쩌면 여러 면에서 가장 현실적인 대안.
  • 확장성을 어떻게 확보할 것인지가 관건.
• 그냥 다 포기하고 각 서비스 알아서 독자 규격 사용하도록 놔둔다.
  • Project Tattertools의 의미 퇴색이 문제.

매우 괴상한 규격을 만들긴 했지만 나름대로 이런 고민들을 하고 있다. 좋은 의견 있으면 꼭 댓글이나 트랙백으로 달아주었으면 좋겠고, 차기 스킨 규격 제작에 꼭 반영할 수 있도록 노력하겠다.

사실 이런 걸 두고 정말 '공학적인 문제' 또는 '정답 없는 문제'라고 말할 수 있겠지. ㅠ_ㅠ 이런 문제를 학교 수업에서는 거의(?) 다루지 않는데, 과연 교수님들한테 이런 상황을 설명하면 어떤 대답을 하실지 궁금하다. ('그냥 너가 알아서 해' 이런 거 빼고.)

어제는 제6회 태터캠프가 있었다. 지난 7월 초에 있었던 5회 태터캠프 이후 TNC가 구글로 인수되기도 하는 등 많은 변화가 있었기 때문에 이번 주제 또한 Transition이었다. 우리 형이 홍익대 건축대학원에 합격했기 때문인지 왠지 더 친근한 홍문관 건물에서 행사가 열렸는데 행사장 자체는 상당히 자유분방하고 아늑한 분위기였다. (다만 태터캠프에서 그런 점을 충분히(?) 살리지 못한 점이 조금 아쉽다.) 나는 그동안 만들어온 구글맵 플러그인을 소개하고, 이것이 텍스트큐브, 더 나아가 블로그에서 어떤 의미를 가지는지, 앞으로 이것으로 할 수 있는 일들이 무엇이 있을지 간단하게 소개하는 발표를 맡았다.

질문 시간에 나왔던 것 중 가장 기억에 남는 황당한 것을 뽑으라면, 지역 로그에 '안드로메다'를 사용한 경우는 어떻게 되나요라는 것이었다. 항상 개발자들이 예상한 use-case를 벗어나는 경우가 있다는 사실을 일깨워주는 대표적인 사례라 할 수 있겠다. ㅋㅋㅋ 결국은 카테고리나 태그를 활용하세요..라고 대답할 수밖에 없었다.

다른 발표들은 태터캠프 후기용 포스팅에 걸린 트랙백들을 참고하면 되겠다. 개인적으로 가장 인상깊었던 발표는 티스토리의 PRO.T.OS 프로젝트와 겐도님의 발표였다. (사실 다른 부분들은 대충 다 알고 or 예상하고 있던 내용들이라서...) 티스토리팀에서 남는 20% 시간을 활용해 만들었다는 티스토리의 콘솔 인터페이스 버전은 사실 이미 옛날에 TNF 내부에서 아이디어가 나온 적이 있었던 것이나 역시 여가시간에 참여하는 오픈소스 특성상 이미 있는 요구사항 구현하기도 벅차서 안드로메다로 사라진 뭐 그런 것이라 더욱 흥미로웠다.

무엇보다 나는 오랜만에 노정석님과 김창원님, 겐도님 등 나름(?) 정들었던 TNC 구성원분들을 다시 뵐 수 있어서 좋았다. 바쁘고 어수선한 시기도 있었겠지만 일단 지금은 구글에 잘 적응하신 것 같아 보였다. 겐도님은 여전히 각종 기술적인 이야기들을 쏟아놓으셨다. 하지만 역시 영어 커뮤니케이션은 조금 부담되시는 면도 있는 듯.

특히 반가웠던 것은 그동안 사실상 혼자(초기에 그라피티에님의 도움을 좀 받았던 것을 제외하고) 작업하고 있는 TTSKIN 2.0 표준화에 대한 이야기가 나왔다는 점과 앞으로 지역로그나 지역태그 관련해서 티스토리 측과도 서로 데이터 형식 호환이 되게 하자는 데에 동의를 이끌어냈다는 점이다. 실제 기술적인 부분은 앞으로 좀더 논의를 해봐야겠지만 말이다.

일단 가장 시급하면서 사실 가장 해결하기 힘든 문제가 표준화이다. 태터캠프 발표에서도 나왔듯 이미 티스토리와 텍스트큐브닷컴 모두 스킨 스펙을 자체적으로 개발하고 있고, 서로 목표하는 서비스 지향점이 비슷한 듯하면서도 다르기 때문에 모두를 충족시키는 규격을 만들기란 쉽지 않을 것이다.

사실 내가 작업한 draft는 일단 엔지니어 입장에서 봤을 때 HTML을 마크업 언어로 사용하여 디자인을 정의할 때 어떻게 하면 가장 잘 추상화할 수 있는지 극단적으로 실험해본 거라고 할 수 있을 것이다. 어제도 얘기가 나왔지만 역시 깔끔한 추상화를 할수록 초보자나 일반 사용자들, 혹은 디자이너들이 접근하기 어려워지는 문제가 있다. 지정된 CSS Selector만 맞추면 되고 사실 대부분 optional하기 때문에 스킨 스펙 구현은 상당히 간단한데(아마 성능도 지금보다 많이 끌어올릴 수 있을 것이다), 디자이너들 입장에서 가장 큰 문제는 HTML 없이 CSS Selector만으로 디자인 작업을 할 수 없다는 것이다. 이 문제 때문에 초기 논의 단계부터 실은 각 서비스별로 블록치환자들을 치환한 후의 HTML 결과물을 생성해주는 간단한 서비스를 제공하도록 할 생각도 가지고 있었지만 역시 스펙 차원에서 굳이 그럴 필요가 없다면 더 좋을 것이다.

그나마 사용자 친화적(?)인 스킨 스펙을 만들려고 노력하고 있다는 티스토리 관계자 말씀에도 불구하고 이런 불만(?)들이 나오고 있으니 차기 스킨 규격 입안자로서 정말 고민이 되지 않을 수 없다. ㅠ_ㅠ; 예전에 위지윅 에디터에 대한 고민을 할 때도 궁금했지만, 사용자 친화성과 아름다운 추상화는 꼭 대립할 수밖에 없는 것일까?

이 외에도 골치아픈 문제들이 더 있는데, TTXML 스펙이야 어떻게든 맞춘다쳐도, 위지윅 에디터에서 오브젝트 등을 삽입하고 그에 대한 부가 속성들을 관리하기 위해 사용되는 TTML도 어떻게 표준화할 것인지 큰 고민이다. 구글 텍스트큐브닷컴에서는 내부적으로 XML 형태의 치환자를 사용하고 있다고 하는데, 현재 내가 생각하고 있는 것은 object 태그를 활용하든지, div 태그를 이용해서 컨텐츠 영역과 fallback 영역을 분리해놓고 RSS로 보거나 일반 글보기 상태로 보거나 하는 view 맥락에 따라 적절하게 핸들러를 골라서 보여주는(그리고 그 핸들러는 플러그인으로도 정의될 수 있는) 방법인데 역시 문제는 표준화일 것이다.

스펙 자체가 표준화되었다 하더라도, 예를 들어 구글맵 플러그인과 다음맵 플러그인이 있다고 할 때 구글맵 플러그인으로 작성했던 포스트를 다음맵 플러그인만 사용하는 환경으로 옮겼을 때 똑같은 내용을 표현하는 지도를 단지 핸들러가 다르다고 해서 완전히 다르게 취급해야 할 것인지까지 고려하기 시작하면 더욱 골치아파진다. (글 자체의 속성으로 들어가는 지역 태그나 위경도 좌표 등은 호환시키가 어렵지 않겠지만 말이다.)

단순히 웹표준을 지키려고 하는 입장에서야 표준을 지키지 않는 웹브라우저를 비난하면 그만(?)이었지만 직접 표준을 만드는 입장이 되어보니 또다른 어려움들이 생긴다. 잘만 되면 대박이지만 잘 안 되면 흐지부지되고 그냥 역사 속으로 사라져버릴 수도 있는 게 바로 표준이라서 참 많은 고민이 된다.
(어째 시작은 태터캠프였는데 끝은 표준화 얘기가 되어버렸다. -_-)

그저께 고등학교 동기 친구의 아버님이 돌아가셨다. 대안언어축제 및 P-CAMP를 2박3일 동안 마치고 돌아와 성당 다녀온 다음 저녁 먹으려던 찰나에 연락받았다. 가족·친척 빼고 태어나서 처음 가는 조문이었다. (사실 아주 어렸을 때 할머니 돌아가신 거 말고는 장례에 가본 적이 없다.) 대안언어축제 마지막날 거의 밤새고 그 전날도 잠을 설치고 그랬던 터라 매우 피곤한 상태였지만 그래도 안 가볼 수는 없었고, 또한 경기과학고 21기 아이들도 많이 올라오고 있다고 하니 얼굴도 볼 겸 가게 되었다.

빈소에 조문하러 가면 나는 전체적으로 아주 엄숙한 분위기일 거라 생각했지만 일단 영정에 절하고 상주와 맞절하는 순서를 마치면 방문한 사람들끼리 앉아 음식 대접을 받으며 왁자지껄하게 떠드는 그런 거였다. 누구 말로는 초상으로 인한 허함을 달래기 위해 사람들이 모여 먹고 마시고 떠듬으로써 그 빈 공간을 채우고자 하는 일종의 문화라고 하였다.

언젠가 나도 나이먹고 친구들의 부모님이 돌아가시면 초상집에 조문하러 다니겠지 하는 생각은 막연히 하고 있었지만 이렇게 갑작스레, 예상보다 일찍 찾아왔다. 듣기로는 며칠 전에 쓰러지셨다가 그날 새벽에 돌아가신 거라고 한다. 대안언어축제를 통해 현업에 계시는 분들을 만나 이런저런 이야기와 회포를 풀며 삶에 대한 에너지를 얻었지만 또 이렇게 죽음과 남은 자들의 공허함을 대면해야만 했다. 사실 우리는 삶의 모습만을 보지만 언제나 그 이면에는 죽음들도 함께하고 있는 법이다. 우리가 건강하게 살아가는 것 또한 사실 지금 이 순간에도 수많은 세포들이 태어나고 죽으면서 우리 몸을 유지해주기 때문이리라.

어쩌다보니 이날 조문은 졸업 후 경기과학고 21기의 가장 큰 모임이 되어버렸다. 해외에 나간 친구들과 서너명 정도 연락이 제대로 안 된 녀석들 및 일정 때문에 다음날 방문하기로 한 친구 두세명 빼고 나머지는 거의 다 온 것 같다. 학기 중 일요일이라 카이스트 다니는 아이들은 기차타고 내려가다가, 혹은 도착해서 연락받고 도로 올라오기도 했다. 대부분 학사과정의 끝에 있는 상황이었기 때문에 어쩌면 이 모임이 사회생활을 시작하기 전 마지막으로 만나는 것일지도 모르겠다.

석사 진학한다는 친구도 있고, 의대나 한의대에 진학해서 본과 생활 때문에 힘들어하는 아이들도 있고--해부 실습할 때 쓰는 포르말린 용액 때문에 그 독성으로 얼굴에 여드름이 도진 친구도 있었다--아직은 대부분 학생이지만 앞으로 5년, 10년 지나면 어떤 모습들로 변해있을까. 한의대 간 한 친구는 자기가 공짜로 침 놔줄 테니 허리 아프면 찾아오라는 소리도 했다.

나는 지난 학기에 교환학생을 다녀왔고 이번 학기 휴학 중이었기 때문에 다들 소식이 궁금한 모양이었다. 이런저런 프로젝트들도 하고 있고, 책 쓰는 일도 하고 있다고 하니 몇몇은 흥미있어하는 눈치였다. 대부분 학업을 하며 앞으로 계속 달려나가고 있지만 나는 한 템포 늦추면서 대신 다른 경험을 쌓는 중인 셈. 고등학교 때만 해도 경시 입상하는 것 외에는 주변의 것을 별로 보지 못했던 친구들은 대학생활을 하고 나니 '그 외의 다른 것들'에 대해 느끼는 점들이 있는 것 같았다. 침 놔준다던 친구는 오히려 날 부러워하기도 했다.

남들이 선망하는 의대, 한의대에 진학한 친구들이었지만 자기가 진정 원하는 일을 찾아 하는 친구들을 보고 내심 부러워하는 경우도 있는 것 같다. 물론 자기가 원해서 간 친구들이야 그렇지 않겠지만. 사실 나도 지금 하고 있는 일들이 '진정으로 내가 원하는 일인가'에 대해서는 확신이 서지 않지만, 그래도 일단 하면 즐겁고 성취감이 있다는 점은 분명하다.

한편으로는 어떻게든 학부 전공은 마무리했지만 앞으로 무엇을 할지 고민하는 경우도 있었다. 아직도 자기가 무엇을 하고 싶은 건지 모르겠다는 것. 사실 과학고 정도 되는 학생들에겐 공부를 잘 하는 것보다 삶의 진로 선택이 더욱 중요한 것 아닐까 싶다. 방향만 정해진다면 그걸 향해 달려나가는 것은 누구에게도 뒤지지 않을 친구들이니까. 하지만 동시에 잘못 방향을 잡는다면 더욱 큰 상처를 받을 수도 있는 것이다.

이 친구들을 다시 몇 년 후에 보게 되면 어떻게 달라져 있을까. 고등학교 졸업 후 내가 얼마나 많은 것을 경험했는지 생각해보면 앞으로는 또 어떤 흥미진진한 일들이 펼쳐질지 궁금하다. 언제까지나 순수한 고등학생처럼 남아있을 수 있을지.

지난 금~토요일에는 무려 제주도를 다녀왔다. 원래는 NHN DeView 컨퍼런스를 가려고 일찌감치 등록까지 해놓은 상태였는데 니들웍스를 통해 다음커뮤니케이션 쪽에서 급히 연락이 와서 제주대학교에서 강의(...)를 하게 된 것이다. 다음에서 제주대학교에 오픈소스 개발방법론 강의를 개설했다는 소식은 예전부터 알고 있었지만, 실제로 내가 거기에 가게 될 줄은 전혀 몰랐다. 내가 맡은 부분은 실습 세션으로, 학생들이 기말프로젝트(...)로 텍스트큐브나 제로보드 쪽에 참여하도록 했기 때문에 좀더 익숙해질 수 있도록 도와주기 위한 것이었다.

그래서 가게 된 인원은 총 4명으로 TNF 리더이신 신정규님 외에 최호진님, 고재필님 그리고 나였다. 사전에 듣기로는 주로 3~4학년 컴퓨터공학 전공 학생들이 수강하는 수업이라고 했는데 그럼 나와 동갑이거나 한 살 많은 사람들을 두고 '초청 강사'로 강의를 하게 된 셈이다.;

'텍스트큐브 프로젝트에 참여해보기'라는 과제를 수행해야 하는 학생들을 두고 도대체 어떤 내용의 실습을 진행해야 하나 고민했는데, 결국은 플러그인에 대해 알려주는 쪽으로 결정했다. 텍스트큐브 코어 구조는 엄청난 내부 공사를 거치고 있는 중이라 1.8 버전을 거치며 크게 변할 것이기 때문에 지금 가르쳐준다고 해서 나중에 별로 도움이 될 것 같지는 않았고, 구조가 안 바뀐다고 하더라도 짧은 시간에 수만 줄에 이르는 방대한 코드의 구조를 파악하고 자기가 기여할 만한 부분까지 찾는다는 것은 쉽지 않은 일이기 때문이다. 따라서 정말 자기가 뭔가 '만지고 있다'라는 느낌을 주는 데 가장 적합한 것이 플러그인이라고 생각한 것이다. 혹시나 수업을 들은 학생들 중에 좀더 코어에 깊이 관여해보고 싶은 열정적인(...) 학생이 있었다면 조금 실망했을지도 모르겠다.

교통의 발달 덕분에 요즘엔 그런 큰 거리를 이동하는 것도 훨씬 쉬워진 것 같다. 제주공항에 내리자 우선 훨씬 따뜻하다는 것을 느낄 수 있었다. 전에도 제주도에는 2번이나 왔었지만 한겨울에도 길거리에 있는 푸른 잎들의 야자수를 보면 같은 나라인가 싶다. 택시를 타고 제주대학교로 향하는 길에 다음 글로벌미디어센터도 볼 수 있었는데, 입구에 노트북을 펼치고 앉아있는 돌하르방이 아주 폐인(...)스러워보이는 게 재밌었다;; 제주대학교는 약 해발 200미터 높이의 한라산 북쪽 자락의 경사진 땅에 지어져 있다. 우리가 강의할 건물은 위쪽의 새로 지은 새 건물이었는데, 강의하기 위해 3층인가 4층인가 올라가니 복도 전면 유리창으로 멀리 바다와 푸르른 초목이 보이는 것이 아주 가슴이 뻥 뚫리는 듯 시원했다. 공기도 좋고 전망도 끝내주는 이런 학교에서라면 왠지 공부가 더 잘 될 것 같은 느낌? ㅋㅋ

어쨌든 세미나와 수업은 무사히 끝났고, 초청강사로 강의한 것에 대한 증빙자료(?) 준비 때문인지 신분증 확인 후 수업을 들었던 10명 내외의 학생들과 다음의 윤석찬님과 함께 흑돼지 삼겹살로 저녁을 먹었다. 석찬님이 친히 구워주시는 고기를 먹으면서 이런저런 이야기를 했는데 나도 그렇고 재필님도 그렇고 아쉬워했던 것은 왜 카이스트나 포항공대에는 이런 수업이 없을까 하는 점이었다.

카이스트는 컴퓨터공학과가 아니라 전산학과이기 때문에 아무래도 이론의 비중이 좀더 높고 '프로그래밍 언어는 알아서 배워라' 식의 배짱이 있어서인지 SP와 OS 및 DB개론을 제외하고는 실무와 직접적으로 관련된 내용은 수업에서 거의 가르치지 않는다. (아마도 학생들 머리가 좋으니까 기초를 잘 가르쳐놓으면 알아서 잘 하겠지... 뭐 이런 생각인 것 같다) 하지만 오픈소스 개발은 소위 전통적인 소프트웨어공학으로 달성하지 못한 다른 방향을 보여주고 있기도 하고, 어렸을 때부터 프로그래밍을 접해보지 않은 학생들이 전산과에 왔을 때 겪는 어려움을 극복할 수 있도록 흥미와 동기를 유발하는 효과도 있기 때문에 나는 카이스트에서도 이런 수업을 적극적으로 제공해야 한다고 생각한다.

한 가지 재밌었던 것은 그곳 학생들도 문제의 소프트웨어공학개론 덕분에 꽤나 고생한 경험이 있더라는 것. UML 다이어그램으로 점철된 300장짜리 보고서 이야기를 해주니 '역시...'라며 다들 끄덕끄덕. -_-;;; 윤석찬님께서는 이미 전통적인 개발방법론을 지나 오픈소스를 모델로 하는 방법론들이 연구되어 있고 기업에서도 이를 많이 도입하고 있다면서 학교에서도 그런 방향의 교육이 있으면 더 좋겠다는 말씀을 해주셨다.

저녁 먹고 학생들과 헤어진 후 어둑해진 해안으로 나가 고등학교 수학여행 시절에 보았던 용연과 용두암 야경을 보며 산책한 후 다음 쪽에서 제공한 숙소인 그랜드호텔로 갔다. (나중에 알고보니 여기가 우리 부모님 신혼여행 숙소였다고 한다. -_-) 1층 커피샵에서 윤석찬님과 함께 좀더 심도있는 여러 이야기들을 나눌 수 있었다.

프론트에 물어보니 호텔방에서 유선인터넷을 사용할 수 있다고 해서 좋아라(...) 올라갔는데 접속해보니 하루 만오천원. 역시 호텔은 돈쓰는 곳이야...라면서 adhoc 네트워크로 공유하면 되지 하고 인터넷에 연결했다. 그러나 맥의 인터넷 공유와 우분투하고는 뭔가 상성이 안 맞았는지 호진님은 먼저 쥐쥐치고 주무시고, 재필님도 조금 인터넷을 쓰시다가 자러 가시고, 정규님과 내가 남아서 2.0 프레임웍 구조를 도입하느라 지뢰밭이 되어버린 trunk를 일단 돌아가게 만드는 작업을 했다. 간만의 여행으로 인한 피로와 싸우며 새벽 4시가 되어가고 로컬호스트 주제에 로딩에 5초씩 걸리는 텍스트큐브를 보면서 쥐쥐 선언. -_-;;

다음날은 느지막히 일어나 호텔 근처의 유명하다는 모이세해장국집에서 아침을 먹고 바로 공항으로 향했다. 주말이라 하루 정도 더 묵으면서 제주도를 즐길 수도 있었지만 니들웍스 분들이 전국에 흩어져있어 자주 얼굴보기가 힘들기 때문에 4명이나 한 곳에 모였으니 오프라인 모임을 한번 하기로 했던 것이다. 와이브로를 무선랜으로 공유하여 공항버스 안에서 인터넷을 즐기며 서울 강남으로 향했다. 그라피티에님과 합류하여 trunk 소스를 어떻게 할지, 빨리 처리해야 할 각종 사안들에 대한 논의가 이루어졌고 결국 지난 일주일간 dispatcher 중심으로 개편 중이던 trunk 소스는 암흑의 역사로 이동이 결정되었다. 또한 프레임워크를 도입하면 캐시가 중요하다고 강조하신 실무 유경험자 호진님의 의견을 따라 캐시 부분도 재작성하기로 했는데, 옆에서 듣다보니 '아, django라면 이 삽질 안 해도 되는데...'라는 생각만...ㅠ_ㅠ; 이런저런 이야기들을 하고 숨가쁜(?) 1박2일 동안의 남에 번쩍 북에 번쩍 스케줄을 마무리할 수 있었다.

내 또래 학생들을 놓고 정식 수업으로 초청 강의한다는 게 좀 생경한 경험이긴 했지만 간만에 콧바람도 좀 쐬고 사람들과 여러 발전적인 이야기들을 나눌 수 있어서 좋았다. 점점 갈수록 이번 학기 휴학하길 잘했다는 것과, 구글 인턴에 떨어진 것이 어쩌면 오히려 나에게 더 큰 기회를 주고 있는 걸지도 모르겠다는 생각과 함께 말이다.

ps. 주임교수님 아니랄까봐(?) 나와 재필님이 강의하는 수업에 출석까지 부르시는 윤석찬님을 보니 똑같은 학부생 입장에서 참... 그래도 금요일 오후 수업인데...ㅋㅋㅋ

뭐, 아주 오래 전부터 나온 떡밥이라 더 이상 새로울 것도 없지만 정말 너무 열받아서 써본다. (웹표준이니 오픈웹 소송이니 이런 거 아시는 분들은 읽을 필요 없음.)

아버지가 오래된 골프채 하나를 새로 장만하신다며 인터넷에 봐둔 것이 있다고 하셔서 사려고 했다. 원래는 회사 노트북을 쓰시지만 오늘은 집에 가져오지 않으셔서 내 데스크탑에서 하게 되었다.

1. 우선 네이버에서 검색어 입력 후 쇼핑 가격비교를 통해 신세계몰의 상품 페이지에 들어갔다.
2. 상품 유형 선택하고 설명을 보니 제휴 카드로 하면 5% 할인이 된다고 한다. 주문서 작성 화면에서 카드 할인을 적용하라고 되어 있다.
3. 결제하기 들어가서 비회원 주문 선택. 약관 동의 체크.
4. 결제 플러그인 설치 안 되었다고 궁시렁해서 설치 허용 후 2번부터 반복.
5. 주문서 작성 화면을 아무리 눈씻고 찾아봐도 카드 할인 적용에 관한 문구도 없고, 결제 금액은 할인 안 된 금액으로 그대로 나와 있다. 해당 카드로 선택해도 안 바뀜.
6. 주소 등 주문서 작성.
7. 그냥 할인 포기하고 사려고 결제 시도하자, 카드 번호 입력칸에 입력이 안 된다. 한참 삽질하다가 메모장에서 복사-붙여넣기 하면 된다는 걸 발견.
8. 해당 카드사의 플러그인 설치해야 한다고 궁시렁해서 다시 2번부터 반복.
9. 원래 결제하려던 카드는 어머니 꺼였는데 인터넷 뱅킹을 하신 적이 없으시기 때문에 공인인증서가 없다는 사실을 깨닫고 다시 7번부터 반복.
10. 카드 비밀번호 등을 입력하는 화면으로 넘어갔는데 이젠 붙여넣기도 안 되고 전혀 입력 불가능. 비스타 64비트에서 결제하는 것은 포기.
11. 가상머신으로 윈도 XP 부팅.
12. 다시 1번부터 반복하여 중간에 결제 플러그인 설치하느라 한 번 더 반복 후 7번까지 진행.
13. nProtect 깔라길래 끝까지 설치 안 하려고 했더니 8번에서 걸린다. 설치했는데 다행히 입력은 문제 없었음.
14. 안심클릭 비밀번호를 입력하는 화면에 넘어왔는데, 아버지가 인터넷 결제를 잘 안 하시는 분이라서 예전에 만들어둔 비밀번호가 맞지 않는다. 공인인증서로 하려고 해도 회사에 있으니 못 가져옴. 비밀번호 재설정도 공인인증서 요구.
15. 결국 옆에서 보다 못한 아버지께서 그냥 낼 노트북 가져오든지 회사가서 할께..하시고 포기. OTL

난 도대체 왜 이런 모든 삽질을 해야 하는지 이해할 수가 없다.

대한민국 정부와 금융결제원은 각성하라! 각성하라!

내가 전산과에 들어가서 알게 된 것 중 하나는 전산과 학생들이 누구나 다 프로그래밍을 잘 하는 건 아니라는 사실이다. 그것도 국내에서 나름 가장 수준높은 학생들을 모아놓은 카이스트임에도 말이다. (사실 나는 전부 다 괴짜에 전부 다 초천재적으로 엄청난 알고리즘들을 쏟아내며 코딩하는 줄 알았다.) 대개 프로그래밍을 어렸을 때부터 해왔던 아이들이 잘 하는데, 자세히 보면 뭔가 스스로 삽질을 많이 해본 아이들이 습득 속도도 빠르고 응용력도 더 높은 걸 볼 수 있었다. (가장 대표적인 예는 토끼군. ㅋㅋ)

나는 프로그래밍을 초등학교 5학년 때 처음 접했는데, 당시 시작한 것이 Q-BASIC이었다. 집에 있던 시리즈 과학책 중에 GW-BASIC으로 프로그래밍하는 것을 예제 중심으로 다룬 책이 있었는데, 그걸 보고 혼자 따라하다가 곧 내가 만들어보고 싶은 프로그램을 만드는 것으로 바뀌기 시작했다. 6학년 때 Visual Basic을 접했고 이때부터 본격적인 삽질의 나날이 시작되었다. 프로그래밍을 접하기 전에 내가 가장 관심있었던 것 중 하나는 각종 전략시뮬레이션 게임(스타나 커맨드앤컨커 같은)들의 맵에디터를 빠삭하게 꿰차는 것이었다. 과연 이 게임들은 내부가 어떻게 돌아가는 걸까에서 출발한 호기심이 결국 지금의 나를 만들었다고 하겠다.¹

당시 만든 것 중 지금까지도 기억에 남는 프로그램들이 몇 가지 있는데, 당시 유행하던 레드얼럿의 커스텀 미션을 만들 수 있도록 해주는 레드얼럿 미션에디터와 탭브라우징이란 개념이 널리 퍼지기 이전에 한 창에 여러 웹페이지를 보여줄 수 있는 방법이 없을까 고민하다가 만든 MDI 형식의 웹브라우저가 있다. (물론 HTML 해석기를 구현한 건 아니고 IE 컴포넌트를 쓴 거였지만. 뭐, XML/HTML 파서를 만들려고 시도해본 적은 있다.)

중학교 1학년이 지나면서부터는 비주얼 베이직에서 제공하는 모든 기본 기능과 라이브러리들에 대해 익힐 수 있었고, 미약하게나마 객체지향을 터득하면서 인터페이스 개념을 알게 되었다. (비주얼 베이직은 상속이 안 되지만 나름대로 객체지향적 특징을 가지고 있었다.) 중학교 2학년 때가 가장 절정을 이루었는데 비주얼 베이직의 끝을 본 건 분명 언어는 비주얼 베이직이지만 비주얼 베이직 런타임에 의존하지 않고 순수 윈도 API만으로 윈도 어플리케이션 만드는 방법을 완전히 이해했고--물론 실제 구현하려면 수많은 삽질이 필요하겠지만 어쨌든 원리는 이해했다--인터넷에 올라온 글을 보고 알게 된 것이긴 하나 비주얼 베이직의 특정 함수를 어셈블리 코드로 대치해서 실행한다든지, 또 정식으로 공부한 건 아니지만 재귀를 어떻게 루프만으로 구현할 것인지 등에 대한 어렴풋한 이해를 가지기 시작했다. 이와 함께 어지간한 프로그램을 보면 내가 아직은 잘 모르는 C/C++ 언어로 만들었겠지만 대충 이러이러하게 구현했겠구나라는 정도의 감각이 생겼다.

당시 SQL이나 DBMS에 대한 개념이 없었기 때문에 ADO 관련된 컴포넌트만 안 써봤고, 그 외에는 비주얼 베이직을 거의 극한까지 다루어봤다고 할 수 있겠다. 이 정도 단계에 다다르면 어떤 의문점이 생겼을 때 레퍼런스를 잘 찾아보든지 스스로 설계를 얼마나 더 잘하느냐가 해결의 성패를 좌우하게 되는 것 같다. (물론 고등학교 때 친구 토끼군인 비주얼 베이직으로 즉석에서 디자인한 스크립트 언어의 인터프리터를 구현해내는 걸 보고 또 다른 차원이 있다는 걸 깨닫게 되었지만, 지금은 그에 필요한 이론 지식들을 어느 정도 알고 있으므로 다시 내가 한다면 가능할 것 같다.)

중학교 3학년때와 고등학교 때는 학업 때문에 프로그래밍을 깊게 팔 기회가 없었고, 고등학교 때 수박 겉핥기 식으로 C++의 아주 극히 일부만 조금 배웠다. 대학에 와서는 학교 커리큘럼을 따라 Java를 익히기 시작했는데 사실 처음으로 다뤄본 완성도 있는 객체지향 언어였음에도 처음 프로그래밍을 접하던 친구들에 비해 훨씬 빠르게 익힐 수 있었으며 2, 3학년을 거치면서 PHP, Python, Javascript 등 다른 언어들도 상대적으로 손쉽게 두려움 없이 접근·터득할 수 있게 되었다.

특히 중학교 시절 쌓은 수많은 삽질 경험은 전산과 최고의 로드를 자랑하는 시스템 프로그래밍과 운영체제 과목에서 진가를 발휘했다. 매뉴얼(MSDN)을 보고 이 함수가, 이 컴포넌트가 어떤 방식으로 동작하는지 이해하고 실제로 사용해보고, 또 내가 그걸 이용해서 뭔가 만들어볼 수 있지 않을까 하면서 머리 굴려가며 시도해본 온갖 잡다한 미니프로젝트들은 결과적으로 거대한 시스템의 내부를 들여다보고 남들보다 빠르게 이해하는 능력을 키워준 것 같다.

시스템 프로그래밍 과목은 1번 프로젝트부터 5번 프로젝트까지 계속 기존 코드에 기능을 덧입히는 식으로 진행되었는데, 상당수의 학생들이 초기 명세에만 대응된 설계를 했다가 갈아엎는 일이 많았지만 나는 한 번도 갈아엎지 않고 꽤 깔끔하게 마지막 프로젝트까지 커버할 수 있었다. 이런 건 누가 가르쳐준 것도 아니고 누군가의 도움을 받은 것도 아니지만, 스스로 크고 작은 규모의 프로그램을 만들면서 왜 이렇게 설계하면 안 좋은지 좋은지를 깨달았기 때문이라고 할 수 있겠다. (이에 대한 보다 구체적인 지식은 소프트웨어 공학을 접하면서 배우게 되었지만, 나름의 내재된 감각이 생겼던 것이다.)

사실, 아직은 나 자신이 정말 프로페셔널한 '업계'에서 일해본 경험이 없어서 겐도님처럼 자신있게 "한 달의 기간이 있으면 아키텍처 설계를 포함해 그 언어를 습득·활용할 수 있고 1년이 지나면 전문가라고 말할 수 있다" 정도의 수준인지 아닌지는 나도 잘 모르겠다. 스스로 검증해본 적이 없기 때문이다. 학교 프로젝트를 통해 언어나 개발 환경을 접하게 되면 딱 그 프로젝트를 해결하기 위한 내용만을 익히게 되는 경우가 많고--더군다나 언어는 가르치지 않는다는 카이스트의 풍토 덕분에--실제 회사에서 풀타임으로 일하면서 온 신경을 그것에만 집중하며 배울 때와는 많이 다르기 때문인 것도 있다. 아직 회사에서 일해보질 않았으니까. 게다가 나는 전문 학원을 다니면서 프로그래밍을 배운 것도 아니요, 알고리즘 문제 해결을 위한 공부를 별도로 진행했던 것도 아니라 순수하게 내 호기심과 내 필요를 충족시키기 위해 프로그래밍을 배워왔기 때문에 정말 내가 전문가의 수준에 도달했는지 안 했는지 객관적으로 판단할 근거가 없어 자신없는 부분도 있다. 학부 전공을 하면서 보다 체계적으로 배우면서 단순 호기심과 필요만으로는 채워지지 않은 빈구멍들을 많이 메꿀 수 있었지만 이게 충분한지는 실무에 부딪혀보기 전에는 모를 것 같다.

어쨌든 나한테는 새로운 언어와 개발환경을 익히는 것이 더이상 두렵지 않다. 내가 새로운 환경을 접할 때 더 많이 고려하는 것은 이것이 과연 나의 삽질을 줄여줄 수 있는가, 그리고 오랫동안 지속 가능한 티핑 포인트를 넘었는가, 설계가 개발자의 가능성과 역량을 제한하는 부분은 없는가 등이다. 물론 대부분 일장일단이 있기 때문에 단순 가치 비교는 힘들지만, 어쨌든 필요하다면 배워서 쓸 수는 있다는 것이다.

비주얼 베이직 하나를 깊게 팜으로써 결국 다른 객체지향 언어들을 보다 쉽게 익힐 수 있었고, 하나를 익힐 때마다 그 다음 것을 익히는 데에 걸리는 시간은 점점 줄어들었다. 마치 기존의 지식과 새 체계를 diff 뜨듯 학습한다고나 할까. 물론 단순 diff는 곤란하고 그 안에 내재된 본질을 알고 있어야만 진정 효과가 있을 것이겠지만.

이런 접근 방식은 프로그래밍 말고 중고등학교 시절의 학업에도 큰 영향을 끼쳐, 게임 중독에 가까울 만큼 판판이 놀아가며 학원이나 과외도 받아보지 않고 참고서도 본 경험이 없는 채로 초등학교를 졸업한 후 단 한 학기만에 공부 요령을 터득함으로써 학년이 오를수록 더 적은 시간과 노력을 투자하여 비슷하거나 더 나은 성적을 거두는 결과를 얻기도 하였다. (1학년 1학기 중간고사는 한달을 공부했지만, 3학년 2학기 기말고사는 딱 4일 공부했다. 하지만 결과는 동일하게 전교 10등이었다.)

자기만의 지식 재조직화 과정을 통해 본질을 이해한다면 그 어떤 종류의 학문이라도 초기 문턱만 넘는다면 훨씬 능률적으로 일할 수 있을 것이라 생각한다. 다만 개인적으로 한 가지 아쉬운 점은, 현재의 한국 공교육·사교육을 통틀어 이러한 지식 재조직화 능력을 길러주는 곳이 거의 없다는 것이다. 대학에서 프로그래밍을 처음 접하는 많은 학생들이 어려움을 겪는 이유도 이런 곳에 있는 것이 아닐까?

이 블로그에도 굉~장히 많이 늦었지만 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 자체에 대한 이슈가 여러 곳에서 조금씩 발목을 잡고 있음과 동시에 그래도 점점 나아지고 있다는 것도 느낄 수 있었다. 앞으로도 이 컨퍼런스가 잘 이어져서 웹의 발전이라는 두루뭉실하고 거창한 목표에 한 보탬이 되길 바란다. :)