오늘 좋은 책을 읽었습니다. - 채수원씨의 테스트 주도 개발 TDD 실천법과 도구

[hanmoi Choi]

오늘 드뎌 구입한지 5일만에 채수원씨의 테스트 주도 개발 TDD 실천법과 도구라는 책을 받아서 반정도 읽었습니다.

JAVA는 처음이지만 5년간 C로 임베디드쪽에서 일을 했기에 코드 품질 관리와 디버깅과 일정이 개발에 얼마나 중요한지는

알고 있습니다. 하지만 제가 몸 담았던 회사는 생산해야 하는 모델이 너무 많아 코드 품질보다는 어떻게든 일정내에 프로젝트를

마쳐야 했기에 TDD는 언감생심이었고 들어 보기도 힘든 그냥 딴 세상 일이었기에 관심조차 없었습니다.

이 책을 읽고 나서 소감은 TDD를 활발하게 사용하는 Agile방식으로 프로젝트를 일하는 팀에서 일하고 싶다는 것이었습니다.

제가 SI쪽을 모르기에 얼마나 많은 팀에서 이렇게 일을 하는 지 궁금하지만 만약 취업 인터뷰를 하게되면 Agile로 프로젝트 진
행하나요?

라고 묻고 싶네요 (-0- 이렇게 하면 취업이 안될려나 -_-).

친근한 이름을 가진 분도 몇 분 계시더군요. 그래서 더 반가운 책이었던것 같습니다.

학원에서 공부랑 프로젝트 진행하는 동안 꾸준히 연습하여 조금이나마 익숙해지는게 제 목표입니다.

일단은 배울게 많아서 즐겁고 재밌지만 약간은 힘든 JAVA 인 것 같습니다.

[Sanghyuk Jung]

 

 개인적으로, Spring을 만난 이후로 본격적으로 TDD를 하게 되어서, 뭔가 추상적이던 TDD의 가치를 실제로 느끼게 되었었습니다. Dependency injection이 있으니 테스트 코드안에서 테스트 전용 객체로 바뀌치기도 편하고, MockHttpServletRequest같은 테스트용 객체들도 제공되고,  DB하고 연결한 통합테스트할때 AbstractTransactionalJUnit4SpringContextTests같은 클래스(이름도 길다;)는 정말 고마운 존재죠;

 

 Kent Beck은 주로 일반적이고 보편적인 가치를 이야기한다면, 스프링의 창시자 로드존슨은 Java 웹개발자의 실무와 가까운 거리에서 이야기해주는 느낌입니다..

 

 로드 존슨이 쓴 책이나 인터뷰를 보면, 그도 나름 열혈 TDD 주의자라고 느껴집니다.

 

“그저 테스트를 먼저 작성하지 않고서는 코드를 생성할 수 없습니다…프로토타이핑 중이든 가볍게 시험삼아 무언가를 작성하든 관계없이 무조건 테스트를 먼저만들 것입니다. 이 방법이 현재의 저에게는 더 빠른 방법이니까요”

- 세상을 뒤흔든 프로그래머의 비밀 중에서

 

"It's vital that the suite of tests continues to reflect the requirement of the application throughout the project lifecycle"

- Expert to one to one j2ee development 중에서..

 

그리고 j2ee development without EJB에서도 Test first가 Test late보다 나은 이유를 말하고 있죠..

 

나름 Spring과 TDD도 연관이 있으니  두 주제를 동시에 관심을 가지고 계시면 시너지를 느끼실 거에요 ^^;

 

 

(참고로 NHN에서는 Agile 프랙티스를 많이 따르고 있으니 TDD나 CI, 일일회의, 회고 등의 애자일 프랙티스에 관심이 있으신 분은 많이 지원하셨으면 합니다 ^^;  )

 

2011년 3월 6일 오후 10:36, hanmoi Choi <forh...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[Minjae Kim]

TDD의 진가에 대해서는 곱씹을 필요가 있다고 생각합니다.
왜냐하면 TDD를 소개한 켄트벡 아저씨의 변을 보면 알 수 있습니다.

그 분이 강조하는 단어가 있습니다. accountability
어떤 사안에 대해 설명 가능하냐는 것이죠.

Why, What, How 중 Why를 그 시작점으로 하는 것이 TDD입니다.
스펙이 주어지면 단순코딩을 하는 개발자부터 왜 이걸 해야 아는지 아는 아키텍트급 개발자까지 여러 수준의 개발자 분들이 존재합니다.

