[BOOK] 익스트림 프로그래밍(Extreme Programming Explained)

  익스트림 프로그래밍, 제2판 : 변화를 포용하라 

Kent Beck,Cynthia Andres/Insight (인사이트)
익스트림 프로그래밍(XP)의 목표는 탁월한 소프트웨어 개발이다. 더 낮은 비용, 더 적은 결함, 더 높은 생산성, 더 높은 투자 수익률, 더 행복한 사용자와 고객, 그리고 심지어는 더 행복한 개발자. 1999년에 Ex...

익스트림 프로그래밍(XP)은 최근 개발방법론 중에서 급부상하고 있는 애자일 소프트웨어 개발론(Agile Software Development)의 하나로, 단순성, 상호소통, 피드백, 용기 등의 원칙에 기반해서 "고객에게 최고의 가치를 가장 빨리" 전달하도록 하는 경량 방법론이다. 요구사항 등의 변화가 자주, 많이 있거나 개발자가 소규모(10명 내외)이고 같은 공간을 사용하는 경우에 높은 효과를 볼 수 있다고 알려져 있고, 다른 규모나 원거리 XP 등의 적용이 꾸준히 시도되고 있다.

http://purepond.cafe24.com/moinmoin/moin.cgi/ExtremeProgramming?action=SpellCheck
http://c2.com/cgi/wiki?ExtremeProgramming
http://xper.org/wiki/xp/
http://97net.isp.st/zboard/xp01.html

관련 사이트
http://extremeprogramming.org/
http://xprogramming.com/
http://objectmentor.com/home
http://www.freemethod.org:8080/bbs/BBSView?boardrowid=3111

관련 책자
Extreme Programming Explained
(Kent Beck 영문)
eXtreme Programming Installed
(Ann Anderson , Chet Hendrickson , Ron Jeffries 한글)
Planning Extreme Programming
(Kent Beck , Martin Fowler 영문)
Extreme Programming Examined
(Giancarlo Succi , Michele Marchesi 영문)
Extreme Programming in Practice
(James Newkirk , Robert C. Martin 영문)
Extreme Programming Explored
(William C. Wake 영문)
Extreme Programming Applied
(Roy Miller , Ken Auer 영문)
Questioning Extreme Programming
(Kent Beck , Pete McBreen 영문)
Extreme Programming Perspectives
(Giancarlo Succi , Michele Marchesi , Laurie Williams , James Donovan Wells 영문)
Extreme Programming for Web Projects
(Doug Wallace , Isobel Raggett , Joel Aufgang 영문)
Testing Extreme Programming
(Lisa Crispin , Tip House 영문)

XP 가치
XP는 소프트웨어 개발자들이 최고로 잘 해야하는 것(코드 작성)을 할 수 있도록 하는 가치와 방법을 처방해준다. XP는 개발 인력들을 지치게 하는 모든 불필요한 것을 제거한다:

• 의사소통: 프로젝트와 관련한 문제들은 누군가에 의해 트레이스 될 수 있다.
  
  
• 단순함: XP는 프로세스와 코드 작성과 관련된 작업을 할 수 있는 가장 간단한 것을 수행할 수 있다고 장담한다.
  
  
• 피드백: 고객, 팀, 실제 엔드유저로 부터의 즉각적인 피드백은 자신의 노력을 조정할 더 많을 기회를 제공한다. 수렁에서 건질 수도 있다.
  
  
• 용기: 용기는 다른 세 개의 가치의 정황에서 존재한다. 그들 모두는 서로를 지원해준다. 언제나 구체적인 피드백이 모든 것을 알고 있는 것보다 낫다고 신뢰하기 위해서는 용기가 필요하다. 팀내의 다른 사람들에게 무지함을 노출시킬 때도 용기가 필요하다. 시스템을 단순하게 유지하는데에도 용기가 필요하다. 그리고 단순한 시스템, 지속적인 커뮤니케이션, 피드백 없이 용감해 질 수 없다.

Joint practice: 하나의 팀 만들기
이 그룹의 방법들은 모두에게 적용된다. 팀의 모든 사람들(프로그래머, 고객, 관리자)은 이러한 것을을 언제나 수행해야 한다. 이들은 하위 팀들도 함께 모아 하나의 팀으로 만들어야 한다.

