2009 매시업 경진대회 본선 심사에 다녀왔다. 대회의 규모가 매년 더 커지고 있다. 규모에 맞게 참가자들의 작품도 더 많아지고 작품들의 수준도 높아졌음을 느낄 수 있었다. 흥미진진한 작품들과 그에 못지않은 프리젠테이션을 보느라 시간가는 줄 몰랐다.

본선 참가자들의 작품들 모두 훌륭했다. 그 중에서 가장 인상깊은 것은 Ulzard 이다. Ulzard는 웹상에서 동작하는 웹 애플리케이션 만들기 위한 툴이다. Javascript로 구현했음에도 마치 데스크탑 애플리케이션을 보는 듯 하다. 대단하다는 말밖에는 안나온다. 오픈 소스로 공개된다니 소스를 보는 것도 좋을 듯 싶다.

모두 뛰어난 UI 감각을 가지고 있다는 것이 놀라웠다. 대상을 받은 지구를 여행하는 히치하이커를 위한 안내서는 심사의원이 말했듯이 '당장 서비스해도 손색이 없을만큼' 뛰어난 UI를 가지고 있다. 부럽다. UI 만드는 것을 특히나 어려워하는 나는 너무너무 부러웠다. 화장실 찾기 서비스인 WC119도 좋았다.

UI 에 대해 한가지 배운 것은 "단순하게 만들어야 한다."는 것이다. 개발자는 보통 자신이 좋다고 생각하는 기능들을 늘어놓고 누군가가 가장 중요한 것을 뽑아내 주기를 기대하지만, 누구도 그런 일을 해주지 않는다. 내가 단순하다고 생각하는 것보다 훨씬 더 단순하게 만들어야 한다. 아무 생각없이 이용할 수 있도록.

혼자 이런 곳에 가면 상당히 뻘쭘하고 어색하다. 지루하기라도 하면 집에 가고 싶은 생각이 간절하다. 그래서 혼자는 잘 안다니려고 하는데, 생각해보면 그다지 나쁘지 않은 일이다. 이곳에서는 나와 비슷한 부류의 사람들을 잔뜩 볼 수 있고, 무료 쿠키도 먹을 수 있고, 때때로 재미난 이야기도 듣는다. 운이 좋으면 오늘처럼 엄청난 자극을 받기도 하고, 새로운 영감을 얻기도 한다. 가끔 문제도 생기는데, 하루에 대단해 보이는 사람들을 너무 많이 보게 되면 내가 초라하게 느껴져 우울해진다. 그것만 없으면 참 좋으련만.

갯수가 많은 상품의 목록을 보여줄 때 쓰는 유용한 방법 중 하나가 페이지네이션이다. 한페이지에 적당한 갯수를 보여주고, 페이지 하단에 다른 페이지로 가는 링크를 걸어서 전체 목록을 조회할 수 있도록 한다. ruby on rails를 사용한다면 will_pagination을 이용해서 간단하게 페이지네이션을 구현할 수 있다.

어떤 페이지에 보여줄 목록을 가져오기 위해서는 페이지 번호와 한페이지에 보여줄 갯수만 있으면 된다. 예를 들어 boxes라는 테이블 목록을 한 페이지에 25개씩 보여준다고 하자. 만약 세번째 페이지를 생성시간 순서로 보여주고 싶다면 SQL 쿼리는 다음과 같다.

1. SELECT * FROM boxes ORDER BY created_at LIMIT 75, 25;

인덱스

위 쿼리는 아주 잘 동작하지만 작은 문제가 있다. boxes 테이블 항목의 갯수가 많아지면 많아질 수록 쿼리의 수행 속도도 느려진다. 이점을 보완하기 위해 created_at에 인덱스를 걸어 둔다. 그러면 검색속도가 빨라진다.

목록의 갯수가 아주 많다면?

