JasonPA

새로운 아이디어를 짜내기 위해 끙끙 댄다고 창의력이 향상되는 것이 아니다. 창의력을 개발하려면 단지 기존의 지식을 제거해버리면 된다.

좋은 것은 위대한 것의 원수다. - 볼테르

문제를 해결하는 능력이 바로 창의력이다.

1. 100마일 사고법 (생각나는 대로 빠르게 아이디어를 떠올리는 것): 양과 속도를 결합한 사고방법.
2. 180도 사고법 (전통적인 방식과 정 반대로 사고하는 방법) : 선입견과 고정관념에서 벗어나게해준다.
3. 초은하계 사고법 (자기 일과 무관한 분야의 정보를 자신의 문제와 연결하려고 노력하는 방법) : 합리적인 사고, 즉 계속해서 똑같은 자료에만 의존하려는 틀에 박힌 사고를 없애고 좀더 많은 가능성을 열어줌

창의력을 가로막는 5가지 장애물

1. 미지의 대상에 대한 두려움 (끊임없이 변화하는 세상에서 새로운 아이디어를 받아들이지 않고 현재에 안주한다면 실패할 수 밖에 없다)
2. 바보처럼 보일지도 모른다는 두려움
3. 성급한 판단
4. 옛것에 대한 집착
5. 성공에 대한 미련 (대단한 성과를 올린 사람 가운데에는 옛날의 영광에 사로잡혀 모든 상황에 적용되는 창의적인 해결책을 발견했다고 생각하는 사람이 많다)

모든건 항상 실천이 문제다... 내일 당장 아니 오늘 당장 실행하는 것이 중요 하다.

UML을 공부하려는 사람이 아닌, UML을 사용하려는 사람을 위한 책. UML 지상주의에 빠지지 않고 실용적인 관점에서 다루는 방법을 제시한다 - 알라딘 서평중 일부

서평에 나온 내용에 끌려서 오래전에 읽어봐야지 하고 사두었던 책이다. 한동안 책상 위에서 잠자던 녀석인데, 최근에 다시UML을 그릴 일이 생겨서 작성을 하던 중에 바로이 책이 눈에 띄었다. 굴러다니던 녀석이 왠지 읽어보쇼 하는 느낌이 들어서 첫페이지를 넘겼는데... 그것이약 3시간쯤 전이었던것 같다.

즉, 3시간 + 만에 일독을 해버렸다는 얘기다. !!!

읽는 동안 적어도 평균 2-3 페이지마다 한번씩은 마구 웃었던 것 같다.... 아니 이런 책을 읽다가 웃다니??? 도대체뭔소린가 싶기도 하겠지만, 스스로 찔리는 구석도 많이 느꼈고, 왜 이런 얘기를 저자가 하는가 하는 의구심이 들면서도 공감이되었기 때문이기도 하다.

쩝... (책을 읽고난 느낌을 함축한 말)

쩝이다... 쩝... 좋은 책인데 쩝이다....

실전에서는 이것만 쓰긴 하는데, 난 또 삽질을 해야한다.... 삽질을 해야한다.... 삽질을 해야한다....

어쨌건 읽는 내내 유쾌한 내용이었다. 저자의 공력에 찬사를 보낼만한 내용이다.

강추레벨 A

(인문학) 생각의지도

최근 책을 선별하는 방법을 바꾸고 나서 선택한 몇권의 책중에 첫번째 책을 읽었다. 책을 읽는 것 만큼이나 자신이 읽을 책을 선별하는 것이 중요하다는 것을 뼈저리게 느끼고 나서 - 책에 의하면 나도 너무나 동양적인 사고를 하는지 극과 극을 달리는 주장을 하는 책들을 접할때 마다 음..이 생각도 맞는것 같고저생각도 맞는것 같네... 라는 태도를 지니고 있는 자신을 발견 하고서는 좋은 책을잘 골라서 읽지 않으면 큰일 나겠다고 생각을하게 되었다 - 이제는 내가 읽을 책들을 직접 사냥에 나서기로 하고 맘을 먹고 지난주에 두시간 가량을 서점에서 사냥을 통해 선별해낸 두권의 책중 하나이다.

