Talk with Hani

이 Post는 Curt Hibbs의 Rolling with Ruby on Rails 번역본입니다. 의역과 축약한 부분이 있습니다.

Ruby란?

Ruby의 장점

Smalltalk의 우아함(개념 측면에서)

Pytohon처럼 쉽게 배우고, 쓸 수 있음

Perl의 실용성

Rails란?

Rails는 데이터베이스 지원하는 웹 프로그램 개발용 Open source다. Java 프레임웍을 사용하는 것보다 10배 정도 빠르게 개발할 수 있다고 생각한다. 그럼에도 불구하고, 동일한 품질 수준을 달성할 수 있다.

역자 주 : 이 10배라는 문장에 주목해야 합니다. Rails 글을 읽다 보면 항상 나오는 문구입니다만, 진짜 10배 정도 빨라진다고 합니다. 그러나 제 생각엔 Rails에 어느 정도 익숙해진 다음에 가능한 수치인거 같습니다. 느껴 보시길…

Ruby는 다른 언어와 비교해 보았을 때 보다 더 쉽게 프로그램을 개발할 수 있다. Rails는 이런 Ruby의 장점을 모두 포함한다. Rails는 두가지 정도의 장점이 있다.

Less Software : 훨씬 적은 코드로 applcation을 구축할 수 있다. 즉 더 적은 버그를 가지고 있는 더 작고(코드 크기) 더 빠르게 만들 수 있다. 따라서 코드도 작고 버그도 적기 때문에 유지보수도 매우 쉬워진다.

Convention over configuration : XML 설정 파일을 설정할 필요가 없다. 즉 Rails에서는 설정 파일 대신, 간단한 프로그래밍 규칙을 이용한다.

백문이불여일견(百問而不如一見)

새로운 기술이 선보일 때마다 과대 선전을 하기 때문에, 이 글을 읽는 개발자들은 거짓말이라고 생각할 수 있다. 그러나 진짜로 10배 빨리 개발할 수 있다. 맹신 하라는게 아니다. 일단 보고 나서 믿도록!

소프트웨어 설치

우선 필요한 프로그램을 설치하자. 윈도우즈 기준으로 예제를 설명할 것이기 때문에 리눅스나 맥은 설명하는 것과는 다른 화면이 출력될 수 있다. 다른 os관련 resource는 예제의 끝머리에 링크를 달아 둘 것이다.

Step 1 : Ruby 설치하기

그림 1. Ruby 윈도우 설치 프로그램

Ruby를 설치하는 것은 매우 간단하다.

1. 윈도우즈용 One-Click Ruby 설치 프로그램(그림 1)을 다운로드 한다.

역자 주 : 반드시 1.8.2-15 버전을 설치해야 한다. 1.8.2-15 아래 버전에서는 Rails가 제대로 설치 안된다. 반드시 1.8.2-15 버전을 설치하도록~

2. 다운로드 파일을 더블 클릭해서 실행시킵니다. 별다른 설정없이 계속 enter키를 입력하면 설치가 완료 된다.

Note : 윈도우즈 버전인 경우 RubyGems 패키지도 설치되나, 리눅스와 OS X 사용자는 RubyGems도 설치해야 한다.

Step 2 : Rails 설치하기

그림 2. RubyGems를 이용하여 Rails 설치함

1. 작업창(Command Window)를 실행한 후, prompt 상에 gem install rails - -remote를 입력한다.
2. RubyGems는 Rails와 관련된 library를 설치한다. RubyGems는 각 단계마 설치를 물어볼텐데, 이 때 항상 “y”(Yes)를 입력한다.

Step 3 : MySQL 설치하기

그림 3. MySQL 서버 설정 마법사

Rail은 여러 종류의 데이터베이스를 지원하나, 여기서는 MySQL을 사용하겠다.