공통 어휘
팀의 모든 사람들은 시스템에 대한 공통 이해가 필요하다. 해석하는데 오랜 시간이 걸리는 메타포는 필요없다. 모든 사람들이 사용할 수 있는 공유된 어휘를 갖는것에 주력하라.

열린 작업공간 (New)
비형식적 의사소통은 형식적인 것 보다 효과적이다. 작은 방을 가르는 칸막이는 비공식적 의사소통을 더 어렵게 만든다. 가장 좋은 방법은 열린공간이다. 여기에서 사람들은 무엇인가를 주워들을 수 있고 좋은 생각을 내놓을 수 있고 토론도 가능하다. 이러한 종류의 그룹 인터랙션은 놀라운 결과를 만들어 낼 수 있다. 벽을 없애라 .

어떤 사람들은 개방된 작업공간이 XP가 큰 팀에서는 효율적이지 못하다는 것을 의미하는 것으로 생각한다는 것을 들었다. 그들 말이 맞을지도 모른다. 하지만 솔직히 말해서 잘못되었다. 그들은 아마 두 가지를 생각할 것이다. 그들이 큰 팀을 필요로하는데 이들을 지원할 협업 환경이 없다는 것을 가정하는 것이다.

아마 여러분도 큰 팀이 필요할 것이다. 하지만 생각만 그렇게 하는 것인가 아니면 실제로 성장하고 있는가? 아마도 위대한 일을 수행하기에 좋은 환경에서 작업하는 좋은 개발자들 그룹은 큰 팀들 보다 빠르고 더 좋은 일을 할 수 있다.

반복(New)
XP를 채택하는 사람들은 프로젝트의 리듬에 대해 이야기한다. 이 리듬은 다양한 차원으로 존재한다. 하지만 반복은 실제로 중심에 있다. 1주에서 3주 마다 팀은 고객이 요구하는 새로운 기능으로 작업 시스템을 제공한다. 이것은 과격한 생각이다. 사람들은 이러한 방식으로 소프트웨어를 만드는 것에 익숙하지 않다. 대부분의 접근방식은 코드를 작성하기 전에 많은 것들을 수행하는 것에 초점이 가 있다. XP는 코드를 작성하고 사람들이게 이 코드를 사용하게 한다. 그리고 그들의 피드백이 프로젝트를 조정 할 수 있도록 한다.

반복은 일종의 계획으로 시작한다. 나는 이것을 반복 플래닝이라고 부른다. 이 플래닝은 릴리스 플래닝과 닮았다. 하지만 보다 상세하다. 우리는 다음 반복에 대해서만 주의를 기울인다. 고객에게 묻는다. "프로젝트가 다음 반복 뒤에 끝나면 어떤 기능을 얻고싶으십니까? 그때 우리는 그러한 기능을 구현하기위해서 작업을 평가한다. 고객은 우선순위 대로 몰고간다. 프로그래머는 비용을 정한다. 어떤것은 현재의 반복 안에서 떨어져 나가야 함을 의미한다 .

여기에서 timeboxing이란 단어가 중요하다. timeboxing이란 어떤 작업의 시간 제한을 설정하는 습관이다. 해당 시간까지 작업하고 그런다음 평가한다. 이것은 팀이 너무 오래 작업하는 것을 막는다. 반복 습관은 timeboxing 보다 우위 개념이다. 반복은 사람들로 하여금 과감한 결정을 내리도록 요구한다. 고객들은 가장 중요한 기능을 선택하게된다. 프로그래머들은 구현 방법과 노력에 대해 결정을 내린다. 관리부서는 프로젝트의 전략 방향을 정한다.

반추(New)
반추 없는 작업은 실패의 반복만을 초래한다. 팀의 각자가 자신의 작업을 돌아보고 무엇을 배웠는지를 돌아보고 팀의 나머지 사람들과 나누는 것이 좋은 방법이다.