그래도 여전히 문제가 있다. 목록의 갯수가 아주 많아졌다고 생각해 보자. 갯수가 100만개쯤 되었다고 가정하자. 첫 페이지에 대해서는 빠른 응답을 보인다. 그러나 마지막 페이지를 요청하면 오랜 시간 동안 기다려야 한다. 왜 그럴까? 4만번째 페이지를 요청하는 쿼리는 다음과 같다.

1. SELECT * FROM boxes ORDER BY created_at LIMIT 1000000, 25;

이 요청은 생성된 시간이 백만번째 부터 25개의 box를 가져와라라는 쿼리다. 백만번째 생성된 box가 무엇인지만 알면 인덱스에 의해 잘 정렬된 테이블에서 그 후 25개만 가져오면 된다. 그런데 이 백만번째라는 것이 문제다. 백만번째가 무엇인지 단번에 알 수가 없다. 백만번째 생성된 box를 찾아내기 위해서는 백만번 동안 테이블을 조사 해야 한다. 인덱스가 걸려 있다 해도 마찬가지다. 첫번째, 두번째... 이렇게 순차적으로 조사해 나가는 수밖에 없다. 그래서 시간이 오래 걸린다.

4만번째 페이지라고?

한편으로 생각해보면, 이렇게 많은 내용을 페이지네이션으로 한다는 것은 별 의미가 없다. 32423번쨰 페이지를 어떻게 찾아갈 것이며, 그곳에 찾아가서 무엇을 기대할 수 있을까?  페이지가 1000개가 넘어가면 그저 '많은 페이지가 있구나' 라는 생각이 들 뿐이다. 이렇게 자료가 많다면 페이지네이션이 아닌 다른 조회 시스템을 마련하는 것이 더 낫다. 한가지 예는 성능좋은 검색시스템이 될 수 도 있고, 월별로 조회하는 페이지를 따로 둘 수도 있다. 좀 더 현실적인 문제는 40000번째까지 페이지 링크를 만들어 놓으면 봇들이 돌아다니면서 페이지들을 죄다 누르고 다닌다.

페이지의 수를 제한하자.

페이지네이션을 꼭 사용해야 한다면 최대 페이지의 수를 제한하는 것도 한가지 좋은 방법이다. 자료의 갯수가 아무리 많더라도 페이지네이션으로 보여줄 때는 100페이지만 보여주는 것이다. 만약 최대 페이지를 100으로 제한하고 싶다면 총 항목의 갯수를 가져오는 SQL 쿼리는 다음과 같다.

1. SELECT COUNT(*) as total FROM (SELECT id FROM boxes LIMIT 2500) s;

will_pagination을 사용한다면 총 페이지 갯수를 지정하기 위해 paginate의 옵션에 :total_entries 를 추가할 수 있다.

1. res= ActiveRecord::Base.connection.execute("SELECT COUNT(*) as total FROM (SELECT id FROM boxes LIMIT 2500) s;")
2. total = 0;
3. res.each_hash { |r| total = r["total"].to_i }
4. Box.pagination(:page=>3, :total_entries=>total)

루비로 작성한 프로그램에 대해 문서를 제출할 일이 생겼다. RDOC을 이용하면 간단하게 HTML, XML, chm 형식의 문서를 뽑아 낼 수 있다. 주석을 충분히 달아 놓기만 했다면...

RDOC을 이용해서 문서화할 수 있도록 주석을 다는 법에 대해 알아보자.

RDOC 주석을 위한 특별한 시작은 없다. 클래스나 메쏘드 위의 주석은 모두 rdoc에 의해 해석된다. 주석의 작성 형식은 전체적으로 간단하고 실용적이며, 위키의 포맷과 비슷하다. 어렵지 않다.

리스트 표현

숫자, *, - 로 시작되는 문장은 리스트로 표현된다.

1. # * List item 1
2. # * List item 2

[] 는 다음 처럼 단어 설명에 사용하면 좋다.

1. # [고앙이]   small domestic animal 

인덴트

