Younghoe.Info v3

한국스프링사용자모임(KSUG) 활동이나 프레임워크 전문가로 일하는 탓에 많은 사람에게 스프링 프레임워크 서적 추천 요구를 받아왔지만, 그때마다 기대하는 명쾌한 답을 줄 수 없었다. 대답은 늘 이런 식이었다. “설계 사상을 이해하시려면 로드 존슨(Rod Johnson)이 쓴 세 권의 빨간 표지 책이 가장 좋습니다. 다만, 영문으로 써 있고 설명이 쉽지 않습니다. 한글로 쓰인 책 중에서는 ○○○는 개념 설명은 좋은데 실제 상황에서 문제 푸는 데 도움을 받기에는 부족합니다. △△△는 웹에 있는 공식 참조 문서(Reference Documentation)를 기준으로 개괄적인 내용을 정리한 책입니다. 처음 따라 할 의도라면 ×××가 좋습니다.” 구구절절히 설명한 까닭은 자신 있게 추천할 수 있는 한글 책이 없기 때문이었다. 그러나 앞으로는 자신 있게 이 책을 추천할 수 있어 흐뭇하다.

저자인 이일민 씨를 아는 사람에게는 긴 설명이 필요 없겠지만, 잘 모르는 분을 위해 이 책의 고유한 가치를 몇 가지 떠올려봤다.

첫째, 뛰어난 강사이기도 한 저자의 효과적인 강의 스타일을 담아낸 책의 이야기 전개다. 저자는 대뜸 스프링이 가진 기술을 나열하기보단 친숙한 자바 코드(초난감 DAO)를 내밀었다. 책을 읽어가면 점차 독자는 흔히 쓰이던 코드의 문제점에 공감하고, 여러 가지 방식으로 개선해가는 여정을 함께한다. 책과 함께 고민한 독자라면 여정의 끝에서 스프링을 쓰는 이유와 어떤 게 올바른 사용법인지 배울 수 있다. 사실 이런 전개는 정말 뛰어난 외국 서적에서는 종종 볼 수 있는 방식이지만, 한글 기술서로 한정하면 가히 독보적이라 할 수 있다.

둘째, 사상과 활용법을 모두 담은 넓은 효용성이다. 시중에 두꺼운 기술서는 드물지 않지만, 이 책은 API 설명이나 화면 캡처로 지면을 할애하지 않았다. 책 전반부는 객체지향 프로그래밍 관점에서 어떤 코드가 좋은 코드인지를 다루면서 왜 스프링을 써야 하는지를 설명하고, 후반부는 스프링을 구성하는 요소 기술을 올바르게 사용하는 방법을 빠짐없이 설명하고 있음을 상기하면 책의 두께는 놀랍도록 얇다(?). 학습과제에만 초점을 맞출 수 있도록 구성한 장의 구성과 단계별 예제는 SoC(Separation of Concerns)를 통해 방대한 내용을 모두 담아내기 위해 저자가 각고해 노력한 결과물이다.

셋째, 책의 내용과 예제 코드의 정확함이다. 프로그래밍 서적으로 공부할 때 예제가 작동하지 않아 시간을 허비한 경험이 있는 개발자는 드물지 않다. 1부는 테스트 주도로 진행하고, 2부도 예제 전부가 테스트 코드 형태로 만들어져 결함을 막았다. 한편 개념 설명을 위해 다이어그램을 활용하고 코드에도 충분한 부연 설명을 붙인 결과, 섬세하고 정확한 내용이 만들어졌다.

나름대로 객관적인 시각으로 책의 가치를 정리했더니 책을 볼 때 느낀 감동은 잘 드러나지 않아 개인적인 소회를 덧붙인다. 변변한 책이 없던 시절 스프링을 이해하기 위해 어쩔 수 없이 스프링 소스코드를 봤다. 스프링 소스코드는 객체를 조직화하는 설계에 대한 모범답안과도 같았다. 하지만 방대한 코드만 보고 의도를 모두 익힐 수는 없었다. 그 후에 로드 존슨의 책을 반복해 읽으면서 스프링을 이해할수록 감탄하고 또 감탄했다. 다행스럽게도 지금 스프링을 공부하는 여러분에게는 더 나은 방법을 제시할 수 있다. 로드 존슨이 했던 이야기를 로드 존슨은 할 수 없는 우리말로 읽을 수 있다. 그리고 진정한 고수 개발자로 꾸준히 노력해온 이일민 씨의 노하우를 함께 배울 수 있다.
이일민 씨는 한국스프링사용자모임의 공동 설립자다. 2007년 우리는 수차례 공개 세미나를 통해 스프링을 알렸다. 이 책은 그의 수많은 고민과 생각을 그러모아 담아낸 결정체다. 지금보다 많은 자바 개발자가 이 책을 읽고 진정한 설계에 대해 고민을 함께 하는 모습을 상상해본다. 그리고 이일민 씨의 다음 행보를 기대한다. :)