오랜만에 읽은 인문학 서적인것 같다. 리처드 니즈벳 이라는 사람의 글을 제자인 서울대학교 최인철 교수가 번역을한 내용이다. 무엇보다 책을 고르게된 이유는 글쎄... 서점을 헤메이다가 - 사실 역사쪽 서적을 선택하려고 했었다 - 손에 잡히는 책을 대략 훑어보는 행동을 하고 있었는데, 왠지 얇은 책이면서도 방대한... 오만가지 고민을 섞어놓은 듯한 느낌을 받는 책을 발견하게 되었다.

오오, 이건 할말이 정말 많은 사람 또는 무지 많은 지식을 가지고 있는 사람이 정말 추리고 추려서 적어놓은 글 같은데..라는 생각이 들면서 한장한장 읽을 때 마다 많은 생각을 하게 만드는 것이 재미난 책인 것 같아서 선택하였다. - 사실 책 마지막에 참고서적 목록을 보고서는 좀 놀랐다. -

저자는 동양쪽의 문화에 무척 관심이 많은 듯 했다. 직접 동양의 제자들과 부딧히는 문제들을 해결하면서 느낀점도많았으리라... 하여간 읽는 내내 여러가지 주제에 대해서 나름의 과학적인? 해석 방법을 덧붙여 가며 조목조목 나아가는 모습이 -다분히 주제가 어떤 면에서는 충격적 (극단적 주장일 수도 있으므로) 으로 다가왔지만 - 맘에 들었다.

일예로 동양과 서양의 어린아이가 명사와 동사의 습득의 차이를 보인다던지, 은현중에 말하며 생략하는 것도 차이가 나는 부분이랄지, 집단적인 부분적인 생각의 범주화의 차이를 설명한 부분 등등 무척 흥미로왔다.

이제 이 책을 읽고나서 나 자신이 사고하는 부분중에서 어느부분이 부족한지를 느꼈으니, 좀더 논리적으로 생각할 수 있는, 논리적인 사고의 폭을 넓힐 수 있는데 도움을 주는 녀석을 또 한번 사냥에 나서야 할 것 같다는 생각이 들었다.

.....

프로그래머가 바라본「진보에 장애가 되는 습관」
주목받는 SW 개발방법론「비교 분석」
「논쟁에서 승리하는」개발자가 되려면?

우선 오래된 글인데, 위 세가지 글을 읽어보라고 나 자신에게 권하고 싶다. 어떤 기술에 대해서 관심을 가져야 하며, 어떤것이 도움이 될 것인가? 또 어떤 것을 개선해야하는 항목으로 선정해야 할 것이며, 또 어떤 것을 버리고 어떤 것을 도입해야 할것인가???

모든 질문은 최근 몇일간 나 자신에게 던져진 질문인데, 위 링크의 첫번째 글 " 진보에 장애가 되는 습관 " 이란 글을읽고 다시 생각하는 계기가 되었다. "아 난 자신의 어떤 도그마에 빠져있었구나" .... 고기를 낚았으면 그물을 버리라니?고기를 잡는 방법은 그물만 있는 것이 아니라니? 도대체 상식적으로 이해하기 어려운 것 같으면서도 왠지 공감이 갈려고 하는 이분위기는 뭐지?

본능적으로 쿨한 것에 끌리는 나로서는 왠지 이 글을 읽고나서 반응이 오는 느낌을 갖게된다... 아 뭔가 다시 생각할 부분이 있구나.

새로운 기술들을 도입하는데, 새로운 뭔가를 찾아 헤메이는데 지금 갖고 있는 것을 버리지 못하고 있었다.

“어떤 관습이 편안하게 느껴질 때 그것을 때려 부숴라.” -- 니코스 카잔차키스

지금 편하게 느끼고 있는 기술은 무었인가? 지금 버리지 못하고 애물단지 처럼 안고 놓지 않는 기술은 무었인가?
제일 편하다고 느끼는 것에서 문제의식을 느껴야 한다. 버려야 한다.

"우리의 탐구나 수련으로 통해 얻게 된 지식은 그 자체로서 완결되는 것이 아니라 결국 어느 순간, 과정 내지는 다른 지식을 위한 초석이 된다"

멋진 말이다.

결국 우리가 안주하고 있는 기존의 패러다임. (RM - Engine?) 이 적절한 비유가 될까? 이것을 걍 버리라는 말이 아니다.
"대부분 패러다임의 변화는 이전 패러다임의 한계와 오류를 극복한 대안이기 때문에 오히려 패러다임에 대해 깊은 이해를 가지면 다음 패러다임의 예측도 가능합니다."