스페이스 두개로 인덴트가 표현된다. 리스트 안에 리스트를 표현하고 싶으면 다음과 같이 할 수 있다.

1. #
2. # - list 1
3. #   - list 1.1
4. #     - list 1.1.1

강조

• <b> </b> 는 글씨를 진하게 한다.
• <tt> </tt> 는 글씨를 typewriter 체로 한다.
• <em> </em> 은 글씨를 이택릭체로 한다.
• = 로 시작하면 헤드라인을 보여준다.

1. # <em>text</em>
2. # <b>text</b>
3. # <tt>text</tt>
4. # = Level One Heading 
5. # == Level Two Heading
6. # === Level Three Heading
7. # ==== Level Four Heading

rdoc에 포함시키지 않기

주석중 rdoc에 포함시키기 원치 않은 부분이 있다면 #-- 를 이용할 수 있다. #-- 이하의 부분은 rdoc에 포함되지 않는다. 다시 포함시키고 싶다면 #++를 이용한다.

1. # This is RDOC document.
2. #--
3. # Not included in RDOC from here
4. #++
5. # Now included again

상수를 포함시키고 싶지 않다면 다음과 같이 #:nodoc: 를 이용한다.

1. OsInfo = { #:nodoc:
2.                 "Linux" => "Linux", #:nodoc:  
3.                  "Unknown" => "Unknown" #:nodoc:
4. } #:nodoc:

#:doc:  은 반대로 포함되지 않는 부분을 포함시킨다. 특정한 private method를 주석에 포함시키고 싶을 때 유용하다.

하이퍼링크

http, ftp, mailto, www 로 시작되는 문장은 알아서 하이퍼링크로 치환시켜 준다. 또한 이미지 URL의 경우는 알아서 <img> 태그로 변환시켜 준다.
클래스나 메쏘드 이름과 같은 단어는 알아서 하이퍼링크를 생성해 준다. 굿!

참조

http://rdoc.sourceforge.net/doc/index.html

내가 처음으로 프로그래밍을 재미를 느낀 때는 대학교를 다닐 때다. 그 때는 프로그래밍이 굉장히 멋진 일이라고 생각했었고, 빌 게이츠 처럼 뛰어난 개발자가 되어서 성공적인 회사를 이꿀어 가는 것을 꿈꾸었다. 혹은 이름만 대면 누구나 알 수 있는 해커가 되는 상상을 했다. 이제 프로그래밍을 배우기 시작한지 10년이 다 되어가지만 나의 성장은 기대 이하다. 왜 나는 최고 수준의 프로그래머가 되지 못하는가? 초기 학습 속도는 꽤 빠른 편임에도 불구하고, 어느 정도 수준에 오르면 더이상 성장하지 못한다. 왜 그럴까?  재능이 없는 것일까? 난 진로를 잘못 선택한 것일까?

1만 시간의 훈련

말콤 글래드웰은 아웃라이어라는 책을 통해 그것은 충분히 훈련되지 않았기 때문이라고 말한다. 그는 말한다. 타고난 재능은 크게 중요하지 않다. 더 중요한 것은 그 일에 대한 훈련의 양이다. 굉장한 성공을 하는 사람들을 보고 우리는 그들의 남과 다른 뛰어남을 찾으려 하지만, 알고보면 그들의 성공은 그들의 훈련량에서 비롯되었다. 그리고 그 훈련량은 불굴의 의지 같은 것에 의해 결정되기 보다는 주변의 환경에 의해 더 많은 영향을 받는다. 혼자 잘나서 성공하는 사람은 거의 없다.
훈련량에 영향을 미치는 주변의 환경으로 책에서는 다음과 같은 예를 든다.

• 1월에서 3월 사이에 태어난 캐나다의 하키선수들.
• 1970년대 컴퓨터를 접할 수 있는 환경을 가진 빌 조이, 빌 게이츠
• 함부르크에서 오랜 공연연습을 할 수 있었던 비틀즈
• 교육에 관심이 많은 가정 환경
• 유산으로 물려받은 문화
• 변화하는 비지니스 환경

