라떼군 이야기

Software의 Accessibility

(라떼군) — Sun, 23 Nov 2008 21:25:04 +0900

T-money 단말기(www.t-money.co.kr)

얼마 전 편의점에서 커피를 사먹었던 적이 있었는데 놀라운 것을 발견하였다. T-money 단말기가 계산대 옆에 있는 것이었다. 하도 신기해 보여 일하시는 분께 T-money로도 계산할 수 있는 거냐고 물어보니 그렇다고 했다. 그 후 며칠간 T-money가 머릿속을 떠나지 않았는데 그날 이후 나의 생활권에서 T-money로 할 수 있는 것들이 참 많이 눈에 들어왔다. 먼저 T-money로 버스, 지하철을 탈 수 있고 심지어 현금이 없을 때는 택시도 탈 수 있다. GS25, 훼미리마트, 세븐일레븐, 바이더웨이, 미니스톱등 거의 모든 편의점에서 사용할 수 있을 뿐 아니라 연말이 되면 구세군 자선냄비에 꾸깃꾸깃 돈을 넣는 대신 T-money를 찍어줄 수도 있다. 상황이 이 정도니 가까운 미래에 부모님이 아이들 용돈 줄 때 잃어버리기 쉬운 현금을 주는 대신 T-money를 충전해 주는 일도 머지않은 것 같다.

Triple DES (www.answers.com/topic/tdes)

T-money는 2004년 7월 서울특별시가 대중교통 체계를 개편하면서 새 교통카드로 도입하면서 사용하게 되었다. 특이한점은 스마트카드(Smart Card)라는 점이다. T-money 이전 교통카드 유패스(Upass)는 저가형 Mifare(MIFARE Standard 1k, Ultralight)기반의 메모리 카드이고 Mifare Ultralight가 암호화 없는 512bit의 작은 저장용량만 지원한다는 것과 달리 T-money는 IC(Integrated Circuit) Chip을 내장하고 있다. 이런 스마트카드인 T-money의 특징은 자체적으로 마이크로프로세서와 운영체제를 가지고 데이터의 자체연상과 암호화(T-DES와 SEED)가 가능하기 때문에 I/O가 없는 작은 컴퓨터라고도 불리고 있다는 것이다. 또한, T-money를 IC Card 국제 규격과 ISO 기준을 준수하고 있다고 한다.[1] (T-DES[2]는 Triple DES를 말하는 것이라고 생각되고 SEED는 정보보호진흥원(KISA) 에서 개발한 SEED 블록 암호화 알고리즘을 말한다.)

현재 상황이 이 정도이다 보니 그동안 통신사들이 하고 싶어하던 지급수단의 결합 즉, 이상적인 결합이었던 신용카드(예: MONETA, 통신 업체의 카드사 인수 등)와 이동통신기기의 통합은 결국 인프라 부족으로 말미암아 사람들의 외면과 대한민국 전 국민의 1/4 이상이 거주하는 서울시 포함 경기도의 정책 탓에 이미 T-money의 승리가 예상되고 있는 것이 아닐까 생각된다. T-money의 승리는 T-money가 대단한 기술력을 바탕으로 한 획기적인 서비스이기 때문이 아니라는 점에서 나는 주목하고 있다. 사람들의 사용이 편리함 즉, Accessibility(접근성)의 승리라고 생각한다.

Market Share of US Internet Visits[4]

이와 마찬가지로 소프트웨어 산업에서도 성공하는 소프트웨어가 되려면 Accessibility를 중요시해야 한다고 생각한다. 나는 MSN 메신저와 Windows Live[3]서비스를 사용하고 있다. 개인적인 평가로(주위 몇몇 지인들의 평가 포함) Google 서비스가 Windows Live보다 쓰기 편하고 웹 기발 서비스로는 기술적으로 앞서고 있다고 생각하고는 있으나 MS와 Windows 운영체제 그리고 내가 주로 쓰는 MSN 메신저와 Hotmail과의 연동 부분 등 때문에 옮겨가지 못하는 것이다. 결국, 나는 Accessibility가 사용할 서비스를 결정할 때 가장 중요한 부분을 차지하고 있는 것이다. 싸이월드(Cyworld)와 네이트온(NateOn)과의 결합도 마찬가지로 볼 수 있다. 싸이월드가 먼저인지 네이트온이 먼저인지는 알 수 없으나 싸이월드와 네이트온은 Accessibility의 이유로 서로 기여하고 있음이 틀림없다.

어느 한 소프트웨어를 킬러 소프트웨어(Killer application)[5]로 만들어 사용자들에게 널리 사용되기 위해 노력하고 그것을 성공의 목표로 삶는 것도 좋다. 하지만, 그것만을 목표로 한다면 어떤 다른 소프트웨어가 출시되었을 때 언제든 그 자리를 빼앗길지 모른다고 불안해 매일 밤잠을 설쳐야 할지도 모른다. 이와 반대로 Accessibility가 강조된 소프트웨어는 그렇지 않은 소프트웨어보다 더욱 안정적인 발전을 이룰 수 있으리라 생각한다.@

[1] http://ko.wikipedia.org/wiki/T-money
[2] http://www.answers.com/topic/tdes
[3] http://en.wikipedia.org/wiki/Windows_Live
[4] http://www.liveside.net/main/archive/2007/01/06/google-calendar-catches-msn-s-or-where-oh-where-is-the-wl-calendar.aspx
[5] http://en.wikipedia.org/wiki/Killer_application

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

'영화는 영화다'를 보고

(라떼군) — Fri, 19 Sep 2008 12:58:39 +0900

영화는 영화다 (www.00movie.co.kr)

이번 추석 연휴기간 동안 소지섭, 강지환 주연의 '영화는 영화다'라는 영화를 보게 되었다. 보고 나서 느낀 점은 많았지만 먼저 재미있었는지 추천할만한지를 물어보신다면 나는 추천할만한 영화라고 말하고 싶다.

스포일러(spoiler)가 되고 싶진 않기에 간단하게만 내용을 요약하면 극중 영화배우로 등장하는 강지환(장수타)와 진짜 깡패로 등장하는 소지섭(이강패)이 영화를 찍는 내용이다 실제 깡패로 살아가는 소지섭은 인생 자체가 목숨을 걸만큼 치열한 삶이기에 그런 삶을 흉내만 내는 강지환을 못마땅해 한다. 처음에 강지환은 소지섭의 삶을 이해하지 못했지만 영화를 찍어가며 조금씩 이해해 간다. 하지만 이해한 듯 보였던 소지섭의 삶이 정말로 그 속에서 목숨을 걸만큼 치열한 삶을 살아보지 못한 강지환에게는 결국 결코 이해하지 못한 삶이 된다는 그런 내용이다. (개인적으로 영화 내용을 해석한 것이라 실제 보는 사람과의 이해가 다를 수 있겠다.)