이제는 과거의 패러다임에서 벗어나야 할 때가 온 것 같다.

스스로 반문하는 일이 요즘들어서 많아졌다. 근래에 들어서 더더욱 고민하는 꺼리도 많아졌다. 새삼스러울 것도 없지만, 뭔가개인적으로 주기 같은 것이 있는데, 최근에 읽었던 책의 목록들을 살펴봐도 내가 내심 어떤 것을 원하는지를 알고 싶어하는 것같았다.

최근 3개월 이내에 내가 읽은 책들은

• 조엘의 두번째 책
• 대체 뭐가문제야?
• 백만불짜리 습관
• 마인드 혁명
• 삶의 에너지를 높이는 습관들

이다. 많지는 않지만, 대체로 개인적으로 뭔가 개선할 만한 꺼리를 찾고 있었던 것 같다. 3개월이 지난 지금에 와서도비슷한 행태를 계속 하고 있는 중이기도 하고... 이 와중에 또 김창준 님이 쓰신 블로그 내용을 보고 다시금 또 반성을 하고있는 중이다 ㅡㅡ;; 도무지 운동이란 것에 담쌓고 사는 것이 얼마나 무지한 일인가 깨닫게 해주는 내용인 것 같다. (다시생각해보니 과거에 김창준님이 쓰신 무술과 프로그래밍을 연관지어 쓴 내용을 봤을 때도 그랬던 것 같다).

역시나 게으른 것이 제일 문제였던가 보다... 잠시 수많은 일들을 떨처버리려고 고민만 하던 패턴을 약간 바꿔볼 필요가 있겠다. 머 거창하게 시작하면 나 자신을 잘 아는 나로써는 오래가지 못할 것을 알기에, 간편한
것부터 시작해봐야겠다.

워드프레스의 버그인가? 아래부터 내용이 주욱 잘려서 다시 씀

• 국선도, 내가 예전부터 좋아했었고 한동안 하던 수련인데 자식넘 태어나고 부터 계속 못했었다.
• 수영, 이건 접영만 아직 못하는데 최소한 접영까지는 마스터할 수 있도록 해야겠다.
• 줄넘기, 얼마전부터 시작한 것인데 생각보다 무지 힘들다. 이렇게 힘든 건지 몰랐지만, 짬짬히 해서 시간을 더 늘려갈 수 있도록 해야겠다.

쩝, 기억력의 한계인가? 뭔가를 작성하고 포스팅하고나면 다 잊어버린다니까 ㅡㅡ;; 더 생각이 안난다. 여기서 접어야겠다. (이것도 운동 꾸준히 하면 좋아지려나?)

원문 : http://software.ericsink.com/No_Programmers.html

개발자와 프로그래머의 차이에 대해서 기술한 블로그 내용.

여기서 '프로그래머'란 새로운 기능을 코딩하고 운이 좋으면 버그를 고치는 일만 하는 사람입니다. 프로그래머는 스펙을작성하지 않습니다. 자동화 테스트케이스를 작성하지도 않습니다. 그리고 자동화 빌드 시스템을 최신으로 유지하는데 도움을 주지도않습니다. 또 고객이 힘든 문제를 해결하는 걸 돕지도 않습니다. 설명서를 작성하는 데 힘을 보태지도 않고, 테스트에 참여하지도않습니다. 코드를 읽는 일조차 하지 않습니다. 프로그래머가 하는 일은 오로지 새 코드를 작성하는 것뿐입니다. 소규모 ISV에서는이런 사람을 원하지 않습니다. 여러분에게는 코드를 작성하는 특수 임무를 맡은 '프로그래머'가 아니라, 성공적인 제품 개발을 위해다양한 방식으로 기여하는 '개발자'가 필요합니다.

라는 내용의 글을 에릭싱크 자신의 블로그에 올려놓았다. 위 글을 언급하는 이유는? 최근에 다시금 어떻게 하면 무지막지하게고생하는 팀원들과 나 자신에게 좀더 테스트 코드를 작성하고 활용하게 할 수 있을까에 대한 고민을 다시 새로이 시작하는 시점에참고가 될만한 내용이라고 생각해서이다.