그리고 약간의 행운

우선 글래드웰의 뛰어난 직관에 박수를 보낸다. 그는 성공을 지능 같은 타고난 재능이 아닌 훈련량과 연관을 지었고, 그 훈련량이 만들어지기까지는 몇차례의 행운이 필요하다고 말한다. 뛰어난 하키선수가 되기 위해서는 1월에 태어나는 것이 좋다. 부유한 가정환경에서 자라는 천재들은 그들의 재능을 펼쳐 성공할 수 있는 확률이 더 높다. 1930년대에 태어난  변호사가 꿈인 아이들은 태어난 시기만으로 행운을 얻었다. 그들은 저출산의 영향으로 적은 경쟁 속에서 변호사가 될 수 있었고, 변호사가 되면 충분한 일거리를 보장 받았다. 게다가 1960년대 비지니스 업계의 변화라는 큰 기회를 맞이할 수 있다. 변호사 조셉 플롬은 그 행운을 제대로 잡아서 엄청난 성공을 이루었다.

꾸준함이라는 재능

여기서 한가지 생각해 보자. 충분한 노력이 성공을 만든다는 것은 획기적인 생각은 아니다. 오히려 누구나 다 알고 있는 사실이다. 그렇다면 왜 대부분의 사람들은 성공하기를 원하면서도 꾸준히 노력하지 않는가? 글래드웰은 주변 환경이 도와주어야 한다고 말한다. 맞는 말이다. 비틀즈에게 함부르크에서의 초청이 그들의 음악을 한단계 향상시킬 수 있는 과정이 되었을 것이다. 하지만 그것이 전부인가? 다른 것이 있지는 않을까? 어쩌면 꾸준함을 갖고 있다는 것도 타고난 재능은 아닐까? 그 때 함부르크에 초청된 수 많은 다른 밴드들이 비틀즈 만큼 성장하지 못한 이유는 무었인가? 1970년대 게이츠만큼 뛰어난 프로그래밍 실력을 갖춘 다른 개발자들이 MS만한 기업을 만들어내지 못하는 이유는 무엇인가? 왜 어떤 피아니스트는 8000시간을 연습하고 훌륭하다는 평가를 받고 다른 피아니스트들이 1만시간 연습해서 최고가 되는가? 나는 왜 항상 잘한다는 수준까지는 오르는데, 최고의 수준까지 오르지 못하는 이유는 무엇인가? 어쩌면 꾸준함이라는 것이 인간이 가질 수 있는 최고의 재능은 아닐까?

성공으로 가는 기회를 공평하게 제공하자.

이 책은 성공하기 위해서는 이렇게 해라라는 자기개발서가 아니다. 그보다 성공을 위해 중요한 한가지 요소 - 훈련 - 를 지적하고 그것을 위해 사회가 해야할 일을 제시하고 있다. 글래드웰이 강조하는 것은 공평한 제도와 교육의 중요성이다. 그는 하반기에 태어난 아이들을 위한 하키리그를 하나 더 만들면 하반기에 태어난 아이들에게 뛰어난 하키선수가 될 수 있는 공평함을 제공할 것이라고 생각한다. (여기서 중요한 것은 리그를 하나 더 만드는데 드는 비용이겠지만.) 부유한 환경에서 태어난 아이들은 가정의 보살핌으로 성공으로 가기 위한 유리한 위치에 있게 된다. 하지만 이 격차도 학교제도를 잘 정비함으로써 어려운 환경의 아이들에게도 조금 더 공평한 기회를 제공할 수 있다.

나에게 적용하기

