Blog

Blog

2013년 8월의 개발일지

오늘도 어김없이 일어나 출근을 한다. 출근길에 나는 파스쿠찌[1]에서 카페라떼를 산다. 회사 근처 파스쿠찌에서는 출근 시간 테이크 아웃에 한해서 30% 할인을 해줘서 부담이 덜하다. 나는 출근 시간 15분 전에는 회사에 들어가 자리에 앉아 컴퓨터를 켠다. 오늘 따라 부팅이 느린 것이 느껴진다. 아마 어제 컴퓨터 종료할 때 실행되던 윈도우 업데이트 때문인 것 같다. 갑자기 짜증이 난다. 윈도우는 사용자 배려가 부족하다고 생각한다. 업데이트 때문에 이토록 오랜 시간 부팅 하는 OS가 또 어디 있는가? 하지만 하루를 시작하는 아침인 탓에 조금 너그럽게 생각하기로 하고 기다린다. 컴퓨터가 드디어 켜졌다.

컴퓨터를 켜자마자 구글의 크롬 브라우저(Chrome Browser)[2]를 켠다. 크롬 브라우저는 나도 모르는 사이에 자동으로 집에서 사용하는 랩톱과 내 스마트폰의 정보를 동기화하기 시작한다. 나는 익숙한 듯이 회사 출근부 페이지 주소(Uniform resource identifier, URI)[3]를 입력하고 빠르게 출근 체크를 마친다. 출근 체크 시 이상하게 제대로 체크 되었는지 한 번 더 체크하는 버릇이 있다. 강박증[4] 같기도 하지만 아마 예전에 있었던 출근부 버그 때문일 것이다. 나중에 시간이 되면 크롬 확장(Chrome extension)[5]으로 한 번에 안전하게 출근 체크하는 스크립트를 만들 것을 아주 잠깐 계획해본다.

이제 나는 구글(Google)에 로그인을 시도한다. 구글 로그인 시 2단계(2-step verification)[6] 보안 기능을 사용하고 있다. 그렇기 때문에 아이디, 비밀번호 이외에 원 타임 비밀번호를 추가로 입력해야 한다. 나는 이런 시스템이 해킹의 공포에서 자유롭게 해준다고 믿고 있다. 로그인 후 지메일(Gmail)[7]에 접속한다. 지메일은 거의 하루 종일 접속된 상태로 둔다. 얼마 전에 회사 메일 시스템을 사내 인프라 장비에서 마이크로소프트(Microsoft, 이하 MS)[8]의 office365[9]로 바꾸었다. 나는 이제 회사 메일을 지메일에서 POP3(Post Office Protocol version 3)[10]를 이용해 확인하는 것이 가능해졌다. 만세! 나는 개인적으로 지메일 인터페이스가 맘에 든다. 이렇게 훌륭한 제품을 만드는 구글은 아마 자사 직원들이 이 제품의 가장 충성도 높은 고객이 아닐까 라는 생각을 잠시 해본다. 반면에 MS office365는 사용자의 배려가 너무 부족하다. 아마 MS 직원들도 운영체제 말고는 자기들의 제품을 쓰지 않을 것이다. 그 이유 중의 하나로 이 서비스는 MS의 브라우저에서 조차 제대로 동작하지 않는다. 나는 이제 지메일로 새로 들어온 메일이 있는지 확인한다. 필요한 경우 즉시 회신 메일을 발송한다.

이게 본격적인 업무 시간이다. 사실 나는 개발할 때 운영체제의 많은 기능을 사용하지 않는다. 단지 자바(Java)[11] 컴파일러(Javac, Java programming language compiler)[12]와 단순한 에디터(Editor) 그리고 웹 브라우저(Web Browser) 정도가 전부이다. 생각보다 많이 사용하는 것 같은가? 운영체제가 제공하는 기능에 비하면 절대 많지 않다. 그래서 나는 업무 환경에서 윈도우를 사용하지 않아도 된다고 생각한 적이 여러 번 있었다. 하지만 회사 사내 시스템 등 다른 여러 가지 환경들 때문에 아직은 포기다. 하지만 언젠가 얇고 가벼운 크롬북(Chromebooks)[13] 같은 랩톱에서 아마존 EC2(Amazon Elastic Compute Cloud)[14] 같은 클라우드 개발 환경에 접속하여 일 할 수 있는 날도 얼마 남지 않았다. 이제 정말 업무를 할 시간이다.

