태터툴즈 오픈하우스 때부터 태터캠프는 스웨덴 있을 때 한번인가 빼고 계속 스태프로 참여했는데(Needlworks니까 당연히 스태프-_-) 이번 태터캠프가 어떻게 보면 가장 준비를 안 했으면서 가장 성공한 케이스인 것 같기도 하다. 하긴, 생각해보면 대전에서 사전미팅을 했으니 나한텐 부담이 덜했기도 하고(...) 행사 준비 관련해서 다음·구글과 협의하는 건 재필님이 주로 수고해주셨으니 내 입장에서만(?) 별로 한 일이 없는 것일지도 모르겠다. ㅋㅋ

기존 태터캠프에서는 개발자트랙, 초보자트랙 등으로 세션을 나누거나 발표자 중심으로 세션을 나눴던 적은 있지만 이번처럼 BoF를 한 것은 처음이다. 얼마 전에 IBM DeveloperWorks 행사로 열린 개발자들의 수다에서 발표 세션 끝나고 BoF가 이어지면서 사람들과 한 시간 정도 이런저런 이야기를 나누고 그 내용을 서로 공유하는 시간이 맘에 들어 이번 태터캠프에도 그렇게 하자고 제의했고 결과적으로 성공한 것 같다. 시간이 부족하여 서로 이야기한 내용을 정리·공유하는 것까지 하지 못한 것은 조금 아쉽지만 대신 후기들이 잘 정리하고 있으므로 괜찮을 듯. =3=3 사실은 발표자들을 일찍 모집해서 페차쿠차 형식을 써보려고 했지만 준비 기간이 부족하여 그건 다음으로(?!) 미루었다.

발표 내용은 어떻게 보면 이미 다 알고 있는(?) 것이기도 했지만 몇 가지 기억에 남는 것을 뽑아보았다.

• 메타블로그 : 블로그 = 블로그 : 마이크로블로그
• Bank vs. Banking & Blog vs. Blogging - 은행 자체는 합병되고 파생상품으로 형태가 바뀌어가지만 은행이 하는 근본적인 일에 대한 수요와 정의는 여전히 동일하다. 블로그도 그 형태는 변할지언정 블로깅이라는 행위의 본질은 계속될 것이다.
• 사람들이 블로그를 "어렵다"라고 말하는 것은 사용자 인터페이스뿐만 아니라 정제되고 불특정 다수가 읽을 수 있는 글을 써야 한다는 사실에 대한 부담감을 포함해 여러 요소가 복합적으로 작용한 것이다.
• 티스토리에서 지역태그 대충(?) 적어도 실제 장소와 잘 매치되게 하겠다¹
• 스킨 공개 구매 - 스킨디자이너 생태계 유지를 위한 투입
• VA250 - 여러 채널을 통해 최적화된 광고 게재로, 블로그에 광고를 올리는 것 말고도 블로그를 광고할 수 있다.

뒷풀이에서 나왔던 얘기 중에 깔대기 이론(...)에 따른 연애 관련 이야기를 제외하고,

• 태터캠프가 벌써 7회라니...
• subversion 저장소를 mercurial로 이전할까요?
• 2차로 갔던 세븐몽키즈 카페에 있던 윈도7(!)이 깔린 노트북이 감명깊었다(?) ;;;
• 아이폰 빨리 나왔음 좋겠다 -> KT 사내 공지에 떴다는 떡밥(?)이 있더라 -> 근데 돈 없다 -> 나는 총알 장전 중

정도가 일단 기억이 난다. (더 적으려고 했던 게 있는데 피곤해서 그런지 글쓰다가 까먹었음 orz)

사실, BoF 주제가 워낙 없어서(...) 주제 목록의 절반은 내가 만들었다는 사실을 아는지 모르겠다. (...) 위치기반·모바일 서비스 쪽도 내가 제안한 주제였고 구글맵 플러그인을 만든 경력이 있기 때문에 이쪽에 참여했다.

특히 storyish.com이라는 서비스를 만드신 분이 내가 구글맵 플러그인을 통해 구현하려고 구상하던 것과 비슷한 생각을 많이 하고 계셔서 재미있었다. 삼성전자에서 휴대전화 관련 임베디드 개발하신다는 분한테는 웹브라우저 탑재하게 되면 꼭 Geolocation API 같은 공개 표준을 도입해달라고 부탁(?)을 드렸고, 다른 분들과는 모바일에 위치기반 서비스가 결합하면 어떤 것들이 가능해질지에 대한 이야기를 나눌 수 있었다. 국내에서는 이통사들의 주도권 문제, 제도적 문제 등으로 아직 어려운 것 같다는 의견도 있었고, 2~3년 지나면 많이 활성화되지 않을까 하는 이야기도 나왔다. 별도로 뒷풀이 때는 위치기반 서비스가 (텍스트큐브 입장에서) pain killer라기보다는 vitamin 같은 존재라서 핵심 주력으로 자라날 수 있을까 하는 이야기도 있었다.