프로그래밍에 재능이 없음을 탓하지 말고, 좌절하지도 말고, 꾸준함을 갖도록 하자. 다행히 난 이 일이 싫지는 않다. 아직 늦지 않았다면 언젠가는 최고 수준에 오를 수도 있을 것이다. 그리고 약간의 운이 따라준다면 대단한 성공을 이룰 수 있을 지도 모른다. jake의 말처럼 언젠가 기회는 올 것이고, 그 기회를 알아채고 잡을 수 있을만큼 우리는 충분히 준비해야 한다.
재능은 스스로 성장하지 않는다. 조직을 발전시키기 위해 충분히 교육할 수 있는 환경을 만들어야 한다.

Output Console에서 한글이 나오도록 하기

윈도우에서 Rails 개발을 하다보면 아쉬운 점 하나가 콘솔에 뿌려지는 로그 메시지 중 한글이 깨진다는 것이다. 넷빈즈를 사용할 때는 Output 에 나오는 로그중 한글이 깨지는데, 다음과 같이하면 Output 창에 한글이 제대로 나오게 할 수 있다.

C:\Program Files\NetBeans 6.5\etc\netbeans.conf 를 보면 다음과 비슷한 구절이 있다.

1. netbeans_default_options="-J-client -J-Xverify:none -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true"

이 netbeans_default_options "-J-Dfile.encoding=UTF-8"를 추가해 다음과 같이 만든다.

1. netbeans_default_options="-J-client -J-Xverify:none -J-Xss2m -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-Dfile.encoding=UTF-8"

이제 한글이 Output에 제대로 나올 것이다. 하지만 얻는 것이 있으면 잃는 것도 있는데...

하나는 editor의 폰트가 약간 보기 않좋게 바뀐다. 나눔고딕 코딩 폰트를 사용하고 줄간격을 조절하면 보기 좋아진다 의견도 있다.

또 다른 하나는 subversion을 사용한다면 commit을 할 때 한글을 사용하면 에러가 발생한다.

NetBeans 구동 속도를 빠르게 하기

NetBeans의 처음 구동 속도에 대해 불만을 가지고 계신 분들이 있으시다면, netbeans_default_options 옵션 중 -J-Xms32m 가 스타트 메모리 사이즈에 대한 것이다. 이 사이즈를 128로 늘리면 구동속도가 개선된다.

1. netbeans_default_options="-J-client -J-Xverify:none -J-Xss2m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true"

Editor의 줄간격 조절하기

NetBeans 6.5 에서는 Editor의 줄간격을 조절할 수 있다. 다음과 같은 파일을 찾는다.

C:\Documents and Settings\USERNAME\.netbeans\6.5\config\Editors\Preference\org-netbeans-modules-editor-settings-CustomPreferences.xml

만약 위 파일이 없다면 넷빈즈의 Tools/options 의 Editor 를 수정하면 생긴다.

이 xml 파일에 다음을 추가한다.

1. <entry javaType="java.lang.Float" name="line-height-correction" xml:space="preserve">
2.   <value><![CDATA[1.3]]></value>
   </entry>

NetBeans를 다시 시작하면 달라진 줄간격을 볼 수 있을 것이다.

이 글은 스프링노트에서 작성되었습니다.

웹서비스 개발을 하다보면 HTTP 요청을 내맘대로 설정해서 보내고 싶을 때가 있다. GET 요청은 브라우져를 통해서 하면 간단히 보낼 수 있다. 그러나 POST 요청을 보낼 때는? HTTP Header의 정보를 조작해서 요청을 보내고 싶을 때는? 모두 간단하지 않다.

파이어폭스를 사용하고 있다면 Poster라는 부가기능을 이용해서 다양한 HTTP 요청을 만들 수 있다. 그리고 그 결과도 손쉽게 확인할 수 있다. 설치 및 사용방법도 아주 간단하다.

설치

파이어 폭스의 Poster 부가기능을 설치한다. 설치가 완료되면 파이어폭스의 하단에 Poster 아이콘이 보인다. 작아서 한눈에 찾아지지 않을 지도 모른다. 아마도 이것을 찾는 것이 이 부가기능을 사용하는데 있어서 가장 어려운 일일듯 싶다. 나머지는 그만큼 쉽다.