- 안영회(http://younghoe.info)
한국스프링사용자모임공동설립자, (주)아이티와이즈컨설팅 컨설턴트


토비의 스프링 3 -
이일민 지음/에이콘출판

5. 구글의 데이터센터 건설후보지 선정기준

• 대량의 전력이 저가로 공급될 것
• carbon-neutral을 실현할 수 있을 것
• 대량의 물 공급을 기대할 수 있을 것
• 광대한 토지를 확보할 수 있을 것
• 다른 구글 데이터센터와의 거리
• 세제상의 우대조치가 있을 것

이 중에서 1, 2, 3번이 흥미롭다. carbon-neutral이란 실질 이산화탄소 배출량을 0으로 만드는 것을 의미하는 소위 그린IT 활동에 해당한다. 3번의 물 공급은 설비 냉각 용도다.

출처: 클라우드의 충격 45~47쪽

4. 아마존 Dynamo 구현 사례
Amazon's Dynamo by Amazon CTO, Werner Vogels

3. 주요 인사, Sun CEO 그렉 파파로폴로스 발언
Sun CEO


2. 고객 이탈방지 전술에 대한 정리

고객 이탈방지(lock-in) 전술	핵심 수단	극복책
Technology-based lock-in	compelling technology	기술 모방
Data-based lock-in	데이터 Migration 장벽	Migration 도구 제공

데이터 기반 이탈방지 전술 중에 특이한 점
To the extent that customers depend on provider-proprietary data, there is a real lock-in danger. I think that’s one of the major reasons that lots of companies are excited about the idea of providing cloud services. Build a platform with compelling data that nobody else has, and you have a powerful lock-in mechanism.

Any organization contemplating moving applications to the cloud needs to consider how it wants to deal with this sort of lock-in risk.

출처:  Thoughts on cloud portability

1. 그리드 컴퓨팅과 클라우드 컴퓨팅의 차이

주요 사이트

• 위키피디아: http://en.wikipedia.org/wiki/Cloud_computing
  

클라우드의 충격 - 시로타 마코토 지음, 진명조 옮김/제이펍

아직 출간 전이지만 집필은 끝난 상태로 못 다한 이야기를 벌써 후기로 적었군요. 욕심쟁이..

• [토스 3] 테스트를 위한 필드 주입 유틸

토비의 스프링 3 -
이일민 지음/에이콘출판

아키텍트 대회 Q&A 시간에 들은 가장 인상 깊은 질문에 대해 메모.

(오라클) 그리드 컴퓨팅과 클라우드 서비스 사이의 차이에 대해?

답변하신 분은 이들이 완전히 별개의 기술이 아니라 연속선 상에 있는 기술이며, 두 용어 사이의 차이점은 큰 의미가 없다는 논지였다. 하지만, 질문하신 분은 그래도 새로운 말이 쓰일 때는 이유가 있지 않으냐는 입장이었다. 전문분야가 아니지만 들은 내용에 따르면 얼핏 이런 생각이 들었다.

그리드는 컴퓨팅 환경을 꾸미는 제공자 입장이고, 클라우드는 사용자 측면에서 (어떻게 서비스가 제공되는지는 모르는 상태로) 컴퓨터를 사용하는 현상을 거론한 표현이라고 알고 있다.

생각난 김에 이하는 위키피디아 정리를 비교^[각주:1]


오호.. 역시 위키피디아 정리가 대단하군. 그리드는 운영자가 다른 컴퓨터의 조합을 의미하고, 그래서 개인차원에서도 참여하여 그리드를 형성하자는 구호가 있었지. 전통적인 클러스터와 다른 점은 역시나 상대적으로 낮은 결합도와 이기종에 지역적 편재이다. 한편, 클라우드와 차이라고 생각할 수 있는 점인데 특정한 목적을 위해 많은 컴퓨팅 자원이 결합했다는 점이다. 주로 과학적인 문제나 슈퍼컴퓨터를 대체하는 거대한 PC 조합을 예로 들었던 일이 생각난다. 클라우드 서비스를 제공하기 위해 그리드를 구성할 수는 있다.

클라우드는 일단 구름으로 대변하는 인터넷 기반이다. 핵심은 필요할 때 혹은 필요한 만큼 쓰는 수요 중심적(On Demand)이란 점.

* 7월 27일 클라우드의 충격 내용 일부 발췌

클라우드의 충격 6~11쪽에서 잘 설명하고 있다. 차이점 위주로 특징을 비교한 표를 발췌한다.

	그리드 컴퓨팅	클라우드 컴퓨팅
컴퓨터 위치와 관리주체	지리적으로 분산되어 있고, 각기 다른 조직이 관리	지리적으로 분산되어 있지만, 중앙에서 단일 조직이 관리
컴퓨터 구성	이기종 혼재	동일기종이 많음
표준화 단체	존재	존재하지 않음
기술표준	리소스 관리나 스케줄링, 테이더 관리, 보안 등의 기술표준이 존재	특별히 없음
상호 접속성	중시	고려되지 않음
용도	과학기술 계산, 대규모 연산처리 등 병렬성이 높은 애플리케이션	과학기술적 계산 등과 함께 웹 애플리케이션 등 광범위한 용도로 이용 가능

대신증권의 자바로 쓴 금융 차세대 새 역사

아직도 증권에서는 기간계에는 섣불리 자바를 쓰지 못하는 현실이기에 초기 도입 사례

트랙백을 보고 혹시 오해가 있을까봐 첨언합니다. (7/27)
이미 은행이나 보험사에서 자바를 쓴 사례가 많습니다. 주로 증권사에서 회사에 따라 주전산/기간계/처리계 등으로 불리는 업무 시스템에 대해서 잘 돌아가는 시스템의 형상을 바꾸지 않으려는 태도가 자바에 대한 불신으로 퍼져 있다는 이야기를 들은 일이 있습니다. 이 사건이 정확하지 않은 통념을 바꾸는 계기가 될 수 있다는 의미에서 메모했습니다.

경험적으로 몇 가지 기준은 뚜렷하다.

• 공식적/대외적인 활동(예: 계약, 검수, 보고, 외부 기관 인터뷰 등) 혹은 이해관계자가 많은 작업(예: TFT 회의, 단계말 검토)일수록 미리 계획하고, 바꾸기 힘들기 때문에 다른 활동을 변경해서라도 지킬 수 있도록 계획을 수립한다.
• 활동을 기준으로 삼지 말고 산출물 기준으로 활동을 배열한다.

두 가지 원칙을 잘 사용해도 계획 수립이나 검증이 가능할 법하다. 종종 대형 프로젝트에서 WBS로 정리한 복잡한 계획일수록 산출물 사이의 연관관계를 고려치 않고 별도로 계획하는 경우를 볼 수 있다. 계획의 무결성(Integrity)이 깨진 경우라 할 수 있다. 이는 위의 두 가지 기준을 가지고 검증했다면 걸러낼 수 있는 부분이다.

상기시킨 원칙을 기준으로 미리 수립한 계획을 정제해봐야지. 혹시 남길만한 교훈이 있으면 추가하겠음. :)

지메일을 쓴다면 구글 메신저 대화 내용도 메일 화면에서 찾을 수 있다. 홍길동과 대화한 내용을 찾고 싶다면 아래처럼 한다.


거의 매일 꾸준히 쓰다보니 누군가에게 메신저로 불러줬던 내용을 찾을 수 있어 좋았다. 오늘 아침 경험한 유용한 상황 두 가지를 메모해둔다.

• 다시 대화를 하려는데 어제(마지막으로) 했던 대화가 가물가물할  

어제 했던 말을 다르게 기억하고 대화를 다시 하거나, 했던 말을 또 하면 상대를 당혹스럽게 하거나 번거롭게 한다. 이러한 의사소통 혼선/낭비를 막기 위해 '마지막에 무슨 이야기를 했지' 확인해보는 것. 매우 유용했다. 확실히 정하지 않은 약속 일자를 확인하거나... 마지막으로 논의했던 쟁점을 다시 떠올릴 때.. 점점 약해지는 기억력 보조 수단으로 구글 토크는 아주 좋다. 사내 메신저나 여타 메신저도 대화 저장은 제공하지만, 파일로 저장하는 경우 내용 검색에는 제한이 있어 확실히 지토크의 이점이다.

• 인터넷이 끊겼을 때 주의사항

구글 토크를 쓸 때 주의할 점도 있다. 마지막으로 대화하다가 인터넷이 끊겼을 때 종종 다음 대화가 어색한 경험을 한다. 화자가 마지막에 한 이야기와 청자가 마지막으로 들은 이야기가 다르기 때문임을 오늘 확인했다. 전에는 A, B, C 순서로 말하다 끊기면 A, B 까지만 가서 그런가 하고 내 입장에서만 생각했는데... 눈에 보이는 것만 고려해 양방향이란 점은 생각 못했다.

방금 비슷한 상황을 경험했다. 끊기기 전 내 화면은 ... (업무정보/개인정보보호를 위해 일부 내용 조작)

밑줄 그은 내용을 못 봤으니 다시 대화를 재개하면.. 예의 혼선이나 의사소통 낭비가 발생한다.

일민형이 토비의 스프링 3 간략 목차를 올렸다. 미리 원고를 받아 반쯤 읽었는데 1부에선 인터페이스 기반 프로그래밍(Programming to interface)나 DI(Dependency Injection)의 필요성을 몸소 체험할 수 있도록 쓰여져 있다. 또, Spring Template 코드에 대해서도 실습을 하며 배울 수 있다. 예전에 스프링 컨퍼런스를 갔을 때 Rob Harrop에게 스프링 하위 기술 중에 무엇을 좋아하냐고 물었을 때가 기억난다. 스프링소스 직원 신분탓인지 직접 고르지는 않고, 자사 최대 고객인 JP Morgan에서는 스프링 기술 중에 오직 JDBC Template만 쓴다는 대답을 했다. 스프링에 관심 있는 분이라면 실습을 통해 직접 느껴 보시길...