하나 기억에 남는 건, 중학교 1학년 학생을 데리고 오신 부모님(!)이었다.;;; 부모님 두 분은 행사 끝까지 계셨는지 잘 모르겠으나 그 학생은 끝까지 있었던 것 같은데, 장차 프로그래머가 되어 구글에서 일하는 게 꿈이라는 그 친구에게 진로 상담(...)을 부탁하셨다. 길게 이야기할 수는 없었는데, 중학교 때는 학과공부에 소홀하지 않는 게 좋고 특히 영어와 수학에 대한 기초를 단단히 다져놓는게 중요하다는 점과 함께, IT 기업마다 인재를 뽑는 성향이 많이 다르며 구글은 면접 때 알고리즘 문제를 잘 푸는 것이 중요하기 때문에 경시대회 쪽 감각을 가지고 있는 게 좋을 것이라는 정도만 말씀드렸다. 하지만 동시에 본인이 좋아하는 공부를 하게 하고 무엇이든지 억지로 시키려고 하지 않으면 더 좋겠다는 이야기도 해드렸다.

Icebreaking 때 대학원에 계신 몇몇 분들이 교수님 몰래 온 것이라며 정체를 숨기는(...) 경우를 보았는데, 나도 내년에 대학원 가게 되면 저래야 될까 싶다. -_-;; 대학원생이라고 해도 정말 100% 자신의 시간을 연구에만 투자해야 하는 것일까? 뭐 대학원 특성상 교수님에게 많은 부분이 달려있으니 교수님 성향에 따라 다르겠지만 역시 종속성이 생기는 건 어쩔 수 없는 듯하다. 어쨌든 사람들이 꽤 많았음에도 끝까지 지루하지 않았던 이번 icebreaking은 역대 태터캠프 중 가장 재밌었던 것 같다.

아무튼 이번 태터캠프는 여러 모로 기억에 남는다. BoF가 잘 될지 상당히 긴장했었는데(원래는 각 주제마다 좌장을 정해서 진행시키려고도 했는데 어정쩡해서 그냥 했다-_-) 대충 다들 만족하신 분위기라서 다행이다.;; 다음 태터캠프 때는 api.textcube.org도 제대로 발표할 수 있을 듯.

회사에서 비록 업무시간이었지만 인터넷 동영상 중계를 통해 티맥스 윈도(Tmax Window) 발표회를 지켜보았다. 오피스와 스카우터 부분은 사내 세미나 때문에 못 봤지만 다른 분들 얘기를 통해 어떤 식으로 진행되었는지 알 수 있었다.

우선 무엇이 되었건 운영체제를 만들겠다고 하는 도전에 대해선 박수를 보낸다. (더군다나 Microsoft Windows 호환이라니.) 전산학을 전공하는 학생으로서, 또한 모의 학습용이긴 하지만 운영체제를 부분적으로나마 실제 구현해본 사람으로서 그것이 얼마나 어렵고 방대한 일인지 잘 알기에 도전 자체는 정말 힘든 결정이었으리라 생각한다.

하지만 아쉬운 점들도 있다. 많은 사람들이 지적한 것처럼 오피스와 웹브라우저인 스카우터의 경우 각각 오픈오피스와 웹킷이라는 오픈소스 프로젝트를 바탕으로 만들어진 것이다. 구글에서 크롬을 내놓을 때도, 애플에서 사파리를 내놓을 때도 웹킷을 사용했다는 것은 분명히 밝혀 왔고 오픈오피스 기반의 스타오피스와 같은 상용 프로그램들도 자신들이 그러한 오픈소스를 어떻게 사용했다는 것에 대해선 떳떳하고 분명하게 밝히고 있다. 티맥스의 경우 별도의 기자간담회 등을 통해 이런 사실들이 흘러나오고 있는 정도이다.

사실 TNF 활동을 하면서 대외적으로 사람들을 만나러 다닐 때마다 오픈소스 커뮤니티인 TNF를 마치 회사인 것처럼 오해하는 경우가 많았던 점에 비추어 볼 때, 일반인 대상의 시연 행사에서 오픈소스에 대해 쉽게 이야기하기는 힘들었으리라 생각한다. (그런 점에서 어떤 분들은 텍스트큐브 프로젝트가 이렇게 발전한 것은 우리나라의 오픈소스 인식을 고려했을 때 대단한 일이라고 이야기하기도 한다) 아직 오픈소스에 대해 제대로 이해하고 있는 사람이 많지 않은 상황이기 때문에 어쩌면 더 불리한 요소로 작용할 것이라고 판단했을지도 모르겠다. 하지만 시연행사는 그렇다치더라도 공식적인 채널을 통해 이런 이야기가 없다는 점은 다소 실망스럽다.