가운에 있는 P자 아이콘을 클릭하면 Poster의 창이 나타난다.

사용

사용법은 간단하다. 원하는 URL을 입력하고 Actions의 GET 옆의 Go를 누르면 Get 요청이 보내진다. 그리고 다음과 같은 결과를 얻는다.

주요기능

Request 창의 값들을 조절해 다양한 요청을 보낼 수 있다.

File 을 선택해서 파일 업로드 할 때의 요청을 만들 수 있다.
User Auth를 이용해 Basic Authentication 을 설정할 수도 있다.
Actions 탭에서는 HTTP method를 변경할 수 있다.
Header의 값을 변경할 수도 있고, 요청 파라미터를 설정해서 보낼 수도 있다.
그리고, 사용할 것만 같은 복잡한 설정이 있다면 설정을 저장할 수도 있다.

출처 : 스토리큐

jira 를 활용한 scrum

출처 : 스토리큐

Scrum 관련 자료입니다.

출처 : 스토리큐

마지막으로 블로그에 글을 쓴 것이 2008년 10월 9일. 거의 4개월 동안 다른 곳에 갔다 온 것 같은 기분이 든다. 이런 저런 일들이 있었는데, 지금 돌이켜 보면 아마도 내겐 감당하기 어려웠던 것 같다. 다행히 여러 사람들이 도움을 주었고, 감사하게 생각하고 있다. 그들 덕분에 극단적인 선택은 피할 수 있었다.

그 동안의 일탈을 통해 몇가지 사실을 알게 되었는데, 하나는 혼자 살아가는 것은 힘들다. 사람들과 교류해야 한다. 또 하나는 견고한 사생활을 갖어야 한다. 블로그를 통해 글을 남기는 것은 이 두가지 원칙을 지키는데 도움을 줄 것이다. 누군가에게 내 이야기를 할 수 있다면 내 삶을 조금 더 나아질 것이다.

  대부분의 첫강의가 그렇듯이 첫번째 글은 일반적인 이야기들로 시작된다. 이 글이 앞으로 쓰여질 긴 책의 서문이 되기를 간절히 바란다.

앞으로 어떤 글을 쓸 것인가?

지금까지 해 왔던 대로 프로그래밍 개발에 대한 글을 쓸 것이다. 지식을 기억하고, 공유하기 위해.

그리고 끊임없이 떠오르는 생각들에 대해 써 볼 생각이다. 다른 사람의 글을 읽음으로써 혹은 다른 사람과 이야기함으로써 잠시 머리속에 머물렀다 이내 사라지는 생각들. 그것들을 글로 남길 수 있다면 멋진 일이 될 것이다.

그리고 내 일상과 경제에 대한 글도 올라올 것이다.

왜 글을 쓰는가?

글을 쓸때마다 드는 생각은 나는 이 글을 왜 쓰는가? 이 글은 누구에게 보여지기 위해 쓰이는 것인가? 혼자만을 위한 것이라면 왜 공개하려 하는가?

글을 써야하는 이유에 대해 몇 가지 생각해 본다.

정보 공유

개발자로써 일을 하면서 얻게되는 지식을 글로 적어 놓는다. 그 글들은 주로 어떤 과정을 어떻게 진행했다는 기록들이다. 그 글들의 도움을 가장 많이 받는 사람은 아마도 나일 것이다.  이런 기록들은 부족한 기억력을 보충해 주어 다음에 같은 혹은 비슷한 과정을 진행하게 될 때 큰 도움이 된다. 또한 이런 글들은 비슷한 과정을 겪을 다른 사람들에게도 도움이 될 것이다. 내가 구글 검색을 통해 누군가가 남겨 놓은 글에 도움을 받듯이.

 관심이 필요하다.