REST에 대해 문외한일 때 글 하나 쓰면서 그린 그림

• Representational State Transfer (REST)
• a simpler alternative to SOAP- and Web Services Description Language (WSDL)-based Web services ... 하지만, 일민형이 만난 웹서비스 전문가에 따르면 REST가 시작은 쉽지만 갈수록 첩첩산중이라 WS-*가 깊이 들어가면 도리어 쉽다고 하는데...
• REST defines a set of architectural principles by which you can design Web services that focus on a system's resources, including how resource states are addressed and transferred over HTTP by a wide range of clients written in different languages. 출처: http://www.ibm.com/developerworks/webservices/library/ws-restful/
• 정작 처음 등장한 논문 Roy Fielding's dissertation, "Architectural Styles and the Design of Network-based Software Architectures." 을 통해서는 반향이 적었다.
• a concrete implementation of a REST Web service follows four basic design principles:
• Use HTTP methods explicitly. (고전인 RFC 2616 다시 보기)
• To create a resource on the server, use POST.
• To retrieve a resource, use GET.
• Web caching tools (crawlers) and search engines에 의해 의도치 않는 상태 변환을 막으려면 파라미터 대신 POSTㄴ

• POST /users HTTP/1.1
  
  Host: myserver
  
  Content-Type: application/xml
  
  <?xml version="1.0"?>
  
  <user>
  
    <name>Robert</name>
  
  </user>
  
          

• To change the state of a resource or to update it, use PUT.

• PUT /users/Robert HTTP/1.1
  
  Host: myserver
  
  Content-Type: application/xml
  
  <?xml version="1.0"?>
  
  <user>
  
    <name>Bob</name>
  
  </user>
  
  

• To remove or delete a resource, use DELETE.
• Be stateless.
• REST Web services need to scale to meet increasingly high performance demands.
• Stateful 모형
• Stateless 모형
• A stateless service not only performs better, it shifts most of the responsibility of maintaining state to the client application. ... the server is responsible for generating responses and for providing an interface that enables the client to maintain application state on its own
• This aspect of RESTful Web service design can be broken down into two sets of responsibilities as a high-level separation
• Server: 상태가 없으니 캐시 하기 좋고, 상태 대신 네비게이션 위한 링크를 포함
  
• Client application: Cache-Control response header 이용해서 캐시 여부 결정하고 Conditional GET 활용하며, 매번 독립적인 요청임
  
• Expose directory structure-like URIs.
• Think of a URI as a kind of self-documenting interface
• the structure of a URI should be straightforward, predictable, and easily understood
• One way to achieve this level of usability is to define directory structure-like URIs.
• http://www.myservice.org/discussion/topics/{topic
• http://www.myservice.org/discussion/2008/12/10/{topic} a.k.a http://www.myservice.org/discussion/{year}/{day}/{month}/{topic}
• Some additional guidelines
• Hide the server-side scripting technology file extensions (.jsp, .php, .asp)
• Keep everything lowercase.
• Substitute spaces with hyphens or underscores.
• Avoid query strings as much as you can.
• Instead of using the 404 Not Found code if the request URI is for a partial path, always provide a default page or resource as a response.
• Transfer XML, JavaScript Object Notation (JSON), or both.
• Common MIME types used by RESTful services
• application/json
• application/xml
• application/xhtml+xml
  

역시 술김에 사심 가득한 홍보성 글을 올립니다. 사랑(?)하는 토비 형이 지난 일년간 연 수입의 9/10를 손해 보면서 화끈하게 투자한 책이 다음 달에 나오네요. 앞으로 다시는 저술이나 번역을 안하겠다고 할 만큼 심혈을 기울인 책입니다. 화공과 출신이라 그런지 몰라도 1장은 조금 지루하지만 로드 존슨(Rod Johnson)도 한글을 안다면 인정할만한 책이 아닌가 합니다. 물론, 지금 술김이지만, 추천합니다.

특히나 DI(Dependency Injection) 설명을 위한 초난감 DAO 개선 절차는 이 책의 꽃입니다. 물론, 실무 수준에서는 2부의 엑기스 중심 정리가 더욱 도움이 되겠지만 말이죠... 쩝... 암튼 형 대단해. 2006년 일면식도 없는데 까칠하게 블로그에 태클 단 일 이해해줄께. 다음에 서울 오면 오룡해삼 쏴~

• 개발자 Mindshare
  

 

• Installed base and number of apps

• Learning Curve
  

• Debugging

출처: Developer Perception on Mobile Platforms Survey Results

채수원님으로부터 책을 증정받은 지가 한참인데 바쁘다고 잊고 살다가 일민형이 백년만에 쓴 서평을 보고 몇 자 덧붙인다. 일민형 서평에 완전 공감하는지라 "me, too." 라고 달아도 충분하지만 짧게 추가.

한마디로 정말 좋은 책이다. 이미 TDD에 익숙한 사람이라도 한번은 훑어볼만한 책이고, TDD에 익숙치 않다면 MUST HAVE 아이템이다. 이 책은 TDD나 자동화 테스트 실천에 필요한 꼭지를 두루 다루고 있다. 일민형이 책 분량이 적다고 아쉬워했는데 난 아이폰이나 플래쉬 책만큼 많이 팔리지는 않는다는 점이 아쉽다. 사실 그래서 더욱 값진 책이다. 열악한 시장성(?)에도 불구하고 집필한 저자의 노력과 의지의 결과물이니까.

책 Q&A를 위한 그룹스가 있다. '애프터'를 만들어가는 독자를 기대하며 찾은 김에 가입을 했다. 책 공식 사이트에 책에 실어준 인터뷰가 있길래 링크한다.

WS-* 를 통칭한 웹 서비스(Web Services)는 한물간(?) 듯 보인다. 사실 우리나라 SI 흐름을 보면 자체 개발한 원천 기술은 찾기 어렵고, 외부에서 도입하는 기반 기술은 짧은 주기로 떴다 가라앉곤 한다. Toby 형이 전해주는 해당 분야 전문가의 말에 따르면 RESTful은 간소하기에 처음에는 편리하지만, 개발을 진행할수록 어렵다고 한다. 사실 상식적인 일이다. 오랜 시간 존속한 산업 표준은 이윤을 추구하는 업체가 만든 자산이 있기 마련이다. 범용성을 추구하는 기술일수록 번거로운 일이 따르지만, 반대급부로 주어지는 혜택도 있기 마련이다.

요즘 모바일 붐에 편승해 RESTful 인기가 피부에 와 닿는다. 이런 상황에서 웹 서비스 개발을 새로 시작하는 프로젝트를 들었다. 어차피 알맹이가 중요하지만, 혹시 세상모르고 웹 서비스 추구하다가 비싼 WS-* 솔루션에 투자했다가 이내 RESTful로 다시 개발하지는 않기를 바란다.

작년에 이어 또 발표합니다. 마지막 세션인 40번이네요.

2회 대회 좋았던 점

• 좋은 고객을 만나는 기회
• 좋은 동료(SDS 임술사님)을 만나는 기회
• 한참을 기다려 참석한 질답 시간에 만난 열정적인 참석자
  

아쉬웠던 점

• 40분 발표였는데 앞에서 일장연설하신 분이 있어 실제 20분으로 줄어서 후다닥 골자만 이야기함
  