한편 지금 현재 티맥스윈도 자체의 완성도가 낮은 부분은 충분히 이해된다. 사람들은 마소도 맨날 최적화하느라 난리인데 지금 이 정도 가지고 뭐해먹겠냐는 식으로 이야기하지만, 윈도우 API를 깊이있게 써봤거나 직접 운영체제 커널 프로그래밍을 해본 사람이라면 지금 이 정도 수준만 되어도 감격할 만한 것이다. 짧은 기간에 그만큼이라도 하기 위해서 얼마나 고생했을지 정말 눈물이 앞을 다 가린다. 만에 하나, 윈도우 API/OS 클론 오픈소스 프로젝트인 Wine이나 ReactOS와 관련된 라이선스 분쟁이 발생하지 않기를 바랄 뿐이다. 모두가 예상했던 대로 하드웨어 드라이버 문제는 역시 가장 큰 걸림돌이었던 모양이고 동시에 앞으로도 당분간은 그럴 것 같지만, 티맥스가 뚝심있게 밀고 나간다면 차차 해결되리라 생각된다.

다만, 윤석찬 님이 블로그에서 지적하신 것처럼 힘든 개발 과정에서 연구원들 일부가 이혼을 당하기도 하는 등 굉장히 고생했다는 이야기를 오히려 너무나 떳떳하고 애국심이 넘친 훌륭한 행동인 것처럼 묘사한 것은 잘못되었다고 생한다. 마치 예전에 황우석이 월화수목금금금을 이야기하던 상황을 떠올리게 한다. 연구자, 기술자들이라고 해서 자기 자신과 가정을 돌보고 싶은 욕구가 없겠는가? 그리고 그런 욕구를 억누르고 어떤 한 프로젝트에 애국심으로 무한 헌신하는 것이 과연 지금과 같은 다양성과 개방의 시대에 국수주의적 영웅으로 인정받을 수 있겠는가? 물론 본인들이 원해서 그렇게 했다면 그 사실 자체는 문제 없지만, 그것을 떠나서 회사의 공식적인 입장에서 대외적으로 그렇게 이야기한다는 건 아직 공과 사를 잘 구분하지 못하는 한국 사회의 치부를 보여주는 것이나 다름없는 것이다.

어쨌든 이 모든 논란과 티맥스의 부적절한 커뮤니케이션 방식에도 불구하고, 정식으로 출시된다면 순수하게 개발자의 호기심으로 한번쯤은 써보고 싶다. 하지만... 정말 국산기술로 OS 보유한다는 것 말고 굳이 엄청난 투자를 해가며 운영체제를 만든 비즈니스적 이유는 무엇일까?

지난 월요일, 전산학과의 석사세미나 과목에서 김명호 교수님의 초대로 고려대 법대 김기창 교수님의 강연이 있었다. 마침 요 근래에 오픈웹 관련하여 동아리 메일링에서 3~4일에 걸쳐 160여개 이상의 메일이 오가는 등 매우 많은 논란이 오고가기도 했고, 개인적으로도 소송 원고인단에 참여를 고려해봤을 정도로(못했던 이유는 당시 나이가 안 돼서) 관심을 가지고 있는 주제였기에 안 갈 수가 없었다. 게다가 다행히 수업도 없었고 말이다. :)

강연 제목은 "Code v. Code"였다. 처음에는 법률가로서 law code를 보는 사람인 자신과 전산학도로서 source code를 보는 학생들과의 이야기를 함께 풀어보자로 시작해서 오픈웹을 통해 자신이 느꼈던 바를 정리하고, 한편으론 이 주제에 대해 잘 모르는 학생들을 위해 오픈웹에 대해 일부 설득하는 정도의 내용으로 마무리되었다.

우선 강연 내용을 요약하면 아래와 같다. (일부 빠진 내용이 있을 수 있음.)

강연 내용

• 법률가와 소프트웨어 개발자들
  • 기술 <-> 방법 <-> 법률
• 플러그인
  • 플러그인은 A라는 프로그램 맥락에서 B라는 프로그램을 실행·제어하기 위한 바구니이다.
  • 현재 국내 인터넷뱅킹에서는 SSL/TLS 보안접속도 플러그인을 통해 이루어지고 있다.
• 오픈웹
  • 플러그인을 여러 환경에 맞게 다 만들 것이냐 vs 플러그인을 아예 뺄 것인가
  • 오픈웹을 통해 여러 환경에 다 맞게 만들자고 하면 보안업체들은 좋아할 것이다. (그거 장사하는 거니까) 그래서 패소한 것이 오히려 그들의 밥그릇을 뺏어간 것 같다. (일부러 반어적 표현을 쓰신 듯.)
• cost of plugins
  • 사용자 지원 복잡
  • 보안 위험 : 무조건 '예'
  • 서비스 제공자가 접근권을 장악
  • 웹브라우저 업그레이드 못한다