어디까지 생각하고 개발자의 길을 들어셨는지는 각자 틀리겠지만..
들어선만큼.. accountability를 항상 생각하는 개발자가 되어야 한다고 생각하고, 그러려면 TDD는 좋은 훈련 도구이자 방법론이 되는거 같습니다. ^^

2011년 3월 6일 오후 11:51, Sanghyuk Jung <ben...@gmail.com>님의 말:

--
Deep & Supple

김민재, MJ Kim

Blog: http://px.tistory.com
E-Mail :  con...@gmail.com
NateOn : con...@nate.com
Phone : 82-10-7138-5108

[Chung Wan Park]

현실에서는 TDD를 적용하기가 쉽지 않다는게 가장 어려운 문제일 것입니다.

SI에서 PM이나 개발자들에게 TDD에 대해서 이야기하면 가장 먼저 난색을 표하죠.

이론상으로는 아주 좋으나 일정이 부족할 수 있다는 불만을 접하게 되죠.

PM과 개발자들에게 이러한 TDD의 장점을 이해하고 적극 받아들이는 분위기가 필요하지만, 아직은 쉽지 않은 선택입니다.

저 또한 개인적으로는 TDD의 장점을 이해하고 충분히 적용할 가치가 있다고 느끼지만, 이를 현실에 적용하기란 녹녹치 않은

과제이기도 하구요.

현재 저는 TDD를 훈련 도구로써 유용하게 사용하고 있답니다.

미흡하기는 하지만 Spring을 학습하거나, 문제 해결에 필요한 로직에 대한 점검용으로요.

이 정도 사용에 만족하며, 향 후 TDD 적용 시에 맘껏 함 펼쳐 볼 수 있을거라는 기대를 하면서 말이죠.

2011년 3월 7일 오후 1:43, Minjae Kim <con...@gmail.com>님의 말:

[Toby Lee]

그 분이 강조하는 단어가 있습니다. accountability
어떤 사안에 대해 설명 가능하냐는 것이죠.
Why, What, How 중 Why를 그 시작점으로 하는 것이 TDD입니다.
스펙이 주어지면 단순코딩을 하는 개발자부터 왜 이걸 해야 아는지 아는 아키텍트급 개발자까지 여러 수준의 개발자 분들이 존재합니다.

켄트 벡이 TDD를 설명할 때 언급한 accountability는 why가 아니라 무엇(what)을 어떻게(how) 해왔는지를 샅샅이 설명할 수 있느냐는 개념으로 알고 있습니다. 현재 코드가 어떻게 만들어지게 되서 어떤 경로를 거쳐서 지금의 모습이 되었는지는 테스트로 모두 설명할 수 있기 때문입니다. 마치 기업이 회계장부를 꼼꼼히 기록하면 현재 재무 상태가 무엇을 하고 어떻게 해서 나오게 되었는지 설명할 수 있는(accountable) 것과 마찬가지입니다.

Why는 그런 왜 테스트를 만들었는지를 설명할 때는 필요하겠지만 그것이 TDD의 출발점은 아니라고 생각합니다.

2011/3/7 Minjae Kim <con...@gmail.com>

[Minjae Kim]

토비님 설명이 더 맞을 수 있다고는 봅니다만..
제 글의 맥락은.. 사실 TDD에서 출발했다기보다는 accountability에서 출발했습니다.
accountability는 거버넌스에서도 중요한 단어이고, Why의 측면입니다.

회계장부의 비유가 적절해 보입니다.
그런데, what과 how가 있다면, 그 전의 why에도 분명 닿아 있다고 보는 견해입니다.

쉽게 생각하면,
TDD에서 코딩의 시작은 test code입니다(물론 여기도 반론의 여지가 있겠지만..). 뭘 테스트하고 싶다는 것을 상정하는 것이죠. 뭘 테스트 한다는 것은 이 물건이 무엇에 필요해서인지를 간과한 상태가 아니라는 점을 애써 강조했다고 보심 좋을거 같습니다.
테스트 코드 상에는 why가 잘 들어나지 않을 수 있습니다만, 추적성을 찾아야 하는 경우 분명 왜 이것들을 테스트했는지에 대한 의문과 탐색은 개발자 마음에 분명 있지 싶습니다.

항상 내 위치와 역할이 뭔지를 궁금해 오던 개발자여서 이젠 매사가 why에서 출발을 하는 경향이 있습니다. TDD에 억지로 Why를 맞춘 경향이 있다고 한다면 추가 코멘트 부탁 드릴게요. ^^

2011년 3월 7일 오후 3:02, Toby Lee <toby...@gmail.com>님의 말:

[Toby Lee]

