게임 깎는 욕쟁이 김노인

EC2로 인터넷 뱅킹을 써봤습니다.

Fri, 17 May 2013 23:14:00 +0900

낮에 심심하게 빈둥거리다가 문득 EC2 인스턴스에 접속해 인터넷 뱅킹을 쓸 수 있지 않을까 하는 생각이 들었습니다. 지금도 인터넷 뱅킹을 쓰기 이한 윈도우 돌아가는 기계가 있긴 한데 이게 영 불편합니다. 사실 맥에서 VM을 통해 처리하면 되는 문제인데 혹시 EC2에서 인터넷 뱅킹을 할 수 있다면 VM이나 윈도우 돌아가는 기계를 없애버릴 수도 있지 않을까 하는 생각도 잠깐 들었습니다. (당연히 VM이나 윈도우 돌아가는 기계가 1억배쯤 효율적일테지만)

그래서 .. 해봤습니다. EC2 마이크로인스턴스에 윈도우 서버 2012를 돌렸습니다. 우분투 EBS가 10기가면 되는데 비해 윈도우는 30기가짜리 EBS가 필요합니다. 부팅 시간은 우분투 서버에 비해 서너배쯤 더 오래 걸립니다. 마이크로인스턴스는 시간당 $0.02로 무섭게 싸지만 메모리는 613메가밖에 안됩니다. 접속해보니 시작버튼도 없고 - 윈도우 서버에도 시작버튼이 없다는걸 오늘 처음 알았습니다. - 화면 구석에는 우울한 사양이 나열 되어 있었습니다.

오늘의 목표는 은행에 공인인증서로 로그인한 다음 계좌를 조회하는 것입니다. 그리고 기왕에 바보 삽질을 해보는 김에 AWS 인프라에서 상상할 수 있는 방법 중 가장 안전하다고 생각되는 방법으로 공인인증서를 보관하고 접근해 보자는 조건을 추가했습니다.

공인인증서를 하드에 보관하건 USB메모리에 보관하건 보안과는 1억광년쯤 떨어져 있습니다. 만약 외부 네트워크와 완전히 단절된 장소에 올려놓고 접근할 수 있다면 괜찮지 않을까 하는 생각이 들었습니다. 그래서 공인인증서 파일을 S3 버킷에 올려놓고 VPC를 구성해서 EC2 인스턴스에서 S3에 접근하는데 사설 아이피를 사용하게 해봤습니다. … 라고 써놓고 이제 와서 생각하니 어차피 EC2 인스턴스가 외부에서 접근 가능한데 이게 무슨 소용이었나 하는 생각이 드네요. :(

여튼. 사설 아이피를 통해 S3로부터 공인인증서를 복사해온 다음 은행 홈페이지에 접속을 시도했습니다. 윈도우 서버에 인터넷 익스플로러는 보안 수준이 ‘높음’으로 고정되어 있습니다. 레지스트리를 수정하지 않고서는 ‘높음’ 이외 옵션이 아예 나타나지 않아요. 그래서 은행 홈페이지를 통째로 ‘신뢰할 수 있는 사이트’ 목록에 추가해야 합니다. 그리고 이것 저것 컨트롤을 설치합니다. 하다 보면 충격과 공포의 이런 다이얼로그도 만날 수 있어요. 영어로 되어 있지만 늘상 보던 바로 그 병신 다이얼로그죠.

결과를 말하자면 그래서 잘 됩니다. 그냥 윈도우를 쓸 때는 나타나지 않을 보안 경고 윈도우나, 은행 사이트를 신뢰할 수 있는 사이트 목록에 넣는 윈도우나, 은행 사이트를 사용하는 것 뿐인데 갑자기 듣도보도 못한 이상한 사이트에 접속을 시도하는걸 허용하는 .. 뭐 그런 절차가 필요하긴 하지만 어쨌든 계좌 조회는 가능합니다. (은행 사이트에 접속하는 중간에 컨트롤 배포 사이트라고 생각되는 외부 사이트에 접속을 시도하는게 보안 어쩌구와는 1억광년쯤 떨어진 것처럼 보이지만 뭐 제작자들이 그딴걸 고려했겠어요?)

EC2 윈도우 인스턴스에서 인터넷 뱅킹을 사용할 수 있습니다. 대략 이런 특징이 있어요:

인스턴스를 준비하고 부팅하는데 리눅스 서버에 비해 시간이 더 오래 걸립니다.
EC2 마이크로인스턴스에서 윈도우 서버는 꽤 느립니다. 하지만 체감상 아톰 1.6, 1기가 램이 달린 오래된 HP 넷북과 비슷하거나 조금 더 빨랐습니다.
윈도우 서버 2012에는 시작 버튼이 없습니다. 윈도우 익스플로러를 실행해 인터넷 익스플로러를 찾아서 실행해야 합니다.
인터넷 익스플로러의 보안 수준이 ‘높음’으로 고정되어 있습니다. 은행 사이트를 신뢰할 수 있는 사이트 목록에 추가해야 동작합니다.
외부 웹 주소를 통해 공인인증서를 가져올 수 있습니다. 사설 아이피로 접근하는 S3는 보관에는 보안상 이득이 있지만 인스턴스가 동작하는 동안에는 보안상 이득이 없습니다.
거래가 끝나고 인스턴스를 ‘Terminate’ 했습니다. 시스템에 보안 소프트웨어를 설치해서 관리하거나 하는 부담이 전혀 없습니다.

자. 그럼 이 짓을 하는데 비용이 얼마나 드는지 생각해 봐야겠죠:

EC2 윈도우 마이크로 인스턴스: $0.02/hr (인터페이스 사용)
EC2 리눅스 스몰 인스턴스: $0.08/hr (VPC에 사용되는 서버)
EBS 30기가: $3.3/month ($0.11 * 30)
S3 한 1메가쯤?: $0.01/month
VPC: $0.05/hr
합계: $3.41

여기서 인스턴스를 ‘스몰 인스턴스’로 바꾸면 시간 당 $0.115가 되는 대신 160기가짜리 스토리지가 따라오므로 EBS를 사용할 필요가 없습니다. 게다가 램이 1.7기가나 되어 체감속도가 훨씬 빨라집니다. 이렇게 계산하면 시간 당 한화로 170원을 내면 윈도우 시스템을 사용할 수 있습니다.

장점을 먼저 이야기하자면, 보안상 유리합니다. 공인인증서를 사설 아이피로 접근 가능한 S3에 올려놓고 사용하면 공인인증서를 EC2 인스턴스로 복사해 오는데 인터넷 연결이 필요 없어집니다. 또 인스턴스를 새로 생성하기 때문에 시스템에 원하지 않는 소프트웨어가 깔려 있을 위험성이 아주 낮습니다. 만약 여기 문제가 생긴다면 AMI 자체에 문제가 있다는 이야기인데, 이 부분은 아마존을 신뢰해야겠죠. 또 거래가 끝난 다음 인스턴스를 ‘Terminate’ 해 버리기 때문에 이후 시스템 관리 부담이나 시스템에 남아있는 파일을 통한 보안 위험이 없어집니다. 사용이 끝나면 시스템을 날려버리고 매번 포멧된 새 시스템을 사용하는 셈이니까요.

단점은 .. 일단 비용이 듭니다. 시간당 170원 정도 들어요. 컴퓨터와 윈도우를 구입하거나, VM 소프트웨어와 윈도우를 구입하는 비용에 비해 이게 얼마나 낮은 비용인지는 잘 모르겠습니다. 대강 10만원짜리 시스템과 10만원짜리 윈도우 라이센스를 구입한 다음 이 시스템을 2년 내내 사용한다고 가정하면 전기요금을 제외한 시간당 비용은 12원까지 떨어지기는 하지만 가정용 컴퓨터가 24시간 켜져 있을 리도 없고 가정용 전기요금의 누진세율을 고려하면 시간당 170원이라는 비용이 ‘아주 비싸지는’ 않다는 생각이 듭니다.

또 다른 단점으로는 VM이나 실제 시스템에 비해 준비하는데 시간이 몇 분 더 걸리고 체감속도가 더 느립니다. 이건 시간당 $0.23인 미디엄 인스턴스까지 가면 거의 해결될 문제라고 봅니다. 물론 네트워크를 통한 제어가 로컬 머신이나 VM 수준으로 빨라지기는 어렵겠지만요.

그래서 앞으로도 EC2를 통해 인터넷 뱅킹을 쓸 것인가. 만약 지금 인터넷 뱅킹에 쓰는 윈도우 시스템이 망가져 사용할 수 없게 되면 그렇게 할 것 같습니다. 한달에 한 600원어치 정도 사용하겠죠. 내 공인인증서는 USB 메모리같은 어이없는 미디어 대신 사설 아이피로만 접근할 수 있는 S3에 올라가 있고요. 꽤 가능성이 있고, 실제로도 무리 없이 사용할 수 있을 뿐 아니라 보안 면에서는 큰 장점이 있습니다. 결론은 이정도로. 끝~

인간이 전화번호를 기억할 이유는 없다.

Sun, 12 May 2013 11:18:00 +0900

지하철에서 핸드폰을 들여다보고 있는 사람들을 보면 인간관계의 단절이 어쩌고 하는 이야기라든지, 전화번호를 못 외우니 핸드폰 때문에 내 기억력이 나빠지고 있는 것은 아닌지 뭐 이런 이야기를 봅니다. 전자야 뭐 양 다리 쩍 벌리고 신문을 양팔 가득 펼쳐서 보던 꼰대 노친네들이 더 이상 그짓거리를 못 하게 되어 아쉽다는 수준으로 가볍게 이해할 수 있지만 후자는 근거가 아예 없는 이야기는 아닙니다. 인터넷이 사람들이 생각하는 방식을 바꿔 놓고 있다는 것은 여러 연구를 통해 알려지고 있습니다. 다만 이게 기억력이 나빠지는 방향으로 변하고 있는가 하면 그와는 조금 다르긴 합니다.

ICQ 메신저를 사용해 보신 분이라면 ICQ 번호는 꽤 골치 아픈 것이었다는 사실을 기억하실 겁니다. 초기 ICQ는 내가 추가한 친구들을 클라이언트 사이드에만 기록했습니다. 지금 생각하면 황당한 일이지만 당시엔 그게 유일한 방법이었고, 덕분에 시스템을 재설정해서 ICQ를 새로 설치하면 친구들을 다시 추가해야 했는데, 친구들의 ICQ 번호를 어딘가에 적어 두지 않았다면 이들을 자력으로 다시 추가할 방법은 없었습니다. 친구들에게 다른 방법으로 연락해 그쪽에 추가되어 있을 나에게 다시 한 번 말을 걸어달라고 한 다음 이를 추가해야 했습니다. 만약 ICQ 이외의 방법으로 연락이 닿지 않는 사람은 유실될 수밖에 없었습니다.

그러는 사이에 MSN 메신저라는게 나왔는데 이 메신저는 ICQ와는 달리 친구를 추가하면 이 정보를 서버에 저장했습니다. 나는 내 아이디와 패스워드만 기억하고 있으면 시스템 재설정이 문제가 아니라 아무 PC에나 메신저를 설치하고 로그인 하기만 하면 모두와 계속해서 이야기할 수 있었습니다. 결국 얼마 지나지 않아 ICQ도 친구 추가 정보를 서버에 기록하기 시작했는데, 이때부터 ICQ 번호는 반드시 기억해야 하거나, 어딘가에 적어 놓아야 하는 정보가 아니게 되었습니다.

전화번호도 마찬가지입니다. 과거에 전화번호는 누군가와 연락을 취할 수 있는 거의 유일한 방법이었고, 전화번호를 기억하거나 기록하고 있는 것 자체가 자산으로 인식되었습니다. 자그마한 수첩에 빼곡히 적힌 지인들의 전화번호야말로 ICQ가 클라이언트에 저장하던 친구 추가 정보와 흡사합니다. 거기에 수첩을 잃어버리면 모든 사람들과의 관계를 재구축해야 한다는 점 마저도 비슷합니다. 하지만 시대는 변했고 핸드폰이 전화번호를 대신 기억해 줄 뿐 아니라 이 정보를 서버에 기록해 핸드폰을 바꿔도 똑같은 주소록을 사용할 수 있게 되었습니다. 친구 정보를 서버에 저장하자 ICQ 번호가 더 이상 중요하지 않게 된 것과 비슷합니다.

사람들이 전화번호를 기억하지 않게 된 것은 사람들 머리가 나빠졌다거나, 핸드폰이 사람들을 멍청하게 만들었다거나 하는 이유가 아닙니다. ICQ 번호와 같이 정보의 위상이 달라졌고 전화번호는 더 이상 어딘가에 기록해야 할 중요한 정보가 아니게 되었기 때문에 기억하지 않는 것입니다. 사람은 상대와 연락해야 하는 이유 자체에 집중하면 됩니다. 전화번호를 외우지 못하게 된 것이 아니라 외울 필요가 없게 된 것이며, 여기서 지능이나 핸드폰의 해악을 연결해서 떠올릴 어떤 이유도 없습니다.

… 아마 전화번호와 비슷한 운명이 예정된 것에는 도메인 네임이나 이메일 주소 같은 것들이 있겠죠.

슬레이트PC 필기 환경 소개

Sun, 28 Apr 2013 18:39:13 +0900

대략 6주 정도 전에 아이패드로 필기를 하고 있다고 이야기한 적이 있습니다. 서기 2013년에 모든 사람이 키보드와 키패드로 텍스트를 입력하는 시대에 아직도 펜을 가지고 입력하는 습관을 버리지 못하고 디지털 기기 사이에서 바둥거리며 살아가고 있는 뭐 그런 내용이었습니다만, 6주가 지난 지금은 이 체계를 완전히 없애버렸습니다. 디지털 기기에 필기를 그만 뒀다는 이야기는 아니고, 필기하는 기계를 바꿨다는 이야기입니다. 지금은 몇 주째 슬레이트 PC에 필기를 하고 있고, 이 이야기를 좀 적어두려고 합니다.

시작은 위에 링크한 페이지를 읽은 팀원 분의 악마와도 같은 공격으로 시작됩니다. 글을 공개해 놓고 다음날 출근했더니 팀원 분께서 자리로 오셔서 “나도 똑같은 고민을 해왔는데 내가 더 좋은 솔루션을 내일 가져다 주마” 라고 하시는 것이었습니다. 이건 필시 지름과 관련해 좋지 못한 징조였기 때문에 그 다음날은 이 악마와도 같은 상황을 피하기 위해 예정된 휴가로 대응했습니다. 하지만 그렇게 지름신의 기운을 피해 영영 회사에 출근하지 않을 수는 없었고 휴가 다음날 다시 출근했을 때 그 팀원 분은 얼굴에 부드러운 미소를 띄우며 ‘그 기계’를 건네주셨습니다. 삼성전자에서 나온 슬레이트 PC였습니다.

슬레이트 PC 자체에 대해서는 지난번에 불만으로 가득한 이야기를 적었으니 대강 넘어가고, 필기에 대한 이야기만 하자면, 이건 스크린이 달린 와콤 태블릿 그 자체였고 그림을 그리지 않는 입장에서 글자를 적고 선을 그리려는 목적에 훌륭하게 부합했습니다. 펜 해상도가 낮아 멍청하게 화면을 확대해 부분입력을 할 필요도 없었고 입력한 내용이 백터로 저장되는지 그렇지 않은지를 걱정할 필요도 없었습니다. 팀원 분의 슬레이트 PC를 회사에서 며칠 동안 사용해보게 되었는데 윈도우 8 환경에 설치할 수 있는 원노트 MX는 펜을 떼고 화면을 손가락으로 찍으면 키보드가 튀어올라와 깜짝깜짝 놀라는 점을 제외하고는 훌륭했습니다. 게다가 알아보니 설정을 통해 터치 입력을 완전히 막아버릴 수도 있었습니다. 그리고 그 길로 슬레이트 PC를 구입하고 말았습니다. 아. 굳이 아티브가 아닌 구형 모델을 구입한 이유는 가격 때문입니다. 끝.

와콤 펜은 펜심을 교체할 수 있는데, 슬레이트 PC에 포함된 S-펜도 와콤 펜심과 호환됩니다. 기본 펜심이 들어있는데 필기감이 미끌미끌해서 썩 마음에 들지 않았습니다. 펜심을 교체해서 어느 정도 타협점을 찾을 수 있습니다. 와콤에서 나온 하드펠트심을 사용하면 미끌거리는 종이에 쓰는 것과 비슷한 수준이 됩니다. 하지만 하드펠트심은 꽤 빨리 마모되고 일단 마모되고 나면 기본 심과 비슷한 수준으로 미끌거리기 때문에 이것 만으로는 좀 부족한 감이 있습니다. 아기용 면봉을 구입해 깎아 쓰는 방법도 있는데, 와콤 펜심보다 조금 더 짧게 잘라야 오차가 줄어들고 무시무시하게 마모가 빠르기 때문에 자주 빼서 깎아줘야 하는 귀찮음이 있습니다. 필기감은 면봉을 깎은 펜심 쪽이 훨씬 덜 미끌거립니다.

화면에 저반사 필름을 붙이면 필기감이 좀 더 좋아집니다. 고광택 필름은 화면을 덜 긁히게 하는데는 도움이 되겠지만 펜 끝이 미끄러지는 것을 줄여주지는 못합니다. 하지만 저반사 필름을 필름 자체고 좀 더 두껍고 필름 표면의 마찰도 더 강한 편이라 하드펠트심이나 면봉을 깎은 심을 함께 사용하면 종이와 제법 비슷해집니다. 펜심을 깎는 것이 귀찮다면 하드펠트심과 저반사 필름을 함께 사용하면 되고 아니라면 면봉을 깎아 쓰면 되는데, 가격은 하드펠트심 다섯 개를 살 가격이면 면봉 한 통을 살 수 있습니다. [……]

소프트웨어는 ‘원노트 2013’ 데스크탑 버전을 사용합니다. 사실 윈도우 환경에 필기 입력을 할 별다른 대안이 없었습니다. PDF 파일을 불러 그 위에 필기하는 앱이나 필기 전용 앱이 나와 있기는 했지만 장기간 데이터를 축적하려는 입장에서는 원노트 이외에 대안을 찾기 어려웠습니다. 오히려 경합을 벌인 대상은 윈도우 8 환경으로 나온 ‘원노트 MX’와 데스크탑 환경으로 나온 ‘원노트 2013’이었습니다. 전자는 매트로 인터페이스에 무료이고 필기에 관련된 대부분의 기능을 지원합니다. 다만 펜을 화면에서 멀리 떼고 손가락으로 입력 영역을 찍으면 바로 키보드를 띄우는데, 이게 상당히 불편해서 하드웨어 버튼을 사용해 일시적으로 터치를 무시하는 처리를 해야 하는데, 이 조작 자체가 연속된 필기를 방해했습니다.

반면 데스크탑 환경의 ‘원노트 2013’은 윈도우 8 환경에서 돌리기에 좀 초라하긴 하지만 데스크탑 환경이라 스크린 키보드가 자동으로 밀려 올라오지 않아 필기하기에 편합니다. 펜을 화면에 가까이 두면 터치 입력을 무시하고, 펜을 멀리 뗀 상태에서 화면을 터치해도 키보드가 바로 밀려 올라오지 않습니다. 여기에 태스크바를 자동 숨김으로 설정해 두고 풀 스크린으로 입력하면 원노트 MX와 비슷한 환경에서 필기할 수 있습니다. 다만 키보드로 텍스트를 입력하고 싶을 때 펜을 태스크바 근처로 옮겨 태스크바를 꺼낸 다음 여기 달린 키보드 버튼을 눌러야 온스크린 키보드가 나오는 귀찮음은 여전히 남아있습니다. 다만 이쪽은 필기를 방해하지 않고 터치 입력을 수동으로 켜고 끄는 동작이 필요 없기 때문에 이 방법에 정착했습니다.

원노트 제작사의 주장으로는 필기에 텍스트 검색이 가능하다지만 실제로 사용하기 어려웠습니다. 펜 입력 옵션에 자동으로 드로잉과 글자 입력을 전환할 수 있다고 되어 있는데, 입력의 복잡도에 따라 전환되는 것으로 추정됩니다. 단위 면적 당 복잡도가 일정 수준 이상이면 글자, 일정 수준 미만이면 드로잉인 식입니다. 당연히 정확하지 않고, 드로잉을 글자로 인식하려고 시도하거나 그 반대의 경우가 일어나기도 합니다. 또 하나 주의해야 할 점은 드로잉과 핸드라이팅 입력이 한 노트 안에 있을 때 종종 드로잉과 핸드라이팅이 겹쳐지는 현상이 일어나는 것입니다. 아마 뭔가 정렬을 시도하다가 그렇게 되는 것 같은데 눈으로 보기에는 그냥 필기가 서로 겹쳐 깨진 것처럼 보이게 됩니다. 이 현상을 겪고 바로 실행취소를 하면 원래대로 되돌릴 수 있지만 문제가 생긴 것을 그냥 지나가면 복구할 수 없게 되므로 조심해야 합니다. 문제를 피하는 쉬운 방법은 펜 입력을 ‘드로잉’ 혹은 ‘핸드라이팅’ 한쪽으로 고정하는 것입니다. 어차피 필기입력이 잘 안될 바엔 ‘드로잉’으로 설정하는 것을 추천하며 저도 결국 이렇게 사용하고 있습니다.

사실 디지털 환경에서 굳이 필기 입력을 고수하고 있는 것 자체가 좀 구시대적인 것이 아닌가 하는 생각이 들기는 합니다. 키보드로도 생각을 잘 표현할 수 있고 충분히 빠르며 검색 가능한 데이터를 쉽게 만들어낼 수 있는데 왜 하필 검색도 잘 안되고 신뢰성이 키보드만큼 높지도 않으며 특정 업체의 기술에 의존적인 방법을 사용하는가 하면, 또 이 이야기는 다른 글에서 해 보겠습니다. 오늘은 여기서 진짜 끝. :)