• 플러그인 없으면.
  • (위의 목록과 반대)
  • 인터넷을 플랫폼으로 사용하자
  • 플러그인 기술은 이미 버려졌어야 할 옛날 기술이다.
• 앞으로 학생들이 이러한 관점에서 소프트웨어를 설계했으면 좋겠다는 의미에서 방문한 것.

사실 강연 자체는 워낙 잘 알고 있던 내용이라 별로 인상적인 느낌은 받지 못했다. (물론 내가 강연 내용에 100% 다 동의하는 것만은 아니다.) 다만 온라인으로 쓰여진 글만 보다가 직접 김기창 교수님을 보니 상당히 서민적이고(?) 재밌는 분이라고 느껴졌다.

사실 30분 정도로 짤막하게 끝난 강연시간만큼이나 길게 질의응답이 이어졌는데 진짜 중요한 내용은 여기에 더 많이 나온 것 같다. 내 질문을 포함하여 다른 사람들과 나눈 질의응답까지 모아 정리해보았다.

질의응답

• 보안업체(플러그인 공급자)에 의해 접근이 결정된다는 부분에 대해 -> 보안사고에 대한 책임을 모두 은행에 전가하는 현재의 상황으로 볼때 사회적·문화적 합의 내지는 인터넷 뱅킹의 계약 요소로 보아야 한다는 관점도 있는데 어떻게 생각하시는지? 또한 근본적으로 강제 의무를 없애면, 알아서 적절한 기술을 택하게 될 것이라는 의견도 있었다.

  • 우선 현재의 환경은 기본적으로 많이 변해서, 웹표준이나 접근성 중심으로 많이 기울어있는데, 그렇지 못한 마지막 보루가 전자금융 분야이다. 이는 법률가들의 잘못도 있다고 생각한다. (많은 사람이 안심하고 이용하게 하려면 서비스 제공자에게 모든 책임을 물어야 한다고 생각했던..) 따라서 그런 규정은 개정되어야 한다.
  • 하지만 현재의 법 규정 내에서도 사용자의 위험부담 동의 하에 충분히 설치 강제를 하지 않아도 되지만 은행들이 이것을 사용·허용하지 않고 있다. 즉, 선택권을 주지 않는다. (그리고 지금의 보안도 완벽한 게 아니다. 지금은 오히려 지금 상황에서는 그렇게 복잡한 보안장치를 걸면서도 결국 은행이 책임을 져야 하므로 은행이 불리하다고 볼 수도 있다.) 지금도 어느 정도 충분히 개선 가능하다.
  • 앞으로는 PC의 인터넷뱅킹뿐만 아니라 모바일도 중요하다. 근데... 이미 국내 몇몇 은행들은 뱅킹칩 없이 모바일뱅킹하는 솔루션까지 만들고 있다.;; 게다가 이 솔루션들은 국내 이동통신망에 매우 종속적이다. 모바일 시장에서도 똑같이 되지 않도록 노력해야 한다.
  • 국내의 훌륭한 브로드밴드 환경을 플러그인 배포가 아닌 web 2.0 / RIA에 사용할 수 있도록 해야 한다.

• 우리나라 미디어에서 인터넷 뱅킹 관련 문제를 다루는 태도가 어떻다고 생각하시는지?

  • 한국에서 아직까지 적응하지 못한 것이 컴퓨팅 리소스에 대한 접근 개념. 단지 속도 빠른 컴퓨터면 되고, 이에 대한 담론 자체가 아직 향상되지 않은 것 같다.
  • 컴퓨터·IT 전문 기자들 조차도 충분한 역량이 없다.
  • 웹표준을 이용해 제대로 된 컴퓨팅 지식을 가지고 글로벌한 장사를 할 생각을 해야 한다. 우리 학생들이 그런 일을 해야 하지 않겠나.

• 컴퓨팅 리소스를 제대로 사용하게 하려면 진입장벽이 높아지는데 컴퓨터 사용자 교육에 대한 측면?

  • 기술자들이 https+otp로 바꾸는 것에 대한 막연한 두려움을 가지는 것 같다.
  • 고객에게 교육하는 것은 그리 어려운 문제는 아닌 것 같다. (윈도우 업데이트를 제때 하는 것, 윈도 사용자라면 본격 안티바이러스 소프트웨어를 써라, 비밀번호 입력할 때 주소창 확인하기)
  • 클라이언트 해킹에 의한 보안사고 발생했을 때는 사용자가 책임질 수밖에 없다. 어차피 지금 방식이나 오픈웹이 제안하는 방식도 이 점은 마찬가지.

• 이러한 교육이 강조되면 정보접근권 격차가 벌어지지 않을까?

  • 일단 플러그인 방식은 안전보다는 편리 때문에 선택된 점이 많다. 또한 '컴맹 고객을 위한다'라는 명제 때문에 보안을 많이 compromise했다.
  • 보안 접속을 위한 https는 별도 설치가 필요 없으므로 오히려 간단하다.
  • 클라이언트 보안을 위한 우리나라 방식의 근본적인 문제점 : '사용자는 바보이기 때문에 우리가 하라는 대로 하면 보안 지켜주겠다'라는 접근 자체의 잘못되었다. 기술적으로도 허점이 많다. 결국 사회적 문제, 교육의 문제이다.