나는 요즘 자바 환경에서 개발하고 있기 때문에 가장 먼저 STS(Spring Tool Suite)[15]를 실행한다. 그리고 톰켓(Tomcat)[16]을 실행한다. 오늘은 Front-end 스크립트를 작성할 것이다. 오픈소스 코드 에디터인 Brackets(Adobe Brackets)[17]을 실행시킨다. 요즘 나는 자바스크립트(Javascript)[18]를 사용하는 일이 많은데 Brackets은 정말 훌륭한 툴이다. 특히 이 툴은 CEF(The Chromium Embedded Framework)[19]를 기반으로 만들어졌다. CEF 덕분에 요즘 자바스크립트로 못 만들 어플리케이션이 없어졌다. 여기에 node.js[20] 까지 더하면 정말 최고다. 내가 지금 개발하고 있는 어플리케이션도 다음 버전으로 CEF를 포함시켜 볼지를 건의해봐야겠다. 하지만 빈약한 내 커뮤니케이션 능력 때문에 안될 수도 있겠다.

오늘 나는 어제 마무리 못 한 XHR(XMLHttpRequest)[21] 관련 버그를 잡고 코드 구조를 개선하기로 계획을 세운다. 웹 애플리케이션은 XHR 덕분에 정말 많은 변화가 생겼다. 앞으로 추가로 HTML5[22]가 더 확산되면 웹 애플리케이션은 정말 화려해질 것이고 수많은 작업을 할 것이다. 지금 내가 개발하는 제품도 이러한 기능을 최대한 활용해서 지금까지의 제품들보다 멋지게(Cool) 보이게 하고 싶다. 나는 마지막 출시까지 완성도를 더 높이기 위해서 더 노력해야 하겠다고 다짐한다. 나는 계속 버그(Bugs)를 잡고 기능을 개선해 나간다.

주위에서 잡소음이 난다. 나는 특히 업무 시간에 산만해지지 않으려고 노력하는데 잘 안된다. 이전에 산만함에 대해서 글을 쓴 적도 있었다[23]. 코드에 집중하고 있을 때 나는 최대한 것 때문에 방해받지 않으려고 한다. 하지만 오늘은 실패다. 특히 나는 짜증 내는 듯한 소리와 싸우는 소리에는 쉽게 집중력이 흐트러진다. 그리고 이런 소리는 나를 몇 배나 힘들게 한다. 그래서 나는 이제 음악을 듣기 시작한다. 하지만 음악에 집중하려고 하지는 않고 코드에 계속 집중하기를 원하고 있다.

일하다 보니 어느새 퇴근 시간이다. 역시 집중하고 있으면 시간이 빨리 간다. 간식을 먹고 한두 시간 더 업무를 할 까 생각하다가 이내 그만 둔다. 왜냐면 이 시간 이후에는 집중하기가 쉽지 않다. 오히려 모두 퇴근하고 난 후 밤늦은 시간이 집중하기에는 더 좋다. 나는 브라우저의 내 사용 기록을 모두 지운다. 내 기록이 남아있는 것이 싫어서인데 이것도 강박증과 비슷한 증상인지도 모르겠다. 이제 퇴근한다.


References