나는 이 영화를 보고 나서 감독이 말하고 싶은 것은 바로 '인생의 치열한 삶' 이라고 생각했다. 극중 강지환처럼 가짜 흉내 내는 것만으로는 실제 그것들을 업(業)으로 삶고 있는 사람들을 결코 이해하지 못할 것이다. 내가 마치 예술 하는 사람들을 이해하려고 들거나 의사나 변호사들의 삶을 이해하려 드는 것과 마찬가지 일 거란 생각을 했다. 겉으로는 그 사람들의 삶이 좋아 보일지 몰라도 그것은 업으로 삶고 있는 사람들에게만 있는 생존과도 연관되어 있기에 그 자리를 지키기 위해서는 남들이 모르는 힘겨운 삶을 살아가고 있는 것이다.

요즘 이곳 저곳에서 치열한 삶을 주제로 하는 책들이 쏟아져 나오고 있다. 그 책들에는 한결같이 치열하게 살아야 한다고들 말하고 있다. 하지만 나는 그렇게 살기를 원하지 않는다. 나는 여유롭고 평화롭고 자유롭게 사는 것을 원한다. 하지만 아이러니 하게도 여유롭고 평화롭고 자유롭게 살기 위해서는 그만큼 치열한 부분이 있어야 할지도 모르겠다.

영화를 통해 여러 가지 삶을 느낄 수 있는데 사람들이 이런 격한 영화를 좋아하는 이유도 좀더 각자가 원하는 삶을 살아가기 위해 절대 그들이 이룰 수 없는 일을 이루고 영화로써 새로운 삶을 느끼고 그로 인해 그들의 실제 삶의 방향이 조금은 좋은 쪽으로 전환될 수 있기 때문이라고 생각한다.@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

인터넷이 우리 사회에 미치는 영향

(라떼군) — Mon, 15 Sep 2008 15:14:38 +0900

Visualization of the various routes through a portion of the Internet. (wikipedia)

믿기 어렵겠지만 몇 년 전만 해도 간단한 정보를 검색하기 위해선 백과사전이 필요했고 적은 분량의 백과사전에서 찾을 수 없을 땐 도서관에 가야 했고 또 작은 도서관에서 찾을 수 없을 땐 좀더 큰 도서관으로 가야 했었다. 과연 지금의 중학교, 고등학교 학생들은 과연 몇 명이나 이래야만 했던 사정을 이해해줄지 모르겠다.

하지만 이제는 사정이 달라졌다. 인터넷의 등장으로 예전처럼 정보검색에 수많은 시간과 노력을 쏟지 않아도 더 쉽게 더 좋은 자료를 검색할 수 있고 그를 여러 가지 형태의 미디어로 접할 수 있는 시대가 되었다. 예전에 ‘팀 버너스 리(Tim Berners-Lee)’ 가 처음으로 구체적으로 주장했던 하이퍼미디어(Hypermedia)와 그로 이루어진 인터넷으로 인해 우리 생활은 많이 변화했고 또 이제는 없어서는 안될 것으로 멀티미디어 환경으로 진화해 왔다는 사실은 아무도 부인하지 못할 것이다.

사실 인터넷의 등장만으로도 우리에겐 막대한 영향을 끼쳤다. 하지만 여기서 인터넷의 멀티미디어로서의 역할을 배제한다면 그 영향력을 전부 얘기하지는 못할 것이다. 멀티미디어로서의 인터넷은 위에서 얘기한 것처럼 빠른 정보검색은 물론이고 보다 효율적인 방법으로 정보전달의 기능을 가지고 있다.

대학교 1학년 때 처음 컴퓨터를 공부할 때 일이다. 네트웍에 대해 공부하고 있었는데 마침 네트웍을 설명하고 있는 동영상을 인터넷에서 발견했다. ‘The dawn of the Net’ 이라는 동영상 이였는데 네트웍 패킷이나 라우터, 라우터 스위치 등등 전체적인 네트웍에 대해서 알기 쉽게 설명한 동영상이었다. 이 동영상은 너무 쉽고 직관적이어서 누구라도 이것을 본 사람이라면 네트웍에 대해 모두 안 것 같은 착각을 하게 만들 정도였다. 하지만 대략적인 네트웍에 대해서 안다고 해서 전문가가 되었다고 말할 수는 없을 것이다. 간단해 보이는 현상 뒤에 숨겨져 있는 지식들을 모두 이해하고 설명할 수 있을 때 비로소 전문가라 부를 수 있을 것이다.

이런 멀티미디어적인 환경은 대부분에 사람들에게 보다 폭넓은 지식을 요구하는 사회로 변화하게 되었고 이 같은 지식을 강조하게 되었다. 반면에 깊이 있는 지식은 간과하는 사회 분위기를 만들어 가고 있다. 어떤 면에서는 굉장히 비약적인 발전을 이루어 온 것도 사실 이지만 과도기적인 문화를 겪지 못한 한국의 경우에는 이공계, 특히 소프트웨어 발전에 좋은 영향을 끼쳤다고는 볼 수는 없을 것이다.

The Enigma machine

소프트웨어 발전에 가장 중요한 역할을 하는 것은 그 나라의 문화라고 생각한다. 지금처럼 한 명의 개발자가 얕은 지식으로 데이터베이스 설계에서부터 개발 관리자의 역할 때에 따라선 컨설턴트의 역할까지 모두 해야만 하는 이러한 우리의 현실은 소프트웨어 발전을 저해하고 있는 것이다. 소프트웨어는 누구나 간단한 교육만으로 진입 가능할 수 있는 일명 청바지산업이 아니라 보다 전문적이고 체계적으로 교육받는 사람만이 가능한 산업이 되어야 할 것이다.

결과 만을 중시하고 넓고 얕은 지식을 필요로 하기 보다는 과정을 중시하고 한 한곳에 깊은 지식을 가질 때 비로소 진정한 IT 강국으로 발전할 수 있을 것이라 생각한다. 이제 우리는 이런 멀티미디어적인 환경을 보다 잘 활용해 전처럼 중국 발 해킹으로 허술하게 뚫려 개인정보가 유출되거나 마땅히 지켜야 할 기본적인 표준 HTML 문법조차 지키지 못해 다른 브라우저를 사용하는 대다수의 외국고객들을 놓치는 일은 이제는 없어야 하겠다.