물론 테스트코드 .. 작성하면 된다. 무조건 통과할 수 있도록 거기에 맞추어서 코드를 추가할 수도 있다. 형식적인 자료만될 수 있는 코드도 무지하게 추가할 수 있다. 하지만, 스스로가 이건 정말 도움이 되는 것 같다... 정말 도움이 되었다. 라고느끼지 않는 다면 얼마 지나지 않아서 다시 이런 자동화된 테스트 코드를 작성하는 것을그만 둘 것이다. 나 자신도 물론 그럴것이고.

문제는 현재까지는 이런 테스트 코드를 작성하는 일이 재미도 없고, 그리 도움이 될만하다고 느껴본적이 없으며, 쉽게 느껴지지도 않는다는 것이다.

어떻게 하면 진정으로 도움이 되는 테스트라고 생각할 수 있을까? 어떻게 하면 이런 것을 경험할 수 있을까? 누군가 나서서 이렇게 하자!! 라고 지속적으로 외치기만 해서 해결될 수 있을까?

일단 위에나온 에릭 싱크의 말처럼 접근을 시작하는 것도 좋겠다. 누구나 자신이 발전하는 것을 좋아하기 때문이다. 이렇지않는 사람이라면 전혀 재고의 가치도 없을 것이다. 발전을 원하는 사람들에게라면 어느정도 씨앗이 될 수 있을 만한 거리를제공하고, 어떻게는 테스트 코드를 작성하는 것도 하나의 일이며, 이런 일을 할 수 있는 시간을 확보해서 제공하는 것만이 결국에는모두에게 이익이며 개발비용을 오히려 절감할 수 있는 것이라는 사실을 윗사람들에게도 제공할 수 있도록 데이타가 축적되어야 하겠다.

# 우선 작은 성공을 경험할 수 있도록 제공하자.

# 쉽다고 느낄 수 있도록 자동화할 수 있는 방법을 고민하자.

# 신입사원도 자연스럽게 할 수 있는 상태가 되면 누구에게나 쉬운 것이다.

거창하게 모든 것을 한꺼번에 통합할 필요성은 없다. 단위테스트 코드들이 늘어날 수록 테스트를 자동화해서 매번 거치는코드들은 그만큼 검증되었다고 인정해주는 분위기가 되어갈 때 즐거움을 느끼는 '개발자' 단계로 들어가는 것임을 상기시켜야 하겠다.

[블로그내용소개] 에릭 립퍼트 - 전구하나바꾸는데 마이크로소프트 직원 몇 명이 필요할까?

원문 : http://blogs.msdn.com/ericlippert/archive/2003/10/28/53298.aspx

위 내용이 번역되어진 책이 최근에 조엘의 두번째 책으로 엮어졌습니다.
읽다보니 역시나 조엘의 블로그 만큼이나 재미난 것들이 많더군요. 아직 읽는 중입니다.

이 글에서 나온 내용중에 너무나 지금 하고 있는 일에 딱 맞는 조언이 될 수 있을 것 같아서 한번 생각해보자는 의미에서 발췌해서 보냅니다.
(오래된 글인데, 역시 좋은 글은 언제 읽어도 도움이 되는 것 같습니다. 자세한 내용은 원문을 살펴보시면 되겠습니다.)

물론 우리 회사가 마이크로소프트와는 다른 성격의 제품을 생산하는 곳이라 약간 다르기도 하고 마이크로소프트자체의 프로세스가상당히 복잡하고 까다로와서 아래와 같이 될 수도 있지만, 어쨌든 한번쯤 기능을 추가하실 때 생각해볼만한 문제라고 생각합니다.

(한때 우리가 마이크로소프트를 이기자? 라고 외치셨던 분이 계셨습니다. 높으신 분으로 ... 생각해보면 이기긴 힘들 것 같습니다. ㅎㅎ)

[내용]
마이크로소프트에 근무하고 있는 에릭 립퍼트라는 사람이 VBScript 에 기능을 추가하는 일을 담당하고 있을 때 벌어진 일화를 소개하고 있습니다.

고객이 특정 기능(일반적으로 사용되지 않는 기능)을 추가해달라고 요구하는 상황에서 예기했던 내용이라고 합니다. 물론 이기능을 에릭이 추가하는데는 5분도 걸리지 않는다고 합니다. 하지만 이러한 기능을 넣을 수 없었던 이유에 대해서 아래와 같이얘기했습니다.

"전구 하나 바꾸는데 마이크로 소프트 직원 몇 명이 필요하다고 생각하십니까?"