Code Squiggles이라는 아이디어는 흥미롭다. JUnit 혹은 hamcrest Matcher 혹은 그 이전 Mock 라이브러리에서 봤던 표현이지만, 글에서는 넓은 사용 사례를 말하고 있다. 가장 두드러진 부분만 발췌하면 이렇다.


위와 같은 메소드가 있다면 사용자(client) 코드는 다음과 같다.


사용자 코드만 보아서는 나열한 숫자를 어디에 쓰는지 보이지 않는데 이때 Code Squiggles로 장식할 수 있다.


의도가 명확해진다. 자주 쓰는 경우는 번거로울 수도 있겠지만, 다른 사람이 코드를 보는 경우까지 고려하면 주석보다는 좋은 방법이다.

Code Squiggles 구현 예는 다음과 같다.


위에 언급한 사례만으로 Code Squiggles 도입 가치를 판단하기는 빈약하다. 경험에 따른 상상력이 필요하다. 우선 assertThat과 hamcrest API의 예를 보면 가치가 있다. 특정 영역(domain)으로 한정해서 주요 어휘를 표준화해서 공용으로 쓸 때 코드를 쉽게 소통할 수 있다. 그런 점에서 범위를 한정해서 지속적으로 사용하고 정제하면 일종의 DSL(Domain Specific Language) 제작에 기여하지 않을까 싶다.

squiggle의 뜻을 찾아 보니 구불구불한 선이라고 한다. 감이 잘 안오는데, 'Add flair to your code'란 문구가 힌트를 준다. 아래 그립이 보여주는 squiggles와 달리 code squiggles는 미려하게 보이기 위해서가 아니라 코드 이해를 돕기 위한 장식이란 점이 차이가 있다.

파견(?)근무처에서 복귀하면 흔적이 남는다. 보안 프로그램을 담당자가 제거해주는 경우도 있지만, 그렇지 않은 경우가 있다. 보안 프로그램은 Uninstaller를 제공하지 않는 경우가 많고, 대개 제어판을 이용해 쉽게 지울 수 없다. SePros라는 USB 접근 방지 프로그램이 남아 제거해야 했다. 제어판을 통해 지울 수가 없고, 짧은 윈도우 지식에 레지스트리 편집을 하긴 불안해서 구글링 했더니... unlocker가 떴다.

설치하고 실행한 뒤에 탐색기에서 Programfiles\BnB(?) 폴더를 선택한다. 실행중인 핸들이 뜨면 이를 종료한 후에 다시 개체 삭제를 선택하면 지워진다. 시작 프로그램으로 등록되어 번거로웠는데 재부팅 해보니 사라졌다. SePros뿐 아니라 유사하게 uninstaller가 제공되지 않는 프로그램에서는 모두 사용할 수 있겠다.

쓰고 싶은 생각이 있었는데 한 동안 블로그를 방치했더니 떠오르지 않는다. 예전에는 글이 뜸하면 '요즘 바쁘신가봐요.'라는 말을 듣고, 글을 자주 쓰면 '어떻게 그렇게 글을 자주 쓰세요.'하시는 말씀이 인사였던 때가 있다. 이제는 거리가 먼 이야기다. 생각 난 김에 살아 있음을 알리는 글을 쓴다.

한번 이런 생각을 했다. 좋은 말이나 좋은 생각을 지껄이거나 떠올리긴 쉽지만 실천은 쉽지 않다. 한 번 하고 나서 우쭐대면 이내 다시는 행동에 옮기지 못하곤 한다. 그때 사람들이 하는 말이 떠올랐다. 자신과의 싸움이 힘들다는 뜬구름 잡는 듯한 말.

새로운 마음으로 어제와 다른 나인척 해면, 삼십 여년 몸에 밴 습관과 싸워야 한다. 아무리 새로운 의지가 샘솟아도 수십, 수백만 배의 습관과 부딪혀 이기는 일은 그리 만만치가 않다. :)

세대와 나이를 떠나 뜻을 같이 한다고 믿는 분이 자신이 번역한 책에 대해 실날한 비판일지라도 허심탄회한 의견을 요구하셨다. UML 쓸 일이 드문터라 시간투자가 부담스럽지만 '개체 매니페스토'를 떠들고 실천을 안한 죄로 차분히 책장을 넘겨봤다. 워낙 고전이고 철저한 번역 내용을 비난하기는 어렵다. 굳이 찾자면 '산출물도'가 눈에 띄였다. 얼핏 읽으면 '산출물'에 조사가 붙은 어구인 듯도 하고, 발음하기에도 좋지 않다. 다이어그램(diagram)을 '~도(圖)'로 번역했기 때문인데 산출물도에 있어서는 예외를 두어 '산출물 도해'로 표현했으면 어땠을까 싶은 정도로 허점을 찾으려면 긴 시간 노력이 필요할 듯하다.

사실 책에 대해 하고픈 이야기는 따로 있다. 이전에 이런 일이 있었다. 원서를 교재로 쓰는 수업인데 한 친구가 서점에도 없는 번역서를 구해서 자기 발표 시간에 한글 용어를 쓰며 발표했다. 교수님이 호되게 질책을 했다. 니가 뭔데 마음대로 용어를 정하냐는 것이었다. 교수님 논지는 용어 하나 하나 뒤에는 무수히 많은 논문이 있다는 것이다. 익숙하지 않은 한글 용어가 연달아 들릴 때는 생소하기 이를 데 없긴 했지만, 친구의 자존심이 상할 정도로 나무래는 교수님 모습도 충격이었다. 지금 생각해보면 용어 하나까지 본류를 지키는 모습은 좋아 보이지만, 사대주의 냄새도 난다. 컨설턴트 경력 초기에 현장에서 서로 합의도 되지 않은 용처를 가진 유스 케이스를 필수 도구로 사용하면 많은 사람이 소모적인 논쟁으로 시간과 예산을 낭비했던 경험을 함께 했다. 대부분의 프로젝트에서는 차라리 없는 편이 좋을 수도 있다는 생각이 들었다. 아무리 좋은 개념이나 도구라도 현장의 사람이 적절하게 써서 최종 목적 달성에 이바지할 때 의미가 있다. 다시 말해서 그래야 실용성이 있다. 내용을 떠나 이 책은 실용성으로 무장한 한글화의 정수로 극찬하고 싶다. 물론 컴퓨터 관련 서적 범위안에서 말이다.

예전에 다이어그램 대신 도(圖)는 너무 생소하다는 의견에 대해 역자가 이런 견해를 제시했다. 둘 중 무엇으로 해도 의미가 통한다면 자주 나오는 표현이니 지면을 아끼고 읽는 시간을 줄이는 '도'가 우수하다. 깜짝 놀란 논지였다.

밀린 번역이 있는데 재개할 때는 스스로 정리하던 용어 대신 이 책의 용어에서 출발해야겠다. 나를 포함한 다수 개발자가 용어에 대한 사대주의와 지나치게 원래 의미를 고수하려는 강박관념을 갖고 있다. 국내 독자의 이해를 돕기 위해서라면 원어의 이미에 약간의 손상은 감수해야 한다. 그렇다고 우리 문화를 고려하여 새로운 표현을 고안할 능력이 없으므로 먼저 고민한 선배의 토대에 한술 얻는다는 생각으로 말이다.

한편, 안드로이드 책이 프로그래밍 서적을 독점(?)한 시장에 이런 고전을 내주신 출판사가 고맙다. 그러나, UML 교과서에 해당하는 책 제목으로 'UML 실전 활용 테크닉'으로 선정한 상술은 고전을 출간하는 배포와 비견해보면 매우 아이러니하다. 또, 시장이 작으니 기술 편집자(Technical Editor)가 없는 현실은 그렇다 쳐도 블릿이 있는 글은 굵게 표기한 편집은 책을 조잡하게 보이게 만들어 아쉬웠다.