프로젝트에서 배운 교훈에 대해 생각해보자. 잘 한것은 무엇이고 못한 것은 무엇인지 생각해보라. 팀이 어떻게 일을 수행했는지를 생각해보고 팀이 종합적으로 무엇을 생산했는지를 생각해보라. 일이 더 나아질 수 있겠는가? 왜 그런가? 어떻게 하면 더 나아질 수 있는가? 지금 하고 있는 것을 보다 잘 하기 위해 무엇을 해야 하는가? 어떻게 해야하는가? 이런 종류의 종합적 리뷰는 하나의 릴리스 후에 발생한다. 대체로 매번 반복이 끝날때 이런 일을 수행한다. 긴 시간이 필요없다. 이전 반복에 대해 반추하는 데는 한 두 시간이면 족하다. 지금 상태에서 팀을 보다 낫게 만들면서 가치를 끌어올릴 수 있다. 또한 재미도 함께 가져올 수 있다. 이는 매우 중요하다.

대부분 사람들과 나는 하루 작업 후에 "미니 반추" 시간을 갖는것이 도움이 된다는 것을 알았다. 몇 분 정도가 소요된다. 공유할 만한 것을 배우면 팀과 다음날 나눈다. 이러한 방식으로 많은 것을 얻었다.

반추에는 반드시 몇 가지 용어를 보다 효과적으로 해야 할 필요가 있다. 이에 대한 보상은 보다 통합된 팀이 된다는 것이다. 모든 사람이 이러한 소급 과정에 참여해야 한다. 기술팀과 비 기술팀 모두 참여해야 한다. 한 장소에 모이는 사람들이 너무 많으면 하위 팀들은 자신들의 반추 시간을 갖는 것이 좋다. 중요한 것은 같은 실수를 되풀이 하지 않는 것이다.

Programmer practices

테스트 지향 개발 페어 프로그래밍(Pair programming) 리팩토링 단체 소유권 지속적 통합 YAGNI

테스트 우선 개발
프로그래머가 코드를 변경할 때 마다 그들이 변경한 것이 무언가를 향상시키는 것인지 아니면 어떤 것을 깨트리는 행위인지를 알 필요가 있다. 더 중요한 것은 작업이 수행되는 데 쓰이는 최소한의 코드를 만드는데 필요한 가르침은 유지되어야 한다. 이것이 바로 테스트 우선 개발의 모든 것이다.

XP에는 두 종류의 테스팅이 있다. 단위 테스팅(unit testing)과 인수 테스팅(acceptance testing)이 그것이다. 이들은 전형적인 명칭이지만 나는 별로 좋아하지 않는다. 알아들을 수 없는 말 같다. 나는 Ron Jeffries의 "What is Extreme Programming?" (참고자료)에서 제안한 명칭인 커스터머 테스트(customer test)와 프로그래머 테스트(programmer test)라는 용어를 더 선호한다.

프로그래머는 코드를 작성할 때 프로그래머 테스트를 작성한다. 고객(Customer)은 이야기를 정의한 후에 커스터머 테스트를 작성한다. 프로그래머 테스트는 개발자들에게 시스템이 어는 시점에서 작동할 것인지를 명령한다. 커스트머 테스트의 경우 사용자들이 이 시스템에게 무엇을 바라는지를 팀에게 알려준다. 여기서는 프로그래머 테스트에 대해 이야기 할 것이다.

팀이 자바 같은 객체 지향 언어를 사용한다고 가정하고 개발자들은 깨질 수 있는 모든 가능한 메소드를 위한 프로그래머 테스트를 작성한다. 물론 그 메소드용 코드를 작성하기 전이다. 그런 다음 테스트가 통과될 수 있도록 코드를 작성한다. 가끔씩 사람들은 이것을 이상하게 여기지만 테스트를 먼저 작성하는 것은 다음과 같은 이점이 있다:

• 가장 완벽한 테스트 세트; 코드에 대한 자신감을 증대시킨다.
• 작동할 수 있는 가장 간단한 코드; 이는 나중에 리팩토링하기 쉽다.
• 코드의 의도를 명백히 볼 수 있다; 후에 이해하기 쉽고 리팩토링도 쉬워진다.

개발자들은 모든 프로그래머 테스트가 통과되기 전까지는 소스 코드 리파지토리의 코드를 검사할 수 없다. 프로그래머 테스트는 개발자들에게 그들이 만든 코드가 작동하고 있다는 확신을 심어준다. 이것은 다른 개발자들에게 넘어가 원래 개발자의 의도를 이해할 수 있도록 돕는다. 프로그래머 테스트는 코드 리팩토링도 돕는다. 테스트가 실패하면 개발자들에게 즉시 알려진다. 프로그래머 테스트는 자동화되어야 하며 통과나 실패 결과를 명확히 주어야한다. xUnit 프레임웍(참고자료)은 이러한 일을 잘 수행하며 따라서 대부분의 XP 팀은 이를 사용하고 있다.