[1] (2007). Caffe-Pascucci. Retrieved August 22, 2013, from http://www.caffe-pascucci.co.kr/.
[2] (2012). Chrome 브라우저 - Google. Retrieved August 22, 2013, from http://www.google.com/intl/ko/chrome/.
[3] (2005). Uniform resource identifier - Wikipedia, the free encyclopedia. Retrieved August 23, 2013, from http://en.wikipedia.org/wiki/Uniform_resource_identifier.
[4] (2004). 강박 장애 - 위키백과, 우리 모두의 백과사전. Retrieved August 22, 2013, from http://ko.wikipedia.org/wiki/%EA%B0%95%EB%B0%95_%EC%9E%A5%EC%95%A0.
[5] (2011). 크롬 확장 프로그램 - Chrome - Google. Retrieved August 22, 2013, from https://chrome.google.com/webstore/category/extensions?hl=ko.
[6] (2013). 2단계 인증으로 로그인하는 방법 - Google 계정 도움말. Retrieved August 22, 2013, from https://support.google.com/accounts/answer/1085463?hl=ko.
[7] (2006). Gmail: Google 이메일. Retrieved August 22, 2013, from http://mail.google.com/?hl=ko.
[8] Microsoft 한국 | 장치 및 서비스. Retrieved August 23, 2013, from http://www.microsoft.com/korea/.
[9] (2013). What is Office 365 for business? - Office.com. Retrieved August 23, 2013, from http://office.microsoft.com/en-us/business/what-is-office-365-for-business-FX102997580.aspx.
[10] (2004). Post Office Protocol - Wikipedia, the free encyclopedia. Retrieved August 22, 2013, from http://en.wikipedia.org/wiki/Post_Office_Protocol.
[11] (2003). java.com: Java와 사용자. Retrieved August 22, 2013, from http://www.java.com/ko/.
[12] (2010). javac - Oracle Software Downloads. Retrieved August 22, 2013, from http://download.oracle.com/javase/6/docs/technotes/tools/solaris/javac.html.
[13] (2012). 새로운 크롬북 소개 - Google. Retrieved August 22, 2013, from http://www.google.com/intl/ko/chrome/devices/.
[14] (2006). Amazon EC2 - Amazon Web Services. Retrieved August 22, 2013, from http://aws.amazon.com/ec2/.
[15] (2012). Spring Tool Suite | SpringSource.org. Retrieved August 23, 2013, from http://www.springsource.org/sts.
[16] (2005). Apache Tomcat - Welcome!. Retrieved August 23, 2013, from http://tomcat.apache.org/.
[17] (2012). Brackets. Retrieved August 23, 2013, from http://brackets.io/.
[18] (2005). 자바스크립트 - 위키백과, 우리 모두의 백과사전. Retrieved August 23, 2013, from http://ko.wikipedia.org/wiki/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8.
[19] (2008). chromiumembedded - A simple framework for embedding chromium ... Retrieved August 23, 2013, from http://code.google.com/p/chromiumembedded/.
[20] (2009). node.js. Retrieved August 23, 2013, from http://nodejs.org/.
[21] (2005). XHR - Wikipedia. Retrieved August 23, 2013, from http://en.wikipedia.org/wiki/XMLHttpRequest.
[22] (2006). HTML5 - Wikipedia, the free encyclopedia. Retrieved August 23, 2013, from http://en.wikipedia.org/wiki/HTML5.
[23] (2013). 라떼군 이야기 (Mr.Latte Story): 스마트폰과 눈먼 자들의 도시. Retrieved August 23, 2013, from http://www.mrlatte.net/2013/08/blog-post.html.


코딩 호러의 이펙티브 프로그래밍

이펙티브(effective) 라는 단어는 이상하게도 소프트웨어 관련 서적의 제목으로 많이 등장하고 있다. 이펙티브 자바[1], 이펙티브 C++[2], 이펙티브 STL[3] 등 이펙티브를 제목으로 하고 있는 많은 책들을 어렵지 않게 찾아볼 수 있다. 아마도 이것은 프로그래머들이 중요하게 수행하고 있는 업무 중에 하나가 소프트웨어를 시스템에서 효율적으로 동작하게 하는 것이기 때문일 것이고 이런 제목의 패턴들은 그들의 관심을 쉽게 끌기 위한 것으로 생각한다.

내가 최근에 읽은 '코딩 호러의 이펙티브 프로그래밍(Effective Programming: More Than Writing Code)[4]'도 이펙티브의 제목 패턴을 가지고 있었다. 아마 나도 이펙티브라는 단어 때문에 나도 모르는 사이에 관심을 가지고 선택하게 된 건인지도 모르겠다. 이 책은 제프 앳우드(Jeff Atwood)가 그의 코딩 호러(Coding Horror)[5]라는 블로그에 포스팅한 내용을 책으로 엮어 낸 것이다. 예전에 조엘 스폴스키(Avram Joel Spolsky)[6]가 했던것과 매우 비슷하게 말이다. 심지어 제프는 조엘과 가까운 사이로 공동으로 스택 오버플로우를 창업하기도 했다. 내 생각에 그는 물론 매우 뛰어난 프로그래머이겠지만 어떤 면에서는 조엘의 쫓는 팔로어(Followers)  정도가 아닐까 라고 생각한다.