가끔 일상에서 겸손을 배웁니다. 검손을 배우는 순간은 대개 자신의 오만함을 깨닫는 찰나죠. 그러나, 어리석게도 오만함을 깨닫는 찰나에도 대견함을 느끼기도 합니다. 이렇게 오만을 깨닫는 과정에서도 참으로 오만하기도 합니다. 잘못을 뉘우치고도 또 같은 잘못을 반복하는 삶과도 같죠. 그래도 어쩌겠습니까. 벗어나려고 노력이야 하지만 지금 그릇이 그러한데...

요즘 충동을 느끼는 일이 있습니다. 대동여지도를 그리던 당시의 어려움을 상상하며... 사석에서 몇 번 꺼냈던 이야긴데... 그 분처럼 평생을 지도에 바칠 각오는 없지만 비슷한 일을 도전해보고 싶은 욕심이 있습니다. 의지박약한 자신을 독려하기 위해 애꿎은 동료, 후배, 지인의 귀를 괴롭히며 삽니다.

원문 Thoughts on Flash을 번역한 글이 애플 포럼에 있다. 스티브 잡스는 플래시는 배제한 결정이 사업적인 이유가 아닌 기술적 이유라고 말하고 있다.


결론을 먼저 보면


PC와 마우스 시대에 태어난 것이 왜 문제란 말이냐는 의문이 들면


다섯 번째 이유를 듣고 고개를 끄덕이지 않을 수 없었다. 하지만, 스티브 잡스가 제시한 여섯 가지 이유 중에 가장 중요한 이유로 강조한 것은 크로스 플랫폼을 지향하는 플래시가 애플 플랫폼이 제공하는 변화를 빠르게 개발자에게 전달하지 못할 수 있다는 판단이다.


* 포럼 내용은 토비님 버즈를 통해 알 수 있었습니다.

만지가 22년에 걸처 바위산에 길을 낸 이유는 바위산이 놓여 있어 88킬로미터를 돌아가야만 읍내 병원을 갈 수 있는 곳에 산 탓에 다친 아내가 숨이 끊어지는 걸 그냥 보고 있을 수밖에 없었기 때문이다.

내일부턴 나도 해봐야겠다.

누군가의 말에서 듣던 가르침을 책에서 다시 본다.

나를 바꾸자!

고전이지만 현실을 투사할 수 있는 이야기가 많아 유쾌하게 읽었다. 캉디드가 여행 중간에 만난 엘도라도에 대한 설명 중에서 일부를 발췌했다. 굵게 표시한 부분이 많은 것을 생각하게 해준다.

* 본 글은 월간마소 네이버 뉴스케스트에 기고한 글입니다.

‘스티브 잡스처럼 되려면 개발자 아닌 아키텍트의 길을 가라’라는 기사가 있다. 이 기사뿐 아니라 인터넷에 올라온 의견을 보면 개발자와 아키텍트를 대결 구도로 쓴 내용이 많다. 이분법으로 개발자와 아키텍트를 나누는 일에 대해 유익한 점과 그렇지 않은 점에 대해 이야기를 꺼내 보려고 한다. 우선 양분해서 이로운 점은 무엇일까? 개발자와 아키텍트가 다루는 문제 사이에는 분명 다른 면이 있다. 넓은 의미에서 개발자가 아키텍트를 포함한다고 생각하지만, 일반적으로 개발자라고 하면 코드수준에서 고민해야 한다. 당면 과제가 돌아가는 코드와 눈에 보이는 화면이기 때문에 개발자는 미세한 문제까지 고민한다. if 문의 미묘한 차이에 따라 프로그램은 완전히 다르게 동작하고 UI 컴포넌트가 어떤 화면의 어느 위치에 존재하느냐에 따라 사용자는 전혀 다른 프로그램을 만나기 때문이다. 그래서 개발하려는 프로그램이 커지면 모두가 ‘세세한 내용까지 관심을 두는’ 개발자여서는 곤란하다. 누군가는 세세한 의견을 조율하고, 성격이 다른 코드 조각을 엮어내는 조정자가 필요하다. 그 사람은 개발자 사이에서 조정할 수도 있고, 개발자와 사용자 사이에서 중재하기도 한다. 또, 같은 사용자라고 해도 모든 사용자마다 다른 화면을 제공할 수 없어서 사용자 역할에 따라 적절한 무리를 만들고, 요구사항을 수렴하여 평균적인 화면과 기능으로 합의를 이끌어야 한다. 이처럼 일반적인 개발자와는 구분되는 시각과 역할을 가진 이가 필요하고, 아키텍트란 이름이 흔히 쓰인다.

 

그렇다면 이들의 구분이 유익하지 않은 경우는 무엇일까? ‘구분 짓는 행위’는 일종의 생각하는 기법이다. 앞서의 구분이 서로 다른 역할의 필요성을 드러내기 위함이었는데, 간혹 개발자와 아키텍트를 나누는 글의 바탕에 ‘직업의 귀천’을 깔아두는 내용을 발견한다. 인용한 글에서도 아키텍트의 중요성을 부각하기 위해 ‘단순 용역을 담당하는 개발자’라는 표현을 사용했다. 나는 아키텍트 양성이 중요하다는 말에 왠지 거부감을 느낀다. 그렇다면 개발자 양성은 중요하지 않은가? 설마 우리 곁에 훌륭한 개발자가 많아서 아키텍트가 필요하다 생각하는가? 내 경험으로는 과거 아키텍트 양성(?) 효과인지 훌륭한 개발자는 부족한데 반해 피상적인 지식을 갖춘 아키텍트는 부족하지 않았다. BA나 AA라고 하지만 일반적인 업무처리만 생각하고 수년 혹은 수십 년간 이어온 고객사의 특수성에 대한 분석은 내 일이 아니라는 사람, DA라고 하지만 실상은 단일 DBMS를 위한 DB 모델링 외엔 이야기를 나누기 어려운 사람, TA라고 하지만 타겟 프로그램이 웹 환경인데 웹에 대해서는 잘 모르는 사람을 만날 수 있다. 

 

교육 사업을 하는 사람이 ‘아키텍트를 키워야 한다’고 주장하는 경우를 흔히 본다. 분명히 아키텍트를 키우는 일은 의미 있는 일이고, 반드시 교육이 필요하다. 그러나 과연 아키텍트 교육이 개발자 교육과 구분해서 다룰 문제인가? 그리고 우리 사회에서 개발자 교육은 충분히 존재하는가? 대학 교육은 실무와 엄청난 거리감이 있다. 그나마 존재하는 학원이나 교육기관이 초보적인 기술 교육을 제공하지만, 다음 단계를 나아가려고 하면 교육 프로그램을 찾기 어렵다. 아키텍트 교육은 성격상 MBA 과정처럼 사례 연구 형태가 적합하다고 생각한다. 현장에서 쓰이는 상세 기술과 설계 기법에 대한 일반화도 되어 있지 않은 상태에서 서로 다른 경험치를 가진 참가자 사이에서 충분한 소통이 가능할까? 설사 그렇게 아키텍트를 양성했다고 해도 그들이 그려내는 그림을 실현할 준비된 개발자는 충분한가?