1. MySQL 윈도우즈 설치 프로그램을 다운로드한다. 여기서는 “essential” 버전을 다운로드 한다.(이 글을 쓰는 시점의 최신 버전은 4.1.7이다. 역자 주:번역하는 시점에는 4.1.15가 최신 버전이다.)
2. 그림 3의 설치 프로그램을 더블 클릭한다. 기본 설정을 선택한다. mysql.com의 계정 생성은 생략한다.
3. 설치 마법사가 완료되면 ‘Finish’ 버튼을 클릭한다. 설정 마법사가 생성된다.
4. 보안 창에서 “Modify Security Settings” 항목을 체크하지 않는다.(그림 4) 나머지 탭에서는 기본 설정을 유지한다. “Modfiy Security Settings” 항목을 체크하지 않는 이유는, 4.1.7버전이 새로운 권한 알고리즘을 채용해서, 하위 클라이언트 버전과 호환되지 않기 때문이다. (Rails도 여기에 해당함) 항목을 체크하지 않으면 패스워드 없이 MySQL에 접근할 수 있다.

그림 4. MySQL 설정 마법사

Step 4 : MySQL-Front 설치하기

MySQL-Front는 MySQL GUI 툴이다. 비싸지는 않지만 상업용 프로그램이기 때문에 30일 동안만 무료로 사용할 수 있다. 30일 이후에는 돈을 내고 사용해야 한다. 이 문서에서는 데이터베이스 구축용 툴로써 MySQL-Front를 사용할 것이다.

역자 주 : SQLyog라는 툴은 공짜임. 여기서 다운로드 할 수 있습니다.

1. MySQL-Front 최신 버전을 다운로드한다.(현재 최신 버전은 3.1, 역자 주 : 번역 시 최신 버전은 3.2)
2. 다운로드한 설치 프로그램을 더블클릭하면, 그림 5 MySQL-Front 설치 프로그램이 실행된다. 별 다른 설정 사항이 없는 한 기본 설정으로 설치한다.

그림 5. MySQL-Front 설치 프로그램

Rolling with Ruby on Rails 2/5로 이동

오늘은 당구 이야기로 시작해 보겠습니다. 제가 처음으로 당구를 접한 것은 지금으로부터 11년 전인 94년이었습니다. 대학교 입학식이 끝나고 처음 만난 동기들과 할 이야기도 마땅치 않아, 서먹서먹한 순간에 동기 중 한명이

“당구나 한 게임하러 가지 않을래?”

라는 제안을 하더군요. 그런 서먹함이 싫었던지 10명 정도가 모여 있던 자리에 대부분이 좋다고 하더군요. 사실 그 때까지만 하더라도 학교와 집 밖에 모르던 범생을 벗어나지 못한 상태여서, 왠지 당구장엘 간다는 것이 좀 불량스럽게 느껴졌습니다. (하!하!하! 참 순진했습니다.)

고등학교 때 잘 나간다(?)는 친구들이 쉬는 시간 마다 책상위에 미니 당구대를 만들고, 흰색 분필, 빨간색, 파란색 분필을 잘 갈아서 만든 미니 당구공을 가지고 연습하는 것을 봤기 때문에 처음 잡아 보는 큐와 당구대가 낯설지는 않더군요.

아무튼 dama 30을 놓고 동기 3명과 처음으로 당구라는 것을 해 봤습니다. 어라! 그런데 선무당이 사람 잡는다는 말이 맞는가 봅니다. 같이 당구를 했던 친구들의 수준은 80에서 100 사이였는데 제가 1등을 먹게 되었습니다. 운이 좋아서 그랬던지 천부적인 재능이 있었는지 모르지만 그렇게 시작한 당구인생은, 초등학교 친구들과 본격적으로 당구장에 다니기 시작하면서, 입문 한달만에 dama 100에 도달하게 되었습니다.

저에게 당구의 神氣가 있다고 생각 했습니다. 그럼 11년이 지난 지금 저의 dama는 얼마일까요? 적어도 한달만에 dama 100을 달성했는데, 적어도 dama 300정도는 되어 있겠죠?