이 책은 프로그래머들이 알고 있으면 좋을 내용이 다수 담겨져 있다. 하지만 글쓴이의 주관이 많이 반영된 것으로 반드시 그가 주장하는 것이 맞다는 과학적인 근거는 없다. 따라서 나는 이런 류의 책을 읽는 독자는 그가 주장하는 것을 받아들일지를 본인의 경험에 비추어 다시 재검증하는 과정이 꼭 필요하다고 생각한다. 나 또한 이러한 검증 과정을 거쳤다. 내가 이 책을 읽으면서 공감했던 부분과 그렇지 못했던 부분이 있었는데 그것들을 정리하면 다음과 같다.

먼저 나는 프로그래머를 여덟 개의 단계로 나누어 분류한다는 것에 공감하지 못했다. 제프 앳 우드는 프로그래머에는 여덟 단계가 존재한다고 했다. 프로그래머의 최고 단계로는 다익스트라(Dijkstra)[7]나 도널드 커누스(Donald Knuth)[8]같이 죽은 후에도 그들의 코드가 쓰이는 죽은 프로그래머의 단계가 있다고 말한다. 그리고 빌게이츠(Bill Gates)[9] 처럼 널리 알려져 있고 비즈니스에도 성공한 성공적인 프로그래머도 있으며, 유명한 프로그래머, 이직 걱정 없는 일할 수 있는 프로그래머, 평균적인 프로그래머, 아마추어 프로그래머, 주위에 나쁜 영향을 미치는 프로그래머가 있다고 정의한다.

여덟 가지 분류 중에 나는 아마 평균적인 프로그래머는 되지 않을까라고 생각한다. 이렇게 생각한 이유는 단순히 프로그래머라는 직업으로 수년간 직장생활을 하고 있기 때문이다. 내 명함에도 프로그래머라고 적혀있고 그 명함을 다른 사람에게 인사차 건네도 내가 하는 일에 대해서 의심하는 사람은 없을 것이다. 그리고 아직은 다행히 회사에서 그만 나오라는 소리를 듣고 있지 않으니 나는 아마추어나 나쁜 프로그래머는 아닐 것으로 생각한다. 하지만 나는 어느 회사나 나를 원하고 있지는 않고 기술적으로 직장 걱정이 없을 만한 수준은 아니니 그 이상의 단계는 되지 않을 것이라고 생각한다.

제프 앳우드는 나 같은 평균적인 프로그래머는 자신에게는 자신에게 더 맞는 다른 직업을 찾기를 권하고 있다. 보통 평균적인 능력을 가지고 있는 사람들이 그렇듯 소수의 엘리트(elite)로 발전하지 못할 것이기 때문이라는데 나는 이 부분에 대해서 전혀 동의할 수 없었다. 심지어 나는 내가 평균적인 프로그래머라는 사실을 깨닫고 난 후 그의 이런 주장에 대해서 조금 기분이 나쁘기까지 했다. 하지만 곧 나는 그가 단순히 어떠한 과학적 근거 없이 매우 주관적인 주장을 하고 있다는 점에서 안심이됐다. 나도 그가 했던 것과 비슷하게 경험과 비유를 통해 그의 주장을 반박해본다.

나는 프로그래머는 예술가와 닮아 있다고 생각하지는 않는다[10]. 하지만 이해를 돕기 위해서 프로그래머를 유명한 예술가에 비유해 그 단계를 설명해 보려고 한다. 다익스트라 같이 뛰어난 업적을 이룬 사람을 화가로 비교하면 파블로 피카소(Pablo Ruiz Picasso)[11] 정도가 될 것이다. 왜냐하면 피카소는 주목할 만한 뛰어난 작품을 남겼을 뿐만 아니라 새로운 시도를 통해 역사적으로 뛰어난 업적을 이루었기 때문이다. 그리고 평균적인 프로그래머를 화가의 비유에서 찾는 다면 빈센트 반 고흐(Vincent Willem van Gogh)[12] 또는 에드바르 뭉크(Edvard Munch)[13] 정도일 것이라고 생각한다. 그렇게 생각한 이유는 고흐는 어렸을 때 부터 천부적인 재능을 발휘했다고 기록한 것을 찾을 수 없고 심지어 신학을 공부하는 등 화가와 다른 길을 선택하기도 했지만 청년 이후에 그의 노력이 결실을 맺어 뛰어난 작품들을 만들어 냈기 때문이다. 그리고 뭉크는 내가 아는한 유명한 작품이 '절규(The Scream)[14]' 이외에는 찾을 수 없었기 때문에 평균적인 화가가 아니였을까 생각한다.