* 본 글은 월간마소 네이버 뉴스케스트에 기고한 글입니다.

요즘 홍세화님의 책을 읽으며 사회나 연대(連帶)에 대해 배웠다. ‘개발자니까 이런 부분이 약해.’라는 식으로 합리화를 해보지만 꽤 늦었다는 생각을 지울 수 없다. 그렇지만, 한편으론 인식하지 못했을 뿐 스스로 개발자 커뮤니티 활동을 하며 연대를 시도해왔고 현재도 그렇게 하고 있다. 다만, 뚜렷한 지향점이 없으니 노력에 비해 효과가 적었다.

 

개발자 커뮤니티 다시 생각하기

보통 개발자 커뮤니티 하면 JCO나 데브피아 등을 떠올리는 사람이 많다. 나 역시 그 중 한 사람이었다. 하지만, 커뮤니티(community)라 함은 공동체를 의미할 뿐이다. 형태가 분명하지 않아도 빈번하게 만나는 무리가 있다면 커뮤니티라 할 수 있고, 트위터 팔로우나 블로그 구독을 통해 만들어지는 소셜 네트워크의 일부도 커뮤니티라 할 수 있다. ‘자바 개발자 전체 자바 개발자 커뮤니티로 볼 수도 있지 않을까?’ 하는 생각을 떠올려봤지만, 공동체로 공유하는 부분이 명확하지 않았다. 그렇다면, 커뮤니티의 경계를 구분하는 기준은 무엇일까? 예전에 KSUG(한국스프링사용자모임)를 운영할 때 협찬을 하는 과정에서 회원 수를 물으면 포럼 가입자 수로 대답했다. 가입자 수가 큰 의미가 있을까? 그리고 보니 이일민씨가 오래 전 KSUG 블로그에 올렸던 ‘KSUG는 커뮤니티인가’란 글이 떠오른다.

 

진정한 커뮤니티는 구성원 상호간의 (좀 비율에 있어서 균형적이지 않더라도) 상호 흐름이 있어야 한다. 한쪽에서 정보를 제공하면, 다른 쪽에서 피드백이 오고, 또는 자신이 알고 있는 또 다른 정보를 꺼내놓아야 한다. 제공자이면서 수혜자여야만 커뮤니티로서 생명력이 있는 것이다.

인용 1. ‘KSUG는 커뮤니티인가’ 중에서

 

공동의 가치

공감할만한 글이다. 그러나, 인용한 내용만 보아선 무엇에 대한 제공자와 수혜자인지를 알 수 없다. 이 부분에서 다시 연대를 떠올릴 수 있다. 자주 쓰는 말이 아니라 사전을 찾아보니 ‘특정한 가치의 실현을 위해 행동을 같이 하거나 뜻을 함께하는 행위’라고 한다. 함께 모여서 실현하려는 가치를 중심으로 모여서 기여하고 공유하는 집단이 있다면 커뮤니티라고 할 수 있다. 과연 우리가 개발자 커뮤니티라고 부르는 집단이 명확한 가치를 지향하고 있을까? 또, 충분히 가치를 실현하고 있을까? 양수열씨가 JCO 회장시절을 회상하며 무보수 야근이 일상인 개발자 처우 개선을 위해 당시 정부인사와 만나 논의했던 이야기를 해주었을 때 깜짝 놀랐다. 이런 일을 하는 사람이 있구나 하는 생각에 놀랐고, 왜 우리는 스스로의 환경을 개선하기 위해 노력하지 않을까 반성이 있었다.

 

실효성을 고려한 실천

기관 주도하에 연차로 개발자 가치를 산정하는 일을 지켜보면서 다시 커뮤니티를 떠올렸다. 온라인 커뮤니티를 말하는 것이 아니다. 적절한 기준이 아니라고 불평할 시간과 노력으로 개선을 시도하는데 쏟을 수 있다. 해보지도 않고 ‘그게 가능하냐?’라고 회의적으로 말하는 이도 많다. 솔직히 회의적인 생각이 든다. 그렇지만, 요리조리 궁리를 해본다. 실효성이 있는 실천 방안과 함께 할 무리 즉, 커뮤니티를 찾아 행동을 같이 할 수 있는 방법을 찾기 위해서…

'소프트웨어 개발자의 삶'이라는 소프트(?)한 주제를 준비했다. 애초에는 커뮤니티나 개발자간 연대를 다루고 싶었는데 호주를 다녀오면서 생각이 바뀌었다. 그래서, '개발자로서의 일과 한 인간으로서의 삶'을 부제로 달고 동시대를 함께 사는 동지로서 호주에서 느낀 짧은 깨달음(주로 균형잡힌 삶에 대한 이야기)을 공유하고, 그 외의 시간은 부제와 거리가 있는 내용으로 채웠다. 

• TDD를 하면서 배운 교훈을 삶의 다른 영역에서도 써먹기
• 서로 다른 체계의 만남은 인정에서 비롯됨을 소프트웨어 개발 과정에서 배우기
• 지난 JCO 컨러펀스에서 발표했던 내용 중에서 애자일(Agile) 관련 사항 일부 발췌

주말을 여친이나 가족과 보내겠다고 마음 먹고 실천 중인데, 세미나 시간을 양해해준데 대한 고마움과 혼자 갔던 호주 여행에 대한 미안함에 대해 먼저 여친에게 고마움을 표했다. 여친이 KSUG 세미나엔 처음 참석했다. '재밌었다'는 반응에 도취되어 엘리베이터를 내려갔는데 여친의 혹독한 비판이 쏟아졌다.

일단, 두서가 없다. 자칫 호주 다녀온 자랑으로 들릴 수 있다. 쓸데 없는 움직임이 너무 많다. 불필요하게 장표를 왔다 갔다 한다. 

쩝... 듣기 좋은 이야기는 아니지만, 인정하지 않을 수가 없었다. 단순히 생각해보아도 내가 사용한 시간은 '발표시간 * 참석자 수'이기 때문이다. 여친이 '개발자로서 더 나은 삶을 영위하려면 이런 이런 것을 고려해보아야 하지 않냐?'는 취지 아니냐고 물을 때는 민망함을 느꼈다. 그 정도 줄거리조차 분명하게 잡지 않고 발표한다고 나섰다니.

다음 발표를 준비할 때는 반드시 다음 사항을 준수하자. 아니면 발표를 하지말자.
1. 장표 전체를 머리 속에 담을 수 있도록 일관성 있게 만들자. 그러기 위해 반복 작업한다.
2. 몸 전체를 고정하고 필요한 움직임만 하도록 최소 1회는 연습을 한다.

어제 골드코스트 해변에서 가장 많이 뛴 한국인은 단연 나였을 것이다. 한 시간쯤 해변 모래사장을 뛰려고 나갔다가 내친김에 골드코스트 해변 북쪽 끝까지 갔다. 낮에 토비형 가족과 차를 타고 들른 곳인데, '여기가 해변 북쪽 끝이야'란 말을 들었을 뿐인데. 하여간 밤이라 목표지점이 보이지 않았고, 그저 해변이 끝날 때까지 달렸다. 홀리데이 아파트가 있는 서퍼스 패러다이스와 메인 비치를 지나니 어둠뿐이었다. 7 ~ 8 키로 거리라고 들었는데 쉬지 않고 달렸다. 멈추면 끝까지 가지 못할 듯해서 쉬지 않았다. 한 시간 가까이 달렸을텐데 하늘과 별과 바다뿐이니 여러 가지를 느끼고 생각하기 좋았다.