사실 11년이 지난 지금도 dama 100에 머물고 있답니다. 한달만에 dama 100을 달성했던 그 神氣는 어디로 간 것일까요? 아니면 당구장 수호신이 순진한 대학생을 당구장의 마수에 빠지게 할려는 목적으로 저를 홀린걸까요?

여러분 모두는 무언가를 배우다, 저의 당구 실력처럼 일정 수준에서 더 이상 발전하지 않는 경험을 한번씩은 해 보셨을 겁니다. 이런 학습의 발달 과정을 S자 학습 곡선으로 설명하기도 합니다. S자 학습 곡선에 대해서 잠깐 설명을 드리면요. 학습 초기 단계에는 조금의 노력만 투입해도 학습 수준이 금방 높아집니다. 하지만 어느 정도 학습 수준에 도달하게 되면 투입된 노력에 비해서 학습 수준이 답보하는 정체기를 맞게 되죠. 학습자가 해당 분야에 뛰어난 능력을 보유하거나 뼈를 깎는 노력을 한다면 이 정체기를 벗어나서 다시 학습 초기와 같은 학습 효과를 보게되는게 S자 학습 곡선입니다. (아마도 저의 당구 학습 곡선은 정체기가 무척이나 긴 비정상적인 형태의 S자 모양인거 같네요.)

연금술사, 11분, 오 자히르 등으로 잘 알려진 파올로 코엘료의 소설에서는 이 S자 학습 곡선과 비슷한 설명이 몇 가지 있습니다. 우선 연금술사에서는 다음과 같은 구절이 있습니다.

“…그 채굴꾼은 에메랄드를 캐기 위해 자신의 모든 것을 버린 사람이었다. 에메랄드 하나를 캐기 위해 오 년 동안 강가에서 99만 9천 9백 99개의 돌을 깨뜨렸다. 마침내 그는 포기하기로 마음 먹었다. 그런데 그 순간은 그가 에메랄드를 캐기 위해 돌 하나만, 단지 돌 하나만 더 깨뜨리면 되는 그런 순간이기도 했다. 그는 자아의 신호, 그 중대한 기로에 서 있었다. 노인은 그의 삶에 개입하기로 했다. 노인은 한 개의 돌멩이로 변해서 채굴꾼의 발 앞으로 굴러갔다. 오 년 동안의 보람 없는 노동에 한껏 화가 나 있던 채굴꾼은 그 돌을 집어 멀리 던져버렸다. 그가 던진 돌은 날아가 다른 돌과 세게 부딪혔다. 그리고는 세상의 가장 아름다운 에메랄드를 내보이며 깨어졌다. …”

그리고 오 자히르에서는 아래와 같은 구절로 표현하는군요.

“… 아코모다도르 : 살다보면 어느 순간인가 한계에 도달하기 마련이다. 정신적 외상, 쓰디쓴 실패, 사랑에 대한 환멸 등이 있다. 때론 대가를 치르지 않고 얻은 우연한 성공이 우리를 소심하게 만들어 더 이상 앞으로 나아가지 못하게 한다. 자기 내부의 잠재된 힘을 일깨우는 수련중에 있는 주술사라면 맨 먼저 ‘아코모다도르’ 에서 자유로워져야 한다. 그러기 위해서는 자신의 삶을 전체적으로 되돌아보고, 자신의 아코모다도르가 어디에 있는지를 알아내야 한다. …”

당구 이야기보다 더 오래된 이야기가 있습니다. 지금으로부터 18년 전인 초등학교 6학년 때입니다. 친구 집에 놀러 갔다 컴퓨터라는 것을 처음으로 보았습니다. 뽀얀 하얀색 몸체에 회색의 버튼들이 피아노 건반처럼 나란히 줄 맞혀 놓여있고, 그 위에는 네모난 구멍이 있어서 무엇인가를 넣을 수 있는 네모난 상자, 이것이 저의 컴퓨터에 대한 첫인상이었습니다.