• 전자서명이 꼭 필요한가?

  • 거래내역을 담은 form에 서명하는 것은 플러그인으로 구현할 수밖에 없는데 이것이 꼭 필요한가 하는 질문이라고 다시 요약.
  • 전자서명제도 자체는 대부분의 나라에 존재. (이러이러한 요건을 갖춘 전자서명은 종이나 다른 매체를 통한 서명과 같은 효력을 가진다는 의미에서.)
  • 그러나 우리나라에만 있는 것은 법 아래에 있는 전자금융감독규정에 모든 전자거래에 공인인증서를 요구하는 규정이다. 이것을 사용할지 말지는 원래 선택적이어야 하나 우리나라에서만 강제하고 있다.
  • 강제한 이유는 그런 플러그인을 만들어 파는 시장이 활성화되기 때문으로 본다. 자신은 이것이 필수라고 생각하지 않고 선택적이어야 한다고 보며, 궁극적으로는 부인 방지를 판사가 믿어줄 거냐 아니냐의 문제기 때문에 기술보다는 법률 이슈이다. 전자서명도 결국 개인키와 그 비밀번호가 유출되면 소용이 없다.
  • 즉, 공인인증서 사용 여부는 자율에 맡겨야 한다.

시간 관계 상 학과사무실 문닫기 전에 싸인을 하고 가야 한다고 해서(...) 여기까지만 하고 끝마칠 수밖에 없었는데 몇몇 학생들과 따로 교수님이 떠나시기 전에 추가 질의응답을 할 기회를 얻을 수 있었다.

• 최근 들어 보안업체를 공격하는 글들이 많이 올라와 오픈웹에 등을 돌리는 사람들이 나타나기도 했는데 이런 점에 대해선 앞으로 어떻게 하실 생각인가요?
  • 의도적인 부분도 있었음. (자기도 욕 먹을 걸 어느 정도 예상했음)
  • 패소했다고 이렇게 나온다는 시선을 피하기 위해 소송 결과가 나오기 전부터 보다 강력하게 나오기 시작했음.
  • 비록 비판받고 있긴 하지만 이로 인해 논의 자체가 한단계 더 발전하고 더 많은 사람이 관심을 갖게 되었다는 점에서 긍정적으로 평가.
  • 앞으로도 보안에 대한 기본 전제의 인식 변화를 위해 보안업체에 대한 공격은 계속 이어질 예정.

결국, 웹상에서 상당히 독설을 내뿜고 계시는 것에 비해, 실제로 가지고 계신 생각은 내가 하는 것과 많은 부분 비슷하다는 것을 알 수 있었다. 기술적인 부분보다는 제도적 보완이나 인식 변화가 더 필요하다고 생각하고 계셨고, 다만 보안업체들을 대놓고 공격하거나 SSL+OTP 등에 대해 그렇게 강하게 주장하는 것은 그래야 사람들이 더 나은 대안을 찾기 위해 문제에 대한 인식을 시작할 수 있기 때문이라는 것이다.

최근 논란의 가장 중심에 서계신 분을 직접 앞에 놓고 이야기를 듣고 질의응답을 할 기회였기에 소중한 경험이 되었다. (석사 간 내 이전 룸메 친구는 오랜만의 한국어 강연이라서 좋았다고...ㅋㅋ) 아무튼 인터넷뱅킹에 대해 모두가 어떤 식으로든 문제 의식을 가지고 있는 만큼, 조금씩이나마 나아지길 기대해본다. 김기창 교수님과 같은 분의 노력이 빛을 발할 수 있도록. :)

오픈웹이 금융결제원을 상대로 낸 소송 2심에서 패소하면서 한동안 오픈웹 사이트가 닫히고 다음과 같은 화면이 떴었다. 그러다가 다시 사이트가 열리고 열띤 토론이 오가더니 어느 순간 DDoS 공격을 당하여 사이트가 닫히고 구글 그룹스로 대체된 상태이다.

한동안 오픈웹 사이트를 대체했던 Closed Web 광고(?)

이 과정에서, 내가 속한 SPARCS 동아리 메일링으로도 여러 선배님들이 사상 초유의 엄청난 토론을 벌였다. 불과 3~4일 사이에 메일 쓰레드가 160개 가까이 나올 만큼 뜨겁게 달아올랐는데, 다양한 의견들을 볼 수 있었다.

그 중에서 몇 가지 주요 줄기(?)만 뽑아 '내맘대로' 정리해보면,