먼저 '인생이 매우 짧다'는 생각이 스쳤다. 애초에 관광지에 오려던 계획은 아니었는데 관광지에 왔더니 머리 속이 뒤죽박죽이었다. 비단 여기서뿐 아니라 사는 모습도 마찬가지로 그렇다. 과연 내 뜻대로 생각하고 행동하는 경우가 얼마나 될까? 'OOO면 이래야 한다.'류의 통념에 맞춰 살고, 다른 사람 시선에 갇혀서 혹은 단순히 남들처럼 사는 시간과 게으름 때문에 낭비한 시간을 제외하면 내 삶은 얼마나 남을까? 하고 싶은 일이 생기면 주저 하지 말고 도전해야겠다는 생각이 들었다. 그렇지 않으면 시간은 쉽게 흘러간다.^[각주:1] 뛰면서 이런 생각을 했다는 일이 놀라웠다. ^[각주:2] 희망적인 생각을 하며 달리니까 어제와 달리 하나도 힘들지 않았다. 페이스만 유지하면 끊없이 달릴 수도 있겠다는 호기까지 생겼다.

호기가 생기자마자 바로 얼마 지나지 않았는데 힘이 들었다. 역시 혹독한 경험은 겸손을 가르쳐준다. 힘들고 발바닥도 아팠다. 저 멀리 보이는 등대 불빛은 계속 그 자리에 있는 듯했다. 다행히 포기하지 않았다. 대신 등대 불빛을 보며 조바심 내는 마음을 접었다. 마음이 한결 편해졌다. 그 순간이 내개 말해주었다. '성공보다는 포기하지 않는 의지가 중요하다.' 야구선수가 새로운 시즌을 앞두고 동계훈련 온 느낌이 들었다. 다시 희망에 휩싸여 달렸다.

주변에 불빛도 없어 깜깜한 해안을 지날 때 다시 사점이 왔다. 다행히 견뎌냈다. 아무 생각도 하지 않고 계속 달렸다. 얼마나 남았는지 조바심 부리지 않으려고 노력했다. 꽤 많이 왔다는 생각이 들어도 절대 뒤는 돌아보지 않았다. 안주하는 마음이 얼마나 나약하게 만드는지 잘 알기 때문이다. 그로부터도 한참을 달린 후에 드디어 KIOSK란 글자가 희미하게 보이고, 해변은 끝이 났다.

돌아오는 길은 훨씬 길고 지루했다. 갈 때는 계속 뛰었지만, 돌아가는 길은 반 이상 걸어갔다. 숙소에 돌아오니 두 시간을 뛰었다. 10km 뛰고, 5km 정도 걸었나보다. 계속 뛸 때는 몰랐는데 모래사장에 맨발로 뛰었더니 엄지 발가락은 이미 물집이 잡혔다가 터졌고, 다리는 온통 알이 베겼다. 내일은 과연 걸을 수나 있을까 싶었다.


자고 일어나니 다행히 걸을 수 있어서 어제 달렸던 해변 끝 부근에 있는 SEA WORLD라는 테마 파크에 갔다. (오늘은 해변을 뛰는 대신 버스를 이용했다.) 볼거리가 많았지만 무엇보다 돌고래쇼를 두 번이나 봤다. 돌고래쇼는 애들이나 본다고 생각했는데, 솟아오르는 돌고래의 움직임은 프리미어리그 탑 클래스 선수의 움직임을 볼 때처럼 짜릿한 쾌감을 줬다. SEA WORLD는 테마파크지만, 해양 생태계 보호를 위한 메시지를 곳곳에서 던졌다. 그래도 여친과 가족은 한국에 두고 혼자 관광을 하는 일은 즐겁지만은 않다. 숙소로 돌아와 저녁 먹기 전에 러닝 머신에서 2km를 다시 뛰었더니 다리 전체에 다시 알이 베겼다. 저녁을 먹고 산책하려고 바다에 나갔더니 모래를 밟는 순간 또 뛰고 싶은 충동을 느꼈다. 페이스를 유지해서 서울에서도 달리기는 꾸준히 해야겠다.

여친과 가족들을 서울에서 일상을 보내는데 혼자 부드러운 모래가 끝없이 이어지는 해변을 거니는 것이 마음에 걸렸다. '이제야 좀 철이드나' 라는 말을 수없이 해도 끊임없이 철이 들고, 또 갈 길이 멀다. ㅡㅡ;

열흘이나 남아 있어서 서두르지 않아도 되는 일정이 마음에 든다. 낮에 마트에 가서 장을 봤다. 마트는 우리나라와 너무 비슷해서 세계화란 말을 실감한다. 마트 구조는 비슷하지만, 물건 가격은 품목에 따라 많이 다르다. 호주가 과일이나 고기가 싸고 서울이 워낙 물가가 비싸서인지 관광지임에도 물가가 비슷하거나 조금 싸게 느껴진다.


낮에 해변을 거닐고 지리도 익힐 겸 주변을 둘러 봤다. 돌아오는 길에 Bottle shop에서 맥주를 샀다. 저녁을 먹기 전에 백만년만에 해보는 운동을 시도했다. 홀리데이 아파트 내에 있는 짐(gym)에 가서 20분 정도 러닝 머신 위를 뛰었다. 거리는 2.4km 였고 평균시속은 7.5km/h 였다. 신발을 벗고 해질녘 해변 모래사장에서 대충 2.5 km 정도 뛰어서 5km를 채웠다. 낼 다리가 멀쩡히 버티려나 이번 휴가에 서핑 레슨을 시도하려면 저질체력을 극복해야 할 듯하다. 그보다는 3년 정도 습관으로 자리잡은 "안움직이는 습관"을 더운 날씨를 빌어서 털어 버리려고 시도했다. 낼 오전에 멀쩡히 결심대로 일어나서 조깅을 할 수 있을까?

저녁 식사는 Toby 형이 추천한 스캇치 필레 스테이크를 사서 요리를 했다. 자취 경험도 없는 탓에 혼자 타지에서 요리하는 일은 처음이 아닌가 싶다. 아침에 먹고 남긴 샐러드를 고온에서 살짝 익혀 구운 야채를 만들었다.


끊김이 심해서 인터넷을 계속 사용하기가 너무 힘들다. 내일부터는 휴가 목적인 악습 타파, 충전과 올해 남은 시간에 대한 계획을 위해 투자해야겠다. :)

시드니는 다음 날도 우중충했다. 날씨가 좋으면 다시 Skywalk을 시도하려 했지만, 8시쯤 날씨를 확인하고 다시 잠이 들었다. 젠장, 프론트에서 걸려온 전화 받고 일어 났다. 지금 체크아웃을 안하면 30달러를 더 내야 한다고 해서 후다닥 씻고 준비했다. 30달러 경고(?) 덕분에 알맞은 시간에 공항에 도착했다. 수속을 마치고 조금 남는 시간에 점심을 Hungry Jack's로 해치웠다. 로고만 보면 알 수 있듯이 버거킹 호주 프랜차이즈다. 시드니에서 브리즈번까지는 비행기로 한 시간 거리다. (Toby 형 말로 차로는 12시간) 다시 브리즈번에서 에어트레인을 타고 한 시간쯤 가니 빙리(Beenleigh)에 도착했다. 오랜만에 보지만 마치 얼마 전에도 본 듯한 Toby 형은 외모도 그대로다. Toby 형 차를 타고 역주행(?)을 하며 고속도로를 지나 골드코스트의 서퍼들의 천국에 도착했다.