피카소는 분명 뛰어난 화가임이 틀림없고 3만 점에 이르는 수많은 작품을 남겼지만, 그의 대표작품의 이름을 기억하고 있는 사람이 있는지 궁금하다. 미술을 전공한 사람을 제외하면 아마 대부분의 사람들이 알지 못할 것이다. 단지 피카소를 통해 입체적인 내용의 그림을 떠올릴 수 있는 정도뿐이다. 고흐나 뭉크의 경우는 어떠한가? 고흐의 '별이 빛나는 밤에(Starry Night Over the Rhone)[15]'나 뭉크의 절규는 그림을 잘 알지 못하는 일반인에게도 지금까지 사랑받고 있고 피카소보다 더 많은 사람들에게 기억되고 있다. 소프트웨어의 세계에도 마찬가지이다. 어느 일반인이 다익스트라가 개발한 알고리즘을 알고 있겠는가? 일반인은 현재 자신이 유용하고 사용하고 있는 소프트웨어만 알고 있을 뿐이다. 심지어 그 소프트웨어의 이름을 알지 못하고 사용할지라도 말이다. 이처럼 꾸준한 평범함이 만들어 내는 가치는 더 크다고 생각한다.

반면에 그가 주장한 고무오리 문제 해결법에 대해서는 공감했다. 고무오리 해결법이란 상징적인 고무오리에게 자신의 문제를 설명하므로써 설명하던 도중에 문제의 해결법을 스스로 찾을 수 있는 것을 말한다. 나의 경험을 돌이켜 보면 나 또한 이 방법으로 문제를 해결했던 적이 많았던 것 같다. 처음에 어려운 문제라고 생각하던 것이라도 주위 사람들에게 도움을 요청하기 위해 내 문제를 설명하는 도중 문제의 해결방법을 찾을 수 있을지도 모른다.

EBS에서 방영했던 "공부의 왕도[16]"에서도 이와 비슷한 내용이 나온 적 있다. 내용은 미국 명문대 학생들과 우리나라 보통의 학생들을 비교해보면 실제로 어렸을 때에는 우리나라 학생이 더 어려운 문제를 잘 푸는 경향이 있다. 하지만 우리나라 학생은 자라면서 그 능력을 꾸준히 향상시키지 못하고 있었는데 그것은 혼자 공부하는 습관 때문이었다. 이와 반대로 미국 명문대 학생들은 어렸을 때는 기본 능력이 조금 뒤처져 있을지 몰라도 자라면서 여러 사람과 문제를 나누고 서로의 토론을 통해 더 많이 배울 수 있다고 한다. 이처럼 프로그래머의 세계에서도 여러 사람들과 자신의 문제를 나눌 때 더 많은 것을 배울 수 있다고 생각한다.

그리고 회의는 짧게 하라는 그의 주장에도 공감했다. 그는 극단적으로 회의는 일이 죽으로 가는 장소라고 말하고 있다. 나는 그 정도는 아니어도 회의가 잦아지면 일에 지장을 주는 것은 불가피하다고 생각한다. 그렇게 때문에 그는 어떤 회의라도 한 시간을 넘기면 안 되고 모든 회의에 명확하게 정의된 목표가 있어야 한다고 주장한다. 그리고 그가 제안한 회의에 참석하기 전에 회의에서 필요한 일을 먼저 하라는 것과 회의 참석하는 것은 선택사항으로 하는 것 그리고 회의를 마무리할 때는 할 일을 정리하는 것은 나도 꼭 필요하다고 생각한다.

여기까지가 내가 "코딩 호러의 이펙티브 프로그래밍"을 읽고 느낀 점들의 기록이다. 이 외에 좋은 내용들이 많이 담겨져 있다. 추후 책을 읽어볼 사람들을 위해서 서두에 말했듯이 책의 내용을 자신에게 맞게 취사선택해야 한다는 것을 다시 한 번 상기시키며 글을 마친다.