그 컴퓨터는 아실만한 분은 다 아는 대우에서 나온 msx2였습니다. 그 투박하게 생긴 물건에서 ‘보글보글’이라는 당대 Hit game부터 basic 프로그래밍까지 아무튼 소년에게 환상을 심어주기에는 충분하였습니다. 막 사춘기 시절을 맞게된 그날부터 컴퓨터와 사랑에 빠지게 되었습니다. 그 이후로 XT(대우 코로나 2000), AT, 486 그리고 현재 회사에서 쓰고 있는 노트북까지 어떻게 보면 우리나라 가정용 PC의 산증인이라 할 수 있겠네요.

컴퓨와 맺은 인연은 자연스럽게 베이직 프로그래밍으로 연결되었고 결국에는 오늘날의 밥 벌이까지 되었습니다. 하지만 저의 프로그래밍 실력에도 코엘료가 말하는 ‘아코모다도르’가, S자 학습 곡선에서 말하는 정체기에 놓인거 같습니다. 저 뿐만이 아니라 컴퓨터가 좋아서 이 직업군에 들어왔건, Y2K 때 벤쳐라는 환상을 쫓아 이 세계에 정착을 했건 이런 여러가지 이유를 떠나서, IT세계에서 프로그램을 하는 이들은 어느정도 발전기를 지나면 반드시 맞게되는 정체기가 있습니다.

이런 정체기는 몸 담고 있는 회사에서 요구하는 기술 수준이 일정 수준을 넘지 않거나, 우리나라 IT가 SI위주의 노동 집약적인 산업 구조이기 때문일 수도 있습니다. 만일 S/W 개발이 당신을 행복하게 만들어 주는 원동력이라면, 지금 자신이 ‘아코모다도르’와 진보와 정체의 S자 곡선의 변곡점에 위치해 있는지 곰곰히 생각해 볼 필요는 있는것 같습니다. 그런 고민이 당장에 당신을 성공으로 가는 Royal Road위에 데려다 주진 않겠지만, 에메랄드를 발견하기 위해서 돌을 깨트리는 채굴꾼처럼 어느날 당신에게 영롱한 빛을 발하는 에메랄드를 손에 넣는 계기는 마련해 줄 수 있을겁니다.

뽑기를 기억하시나요? 초등학교 하교 길에 수 많은 초등학생의 주머니를 노렸던 뽑기에 코 묻은 동전 몇개를 받치지 않았던 사람은 없을 겁니다.

뽑기 종류도 많았지만, 기억에 가장 많이 남는건 50원에 한판이었던 설탕을 녹여 만든 사탕 뽑기였습니다. 다들 기억나실거에요. 꽝은 어른 손가락 두개만한 사탕에서 부터 대박이라고 할 수 있는 1:1 scale의 잉어 사탕까지, 50원이라는 적지 않은 돈을 지불했지만 성년이 된 지금 나름대로 추억거리라 생각합니다.

세태는 돌고 도는 법, 요즘 초등학생은 어떤 뽑기를 하는지 궁금해 web surfing을 하다 이런 기사를 찾을 수 있었습니다.

초등학교 앞 불법게임기 성인오락‘판박이’

격세지감이라는 표현이 딱인거 같습니다. 제가 생각하는 추억의 뽑기와는 사뭇 다른 모습이네요. 어른들의 상혼이 어린이들의 추억마저 변질시키는거 같아 씁쓸함을 감출 수가 없습니다.

뽑기 이야기는 여기서 접고, 본론으로 들어 가도록 하겠습니다. 소프트웨어 개발을 하는 것과 뽑기와는 닮은 점이 많은거 같습니다. 왠 쌩뚱 맞게 뽑기와 소프트웨어 개발에 닮은 점이 있다고 하냐구요? 못 믿으시겠다면 예를 하나 들어 보도록 하겠습니다.