모든 what, how에는 당연히 why를 붙일 수 있겠죠. 하지만 그것이 TDD나, TDD의 특징을 설명한 accoutability의 핵심이라고 보지는 않습니다. 그런 식으로라면 TDD가 아니라 다른 개발 방법을 사용해도, 상세한 accountability가 남지 않는 개발 방법도 다 why로 시작한다고 말할 수 있습니다. 

굳이 TDD에 accountability를 붙여서 설명한 이유는 모든 결과물에 대해서 무엇을 하려고 어떻게 해왔는지라는 상세한 log가 남아있게 하는 것이라고 생각합니다. 원래 회계(accounting)이라는 것이 의미나 가치, 이유와 상관없이 어떤 과정을 거쳤는지를 상세하게 정리해두는 logging 작업이니까요. 

그런 의미에서 TDD의 출발은 what, how가 아니라 why라는 말은 그다지 동의 돠지 않습니다. 

 때론 why에 대한 답이 없음에도 두려움 없이 앞으로 나갈 수 있게 만드는 것이 TDD인 것 같습니다.

2011/3/7 Minjae Kim <con...@gmail.com>

[Minjae Kim]

TDD를 이해하는데 도움이 되는 코멘트 감사합니다. ^^
"두려움 없이 앞으로" <-- 이 표현이 유독 좋네요.

2011년 3월 7일 오후 4:09, Toby Lee <toby...@gmail.com>님의 말:

[whites...@gmail.com]

김민재님의 글은 테스트에 대한 글 같고 토비님 글은 티디디에 대한 글 같네요.

보통 소스먼저 만들고나서 테스트하려고 할때 무엇을 왜 할지 생각하게 되고, 테스트를 먼저 만들 땐 어떻게 해볼까 생각하게 되더라구요.

개인적인 느낌일 뿐입니다.

BlackBerry® 에서 보냈습니다.

---

From: Minjae Kim <con...@gmail.com>

Sender: ks...@googlegroups.com

Date: Mon, 7 Mar 2011 16:34:36 +0900

To: <ks...@googlegroups.com>

ReplyTo: ks...@googlegroups.com

Subject: Re: [KSUG] 오늘 좋은 책을 읽었습니다. - 채수원씨의 테스트 주도 개발 TDD 실천법과 도 구

[Sungchul Park]

두 분이 무척 재미있는 대화를 하셨네요.

어쩌면 두 분 다 지난 켄트 백 방한 때 자리를 같이 하셨을 수도...

저는 그 곳에 가지 못해서 구체적인 의미는 알지 못하기에 이 메일링의 대부분 다른 분들과 비슷한 입장인데 다음 글을 통해 대충의 의미를 파악하고 있습니다.

http://www.threeriversinstitute.org/Accountability%20in%20Software%20Development.htm

혹시 두 분의 대화가 이해 안 가시는 분은 위 글을 한번 읽어 보십시오.

참고로 accountability를 영한 사전에서 찾아보면 "책임 있음, 의무" 정도로 나오는데 accountable의 의미를 제 맥 사전에서 찾아보면 이렇게 나옵니다.
required or expected to justify actions or decisions

다음 영영 사전에서는 이렇게 나오고요.
responsible for your decisions or actions and expected to explain them when you are asked

즉 자기의 결정이나 행동을 책임지고 설명할 수 있어야 한다는 말이고, accountability는 그러한 능력이나 성질을 가지고 있다는 의미가 되겠습니다.

TDD를 이해하는데 도움이 되는 코멘트 감사합니다. ^^
"두려움 없이 앞으로" <-- 이 표현이 유독 좋네요.

2011년 3월 7일 오후 4:09, Toby Lee <toby...@gmail.com>님 의 말:

모든 what, how에는 당연히 why를 붙일 수 있겠죠. 하지만 그것이 TDD나, TDD의 특징을 설명한 accoutability의 핵심이라고 보지는 않습니다. 그런 식으로라면 TDD가 아니라 다른 개발 방법을 사용해도, 상세한 accountability가 남지 않는 개발 방법도 다 why로 시작한다고 말할 수 있습니다. 

굳이 TDD에 accountability를 붙여서 설명한 이유는 모든 결과물에 대해서 무엇을 하려고 어떻게 해왔는지라는 상세한 log가 남아있게 하는 것이라고 생각합니다. 원래 회계(accounting)이라는 것이 의미나 가치, 이유와 상관없이 어떤 과정을 거쳤는지를 상세하게 정리해두는 logging 작업이니까요. 