• '사용자는 바보다'라는 가정을 하면, client PC의 보안을 확신할 수 없고 사회·문화적으로 보안 사고의 책임을 모두 은행에게 전가하는 상황에서 (매우 더럽든 어쨌든) 지금 같은 ActiveX 보안프로그램을 사용할수밖에 없다.
  • 그렇다면 사용자가 스스로 보안을 잘 지키도록(윈도 관리자 계정을 가급적 사용하지 않게 하고 업데이트를 주기적으로 실시하며 백신 프로그램 등을 사용하게) 계몽·교육해야 하는가, 아니면 지금처럼 계속 은행 입장에서 보안을 제공해야 하는가.
    • 근본적으로 보안사고의 책임 소재에 대한 범위에 대해 사회적 합의가 먼저 있어야 한다.
    • 그런 합의가 가능할까? 어떻게 해야 실현할 수 있을까?
  • 은행사이트를 열었을 때만 동작하는 보안프로그램이 어떤 의미가 있는가?
    • 일부는 기본값은 아니지만 옵션에 따라 항상 동작하게 할 수도 있다.
  • 인터넷 사용자들이 과연 인터넷에 대해 얼마나 알고 사용하는가. 공교육 차원에서 컴퓨터 교육이 보다 체계화·강화되어야 한다.
  • 한국사용자가 고분고분한 편이다. 해외에서 한국처럼 IE 버전 바뀔 때마다 이 난리 났으면 은행 커스터머 라인 마비된다.
• 문제의 요지는 ActiveX 기술을 쓴다는 사실이 아니라 보안프로그램의 강제 여부이다. ActiveX는 다만 Windows+IE 플랫폼에서 native browser addon을 개발/배포하기 가장 편하기 때문에 선택되었을 뿐.
  • 키보드 보안이나 방화벽 등 인터넷뱅킹시 사용되는 보안프로그램이 성능이 그리 뛰어나다고 하지 못할지라도, 조금이나마 크래커들을 더 귀찮게 하고 조금이나마 보안을 향상시킬 수 있다면, 은행이나 보안업계 측에서는 사용할 수밖에 없다.
  • 강제해야 한다면, 최소한 공개 플랫폼인 Linux + Firefox 환경에서 동작하는 보안프로그램이 나와야 하지 않겠는가.
    • Linux에서 root 권한 주고 소스도 모르고 믿기도 힘든 프로그램을 누가 깔겠나. 오픈소스라면 몰라도.
    • 보안프로그램 특성상 관리자 권한으로 동작하는 것은 어쩔 수 없음.
    • 사용자 편의성과 보안은 원래 함께 만족시키는 것이 어렵다.
  • 사용자 책임 하에 opt-out 할 수 있게 해야 한다.
    • 결국 이에 대한 명확한 계약 조건 명시 또는 사회적 합의 필요.
• SSL+OTP를 대안으로 사용하면 되지 않겠는가.
  • SSL이나 OTP도 만능은 아니다. (MITM 취약점 등)
    • Client PC 보안이 지켜진다면 괜찮지 않겠는가. 또 보안씰처럼 사용자가 오프라인 상에서 직접 만든 이미지를 제시한다든지, 마우스를 이용해 비밀번호를 입력하는 방법 등등 여러 장치를 통한 대안이 있을 수 있다.
  • 또다른 방법으로는 보안프로그램의 제공 수준에 따라 거래한도를 다르게 하는 것도 좋을 듯.
    • 해외와 달리(?) 국내 사용자들은 인터넷뱅킹에서 모든 것을 오프라인과 동일한 수준으로 하길 원하는 것 같다.
  • '나'는 지금같이 불편하지만 보안이 높은 인터넷뱅킹을 더 선호한다.
• 다수를 위해 소수가 반드시 희생해야 할 필요는 없다. 모두가 만족할 수 있는 방향을 찾을 수 있다면 그것을 적용하는 것이 좋다.
  • Firefox 사용자는 숫적으로는 열세라도 이미 여러 대안을 선택할 수 있는 '강자' 아닌가.
    • 누구나 다 비싼 정품 Windows를 구입해야 하는가.
    • 앞으로 모바일 디바이스에서도 웹을 많이 쓰게 될 텐데, 그런 환경에 대한 대비도 미리 해야 되지 않겠나.
    • (해외에 계신 분 말씀) 아시아권에서는 소수가 다수를 위해 참는 것을 화합으로 인정하는 것 같지만 서구에서의 harmony와는 다른 뜻이다.
• 인터넷뱅킹 서비스가 과연 공공재인가? 결국 창구 운영 비용보다 싸기 때문에 채택하는 것이 아닌가. 결국 모든 것은 시장논리에 의해 자연스럽게 선택될 것이다. 전자정부라면 이런 논의가 유효하지만 인터넷뱅킹은 글쎄.
  • 만약 공공재로 본다면, 관련 비용은 누가 지출해야 하나. 국가에서 해준다면 좋겠지만 가능성은?