# 요구 기능을 5분 안에 구현하기 위한 개발자 1명
# 명세를 작성하기 위한 프로그램 관리자 PM 1명
# 명세의 지역화 문제를 검토하기 위한 지역화 전문가 1명
# 명세의 접근성과 사용성 문제를 검토하기 위한 지역화 전문가 1명
# 발생 가능한 보안 취약점을 점검하기 위한 개발자 1명, 테스터 1명, PM 1명 (최소인원)
# 보안 모델을 명세에 추가하기 위한 PM 1명
# 테스트 계획을 작성할 테스터 1명
# 테스트 스케줄을 갱신할 테스트 리더 1명
# 테스트 케이스를 작성하고 테스트 자동화 방법을 만들 테스터 1명 (단위테스트만 하는 개발자형 테스터가 따로 있는 모양이군요)
# 무작위로 버그를 찾아내기 위한 테스터 3-4명
# 문서를 작성하기 위한 기술 저장 1명
# 문서를 교정하기 위한 기술 검토자 1명
# 문서를 교정하기 위한 편집자 1명
# 새로 작성한 문서를 기존 문서에 추가하고 목차, 인덱스를 갱신할 문서 관리자 1명
# 문서와 에러 메시지를 윈도우에서 지원하는 모든 언어로 번역하기 위한 번역자 25명
# 이들 업무를 조정하고 개발 비용을 부사장에게 승인 받아야 할 상위 관리자 팀.

이들 중 개별적으로 시간이 많이 소요되는 건 없지만 다 더하면 상당한 시간을 소모하게 됩니다. 그것도 아주 간단한 기능을구현하기 위해서 말이죠. 그리고 위 작업은 모든 것이 딱 맞아 떨어질 때를 가정한 것입니다. 만약 처음에 작성한 코드 다섯 줄에버그가 있다면 어떻게 할까요? 우리는 버그를 찾고, 다시 테스트를 수행하는 등의 작업을 하기 위한 비용을 추가해야 할 것입니다.

처음 생각한 5분 이라는 개발 시간은 많은 사람의 작업과 비용으로 확장됐습니다. 그저 한 고객에 자신이 원하는 기능을 담은1회용 VB6 컨트롤을 만드는 수고를 덜어 주기 위해서 말입니다. 미안합니다, 그렇게 하는 것은 사업상 불가능 하군요.마이크로소프트 직원은 덜 익은 소프트웨어를 출시하는 일이 없도록 매우 열심히 노력합니다. 소프트웨어를 올바르게 작성하는 것 -무엇보다도 평범한 일반 사용자가 보안 문제 없이 쉽게 기능을 사용할 수 있도록 보장하는 것 - 은 비용이 상당히 많이 드는일입니다.

하지만 우리는 그 일을 잘 해내야 합니다. 우리가 새로 만드는 스크립트 엔진을 수억 명이 사용하고 수천만 명이 프로그래밍할 테니까요.

보편적인 일반 사용자와 관련이 없는 기능을 새로 작성하는 것은, 주요 기능을 구현하고 버그를 잡으며 보안 취약점을 찾을 자원 (사람, 시간, 돈)을 훔치는 일과 다를 바 없습니다.

끝.

위와 같은 내용입니다.

밑줄친 부분을 해석할때 오해를 갖게되면 곤란하니... 다시 얘기하면 어쨌든 우리는 제품을 내놓기도 하지만, 커스터마이징도 해줍니다. (이런 경우를 같이 하고 있는 상황을 염두해두고 이해하시면 좀 안맞는 상황일 수 있습니다)

내부적으로 연구소가 PS 팀 또는 다른 협력업체에게 릴리즈 한다는 개념 선상에서 이해하시면 좋을 것 같습니다.

(고객에게 바로 릴리즈하는 것은 SI 죠? 안그렇습니까? 우리 회사는 SI 이다 라고 생각하시면 쩝 머 그런거겠죠. 그럼 여기서 생각은 스탑. - SI 하면서 고객에 요구하는데 안하면 안되지 않습니까?)

어쨌든 마이크로소프트와 우리가 다르다고 생각하십니까? 그렇죠 여러가지 여건이나 상황은 다를 수 있습니다. 머 그럼 여기서생각은 또 멈춰버리겠네요. 그럼 재미 없겠죠? 어쨌든 상황은 마소나 우리나 비슷한 것 같습니다. 제품을 패키징해서 내보내고있으니까요. 제품 출시가 계속 되는 한은 위 문제를 우리 것으로 소화해서 고민해볼 만한 가치가 있는 것 같습니다.