프로그래머로서 프로그래머 테스트를 거친 코딩과 그렇지 않은 코딩 사이의 차이를 보고 놀랄 때가 종종 있다. 코드를 작성할 때 지극히 적은 단계를 거친다는 것을 깨닫는다. 사실 그 적은 단계동안 디버깅을 많이 할 필요도 없다. 문제가 있는 소스는 명확하기 때문이다.

페어 프로그래밍
XP에서 쌍을 이룬 개발자들이 모든 제품 코드를 작성한다. 대부분의 개발자들은 다른 사람들과 합심하여 코드를 작성한 경험이 전혀 없고 처음에는 낯설다. 페어 프로그래밍은 두 명의 개발자들이 하나의 컴퓨터를 공유하는 것을 의미한다. 한 명은 코드에 주도권을 갖고("driver") 다른 한명은 그가 길을 찾을 수 있도록 돕는다. ("navigator" 또는 "partner"). driver가 혼란스러워하거나 navigator가 좋은 생각을 갖고 있다면 현재의 driver는 제어권을 포기하고 navigator가 잠시동안 그 역할을 맡는다. 각자는 역할을 수시로 바꿔야한다. 이러한 역할에 익숙해지면 역할 변동은 보다 자유롭게 일어난다.

이러한 접근방식이 비효율적으로 비춰질 수도 있다. 이럴 때면 나는 Martin Fowler의 대답을 떠올린다. "페어 프로그래밍이 생산성을 떨어트린다라고 사람들이 말할 때 저는 대답합니다. 프로그래밍의 대부분이 타이핑에 소모된다면 그 말은 사실이라고." 시실 페어 프로그래밍은 더 만은 혜택을 준다:

• 모든 디자인 결정에 적어도 두 개의 두뇌가 투입된다.
• 적어도 두 명이 시스템의 모든 부분에 익숙하다.
• 두 명 모두 테스트나 다른 태스크를 게을리할 경우가 거의 없다.
• 쌍을 바꾸면 팀간 지식이 확산된다.
• 코드는 적어도 한 사람에 의해 언제나 리뷰된다.

코드 리뷰는 코드 품질을 증대시킨다는 경험적 연구결과가 있지만 나는 이런 것이 싫다. 또한 정확하게 이를 수행하는 것이 매우 어렵다는 것도 확신한다. 그리고 페어 프로그래밍 만큼 효과적이지도 않다.

The Costs and Benefits of Pair Programming (참고자료) 에서는 쌍을 이루어서 하는 프로그래밍이 프로그래밍 보다 더 효율적임을 나타내고 있다.

리스크의 경우 프로젝트가 실패한 원인에 대해 잠시 생각해보자. 큰 이유 중 하나는 한 명의 영웅에 지나치게 의존하는데 있다. 만일 당신의 프로젝트의 영웅께서 순간적 사고로 숨진다면 프로젝트는 어떻게 될 것인가? 쌍을 이루는 것의 본질은 지식을 곳곳에 퍼트리는 것이다. 또한 자주 변화해야 한다. 지나치게 굳어져있으면 멈춰버린다.

페어 프로그래밍에 대해 여러가지 장점을 얘기했음에도 불구하고 대부분의 개발자들은 이러한 생각을 싫어한다. 이는 자부심의 문제이다. 대부분의 개발자들은 영웅이 되기 원한다.

다른 사람들을 사랑할 때 그들의 장점이 보이며 그들의 성장을 도울 수 있다. 오래 참고, 친절하며 시기하지 않고 관대하며 겸손하고 무례히 행치 않아야 한다. 이러한 친밀한 상호 관계는 대부분의 사람들이 흥미있어하는 것이 아니며 개발자들은 사람이다. (따라서.. ) 이것은 급진적 생각이고 모든 사람들에게 적용될 수는 없다. 하지만 이를 실천했을때 그 보상 역시 크다.