지금 여러분 앞에 상자가 하나 있다고 가정을 해 봅시다. 이 상자에는 S/W 개발 Project을 하면서 발생할 수 있는 나쁜 상황을 (개발 납기 지연, 개발자 퇴사, 개발 비용 증가, 팀의식 악화, 사소한 PC 고장 등등) 적은 쪽지와 ‘꽝’이라고 적혀 있는 쪽지가 적당한 비율로 섞여 있습니다. 프로젝트를 시작하면 프로젝트 팀원 중 한명이 매일 이 상자에서 쪽지를 하나씩 뽑기 시작합니다. 그런데 이 뽑기 상자는 신비한 마력을 갖고 있기 때문에 뽑은 쪽지의 상황이 발생하게 됩니다. 즉 “개발 납기가 10일 지연 됩니다”를 뽑게 되면 너무나 신기하게도 개발 납기가 10일 지연되는겁니다. 반대로 ‘꽝’을 뽑게 되면 그 날은 무사히 넘어갈 수 있습니다.

자~ 이런 식의 뽑기를 매일 한다면 PL은 아침마다 신경이 곤두 서게 됩니다. 재수없게 며칠 연속으로 나쁜 쪽지를 뽑게 되는 판이면 주위에서 알려 주는 유명한 박수 무당에게 가서 살풀이 굿이라도 하고 싶은 심정일 것입니다.

우리가 몸 담게 되는 프로젝트는 이런 뽑기 상자를 하나 씩 가지고 있습니다. 어떤 프로젝트는 너무 운이 좋아서 나쁜 쪽지의 비율이 5% 미만일 수도 있고, 또 다른 프로젝트는 억세게 운이 없어 나쁜 쪽지의 비율이 반을 넘을 수도 있습니다.

나쁜 쪽지를 뽑는다는 것은 프로젝트에 어떤 의미가 있을까요?

프로젝트에서 Risk가 발생한다고 말할 수 있습니다. 나쁜 쪽지가 많이 들어 있는 상자를 가지고 있는 프로젝트는 Risk 발생 정도가 높은 High risk project라 할 수 있으며, 반대로 나쁜 쪽지가 거의 들어 있지 않는 상자를 가지고 있는 프로젝트는 Low risk project라 할 수 있습니다.

나는 소망한다. 내게 Low risk project가 걸리길…

그렇다면 Low risk project는 High risk project보다 좋은 걸까요? “피플웨어”를 쓴 톰 디마르코와 티모시 리스터의 또 다른 명저 “소프트웨어 프로젝트에서의 리스크 관리”에서는 Low risk Project와 High risk project를 이렇게 평가합니다.

“… 리스크를 회피하는 것은 결코 좋은 전략이 아니다. 여러 프로젝트를 하다 보면, 가끔은 리스크가 전혀 없어 보이는 프로젝트를 할 때가 있다. 그런 손쉬운 프로젝트를 맡기 위해 노력도 하고, 덕분에 쉬운 프로젝트를 맡게 되었을 때는 조상님께 감사했던 기억이 있을지도 모르겠다. 물론 나도 예외는 아니었지만, 돌이켜보면 참으로 어리석은 일이다. 왜냐하면 리스크가 없는 프로젝트를 수행한다는 것은 정말 가치 없는 일이다. … 리스크가 없는 프로젝트는 절대로 하지 마라 … 리스크와 이익은 항상 동전의 양면과 같다. 보통 프로젝트에 리스크가 많은 이유는 프로젝트를 통해 이제까지 경험하지 못했던 미지의 문제들을 해결해야 하기 때문이다. …”