우리도 이제 38세가 되면 38선을 넘는다느니 퇴직해야 한다느니 하는 우리나라의 분위기보다는 나이가 들면 들수록 좀더 깊은 전문성으로 소프트웨어 개발에 힘쓰는 그런 시대가 오기를 바란다. 백발을 휘날리며 소프트웨어 개발에 힘쓴다거나 한국사람 최초로 ‘튜링상(Turing Prize)’을 수상하는 일도 이미 잘 갖추어진 멀티미디어 환경을 잘 활용하고 발전시켰을 때 이런 일도 우리에게는 꿈 같은 일만은 아니라고 생각한다.@

[참고문헌]
http://www.wikipedia.org/

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

페이지 랭크(PageRank) 와 링크(Links)

(라떼군) — Fri, 12 Sep 2008 19:07:21 +0900

Link Popularity vs. PageRank vs. Yoda (http://blaugh.com/)

나는 버스로 퇴근 하는 것이 좋다. 출근 시간에는 시간여유가 없고 교통체증이 어떨지 모르기 때문에 버스를 이용하지는 않지만 늦은 시간 퇴근할 때는 주로 버스를 이용하는 편이다. 버스를 이용하는 것이 지하철을 이용하는 것보다 20분 정도 더 걸린다. 하지만 버스를 타고 가는 시간 동안 사람들을 관찰하는 즐거움과 창 밖 저녁 도시 풍경을 볼 수 있는 것은 버스를 탐으로써 지연되는 시간과 충분히 바꿀만한 것들이다.

버스에도 명당 자리는 있다. 가장 편하고 사람들을 잘 관찰할 수 있을 뿐 아니라 운전기사와 주행 시선을 같이 함으로써 오랜 버스 여행의 피로를 덜하게 하는 자리가 바로 운전수 바로 뒷자리이다. 무엇보다 그 자리가 좋은 건 승차하는 사람들을 볼 수 있다는 점이다. 사람들을 관찰하고 있노라면 사람들을 관찰하는 능력이 생기는 것 같다. 퇴근 길에 버스를 탄 사람, 친구 만나러 놀러 가는 사람, 이 버스를 처음 탄 사람 등 사람들의 표정과 행동만 봐도 그 정도는 대충 맞힐 수 있게 된다.

그런데 이런 사람들을 관찰하다가 우연찮게 흥미로운 것들을 발견할 수 있었다. 그것은 버스 안에 대부분 사람들은 다른 사람들이 어떤 옷을 입었는지 어떻게 생겼는지 피곤한 모습인지, 심지어는 옷에 더러운 것이 묻어있는지에 대해서도 생각보다 크게 관심을 두지 않는 다는 점이다. 누구나 사춘기 때 주위사람들이 자신에게 관심을 가질 거라 생각하고 사소한 외모에도 신경 쓰던 것과 너무 대조적인 것이다. 여기서 조금 더 유심히 관찰하면 그 관심의 정도는 다른 사람들과의 친분 정도에 비례한다는 것 까지도 알 수 있다. 가족처럼 매우 친한 관계에서는 다른 사람이 못 보는 사소한 것까지도 관심을 갖지만 버스안에서 만난 사이라면 가족들이 관심을 갖는 대부분의 것들에 무관심할 것이다.

이와 같은 사람과의 관계가 마치 웹(Web)에서 말하는 링크(Links)같다는 생각이 들어 링크의 정의를 찾아 보았다. 우리가 보편적으로 생각하는 링크의 종류인 하이퍼링크(Hyperlink)의 Wikipedia의 정의는 다음과 같았다.

In computing, a hyperlink is a reference or navigation element in a document to another section of the same document or to another document that may be on or part of a (different) domain.

모두 알고 있듯이 다른 어떤 것과 연결됨을 생각하면 될 것이다. 인간 사회에서도 그렇듯이 인터넷에서도 인간관계에서 말하는 친분관계와 같은 의미로 링크가 존재하는 것이다. 어느 한 웹 페이지가 링크를 통해 친분의 정도를 나타내고 있다고 생각할 수 있겠고 이것이 구글(Google)에서 말하는 페이지 랭크(PageRank™)로 관심을 갖는 정도를 표현 하고 있는 것이다.

Google's PageRank

페이지 랭크라는 것은 구글의 설립자 레리 페이지(Larry Page) 와 세르게이 브린(Sergey Brin)이 스탠포드 대학에서 개발한 시스템이다. 특정 페이지에 대해 더 정규화된 페이지 랭크를 계산하기 위한 여러 복잡한 단계를 거치지만 간단히 요약하면 랜덤 웹 써퍼(Random web surfer)가 웹 써핑을 하다 자신의 페이지를 방문할 확률을 나타내는 것이다. 그렇기 때문에 페이지 랭크를 높이기 위해서는 다른 여러 웹 페이지와의 링크가 많아야 하고 연결된 다른 웹 페이지는 페이지 랭크가 높아야 한다. 그래야 랜덤 써퍼가 자신의 웹 페이지를 방문할 확률이 높기 때문이다.

인간 사회에서도 유명한 사람들은 페이지 랭크가 높은 웹 페이지와 같다. 이 사람들은 여러 사람들이 링크로 연결되어 있고 그게 단 방향일 지라도 유명한 사람은 다른 사람들이 아주 사소한 것에도 관심을 가질 정도로 친밀하다. 사회에서 성공하기 위해서는 자신의 웹 페이지의 페이지 랭크를 높이는 것과 비슷하다는 생각이 들었다. 여러 사람과 소통하고 그 사람들로부터 관심의 대상이 되어야 한다는 것이다. 컴퓨팅 시스템들도 사실은 설계자의 사상이 반영된 인간 사회 투영이 아닐까하는 생각이 든다.@

[참고문헌]
http://blaugh.com/
http://en.wikipedia.org/wiki/Hyperlink
http://www.terms.co.kr/
http://popuri.us/
http://www.emh.co.kr/xhtml/google_pagerank_citation_ranking.html
http://www.google.co.kr/corporate/tech.html

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

SOA와 프로젝트 현실

(라떼군) — Fri, 05 Sep 2008 01:09:18 +0900

Just Boring SOA (http://geekandpoke.typepad.com/)

오늘 소공동 롯데 호텔에서 열리는 '성공적인 SOA 도입을 위한 IBM 제언 세미나' 에 다녀왔다. (SOA: Service-oriented architecture) 세미나에 참석하게 된 가장 큰 이유는 세미나 아젠다(Agenda) 중에 '웹 서비스 및 XML의 한계와 이의 극복 방안' 이라는 주제가 있어서 기대하며 다녀오게 되었다. 기대가 너무 컸던 탓일까? 발제자들은 많은 것을 알고 있으면서도 잘 알려주려 하지 않는 것 같아 보였고 모든 XML(Extensible Markup Language)과 관련된 문제점들을 자신들의 제품에서만 해답을 찾으려고만 하는 것 같다 좀더 기술적인 내용을 기대하고 참석했던 나로써는 좀 아쉬운 세미나가 된 것 같다.

나는 항상 세미나를 하고 거기서 전달이 가능한 내용들은 발제자가 알고 있는 지식의 25% 정도 밖에 되지 않는다고 개인적으로 생각하고 있다. 발제자의 능력이 100%이라고 한다면 여러 사람의 수준을 맞추는데 50%의 전달능력을 상실되고 자신의 지식을 또 알맞게 포장하는데 또 50%의 전달능력이 상실된다고 생각한다. 그만큼 수준이 다른 여러 사람들을 대상으로 발표하고 그것을 이해시키기가 그만큼 어렵다는 말이다. 그래서 나는 누가 세미나를 들을 때 발제자의 실력이 내가 느끼는 것보다 4배정도 잘하는 사람이라고 미리 생각하고 세미나를 듣는다. 그런데 오늘 첫 번째 세션을 발표하시고 미국 IBM에서 근무하시고 계신다는 '손성익' 이란 분은 세미나를 통해 느껴지는 그분의 내공도 대단했지만 실제 그분이 오랜 기간 대기업에서 소프트웨어 산업에 몸담고 있으면서 겪었던 경험들을 생각할 때 더 대단한 분 일거라는 생각이 들었다.

대기업 개발자들과 만나 볼일은 별로 없지만 가끔 만날 때마다 공통적으로 느끼는 점이 있었다. 오늘도 마찬가지로 그런 느낌을 느낄 수 있었는데 그것은 대기업 개발자와 중소기업 그리고 소기업 개발자와는 확실히 차이가 난다는 것이다. 그 차이는 간단히 말해서 100억짜리 프로젝트를 해본 개발자와 1억짜리 개발을 해본 개발자와 1,000만 원짜리 개발을 해본 개발자로 달리 말할 수 있겠다. 사실 100억짜리 프로젝트라고 해서 뭐가 그렇게 다르겠는가? 그렇게 비싼 프로젝트라도 황금으로 만든 키보드와 마우스로 작업하거나 매일 저녁 야식을 위해 스테이크를 구워먹거나 하지는 않을 것이다. 그냥 똑 같은 프로젝트일 뿐인데 어떤 프로젝트는 여러 회사들의 이해관계가 얽혀(혹은 국가 일지도 모르겠다) 가격이 올라가고 또 그러기에 좀더 중요한 프로젝트라 불려지는 것뿐이다.

그래도 나는 개발자라면 한번쯤은 큰 규모의 프로젝트를 해볼 필요가 있다고 생각한다. 그런 큰 규모의 프로젝트를 해봄으로써 작은 프로젝트에서는 결코 경험할 수 없는 새로운 문제점들을 경험할 수 있게 될 것이라고 확신한다. 그런 문제점들을 해결해 나감으로써 다른 프로젝트를 바라보는 보다 넓은 시각을 갖게 해줄 것이라고 생각한다.

사실 소프트웨어 공학에서 나오는 대부분의 것들이 소규모 프로젝트를 대상으로 하고 있는 것은 없지 않은가? 심지어 오늘 세미나의 주제인 SOA도 그렇지 않은가? “SOA는 기업의 소프트웨어 인프라를 구축하는 방법으로 서로 다른 운영체제와 프로그램에 상관없이 애플리케이션간에 데이터와 프로세스를 교환할 수 있는 아키텍처를 말한다.“라고 IBM사이트에서도 말하고 있듯이 그 내용부터 소규모 프로젝트는 벌써 배제되고 있음을 알 수 있다. SOA 탄생의 궁극 목적도 새로 개발하거나 유지보수에 따르는 비용이 큰 대형 레거시 시스템(Legacy System)들을 어떻게 최소 수정으로 신규 시스템에 통합할 것인가로부터 생각이 출발한 것이 아닐까?

요즘 내가 일하는 부서에서는 소스통합에 대한 이슈가 제기되고 있다. UI와 플래폼(Platform)과 개발언어는 다르지만 기능이 비슷한 두 프로젝트의 소스를 하나로 합쳐 추후 지금보다 낮은 비용으로 개발하고자 하는 것이 그 목적이다. 하지만 물론 가능은 하지만 그 작업으로 인해 앞으로 나타날 험난한 프로젝트의 문제점들과 시행착오들이 나에게는 그저 깜깜하게 보일 뿐이다.

SOA도 좋고 웹 서비스도 좋고 IBM에서 말하는 하드웨어로 구현된 엄청 빠른 XML파서인 DataPower도 좋지만 그것들의 장점을 살릴 수 없는 중소형 프로젝트들과 만약 장점을 살릴 수 있는 길이 있다고 하더라도 그것들을 관리자에게 제대로 이해시키지 못하는 나 같은 개발자에게는 그저 공허한 울림이 될 수 밖에 없다. 보다 풍부한 경험이 있었더라면 더 좋은 방향을 제시할 수도 있을 거라 생각을 하면서 나에게 있어서 여러 가지 상황의 경험과 그에 맞는 기술적 조합이 부족함을 절실히 느낀다.@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

구글 브라우저(Chrome)와 웹 제국

(라떼군) — Tue, 02 Sep 2008 21:47:00 +0900

구글 크롬(Chrome)

이제 구글도 웹 브라우저(Web browser)를 만든다. 9월 2일 출시되는 '크롬(Chrome)'이 그것이다. MS진영과 Firefox로 대변되는 오픈 소스 기반의 웹 브라우저와의 싸움의 시작을 예견 하는 목소리가 이곳 저곳에서 흘러나오는 것 같다. 하지만 나는 이것은 단순히 싸움에서 그칠 것으로 생각되지 않는다. 이 뉴스를 접할 때 왠지 영화 속 터미네이터(Terminator)가 등장할 때 나오는 음악이 내 귀에 들리는 것 같았고 긴장되면서 한편으로 기분 좋은 느낌이었다. 내가 그렇게 생각한 이유는 다음과 같다.

구글은 지금까지 웹 기반 어플리케이션으로 인한 사업을 추진하고 있었다. 구글 검색(Google Search), 구글 닥스(Google Docs), 그리고 iRow를 인수해 구글이 갖게 된 스프레드시트(Google Spreadsheets), 구글 캘린더(Google Calendar) 등이 그 예가 될 수 있겠다. Ajax (Asynchronous Javascript And XML)의 등장과 구글의 노력으로 많이 개선되기는 했지만 하지만 이런 웹 기반 오피스들을 사용해본 사람은 이미 조금은 느꼈겠지만 데스크톱(Desktop) 어플리케이션에 비해 약간 2% 부족하고 답답함을 느꼈을 것이다. 마치 MS와 선대 프로그래머들이 가둬놓은 웹 브라우저라는 올가미에 걸린 거대한 드래곤(Dragon)처럼 말이다.

그것은 바로 W3C에서 1999년에 발표되었지만 아직까지 쓰고 있는 구시대 프로토콜인 HTTP/1.1와 IE(Internet Explorer)와 Netscape의 싸움으로 브라우저 시장의 잠식만 중요시 했던 시대의 결과물인 현재 웹 브라우저의 성능한계 때문이 직접적인 원인이라고 말할 수 있겠다. 쉽게 말해서 웹 브라우저가 벤더들이 원하는 기능을 그만큼 소화하지 못하는 것이다. 때문에 불행하지만 우리나라에선 ActiveX로 만들어진 지저분한 웹사이트들도 나타나게 된 것이다.

하지만 그와 별개로 웹 기반 소프트웨어에 대한 관심이 집중되고 있다. web2.0이 이슈가 되었던 것처럼 웹 기반 소프트웨어는 단순하며 사용하기 쉽고, OS(Operating system)에 상관없이 웹 브라우저만 있으면 사용할 수 있고, 특정 소프트웨어가 설치되어야 할 필요도 없기 때문에 장소에도 구애 받지 않는다. 이러한 웹 기반 소프트웨어대 대한 관심 집중 현상은 앞으로 데스크톱 어플리케이션의 새로운 패러다임이 나오기 전까지는 바뀌지 않을 거라 생각한다.

여기서 구글이 웹 브라우저 시장에 진출한 이유를 다시 생각해 봤으면 좋겠다. 단순히 IE와 Firefox의 시장을 나눠먹기 위해서 진출하지는 않았을 것이다.

구글은 웹 기반 소프트웨어에 대해 또 다른 야심을 가지고 있는 것이라 생각되고 이제 단지 그것의 발톱을 약간 드러냈을 뿐이다. 나는 심지어 구글 브라우저에서 일반적인 웹 브라우저와 달라진 탭(Tab) 위치에서도 구글이 갖는 웹 기반 소프트웨어에 대한 야심을 느낄 수 있었다. 구글이 완전히 이빨을 다 들어냈을 때 구글 브라우저 위에서 구동되는 구글의 웹 기반 소프트웨어들이 어떤 모습이 될지 기대되는 바이다. 또한 구글은 한발 짝식 구글 제국(?)을 건설하기 위해 도전적으로 전진하는 모습이 부럽다. 우리나라에도 이와 같이 좀더 원대한 목표를 갖고 전진하는 소프트웨어 개발사들이 많아졌으면 하는 바램이다.@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

춘천 여행

(라떼군) — Thu, 28 Aug 2008 22:33:46 +0900

8월 26일부터 28일까지 춘천으로 동원예비군을 다녀왔다. 동원예비군은 이번이 처음이라 약간 긴장된 기분으로 포탈사이트에서 몇 가지 사전 지식을 입수하고 다녀왔다. 후덥지근한 날씨와 따가운 햇볕 때문에 좀 곤혹스럽긴 했지만 그래도 비록 그 당시에는 그렇게 생각 안 했을지 몰라도 지나간 압축된 기억으로 다시 되짚어보면 괜찮았던 것 같기도 하다. 특히 야간훈련 때 쏟아질듯한 별들을 볼 수 있었던 건 너무 좋았다.

예비군

모처럼 춘천까지 왔는데 머리 좀 식힐 겸 몇 군데 구경하고 서울로 돌아가기로 마음먹었다. 예비군복을 입고 돌아다닌 다는 것은 사람들 시선도 신경 써야 해서 부담스럽긴 했다. 부담스러운 이유는 더운 날씨게 맞지 않게 나를 힘들게 하는 두꺼운 군복 탓도 있었지만 가장 큰 부담은 어디를 가나 사람들의 따가운 시선을 받아야 한다는 점이다. 역시 군복을 입은 순간부터 사람들에게는 신기한 존재가 된 듯 하다. 하지만 나는 게이치 않고 제대로 구경하기로 마음먹었다.

배용준,최지우 마네킹

먼저 춘천에서 가장 먼저 들른 곳은 시내에 있는 '드라마 갤러리'라는 곳이다. 이곳은 지나가다가 우연히 발견한 곳이다. 겉으로 볼 때는 꽤 규모가 있어서 기대가 컸었는데 막상 들어가보니 너무 볼게 없었다. 그냥 욘사마를 좋아하는 일본인들을 끌어들이기 위한 간단한 '겨울연가' 드라마 소개소 정도여서 좀 아쉬웠다. 왠지 욘사마를 좋아하는 일본인들이 오기 만들 목이 빠져라 기다리는 두 명의 안내원이 약간 불쌍해 보이기 까지 했다.

겨울연가 피아노

이런 곳을 만드는 것 자체가 참 유치하다. 언제까지나 '겨울연가'를 통한 한류열풍이 계속될 것이라고 생각하는 것일까? 드라마의 인기나 배우에 대한 인기는 언젠가는 식기 마련이기 때문에 정말 '드라마 갤러리'로 운영할 생각이라면 춘천을 배경으로 하는 드라마를 좀더 많이 유치해서 여러 편의 드라마를 같이 소개하는 곳으로 만드는 것이 바람 직 하다고 생각한다.

소양강댐 입구 인공폭포

소양호1

소양호2

소양호3

다음으로 찾은 곳은 소양강 댐이다. 역시 춘천 하면 가장 먼저 생각나는 곳은 소양강 댐인 듯이 경치도 장관이었다. 소양호를 바라보기 가장 좋은 자리에 '소양강댐 물 문화관' 이라는 것이 보였다. 2007년 1월에 새로 문을 연 곳이라고 한다. 이곳은 시설도 깨끗하고 볼 것도 많고 그리고 입장료도 무료여서 참 맘에 들었다. 총 3개 층으로 이루어져 있고 각 층마다 소양강댐과 관련된 내용 또는 물과 관련해 볼만한 것들을 전시해 놓고 있었다. 어른들도 관람하기 괜찮았지만 만약 어린 자녀가 있다면 같이 구경하는 것도 꽤 괜찮을 것이라는 생각이 들었다. 4층에는 전망대가 있었는데 소양강호를 그 어느 곳보다도 가장 높은 곳에서 바라볼 수 있어 좋았다. 가슴이 확 트일 듯한 기분이었다.

소양강댐 물 문화관

소양강댐 물 문화관1

소양강댐 물 문화관2

소양강댐 물 문화관3

소양호를 뒤로하고 기차역(남춘천역)으로 향했다 마침 가는 길에 소양 제2교를 건넜고 건너면 바로 보이는 소양강 처녀 동상을 멀리서만 바라보았다. 날씨가 너무 더웠기 때문에 버스에서 내리는 것이 너무 힘들어 그냥 멀리서 바라만 봤는데 집에 와서 소양강 처녀 동상으로 검색해 확대된 사진을 보니 멀리서 볼 때와 달리 가까이서만 볼 수 있는 소양강 처녀의 예쁜 모습을 보지 못한 것 같아 좀 아쉬웠다.

남춘천 기차표

처음 와본 남춘천역. 춘천역 하면 '와니와 준하'가 생각나는데 영화에 나왔던 장면과 거의 다르지 않았다. 나는 철길를 건너 기차를 타러 가는 이런 클래식한 분위기의 기차역이 좋다. 나는 버스보다 기차를 더 좋아하는데 기차가 버스보다 좋은 점을 꼽으라면 기차의 칙칙폭폭 소리와 기차 안에서 파는 김밥과 삶은 달걀(요즘은 KTX가 아니면 기차 안에서는 팔지 않는가 보다.) 그리고 클래식한 분위기의 기차역에서 철길을 넘어 씩씩거리며 출발할 것을 기다리고 있는 열차를 올라탈 때 그 설래이는 느낌을 특히나 좋아한다.

남춘천역(와니와 준하)

이번 여행은 잘못하면 그냥 구경도 못하고 돌아올 뻔한 길을 시간이 잘 맞아 구경할 수 있었다는 게 참 좋았다. 아니다. 시간이 잘 맞아서 구경할 수 있었던 것은 아닌 것 같다. 여행은 시간이 맞고, 기회가 좋아야만 할 수 있는 것은 아닌 것 같다. 여행에는 여유라는 것이 필수적으로 필요 하다. 이번에 내가 구경할 수 있었던 이유도 여유를 가지려고 노력했기 때문에 가능했던 것 같다. 아무리 좋은 풍경이 눈앞에 펼쳐서 있다고 하더라도 자기 마음속에 여유가 없다면 그 절경(絶景)이 제대로 눈에 들어오기나 할 것인가?

일을 할 때도 마찬가지 인 것 같다. 어떤 문제가 닥쳤을 때 남들보다 더 현명한 방법으로 문제를 해결해 나가는 사람들을 보면 항상 여유를 갖고 있음을 확인할 수 있을 것이다. 어려운 문제에 대해 아주 많은 고민은 오히려 그것을 바라보는 시각을 좁혀 좋지 않은 방법으로 문제를 해결할 가능 성이 크다는 것을 이미 경험을 통해서 알고 있을 것이다. 어려운 일이 있거나 흥분되는 일을 해결할 때 필요한 것은 잠시 한발 짝 물러서 심호흡을 할 수 있는 여유가 필요한 것이다. 이처럼 여유로운 마음은 삶을 더 즐겁게 살아가기 위한 열쇠 같은 것인지도 모르겠다. 나도 여유를 갖고 살아가기를 원한다.@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

소프트웨어의 요구사항

(라떼군) — Sun, 24 Aug 2008 13:48:37 +0900

How Project Really Work(http://www.projectcartoon.com)

소프트웨어 개발자(software developer)로써 일을 하다 보면 기획자와 많은 시간을 보내게 된다. 여기서 기획자란 말은 소프트웨어의 요구사항을 만들어내는 사람이라고 봐도 좋겠다. 혹은 드물겠지만 기획자라고 부를 만한 사람이 없다면 소프트웨어를 사용하는 사용자를 떠올리기 바란다.

요구사항을 만들어내는 사람들은 개발자를 곤혹스럽게 하곤 한다. 그것은 근본적으로 개발자가 하고 싶지 않은 일을 시키기 때문이라고 생각한다. 개발자는 성능을 중시하고 코드가 얼마나 간결한지를 중시하곤 하는데 복잡한 요구사항들은 이런 코드를 지저분하고 복잡하고 느린 모습으로 바꾸곤 하기 때문이다. 하지만 자신의 소프트웨어가 살아 있는 한, 자신의 소프트웨어를 사용해주는 사용자가 있는 한, 요구사항이 있는 한 이러한 일은 끊이지 않을 것이다.

같은 요구사항이라도 기획자에 손을 어떻게 거치느냐에 따라 어렵고 시간이 오래 걸리는 것이 있는 반면 간단하면서 빨리 끝낼 수 있는 일도 있었던 것을 많이 보아왔다. '실력 있는 개발자라면 오래 걸리는 개발도 쉽게 끝낼 수 있을 않느냐?' 라고 반문하실 지도 모르겠다. 하지만 이건 실력하고는 별개의 문제라고 생각한다. 나의 경험을 비춰 봤을 때 똑같은 기능이라도 어떤 기획서는 작업하기 쉬웠던 반면에 어떤 기획서는 작업하기 힘들었던 적이 분명히 있었기 때문이다. 이것은 기능의 많고 적음을 얘기하는 것은 결코 아니다.

어려운 기획서의 가장 큰 부분은 기존에 이미 요구돼있던 기능의 기본적인 틀의 변경이 여러 번 번복되어서 가해지는 부분이다. 한번 이렇게 바꿔보고 또 아니다 싶으면 다르게 바꿔보는 식이다.

이것이 어려운 이유는 간단해 보이는 요구사항일지라도 소프트웨어 설계 전체에 대한 수정이 가해져야만 적용될 수 있는 부분이 있기 때문이다. 웹 어플리케이션을 예로 들면 대부분 데이터베이스와 밀접한 관계를 가지고 그것의 설계에 기초 하는 것들이 많기 때문에 데이터베이스의 설계가 심하게 변경 되어야만 했을 때 데이터베이스 레이어(Database layer)부터 프레젠테이션 레이어(Presentation layer)까지 수 많은 부분들이 변경되어야만 한다. 기획자는 기존 요구사항에 대한 수정 또는 요구사항 번복에 대해 충분히 신중해야 할 것이다. 사실 이것이 내가 실제로 일을 하면서 기획자들에게 가장 불만을 갖고 있는 부분 이기도 하다.

사실 기획자들이 이런 변경에 대한 요구를 끊임없이 해오는 이유는 고객의 요구사항을 제대로 파악하지 못해서 생긴 일이 대부분 이라고 생각한다. 일반 고객들이 바로 요구사항을 만들어내는 상황의 소프트웨어라면 이런 잦은 요구사항 수정에 책임은 요구사항을 제대로 파악하지 못한 개발자에게 있다 것이다. 또 기획자에 의도를 제대로 파악하지 못해 엉뚱한 것을 만들어 내고 있었다면 이것 역시 개발자 책임일 것이다. 그냥 한번 만들어보고 그게 아니면 또 바꾸는 식의 해결방법은 곤란하다. 하지만 이런 문제를 해결할 수 있는 방법은 얼마든지 있다.

프로토타입(Prototype)을 이용해 해결할 수 있다. 프로토타입이란 어떤 구조물이나 장비에 대하여, 형상이나 설계, 적합성 또는 성능 등을 평가하기 위해 만든 실물 크기의 모형을 말한다.(http://terms.co.kr) 즉, 기획자가(고객이) 무엇을 원하는지 제대로 모를 때 프로토타입을 빠르게 만들어서 보여주고 ‘이게 맞습니까?’ ,’이 정도면 되겠습니까?’ 이렇게 물어볼 수 있는 것이다. 요구사항이 명확히 파악된다면 그걸 기반으로 더 잘된 설계를 이끌어 낼 수 있을 것이다.

또는 그 소프트웨어를 가지고 일하는 사람들과 같이 지내 봄으로써도 해결할 수 있다. 요구사항을 제대로 파악하지 못하는 이유 중에 하나가 자신의 소프트웨어를 자신이 실제로 써보지 않아서 어떤 것이 어떻게 불편한지 제대로 알지 못해서 일 것이라고 나는 확신한다. 웹 메일 서비스라면 자신이 직접 웹 메일을 써봐야 어떤 점이 업무를 불편하게 하는지 알 수 있을 것이고 게임을 만든다면 직접 그 게임을 해봐야 어떤 점이 재미없는지도 알지 않겠는가?

나는 개발자들이 개발에만 열중할 것이 아니라 고객(또는 요구사항을 만들어내는 기획자)과 소통하는데 더 노력을 기울일 것을 권하고 싶다. 이것이 바로 자신의 소프트웨어를 성공 시킬 수 있는 진정한 one way 인 것이다. 코드가 깔끔한 소프트웨어라고 성공하는가? 자신의 소프트웨어가 사용하기 불편한 대신 코드가 깔끔하다고 광고할 생각인가? 심지어는 버그가 많은 소프트웨어가 다른 경쟁 업체들을 제치고 성공하기까지 하는 이유는 바로 요구사항을 다른 경쟁 업체들 보다 제대로 파악했기 때문이 아닐까?@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

웹 기반 서비스의 업그레이드

(라떼군) — Sat, 23 Aug 2008 14:52:31 +0900

내가 사용하는 웹 브라우저

나는 지금 웹을 기반으로 하는 서비스를 개발하고 있다. 프로젝트의 모든 부분이 웹 어플리케이션은 아니지만 프로젝트를 실행하고 사용 하는데 있어 웹은 필수적이고 실제로 프로젝트의 많은 부분을 차지하는 하고 있다. 몇 일 전에 이런 프로젝트의 버전 업그레이드가 있었다. 웹을 기반으로 하는 서비스의 업그레이드 버전을 출시한 것이다. 웹 기반 서비스의 업그레이드 버전의 출시가 생소한 일일지도 모르지만 우리는 고객에게 변화하는 모습을 보여주고 그 효과를 극대화 하고자 빌드 버전(Build Version)을 사용하고 있고 버전을 업그레이드 하면서 지금까지 계속 제품을 출시했고 이런 대대적인 업그레이드 작업 2번에 걸쳐 현재 버전 2.5에 이르렀다. 하지만 이번 업그레이드 작업을 하는 동안 몇 가지 의문이 생겼다.

'왜 장시간 서비스 중지를 하면서 업그레이드를 진행해야만 하는가?' 대대적인 업그레이드 라는 것은 그만큼 바뀌는 부분이 많다는 것이다. 따라서 해야할 일도 많이 때문에 다른 점검 시간(정기 점검 등 간단한 점검 시간)과 달리 상대적으로 오랜 시간 동안 서비스를 중지해야만 한다. 하지만 고객은 서비스가 항상 온라인 상태이기를 원할 것이다. 이른 새벽부터 중요한 업무를 보기 위해 서비스에 접속했을 때 정검 페이지가 나온다면 얼마나 절망적일까? 이게 만약 웹 메일 서비스라면 상사가 보낸 메일을 제시간에 확인하지 못해 곤욕을 치를 것이고 항공권 발매 서비스라면 제시간에 비행기 티켓 발권을 못하는 일도 있을 수 있을 것이다. 마치 사막에서 힘들게 오아시스를 찾았는데 썩은 물만 고여있는 것을 본 것과 같고 뒷모습이 예쁜 분을 쫓아가 말을 걸었는데 알고보니 남자인 걸 알았을 때의 그런 심정과 같을 것이다. 사실 웹 기반 서비스는 사실 이런 고민을 할 필요가 없다. 웹은 실시간으로 업데이트가 가능하기 때문이다.

'대대적 업그레이드를 하면 안정성이 떨어진다.' 내가 다니는 회사에서는 제품 출시 이전에 QA(Quality Assurance) 팀의 테스트를 거치고 나서 출시하도록 되어있다. 보통 QA팀의 테스트를 마치고 나면 제품의 퀄리티(Quality)가 테스트 이전보다 훨씬 높아져 안정성을 확보할 수 있었다. 하지만 이번처럼 대대적인 개편의 경우 여러 번의 테스트를 거쳤지만 업데이트 이후 이전에 발견하지 못한 혹은 예상치 못한 작은 문제들을 발견할 수 있었다. 마치 싸인(Sign)곡선처럼 업데이트 후 겨우 안정화된 서비스를 다시 업데이트하여 안정성을 떨어뜨리는 현상이 일어나게 되는데 이건 서비스로써 매우 바람직한 현상이 아닐 것이다. 대대적인 업그레이드가 필요한 이유가 고객 홍보화 그 효과의 극대화라 한다면 잦은 업데이트 여러 번으로 기능을 이미 적용해 놓은 상태에서 혹은 기능만 가려놓은 상태에서 마케팅 전략에 따라 언제든지 필요할 때 기능 오픈과 홍보가 가능할 것이다. 이는 웹 기반 서비스 이기 때문에 가능한 장점이다.

웹 기반 서비스는 실제로 사용자에게나 개발자에게 많은 장점이 있다. 사용자는 별도의 소프트웨어 설치 없이 언제 어디서나 같은 소프트웨어를 사용할 수 있다는 장점이 있다. 개발자에게는 소프트웨어의 버그가 있을 때 또는 기능 추가가 있을 때 사용자들에게 새 버전이 나왔으니 새로 설치해달라고 애원하지 않아도 된다. 이것은 서비스의 안정성과도 연관 되어 있는데 이렇게 잦은 업데이트 및 버그 패치를 통해 어떤 종류의 데스크 탑 소프트웨어보다 퀄리티 높은 제품을 만들어 낼 수 있는 것이 바로 웹 기반 서비스라고 생각한다. 구글(Google)의 성장이 말해 주듯이 전 세계적으로 웹 기반 소프트웨어는 현재 소프트웨어 산업의 흐름을 주도하고 있다고 생각한다. 하지만 상대적으로 부족한 우리 나라의 웹 기반 서비스에 대한 안타까운 마음과 함께 우리나라에서 더 많은 웹 기반 Killer Software 서비스들이 나와줄 것을 기대하는 바이다.@

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

프로그래머의 break time

(라떼군) — Sun, 17 Aug 2008 16:14:20 +0900

Stress Qoutes

프로그래밍 작업은 고통스럽다. 사실 프로그래밍하는 작업이 고통스러운 건 아니다. 그건 즐거운 일이며 나에게 있어 생각만으로도 아드레난린(Adrenaline)을 분비시켜 힘을 나게 한다. 하지만 그것이 일과 연관 되어있을 때는 마냥 즐거운 일일 수만은 없다. 프로그래머는 일할 때는 초현실적인 UI(User Interface: 사용자 인터페이스)를 만들어내는 기획자도 설득해야만 하고 자꾸 모호한 말만 하는 애매한 디자이너도 상대해야 하기 때문이다. 하지만 프로그래밍을 하는 사람으로써 마냥 고통스럽게 있을 수만은 없다. 고통의 연속이라면 더 이상 생산성을 떨어뜨릴 뿐만 아니라 회사의 월급도둑 역할만 하는 일은 그만두고 다른 직업을 찾아보는 것이 본인에게도 좋을 것이다. 그럼 항상 즐거울 수만 없는 이런 일들을 어떻게 즐기며 일할 수 있을 것인가?

먼저 '잘 쉬어야 한다.' 일하는 모든 사람들에게 적용되는 말이다. 잘 일하기 위해서는 잘 쉬어야 한다. 하지만 이 말을 오해하는 사람들이 있다. 쉬라는 말이 집에 누워서 아무것도 하지 않은 채로 시체놀이 만으로 주말을 보내라는 그런 말은 아니다. 쉬는 것은 일 외에 다른 곳에 관심을 돌리는 것을 쉬는 것이라고 말할 수 있다. 예를 들면, 회사에서 가상 파일시스템을 개발하는 사람이 남는 시간을 통해 웹 메일 클라이언트를 만들어 오픈 소스 커뮤니티에 올리는 일을 했다라고 한다면 그 사람은 쉬었다 라고 말할 수 있다. 또는, 남는 시간을 통해 새로운 언어(Python, Perl, Lisp …) 공부하는 것도 마찬가지다. 잠시 짜증나는 업무에서 벗어나 생각을 리프레시(refresh) 함으로써 일을 더 즐겁고 잘할 수 있는 것들이 여기에 포함될 것이다.

'원인을 분석해야 한다.' 일이 힘들어 졌을 때는 왜 일이 힘들어 졌는지 어떤 일 때문에 즐겁지 않은지 원인을 분석해야 할 필요가 있다. 노트에 하나씩 적어보자. 예를 들면 이런 것들이 있을 수 있다. '기획자가 보내온 기획서가 너무 엉망이다.', '요구사항이 너무 수시로 바뀐다.', 또는 '상사가 나를 싫어한다.' 등등.. 하나씩 적어보자. 만약 하나도 적을 것이 없거나 납득할만한 내용을 적을 수 없는데 일이 힘들어졌다면 그건 자신에게 문제가 있는 것이다. 모두 적었다면 하나씩 해결하려고 노력해볼 필요가 있다. 기획서가 너무 엉망이라면 왜 엉망인 기획서인지 기획자에게 알려주고 다음부터 보완하도록 얘기해볼 수 있을 것이다. 요구사항이 너무 수시로 바뀐다면 경험적으로 바뀌는 요구사항에 맞게 어느 정도 유연한 설계를 할 필요가 있을 것이고, 상사가 나를 싫어한다면 그 원인을 알고자 상사와 대화해야 할 것이다.

'커피를 마셔라.' 여기서 커피는 자판기 커피나 커피 믹스는 제외한 것이다. 1994년 일본 교린 대학의 연구결과에 따르면 커피 향은 뇌의 혈액량을 증가시키고 뇌파를 변화시켜서 집중력과 쾌감 기능을 높여 준다고 밝혀졌다. 자판기 커피나 커피믹스는 향이 적고 그다지 좋지 않으므로 에스프레소(Espresso)를 마실 것을 권하고 싶다. 난 카페라떼(Latte), 카푸치노(Cappuccino)를 좋아한다. 예전에 홍대 앞에서 근무할 당시 매일 한잔씩 마시던 카페라떼 향은 아직도 잊을 수 없다. 그때 회사가 참 힘들었었는데 생각해보면 그때 힘들었던 일들을 커피 덕에 조금이라도 덜 힘들게 일할 수 있지 않았나 싶다. 커피 한 모금처럼 본인에게 더 맞는 리프레시 수단이 있다면 그것을 찾을 것을 권하고 싶다.

하나씩 고통의 원인을 제거해 보면 프로그래머로써 일하는 것은 고통스러운 일이 결코 아닐 것이다. 고통은 대게 나 자신에게서 시작되고 있고 그게 해결되지 않은 채로 지속되고 있을 땐 결국엔 지쳐 쓰러지게 된다. 그때는 어떤 원인 때문에 내가 힘들어 하는지도 모르고 아무리 쉬어도 회복될 수 없는 상태가 되고 말 것이다. 프로그래밍 작업만 분석적으로 할 것이 아니라 자신의 생활도 디버깅 하듯이 혹은 '커피' 같은 툴의 도움을 받아 고통의 원인을 하나씩 찾아서 해결해 보는 것은 어떨까? @

이미지: Stress Qoutes, http://1927cafe.wordpress.com/2007/09/26/stress-qoutes/

Creative Commons License

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.