서퍼스 인터내셔널이라는 홀리데이 아파트는 마음에 들었다. 비수기 탓도 있겠지만 제주도 리조트보다 숙박비가 훨씬 싸다. TV, 냉장고, 오븐, 토스터, 전자렌지, 식기세척기, 세탁기, 건조기 등이 모두 구비 되어 있고, 널찍한 거실에 침실도 따로 있다. 호주는 여름이 지났지만, 시드니는 서늘한 반면 골드코스트는 해수욕하기 딱 좋은 기온이다. Toby 형과 저녁을 먹고 해변에서 간단히 담소를 나눈 후에 숙소 세팅(?)으로 밤을 보냈다. 인터넷 연결 계정을 구입하려고 결재하던 도중에 끊겨서 오류를 만난 채로 하루를 보내서 마치 밀린 일기 쓰듯 지금 글을 올린다.


식탁에서 밥 먹을 일이 없을 듯 해서 바다를 보며 랩탑을 사용하려고 세팅을 했는데... 결국 하루가 지나 쓸 수 있었다.

 * 일기와 두서 없는 여행지 메모이기 때문에 진지하게 읽지 않으실 것을 권장합니다. :)

열흘 이상 여행은 2006년에 컨퍼런스 참석겸해서 스페인에 다녀온 이후 처음이다. 비행기를 타면 어김없이 잉글리시 컴플렉스가 찾아온다. 아쉬운 점은 첫 여행지인 스페인에서 스페인어나 영어를 쓰지 않아도 열흘 거주에는 큰 지장이 없다는 것을 배웠다는 점이다. 물론, 컨퍼런스 중간 리셉션 시간에는 하고 싶은 말을 10%도 못해서 답답했지만 말이다. 숫자와 영어를 읽을 수만 있으면 관광에는 별 지장이 없다.

대한항공을 탔지만, 기내식이 맛있는 대신 표값이 비싸단 점을 빼면 승객 구성이 외국 항공과 큰 차이가 없었다. Toby 형 말에 따르면 중국에서 한국을 경유하면 표 값이 싸져서 많은 중국인이 이용한단다. 내 옆에는 아랍 남자가 앉았다. 종종 등뒤로 손을 넣어서 때를 미는 듯한 행위를 해서 못본 척 하려고 노력했다. :)

보통 외국인과 대화를 하면 강조하여 발음하는 중요한 단어 이외에는 잘 안들리는데, 아랍인이 하는 말은 전혀 안들렸다. 비빔밥을 비벼 먹는 모습이 무척 인상적이어서 입국신고서 작성할 때 펜을 빌려줬더니 무척 좋아한다.

서점에서 가장 최신 내용(2007년)에 기반한 여행 가이드를 샀지만, 예약한 호텔인 Travelodge Hotel Sydney가 없었다. 비슷한 이름의 다른 호텔만 있었고, 더구나 호텔이 위치한 Wentworth Ave.가 안 나왔다. 다행히 택시 기사가 위치를 알았다. 호텔은 위치나 시설이 마음에 들었지만, 인터넷을 사용할 수 없었다. 로비에 있는 키오스크에서 동전을 넣고 쓴다. 20분에 2AS(호주 달라). 우리 돈으로 10분 천원꼴이다. 지금 있는 골코(골드 코스트)에도 인터넷 카페 고속 인터넷 가격은 시드니와 같다. 블로그를 쓰는 무선 인터넷 연결은 우여곡절 끝에 일주일짜리 4만원 정도에 결재했는데, 5분이 멀다하고 끊긴다. '인터넷 (연결) 강국' 코리아가 그립다. :)



사이클론을 피해 바꾼 일정인데 무심하게도 시드니엔 비가 왔다. 비 탓에 가장 기대했던 Sky Walk(80층 높이 시드니 타위 위를 한 시간 반 동안 걷는 투어)는 무산됐다. 밤새 비행기를 탄 여독을 풀기 위해 호텔에서 잠깐 눈을 붙인 후에 비가 잦아 들 때 관광을 나섰다. 부슬비를 맞으며 차이나 타운에 가서 중국 요리로 이른 저녁을 먹었다. 차이나 타운 입구에 있는 샵에서는 브아걸과 티아라의 뮤비를 연신 틀어줘 여기서도 한류를 느낄 수 있었다. 지하철을 타고 서큘러 키(Circular Quy)로 갔다. 지하철 표 판매기는 매우 직관적이라 처음 사용했지만 큰 어려움은 없었다. 동전만 되는 기계와 지폐가 되는 기계가 함께 있다. 우선 목적지(City)를 누르고, 티켓 타입을 고르고 돈을 넣는다. 티켓 타입이 먼지 몰라, 옆 사람에게 물었더니 친절하게 가르쳐줬다. 듣고 보니 성인이냐 학생이냐, 편도냐 왕복이냐 선택하는 버튼이 있었다.

외국에 올 때마다 느끼지만, 인터페이스를 설계할 때 직관적인 설계는 우리보다 나은 듯하다. 표지판이나 자동 판매기 등에서도 확연히 느끼지만, 무엇보다 마트에서 냉장고를 비교해보면 알 수 있다. 우리나라는 데코레이션이나 스타일링이 월등히 강한데, 지나친 데코레이션은 가격을 높이거나 불편함(복잡한 버튼 조작, 낭비하는 공간)을 더러 초래하기도 한다.


서큘러 키에서 맨리 가는 페리를 탔다. 30분 배를 타는데 그 유명한 오페라 하우스와 호화 별장을 볼 수 있었다. 절벽 부근 호화 별장 중에서 톰 크루즈 별장이 있다고 한다. Toby 형 말을 쫓아 맨리를 둘러보려던 차에 폭우가 쏟아져 다시 회항했다. 회항하는 길에 야경으로 만나는 오페라 하우스와 하버 브리지는 절경이다. 여친과 함께 오지 않은 점이 무척 아쉬운 순간이었다.

너무 어두워져서 숙소로 향하는 지하철을 탔다. 뮤지엄 역에서 내려 지도를 보고 호텔을 찾아 갔다. 맥주를 사려고 편의점에 갔는데 맥주를 팔지 않는다. 알고보니 초저녁에 문닫는 보틀 샵에서만 술을 판다. 아쉬운대로 진저 비어를 샀다. 편의점에서 맥주 산 후에 방향을 완전히 잘못 들어서 거꾸로 갔다. 결국 부슬비 내리는 시드니 밤길을 한 시간 넘게 해맸다. 숙소에 빨리 갈 이유도 없었기에 나쁘지 않았다. 덕분에 생각지도 않았던 거대한 중앙역사도 보게 되었고, 언뜻 보아도 10대들로 보이는 애들이 넘쳐 나는 번화가도 지나갔다.

혼자 하는 여행은 외부가 아닌 나를 돌아볼 기회를 줘서 좋다. 여유를 느끼기도 하지만, 위축되는 모습이나 외로움, 방황하는 자신도 쉽게 눈치챌 수 있다. 남은 날동안 그간 미뤘던 일(운동, 번역, 기획)을 할 수 있도록 충전하고 변화하는 기회를 만들어볼 생각이다. 시드니에서 맞는 처음이자 마지막 밤은 호텔에서 TV를 보다 잠이 들었다. 호주에서는 하루 종일 크리켓과 럭비 중계를 볼 수 있다.

* 인터넷이 느려서 파일 업로드는 자제해야겠다.