References

[1] (2009). 이펙티브 자바(EFFECTIVE JAVA) – Daum 책. Retrieved August 18, 2013, from http://book.daum.net/detail/book.do?bookid=KOR9788986044768.
[2] (2008). Effective C++ (이펙티브 C++) - Daum. Retrieved August 18, 2013, from http://blog.daum.net/shuaihan/15437997.
[3] (2006). 이펙티브 STL - 알라딘. Retrieved August 18, 2013, from http://www.aladdin.co.kr/shop/wproduct.aspx?ISBN=8956743118&partner=egloos.
[4] (2012). Amazon.com: Effective Programming: More Than Writing Code ... Retrieved August 18, 2013, from http://www.amazon.com/Effective-Programming-More-Writing-ebook/dp/B008HUMTO0.
[5] Jeff Atwood (2004). Coding Horror. Retrieved August 18, 2013, from http://www.codinghorror.com/.
[6] (2003). Joel on Software - 조엘 온 소프트웨어. Retrieved August 18, 2013, from http://korean.joelonsoftware.com/.
[7] (2006). 데이크스트라 알고리즘 - 위키백과, 우리 모두의 백과사전. Retrieved August 18, 2013, from http://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%81%AC%EC%8A%A4%ED%8A%B8%EB%9D%BC_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98.
[8] (2004). 도널드 크누스 - 위키백과, 우리 모두의 백과사전. Retrieved August 18, 2013, from http://ko.wikipedia.org/wiki/%EB%8F%84%EB%84%90%EB%93%9C_%ED%81%AC%EB%88%84%EC%8A%A4.
[9] (2003). 빌 게이츠 - 위키백과, 우리 모두의 백과사전. Retrieved August 18, 2013, from http://ko.wikipedia.org/wiki/%EB%B9%8C_%EA%B2%8C%EC%9D%B4%EC%B8%A0.
[10] (2011). 라떼군 이야기 (Mr.Latte Story): 해커는 화가를 닮지마라. Retrieved August 20, 2013, from http://www.mrlatte.net/2009/09/blog-post_5748.html.
[11] (2004). Pablo Picasso - Wikipedia, the free encyclopedia. Retrieved August 19, 2013, from http://en.wikipedia.org/wiki/Pablo_Picasso.
[12] (2003). Vincent van Gogh - Wikipedia, the free encyclopedia. Retrieved August 20, 2013, from http://en.wikipedia.org/wiki/Vincent_van_Gogh.
[13] (2003). Edvard Munch - Wikipedia, the free encyclopedia. Retrieved August 20, 2013, from http://en.wikipedia.org/wiki/Edvard_Munch.
[14] 파일:The Scream.jpg - 위키백과 - Wikipedia. Retrieved August 20, 2013, from http://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:The_Scream.jpg.
[15] (2008). File:Starry Night Over the Rhone.jpg - Wikimedia Commons. Retrieved August 20, 2013, from http://commons.wikimedia.org/wiki/File:Starry_Night_Over_the_Rhone.jpg.
[16] (2010). 공부의 왕도 - EBSi. Retrieved August 18, 2013, from https://www.ebsi.co.kr/ebs/pot/pote/retrieveStdKingIntro.ebs.


스마트폰과 눈먼 자들의 도시

"눈먼 자들의 도시[1]"라는 책을 읽어 보았는가? 이 책은 포르투갈의 노벨문학상 수상 작가 주제 사라마구(José_Saramago)[2]가 쓴 장편 소설이다. 소설은 알 수 없는 원인으로 사람들이 점차 시력을 잃어가는 내용을 담고 있다. 나는 이 소설을 처음 읽었던 때의 느낌을 아직도 잊을 수가 없다. 이 책이 눈먼 자들의 느낌을 아주 생생히 묘사하고 있었기 때문이다. 실제로 나는 이 책을 잃고 앞이 보이지 않는 사람들의 막막한 느낌을 아주 조금이나마 이해할 수 있었다고 생각했을 정도였다.