즉 톰과 티모시는 High risk project에서 많은 가능성이 있다고 주장합니다. 가능성이라 함은 High risk project를 하면서 얻을 수 있는 역량 성장, 높은 성과, 고객의 좋은 평가라 할 수 있겠죠. 톰과 티모시의 주장이 맞다라면 우리는 High risk project를 피해야 할 장애물로 인식하는 것이 아니라 극복의 대상으로 보아야 합니다. 그렇다면 High risk project가 문제가 되는 이유가 무엇일까요?

문제는 High risk project가 아니라, Risk를 대하는 우리의 자세입니다. 앞에서 들었던 예처럼 매일마다 뽑기를 하는 심정으로 프로젝트의 Risk를 대하는 거죠. 오로지 운에 맡기면서 프로젝트가 아무런 탈없이 종료되기를 바라는 것입니다. 재수 좋게 나쁜 쪽지가 없는 Low risk project라 하면 별 문제 없겠지만, High risk project라면 문제의 심각성이 매우 높을 것입니다.

Risk는 모든 project에서 필연적으로 발생할 수 밖에 없다면, 우리는 발생된 Risk가 project를 망치지 않도록 관리해야 합니다. 따라서 project를 성공적으로 끝내기 위해서는 반드시 Risk 관리를 해야 하는 것이죠. 오늘은 여기에서 post를 마치고 다음 차례에 Risk관리란 어떻게 하는 것이 좋은지에 대해 post하도록 하겠습니다. (언제라고 기약은 못 하겠습니다. 자주 방문하시면 언제간 post 되어 있겠죠? ^^)

※ 며칠 연속으로 나쁜 쪽지를 뽑은 PL이 고심 끝에 용하다는 무당을 찾았습니다. 이야기를 들은 무당이 부적 하나를 써주겠다고 합니다. 그런데 부적 값으로 100만원이나 달라고 하는군요. 사기꾼 같은 무당이라고 PL은 속으로 생각했지만 한편으로는 며칠 계속 되는 불운에 지푸라기 잡는 심정으로 100만원 짜리 부적을 쓰게됩니다. PL이 못보도록 부적을 쓴 무당은 부적을 봉투에 넣은 후

“이 부적을 상자에 붙히면 효과가 있을거야. 프로젝트 끝나면 봉투에서 부적을 꺼내 불태워.”

PL은 부적이 든 봉투를 가지고와 무당이 시킨대로 상자에 붙혔습니다. 이를 본 팀원들은 며칠 계속된 불운에 PL이 맛이 갔다고 생각했습니다만, 한편으로는 부적이 효험이 있기를 바랬습니다. 그런데 너무나 지은 듯한 얘기처럼 부적을 붙인 다음 날부터 프로젝트가 끝나는 날까지 나쁜 쪽지를 뽑아도 그 쪽지의 일이 발생하지 않는겁니다. (너무 지은 얘기같이 티나죠?) 드디어 프로젝트는 성공적으로 끝나고 PL은 부적을 태우기 위해서, 상자에 붙은 봉투에서 부적을 꺼내어 봅니다. PL은 부적에 적힌 글을 보고 놀랍니다. 부적에는

“PL君 다음부터는 비싼 부적 쓰지말고, Risk관리하게나.”

라고 적혀 있었다는군요.

이 Blog를 만들기로 결심하면서 행복한 고민에 빠지게 되었습니다.

…Don’t count your chickens before they are hatched.

만들지도 않은 blog지만 이름은 폼 나는 걸로 하고 싶다는 생각이 들더군요. 또 유명해져서 blog가 활성화 되면 많은 부하가 걸리게 될게 걱정되더군요. 그래서 돈 아낀다고 중소 업체의 웹서버를 사용하기 보다는 처음부터 성능 좋은 웹호스팅을 받아야 하지 않을까 라는 생각도 들었습니다. 호스팅을 한다면 윈도우즈로 해야 하는 건지 아니면 리눅스로 해야 할지. 리눅스/유닉스로 한다면 php로 하는 게 좋을지 아니면 jsp로 해야 할지.