그런 의미에서 TDD의 출발은 what, how가 아니라 why라는 말은 그다지 동의 돠지 않습니다. 

 때론 why에 대한 답이 없음에도 두려움 없이 앞으로 나갈 수 있게 만드는 것이 TDD인 것 같습니다.

2011/3/7 Minjae Kim <con...@gmail.com>

토비님 설명이 더 맞을 수 있다고는 봅니다만..
제 글의 맥락은.. 사실 TDD에서 출발했다기보다는 accountability에서 출발했습니다.
accountability는 거버넌스에서도 중요한 단어이고, Why의 측면입니다.

회계장부의 비유가 적절해 보입니다.
그런데, what과 how가 있다면, 그 전의 why에도 분명 닿아 있다고 보는 견해입니다.

쉽게 생각하면,
TDD에서 코딩의 시작은 test code입니다(물론 여기도 반론의 여지가 있겠지만..). 뭘 테스트하고 싶다는 것을 상정하는 것이죠. 뭘 테스트 한다는 것은 이 물건이 무엇에 필요해서인지를 간과한 상태가 아니라는 점을 애써 강조했다고 보심 좋을거 같습니다.
테스트 코드 상에는 why가 잘 들어나지 않을 수 있습니다만, 추적성을 찾아야 하는 경우 분명 왜 이것들을 테스트했는지에 대한 의문과 탐색은 개발자 마음에 분명 있지 싶습니다.

항상 내 위치와 역할이 뭔지를 궁금해 오던 개발자여서 이젠 매사가 why에서 출발을 하는 경향이 있습니다. TDD에 억지로 Why를 맞춘 경향이 있다고 한다면 추가 코멘트 부탁 드릴게요. ^^

2011년 3월 7일 오후 3:02, Toby Lee <toby...@gmail.com>님 의 말:

그 분이 강조하는 단어가 있습니다. accountability
어떤 사안에 대해 설명 가능하냐는 것이죠.
Why, What, How 중 Why를 그 시작점으로 하는 것이 TDD입니다.
스펙이 주어지면 단순코딩을 하는 개발자부터 왜 이걸 해야 아는지 아는 아키텍트급 개발자까지 여러 수준의 개발자 분들이 존재합니다.

켄트 벡이 TDD를 설명할 때 언급한 accountability는 why가 아니라 무엇(what)을 어떻게(how) 해왔는지를 샅샅이 설명할 수 있느냐는 개념으로 알고 있습니다. 현재 코드가 어떻게 만들어지게 되서 어떤 경로를 거쳐서 지금의 모습이 되었는지는 테스트로 모두 설명할 수 있기 때문입니다. 마치 기업이 회계장부를 꼼꼼히 기록하면 현재 재무 상태가 무엇을 하고 어떻게 해서 나오게 되었는지 설명할 수 있는(accountable) 것과 마찬가지입니다.

Why는 그런 왜 테스트를 만들었는지를 설명할 때는 필요하겠지만 그것이 TDD의 출발점은 아니라고 생각합니다.

2011/3/7 Minjae Kim <con...@gmail.com>

TDD의 진가에 대해서는 곱씹을 필요가 있다고 생각합니다.
왜냐하면 TDD를 소개한 켄트벡 아저씨의 변을 보면 알 수 있습니다.

그 분이 강조하는 단어가 있습니다. accountability
어떤 사안에 대해 설명 가능하냐는 것이죠.

Why, What, How 중 Why를 그 시작점으로 하는 것이 TDD입니다.
스펙이 주어지면 단순코딩을 하는 개발자부터 왜 이걸 해야 아는지 아는 아키텍트급 개발자까지 여러 수준의 개발자 분들이 존재합니다.

어디까지 생각하고 개발자의 길을 들어셨는지는 각자 틀리겠지만..
들어선만큼.. accountability를 항상 생각하는 개발자가 되어야 한다고 생각하고, 그러려면 TDD는 좋은 훈련 도구이자 방법론이 되는거 같습니다. ^^

2011년 3월 6일 오후 11:51, Sanghyuk Jung <ben...@gmail.com>님 의 말:

 

 개인적으로, Spring을 만난 이후로 본격적으로 TDD를 하게 되어서, 뭔가 추상적이던 TDD의 가치를 실제로 느끼게 되었었습니다. Dependency injection이 있으니 테스트 코드안에서 테스트 전용 객체로 바뀌치기도 편하고, MockHttpServletRequest같은 테스트용 객체들도 제공되고,  DB하고 연결한 통합테스트할때 AbstractTransactionalJUnit4SpringContextTests같은 클래스(이름도 길다;)는 정말 고마운 존재죠;

 

 Kent Beck은 주로 일반적이고 보편적인 가치를 이야기한다면, 스프링의 창시자 로드존슨은 Java 웹개발자의 실무와 가까운 거리에서 이야기해주는 느낌입니다..

 

 로드 존슨이 쓴 책이나 인터뷰를 보면, 그도 나름 열혈 TDD 주의자라고 느껴집니다.

 