이제 컴퓨터 얘기를 해보자. 1946년 2월 최초의 컴퓨터 애니악(ENIAC, Electronic Numerical Integrator And Computer[3])이 공개된 이후로 지난 약 70년 동안 컴퓨터는 아주 비약적으로 발전해왔다. 사실 최초의 컴퓨터가 애니악인지에 대해서는 논란의 여지가 많지만 애니악을 컴퓨터의 비약적 발전 기준의 시기 정도로 생각하는 것이 좋겠다. 컴퓨터는 계속 발전하여서 결국 인터넷이 만들어지게 되었고 이제 우리는 필요한 정보가 있다면 손쉽고 빠르게 그리고 인공지능의 성과로 실제 의도보다도 더 내 의도에 맞는 결과를 보여주기까지 한다. 그리고 대부분의 사람은 항상 인터넷에 온라인 되어서 있으며 실시간으로 원하는 정보를 검색하는 시기가 되었다.

그리고 우리는 최근 몇 년간 스티브 잡스[4]가 이끌었던 애플의 아이폰을 시작으로 스마트폰이 비약적으로 발전하는 시기를 경험하고 있다. 스마트폰의 발전 속도는 컴퓨터의 발전 속도보다 훨씬 빠르다고 생각한다. 그 뿐만 아니라 아직 상용화 되지 않았지만 구글은 최근 구글 글래스(Google Glass)[5]라는 새로운 제품을 발표했다. 이것을 이용하면 더욱 쉽게 온라인 상태를 유지할 수 있게 된다.

한국에서도 많은 사람들은 지하철에서 스마트폰에 열중하고 있는 현상을 볼 수도 있다. ZDnet[6]을 비롯한 많은 기사[7][8]들에서 이러한 특이한 현상을 보도한 적이 있다. 이런 사람들은 심지어 걸어 다닐 때도 인터넷 메시지나 유튜브 동영상을 보거나 인터넷 정보를 검색하는 것을 멈추려고 하지 않는다. 마치 무엇에 홀린 사람처럼 말이다.

사람들은 기계처럼 멀티테스킹을 하고 있다. 컴퓨터에서의 멀티테스킹은 시분할(Time-sharing)[9]이라는 방법을 이용하고 있다. 이것은 일정 시간을 작은 단위로 쪼개서 여러 작업들 간의 전환을 빠르게 일어나게 함으로써 동시에 일이 처리되고 있는 것처럼 보이게 하는 것이다. 현대 사람들은 마치 컴퓨터가 하는 것처럼 멀티테스킹을 한다. 지하철에서 걸어 다니면서 메시징 서비스를 이용하고 걸어 다니면서 동영상을 보며 누군가는 밥을 먹으면서까지 스마트폰을 놓지 않고 있다. 나는 이러한 현상들을 보면서 '눈먼 자들의 도시'에서 사람들이 하나씩 눈이 멀어져 가는 장면을 떠오른다.

하지만 생물학적으로 사람은 멀티테스킹을 수행할 할 수 없다. 미래학자 니콜라스 카(Nicholas G. Carr)[10]는 그의 책 '생각하지 않는 사람들(The Shallows)[11]'에서도 같은 주장을 하고 있다. 컴퓨터의 멀티테스킹은 여러 일을 빠르게 처리하는 데 도움을 줄 수 있지만, 인간은 그렇지 않다. 오히려 인간의 뇌는 가소성(plasticity)[12]을 가지고 있어서 이런 멀티테스킹처럼 행동하는 것은 어떤 일에 집중하지 못하고 산만해지도록 뇌의 구조가 변할 수 있다고 경고하고 있다.

이와 같은 주장을 하는 것은 니콜라스 카뿐만이 아니다. 제프앳 우드(Jeff Atwood)도 '코딩 호러의 이펙티브 프로그래밍[13](Effective Programming: More Than Writing Code[14])'에서도 멀티테스킹은 도움이 되지 않는다는 비슷한 주장을 하고 있다. 'The Multi-Tasking Myth'[15] 란 제목으로 그의 블로그[16]에서도 확인할 수 있다.

니콜라서 카는 과학적 근거를 두고 이와 같은 주장을 하고 있다. 하지만 제프앳 우드는 과학적 근거가 부족하다. 글이 게시된 곳이 블로그이기 때문에 블로그 특유의 가벼움과 유머 때문에 이런 근거를 제외했을지는 모르겠다. 하지만 비록 그렇지 않다고 하더라도 그의 주장은 그의 많은 경험을 바탕으로 이와 같은 결론을 내렸을 것이기 때문에 무조건 터무니없는 주장이라고 치부하기는 어렵다.