직접 개발하지 않는다면 제로보드를 사용하면 쉽게 만들 수 있지만, 제가 생각한 blog의 이미지와는 맞지가 않더군요. 아니면 처음부터 인터넷 상에 돌아다니는 open source wiki를 사용할지. 좀 고쳐서 취향에 맞게 할지. 회원 관리는 해야 되는 건 아닌지. 아니면 메일링 리스트로 간단히 blog 업데이트 정도를 알려 주는 게 좋을지.

제 상상의 날개는 꼬리에 꼬리를 물고 2-3일이 지나도 blog의 진전은 없더군요. 이런 식으로 가다가는 naver를 만들어야 겠다는 생각도 들었습니다.

그러다 머리를 스치고 지나 가는 글이 하나 있었습니다. 바로 joel on software에서 읽은 글인데 원글은 Fire And Motion 여기서 확인하실 수 있습니다.

본문의 내용을 간추려 보면

“…전투에서 적에게 접근하기 위해서는 적이 얼굴을 들지 못하도록 엄호 사격을 해야 합니다. 만일 내가 아무것도 하지 않고 참호에 가만히 앉아 있다면 적은 내게 무슨 일이 있는지 눈치 챌 것이고 바로 그 순간이 적이 나에게 다가올 기회를 주는 것입니다…”

글쎄요. 제 blog에 적이 존재할까요?(모든 이와 친구가 되고 싶은데 적이라요.) 적이라는 표현을 제 blog에 접속하는 블로거로 바꾸어 보는 건 어떨까요? 제가 blog에 글을 쓰는 이유는 무엇일까 라는 생각을 해 보았습니다. 여러 가지가 떠올랐지만 가장 큰 이유는 평소에 software 개발을 하면서 느꼈던 점을 블로거들과 공유하고 싶어서 입니다.

생각의 공유가 일차적인 목표라는 생각이 들자. php나 웹호스팅같은 것은 너무나 하찮게 보였습니다. 그래서 모든 생각을 접고 윈도우즈의 메모장을 실행시켰습니다. 우선 기본적인 부터 입력하기 시작했습니다. 다음으로는 body를 만들고 layout 정리를 위해서 table을 추가 시켰습니다. 그리고 photoshop에서 “Talk about Software with hani.” 라는 (이틀간의 고민의 산물) banner를 만들어서 table에 넣고 joel의 홈페이지에서 stylesheet 파일을 참고로 제 blog의 stylesheet를 만들었습니다. 그리고 첫번째 post로 무엇이 좋을까 고민하다 Moneytoday에서 읽은 “프로젝트 성공의 첫째 요건”이 떠올라서 Moneytoday에서 찾아 index.html에 넣었습니다.

이 작업에 얼마나 걸렸을까요? 대략 1시간반정도요.

달랑 index.html 파일 하나지만 2-3일 전에는 상상도 못했던 blog를 가지게 되었습니다. Software를 하건 무엇을 하건 간에 일단 조금씩 움직이는 게 목표를 달성하는 지름길인 거 같습니다. 이런 작은 움직임은 조금씩 앞으로 전진해 나간다는 것을 뜻하니까요. 코끼리를 한입에 삼킬 수는 없지만 한조각씩 먹는다면 언젠가는 그 큰 코끼리도 다 먹어 치울 수 있지 않을까요? 하고 싶은 일이 있다면 그게 무엇이 되듯 지금 시작해 보세요.

※ 앞으로 php와 MySql을 이용해서 blog를 구성할 계획은 가지고 있습니다만, 차근 차근히 하나씩 필요할 때마다 만들 생각입니다. (물론 제가 다 만들겠다는 생각은 없습니다. 세상은 넓고 뛰어난 tool들은 이미 나와있으니까요.)

※ 2005.12.04 : 조금씩 움직이기 전략에 기반해서 blog를 간단한 htm버전에서 WordPress 툴로 migration했습니다. 여기서 최초의 blog버전을 확인하실 수 있습니다.