리팩토링
리팩토링은 기능을 변경하지 않고 코드를 향상시킬 수 있는 기술이다. XP 팀은 무자비하게 리팩토링을 한다. 개발자들이 리팩토링 할 수 있는 두 번의 핵심 기회가 존재한다. 기능 구현의 전과 후 이다. 개발자들은 기존 코드를 변경하는 것이 새로운 기능을 더 쉽게 구현할 수 있도록 돕는지의 여부를 결정해야 한다. 예를 들어 추상화의 기회를 보게된다면 구체적 구현에서 중복 코드를 제거하기 위해 리팩토링을 한다. 여기서 중요한 것은 새로운 코드를 디자인하고 작성하거나 기존 코드를 리팩토링 해야한다는 것이다. 그 두 작업을 한번에 시도하지 말라.

XP는 작동 가능한 가장 간단한 코드를 작성하는 것에 중점을 두고 언제나 배울 것을 강요하고 있다. 리팩토링은 배운 것과 코드를 결합할 수 있도록 한다. 이로서 코드는 깨끗하게 유지된다. 오랫동안 생존할 수 있으며 문제는 적어진다.

리팩토링의 요지는 기존 코드의 디자인을 향상시키는 것이다. 팀은 프로그래머 테스트 슈트와 커스터머 테스트 슈트를 자동화 해야한다. 전자는 언제나 통과해야 하며 후자는 고객이 요구하는 수준까지 통과하면 된다. 테스트를 실행하라. 코드를 리팩토링하라. 프로그래머 테스트가 잘못되었는가? 문제를 해결하라. 고객의 요구가 있는가? 문제를 해결하라. 테스트 없이 코드를 변경하는 것은 억측 게임과도 같다.

집합적 소유권 (Collective ownership)
팀의 누구라도 코드를 개선하기 위해 변경할 권한을 가져야 한다. 누구나 모든 코드를 소유한다는 것은 다시말하면 책임도 져야한다는 것을 의미한다.

누구나 코드를 소유한다는 것이 어떤 누구도 코드를 소유하지 않는 것과 같은 것은 아니다. 아무도 코드를 소유하지 않으면 원하는 어디엔가 코드를 유출시키고 어떤 책임도 지지 않는다. XP는 "당신이 망쳤으면, 당신이 픽스하라."고 요구한다.

지속적 통합
새로운 변화를 매번 시스템에 통합시키고 전체를 자동으로 재구현하라. 모든 테스트가 실행될 때까지 변화를 누설하지 말라. 테스트가 실패하면 두 개의 선택이 있다. 고치고 통합하는 것과 통합하지 않는 것. 고칠 수 없는 실패한 테스트는 통합해서는 안된다.

지속적 통합이라고 해서 수시로 통합하는 것을 의미하는 것은 아니다. 더 빨리 자주 통합하라는 의미이다. 매일은 부족하다. 많은 사람들이 이 말을 듣고 경악하겠지만 테스트가 이러한 공포를 날려보낼 것이다.

YAGNI("You aren't going to need it"; 더 이상 이것이 필요하지 않을 것이다)
"XP distilled" 칼럼에서 Chris Collins와 나는 "XP의 반대자들이 프로세스가 디자인을 무시한다고 주장하고 있다는 것을 밝힌 바 있다.

반대 의사가 시사하는 바는 사람들은 이러한 신생의 디자인에 편안함을 느끼지 않는다는 것이다. 방향을 설정하고 이정표를 마련한 다음 여행을 시작하는 것이다. 이러한 접근 방식을 싫어하는 사람들은 이러한 방식이 다듬어 지지 않은 방식이라고 간주한다. 실제로 이는 현실적인 접근 방식인데 말이다.

전형적인 방식은 수평의 정적 그림을 가져다가 그곳에 도달 할 완벽한 지도를 그리려는 것과 같다. 요구사항이 항상 같다면 이것은 좋은 접근 방식이다. 실제로는 대부분의 개발자들은 전에 한번도 풀지 못한 문제를 경험하게 되고 전에 한번도 시도하지 못한 솔루션을 구현하고 있다. 오늘날 대부분의 시스템은 끊임 없이 변화하는 시장에서 경쟁 할 용도로 디자인되고 있다.