• 지금처럼 보안프로그램을 강제하면서 프로그램 설치에 대한 보안경고창에 항상 '예'를 누르도록 강요하는 것은 사용자 보안을 약화시키는 결과를 가져온다.
  • 하지만 Firefox 다운로드 페이지를 봐도 그렇고 결국 다 마찬가지 아닌가.
    • 사용자가 해당 프로그램이 무엇을 하는 것인지 정확히 알게 하는 것이 중요하다.
• 문화적으로 보면,
  • 아직 계약에 대한 인식이 부족해서 사용자와 은행의 책임을 명확히 구분하지 못하고 있다.
  • 해외(특히 미국)의 경우 one-source multi-use가 매우 중요해졌고 이것이 실제 돈과도 연결되기 때문에 인터넷뱅킹 서비스도 여러 플랫폼을 지원하는 것이 당연하게 여겨지고 있다. 아직 한국에서는 그 정도까지 인식이 되지 않고 있어서 그런 게 아닐까.
  • 온라인은 단지 오프라인의 거울일 뿐. 아직도 폐쇄적인 문화이지 않은가.

이 외에도 몇 가지 줄기가 더 있지만 논의에 관련된 핵심적인 것들만 뽑아보니 대충 이 정도쯤 되는 것 같다.

내가 보기엔, 결국은 양쪽 다 맞는 소리다. 공공재적 성격을 띠는 인터넷 뱅킹과 온라인 결제 시스템이 가능하면 접근성이 높아야 하고 그렇게 하기 위해 공개 표준을 이용하는 대안들이 존재한다. 하지만 보안을 하는 사람들 입장에서는 기술적으로 '최대한'의 보안을 확보해야 하고, 사회적으로 책임소재임을 요구받는 은행이 주문한 대로 만들 수밖에 없다는 입장인데 이 역시 맞는 이야기다.

다행스러운 것은, 행정안전부에서 주최하는 회의에서 강제 여부를 해제하는 쪽으로 합의가 도출되었다는 점이다. 나도 기술적으로 지금과 같이 무겁고 불편하고 가끔 오류도 내는 보안프로그램들이 어쨌든 0.01g이라도 더 나은 보안을 위해서 필요하다면 어쩔 수 없다고 보지만, 사용자가 원한다면 은행측이 제공하는 보안프로그램을 사용하지 않을 수 있는 선택권과 접근성은 필요하다고 생각하기 때문이다.

다만 아쉬운 점은 오픈웹 쪽에서 그동안의 지리한 소송과 말이 안 통하는 상대들을 대상으로 이러한 주장을 해온 것 때문인지 나같이 오픈웹 관점을 지지하는 사람이나 보안업계 사람이나 어느 쪽에서 봐도 다소 거부감이 드는 발언들이 많이 나오고 있다는 점이다. 사람이기에 지치고 힘든 건 이해하지만 감정적으로 휘말리지 않고 생산적인 논의가 계속될 수 있었으면 좋겠다. 뭔가 '말'로는(literally) 다 맞는 얘기인데 미묘하게 글 중에 감정이 보이는 것이 아쉽다. 나만의 착각이길 바랄 뿐.

추가: 이 사태에 관해서 김국현씨가 아주 일목요연하게 논점을 잘 정리해주셨다. 이 글은 두고두고 기억해야 할 것이다.

네트워크 프로젝트 때문에 바쁘고 시험기간이고 책 써야 하고 어쩌구 저쩌구 해도 볼 건 다 보고 있다. ㅋㅋ

기본적으로 웹에 무언가를 올리면 링크의 대상이 된다는 원칙에는 동의하는데, 이 문제는 좀더 다른 시각에서도 바라볼 필요가 있는 것 같다. 우선 웹을 사용하는 사람들이 폭발적으로 늘어났기 때문에 웹을 정말 '웹'으로 사용하지 않는 경우도 있을 수 있고, 인터넷 상의 누군가가 내 글을 봐주길 바라면서도 동시에 갑자기 수십만명이 몰려와 글을 읽는다는 사실에 대해 부담을 느끼는 사람들이 생기는 것도 당연하다. (임의의 누군가를 고려하는 것하고 임의의 수십만명을 고려하는 것하고는 아무래도 다르지 않은가.)

텍스트큐브 프로젝트를 하면서 느끼는 거지만 사용자들은 정말 다양한 용도로 툴을 사용하고, 소통이 근본 원칙이자 어떻게 보면 그게 정체성이라고도 할 수 있는 블로그툴을 사용하면서도 매우 개인적인 공간을 꾸미길 원하는 경우도 많이 봤다. (사실 개인 데스크탑PC에 로컬로 설치할 수 있는--그러니까 혼자만 쓸 수 있는--블로그나 위키에 대한 수요가 꽤 있는 것 같다) 지금의 웹이 탄생하기까지 인류가 겪어온 수많은 철학적 고민과 기술적 고민들에 대해서 대부분의 사람들은 별다른 관심도 없고 알지도 못한다. 그저 자기 원하는 거 잘 돌아가면 장땡인 것이다.