“그저 테스트를 먼저 작성하지 않고서는 코드를 생성할 수 없습니다…프로토타이핑 중이든 가볍게 시험삼아 무언가를 작성하든 관계없이 무조건 테스트를 먼저만들 것입니다. 이 방법이 현재의 저에게는 더 빠른 방법이니까요”

- 세상을 뒤흔든 프로그래머의 비밀 중에서

 

"It's vital that the suite of tests continues to reflect the requirement of the application throughout the project lifecycle"

- Expert to one to one j2ee development 중에서..

 

그리고 j2ee development without EJB에서도 Test first가 Test late보다 나은 이유를 말하고 있죠..

 

나름 Spring과 TDD도 연관이 있으니  두 주제를 동시에 관심을 가지고 계시면 시너지를 느끼실 거에요 ^^;

 

 

(참고로 NHN에서는 Agile 프랙티스를 많이 따르고 있으니 TDD나 CI, 일일회의, 회고 등의 애자일 프랙티스에 관심이 있으신 분은 많이 지원하셨으면 합니다 ^^;  )

 

2011년 3월 6일 오후 10:36, hanmoi Choi <forh...@gmail.com>님 의 말:

오 늘 드뎌 구입한지 5일만에 채수원씨의 테스트 주도 개발 TDD 실천법과 도구라는 책을 받아서 반정도 읽었습니다.

JAVA는 처음이지만 5년간 C로 임베디드쪽에서 일을 했기에 코드 품질 관리와 디버깅과 일정이 개발에 얼마나 중요한지는

알고 있습니다. 하지만 제가 몸 담았던 회사는 생산해야 하는 모델이 너무 많아 코드 품질보다는 어떻게든 일정내에 프로젝트를

마쳐야 했기에 TDD는 언감생심이었고 들어 보기도 힘든 그냥 딴 세상 일이었기에 관심조차 없었습니다.

이 책을 읽고 나서 소감은 TDD를 활발하게 사용하는 Agile방식으로 프로젝트를 일하는 팀에서 일하고 싶다는 것이었습니다.

제가 SI쪽을 모르기에 얼마나 많은 팀에서 이렇게 일을 하는 지 궁금하지만 만약 취업 인터뷰를 하게되면 Agile로 프로젝트 진
행하나요?

라고 묻고 싶네요 (-0- 이렇게 하면 취업이 안될려나 -_-).

친근한 이름을 가진 분도 몇 분 계시더군요. 그래서 더 반가운 책이었던것 같습니다.

학원에서 공부랑 프로젝트 진행하는 동안 꾸준히 연습하여 조금이나마 익숙해지는게 제 목표입니다.

일단은 배울게 많아서 즐겁고 재밌지만 약간은 힘든 JAVA 인 것 같습니다.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Deep & Supple

김민재, MJ Kim

Blog: http://px.tistory.com
E-Mail :  con...@gmail.com
NateOn : con...@nate.com
Phone : 82-10-7138-5108

--

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Deep & Supple

김민재, MJ Kim

Blog: http://px.tistory.com
E-Mail :  con...@gmail.com
NateOn : con...@nate.com
Phone : 82-10-7138-5108

--

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.

이 그룹에 게시하려면 ks...@googlegroups.com(으) 로 이메일을 보내세요.

그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.

더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에 서 그룹을 방문하세요.

[Toby Lee]

http://www.threeriversinstitute.org/Accountability%20in%20Software%20Development.htm

켄트 벡이 설명하는 TDD의 accountability는 이 글에 잘 설명되어 있습니다. 이전에 구글에서 TDD 강의를 할 때 accountability를 설명한 내용도 좋은데, 그 이후에 자신이 설명한 accountability에 대한 오해들이 있는 듯 해서 좀 더 자세히 풀어서 쓴 글 같네요.

2011/3/7 Sungchul Park <gyu...@gmail.com>

[Toby Lee]

http://itc.conversationsnetwork.org/shows/detail301.html#

켄트 벡이 TDD를 설명할 때 accountability를 얘기하기 시작한 것은 이 때(2004년)였습니다. 참 좋은 내용이니 한 번 들어보세요.

2011/3/7 Toby Lee <toby...@gmail.com>