한번쯤 사간나실때 읽어보시고 (원문을) 생각하는 시간을 가져보시기 바랍니다.

Michael Yuan Java blog: "Is Ruby replacing Java? -- Not So Fast"

루비가 자바를 대체한다고? 음.. 아직은 아니다... 라는 내용의 글인데, 요지는 아래와 같다.

1. 우선 우수한 솔루션이 보다 덜 우수한 솔루션을 항상 대체하는 것은 아니다.

2. 경재적인 측면에서도 우수한 프로그래밍 언어를 선택하는 것이 항상 비용이나 생산성 측면에서 보다나은 잇점을 가져다 주지는 않는다.

In software engineering speak, the actual implementation of asystem using a specific programming language has the lowest value inthe value chain

3. 한 프로그래밍 언어가 다른 것을 대체하지는 않는다. 새로운 언어가 새로운 분야를 개척하거나 새로운 언어를 시도하려고하는 신규 개발자들을 유입시키는 역할을 한다. 이러한 점 때문에 새로운 언어를 위한 파이를 키울 필요가 있는 것이다.
ex) 포트란 : Science , 코볼 : Buissiness, 자바: web app. 등등등.

!! Ruby/RoR 은 다음과 같은 점에서 배워야할 중요한 기술이다.

1. Ruby/RoR 의 가장 중요한 점은 Java EE 에서 혁신을 주도할 것이다. C# 이 자바 1.5의 혁신을 주도했던것 처럼.

2. 많은 웹사이트들을 빠르게 개발해야하는 사람들은 (예를들어 컨설턴트 또는 신규창업) Ruby/RoR 이 아이디어나 빠른 베타/프로토타입을 시장에 내놓기 위해 사용하기에 가장 훌륭한 툴이다.

==============
저자의 결론은 어쨌거나 Ruby/RoR 이 자바 프로그램들을 대체하지는 않을 거라는 내용이다. 하지만 Ruby/RoR 이배워야만하는 가치는 있다. 라는 내용인데.. .글쎄.. 과연 컨설턴트나/새로 창업하는? 신규로 시작하는 사람들에게만 유용한것일까?

역시 기존! 과거! 옛것! 등등 류에 깃발을 꽃기란 쉽지가 않은 것 같다.
내공이 높은 사람들을 모두 설득하기에도 역시나 새로운 기술이 얼마나 경험많은 사람의 고집을 꺽을 수 있을까?

모든 것이 비슷한 패턴이다... 이 것 또한 시간이 해결해줄 것인가? 나는? 우리는? 그냥 가만히 있진 말고 시도! 도전! ...

.

해커와 화가 (1): "아름다운 소프트웨어인지 아닌지 측정할 수 있는 유일한 외부적인 방법은 시간이다. 시간이 지남에 따라서 아름다운 것은 번창하고못난 것은 사라진다. 불행하게도 여기에서 이야기하는 시간은 사람의 수명보다 길 수도 있다. 사무엘 존슨은 한 작가에 대한 평판이일정한 결론에 도달하기까지는 대략 백년 정도의 시간이 걸린다고 지적했다. 여론 형성에 영향을 미치는 작가의 친구와 추종자들이모두 죽어서 없어질 때까지 기다려야 한다는 뜻이다."

흣 재미난 내용이다. 사실 살아있는 동안 훌륭한 것이었다 라는 평가를 받기가 왜 어려운지 대충 이해할 수 있도록 설명해주는 내용 쯤 이랄까....
머 어쨌든 소프트웨어 업계에서 살아남는 것과 훌륭한 녀석을 선별할 수 있는 능력 과는 뗄레야 뗄수 없는 관계가 아닐까생각해본다. 매일 쏟아지는 녀석들 중에서 옥석을 가려내기가 참 어렵다. 이때 위와 같은 방법대로 약간 지켜보는 것만으로 어느정도가려낼 수 있다니.. 흐흐... 남들을 따라가는 형태로 보일 수도 있을 것 같은데, 잘 모르겠다.

문제는 열정과 관심을 잃지 않는 것. 항상 궁금해할 것. 튼튼한 체력! 정도가 아닐까.