꿈도 희망도 없는 반도국 카드회사 메일.

Sun, 14 Apr 2013 15:16:47 +0900

기왕에 똥을 싸기 시작했으니 지난 주에 카드회사에서 날아온 이메일 이야기를 하나 해봅시다. 얼마 전에 카드회사에서 날아온 이메일 명세서로 위장한 메일이 돌아다닌다는 이야기를 들었습니다. 카드회사에서 날아오는 이메일 명세스는 온갖 놀라움과 신비로움으로 가득 차 있는데, 일단 나한테 보내는 이메일에 내 이름 중간 글자를 ’ * ‘로 표시한다든지, 나한테 보내는 이메일에, 게다가 나한테 도착한 이메일에 표시된 내 이메일 주소 일부를 ’ * ‘로 표시한다든지 (진짜 이쯤 되면 좆병신 아닌가!) 어차피 전화하면 줄줄 불러줄 카드 사용 내역을 이상한 컨트롤을 하나 설치해야 보여준다든지, 어차피 중국에 널리 퍼진 주민등록번호 뒷자리 (미친-_-)를 입력해야 보여주는 온갖 것들이 한 곳에 가득 차 있습니다. 자 딱 보면 너무 먹음직스럽죠. 공격자들이 왜 여태까지 이런 손쉬운 먹거리를 놔뒀는지 이해를 못하겠습니다.

그냥 카드회사 이메일로 위장해서 아무 주소에나 뿌려댑니다. 조선반도 궁민들이 일인당 카드를 몇 개나 가졌다고 생각하시나요. 아무 카드회사 메일로나 위장해서 마구 뿌려도 대강 절반은 걸려들 겁니다. 이 사람들은 무기력하게 이메일에서 요구하는 실행파일을 실행하도록 지난 수 년에 걸쳐 훈련되어 왔습니다. 심지어 실제 카드회사에서 날아온 이메일에 첨부된 파일 이름이 ‘카드명세서.html’인 경우도 있습니다. 이쯤 되면 어느 것이 진짜고 어느 것이 가짜인지 구분하는 것은 불가능합니다. 그냥 아무 파일이나 실행하고 민번 뒷자리를 쳐 넣는 겁니다.

또 어떤 카드회사에서 보내 오는 이메일 명세서는 방금 이야기한 식의 첨부파일을 연 다음에도 자사 웹사이트를 열어 명세서를 보여주기도 합니다. 이메일을 열어 실행파일을 열고 민번 뒷자리를 넣었더니 새 창이 하나 뜨면서 카드회사의 명세서 페이지를 보여주는 겁니다. 도대체 어떤 대가리에 똥만 쳐든 새끼가 만든 정책인지 모르겠습니다. 이런 정책으로 메일을 보내는 카드회사 메일을 자꾸 받다 보면 사용자는 이메일에서 브라우저로 새 창을 띄워도 아무런 의심도 하지 않게 됩니다. 심지어는 민번 뒷자리를 입력한 다음에 뜨는 카드회사 홈페이지가 또다시 로그인을 요구하기도 하는데, 이런걸 반복하다 보면 공격자가 꾸민 가짜 웹사이트에 아이디, 패스워드를 집어넣는 것은 너무 당연한 이야기입니다.

요새 이런 일이 좀 이슈화되어 상황이 나아질까 했지만 역시 반도국. 반도국에서 보안 어쩌고 일한다고 하는 새끼들은 전부 쳐돌았어요. 카드회사에서 내 놓은 대책을 담은 메일이 왔어요. 한번 읽어보죠.

길어서 읽지 않았을 분들을 위해 요약해보면,

네가 가입한 적 없는 카드회사에서 날아온 메일은 열지마. 누가 그렇게 카드를 많이 만들랬어?
요즘 내가 보내는 이메일이랑 똑같은 가짜 이메일을 보내는 애들이 있다더라. 너도 알지?
가짜 이메일을 구분하는 방법을 알려줄께. 우리가 보내는 이메일이랑 완전 똑같아. 여튼 네가 알아서 잘 구분하렴,
가짜 이메일에는 가짜 첨부파일이 붙어있어. 근데 우리가 보내는 첨부파일이랑 똑같으니까 이것도 알아서 잘 구분하렴. 근데 가짜를 실행해서 생긴 문제는 네가 알아서 우리한테 신고를 해줘야 돼.
우린 카드명세서 보는데 보안카드번호를 묻진 않아. 근데 패스워드 바꿀 때는 물어보니까 네가 알아서 잘 판단해.

이걸 다시 요약하면 “우린 하던 대로 계속 할거야. 네가 알아서 잘하렴” 이 됩니다. 뭐 지금까지 실컷 말했으니 그냥 여기서 끝내자면, 이건 정말 꿈도 희망도 없어요. 그냥 털리면 ‘아 반도국에서 이런걸로 털리는건 당연하지’ 하며 한화팬과 같은 자세를 가지시기 바랍니다. 끝.

최근 겪은 보안 문제 - 반도에선 이메일만이 살길.

Sun, 14 Apr 2013 14:24:51 +0900

나름 로그인 보안이나 스토리지 암호화, 네트워크 통신 암호화 등에 신경을 쓰고 있다고 생각했습니다. 패스워드는 ‘1Password’가 랜덤으로 생성한 것을 사용하고 덕분에 하나의 패스워드는 하나의 로그인에만 사용했습니다. 어지간한 스토리지는 암호화 되어 있고 제가 관리할 수 있는 네트워크는 최소한 ‘업계 표준 수준’으로 보호하고 있다고 생각했습니다. 하지만 최근 로그인이 필요한 서비스 두 곳과 조선반도 전용 인증 서비스 한 곳이 털리면서 뭔가 잘못됐다고 생각하기 시작했습니다. 결론부터 이야기하자면 귀찮음 때문에 방금 나열한 원칙을 깬 어딘가에서 패스워드가 털렸고 그 덕분이었는데, 과정을 좀 설명해 보겠습니다.

며칠 전 한밤중에 아키에이지로부터 메일이 왔습니다. 제가 패스워드를 방금 바꿨다는 내용이었습니다. 자려고 자리에 누워 알람을 맞추는 도중이었는데 무슨놈의 패스워드 리셋인가 싶어 도로 일어나 노트북을 열고 아키에이지 홈페이지에 접속해 패스워드 리셋을 시도했습니다. 휴대전화 문자 인증을 요구했는데 이걸 시도해보니 이용량이 많다며 인증을 진행할 수 없었습니다. 모르긴 몰라도 이용량이 갑자기 늘어나는 상황에 대응하지 못하는 싸구려 대행사를 아무렇게나 쓰는 모양입니다. 여튼 서너번 시도해도 안되길래 그냥 자고 다음날 오후에 다시 시도해서 패스워드를 바꿨습니다.

오늘 메일 두 통이 왔습니다. 하나는 아이핀 패스워드가 변경되었다는 거였고 다른 하나는 배틀넷 패스워드가 변경되었다는 것이었습니다. 베란다에서 꽃 사진 찍고 있었으니 분명 제 또 다른 인격이 패스워드를 바꿨을 리는 없었습니다. 일단 아이핀 나부랭이보다는 내 배틀넷 패스워드가 더 소중하므로 일단 배틀넷에 갔는데 잘 생각해보니 여기 패스워드를 리셋하려면 아이핀 패스워드가 필요했습니다. 그래서 아이핀 패스워드를 리셋하러 갔습니다.

아이핀은 서비스를 맨 처음 시작할 때 한번 가입해 놓고 쓸 일이 없었는데, 최근에 다시 가보니 서비스 업체가 왕창 생겨났고 로그인할 때마다 아이디가 중복이라며 개 쌩 난리를 치고 있었습니다. 아이핀 홈페이지는 믿을 수 없을만큼 불편한데, 사이트 생긴 것을 보면 어디서 쌍팔년도 웹디자이너를 시급 100원에 데려다가 두어시간 만에 만들어낸 인터페이스입니다. 이건 인터페이스고 뭐고 고려하고 자시고 한 것이 없고 그냥 간신히 동작만 하는 모양새입니다. 여튼 패스워드를 바꾸러면 아이핀 아이디, 내 이름을 넣고 인증 방법을 선택하는데, 신용카드 인증 같은 것도 있었습니다. 하지만 이딴 병신 사이트에 신용카드 번호를 잘도 입력하게 생겼군요. 그냥 전화번호를 넣고 인증을 거쳐 패스워드를 바꿨습니다.

이어서 배틀넷 홈페이지에 가서, 방금 바꾼 아이핀 패스워드로 로그인을 한 다음 패스워드를 바꿨습니다. 배틀넷도 비슷하게 내 계정과 내 이름을 넣고 아이핀 인증만 하면 패스워드를 바꿀 수 있게 되어 있습니다.

자, 여기서 아이핀과 배틀넷이 동시에 털린 이유는 제가 아이핀 패스워드를 ‘짧고’, ‘외우기 쉽고’, ‘허접한 사이트에 사용하는’ 것으로 사용했기 때문입니다. 제 패스워드는 크게 두 가지로 나뉘는데, 하나는 ‘1Password’가 자동 생성해 주는 것입니다. 그럭저럭 가끔 로그인 하는 사이트는 전부 이 패스워드를 사용합니다. 제가 외울 수 없어서 언제나 프로그램의 도움을 받아야만 합니다. 다른 하나는 병신 같은 사이트에 앞으로 영원히 로그인할 일이 없을 것 같고 지금 당장 저 서비스를 딱 한 번만 사용하고 싶은데 가입하라고 지랄을 떨 때 아무렇게나 입력하는 패스워드가 있습니다. 아마 이 패스워드를 아이핀에 넣어 둔 것이 화근이었을 것으로 추정됩니다. 아이핀 패스워드가 털리자 바로 아이핀에 연결된 배틀넷이 털린 것으로 그렇게 추정했습니다.