프로게이머 김택용이 신인일 때 스타리그에 첫 진출을 하면서 이렇게 말했다. "관심받고 싶어요" 그리고 그는 프로게이머로서 멋지게 성공했다. 나도 관심을 받고 싶다. 혼자서 대단한 것을 이룰 수 있을만큼 난 뛰어나지 않다. 누군가의 격려와 칭찬으로 힘을 얻고 그 힘으로 한 단계 더 도약할 수 있다. 그리고 그 관심이 훗날 좋은 평판으로 이어졌으면 좋겠다.

깊은 생각

머리 속에 맴도는 것들을 글로 표현하기는 쉽지 않다. 어떤 생각들은 그렇게 잠시 맴돌다가 사라지기 때문에 마치 꿈처럼 금방 잊혀진다. 사라지지 않는다 해도 혼자하는 생각에는 한계가 있어서 더 나은 것으로의 발전이 더디다. 난 내 글들이 내가 다른 사람들과 교류할 수 있는 창구가 되기를 희망한다. 나와 같은 고민을 이미 거쳐간 사람, 현명한 사람들로부터 내 생각의 오류들을 바로잡을 수 있을 수 있기를.

글쓰기 능력 향상

애덤 스미스는 "나는 내 저서를 통해서만 아름다워질 수 있지" 라고 말했다. 글쓰기와 말하기 능력은 어느 분야에서 일을 하느냐에 상관없이 중요하다. 아무리 위대한 철학을 가지고 있다 한들 그것을 제대로 표현하지 못한다면 무슨 소용이 있겠는가? 뛰어난 내용을 담고 있는 책임에도 불구하고 난해한 문체로 졸음만을 주는 책을 쓰고 싶지는 않다.

글을 쓰지 못했던 이유는 무었인가?

익숙하지 않아서

난 단조로운 말투로 긴장해서 말하곤 한다. 내 처음 글은 마치 시험보기 위한 요점정리 목록같다. 키워드만 몇개 있을 뿐이다. 그 목록에 살을 붙여서 읽을 만한 글로 만드는 능력이 내겐 매우 부족하다. 적절한 예시를 하고 비유를 하는 것은 영 익숙치가 않다. 그러다 보니 글 쓰는 일이 힘들다. 힘들다보니 글쓰기를 꺼려하게 된다. 내 키워드 목록은 주머니 속에서 몇 주을 머물다가 슬며시 버려진다.

부끄러워서

내가 쓴 글이 재미없다는 생각과 소심한 성격은 절묘하게 조합되어 글이 공개되는 것을 극도로 부끄러워하게 한다. 내 부족한 생각을 공개하는 것 또한 마찬가지로 매우 창피한 일이다.

최근 완벽함을 추구하는 것에 대해 재미있는 설명을 알게 되었는데, 사람들이 완벽함에 집착하는 이유는 죽음에 대한 두려움 때문이라고 한다. 갈릴레오는 이렇게 말했다. "사람들이 완벽함 영원성 등을 높이 찬양한다면 내 생각에 그것은 계속 살고자하는 욕구 때문이고 죽음에 대한 두려움 때문이다."

부끄러움을 버리자. 어차피 죽는다.

꾸준함이 필요하다.

  하루 한시간씩 꾸준히 훈련한다면 누구나 마라톤을 완주할 수 있다고 한다. 쉬운 말이고 당연한 듯이 보이는 말이지만 마라톤을 완주하는 사람은 결코 많지 않다. 글쓰기를 꾸준히 할 수 있다면 내 삶을 좋은 쪽으로 개선시키는데 큰 도움이 될 것이 틀림없다. 그러나 그 꾸준함은 결코 쉽지 않다. 캘빈 쿨리지는 이렇게 말했다. "이 세상에서 그 어떤 것도 끈기를 대신할 수 없다. 끈기와 결의만이 무한한 힘을 가지고 있다." 지금 내게는 꾸준함이 필요하다.