우리는 지금 기술적으로 급변하는 시대에 살아가고 있다. 그리고 이런 기술들은 우리 삶을 크게 바꿔 놓고 있고 앞으로 더 많이 변화할 것이다. 그리고 나는 프로그래머의 직업 특성상 이러한 기술을 완전히 거부할 수도 없다. 선택의 여지가 없다. 기술을 잘 익히고 기술의 선도자가 되어야 한다. 하지만 기술을 나의 도구로 사용할지 내가 기술의 도구가 될지는 온전히 나의 선택일 것이다. 나는 앞으로 기술이 어떻게 우리 삶을 바꿔 놓든지 기술을 자신의 도구로 잘 활용하고 기술 때문에 우리가 가지고 있는 인간적인 좋은 성향들을 포기하지 않기를 바란다. 비록 세상 사람들이 모두 기술에 잠식당해 '눈먼 자'들이 되고 그 세상에 유일한 '눈뜬 자'가 내가 될지라도 나는 기술의 도구는 되고 싶지 않다.


Reference

[1] (2008). 눈먼 자들의 도시 - 위키백과, 우리 모두의 백과사전. Retrieved August 8, 2013, from http://ko.wikipedia.org/wiki/%EB%88%88%EB%A8%BC_%EC%9E%90%EB%93%A4%EC%9D%98_%EB%8F%84%EC%8B%9C.
[2] (2005). José Saramago - Wikipedia, the free encyclopedia. Retrieved August 8, 2013, from http://en.wikipedia.org/wiki/Jos%C3%A9_Saramago.
[3] (2003). ENIAC - Wikipedia, the free encyclopedia. Retrieved August 8, 2013, from http://en.wikipedia.org/wiki/ENIAC.
[4] (2004). Steve Jobs - Wikipedia, the free encyclopedia. Retrieved August 9, 2013, from http://en.wikipedia.org/wiki/Steve_Jobs.
[5] (2013). Google Glass - Home. Retrieved August 9, 2013, from http://www.google.com/glass/start/.
[6] ZDNet | Technology News, Analysis, Comments and Product ... Retrieved August 8, 2013, from http://www.zdnet.com/.
[7] (2013). 지하철 스마트폰 사용 위험천만...사고 1위 - 지디넷코리아. Retrieved August 8, 2013, from http://www.zdnet.co.kr/news/news_view.asp?artice_id=20130717133644.
[8] 출근길 지하철, 건강 망치는 습관 ´Top 4´ - 중앙일보 뉴스. Retrieved August 8, 2013, from http://joongang.joins.com/article/652/12217652.html?ctg=1200&cloc=joongang%7Chome%7Cnewslist1.
[9] (2003). Time-sharing - Wikipedia, the free encyclopedia. Retrieved August 9, 2013, from http://en.wikipedia.org/wiki/Time-sharing.
[10] (2005). Nicholas G. Carr - Wikipedia, the free encyclopedia. Retrieved August 9, 2013, from http://en.wikipedia.org/wiki/Nicholas_G._Carr.
[11] (2012). The Shallows: What the Internet Is Doing to Our Brains: Nicholas ... Retrieved August 9, 2013, from http://www.amazon.com/The-Shallows-Internet-Doing-Brains/dp/0393339750.
[12] (2006). 가소성 - 네이버 백과사전. Retrieved August 9, 2013, from http://100.naver.com/100.nhn?docid=1211.
[13] (2013). YES24 미리보기 - [도서] 코딩 호러의 이펙티브 프로그래밍. Retrieved August 9, 2013, from http://www.yes24.com/24/viewer/preview/8611802?PID=146051.
[14] (2012). Amazon.com: Effective Programming: More Than Writing Code ... Retrieved August 9, 2013, from http://www.amazon.com/dp/B008HUMTO0.
[15] Jeff Atwood (2010). Coding Horror: The Multi-Tasking Myth. Retrieved August 9, 2013, from http://www.codinghorror.com/blog/2006/09/the-multi-tasking-myth.html.
[16] Jeff Atwood (2004). Coding Horror. Retrieved August 9, 2013, from http://www.codinghorror.com/.




Subscribe to: Posts (Atom)