아이핀 패스워드는 최대 20글자까지 설정할 수 있는데, 조선반도 웹사이트가 늘 그렇듯 특수문자 사용 없이 영문자와 숫자만 사용 가능한데다가 신비롭게도 숫자를 8글자 이상 써야 합니다. 이게 무슨 의미냐 하면 공격자에게 20글자 중 적어도 8글자는 숫자라서 0~9 까지만 시도하면 된다는 의미입니다. 어떤 또라이새끼가 이런 정책을 만들었는지 모르겠지만 내일 오전에 출근하다가 사고로 죽길 바랍니다. 여튼 아이핀 패스워드를 ‘1Password’로 관리하기 시작했으니 아이핀에 연결된 다른 로그인이 털리는 일이 없길 기대합니다. .. 물론 아이핀 패스워드 리셋 과정으로 봐선 내 행세를 한 누군가에 의해 쉽게 털릴 수 있을 것 같아 보이긴 합니다만. :(

이번 경험으로 인터넷 로그인 보안의 핵심은 이메일이라는 것을 다시 한번 느꼈습니다. 이상의 문제를 인지하게 해준 것도 이메일이었고 패스워드를 리셋하는 과정에 휴대전화와 이메일을 사용해 인증을 해야 했습니다. 또 신용카드 번호 보다는 이메일 계정을 통한 인증이 조선반도 보안에서는 좀 더 유리하기 때문에 이메일은 정말 중요합니다. 만약 이메일이 털린다면 정말 끔찍한 상황이 벌어질 겁니다. 내가 패스워드를 얼마나 길고 까다롭고 또 다른 사이트와 다르게 설정해 놓았다고 하더라고 이메일을 통해 리셋해버리면 그만이기 때문입니다.

결국 이 일을 겪고 나서 한동안 귀찮아서 꺼놓았던 2차 인증 옵션을 켜고 로그인 할 때마다 랜덤 번호를 추가로 입력하도록 해놨습니다. 아이핀이고 공인인증서고 나발이고 조선반도에서 ‘패스워드’를 사용해 로그인하는 모든 행동의 맨 마지막은 이메일로 지켜지고 있습니다. 이메일이 털리면 정말 끝장입니다. 다른 것은 몰라도 이메일 로그인 하나만은 보안에 크게 신경 써야 합니다. 적어도 반도국에서는 그렇습니다.

마이크로소프트는 머리가 둘 달린 괴물을 만들었다

Sat, 06 Apr 2013 14:57:46 +0900

윈도우 8 이야기입니다. 윈도우 8이 나왔을 때 진심 아무런 관심이 없었습니다. 집에서는 맥을 사용했고 윈도우는 반도국 웹에서 어쩔 수 없이 사용하는 경우와 회사에서 업무용으로 사용하는 것이 전부였기 때문에 윈도우 8은 컨슈머를 대상으로는 의미가 있지만 업무용으로는 의미가 없다고 생각했습니다. 하다못해 파워포인트 프리젠테이션 문서를 터치스크린을 이용해 업무에 의미 있는 수준의 생산성을 가지고 만들 수 있으리라고 생각한 것은 아니겠죠. 아이패드로도 ‘세상에 마우스란 존재하지 않아’라고 자기최면을 건 다음에야 뭘 만들어낼 수 있는 마당에 말입니다. 그러다가 와콤 시스템에 뿅가 슬레이트 PC를 구입하면서 이야기가 시작됩니다. 마이크로소프트 스토어에서 윈도우 8을 사다가 윈도우 7이 깔려 있던 슬레이트 PC에 설치하기 시작했거든요. 그리하여 관심도 없던 터치스크린 윈도우의 한복판에 떨어지고 말았습니다.

윈도우 8은 이 이미지 하나로 설명할 수 있습니다. 다들 예쁜 ‘메트로 인터페이스’에 집중하지만 그건 윈도우 8의 절반일 뿐입니다. 나머지 절반인 ‘데스크탑 인터페이스’가 어떻게 만들어져 있는지 살펴봐야 윈도우 8이 어떤 환경인지 이해할 수 있습니다. 윈도우 8은 터치 인터페이스를 상당 부분 받아들였지만 지금까지 20여년의 세월 동안 마이크로소프트를 죽도록 괴롭혀 온 하위 호환의 굴레를 벗어버리지 못했습니다. ‘OS X’을 발표하면서 시스템 9를 관 속에 처박아버리거나 뻔뻔하게 ‘이번 버전부터 로제타 지원은 없어’라는 식의 무책임한 애플과 달리 마이크로소프트는 하위 호환이라면 목숨을 걸고 지켜 왔습니다. 윈도우 95와 심시티 2000이나 윈도우 7에서도 돌아가는 비즈칼크의 전설은 다들 아실테고, 이 기조는 터치 인터페이스를 대규모로 받아들인 윈도우 8에서도 계속됩니다. 그러니까, 메트로 인터페이스를 도입하고 나서도 데스크탑 인터페이스를 차마 치워버릴 수 없었던 겁니다.

이게 문제가 되는 것은 메트로와 데스크탑은 서로 조작 방식이 전혀 다르다는 겁니다. 모두가 알다시피 메트로는 손가락으로, 데스크탑은 마우스 커서로 조작할 것을 예상하고 만들어졌습니다. 사실 전자는 그렇게 만들어졌고, 후자는 20년 전부터 그냥 그대로 있었습니다. 지금까지 아무 일도 일어나지 않았던 것은 이런 서로 다른 조작 환경을 하나로 합쳐 바로 옆에 갖다놓고 키 하나만 눌러 양쪽을 전환할 수 있도록 만들어 놓은 시도가 없었다는 것 뿐입니다.

스티브 발머가 윈도우 7이 깔린 슬레이트를 들고 시작 버튼을 한 열번 시도해서 간신히 누르는 장면을 보신 적이 있을 겁니다. 윈도우 8에서도 데스크탑은 똑같은 문제가 있습니다. 윈도우 기본 인터페이스에 기존 툴바보다는 조금 더 큰 리본 인터페이스를 도입했지만 여전히 리본 각각은 내 새끼손가락에 비해서도 너무 작았고 이걸 누르려면 손가락 끝을 잘 세워서 손톱이 닫도록 해야 합니다. 실수로 컨텍스트 메뉴에서 복사 대신 잘라내기나 삭제를 누르지 않도록 주의해야 하고, 바탕화면에 아이콘을 더블클릭 하다가 미끄러져 엉뚱한 앱을 실행하기도 합니다. 이 모든 문제는 마우스를 사용하면 해결되고 마우스를 꽂을 수도 있게 되어 있지만 마우스를 꽂는다고 금새 행복해질 수 있는 것은 아닙니다. 키보드에 달린 시작 버튼을 누르는 순간 지금까지 보던 화면은 온데간데 없이 사라지고 새로운! 아름다운! 메트로 인터페이스가 화면을 가득 메워 버리기 때문입니다.

윈도우 8 시작 화면은 사실 꽤 괜찮은 아이디어입니다. 애플 기계처럼 아이콘만 덩그러니 늘어놓고 숫자 뱃지로 간신히 정보 표기를 하기에 급급한 것도 아니고 안드로이드처럼 정신나간 위젯 화면과 아이콘 화면을 오가며 정신을 빼앗기는 것도 아닙니다. 아이콘 자체가 위젯 역할을 하도록 만들어 앞서 말한 두 가지 환경의 단점을 해결했고 그 자체로 보기에도 나쁘지 않으며 손가락으로 누르기에도 훌륭합니다. 세로 해상도가 768 픽셀밖에 안되는 슬레이트 PC에 타일 세 줄이 나와도 손가락으로 조작하기에 너무 편리합니다. 이 정도면 인피니티 루프 주차장에 차를 세우다 말고 달려가 개발을 시작해야 할 정도로 위기입니다만, 앞서 데스크탑을 사용하기 위해 꽂아 둔 마우스를 잡아 보면 또 다시 이야기가 달라집니다. 마우스로 조작하기에는 너무 거대한 당신, 메트로 인터페이스는 이걸 마우스로 누른다는 생각을 별로 하지 않은 모양입니다. 마우스 커서는 하릴없이 거대한 타일 사이를 오가고 앱을 하나 실행시킬래도 거대한 시작메뉴를 오른쪽으로 한참이나 스크롤 해서 그룹으로 묶여 있지도 않은 앱 사이를 헤매야만 합니다.

자. 이제 삽질하는 이야기는 그만 두고 어떤 점이 문제를 일으키고 있는지를 하나씩 이야기해 봅시다.

첫째. ‘윈도우 로고 키’가 하는 일이 완전히 달라졌습니다. 윈도우 7 까지는 ‘시작 메뉴’를 부르는 키였습니다. 시작 메뉴는 윈도우에 설치된 앱이 그룹 별로 나타나고, 여기에 제어판이나 도움말, 검색 같은 추가 기능을 함께 사용할 수 있는 ‘메뉴’였습니다. 메뉴를 조작하는 동안 여전히 바탕화면 위에 떠 있는 앱과 이걸로 진행하던 작업의 맥락을 유지할 수 있었습니다. 마인드매니저로 맵을 그리다가 여기 붙여넣을 스프레드시트를 열기 위해 시작 메뉴에서 엑셀을 찾아 헤매는 사이에도 여전히 마인드매니저를 볼 수 있었다는 이야기입니다.

하지만 윈도우 8에서는 이게 완전히 달라졌습니다. 윈도우 8에서 시작 메뉴는 더 이상 ‘메뉴’가 아니라 ‘화면 전환’이자 ‘모드 전환’입니다. 마인드매니저 작업을 하다가 ‘윈도우 로고 키’를 누르면 - 시작 버튼이 없으므로 - 메트로 인터페이스 ‘모드’의 ‘시작 화면’으로 이동해 버립니다. 사실 이 화면 안에서 내가 원하는 앱을 찾을 수는 있습니다만, 기존에 시작 메뉴에서 앱을 탐색하던 습관과 완전히 다를 뿐 아니라 화면 전체를 덮어버리며 맥락을 잃게 만듭니다. 나는 엑셀 파일 하나를 열고 싶었을 뿐인데 갑자기 일정과 일기예보와 할일과 트위터 답글이 빼곡히 적힌 화면이 나타나는 겁니다. 맥으로 말하면 ‘알트 탭’을 눌렀더니 ‘대시보드’가 나타나는 꼴입니다.

윈도우에 기반한 운영환경의 강점은 맥락을 유지한 앱 사이의 작업 전환입니다. 비지오에서 그림을 그려 알트 탭을 눌러 바로 워드에 붙여넣을 수 있는 그 작업 플로우 자체가 강점입니다. 그런데 윈도우 8에서는 이 플로우를 깨버렸습니다.

둘째, 메트로 모드와 데스크탑 모드는 서로 상대 모드가 없는 것처럼 행동하려고 하지만 서로 상대 모드에 의존성이 있습니다. 메트로 모드에 제어판이 있고 데스크탑 모드에 또 다른 제어판이 있습니다. 메트로 모드에 윈도우 익스플로러가 있고, 데스크탑 모드에 또 다른 윈도우 익스플로러가 있습니다. 메트로 모드에 인터넷 익스플로러가 있고 데스크탑 모드에 또 다른 인터넷 익스플로러가 있습니다.

아마도 윈도우 RT 환경을 의식해서 서로 상대 모드에 의존성을 가지지 않도록 만들어야 했기 때문에 이렇게 됐을 수 있다고 생각했습니다만, 데스크탑 환경에서 이미지를 더블클릭하면 이런 생각도 무너집니다. 이미지를 열면 메트로 쪽 뷰어로 날아가 그쪽에서 보여주거든요. 반대로 메트로 쪽에서는 무슨 수를 써도 백업 옵션이나 하드웨어 설정에 접근할 수가 없습니다. 반드시 데스크탑 모드에 가서 그쪽 제어판을 열어 접근해야 합니다.

셋째. 메트로와 데스크탑은 멀티태스킹에 대한 제어방법이 서로 다릅니다. 일단 데스크탑은 우리가 생각하던 그대로입니다. ‘X’를 누르면 꺼지고, 예외로 트레이에 살아남아 있는 것들만 신경 쓰면 됩니다. 헌데 메트로에서 앱을 실행하다가 홈 버튼을 눌러 시작 화면으로 돌아오면 앱은 꺼지지 않은 상태로 유지됩니다. 아이폰이나 아이패드에서 사용하던 경험 그대로입니다. 아이패드에서는 특별히 앱을 종료할 필요가 없는데, 자원이 모자르면 알아서 앱을 꺼 주기 때문입니다. 이런 상황에 대응하도록 앱을 개발해야 하고 종료 과정이 매끄럽지 않아 가끔 새로 실행한 앱이 중간에 그냥 꺼진다거나 하는 상황이 있지만 그럭저럭 잘 동작합니다. 메트로 모드도 이렇게 만들려고 했던 것 같은데, 메트로에서 앱을 실행했다가 종료에 신경 쓰지 않고 시작 메뉴로 돌아오기를 반복하면 윈도우 CE를 사용하던 시절처럼 빼도박도 못 하는 상황이 벌어집니다.

일단 시스템이 꽤 버벅거린다고 느껴질 시점까지 앱이 꺼지질 않습니다. 아마도 자동으로 끄도록 설계했을 것 같은 냄새가 곳곳에서 나는데 체감상 잘 동작하지 않습니다. 그 말은 앱 사이를 전환할 때 홈 버튼을 누르기 보다는 화면을 내리 그어 앱을 끄면서 시작 화면으로 돌아가는 편이 더 안전하며 이 동작을 할 때마다 멀티태스킹에 신경을 쓰게 된다는 이야기이기도 합니다.

또 메트로 모드에 여러 앱을 종료 없이 들락거린 다음 알트 탭을 눌러 보면 작업의 맥락을 파악할 수 없게 되어 버립니다. 잠깐 보고 싶었던 날씨, 할일, 달력, 메일, 브라우저 등등 온갖 앱이 동시에 떠 있고 이들 사이를 전환하는 일은 꽤 피곤합니다. 이런 상황이 서로 상대 모드에서 일어나면 모드를 전환하기 전까지는 파악할 수도 없습니다. 이들이 떠서 빨아먹는 배터리 이야기는 굳이 여기서 더 꺼내지 말도록 하죠.

넷째. 메트로 모드와 데스크탑 모드 사이에 접근성 옵션 처리가 서로 다릅니다. 간단히 데스크탑에서 사용하던 돋보기가 메트로에서 동작하지 않고 나레이터가 서로 다른 방법으로 화면을 읽어줍니다. 화면이 보이지 않을 경우 데스크탑에서 메트로로 전환하고 나면 다시 데스크탑으로 돌아오기 아주 어렵습니다.

사실 이런 온갖 문제점들이 지난 수 십 년 동안 사용해 오던 커서 기반의 인터페이스가 터치 기반의 인터페이스와 통합되면서 일어나는 과도기적인 현상이라는 것을 모두가 잘 알고 있습니다. 또 마이크로소프트만 이렇게 삽질하고 있는 것이 아닙니다. 애플도 멀쩡한 맥에 풀스크린 앱을 도입하고 미션 컨트롤을 도입하고 대시보드를 축소하고 런치패드를 만들어 가며 온갖 삽질을 반복하고 있습니다. 다만 애플의 접근은 기존 맥이 가지고 있던 맥락을 유지한 상태의 멀티태스킹을 유지한 채로 새로운 시도를 하고 있습니다. 반면에 마이크로소프트는 정 반대의 방법을 시도하는 부분은 다릅니다. 장기적으로 이들 인터페이스는 잘 통합되거나, 보다 부드러운 전환 방법을 제공하는 식으로 개선되겠지만 지금은 아닙니다. 마이크로소프트는 서로 전혀 이야기하지 않는 머리 둘 달린 괴물을 만들었고 한동안 이 머리 둘을 제어하느라 사용자 입장에서 꽤나 골치를 썩게 될 겁니다.

곧 후속 버전인 윈도우 블루 업데이트를 내놓는다는데, 공개되는 스크린샷은 온통 예쁜 메트로 인터페이스 뿐이라 많이 걱정됩니다. :(

슬레이트 PC 사용기

Sat, 06 Apr 2013 11:11:07 +0900

한동안 아이패드에 필기를 하다가 슬레이트 PC에 와콤 스타일러스가 달렸고 신형 아티브가 나오면서 가격이 내려간 것을 보고 슬레이트 PC를 덥썩 샀습니다. 지금까지는 어지간한 어떤 필기 입력 기계도 와콤 스타일러스보다 나은 필기 경험을 하게 해 주지는 못합니다. 아이패드용 필압감지 펜을 팔아버리고 슬레이트 PC를 사용하기 시작했는데 어떤 기계도 일단 마구 만들고 일단 팔고, 다음에는 모른 척 하고 보는 제조사의 특성을 고려해 옴니아 수준의 심각한 문제가 일어나지 않는다면 그냥 참고 쓰고 있었는데, 심각하지만 않지만 아무리 생각해도 희한한 세 가지 이슈만 이야기해 보려고 합니다. 심각한 것은 아닙니다. 하지만 괴상합니다.

이 기계에 달린 여러 버튼은 윈도우 운영체제에 절대적으로 의존합니다. 기계 전면에 달린 홈 버튼은 아이패드의 홈 버튼과 같은 기능을 할 거라고 예상하기 쉽지만 그렇지 않습니다. 이 버튼은 키보드에 달린 ‘왼쪽 윈도우 키’입니다. 그래서 윈도우 8 환경에서 홈 버튼을 누르면 시작 메뉴가 나타납니다. 여기까지는 아이패드 홈 버튼과 같지만 절전 모드가 되면 이야기가 달라집니다. 절전 모드에서 홈 버튼을 눌러도 아무 반응이 없습니다. 어쩌면 제어판 깊숙한 어딘가에서 키보드 입력으로 절전 모드를 해제하는 옵션을 켜면 달라질 수도 있지만 기본 상태에서는 절전 모드에서도 반드시 전원 버튼을 눌러야만 기계를 켤 수 있습니다. 또 윈도우 로고 키 입력을 받지 않는 앱이 포그라운드에 떠 있으면 홈 버튼은 먹통이 됩니다. 윈도우 운영체제에 의존성이 있는 것 자체가 문제는 아닙니다만, 하드웨어 입장에서 같은 버튼이 상황에 따라 서로 다른 동작을 하는 것은 문제입니다.

앰비언트 라이트 센서가 희한한 곳에 달려 있습니다. 정면의 오른쪽 상단부터 1/4 지점에 달려 있습니다. 처음에 원노트에 필기를 하다 보니 화면이 저 혼자 밝아졌다가 어두워졌다가를 반복하는데 이유를 몰라 답답했습니다. 그러다가 저반사 필름을 붙이고 나서 보니 그 자리에 구멍이 뚫려 있고 거기가 앰비언트 라이트 센서 자리라는 사실을 알고는 의문이 풀렸습니다. 저는 오른손으로 글씨를 쓰는데 오른손이나 팔뚝이 종종 저 센서를 가렸고 그럼 기계는 당연히 주변이 어두워졌다고 생각하고 화면을 어둡게 만든 겁니다. 또 손이나 팔뚝을 치우면 다시 밝아졌다고 생각하고 화면을 밝게 만든 거겠죠. 뭐 개발자가 왼손으로 글씨를 쓰는 사람이라면 인정할 수도 있겠지만 그럴 가능성은 낮다고 봅니다. 이건 두 가지를 의미하는데, 일단 펜을 달아놓고 개발 스탭 중 어느 누구도 장시간 펜 입력 테스트를 한 적이 없다는 것과 아무도 앰비언트 라이트 센서가 한쪽에 치우쳐 있는 설계가 괴상하다고 느끼지 않았을 거란 점입니다. 아이패드나 아이폰을 보면 해결 방법은 간단한데, 그냥 센서를 화면 상단 중앙이나 그 근방에 갖다 놓으면 됩니다. 애플 제품을 그렇게 잘 배껴대면서 왜 이런 부분은 배끼지 않나요. 설마 화면 상단 중앙에 달린 앰비언트 라이트 센서 위치가 특허인가요?

또 하나 이상한 점은 분명 와콤 센서를 달고 와콤 펜을 끼워 주면서 기계 본체는 펜이 없는 것처럼 만들어졌다는 점입니다. 웹에서 이 기계를 뜯어 놓은 이미지를 본 적이 있는데, 내부는 여기 저기 빈 자리가 많았는데 여기 어딘가를 짜맞춰 펜 한자루 넣을 공간을 확보하자는 결정이 그렇게도 어려웠거나 설마 이걸 아무도 생각하지 않았을까 하는 생각을 하면 울화통이 치밉니다. 물론 최신 제품인 아티브에는 펜 꽂는 자리가 있다고는 합니다만, 그럼 슬레이트 PC에 펜을 쓰는 사람들은 다들 펜을 다른 주머니에 곱게 넣어 다니는 것이 당연하다고 생각했을까요? 하다못해 서피스 프로만 봐도 자석을 이용해 펜을 기기 한쪽에 붙이도록 하고 있는데 여기 저기 잘 배끼면서 왜 이런 기능은 안 배꼈는지 이해할 수 없었습니다.

이 기계는 ‘와콤 펜으로 원노트에 필기 입력을 한다’는 단 한 가지 조건을 만족하기 때문에 사용하기 시작했지만 기계 자체의 만듦새를 보고 있자면 울화통이 치밉니다. 이딴 기계를 만들어 고가에 파는 깡도 대단하고 이런걸 덥썩덥썩 구입해주는 호갱님들 - 저를 포함한 - 도 대단합니다. 수 년 전이나 지금이나 제조사는 서기 2013년에는 너무 당연한 최소한의 디테일에 별 관심 없이 여전히 기계를 찍어내는데 급급한 수준이 아닌가 하고 넘겨짚으며 오늘도 앰비언트 라이트 센서를 가릴 때마다 어두워지는 화면을 보고 글씨를 씁니다. :(

그 외에도 이상한 펜 컨트롤, 이상한 뒷 판 설계, 마이크로SD 카드 슬롯의 위치 문제 등 신경 쓰이는 부분이 참 많지만 그저 ‘일단 만들어놓고 제대로 기계를 써본 사람이 없을 것’이라고 가정하면 전부 다 이해됩니다.

접근성

Sun, 31 Mar 2013 12:00:34 +0900

아침에 안드로이드 기기가 접근성에 문제가 있고 국내 관련 법령 개정 이전에 수정하지 않으면 곤란할 수 있다는 글을 봤습니다. 거기 달린 의견들을 읽어보니 안드로이드는 처음부터 접근성에 대한 고려가 별로 없었지만 최근에는 스크린 리더나 확대 기능 등을 집어넣어 접근성에 큰 문제는 없다는 의견이나, 안드로이드보다는 iOS가 접근성이 더 낫다는 의견이 있었습니다. 말하고 싶은 결론부터 이야기하면 그나마 괜찮은 것으로 알려진 iOS나 맥도 사실 별 거 없다는 것입니다.

접근성에 관련된 기능에 접근할 때 중요한 점은 접근성을 향상시키기 위해 OS나 애플리케이션 레벨에서 뭔가 기능을 추가하면 될 거라는 식의 접근은 곤란하다는 겁니다. 안드로이드 기기는 시각장애인이 사용할 수 없으니 스크린 리더 기능을 추가하면 시각장애인의 접근성 문제를 해결할 수 있을 거라고 생각했다면 기능을 추가한 코더들만 고생하고 기능을 구입하는데 들어간 비용만 날릴 뿐입니다. 물론 이쪽이 법률비용보다 저렴할 수는 있겠죠. 하지만 이런 접근은 실제로 아무 도움도 주지 못합니다.

스크린 리더가 OS 레벨에 붙어 그나마 잘 동작한다고 알려진 iOS도 스크린 리더를 사용하려면 난처한 상황에 처하게 됩니다. OS는 기능을 지원하지만 그 위에서 돌아가는 앱은 이 기능을 지원하지 않는 경우가 대부분이기 때문입니다. 그나마 이쪽은 인터페이스 가이드에서 스크린 리더가 인터페이스를 읽도록 하기 위한 방법을 제시하고는 있습니다. 하지만 이 가이드라인에 따라 앱을 만들어도 스크린 리더는 개발자가 인터페이스에 집어넣은 텍스트를 읽어주는 수준에서 그칩니다. 결코 앱에서 수행하고자 하는 작업의 맥락을 파악할 수가 없습니다. 그나마 이 가이드라인은 가이드라인일 뿐이기 때문에 상당수 예쁜 커스텀 컨트롤을 사용하는 앱은 스크린 리더와 전혀 호환되지 않습니다. 마치 웹 사이트에 달린 플래시 같은 느낌입니다.

접근성 문제에 과거부터 형식적인 기능으로 일관해 오기로 말하면 윈도우 이야기를 안 할 수가 없는데, 윈도우에는 시력이 약한 사람이 사용하라고 텍스트 크기를 키우는 설정이 있습니다. 원래 표시되는 텍스트를 100%로 잡고 125%로 설정하는 기능인데, OS에서 지원하기는 하지만 이걸 켜고 재시작 하는 순간 굉장한 꼴을 보게 됩니다. 이 설정에서 제대로 보이는 앱이 거의 없기 때문입니다. 하다못해 메시지박스에 텍스트 마저도 텍스트가 박스 밖으로 잘려나가 읽을 수 없거나 버튼이 화면 바깥으로 밀려나가 영원히 조작할 수 없는 상태가 되기도 합니다. 서드퍼티 앱은 물론이고 마이크로소프트에서 만든 오피스도 어느 컨트롤은 이 설정을 지원하고 어느 컨트롤은 설정을 지원하지 않아 흉한 꼴이 되고 이 설정을 끄러 가기조차 어렵게 되기도 합니다. 이건 쓰라고 만든 설정이 아니라 법률 비용을 아끼려고 넣은 설정입니다.

윈도우 돋보기도 비슷한데, 화면을 확대해 주기는 하지만 분명 이보다 더 편리하게 만들 수 있었을텐데도 십 수년 동안 아무 노력도 하지 않는 접근성 기능 중 하나입니다. 돋보기를 켜면 화면 상단에 확대 영역이 나타나고 마우스커서나 캐럿의 이동에 따라 확대 영역이 정해지는데, 인터페이스를 깨지 않는다는 점에서는 텍스트 확대 기능보다는 실제로 사용할 수 있을 가능성이 있지만 윈도우에서 행하는 작업 대부분이 ‘툴바’와 ‘캐럿’처럼 서로 멀리 떨어진 두 가지 오브젝트를 동시에 다뤄야 하는 일이 많음을 감안하면 한 번에 한 장소만, 그것도 상하 폭이 제한된 크기만을 확대할 수 있도록 만들어진 기능은 형식적이거나, 아니면 한번 만들어 넣고 아무도 거들떠보지 않았거나 중 하나일 것입니다.

상대적으로 맥은 이런 문제로부터 자유롭다고 알려져 있지만 아마도 이런 기능을 쓸 일이 없는 사람들이 낸 소문이 분명합니다. 물론 화면 확대 기능을 생각하면 분명 윈도우보다는 쓸만합니다. 화면 전체를 확대해 인터페이스가 깨지지 않고 화면 전체를 확대하기 때문에 동시에 사용할 인터페이스를 확대된 화면 안쪽에 잘 배치하면 그럭저럭 작업도 가능합니다. 또 랩탑을 사용한다면 트랙패드를 사용해 확대 기능에 말도 안될 정도로 편하게 접근할 수 있습니다. (윈도우에서 돋보기 기능을 켜고 꺼 보세요) 하지만 이 확대 기능은 100% 배율일 때 텍스트에 안티앨리어싱이 먹은 상태 그대로 확대해 주기 때문에 높은 배율에서 글자 주변에 망가진 픽셀이 그대로 눈에 들어와 거슬리고 장시간 쳐다보면 어지러움을 느끼기도 합니다.

스크린 리더 기능은 윈도우나 맥 양쪽 모두 인터페이스를 읽어주는데 집중한 나머지 작업의 맥락을 파악하기 아주 어렵습니다. 스크린 리더 앱에 훈련되어 있다면 어느 정도 사용이 가능하겠지만 단순히 화면에 배치된 인터페이스를 읽어 주는 수준으로는 한계가 있습니다. 만약 실제 이 기능을 필요로 하는 사람의 적극적인 피드백이나 실제 개발 참여가 있었다면 분명 작업의 맥락을 파악할 수 있는 스크린 리딩이 아니라 음성 어시스턴트 기능 같은 것으로 발전할 수 있었겠지만 지금은 양쪽 모두 극도로 초보적인 수준입니다. 리눅스요? .. 음.. 어… 넘어가죠.

요즘 기기 접근성에 대한 이야기가 가금 튀어나오는 것 자체는 환영할 만한 일입니다만, 이런 이야기 자체, 그리고 개발 과정에 실제 이런 기능을 필요로 하는 사람들의 참여 없이 진행되어 봐야 법률 비용을 물지 않는 것 이상의 역할을 하기는 어렵습니다. … 그냥 답답해서 지껄여봤어요. 끝.

개발 문서를 자동화할 수 있지 않을까?

Sat, 16 Mar 2013 11:08:13 +0900

오늘은 개발에 필요한 문서를 만들다가 든 생각을 이야기할 작정인데, 그에 앞서 스냅샷이라는 개념을 잠깐 이야기하고 넘어가겠습니다. 위키백과에서 찾아보면 “컴퓨터 파일시스템에서 과거의 한 때를 유지시킨 파일과 디렉토리의 모양”이라고 되어 있습니다. 원래는 사진에서 나온 말인데 요즘에는 시스템의 어느 시점에 상태를 기록한 여러 가지 것들을 퉁쳐서 스냅샷이라고 부르는 모양입니다. 팀에서는 주로 프로그래머들이 사용하는 단어인데, 방금 이야기한 개념에 따라 스냅샷이라는 말을 섞어서 써봤더니 아무도 이상하다고 지적하지 않았고 대강 의사소통이 이루어진 것으로 미루어 스냅샷을 이렇게 이해해도 괜찮은 모양입니다.

스냅샷은 시스템의 어느 한 시점에 상태를 기록한 것입니다. 이 말은 시스템의 상태는 계속해서 바뀌고 스냅샷은 어느 한 순간을 기록한 것이며 시스템의 ‘최신 상태’와는 차이가 있을 수 있다는 말입니다. 스냅샷 여러 개를 주기적으로 남겨 상태를 관찰할 수는 있지만 결코 시스템의 최신 상태에 일치할 수가 없습니다. 시스템의 최신 상태와 스냅샷을 일치시키는 유일한 방법은 시스템의 변경을 멈추는 것 뿐입니다. 개발을 중단하거나 서비스를 종료하면 그 마지막 상태와 스냅샷이 일치하겠죠.

뭔가를 - 여기서는 게임을 - 개발하기 위해서는 의사소통을 위한 문서가 필요합니다. 누군가는 기획서라고 뭉뚱그려 부르기도 하고 누군가는 조금 더 나눠 컨셉과 시스템 문서로 구분하기도 합니다. 여기서 조금 더 나가면 설계와 API 문서로 나누기도 하고 여기에 의사결정 과정을 기록한 문서를 더 추가하기도 합니다. 이렇게 여러 가지 문서를 기록하는 모든 과정에서 똑같이 일어나는 문제는 언제나 문서와 실제 개발된 결과물 사이에 차이가 생긴다는 겁니다. 문서를 열심히 잘 작성하려고 아무리 노력해도 문서와 구현물, 문서와 사람들이 파악하고 있는 상태 사이에는 언제나 크고작은 차이가 있고 이걸 해결하는데 시간을 아무리 부어도 현재 상태에 수렴해갈 뿐 일치하지 않습니다.

이런 상태는 크고작은 비용을 요구하기 때문에 이걸 해결할 수 없을지 생각해보다가 개발에 사용되는 모든 문서는 시스템의 스냅샷이기 때문에 영원히 문서가 시스템을 따라갈 수 없는 것이 당연하다고 보기 시작했습니다. 처음에는 컨셉 문서를 만들어 이걸 바탕으로 시스템을 개발하기 시작하면 이 순간부터 문서와 시스템은 어긋납니다. 문서에 없는 구현이 추가되고 컨셉은 틀어집니다. 누군가는 이 상황을 참지 못하고 문서를 열나게 수정하겠지만 결코 개발 중인 시스템을 따라갈 수는 없을 것입니다. 문서는 영원히 시스템의 스냅샷일 뿐 시스템 자체가 아닙니다.

스냅샷을 벗어나기 위해서는 시스템의 현재 상태를 실시간으로 관찰해야 합니다. 보통 실시간이라는 말에 포함되는 기계를 통한 자동 모니터링으로부터 힌트를 얻었습니다. 시스템의 현재 상태를 자동으로 모니터링해서 문서화하고 인간이 이 문서와 컨셉 사이에 관계를 정의합니다. 이 과정을 통해 현재 시스템을 만들어낸 인간의 의도와 시스템의 현재 상태를 합쳐서 문서화할 수 있습니다. 상위에 컨셉이 있고, 이를 반영한 시스템의 현재 상태 중에서도 상위 설계가 자동으로 문서화되며 이들 사이를 인간이 연결해줍니다. 어떤 컨셉은 여러 개의 시스템에 연관될 수 있고 어떤 시스템은 여러 컨셉으로부터 나온 결과일 수도 있습니다. 컨셉을 자동화할 수는 없지만 현재 시스템의 상태를 문서화하는 것은 어느 정도 자동화가 가능할 거라고 봅니다. 이 둘을 합쳐 문서를 만들면 언제나 비교적 최신 상태의 문서를 유지할 수 있습니다.

전통적으로 문서를 작성하는 방식을 다시 생각해 봐야 합니다. 문서는 워드프로세서나 위키 같은 정적인 매체를 통해 기록해 왔습니다. (물론 현대의 위키는 동적인 시스템을 추가할 수 있지만) 컨셉 단계까지는 정적인 매체를 통해 기록할 수 있지만 개발이 시작되고 시스템이 마구 변하면 동적인 시스템에 기록되어야 합니다. 동적인 문서 작성 시스템은 인간의 의도를 정적으로 기록하지만 이 의도가 반영된 시스템의 현재 상태에 대해서는 필요한 부분에 한해 시스템의 상태를 자동으로 문서화하고 이 둘을 합쳐 하나의 문서로 제시합니다. 여기에 컨셉과 시스템에 기반해 자동으로 만들어진 문서 사이에 관계 관리를 인간이 담당합니다. 마치 서버 사이드 스크립트를 통해 동적으로 생성된 웹페이지를 클라이언트에 보내주듯 개발 문서도 이와 같은 방식으로 접근해야 합니다.

… 여기에 문서 사이에 관계 관리가 문서 자체 뿐 아니라 내용에도 필요하다는 생각을 하기 시작했는데 이건 나중에 다시 이야기해 보겠습니다.

아이패드 필기 환경 소개

Sun, 10 Mar 2013 21:02:11 +0900

네. 아이패드에 필기를 합니다. 꽤 많이 하고, 순발력이 필요한 순간을 제외한 나머지 필기를 모두 대체했습니다. 지금 쓰는 노트 앱을 쓰는 사람이 전 세계에 수 십만 명이나 되고 구글에 검색하면 사용기가 수 십 개나 나오지만 굳이 필기 환경을 이야기해 보려고 하는 이유는 제 필기를 보고 대체 뭘 어떻게 쓰는 거냐고 물어 오신 분이 꽤 많아서입니다. 그래서 글로 남겨두는 김에 그동안 해온 삽질에 대해서도 조금 이야기해 보고, 그래서 지금 정착한 필기 환경에 대해서도 이야기해 보겠습니다.

맨 처음에는 디지털 필기가 주 목적이 아니었습니다. 오히려 그냥 사라져 버리는 필기 자료를 디지털화해서 남겨두고 참고하려는 것이 목적이었습니다. 그래서 필기를 스캔해볼까 하는 생각을 했는데 이 생각을 처음 한 당시에 스캐너라고는 평판 스캐너 뿐이었고 핸드폰 카메라도 그리 좋지 않았습니다. 카메라 자체가 나빴다기 보다는 핸드폰에서 사진을 꺼낼 수가 없었습니다. (nTop 시대가 끝나자 마자 나온 Nate 버튼 달린 핸드폰에서 사진을 꺼내려고 시도해 보신 분은 이해하실 겁니다.) 그래서 여기 저기 살펴보다가 눈길이 간 것은 Acecad의 DigiMemo 라는 제품이었습니다. 태블릿 판과 전용 펜을 쓰되 그 위에 보통 종이를 올려놓고 쓰는 구조입니다. 펜 끝에 달린 전자석을 이용해 볼펜으로 글씨를 쓰면 전자석의 신호를 태블릿에 전달하고 이걸 저장합니다. 장점은 종이에 그냥 볼펜으로 쓸 수 있다는 점, 단점은 매번 페이지를 바꿀 때 수동으로 기계에 달린 버튼을 눌러 새 페이지가 시작됨을 알려야 하는 것입니다. 상상하셨겠지만 기계에 달린 페이지 버튼 누르는 것을 깜빡 하면 여러 페이지에 걸친 메모가 한 페이지에 겹쳐 있는 꼴을 보게 됩니다. 복구가 불가능해 아주 빡치죠.

한 2년쯤 이 기계로 편안하게 살았습니다. 헌데 시간이 지나다 보니 문제가 생겼는데, 검색과 정리가 쉽지 않았습니다. 나름 OCR 소프트웨어를 제공했지만 형편없었고 저장 파일은 자체 포멧인데 제작사의 소프트웨어 지원은 수준 이하였습니다. 그래서 자체 포멧을 읽어 PDF로 바꿔주는 펄 스크립트를 사용하고 검색 대신 페이지마다 태그를 달아 관리했습니다. 그러다가 어느 순간 “이게 뭐하는 짓인가” 싶었던 겁니다. 필기를 디지털 형식으로 남겨두는 것은 의미가 있었지만 관리부담이 컸고 PDF 파일을 편집하려면 아주 큰 비용을 지불해야 했기 때문에 - 아크로뱃을 사야 했지만 아주 비쌌죠 - 모든 페이지는 낱개의 PDF 파일로 분해되어 있었습니다. 어느 순간부터 점점 시들해지고 더 이상 사용하지 않게 되었습니다.

그 후 현재 시스템에 이르기까지 펜 끝에 카메라가 달려 있어 점이 찍힌 전용 용지에 쓰는 펜이나, 종이 위에 클립처럼 생긴 기계를 물려 놓고 전용 펜으로 쓰는 기계 같은 것을 시도해봤지만 하나같이 맨 처음 사용한 태블릿을 사용하며 겪던 문제를 벗어날 수가 없었습니다. 형편 없는 필기 인식으로 인한 검색 불가, 전용 포멧, 형편 없는 소프트웨어 지원, 필기 자체가 온전하게 기록되지 않는 문제 따위였습니다. 하나하나 설명하기에는 귀찮고 바로 현재 체계로 넘어가 보겠습니다. […]

지금은 아이패드에 ‘Noteshelf’ 라는 앱을 사용해 필기를 하고 있습니다. 이 앱에 정착하기 전에 마지막까지 경합을 벌이던 앱은 ‘UPad’ 였습니다. UPad의 장점은 딱 하나. 필기 엔진이 훌륭합니다. 사실 아이패드에 필기하는 것은 종이에 필기하는 것과 완전히 다른 경험입니다. 종이에 쓰던 버릇 대로 획을 그어도 그걸 곧이곧대로 받아들이면 초딩 글씨처럼 되고 맙니다. 그래서 소프트웨어적으로 획을 보정해 주는 장치가 필요한데 UPad는 한글로 필기하는 입장에서 이런 보조 장치가 가장 잘 되어 있습니다. 거의 유일하게 볼펜으로 휘갈겨 쓸 때 종이에 남는 자국이나 펜을 들어올리며 긋는 자국 등을 재현해줍니다. UPad를 강력하게 고려했지만 선택하지 않은 이유는 두 가지인데, 종종 노트가 이유를 알 수 없이 사라졌고 지금 쓰는 필압 감지 펜을 지원하지 않았기 때문입니다. 반대로 지금 정착한 Noteshelf는 필기 보조 시스템은 UPad보다 못하지만 필압 감지 펜을 지원하고 몇 달 동안 사용한 경험 이내에서 안정적입니다. (최근에 한 노트의 페이지가 많아지면서 익스포트에 문제가 좀 생기고 있긴 합니다만.) 아마 Noteshelf가 블루투스 펜을 지원하지 않았다면 노트를 잃는 문제에도 불구하고 UPad를 선택했을 겁니다. 그만큼 필기 경험이 뛰어납니다.

아이패드로 필기를 시도할 생각을 하기 전에 꼭 알아둬야 하는 점은 아이패드에는 무슨 수를 써도 노트에 하는 것 만큼 작은 글씨로 정교하게 쓰는 것은 불가능하다는 것입니다. 어지간한 노트필기 앱 스크린샷에 큼직큼직한 글씨와 그림만 나온다는 점을 떠올려 보면 됩니다. 이유는 간단한데 아이패드의 터치 인식 단위가 3밀리미터이기 때문입니다. 3밀리미터보다 좁은 단위에 들어오는 터치는 인식할 수가 없습니다. 그래서 아이패드용 터치펜이 그렇게 굵직굵직한 거고 그렇게 굵다 보니 작은 글씨나 정교한 그림을 그리는 것은 어렵습니다. 앱 제조사마다 여러 시도를 하고 있는데, 그림은 페이지를 확대해서 그리도록 하는 것이 일반적이고 글씨를 쓰는 앱도 비슷하게 화면을 확대해 하단에 나타난 확대창에 입력하도록 하고 있습니다. 화면을 확대해서 큼직큼직하게 쓰고 배율을 원래대로 되돌리면 작게 쓴 글씨처럼 보이는 식입니다. 글씨를 작게 써서 실제 종이 노트처럼 보이는 장점이 있지만 화면의 일부를 확대해서 쓰기 때문에 자유로운 메모와는 거리가 있습니다. 쓰다 보면 키보드로 커서가 있는 위치에 글쇠를 입력하는 것과 아주 비슷하다는 느낌을 받게 됩니다.

Noteshelf를 선택한 이유 중 하나인 필압 감지 펜 지원에 대해서 이야기해보면, 가장 최신 버전인 7.0 부터 지원하기 시작했고 지원하는 펜은 세 종류인데 제가 사용하는 것은 그중 하나인 ‘pogo-connect‘입니다. 나름 ‘수 백 단계’의 필압을 지원하고 블루투스 4.0을 지원해 ‘몇 달’ 동안 지속되는 배터리 수명을 자랑합니다. 이 펜은 AAA 전지를 넣어야 하는 만큼 두툼하고 무게도 볼펜보다는 무겁습니다. 또 어지간한 터치펜보다 팁이 더 큽니다. 거의 유성매직 정도 크기라고 보시면 되는데, 이걸로 가는 글씨를 익숙하게 쓰는데는 적응 기간이 좀 필요합니다. 물론 가는 펜 끝을 만들어낸 Jot Pro 같은 제품도 있습니다만, 그냥 한마디로 구립니다. 필기할 때 유리와 딱딱한 투명 플라스틱이 부딪쳐 소음이 크고 소음 만큼 손에 피로가 빨리 옵니다. 반면 pogo-connect는 끝이 뭉툭해 글씨를 쓰기 위한 적응 기간이 필요한 대신 상대적으로 부드럽게 쓸 수 있어 여러 페이지를 기록하기에 적당합니다.

이 펜이 필압을 지원하는 원리는 생각보다 단순합니다. 일단 좌표 입력은 아이패드의 터치에 의존합니다. 펜 광고에는 ‘캘리브레이션이 필요 없다!’라고 하는데 그냥 아이패드 터치를 이용한다는 이야기입니다. 때문에 펜 끝이 그렇게 무시무시하게 굵은 거고요. 펜은 아이패드와 블루투스로 연결되어 있는데, 블루투스로는 필압만 전송합니다. 그래서 터치 기반으로 입력된 좌표에 블루투스로 날아온 필압 데이터를 합쳐 획을 그리게 됩니다. 이런 구조는 배터리가 떨어져도 펜을 쓸 수 있게 해줍니다. 다만 전원을 끈 채로 글씨를 쓰면 획이 더 굵어지고 전원을 켜고 쓰면 더 가는 획을 쓸 수 있게 됩니다. 좌표를 블루투스로 전송하지 않기 때문에 안정적이지만 정교하지는 않으며 그래서 여전히 앱에서 지원하는 확대 입력 기능을 사용해야만 합니다.

펜에 큼직한 AAA 배터리가 들어가서 쫄았지만 배터리는 제법 오래 갑니다. 약 3개월 동안 250페이지 정도를 썼는데 배터리는 35% 정도가 남아 있습니다. ‘몇 개월쯤 간다’는 제조사의 광고가 완전 허구는 아닌 모양입니다. 추가로 팁을 교체할 수 있게 되어 있고 제조사에서는 팁을 업그레이드 할 수 있을 테니 조금만 기다려보라고 했지만 오늘 제조사 홈페이지에 가보니 여전히 기본 팁 한 종류만 팔고 있습니다. […] 여튼 팁을 쉽게 교체할 수 있어 나중에 Jot Pro 같은 투명 타입의 팁이 나온다면 그것도 괜찮겠습니다.

이렇게 ‘Noteshelf’ + ‘pogo-connect’의 조합으로 필기를 하고 있습니다. 종이 필기를 완전히 대체하지 못한 것은 아이패드가 순발력이 떨어지기 때문입니다. 당장 책상 위에 볼펜과 종이를 집어들고 필기하는 것은 1초면 시작할 수 있지만 아이패드는 패스워드를 입력하고 앱을 실행하고 노트를 선택하고 페이지를 선택하고 확대 기능을 켜고 혹시 펜이 꺼져 있다면 펜을 켜는데 10초는 족히 걸립니다. 때문에 여전히 순발력이 필요한 메모에는 포스트잇과 볼펜을 사용하고 있습니다. 그래서 이 종이 메모를 처리할 방법이 추가로 필요하게 됩니다.

과거에 종이 메모를 디지털화하는 여러 가지 방법을 시도했지만 가장 기본적인 것이 가장 좋은 방법이었습니다. 종이 메모는 스캐너로 스캔합니다. 사용하는 제품은 ‘BenQ CP100’ 이라는 제품인데 종이를 한장씩 스캔할 수 있습니다. 컴퓨터와 연결 없이 바로 SD카드에 스캔된 이미지를 저장하기 때문에 특히 보안 문제로 컴퓨터와 연결이 제한되는 업무 환경에도 적용 가능합니다. A4용지에 메모한 것은 그대로 스캔하고, 포스트잇은 뒷면이 끈적거리기 때문에 종이에 붙여 스캔합니다. A4 전체를 600DPI로 스캔하면 이미지가 5000x7000 정도이기 때문에 포스트잇을 스캔할 때는 종이를 반 접거나 반에 반으로 접은 다음 그 위에 붙여서 스캔하면 용량과 스캔 시간을 줄일 수 있습니다. 이 스캐너는 작고 편하고 군더더기 없지만 종이 투입부 설계가 저질이라 종이를 똑바로, 걸리지 않고 집어넣는데는 적응 기간이 필요합니다. 제조사가 이런 문제를 인지하고 있다면 다음 버전에서는 개선될 가능성도 있습니다.

마지막으로 스캐너에서 매번 SD카드를 뽑아 카메라킷을 통해 아이패드로 옮기는걸 몇주 해보니 귀찮아 환장하겠길래 ‘Eye-Fi’ 카드를 사용하기 시작했습니다. SD카드와 똑같이 생겼는데 속에 와이파이 기능이 들어있습니다. 직접 인터넷에 접속해 지정된 장소에 업로드하거나 다이렉트 모드를 통해 스스로 핫스팟이 되어 접속한 장비로 사진을 복사할 수 있습니다. SD카드를 꽂은 장비의 전원을 끌어다 쓰기 때문에 카메라라면 배터리가 광탈하는 문제가 있지만 언제나 전원을 꽂아 놓고 쓰는 스캐너에서는 아무 문제가 없었습니다. 다만 스캐너를 가만 놔두면 알아서 전원을 끄는데, Eye-Fi 카드 사정을 봐주지 않기 때문에 전송량이 많을 경우 중간에 끊길 수도 있습니다. 물론 다음 번에 스캐너를 켜면 이어서 전송하므로 큰 문제는 아닙니다. 참고로 Eye-Fi 자체는 잘 동작하지만 데스크탑이나 아이패드용 소프트웨어가 쓰레기같아 처음 사용할 때 혈압이 좀 오를 수 있습니다. :(

여기까지가 지금 사용하는 디지털 메모 환경 전부입니다. 요약하면 아이패드에 메모 앱은 ‘Noteshelf’, 필압감지 펜은 ‘pogo-connect’, 종이 메모 스캔은 ‘BenQ CP100’, 무선 전송은 ‘Eye-Fi’ 카드를 사용합니다. 크게 완전한 디지털 메모와 종이 메모를 디지털화 하는 두 부분으로 나눠져 있고 만약 아이패드 필기 쪽에 순발력이 보강된다면 종이 메모 부분을 대체할 수도 있겠지만 아직은 갈 길이 멀다는 생각입니다. 메모를 디지털화해서 얻은 것에는 더 이상 메모를 잃지 않게 되었다는 것과 종이 필기가 유실되면서 함께 유실되는 짧은 생각이나 대화 같은 것들이 더 이상 사라지지 않게 되었다는 점입니다. 단점은 여전히 OCR을 통한 검색은 요원하다는 것입니다. 디지털 메모를 처음 시도한 약 10년 전이나 지금이나 별로 달라진 것이 없다는 점은 절망적이지만 그 각각을 구성하는 환경은 적어도 10년 전보다는 ‘덜 실험적’이고, ‘좀더 안정적’이며 ‘장기간 활용’ 가능한 제품들로 변해가고 있다는 점은 희망적입니다. 게다가 10년 전과 달리 지금은 스캔한 이미지는 자동으로 에버노트에 올라가고 Noteshelf에서 내보낸 PDF 파일은 바로바로 드랍박스에 올라가는 것만 하더라도 메모 환경 전체를 어우를만한 큰 발전입니다. :) … 결론이 이상하지만 뭐 여튼 끝.

게임디자인 문서에 대한 생각

Sat, 02 Mar 2013 13:51:00 +0900

게임디자인 하는 사람이 만드는 모든 문서는 결국 생각을 공유하기 위한 것입니다. 가끔 이야기하다 보면 게임디자이너가 문서를 쓰는 사람이라고 이야기하시는 분도 있지만 제 생각은 게임디자이너는 뭔가 재미있는걸 생각해내서 함께 일하는 다른 스탭들에게 전달해 그들로부터 제작에 도움을 받는 역할을 하는 것입니다. 게임디자이너가 아무리 좋은 혹은 재미있는 생각을 했다고 하더라도 이걸 함께 일하는 스탭들에게 제대로 전달하지 못하면 게임 근처에도 못 가보게 되죠. 모든 글쓰기가 그렇겠지만 공유하기 위해 논리적으로 문제가 없어야 하고 서로 중복되는 내용이 없고, 전체를 포괄할 수 있어야 한다고도 합니다. 그렇지 않으면 전달하고자 하는 생각을 온전히 문서에 담을 수도 없도 당연히 읽는 사람에게 전달하거나 이해시키기도 어려워요.

문서는 항상 변합니다. 게임디자이너는 천재가 아니고 아인슈타인처럼 머릿속으로 시뮬레이션을 할 수 있는 수준이 아닌 이상 한 방에 재미있는 것을 생각해낼 수는 없어요. 게임디자이너가 다른 스탭들보다 조금 더 나은 점은 게임을 좀 더 많이 해서 경험이 있다거나, 생각을 조금 더 해봐서 머릿속 시뮬레이션에 아주 조금 더 익숙하다거나 하는 것들 뿐입니다. 덕분에 생각을 문서로 옮겨 다른 스탭들의 도움을 빌려 무사히 동작하는 뭔가를 만들었다고 하더라도 이게 재미있으리라는 보장이 없습니다. 또 동작하는 뭔가를 만들기도 전에 온갖 문제점이 발견되기도 합니다. 이때 필요한 것은 생각을 수정하고 이를 문서에 반영하는 것입니다. 개발에 들어간 문서는 정신 없이 수정되기 마련입니다. 게임디자이너 자신이 수정하는 것 뿐 아니라 함께 일하는 다른 스탭들이 게임디자이너의 실수를 찾아내고 개발을 계속하는 과정에서 돌아가는 뭔가도, 이를 뒷받침하는 문서도 게임디자이너가 작성했던 처음보다는 훨씬 나아집니다.

변화를 공유하기 어려운 형식은 문서를 죽게 만듭니다. 방금 이야기한 상황 때문에 문서는 변하고 이건 항상 공유되어야 합니다. 문서를 그때그때 고치고 공유하는 일은 생각보다 훨씬 어려워서 문서를 고쳐서 다시 공유하는 것 자체에 의미를 두지 않고 동작하는 게임 자체에만 의미를 두고 문서는 초기 논의 단계의 자료 정도로 생각하는 경우도 있습니다. (개인적으로는 이쪽을 지지합니다.) 개발 진행에 따라 처음 문서에 썼던 내용은 사정없이 바뀝니다. 하지만 이 바뀌는 논의 과정에 참여하지 못한 스탭들에게도 내용을 전달해야 하는데 이 과정에서 공유하기 어려운 형식이나 체계는 서로를 힘들게 만듭니다. 2013 년에도 문서를 워드프로세서로 작성해서 공유디렉토리에 올려놓는 참상을 떠올려봅시다. 혹은 문서 제목 뒤에 ‘20130302’를 붙이거나, 이 뒤에 또다시 ‘최종’을 붙이거나, 이 뒤에 또다시 ‘(수정)’을 붙이거나, 이것도 모자라 그 뒤에 다시 ‘김노인 수정’을 붙이는 참상을 생각해봅시다. 이런 과정을 아무렇지도 않게 반복하다 보면 자연스레 문서는 죽게 됩니다. 사실 이 과정을 반복하기도 전에 서기 2013년에 문서를 워드프로세서로 작성하면 저장하고 문서를 닫는 순간 문서는 죽게 됩니다. 이 시점부터 문서는 마치 냉동인간이나 미라와 다름없어요.

변화를 공유하기 편한 방식이 전부는 아닙니다. 워드프로세서에 쓴 문서가 저장하고 닫자마자 죽게 된다고 앞에서 주장했는데, 그렇다면 다른 문서 형식이 필요하다는 이야기인가. 반은 그렇고 나머지 반은 아닙니다. 위와 같은 문제를 겪고 나서 처음에는 워드프로세서로 작성한 문서를 형상관리도구를 통해 관리해 최소한 문서 뒤에 ‘_20130302’를 붙이는 참사를 피했지만 별 소용이 없었습니다. 워드프로세서에 작성한 문서는 저장한 즉시 냉동인간이 되고 마니까요. 그래서 일부 스탭들의 반발을 가볍게 무시하고 위키를 사용하기 시작합니다. 지금은 동네 개발팀에 물어보면 어지간하면 다들 위키를 사용한다고 합니다. 형상관리도구를 따로 사용하지 않아도 되고 공유가 편리하며 아무나 마구 수정해도 안전합니다. 그렇게 해서 게임디자이너의 생각을 모든 스탭에게 잘 전달할 수 있었느냐 하면 그렇지 않았습니다. 이 정보는 어쨌든 위키에 올라가 있었을 뿐 필요한 순간에 적절하게 제공되지 않았습니다.

문서 혹은 정보는 필요한 순간에 적절한 정보가 제공되어야 합니다. 스토리가 있는 게임을 만들 때 일어나는 일을 잠깐 상상해봅시다. 스토리에는 어쩌면 인물, 사건, 장소, 물건, 역사 같은 것들이 필요할지도 모릅니다. 이런 것들이 어디에 어떻게 정리되어 있는지 생각해 보자는 거죠. 인물은 어쩌면 ‘인물’이라는 파일 이름이나 별도의 위키 페이지에 정리되어 있을지도 모릅니다. 소개가 길다면 인물 별로 서로 다른 페이지에 기록 되어 있겠죠. 사건이나 장소도 마찬가지입니다. 특히 장소는 전체 맵에서 어디쯤인지 표시하는 그림파일 하나를 포함하고 있을지도 모릅니다. 물건은 조금 다른데, 문서에는 물건의 특징에 대한 최소한의 언급이 있겠지만 실제 물건은 ‘Item.xls’ 같은 곳에 실제 데이터화 되어 기록되어 있을 가능성이 있습니다. 이 상황이 문제입니다. 하다못해 음성 더빙을 위해 더빙이 필요한 대사만 추려낸다든지, 사건이 일어날 장소 사이의 동선에 적당한지 체크해 본다든지, 진행에 필요한 물건이 제대로 분배되었는지를 체크해보기 위해 언제나 기존 문서를 참고해 별도의 문서를 작성하는 일을 반복합니다. ‘액트3 강남구 동선 체크.ppt’나, ‘퀘스트 아이템 사용 현황.xls’ 같은 파일을 만들게 될지도 모릅니다. 이런 데이터는 스냅샷이라 만드는 순간 최신 데이터가 아니기 때문에 인간이 계속해서 관리해야 하고 새로운 종류의 스냅샷이 필요할 때마다 인간의 관리부담이 늘어나게 됩니다. 애초에 인간이 관리할 수 있는 형태가 아니며 관리되지 않는 이상 제대로 된 정보라고 보기도 어렵고 인간이 만드는 이상 필요한 순간에 적절히 제공될 수도 없습니다.

한동안 대 유행이던 ‘의미 기반의 웹’에서 아이디어를 얻어와 봅시다. 별 지식이 없는 제 입장에서 간단히 이해해 보면 ‘사과’라는 단어를 컴퓨터에게 알려줄 때 이게 과일이고, 과일에 대한 정의를 다시 알려주고, 문서에 표현할 때 과일은 밑줄을 그으라는 식으로 표현과 의미를 구분해서 데이터 처리에 활용하자는 개념입니다. 단어에 밑줄을 그을 생각이라면 그냥 밑줄을 그으면 되겠지만 이 밑줄의 의미는 인간만 알 수 있고 기계 처리를 할 수는 없습니다. 하지만 단어에 의미를 부여하고 의미에 형식을 부여하면 인간은 형식을 보고 기계는 의미를 처리할 수 있게 됩니다. 게임 라이터가 시나리오를 쓰는 장면을 한번 상상해보죠. 강남역 사거리에서 싸이가 노래를 부르며 말춤 스킬을 쓰는 장면을 글로 쓰려고 합니다. 이때 ‘강남역 사거리’는 이미 장소 목록에 들어있고, ‘싸이’는 인물 목록에, ‘말춤’은 스킬 목록에 들어있어요. ‘강남역 사거리’라고 입력하면 마치 프로그래머들이 쓰는 도구처럼 강ㄴ 까지 치면 알아서 나머지 단어를 제안해주고 이게 장소라는 사실도 함께 제공 받을 수 있어요. 문장을 완성해 가면서 사용하는 각각의 단어가 의미에 맞게 사용되는지 점검하는 동시에 라이터가 쓴 글 자체가 데이터로써 의미를 가질 수도 있어요. 이제 ‘음성 더빙을 해야 하는 캐릭터 수’나, ‘대사 목록’, ‘스킬 목록’, ‘장소 목록’ 같은 것들을 인간이 정리하는 대신 기계가 자동으로 추려낼 수 있고 인간은 이 일에서 해방됨과 동시에 실수의 위협으로부터 자유로워질 수 있습니다.

지난 주에 스팀에서 ‘Articy:Draft‘라는 도구를 봤는데 그걸 보니까 이런 생각이 들더라구요. 이 도구는 방금까지 너절하게 - TL;DR - 적어둔 여러 가지 상황을 만족시킬 가능성이 있는 도구입니다. 일단은 게임 라이팅을 하는 상황을 생각하고 만들기 시작한 도구인 것 같습니다. 실제로는 스팀에 소개되기 전부터 꽤 비싼 가격 - 수백 유로! - 에 팔리던 소프트웨어이고 지금은 Q2에 메이저 업데이트를 위해 스팀에 저가로 이전 버전을 판매하는 행사를 하는 모양입니다. 게임 라이팅에는 여러 갈래로 갈라진 인터랙티브 스토리텔링이 필요하고 여기에는 사람 머리로 관리하기에는 여러 가지 문제가 생길 수준으로 많은 인물, 장소, 물건, 사건, 여기에 따른 수많은 대사와 온갖 상황이 함께 해야 합니다. 아마도 이걸 쓰자마자 죽어버리는 것이 확실한 워드프로세서에 적는다거나, ‘사건 현황 정리.xlsx’ 같은 파일 따위로 만들어 관리한다면 누군가의 머리가 녹아버리거나 빈틈이 생겨 고객들을 실망시킬 수밖에 없겠죠. 하지만 이 도구를 사용해 스토리에 필요한 여러 가지 요소에 의미를 부여해 관리하기 시작하면 거대한 스토리를 실제 개발하기 위한 온갖 데이터를 뽑아내기 훨씬 수월해지고 실수할 여지도 줄어들 겁니다.

가까이는 스토리텔링과 레벨디자인에 한정한 도구이기는 하지만 이런 개념을 나아가 게임디자이너가 만드는 대부분의 자료에 응용할 수 있습니다. 저 도구를 직접 활용할 수 없다고 하더라도 여러 시스템 각각을 설명한 문서가 형상관리도구나 위키의 어딘가에 단순히 트리 구조를 통한 카테고리 분류만으로 올라가 있는 것은 위에서 이야기한 ‘적절한 순간에 제공’할 수 없을 뿐 아니라 시스템 간의 의존성을 판단하기도 어렵습니다. 그래서 늘 기획서 대로 개발하다 보면 빈 공간이 생기는 거고, 이건 빈 공간을 미리 발견하지 못한 게임디자이너나 프로그래머의 잘못일 수도 있지만 이 자체가 잘못이 아니라 이미 게임 프로젝트가 인간이 통제해낼 수 있는 범위를 벗어났다고 봅니다. 때문에 이를 해결하기 위해 컨텐츠 뿐 아니라 시스템에 대한 문서도 시스템 간의 관계를 정의해 두면 시스템의 빈틈을 더 쉽게 발견하고 문서를 필요한 시점에 제공할 수 있게 될 겁니다.

뭐 별 영양가도 없는게 길이만 길어졌는데, 인터렉티브 스토리텔링 분야도 그렇고, 게임 시스템 디자인 분야도 그렇고 전통적인 관리 시스템으로는 프로젝트를 유지하고 진행하기 어려운 시대가 오고 말았습니다. 이미 몇 년 전에 왔지만 이걸 인력으로 어떻게든 커버하고 있었는데, 인력 대신 기계에게 관리를 맡기고 인간은 게임의 재미 자체와 효율적인 구현에 더 관심을 쏟아야 합니다. 이를 위해 전통적인 문서 작성 및 관리 방식에 대해 이대로 정말 괜찮은가! 하는 심각한 고민을 해야 하고 위에서 이야기한 도구로부터 힌트를 얻을 수 있습니다. 다음에는 저 위에 이야기한 도구를 며칠 더 써보고 나서 마저 이야기를 해보죠. 끝.

풀터치폰과 모바일게임

Sun, 17 Feb 2013 12:17:29 +0900

수년 전에 컴퓨터나 음악플레이어를 만들며 그럭저럭 살아가던 한 회사에서 핸드폰을 내놨습니다. 별로 새로울 것도 없었어요. 비슷한 핸드폰을 만들던 회사들이 십년 전부터 똑같은 핸드폰을 만들고 있었고, 그런 핸드폰은 도통 팔리지 않았어요. 그래서 다른 핸드폰 회사와 통신회사들은 이런 핸드폰을 만드는 대신 버튼이 잔뜩 달린 핸드폰을 만들어 잘 팔며 살아가고 있었고 별 일 없는 그저 그런 핸드폰 발표로 끝날 가능성이 높았어요. 하지만 우리 모두가 알다시피 신기하게도 이 핸드폰은 꽤 많이 팔렸고 반도국에 들어오는데까지 많은 시간이 걸렸지만 결국 반도국에도 들어와 여러 가지 환경을 바꾸는데 공헌했어요. 흥미로운 것은 이 핸드폰이 출시되고 나서 반도국에 들어오기 전까지 길고 긴 기다림의 기간 동안에 반도국 핸드폰 회사들이 이 핸드폰에 대한 해석이에요.

풀터치폰. 이게 초기 반도국 핸드폰 회사들이 내린 해석이었어요. 그도 그럴 것이 딱 봐도 버튼은 하나도 없고, 아니 하나 뿐이고 - 정확히는 네개지만 - 전화번호 버튼이나 통화, 끊기, 인터넷 - 씨발 - 버튼도 없는 이상한 폰이었어요. 이걸 전부 터치스크린으로 우겨 넣은게 딱 봐도 가장 큰 특징이었을 그런 핸드폰이네요. 그래서 이 핸드폰을 ‘풀터치폰’이라고 정의하고 이 핸드폰 카테고리에 비슷한 핸드폰을 개발하기 시작해요. 잘 기억나지도 않고 기억하고 싶지도 않지만 이 정의에 따라 만든 초기 핸드폰에는 누르면 진동이 오는 핸드폰이 있었는데, 생각만큼 잘 팔리진 않았나봐요. 그리고 그 이후에 몇 년 동안에 걸쳐 삽질을 거듭하며 모든 ‘풀터치폰’이 시장에서 큰 빛을 못 본 채로 사라지고 마지막에는 기계만 만들고 그 안에서 돌아가는 ‘모든’ 소프트웨어를 천조국에 다른 회사로부터 수입해다가 통째로 얹고 나서야 그럭저럭 팔기 시작해요.

신기하게도 컴퓨터랑 음악 플레이어 만들던 회사에서 내놓은 핸드폰은 그걸 발표할 때 분명히 이 핸드폰은 어떤 거라고 큰 소리로 발표했어요. 비밀리에 자기들끼리만 공유한 것도 아니고 전 세계 누구나 볼 수 있는 행사에서 ‘이 핸드폰은 데스크탑 클래스임ㅋ!’ 라고 청바지에 검정 윗도리를 입은 아저씨가 분명 말했단 말이죠. 이건 그 시대부터 지금에 이르기까지 일관된 기조에요. 그 아저씨 말을 그대로 가져오자면 ‘절름발이 같은 기능’이 아니라 ‘데스크탑 클래스’라고 했지요. 스스로 뭘 하는 기계인지, 어디쯤 속하는 기계인지 정의해 버렸어요. 실제로 그 기계가 데스크탑 클래스인지는 별로 중요한 문제가 아니에요. 어떤 시각으로 만든 기계인지, 여러분들이 이 기계와 경쟁하려면 어떻게 해석해야 하는지를 정의한 거죠. 하지만 아시다시피 ‘풀터치폰’이란 몹쓸 정의는 정설처럼 받아들여져 천조국에서 알멩이를 수입해 오기 전까지 계속됐어요.

이 사례로부터 우리는 자기 카드를 다 까놓고 플레이하는 포커 상대를 이길 수 없는 이유가 이 사람 카드 운이 너무 좋아서가 아니라 우리 대가리가 한없이 멍청하고 한번 잘못 내린 판단을 수정할 생각조차 하지 않으며 그렇게 멍청한 머리로 내린 판단을 향해 레밍들처럼 무작정 따라가 절벽으로 굴러떨어지는데 너무 익숙하기 때문이라는 것을 짐작할 수 있어요. 분명히 ‘데스크탑 클래스’라고 말했지만 이걸 ‘풀터치’라고 잘못 알아들을 수도 있죠. 원래 영어가 어려운 언어잖아요. 하지만 그걸 천조국에서 알멩이를 수입해 오기 전까지 몇 년이고 유지하는건 영어가 어려워서라고 실드를 쳐줄 수가 없어요. 이건 멍청한 거죠.

그렇게 서기 2013년이 됐는데, 이런 꼴을 또 보고 있어요. 이번에는 다들 ‘모바일 게임’이라고 말하는데, 저는 이 해석이 ‘풀터치폰’급 해석이라고 봐요. 사람들이 갑자기 콘솔게임이고 PC게임이고 때려치고 핸드폰에서 게임을 하고 있어요. 한달에 만 얼마씩 내야 하는 커다란 온라인 게임 로그에 클라이언트 로딩이 끝나고 아무 행동도 안 하다가 몇 분 후에 그냥 로그아웃하는 사람들이 ‘주목할만큼 많이’ 나타나요. 사실 이걸 ‘사람들이 모바일 게임을 하기 시작했다’고 해석하고 ‘그러니 우리도 모바일 게임을 만들자!’라는 전략을 만드는건 너무 쉬워요. 심지어는 멍청한 시각으로 보면 그럴듯해 보이기까지 해요.

하지만 더도 말고 덜도 말고 딱 장막 한장만 더 걷어내고 보자고요. 사람들이 모바일 게임을 하는 것은 분명 사실인데, 그럼 왜 모바일 게임을 하게 됐냐가 핵심이죠. 사람들 손에 어느날 ‘데스크탑 클래스’ 핸드폰이 쥐어졌어요. 그리고 이 기계는 핸드폰이 그동안 가지고 있던 특성 그대로 사람들 주머니에 들어있어요. 집에 있는 책상 위나, 등 뒤에 맨 가방 속이 아니라 주머니에 들어있어서 꺼내서 켜는데 3초도 채 걸리지 않아요. 집에 들어갈 때까지 기다리거나, 가방을 풀어 기계를 꺼내는데 걸리는 두시간이나 1분을 기다릴 필요가 없어요. 그리고 나서 어쩌다 보니 그 기계에서 게임도 돌아가는 거였어요. 꺼내는데 3초도 안 걸리고, 거의 모든 사람들 주머니에 당연하다시피 들어 있는 기계에서 어쩌다 보니 게임도 돌아가요. 그럼 이제 ‘모바일 게임’이란 해석이 ‘풀터치폰’급 해석이라는게 무슨 말인지 이해하실 거라고 생각해요.

게임과 사람들 사이 관계가 정말 가까워졌어요. 집에 가서 책상 위에 있는 컴퓨터를 켜는데 걸리는 2시간이나, 백팩에 들어있는 랩탑을 꺼내는데 걸리는 시간 1분이 아니라 주머니에 들어있는 핸드폰을 꺼내는데 걸리는 3초면 게임에 접근할 수 있고 ‘당연하게도’ 3초면 게임을 할 수 있는데 굳이 2시간이나 1분을 기다릴 이유는 정말 적어요. 이 적은 이유를 해집어 대형다중접속역할수행게임을 만들어 ‘틈새시장’을 공략할 수도 있겠네요. 이건 비밀인데, 제가 다니는 회사에서도 이런 ‘틈새시장’을 노리는 게임을 만든답니다.

자. 이건 중요한 이야기가 아니고, 이런 관점에서 ‘모바일 게임’을 만드는건 위험해요. 실상은 ‘모바일 게임’이 아니라 ‘아주 가까운 곳에 있는 게임’을 하기 시작한 거고 여기에 맞는 게임을 만들어야 해요. 게임까지 거리가 가까워졌기 때문에 그동안은 게임까지 거리가 멀다고 생각해서 게임에 별 관심이 없던 사람들도 3초면 시작할 수 있는 게임을 하기 시작했고 이 사람들을 위한 게임은 ‘모바일 게임’이 아니라 이 사람들이 흥미를 느낄 수 있는 게임이어야 하고 게임하는 사람들과 가까운 거리를 유지할 수 있는 게임이어야 해요. 그중 한 가지 해석이 모바일이 될 수도 있겠죠. 하지만 이걸 바탕으로 해서 ‘이제 사람들이 하드코어한 게임도 할거야! 이쪽으로 발전할거야!’라고 해석하는건 풀터치폰스러운 해석이라고 봐요.

멍청하게 추상적인 이야기만 늘어놓아 답답하셨겠지만 이 글은 끝까지 추상적인 이야기만 하고 끝내려고 해요. ‘풀터치폰’이라는 해석이 멍청하기 짝이 없었음을 이제는 다들 알아요. 심지어는 이런 멍청한 단어에 잘 속아넘어가는 통신사도 이제 이런 말에 속질 않죠. ‘모바일 게임’도 마찬가지에요. 몇 년이 지나면 이 해석이 잘못됐음을 모두가 알겠지만 그땐 너무 늦어요. 우리가 만들건 모바일 게임이 아니라 추상적이라 미안하지만 플레이어와 아주 가까운 게임입니다. 이쪽에서 해석해서 나온 ‘모바일 게임’이라면 인정하겠어요. 또 이런 관점에서 ‘우리도 올해부터 모바일 게임을 만들겠엉!’ 이라고 말하는건 … 음 …

다이하드: 최후의 성전

Mon, 11 Feb 2013 22:11:49 +0900

사실 쫄았습니다. 이것은 ‘다이하드가 아니다‘를 보고 이걸 보느냐 마느냐 좀 고민을 할 수밖에 없었습니다. 팬이라고 하긴 좀 그렇고, 존 맥클레인 프렌차이즈 영화를 감명깊게 봤습니다. 제 기준에서 한참 중이병에 시달리던 시대에서 지금에 이르기까지 영화에 나온 대사를 빌어 말하면 ‘날뛰는 카우보이’ 영화의 끝판왕이라고 할만 합니다. 사이먼 그루버를 헬리콥터와 함께 전깃줄 저편으로 날려버리고 낄낄거리며 공중전화로 걸어가는 장면은 비록 가족 중 아무도 납치되지 않았지만 가슴을 쓸어내리게 만들었고 덤프트럭으로 금괴를 끄집어내는 간지가이와 수송기에 수류탄을 던져 넣는 적들은 머릿속에 또렷하게 남기 충분했습니다. 하지만 전작에서 이런 강력한 상대는 간데없이 총 쏘는 장면이 어색한 ‘IT Guy’가 튀어나와 우울하게 만들더니 이번에는 이런 의견이 나타난 겁니다.

사실 전작은 존 맥클레인이 권총 두 발로 사이먼 그루버를 헬리콥터 째로 땅에 쳐박은 이후 12년 만에 나타난 거라 잔뜩 기대를 품고 봤습니다. 하지만 이번에는 지난번에 한번 실망했으니 내 시간과 돈을 - 땅 파도 1원짜리 하나 나오지 않는 것 - 쓸 것이냐 말 것이냐를 고민하게 만들었습니다. 솔직히 미안했습니다. 여튼 연휴 같지도 않은 연휴 끄트머리 저녁에 극장으로 가는 버스에 몸을 실었습니다.

자. 미괄식 같지 않은 미괄식. 결론부터 이야기하면 생각만큼 엄청나게 나쁘지는 않습니다. 스탭들은 전작들을 숙지하긴 한 것이 분명합니다. 계속되는 추적과 총질은 맥락을 따라가기 쉽지 않게 만들고 앞뒤가 잘 안 맞는 것 같은 느낌을 지워버릴 듯이 계속되는데, 들여다보면 전작 어디선가 본 적이 있는 장면들이 계속됩니다. 맥클레인이 차를 빼앗아 타는 장면은 전전작에서 지나가던 벤츠를 빼앗는 장면을 패러디한 거고 이 차로 입체교차로 난간을 부수고 떨어지는 장면 역시 전전작에 나온 바로 그 장면입니다. 심지어는 카메라로 교차되는 차선을 훑는 장면까지 비슷합니다. 물론 장갑차를 날려버리는 장면은 그리 마음에 들지는 않지만 전작에서 택시로 헬리콥터를 박살내는 장면에서 가져왔고 출발하는 헬리콥터에 매달리는 장면은 전전전작에서 탈출하는 비행기 날개에 매달린 장면에서 가져왔습니다. 게다가 클라이막스의 그 장면과 거기서 살아남는 장면 역시 전전작과 똑같습니다. 이렇다 보니 존 맥클레인 프렌차이즈를 기억하고 있다면 생각보다 깨알같이 볼 수 있습니다. 덕분에 생각만큼 나쁘지 않다고 느꼈습니다.

다이하드는 마치 스티븐 스필버그가 만든 마냥 적어도 표면적으로는 가족간의 갈등 관계가 해소되는 과정입니다. 물론 그 과정에 총질과 자동차 추격과 폭발이 계속되기는 하지만 아내를 구하고, 또 아내를 구하고, 아내에게 전화를 하고, 딸을 구하지만 아내는 못 만나기를 반복합니다. 이번에도 가족 간의 갈등 관계를 해소하는 과정이 반복되는데 이번에는 전작들과는 달리 마치 ‘인디아나존스: 최후의 성전’같은 방식을 택합니다. 어쩔 수 없이 만난 아버지와 아들이 극중 사건을 겪으며 관계를 회복하는 식입니다. 그렇다 보니 총으로 악당을 쏴죽여대며 여기저기 폭발시켜야 간신히 가족들로부터 인정받을 기회를 얻는 존 맥클레인의 아버지상과 차이가 생겨 익숙하지 않을 수도 있습니다만 핸리존스와 인디아나존스의 관계 회복 과정을 떠올려보면 나름 재미있습니다. 이번에도 존 맥클레인은 트렁크에 들어있던 온갖 무기를 쏴대며 눈앞에 보이는 온갖 것들을 때려부수는 과정을 거치고 나서야 잭 맥클레인과 갈등을 해소할 수 있었습니다. 물론 갈등 해소의 기회가 아니라 갈등 자체가 해소되는 부분은 맥클레인 형사에게 기대할 만한 장면이 아니라는 점은 동의합니다.

다만 다이하드는 대대로 이야기 진행이 2트랙으로 이루어져 있었습니다. 빌딩 전산시스템을 장악하고 사람들을 인질로 삼는 사이에 존 맥클레인이 무기를 얻어 총질을 시작하고, 공항에서 난동을 부리는 사이에 수송기가 착륙하고 공항을 제어하기 시작하며, 월스트리트 거리를 달리며 물통에 물 4온스를 담는 사이에 은행에서 금괴를 훔쳐냅니다. … 그 다음은 별로 기억나지도 않네요. 헌데 이번에는 트랙 한 개로 단순하게 진행됩니다. 존, 잭 맥클레인이 서로 만나는 시점부터는 악당 쪽의 이야기가 다른 트랙으로 진행될만한 충분한 여유 없이 맥클레인 부자는 언제나 현장에 바로바로 나타납니다. 악당이 충분히 강하지도 않고 강해질만한 여유도 없고 악당이 목적을 달성할 만한 기회도 없습니다. 게다가 중간 보스 급의 대머리 수염 아저씨는 전전전작에서 맥클레인이 12발을 맞고도 살아남은 수류탄 고작 한방에 저승으로 가시고 암만 찾아봐도 맥클레인을 상대할만한 적 같은 것은 전작과 마찬가지로 없었습니다.

온갖 쏘고 터지는 장면들은 이야기 전개를 까먹을 정도로 몰아치며 이 사이에 스토리는 어디로 증발하고 없지만 전작(들)의 장면장면을 기억한다면 깨알같이 재미있게 볼 수 있습니다. 영화 시작 전에 쫄았던 것을 생각해보면 그 정도로 쫄 것 까지는 없었습니다. 적어도 전작에 비해서는 좀 더 맥클레인 영화 같습니다.

아인슈타인 급이 아니면 직접 프로토타이핑 합시다.

Sun, 03 Feb 2013 15:36:46 +0900

정확히 기억나지 않는 드라마 하우스 에피소드 중에서 하우스가 총에 맞아 꿈을 꾸는 화가 있습니다. 아마 시즌3 끄트머리였을텐데, 꿈 속에서 환자를 진료하기 위해 스탭들과 감별 진단을 하는데 평소같으면 하우스 입장에서 도움이 안될 법한 의견을 내놓던 사람들이 갑자기 하우스가 생각하고 있던 정답과 그에 대한 이유를 쉽게 이야기해 버리는 겁니다. 하우스는 한동안 이게 이상하다고 생각하지만 어느 순간 이게 꿈이고 스탭들이 그렇게 말할 수 있는 이유는 모두 다 자기 머리 속에서 일어나는 일이기 때문이라는 사실을 깨닫게 됩니다.

사실 이 에피소드가 이런 이야기를 시작하려고 만들어진 것은 아니겠지만 굳이 내 방식대로 내 생활에 적용해보자면 온갖 의사소통활동 중에 가장 빠르고 효율적인 것은 자기 머리속에서 일어나는 의하소통활동입니다. 물리적인 거리가 0에 가깝고 굳이 의자에서 일어나 파티션 몇 개를 지나 어릴 때부터 학습해왔지만 여전히 익숙하지 않은 의사소통 방식인 말을 통하는 대신 머리속에 이미지를 띄워 이걸 직접 주고받을 수도 있습니다.

프로토타입 없이 새로운 게임 메카닉을 개발하는 흔한 광경을 상상해 봅시다. 새로운 게임을 만들거나 게임에 새로운 룰을 추가하려고 합니다. 일단 뭔가 아이디어가 필요할테니 갖가지 방법으로 머리 속에 룰을 하나 떠올립니다. 다음에는 키보드를 열심히 두드려 문서로 만듭니다. 그걸 들고 다른 게임디자이너들이 가득 모인 리뷰 회의에서 종이나 화면을 통해 구경시키며 상상해 문제점을 파악한 다음 문서를 보강해 개발을 요청합니다.

어째서 이런 대참사가 아무렇지도 않게 일어날까요. 프로토타입 비용이 비싸다고 생각해서일 수 있습니다. 프로토타입을 만들려면 ‘검증이 필요한 아이디어’를 예쁘게 문서로 만든 다음 프로그래머를 잘 꼬셔서 개발해 이걸 플레이 해서 확인해야 합니다. 개발자는 멀고 리뷰 회의는 가깝습니다. 만약 프로그래머를 거쳐 만든 프로토타입이 생각과 다르면 이를 어쩌면 좋은가요. 프로그래머에게는 뭐라고 말하면 좋을까요. 님이 지난 2주간 만든 코드를 다 버리게 됐으니 지지난주 월요일 리비전으로 돌아가자고 해야 할까요? 종종 이게 잘 안돼서 분명히 개발팀도 구리다고 생각했을법한 이상한 메카닉이 라이브까지 굴러나오기도 합니다.

프로토타입이 비싼 것은 아닙니다. 개발 비용 자체가 비싼 것에 가깝습니다. 우리 같은 초급 디자이너들은 프로그래머가 우리보다 비싸다는 사실을 경험을 통해 잘 알고 있습니다. 이 사람들을 통해 프로토타입을 만들면 당연히 비쌉니다. 그렇다고 프로토타입 대신 회의실에서 하는 리뷰질로 메카닉을 판단할 수는 없습니다. 싼게 비지떡입니다. 우리, 혹은 리뷰 회의에 참가한 사람들이 머리 속으로 엘리베이터 추락 실험을 할 수준이 아닌 이상 불가능합니다. 메카닉을 판단하기 위해 프로토타입은 필요합니다.

사실 이미 답을 알고 있습니다. 디자이너 레벨에서 프로토타입 단계를 직접 실행하는 겁니다. 일단 우리가 직접 움직이는 것은 어떻게 해도 프로그래머를 움직이는 것보다 비용이 적습니다. 프로그래머를 움직이려면 어지간해서는 예쁜 문서작업과 전달이 필요합니다. 이걸 줄이려면 프로그래머 옆자리에 앉든가 그게 아니면 꼼짝 없이 문서질 하고 프로그래머가 파악한 다음, 만들기도 전에 보이는 이상한 점을 고쳐 서로 싱크한 다음 개발하고 그 사이에 디자이너는 적어도 이 업무에 대해서는 손가락을 빠는 불행한 일이 벌어지고 맙니다.

디자이너가 직접 프로토타입을 만들어야 합니다. 온갖 이유에도 불구하고 우리 같은 초급 디자이너들의 상상력이 부족해 적당한 프로토타입 방법을 찾아내지 못하고 있을 뿐 온갖 희한하고 편안한 방법이 널린 시대입니다. 전뇌화 시술을 받은 다음 프로그래머 뒤통수에 선을 꽂고 직접 디자인을 전달할 계획이 아니라면 디자이너의 머리속에서 시작해 디자이너의 손에서 끝내는 것이 새로운 게임 메카닉을 개발하기에 가장 좋은 방법입니다. 가장 좋은 방법이라고 해서 회의실에서 리뷰질을 하는 것이 그 다음으로 좋은 방법이라는 이야기는 아닙니다. 이건 똥이고요.

이메일 구성 변경 - 그래도 익스체인지를 쓰겠다.

Sun, 16 Dec 2012 02:29:38 +0900

2004년부터 지금까지 지메일을 사용해 왔습니다. 거의 10년어치에 달하는 이메일이 한 곳에 모여 있고 이건 대단한 장점이자 대단한 가치입니다. 지메일은 처음엔 용량 외에 별 기능이 없었지만 시간이 지남에 따라 POP를 지원하고 나중에는 IMAP도 지원했으며 익스체인지 서버도 지원했습니다. 이보다 끝내주는 이메일 서비스는 적어도 지구상에는 없었습니다. 블랙베리를 쓰기 시작하고 이어 아이폰을 쓰면서 지메일에 크게 의존하게 된 계기가 바로 익스체인지 서버였습니다. 블랙베리를 쓰지 않아도 이메일, 캘린더, 주소록을 실시간으로 동기화할 수 있었습니다.

내년 1월부터는 더이상 지메일은 익스체인지 서버를 지원하지 않게 된다고 합니다. 구글 블로그에 공지도 있어요. 이게 무슨 말이냐면 지금 사용하는 아이폰, 아이패드, 맥에서 메일과 캘린더와 주소록을 실시간으로 받을 수 없게 된다는 이야기입니다. 여전히 지메일 전용 설정을 사용해 메일에 접근할 수 있지만 이건 일정 주기마다 서버에 접속해 변경을 확인하는 방식으로 ‘일정 주기’만큼 딜레이가 생깁니다. 만약 좀 더 메일을 자주 받아오면 그만큼 배터리 소모가 커지고, 반대로 배터리 소모를 줄이기 위해 ‘일정 주기’를 길게 설정하면 이메일은 점점 더 늦게 오게 됩니다. 지메일과 아이폰을 사용한다면 실시간 이메일은 이제 꿈도 희망도 없게 된 겁니다.

다만 아주 작은 여지는 있습니다. 하나는 지금 익스체인지를 설정해서 쓰고 있는 사람들은 문제가 없다는 겁니다. 그냥 쓰던 대로 계속해서 쓰면 됩니다. 다만 새로 설정하는 것은 불가능합니다. 새로 지메일에 가입해서 익스체인지 설정을 사용할 수 없고 기존에 사용하던 사람들도 핸드폰을 바꾼다든지 해서 이메일 설정을 새로 시도하면 지메일에 익스체인지를 더 이상 사용할 수 없게 됩니다. 그래서 지금 익스체인지를 쓰고 있다면 핸드폰도 바꾸지 말고 실수로 설정을 지우거나 하지 않도록 조심하며 천년 만년 사용하면 됩니다.

다른 한 가지 여지는 구글 앱스입니다. 구글 앱스는 얼마 전에 완전히 유료화됐지만 그 전에 계정을 만들어 사용하던 사람들에게는 여전히 10명까지는 무료입니다. 그리고 이번 지메일의 익스체인지 서버 지원과 관계 없이 계속해서 익스체인지 서버가 지원됩니다. 그래서 이전에 구글 앱스에 계정이 있거나, 구글 앱스에 한달, 한명에 5달러를 내고 사용하기로 한다면 여전히 지메일과 익스체인지 서버를 사용할 수 있습니다.

저는 제 도메인을 가지고 있어서 이전에는 DNSEver에서 지원하는 메일 포워딩 기능을 사용했습니다. 메일 포워딩은 도메인 하위에 이메일 주소를 마구 생성해서 원하는 타겟 주소로 포워딩하는 기능인데 새로운 이메일 계정이 필요할 때 아주 편리하게 사용했습니다. 예를 들어 곧 없어질 제 MSN메신저 계정 이름은 ‘msn@neoocean.net’ 입니다. 아이튠즈 미국 계정은 ‘*-us@neoocean.net’ 입니다. 이런 식으로 이메일 계정이 필요할 때마다 포워딩을 만든 다음 메인으로 사용하는 지메일 계정으로 포워딩하도록 설정해 사용해 왔습니다. 그리고 이 메일은 모두 익스체인지 서버를 통해 실시간으로 아이폰에 동기화됐습니다. 헌데 이걸 못 쓰게 된 거지요.

현재 이메일 구성:

2004년부터 지메일을 쓰고 있음.
DNSEver의 이메일 포워딩을 통해 여러 개의 이메일 계정을 사용.
그래서 지메일 계정을 직접 사용하기보다는 도메인으로 끝나는 이메일 계정을 사용함.

결단을 내렸습니다. 서비스가 끝나는 내년 1월까지 기다릴 필요도 없었고 그냥 쓰다가 새 아이폰을 구입할 때가 돼서야 문제에 직면하고 싶지도 않았습니다. 위에서 이야기한 두 가지 여지 중에서 두번째, 구글 앱스로 가기로 했습니다. 이전에 구글 앱스가 처음 나올 때 집적거려본 것이 이럴 때 우울하지만 도움이 됐습니다. 일단 이메일 체계 이전을 위해 다음 사항을 고려했습니다.

이메일 이전 시 고려할 사항:

구글 앱스가 완전히 유료화되는 경우를 대비해 현재 사용하는 지메일 계정은 ‘유효한 상태’로 유지해야 한다.
DNSEver의 이메일 포워딩을 통해 사용하던 이메일 주소가 모두 유지되어야 한다.
이메일은 아이폰, 아이패드, 맥에 익스체인지 서버를 통해 실시간으로 동기화 되어야 한다.

설정 과정은 단순했습니다. DNSEver에서 이메일 포워딩 설정을 모두 삭제하고 구글 앱스로 MX 레코드를 변경한 다음 잠깐 기다리면 끝입니다. 다만 위에서 지메일 계정을 ‘유효한 상태’로 유지하기 위해 구글 앱스에서 포워딩 설정을 해야 했는데 제가 원하는 것은 어느 시점에선가 지메일 계정을 열어도 그간 사용하던 이메일이 동기화 되어 있는 것입니다. 또한 지메일 계정으로 날아온 이메일도 구글 앱스 계정에서 바로 열어볼 수 있어야 했습니다. 그래서 지메일에서는 구글 앱스로, 구글 앱스에서는 지메일로 메일을 포워딩하게 했습니다. 물론 무한루프를 돌지 않도록 조금 더 신경을 써야 했습니다.

‘여러 개의 이메일 주소를 유지’하는 부분은 걱정스러웠습니다. 이전에 같은 것을 시도했었는데 제가 사용하는 이메일 주소는 10개를 넘었고 구글 앱스에서 10개 이상의 계정을 생성하려면 유료로 업그레이드 해야 했기 때문입니다. 헌데 오늘 이전을 시도하면서 보니 ‘별명 설정’이란 기능이 생겨서 아무 문제가 없게 됐습니다. DNSEver에서 사용하던 포워딩과 아주 흡사합니다.

이렇게 사용자 한 명을 생성해놓고 설정에서 별명을 추가하면 도메인 하위에 여러 개의 이메일을 한 계정으로 받아볼 수 있게 됩니다. 이걸로 이전에 사용하던 모든 이메일 주소를 같은 계정으로 받아볼 수 있게 됐습니다. 참고로 DNSEver에서 이메일 포워딩을 삭제하면 이메일 포워딩 기능이 없어져 버립니다. 검색해보니 앞으로 이메일 포워딩 서비스를 제공하지 않을 계획이라고 하니 이 기능을 사용 중이신 분들은 이전을 고려하시는 것도 좋겠습니다. 현재 이 기능을 사용하는 사람들은 계속해서 사용할 수 있지만 신규 등록은 불가능하고 포워딩을 삭제하고 나면 메뉴가 없어져 버립니다.

결론:

곧 지메일을 익스체인지 서버를 통해 동기화할 수 없게 됩니다. 캘린더, 주소록도 마찬가지. 그래서 익스체인지 서버를 쓰고 싶으면 뭔가 방법을 찾아야 합니다.
유료화되기 전에 구글 앱스 계정을 만든 적이 있고 도메인을 사용한다면 이쪽으로 옮겨 익스체인지 서버를 계속해서 사용할 수 있습니다.
DNSEver 에서 이메일 포워딩을 통해 여러 개의 이메일을 사용하고 있었다면 구글 앱스에 추가된 ‘별명’ 기능을 이용해 사용자 수를 늘리지 않고서도 이메일 주소 여러 개를 사용할 수 있습니다.
구글 앱스를 사용하더라도 도메인을 사용하고 있었다면 이메일 주소를 바꿀 필요는 없습니다.
구글 앱스를 사용하더라도 기존에 사용하던 지메일 계정에 이메일을 포워딩해 기존 메일과 새 메일을 한 곳에 보관하도록 하면 언젠가 편리하게 사용할 날이 옵니다.
참고로 구글 앱스를 유료로 사용하면 한달, 한명당 이용요금은 $5 이며 지원되는 공간은 25기가입니다. (기존 사용자는 10명까지는 무료입니다.)

… 이메일을 이렇게 쓰는 사람은 드물 것 같아 아무에게도 도움이 안될 것 같지만 … 일단 기록으로 남겨 둡니다. 끝.

얼음정수기 - 얼음이 그렇게도 중요했나?

Sat, 08 Dec 2012 11:42:45 +0900

얼마 전에 회사 탕비실에 정수기가 새로 들어왔습니다. 이전에 있던 정수기는 온수와 냉수 꼭지가 각각 하나씩 달린 회색 플라스틱 껍데기가 오래되어 누렇게 뜬 그런 정수기였는데 필터 청소를 언제 하는지는 몰라도 물맛이 상당히 수상한 그런 정수기였습니다. 그런데 어느날 가보니 이게 갑자기 쨔쟌!! 최신 얼음정수기로 바뀌어 있었던 겁니다. 집에는 텔레비전이 없지만 밖에서 이 얼음정수기 광고를 줄기차게 하는걸 봤습니다. 아이가 엄마한테 ‘엄마 우리집은?’ 막 이러면서 부모들 속을 긁어버리는 잔인한 광고였습니다. 여튼 얼음이 나온다니 재미있다 싶었는데 그게 탕비실에 나타났습니다.

오. 벌써 생긴것부터 번들번들 까무잡잡한 것이 뜨거운 나라에서 오래 살다 온 탄탄한 근육질입니다. 물 받는 곳 위로 부드럽게 꺾인 곡선도 눈에 띄는군요. 여기에 왼편에는 바로 이 정수기의 핵심 기능이자 ‘엄마. 그럼 우리 집은?’ 이라며 약을 올리던 바로 그 놀라운 얼음 나오는 부분이 자리잡고 있습니다. 게다가 총무부서에서 얼음 나오는 자리 위에는 귀엽게 ‘얼음을 사용하려면 여기를 누르세요’ 라고 붉은 스티커에 적어놓기까지 했습니다. 이제 네스프레소로 커피를 내려 찬물을 부어 마시는 대신 얼음을 넣고 레알 아이스아메리카노 간지를 낼 수 있는 바로 그 순간이 찾아왔습니다. 모든 직원들이 칭송에 마지않으며 딸랑딸랑 얼음끼리 몸을 부벼 내는 맑은 소리가 나는 잔을 부여잡고 개발에 매진하려는

바로 그때였습니다. 누군가 컵라면 뚜껑을 따 들고 온갖 화학조미료로 가득한 저열한 스프를 면 위에 정성스럽게 뿌린 채로 정수기 앞으로 걸어오고 있었습니다. 아니. 얼음도 나오는 최첨단 정수기에 감히 컵라면질이라니. 이건 ‘엄마. 그럼 우리 집은?’ 급의 정수기에 어울리지 않는 행동이라고 생각했지만 허기에 지친 그의 표정은 차마 정수기의 품격을 위해 앞을 가로막을을 수 없도록 만들었고 그는 당당히 정수기 앞으로 걸어가 이전 정수기를 사용하던 본능적인 습관 그대로 정수기 왼편에 그윽한 냄새를 풍기는 팔도왕뚜껑을 밀어넣고 당당히 버튼을 - 게다가 뭔가 따뜻한 느낌의 붉은 스티커까지 붙어있는! - 눌렀습니다.

‘철커덩’ 아이스아메리카노를 만들던 맑고 깨끗한 얼음 부딪치는 소리는 온데없고 향긋하고 매콤한 스프가루가 온몸에 붙은 얼음조각이 아직 딱딱한 라면 위를 미끄러져 돌아다니고 허기로 가득한 아저씨의 표정은 황당함과 웃김과 부끄러움이 스쳐 지나간 다음 다시 고개를 돌려 나를 쳐다보며 ‘아니. 난 냉라면이 먹고싶어서’ 라고 말하기에 이르렀습니다. 이럴 때는 어떤 표정을 지어야 할 지 모르겠어. 가 아니라 잠시 허기와 황당함으로 가득한 그의 표정에 있는 힘껏 비난을 가득 담은 손가락질을 퍼부으며 ‘ㅋㅋㅋㅋㅋㅋㅋㅋ’를 날려 주었습니다. 결국 아저씨의 허기를 달래려던 라면은 얼음을 집어내는 대 수술을 거친 후에야 그의 위장에 온전히 그의 생을 의미있게 마칠 수 있었습니다.

저는 비겁하게 허기진 아저씨의 웃긴 행동에 비난을 날렸지만 사실 비난 받아 마땅한 것은 이 정수기를 만든 자들입니다. 정수기를 사용하는 사람들은 정수기에 달린 두 개의 꼭지를 보고 지금까지의 경험으로 미루어 하나는 온수, 하나는 냉수라고 생각할 것입니다. 조금 더 자세하게 이야기하면 일반적으로 왼쪽 꼭지는 주로 붉은 계통으로 칠해져 있고 온수가 나오며 오른쪽 꼭지는 주로 푸른 계통으로 칠해져 있고 냉수가 나오게 되어 있습니다. 이게 정수기 사업자들간의 어떤 약속에 의한 것인지는 잘 모르겠지만 정수기 대부분이 이런 배치를 취합니다. 장점은 아무 회사 정수기와 맞닥뜨려도 일단 왼쪽 꼭지에 라면 국물을 받고 오른쪽 꼭지로 물을 받아 마시려고 시도하면 대부분 실패하지 않습니다.

그런데 이 정수기는 이런 경험에 정면으로 도전합니다. 이 정수기에 달린 꼭지 두 개는 더 이상 온수와 냉수용이 아닙니다. 왼쪽은 얼음, 오른쪽은 물이 나옵니다. 뭐 얼음 나오는 정수기를 만들다 보니 얼음 기능이 더운물만큼 중요해서, 혹은 정수기 앞에 꼭지 세 개를 달자니 기계가 두꺼워져서 등등의 이유로 하는 수 없이 꼭지 둘 중 하나에 얼음 기능을 부여했을지도 모릅니다. 하지만 이건 기존 정수기 사용 경험을 완전히 무시하는 시도입니다. 회사에서 제가 본 것만 세 번의 라면 위에 얼음을 붓는 사례가 있었습니다. 이게 새 정수기에 적응하지 못한 꼴보수가 라면만 먹어서 생긴 상황일까요? 아닙니다. 이건 정수기 만드는 작자들이 자기들은 정작 정수기를 사용하지 않거나 예전의 그 냉장고처럼 회사 밖에 있는 정수기를 써보 적이 없어서 자기들이 정수기에 무슨 짓을 하는지 잘 몰랐을 가능성이 있습니다. 얼음 기능을 그렇게 넣고 싶었고 이게 중요한 기능이라면 온수, 냉수 꼭지를 그 자리에 남겨 놓고 어딘가 다른 위치를 찾거나 아니면 얼음 나오는 곳 위에 대문짝만하게 얼음 그림이라도 그려놔야 했습니다.

다른 한 가지 문제는 아마 짐작하실 수 있겠지만 물 나오는 곳이 오른쪽 하나 뿐이라는 것과 이곳의 모드가 온수, 냉수, 정수의 세 가지가 있다는 점입니다. 물 나오는 곳은 하나, 그곳의 상태는 세 가지. 그래서 물 나오는 곳 위에 버튼 세 개가 달려 있고 그 위에 다시 전구가 하나씩 붙어 있어 지금 어떤 상태인지를 표시해줍니다. ‘냉수’ 상태가 기본인지 온수나 정수를 선택한 다음 시간이 지나면 다시 냉수로 돌아가 버립니다. 여기서도 사람들의 예상 가능한 실수가 이어집니다. 녹차 티백을 넣어 들고 냉수를 붓거나, 라면에 얼음을 넣은 것도 불쌍해 죽겠는 허기진 아저씨가 이번에는 라면에 냉수나 정수를 붓기도 합니다. 이전의 사용 경험으로는 이런 선택 없이 바로 꼭지를 밀면 물이 나왔지만 이 정수기는 다짜고짜 꼭지를 밀기 전에 버튼을 눌러야 한다고 말하는 겁니다.

게다가 이 세 가지 상태는 이 상태가 언제까지 유지될지 예측하기 어렵습니다. 온수 버튼을 눌러 라면에 물을 받은 다음 가만 놔두면 다시 냉수 상태로 돌아가는데, 이게 언제 돌아가는지 확실하지 않습니다. 그래서 앞사람이 온수 상태로 바꿔 물을 받은 것을 보고 안전하다고 생각하고 뒷사람이 라면을 뜯어 들고 가서 별 생각 없이 꼭지를 밀어 물을 부으려는 순간 냉수 상태로 돌아가고 이걸 눈치채지 못한 채 꼭지를 물면 의도하지 않게 또다시 라면에 냉수를 붓게 되는 겁니다. 이런 상황은 애초에 꼭지를 두 개로 했다면 일어나지 않았을 상황이지만 굳이 꼭지 하나를 위대한 얼음 기능에 줘버려야 했다면 이 버튼은 차라리 기계식으로 하거나, 현재 상태가 뭔지를 대문짝만하게 보여주거나, 언제 상태가 바뀔지 예상할 수 있게 만들어야 했습니다. 라면에 찬물을 부어버린 누군가가 말한 ‘아니 이럴거면 바뀌기 전에 신호등처럼 깜빡거리기라도 하든가!’도 해결책 중의 하나가 될 수 있습니다. - 물론 이게 좋은 해결책이라 생각하지는 않지만 -

그냥 몇 명이 라면에 얼음을 붓거나 냉수를 붓고 또 누군가는 녹차 티백을 찬물로 우리는 상황을 겪는 것이 이 비싸보이는 얼음정수기를 들여놓는 댓가라고 한다면 뭐 그런가보다 하면 되고 또 가만 놔두면 다들 적응해서 잘 사용하게 될 것이 틀림없지만 이 과정에서 정수기 제조회사는 아무런 피드백을 받지도 못하고 또 다음에 다른 기능을 추가한 정수기로 똑같은 실수를 반복할 거라고 생각하니 좀 답답한 생각이 들었습니다. 그리고 허기진 누군가는 또다시 단 하나뿐인 컵라면에 찬물을 부어 우적우적 딱딱한 식감을 즐겨야 하겠지요.

외부기억장치

Sun, 02 Dec 2012 10:56:00 +0900

공각기동대 TV시리즈인 ‘Stand Alone Complex’를 보면 첫 시즌 끄트머리에 웃는 남자와 소령이 종이책 도서관에서 이야기를 나누는 장면이 나옵니다. 여러 가지 상징으로 가득차 있는데, 이미 거의 모든 사람이 전뇌 시술을 받아 정보를 뇌에 직접 꽂아넣을 수 있고 직접 의사소통을 할 수 있는 시대에 의례적으로 행하는 종이 자료를 보관하는 장소에서 각자 전뇌 관련으로 최고 기술을 가진 두 사람이 각각 자기 머릿속에 있는 지식만으로 온갖 지식의 허세를 부리며 말로 대화합니다. 이 장면이 끝날 무렵 9과 과장이 등장하며 하는 첫 마디는 ‘외부기억장치를 사용하지 않으면 따라가기 어려운 대화다’인데, 이를 통해 전뇌화가 보편화된 시대에 지식의 위상을 짐작할 수 있습니다.

이런 시대는 아주 멀게 느껴집니다. 아직 사람들은 뇌의 각 부분이 어떤 역할을 담당하는지 간신히 알아냈을 뿐입니다. MRI에 사람을 눕혀 놓고 질문을 한다든지, 뭔가 상상하도록 시킨다든지 해서 뇌의 어느 부분이 반짝거리는지를 확인하는 수준에 머물러 있습니다. 이게 의미가 없는 것은 아닙니다. 이를테면 거짓말을 하려는 사람의 뇌와 그렇지 않은 사람의 뇌가 반응하는 모습은 완전히 달라 이를 여러 가지로 응용할 수 있다고 합니다. 하지만 이런 연구는 뇌 자체에 초점이 맞춰져 있고 뇌의 기억 방식을 이해해서 인간의 입출력 - 주로 오감과 말, 행동 - 을 통하지 않고 뇌에 직접 정보를 꽂아 넣는 것은 아직 요원합니다. 미래의 어느 시점엔가는 매트릭스에서처럼 목 뒤에 선을 꽂아넣고 파일을 복사하는 수준으로 언어나 운동 방법 따위를 순식간에 익히게 될지도 모릅니다.

꽤 먼 이야기를 했지만 이게 방금 한 이야기처럼 정말로 먼 이야기인가 하면 사실 그렇지는 않습니다. 지금은 서기 2012년 말이고 세계에는 아직 전뇌화한 사람도 없고 인간의 입출력을 거치지 않고 뇌에 곧바로 정보를 꽂아 넣을 기술도 없습니다. 인간의 뇌에 대한 이해를 실용화한 사례는 뇌의 특정 부위에 전기적 자극을 가해 무력화하는 수준에 머물러 있습니다. 하지만 인간의 입출력 기능을 사용하는 경우를 포함해 맨 처음에 이야기한 외부기억장치를 통한 사고는 이미 모든 사람들이 하고 있습니다. 바로 인터넷 검색입니다.

인간의 입출력 기능을 사용해서 뇌에 데이터를 복사하는 일은 동굴에 벽화를 남기던 시대부터 가능하던 이야기라 세삼스러울 것이 없다고 해도 이상하지 않습니다. 하지만 현대 이전에는 이런 외부기억장치 자체에 접근하는 일이 지금처럼 편리하지 않았습니다. 동굴에 그린 벽화는 어떤 이유로든 동굴을 떠날 때 가져갈 수 없었고 금속활자가 발명되어 인쇄한 책은 일반인이 접근하기 어려웠습니다. 소수의 사람들만이 이런 외부기억장치를 사용해 데이터를 뇌에 복사해 다른 사람들보다 더 나은 지위와 재산을 유지하는데 사용했습니다.

서기 2012년에는 이런 상황이 완전히 달라졌습니다. 바닷속에 거미줄처럼 묻힌 해저 광케이블과 세계 방방곡곡에 널려 있는 거대한 비용이 투자된 데이터센터를 통해 어지간한 사람이면 누구든 방대한 외부기억장치에 접근할 수 있게 되었습니다. 외부기억장치에 접속을 원하면 정부의 감시를 피해 몰래 책을 구해 뇌에 복사하거나, 가까운 도서관에 찾아가 종이책을 검색해내 자리에 앉아 시간을 투자해 머릿속에 복사하는 과정을 거쳐야 하던 시대에서 주머니에 있는 핸드폰을 꺼내 즉시 세계 전체의 광케이블 네트워크와 거대한 데이터센터 인프라와 거기에 데이터를 토해 놓는 수많은 사람들이 구축한 외부기억장치에 몇 초 이내로 접근할 수 있습니다. 이런 개 폼 잡는 표현을 빼고 말하자면 누구든 구글에 검색할 수 있다는 겁니다. 공각기동대에 나오는 인간의 입출력을 건너뛰에 뇌에 바로 데이터를 입력할 방법은 아직 없지만 최소한 ‘외부기억장치’ 자체에는 언제든지 접근할 수 있게 됐습니다.

외부기억장치에 대한 정의를 바꿔야 합니다. 주머니에서 핸드폰을 꺼내 검색하고 인간의 입출력을 통해 뇌에 복사하는 과정을 거쳐야 하지만 외부기억장치는 이제 내 뇌의 일부분입니다. 공각기동대에서 전뇌화 시술을 받은 사람이 인간의 입출력을 건너뛰어 다른 사람과 의사소통을 하고 정보에 접근하는 과정이 전뇌화 대신 주머니 속의 핸드폰, 혹은 무릎 위의 컴퓨터를 통하고 인간의 입출력을 통한다는 점을 제외하면 이미 전뇌화를 통한 외부기억장치에 접근하는 시대입니다. 외부기억장치는 공각기동대에서처럼 뭔가 이 세상에는 아직 없는 거창한 개념이 아니라 내 주변에 굴러다니는 온갖 장비 그 자체입니다.

이런 관점에서 현대 사회에서 검색 능력이 없다는 것은 마치 뇌의 측두엽 한쪽이 없는 것과 비슷한 위상을 가집니다. 쉽게 검색 없이 데이터가 부족한 상태로 이야기하거나 일을 처리하는 상황이 일어납니다. 예전에는 이런 일을 용납할 수 있었지만 이제는 아니라고 생각합니다. 누구든 접근할 수 있는 외부기억장치의 거대한 인프라가 개방되어 있고 비록 인간의 입출력을 사용해야 하는 한계는 있지만 시간을 들여 내 뇌에 데이터를 복사해 활용하거나 복사하는 동시에 다른 사람들에게 출력할 수도 있습니다. 이런 시대에 외부기억장치 없이, 바꿔 말하면 검색하지 않거나 데이터가 부족한 상태로 일하는 것은 이제는 뇌의 일부가 없는 채로 일하는 것과 같습니다.

외부기억장치를 사용하는 시대는 이미 와 있습니다. 당장 사용할 수 있도록 개방된 인프라는 마치 내 머리 속에 있는 것처럼 활용해야 합니다. … 현대 사회에서 검색하지 않거나 검색 능력이 부족한 것은 마치 뇌의 일부가 없는 것에 비유할만한 일입니다.

사려 깊지 않음

Sat, 01 Dec 2012 22:31:49 +0900

지하철에서 옆자리에 한 아주머니가 타고 계셨습니다. 평소에는 광역버스를 주로 타서 다른 사람들을 눈여겨볼 기회가 없지만 지하철을 타면 좀 다른데, 서 있으면 내 앞에 있는 사람을 쳐다보게 되고 앉아 있으면 내 앞에 있는 사람이나 건너편에 있는 사람을 별 수 없이 쳐다보게 됩니다. 다른 곳에서라면 서로의 시선이 불편하겠지만 지하철에서는 별 수 없죠. 상대도 저를 쳐다보고 뭐 이제 비겼습니다. 헌데 옆자리 아주머니는 커다란 핸드폰을 들고 인터넷을 통해 글을 보고 있었습니다. 내용에는 관심이 없었지만 커다란 핸드폰을 들고 글을 보는 모습을 지켜보니 두 가지가 눈에 띄였습니다.

DMB 안테나를 하늘 높이 뽑아 들고 있었습니다. 사용하는 모습으로 보아 DMB를 보고 있었던 것 같지는 않았습니다. 브라우저로 웹을 돌아다니며 글을 보는 것이 전부였는데, 조금 넘겨짚자면 저 안테나는 인터넷 신호를 더 잘 잡기 위한 목적으로 뽑아놓은 것 같았습니다. 사실 이런 경우가 드문 것은 아닙니다. DMB 기능이 있는 핸드폰을 쓰는 사람들이 그게 DMB 안테나라는 사실을 모른 채로 일단 안테나가 달려 있으니 그걸 쭉 뽑아 놓으면 전화나 인터넷이 더 잘 될 거라고 생각하는 것은 몇 년 전의 핸드폰 사용 습관에 비추어 볼 때 이해할 만한 일입니다. 누구도 그게 DMB만 쓰는 안테나이며 지금 쓰는 주파수 대역은 더 이상 그렇게 길다란 안테나를 필요로 하지 않는다는 기술적 배경을 설명해주거나 됐고 그냥 안테나 안 뽑아도 전화든 인터넷이든 잘 된다고 이야기해 주지도 않았을 겁니다.

사실 이건 단말기 제조사가 사람들이 자기들 핸드폰을 어떻게 쓰는지 관찰해본 적이 있다면 당연히 알려줘야 하는 부분이라고 생각합니다. 어쩌면 아무도 읽지 않는 진짜 두툼한 메뉴얼 어느 구석에 ‘DMB 안테나는 이외의 기능에는 아무 영향을 주지 않는다’고 써놨을 가능성도 있습니다. 하지만 제조사가 좀 더 사려 깊었다면 새 핸드폰 안테나에 스티커라도 하나 붙여 놓고 작은 글씨로 ‘이 안테나는 통화에는 영향을 주지 않는다’고 써놨어야 옳습니다. 스티커를 떼면서 한번 읽어본다면 DMB를 보고 있지도 않은데 안테나를 하늘 높이 뽑아 앞에 서 있는 사람 눈알을 찌르려고 하는 일도 없었을 겁니다. 스티커에 뭘 적든 사람들이 절대 읽지 않는다는 사실까지 접근했다면 하다못해 안테나 끄트머리를 둥글게 만들어 사람 눈을 찌를 가능성을 낮추는 것도 방법이었겠지만 어느쪽도 준비되어 있지 않아 보였습니다.

다른 한 가지, 아주머니의 커다란 핸드폰을 보며 눈에 띄인 것은 화면이 꺼지는 시간이었습니다. 브라우저로 웹을 돌아다니며 글을 읽고 있었습니다. 글은 모바일 화면에 맞게 좌우 폭이 조절되어 나타났고 한 화면에 약 15줄 내외로 나타나 있었습니다. 지켜보니 텍스트가 가득찬 화면을 모두 읽고 다음으로 스크롤하는데는 약 1분 정도 걸리고 있었는데 읽는 도중에 아무 입력이 없이 10초 정도 경과하자 화면이 어두워졌고 그 때마다 화면을 툭 쳐서 다시 밝아지게 만들기를 반복하고 있었습니다. 또 한번은 어두워진 채로 글을 읽다가 5초가 지나자 화면이 꺼져버렸습니다. 그러면 다시 핸드폰을 켜서 읽기를 반복하고 있었습니다.

이 이야기를 트위터에 올렸더니 핸드폰 설정을 바꿔주고 싶다고 말씀하시는 분들이 있었습니다. 네. 분명 핸드폰 설정 화면 어딘가에 n초 동안 입력이 없으면 화면을 어둡게 하고 이 상태에서 다시 m초간 입력이 없으면 화면을 끄라는 설정이 있을 겁니다. 화면 설정에 있거나 어쩌면 전원 관련 메뉴에 있을지도 모릅니다. 브라우저를 통해 화면에 떠 있는 텍스트를 읽는 사용 패턴에 따라 n과 m을 각각 좀더 긴 숫자로 바꿀 수 있을 것입니다. 한 화면을 보는데 약 1분 정도가 걸리니 거기에 맞춰 설정하면 가끔씩 화면을 툭 쳐서 다시 밝게 만들 수고는 필요 없습니다.

이게 뭡니까. 핸드폰이나 태블릿으로 책 볼 때 이런 바보같은 경험을 한 적은 없을 겁니다. 책 보는 앱은 충분히 사려 깊게 만들어져 책을 한참 동안 보고 있어도 화면을 그냥 꺼버리거나 하지 않습니다. 정확히는 단지 좀 더 오랜 시간 동안 화면을 켜 두고 그래도 아무 입력도 하지 않으면 그때서야 화면을 끄는 정도이지만 제가 책을 읽는 경험을 하는 동안에는 원하지 않는 때에 화면이 어두워져 난처한 적은 없었습니다. 또 책을 보다가 그냥 놓고 나갔다 돌아와서 나가 있는 내내 화면이 켜져 있어 화면이 손상되거나 원하지 않는 배터리 소모가 일어난 경험도 없었습니다. 이건 충분히 자동으로 처리할 수 있는 부분입니다. 화면에 텍스트가 잔뜩 떠 있고 조작한지 얼마 안 되었으며 주머니에 넣고 걷는 것 같지도 않고 그럼 설정보다 좀 더 오래 화면을 켜놓는 정도의 간단한 조치만으로도 충분히 브라우저로 텍스트를 읽는 경험을 개선할 수 있었을 겁니다. 조금만 더 생각한다면 새 킨들처럼 이 챕터를 다 읽는데 걸리는 시간을 표시하는 방법을 응용해 이 페이지를 다 읽는데 걸리는 시간만큼만 화면을 밝게 유지해 최대한 전원을 아낄 수도 있었을 겁니다.

이건 사려 깊지 않은 단말기 제조사와 사려 깊지 않은 운영체제 제조사가 힘을 합쳐 만든 대수롭지 않은 지나가는 사용자 한 명의 사용 경험일 뿐입니다. 제가 그 핸드폰을 쓰는 것도 아니고 그 핸드폰을 사용하는 사람이 이 상황이 별로 이상하지 않다고 느낄 수도 있습니다. 뭐 그럼 아무 일도 아닐 수도 있죠. 다만 그냥, 단말기 제조사와 운영체제 제조사 양쪽 모두 그다지 사려 깊지 않음이 아쉬웠습니다. 이런 부분이 최근 불거진 여러 가지 문제에도 불구하고 단말기와 운영체제를 한 회사에서 만드는 핸드폰을 쓰는 이유이기도 하고요.

투더문 - 제한된 표현 방법

Thu, 29 Nov 2012 22:10:00 +0900

투더문. 세일이 한창 진행 중일 때에도 별 관심이 없었습니다. 아무 정보도 없었고요. 하지만 온라인에서 몇몇 분들이 이 게임을 플레이 한다는 이야기를 들었고 평이 좋은 것을 보니 유로트럭 시뮬레이터가 스팀에 올라오기 전에 이 시류를 타봐야겠다는 생각이 들었습니다. 이야기에 대한 취향 차이 때문에 다른 분들만큼 큰 호평을 하지는 않겠지만 게임을 통해 뭔가 표현하려고 한다면 요즘 세상에서 배울만한 점이 있겠다 싶었습니다. 게임의 스토리나 진행 방식이나 음악 같은 부분은 다른 글에서 수없이 다뤘거나 다룰테니 저작 도구와 표현의 한계에 대한 이야기를 해 보려고 합니다. 한계라고 해서 특별히 혹평을 시도하려는 것은 아닙니다.

이 게임은 ‘RPG 쯔꾸르 XP’로 만들었다고 합니다. 회사에서 하고 있으니 사람들이 뒤에 와서는 ‘이자식. 대체 뭘 하는거야’란 눈빛을 느낄 수 있었습니다. 제 입장에서는 오랜만에 이런 그래픽을 보니 막 가슴이 설레였습니다. 마치 에어매니지먼트를 하면서 처음으로 이륙하는 비행기를 보는 것처럼요. 회사에서 게임을 만들기 전에는 게임 회사에 가면 이런걸 쓱쓱 만들 수 있을 줄 알았거든요. 여튼 게임은 저작 도구의 썩 좋다고는 말하기 어려운 환경과 표현의 한계 범위 안에서 만들어졌습니다. 제작자가 각각의 장면을 저작도구의 제한 속에서 어떻게 표현하면 좋을지 고민한 흔적이 곳곳에 눈에 띕니다. 이런 접근은 고대에서 중세에 이르기까지 자주 보여 왔지만 현대에는 찾기가 쉽지 않아 생각해볼 만한 주제입니다.

저작 도구는 캐릭터 스프라이트를 움직이거나 일러스트를 보여주는 것 이상의 방법을 제공하지 않습니다. 이런 환경에서 캐릭터 감정 표현은 상당히 어려운 이야기입니다. 지금이라면 캐릭터 얼굴에 카메라를 갖대 대고 얼굴 근육을 잘 움직여 표정을 만들어내는 것이 아주 어려운 일이 아니지만 거의 양 손에 달린 손가락으로 셀 수 있을 정도의 픽셀만으로 표정을 표현하는 것이 쉽지 않고 이것을 플레이어 눈에 잘 띄도록 보여주는 것은 더더욱 만만한 일이 아니라 거의 불가능합니다.

무안함을 표현하기 위해 머리 위에 말줄임표가 찍힌 말풍선을 띄웁니다. 기쁨이나 놀라움을 표현하기 위해 캐릭터가 제자리에서 점프합니다. 점프라기 보다는 스프라이트를 좀 위로 올렸다가 내립니다. 올리는 동안에는 바닥에 동그란 그림자를 깔고요. 캐릭터가 두려워하면 뒤로 한 발짝씩 물러납니다. 힘 빠진 캐릭터는 바닥에 주저 앉습니다. 위험한 상황에서는 화면 전체에 붉은 효과를 주고 회상 장면에서는 화면 전체에 오래된 테이프에 낀 노이즈 효과를 줍니다. 월드의 끝을 노골적으로 잘린 경계로 표현하기도 하고 신나는 기분을 표현하기 위해 캐릭터가 평소보다 훨씬 빨리 달립니다.

지금 게임을 만드는 입장에서는 바로 옆에 개발팀과 아트팀이 있습니다. 만약 지금 게임 시스템으로 만들 수 없을 것 같은 상황이나 표현을 하기 위해서 현재 시스템을 이용한 방법을 깊히 고민하지 않아도 비교적 쉽게 개발팀과 아트팀을 움직여 훌륭한 리소스를 게임 안에 나타낼 수 있습니다. 무안하면 무안한 표정을, 기쁨이나 놀라움 역시 얼굴에 직접 표현할 수 있습니다. 최소한 그럴싸한 일러스트나 모델 리터치 이미지를 받을 수도 있습니다. 위험한 상황이라면 카메라를 돌려 상황을 직접 보여줄 수도 있고 원한다면 컷신 담당자의 힘을 빌려 그럴싸한 영화적 기법을 사용할 수도 있습니다. 신나는 기분을 표현하기 위해 성우의 힘을 빌려 연기에 코멘트를 할 수도 있습니다.

하지만 이렇게 해서 나온 게임이 과연 ‘투더문’에 비해 정말로 여러 가지 상황과 감정을 더 잘 전달할 수 있는가 하면 꼭 그렇지는 않은 것 같습니다. 물론 책 보다는 만화가, 만화보다는 영화가 좀 더 이런 것들을 쉽게 전달할 수 있다고 알려져진 방법이지만 후자로 갈수록 비용 효율이 나빠지고 전자로부터 얻을 수 있는 상상의 기회나 이를 통한 간접 경험과 공감의 가능성은 점점 더 낮아질 것입니다.

여력이 된다면 게임의 표현은 결국 영화의 그것을 따라갈 것입니다. 이런 방법의 가격은 점점 싸지고 있기도 하구요. 다만 이런 방법을 모든 게임이 사용할 수 없고 또 모든 게임이 이런 방법에 어울리는 것도 아닙니다. 그렇다면 주어진 환경과 시스템에서 최대한의 표현을 하기 위해서는 개발팀과 아트팀에 말하기 전에 지금 가지고 있는 것 만으로도 표현할 수 있는 최대한의 방법은 없는지 좀더 많이, 좀더 깊이 고민해 봐야 합니다. 끝.

AWS Glacier 요금 체계

Thu, 22 Nov 2012 22:39:00 +0900

지난주에 Glacier와 Arq가 가정용 오프사이트 백업으로 사용하기에 적당하다는 이야기를 했습니다. 1기가당 요금이 $0.01 수준이고 가장 비싼 도쿄 데이터센터도 $0.012 수준입니다. S3는 1기가당 $0.125 정도이기 때문에 1테라 정도 올리면 상당히 압박스러운 비용이 들지만 Glacier는 그렇지 않습니다. 때문에 Glacier를 2차 백업 수단으로 사용하면 좋겠다고 이야기했었습니다. 그런데 이 스토리지 요금 외에도 검색과 다운로드에도 요금이 있고 시나리오에 따라 소위 ‘요금폭탄’을 맞을 가능성이 있기 때문에 Glacier의 요금 체계를 짚고 넘어가려고 합니다. 결론부터 이야기하면 서드퍼티 앱을 통해 통제된 상황에서 사용할 때는 납득할만한 요금 범위 내에서 사용할 수 있습니다. 하지만 통제되지 않은 상황에서 다운로드 요청이나 다운로드는 위험할 수도 있습니다.

먼저 Glacier가 데이터를 어떻게 보관하는지 알아둘 필요가 있습니다. Glacier는 비용을 낮추기 위해 다른 데이터센터처럼 언제나 모든 서버에 전력을 최대한 공급하지 않습니다. 일단 데이터를 기록하고 나면 최소한의 전력만 공급한 상태로 유지합니다. 그러다가 다운로드 요청을 하면 요청 받은 데이터를 보관한 서버를 찾아내 전력을 정상 공급하고 데이터를 언제나 전력이 공급되는 서버로 복사해온 다음 유저가 다운로드하게 해 줍니다. 이런 식으로 구성된 덕분에 S3에 비해 1/10도 안되는 비용으로 서비스를 할 수 있는 모양입니다.

이런 구조를 통해 아마존은 데이터를 다시 다운로드하는데 두 가지 요금을 적용합니다. 하나는 다운로드 요금입니다. 아마존 지역 데이터센터 바깥으로 나가는 데이터에 대해 부과되는 요금으로 한달에 1기가까지는 무료로 다운로드 할 수 있지만 그 다음 10테라까지는 1기가당 $0.201 이 청구됩니다. 100기가를 다운로드하면 $12, 1테라를 다운로드하면 $120이 든다는 이야기입니다. 한달에 100기가 언저리를 복원한다면 큰 문제가 되지는 않겠지만 테라바이트 단위를 한달 안에 다운로드한다면 부담이 될 수 있습니다. 물론 Glacier에서 대량으로 데이터를 다운로드한다는 것은 로컬 백업이 모두 유실된 꽤 심각한 상황에 한정되기 때문에 납득할 만한 수준이라고 생각합니다.

다른 하나는 ‘검색 요금(Retrieval Fee)’입니다. 이 부분이 아주 중요한데 위에서 데이터 보관 비용을 낮추기 위해 언제나 서버에 전력을 공급하지 않는다고 이야기했습니다. 그래서 Glacier는 S3와 달리 데이터 다운로드 요청을 하면 즉시 다운로드를 할 수 없습니다. 3~5시간 정도의 다운로드 준비 시간이 필요합니다. 어딘가 내 데이터가 잠들어 있는 빙산을 녹여 데이터를 꺼낸 다음 항시 전원이 들어오는 서버로 복사해 오는데 필요한 시간입니다. 그런데 이 작업 자체에 비용이 청구됩니다.

검색 비용은 한달 동안에 시간당 가장 많은 데이터 검색을 요청한 시점에 얼마만큼의 데이터를 요청했는지에 따라 매겨집니다. 다운로드를 요청한 데이터는 평균 준비시간인 4시간으로 나눠서 계산하게 됩니다. 한달에 딱 한번 10기가짜리 검색을 요청하면 한달 내내 10기가만 받았다고 해도 ‘10기가 / 4시간 * 24시간 * 30일’의 요금이 청구됩니다. 이에 비해 한달 내내 하루에 1기가씩 30일 내내 검색을 요청하면 한달에 300기가를 다운로드 하게 되더라도 요금은 ‘1기가 / 4시간 * 24시간 * 30일’만큼만 청구됩니다. 더 많은 용량을 받았지만 요금은 1/10만 내게 된다는 겁니다.

제 경우를 빗대어 현실적인 시나리오를 대입해 보겠습니다. Glacier에 500기가 정도를 올려놓았습니다. 이 중에서 90기가짜리 첫번째 애퍼처 라이브러리에 대한 다운로드 요청을 했다 칩시다. 그러면 제가 내야 하는 검색요금은 다음과 같이 계산할 수 있습니다.

시간당 최대 검색 요청량 = 90GB / 4Hr = 22.5GB
- (평균준비시간 = 4시간)
일일 무료 검색량 = 500GB * 0.05 / 30Day = 0.83GB
- (한달에 전체 용량의 5%까지 무료 검색)
시간당 최대 무료 검색량 = 0.83GB / 4Hr = 0.21GB
- (일일 무료 검색량을 평균 준비시간 4시간으로 나눔)
비용 청구 대상 최대 검색 요청량 = 22.5GB - 0.21GB = 22.29GB
- (이 용량을 기준으로 가격이 책정됩니다.)
검색 비용 = 22.29GB * 24Hr * 30Day * $0.01 = $160.5
- (약 19만원 정도)
전체 비용 = $160.5 + (90GB * $0.12) = $171.30
- (10테라 받을때까지는 1기가당 $0.12를 추가, 총 20만 5천원 정도)

500기가를 올려놓고 그중 90기가를 받는데 20만원 돈이 든다는 이야기입니다. 이 요금 체계에서 500기가를 올려놓고 500기가 전체를 요청하면 한화로 115만원 정도가 듭니다. 이래서야 아마존 무서워서 데이터를 받을 엄두가 나지 않습니다. 여기서 하나 더 짚고 넘어갈 것은 데이터 검색 요청을 하고 나서 3~5시간 뒤에 다운로드 할 수 있도록 준비되면 이후 24시간 동안만 유지된다는 점입니다. 24시간 후에는 다시 검색 요청을 해야 합니다. 만약 24시간 동안에 다운로드 할 수 있는 용량보다 더 많은 용량에 대한 검색을 요청할 경우 검색 비용을 중복해서 지불하게 될 수도 있습니다.

이런 요금 체계 때문에 Glacier에 검색을 요청할 때는 시간당 최대한 작은 크기만큼만 검색을 요청해야 요금을 줄일 수 있습니다. 위의 시나리오에서 저는 90기가를 한번에 요청해 20만원을 낼 위기에 처했지만 만약 한방에 90기가를 요청하는 대신 시간당 10기가씩 아홉번 요청한다면 검색 요금은 $16.50 만 내면 됩니다. 여기에 90기가에 대한 전송비용 $10.8 을 더하면 $27.3, 대강 3만 2천원 정도로 줄어듭니다. 하지만 집에서 한시간에 10기가를 받을 수 없다는 사실을 경험상 이미 알고 있고 이보다 더 적은 양으로 나눠 검색을 요청할 경우 요금은 더 줄어듭니다.

그래서 다운로드 비용을 통제하기 위해 업로드할 때 커다란 파일을 작게 나눠 올리고 내 회선 속도에 따라 시간당 다운로드 가능한 크기 이하만큼씩만 검색을 요청할 수 있어야 합니다. Arq를 사용해 파일 다운로드를 시도하면 회선 속도를 감지해 다운로드 속도를 지정할 수 있게 해줍니다. 속도를 지정하고 나면 초당 다운로드 속도를 기준으로 시간당 최대 검색량을 통제해 예상 비용을 표시해 줍니다. 만약 시간이 충분하다면 다운로드 속도를 낮춰 한번에 더 작은 검색 요청을 해서 비용을 더 낮출 수도 있습니다.

결론. Arq같은 서드퍼티 앱을 통해 비용을 통제해서 사용한다면 Glacier는 여전히 쿨합니다. 다운로드할 때 비용이 좀 더 많이 들지만 자동 다중화를 통한 안전한 보관을 감안하면 충분히 납득할만한 비용입니다. 하지만 비용을 통제하지 않는다면 검색 요금은 쉽게 요금 폭탄을 맞을 수 있도록 만들어져 있고 서드퍼티 앱을 사용한다고 하더라도 이런 내용을 인지하고 있는 편이 좋겠습니다.

검색 요금 계산용 구글 스프레드시트
- 맨 위에 ‘Stored Data’와 ‘Requested Data’를 채우면 됩니다.

아. 이건 참고사항인데, Glacier에서 24시간 안에 받을 수 없는 양의 데이터를 요청한 경우에 S3로 옮겨서 다운로드할 수 있습니다. 같은 지역의 AWS 데이터센터 내에서 데이터를 옮기는 비용은 무료이기 때문에 Glacier에서 데이터를 검색해낸 다음 이를 S3로 옮기고 그 후에 천천히 받으면 24시간 제한을 신경쓰지 않아도 됩니다. 현재 아마존은 이를 자동화하는 옵션이나 API를 지원하지 않고 있지만 조만간 도입할 계획이라고 하며 Arq 포럼에 따르면 Arq도 데이터의 접근 빈도, 다운로드 예상 시간, 비용 등을 고려해 Glacier와 S3 사이에 데이터를 옮기는 기능을 넣을 예정이라고 합니다. 끝.