이와 같이 요구 사항이 매 시간 변하는 상황에서 요구 사항이 일정하리라는 보장이 없다. 큰, 업프론트 디자인이 부적절하다. 최선의 방법은 일반적인 방향을 설정한 다음 작게 만들고 수시로 조정하는 것이다. XP는 모든 과정에서 단순함을 요구한다. 필요할 때 마다 방향을 바꿀 수 있도록 하기 위해서이다.

Kent Beck에 따르면 작동이 가능한 가장 간단한 디자인은 다음과 같은 것이다:

• 모든 테스트를 실행한다.
• 중복 코드를 포함하지 않는다.
• 모든 코드에 대한 프로그래머의 의도를 명확히 언급한다.
• 최소한의 클래스와 메소드를 포함한다.

단순한 디자인을 요구한다고 해서 모든 디자인이 작거나 간단해야 하는 것을 의미하는 것은 아니다. 가능한 단순한 상태를 유지해서 작동하게 하는 것이다. 사용하지도 않는 과잉의 기능을 추가하지 말라. 우리는 그와 같은 것을 YAGNI라고 부른다. 이는 '더 이상 이것이 필요하지 않을 것이다'라는 의미이다. 다시 말해서 필요할 것 같은 것을 설계하지 말라는 의미이다. 다음 통합 때 이를 깨닫게 될 것이다. 대신 테스트를 작성하고 테스트가 통과 할 수 있는 코드를 만드는 것이다.

-----------------------------------------------------------------------------


 성공을 준비하라. 성공에서 한 발짝 뒤로 물러나 자신을 보호하지 말라. 최선을 다한 다음 결과에 대처하라. 이것이 극단(extreme)이다. 자신을 노출하라. 어떤 사람들에게는 이렇게 하는 것이 믿을 수 없을 만큼 두려운 일이겠지만, 다른 사람들에게는 그저 일상일 뿐이다. 바로 이것이 사람들이 XP에 그렇게 극단적으로 갈리는 반응을 보이는 이유다.
                                                                                                (P. 24)

• XP는 오래되고 효과가 없는 사회적 습관들을 버리고 효과 있는 새로운 습관들을 채택하는 것이다.
• XP는 오늘 내가 기울인 모든 노력에 대해 자신을 인정해 주는 것이다.
• XP는 내일은 좀 더 잘해보려고 애쓰는 것이다.
• XP는 팀 전체가 공유하는 목표에 내가 얼마나 기여했는지를 잣대로 자신을 평가하는 것이다.
• XP는 소프트웨어 개발을 하는 중에도 여러분의 인간적 욕구 가운데 일부를 채우겠다고 요구하는 것이다.

이것이 XP의 패러다임이다. 깨어 있고 적응하며 변하는 것.
소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다.
                                                                                               (p. 36)


가치를 명시하는 일이 중요한 까닭은, 가치가 없이는 실천이 금세 기계적인 활동, 아무런 목적이나 방향도 없이 그냥 그렇게 하라니까 하는 것이 되어 버리기 때문이다.
                                                                                              (p. 38)


문제는 자네가 모르는 것 때문에 생기는 게 아냐. 잘못 아는 데서 생기지.
                                                                      - 윌 로저스 -     (p. 43)


  소프트웨어 개발에서는 '완벽하다'는 없고 '완벽해지도록 노력한다'만 있다. 완벽한 프로세스는 없다. 완벽한 설계도 없다. 완벽한 스토리도 없다. 하지만 프로세스나 설계, 스토리를 완벽하게 만들려고 노력하는 것은 가능하다.
  '최선은 차선의 적' 이라는 말은 완벽을 기다리는 것보다는 평범한 것이라도 있는게 낫다는 뜻이다. 이 표현은 XP의 요점을 놓치고 있다. XP란 개선을 통해 탁월한 소프트웨어 개발에 도달하는 것이다.
                                                                                            (p. 58)


변화는 깨달음과 함께 시작된다. 변화가 필요하다는 깨달음은 감정, 본능, 사실, 외부자의 피드백에서 나온다.
변화가 필요함을 깨달았다면, 변화를 시작할 수 있다.
                                                                                           (p. 99)


언제나 변화는 가까운 곳부터 시작한다. 여러분이 실제로 변화시킬 수 있는 사람은 여러분 자신뿐이다.
                                                                                           (p. 100)