블로거들 중에는 "내 글이 좀 알려지고 많이 읽히면 좋겠다"라는 막연한 기대와 동시에 "갑작스레 너무 많은 사람(수십만명 이상)이 들어와서 읽는 건 부담돼서--트래픽 때문에 먹통되어서일수도 있고 단지 개인적인 이야기가 불특정 다수한테 노출되는 것이 싫어서일수도 있고 내가 그만큼 널리 읽힐 만한 퀄리티의 글을 썼는지 확신이 서지 않아 부끄러워서일수도 있고--싫어"라는 입장을 가지는 경우가 있을 것이다. 나는 그런 사람들을 비난할 수 있다고 생각하지는 않는다.

이런 부분에서는 개인적으로는 미리야님이 제안하신 대로 네이버 쪽에서 오픈캐스트에 링크되길 거부하는 블로거들이 스스로 거부 의사를 표현하면 캐스터가 링크걸려고 할 때 경고메시지를 띄워주는 정도의 기능을 제공하는 것이 좋을 것 같고, 동시에 링크에 대해서 웹사용자 모두가 좀더 정확히 이해할 수 있는 계기로 삼아 문화적으로 보다 많은 사람들이 웹의 특성을 이해하면서 쓰게 되기를 바란다.

한편, 기술적으로도 해결해야 할 문제들이 있다. 티스토리나 이글루스 같은 서비스형 블로그를 쓰는 사람이라면 그렇게 트래픽 폭탄을 맞아도 악성댓글이 많이 달릴 수 있다는 가능성을 제외하곤 사실 별다른 손해(?)는 없는데, 나처럼 개인 서버를 운영하는 사람이나 호스팅을 쓰는 경우는 트래픽에 민감할 수밖에 없다. 물론 http referer로 차단한다든지 robots.txt를 이용한다든지 하는 기술적 조치 방법들이 있지만, 나같이 웹기술에 대해 어느 정도 잘 아는 사람이나 써먹지 대다수의 사람들에겐 저렇게 이야기해줘도 무슨 소리인지 모를 것이다. (그리고 사실 그런 기술을 잘 안다고 해도 어지간하면 귀찮아서 냅두는 경우도 많을 것이다.)

그런 면에서, 지금은 전문가들만 사용할 수 있는 Amazon EC2나 Google AppEngine과 같은 scalable hosting 서비스들이 일반 웹호스팅을 사용하듯 쉽게 사용할 수 있게 되어야 할 것이다. 사용법은 지금의 웹호스팅과 똑같으면서 가상화 기술을 사용하여 동적으로 트래픽에 대응하고, 요금은 후불제이되 매우 저렴하여 거의 부담을 느끼지 않을 수준이 된다면 '내 글을 누군가 많이 읽어주었으면 좋겠다'와 동시에 '한꺼번에 수십만명이 몰려오면 쥐쥐인데'하는 모순점을 해결할 수 있을 것이다.

포탈사이트 중심의 웹 구조로 인해 포탈 메인에 링크가 걸리는 순간 예측 불가능한 트래픽 폭탄을 맞게 되는 것은 사실 아무리 자기 글이 널리 알려지길 바라는 사람이라도 당황스럽지 않을 수 없다. 그걸 기분좋게 받아들일지 기분나쁘게 받아들일지는 각자의 판단에 따라 다른 것이다. 다만 기술적으로도 지금 당장은 부담될 수밖에 없고, 문화적으로도 모든 웹사용자들이 링크의 용도나 범위에 대해 사회적 합의를 가지고 있지 않기 때문에 문제가 되는 것이다. 이런 부분들을 어떻게 개선할 수 있을지 차근차근 돌이켜보는 것이 필요하지 않을까.

ps. 사실 텍스트큐브 개발에 참여했지만 텍스트큐브를 가지고 정말 상상을 초월하는 용법(?)을 보여주는 몇몇 사례를 보면서 팀버너스리가 이런 논란이 나올 것을 예상하고 하이퍼텍스트를 만들지는 않았을 것 같다는 생각이 든다. ㅋㅋ

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

Dreaming in Code

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

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

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

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

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

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

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

지난 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 맥락에 따라 적절하게 핸들러를 골라서 보여주는(그리고 그 핸들러는 플러그인으로도 정의될 수 있는) 방법인데 역시 문제는 표준화일 것이다.

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

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

이 블로그에도 굉~장히 많이 늦었지만 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 재설치 작업으로 인해 오늘 혹은 내일 중으로 몇 시간 정도 접속이 안 될 수 있습니다. 이런 작업을 처음 해보는 거라서 정확히 얼마가 걸린다고 얘기해드리지는 못하겠군요.;; 최대한 빨리 끝낼 수 있도록 하겠습니다.