[Day 18] 소프트웨어 장인 - 08

1부 이념과 태도

1장 21세기의 소프트웨어 개발
2장 애자일
3장 소프트웨어 장인정신
4장 소프트웨어 장인의 태도
5장 영웅, 선의 그리고 프로페셔널리즘
6장 동작하는 소프트웨어
7장 기술적 실행 관례
8장 길고 긴 여정

2부 완전한 전환

9장 인재 채용
10장 소프트웨어 장인 면접하기
11장 잘못된 면접 방식
12장 낮은 사기의 대가
13장 배움의 문화
14장 기술적 변화의 실행
15장 실용주의 장인정신
16장 소프트웨어 장인으로서의 커리어
부록 소프트웨어 장인정신에 대한 오해와 설명

---

 

Chap 15. 실용주의 장인정신

• 좋은 품질은 그렇게 되기까지 오랜 시간이 걸린다는 고정 관념이 있다. 관리자와 개발자들 모두 품질과 비용은 양립할 수 없는, 둘 중 하나를 선택해야만 하는 문제라고 생각한다.
• 품질은 선택사항이 아니다.
  • 가장 근본적인 문제는 싸고 그저 그런 코드로도 충분하다는 매우 잘못된 가정을 할 때가 많다는 것이다. 보통 품질의 코드를 목표로 하는 회사들은 형편없는 코드를 결과물로 내놓는 경우가 대부분이다.
  • 고객들은 돈을 지불한 그 이상의 가치가 제공되기를 당연시할 것이다.
  • 많은 비용이 들어도 품질을 높여야 하는 경우도 있고 품질이 낮더라도 비용을 적게 들여야 하는 경우도 있을 수 있다.
  • 어떤 결정을 하든지 간에, 심지어 저품질을 선택해야 하는 경우에서도 항상 품질이 좋기를 희망한다. 그 어떤 경우에도 비용을 지불한 서비스의 결과물에 문제가 발생하는 일은 좋아하지 않는다.
  • 하지만 고품질이 고비용을 요구하지 않는다면 어떻게 될까? 저품질의 서비스와 고품질의 서비스 간에 비용과 소요기간의 차이가 매우 작다면 어떻게 될까? 그때도 저품질의 서비스를 선택할까? 전혀 그렇지 않을 것이다.
• 좋은 품질은 비싸고 시간이 오래 걸릴까
  • 소프트웨어 장인은 익스트림 프로그래밍(XP)의 실행 관례와 애자일 원칙을 습관화하고 있다.
  • 소프트웨어 장인이 개발 및 진행 중인 프로젝트라면 첫날부터 동작하는 소프트웨어가 고객에게 전달된다.
  • 기능 구현을 완료했다는 의미는 그 기능이 상용 시스템이나 상용 시스템과 비슷한 내부 검증 환경에(아직 소프트웨어를 공개 배포할 수 없는 경우) 전개되었다는 의미다.
  • 소프트웨어 장인은 지속적인 통합과 프로젝트 초기부터의 제품 딜리버리를 목표로 하기 때문에 소프트웨어 품질로 인해 상용 릴리즈가 지연되는 일은 가정에 없는 사항이다.
  • 소프트웨어 장인은 테스트 주도 개발과 같은 실행 관례들을 마스터하고 있어서 실행 관례의 준수로 인해 업무 속도가 늦어진다는 것은 있을 수 없는 일이다.
  • 어떤 코드이든 몇 줄이 넘어가는 복잡도를 가졌다면 소프트웨어 장인은 테스트 코드를 함께 작성하며, 다른 보통의 개발자가 테스트 코드 작성 없이 작업하는 것보다 더 느려지지 않는다.
  • 큰 애플리케이션의 복잡한 테스트라 하더라도 소프트웨어 장인이 작성한 자동화 테스트는 몇 초 안에, 늦어도 몇 분 안에 완료된다.
  • 무엇이든지 새로운 것을 배울 때는 시간이 걸리는 점이 문제다. 새로운 실행 관례를 도입한다는 것은 기존의 익숙하던 일하는 방식을 벗어나야 한다는 것을 의미한다.
  • 애플리케이션의 크기가 크면 XP 실행 관례를 몸에 익힌 소프트웨어 장인이 XP 실행 관례를 전혀 수용하지 않은 보통의 개발자보다 훨씬 더 빨리 작업을 완료한다.
  • 어떤 실행 관례를 배우고 마스터하는 데는 시간이 필요하다. 배우는데 시간이 든다고 해서 그 실행 관례가 나쁘다고 할 수는 없다.
  • 실행 관례를 무시하는 대신 경험 많은 소프트웨어 장인을 더 많이 확보하여 팀 구성원들의 학습 곡선을 당기고 멘토링하는 데 관심을 기울여야 한다.
  • 테스트 주도 개발이 항상 필요할까
    • 도구나 실행 관롈르 선택할 때는 실제로 처한 맥락을 반드시 고려해야 한다. 실행 관례에 의문을 표하는 사람들은 그들이 뒤에 남길 골칫덩이에 대해서는 인지하지 못하고 당장 뭔가를 만들어 내는 것에만 집중한다.
    • 유능한 개발자라면 TDD 때문에 개발 일정이 지연되지 않는다.
    • TDD 에 능숙한 개발자들은 TDD 때문에 개발이 지연되었다거나 시간이 없어서 테스트를 작성하지 못했다는 변명은 절대 하지 않는다. TDD 등 XP 실행 관례를 전파하고 싶다면 먼저 스스로 충분히 능숙해져야 한다.
• 리팩토링
  • 리팩토링을 위한 리팩토링은 시간 낭비다.
  • 레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래보다 깨끗하게 만들어 놓아야 한다. 새로운 기능을 추가할 때마다 코드를 분석하고 필요한 경우 리팩토링을 하여 레거시 코드가 새로운 기능을 자연스럽게 받아들일 수 있도록 해야 한다.
  • 레거시 코드는 새 기능을 받아들일 준비가 되어 있는가? 수정해야 할 코드량은 어느 정도 되는가? 이 두 질문에 대한 답이 '아니오'와 '아주 많이'라면 먼저 레거시 코드를 리팩토링하여 새로운 기능을 받아들이기 쉬운 상태로 만들어야 한다.
  • 분명한 필요에 의해 시스템을 변경하고, 그 와중에 작은 리팩토링을 꾸준히 하는 것이 실용적인 관점에서 바람직한 애플리케이션 개선 방법이다.
• 소프트웨어 개발 방법의 한 가지 예
  • 소프트웨어 장인정신 운동의 가장 큰 목적은 소프트웨어 개발이라는 업의 수준을 기술적, 사회적으로 높이는 것이다.
  • 장인이라면, TDD 와 같은 XP 실행 관례들을 절대 불변의 진리라고 믿어서는 안 된다. 지금 당장 우리가 XP 를 추구한다고 해서 더 나은 다른 방법을 찾아 보는 것을 멈춰서는 안 된다.
• 비즈니스 돕기
  • 진정으로 원하는 바가 무엇인지 비즈니스 담당자 스스로도 잘 모르는 프로젝트들을 흔하게 볼 수 있다.
  • 가장 좋은 방법은 뭐든 최대한 빨리 만들어서 이들 앞에 내놓는 것이었다. 비즈니스 담당이 마음을 바꾸는 것과 거의 같은 속도로 코드를 바꿀 수 있어야 했다.
  • 단순하고 빠른 솔루션
    • '빨리 만들었다는 것이 엉망이다'라는 것이어서는 안 된다.
    • 문제는 비즈니스 담당과 사용자 모두 구체적인 수준에서 뭐가 어떻게 되어야 하는지 제대로 알지 못한다는 점이었다.
    • 비즈니스 담당들은 전체적인 관점에서 모든 기능들이 잘 엮어서 의미에 맞게 동작하는지를 빨리 보고 싶어 했다. 우리는 더 빠른 솔루션을 제안했다. 전체를 아우르는 모든 기능들 각각에 대해 웹 페이지들을 전부 구현하되 가상의 내장된 샘플 데이터를 통해 값이 어떻게 보일지만 시험해 볼 수 있고 실제 데이터 연동은 안 되는 방식이었다. 이러한 접근 방법을 통해 기능적 애플리케이션을 상당히 빨리 만들어서 하루에도 몇 번씩 새 버전을 전개하여 사용자 인수 시험(UAT) 환경에 넣을 수 있었다.
    • 전체 애플리케이션을 테스트 기반으로 개발했다. 일이 너무 바쁘다는 이유로 실행 관례를 포기하지는 않았다. 우리 모두 TDD 에 매우 익숙했고 코드 타이핑이 업무의 병목점이 아니었으므로 TDD 때문에 지연되는 일은 없었다. 반대로 매우 짧은 시간에 많은 변경들을 해 나가야 했기 때문에 TDD 는 전체적인 작업 속도를 높여주었다.
    • 요구사항과 기능의 복잡도 때문에 작업이 느려지는 경우는 있었지만 단위 테스트때문에 작업이 느려진 적은 한 번도 없었다. 오히려 테스트 덕분에 더 자주, 더 빨리 릴리즈 할 수 있었다.
    • 여기서의 요점은 개발팀 차원에서 비즈니스를 도울 방법을 찾아서 실행했다는 점이다. 다른 부작용 없이 최대한 빨리 코드를 수정할 수 있는 방법을 고안하고 실행하였다.
    • 소프트웨어 프로젝트에서 예측 못한 변경의 양 자체는 문제가 아니다. 문제는 그러한 변화를 따라갈 수 있는 역량의 부족이다. 잘 작성된 소프트웨어는 고객에게 가치를 제공하기 위한 수단이다.
• 소프트웨어 프로젝트는 우리를 위한 것이 아니다
  • 프로페셔널로써, 소프트웨어 프로젝트가 개발자를 위한 것이 아니라는 사실을 이해할 필요가 있다. 어떤 개발자들이 프로젝트에 추가하는 가치들이, 바로 그 개발자들의 참여를 조건부로 한다면 그것은 가치가 아니다. 그것은 실패 요인이다.
• 비범함과 평범함
  • 그 어떤 바보 같은 개발자도 뭔가를 동작하게 만들 수는 있다. 비범한 개발자와 평범한 개발자를 가르는 기준은 어떤 방식으로 그것을 동작하게 만드느냐이다. 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다. 문제를 단순하고 우아한 방법으로 해결하는 것은 복잡하고 과잉된 방법으로 해결하기보다 훨씬 더 어렵다.
  • 비범한 개발자들은 심지어 단순하고 짧은 솔루션 이상의 것을 추구한다. 그들은 코드 한 줄도 짜지 않고 문제를 해결할 방법을 찾는다. 가장 훌륭한 코드는 작성할 필요가 없는 코드다.
• 단순한 설계를 위한 네 가지 원칙
  • 모든 테스트를 통과해야 한다
  • 명료하고, 충분히 표현되고, 일관되어야 한다 : 명료성의 최대화
  • 동작이나 설정에 중복이 있어서는 안 된다 : 중복의 최소화
  • 메서드, 클래스, 모듈의 수는 가능한 적어야 한다 : 구성 요소의 최소화
  • 나는 중복 제거보다는 명료함을 항상 우선시한다. 단순한 설계를 위한 가이드 라인으로 좋은 네이밍과 비즈니스 콘셉트를 잘 투영한 추상화에 집중한다. 그 다음에 중복을 제거하면서 코드의 응집성과 독립성을 높인다. 중복을 제거하다 보면 새로운 구조가 떠오르고 다시 명료성을 높인다. 다시 중복을 없앤다. 이러한 사이클을 매우 짧은 반복 주기로 작업이 완료될 때까지 계속한다.
  • 디자인 패턴
    • 범용 코드는 물론 좋다. 하지만 공짜가 아니다. 코드가 범용화될수록 더 복잡해진다. 
  • 패턴을 위한 리팩토링
    • TDD 에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다. 테스트 코드는 비즈니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것은 아니다. 코드는 테스트 통과에 꼭 필요한 만큼만 작성된다.
    • 당장의 합당한 이유 없이 단지 '미래를 대비해야 한다'는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션이 엉망이 된다. 미래에 어느 부분에서 수정이 필요할지 모르기 때문에 모든 부분에서 추상화(복잡도 증대)를 적용해버린다.
    • 실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화를 도입하는 것이다. 그렇게 하면 전체적인 복잡도를 낮추는 데 도움이 된다. 당연하지만 복잡도가 낮은 시스템이 높은 시스템보다 유지보수 비용이 낮다.
    • 패턴이 먼저가 아니다. 문제에 적합한 리팩토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다.
• 장인 정신과 실용주의
  • 실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다.
  • 프로젝트의 크기나 복잡도가 어떻든 간에, 소프트웨어 장인은 항상 높은 품질의 코드를 생산해 낸다.
• 품질은 비싼 것이 아니다. 스킬 부족이 잘 작성된 코드를 비싼 것으로 만드는 원인이다. TDD 가 개발자를 느리게 만들지는 않는다. 타이핑 자체가 병목점인 경우는 없다.
• 관리자나 제품 오너가 어떻게 이야기하든지 항상 높은 품질을 전제하고 요구한다. 시간이나 비용과 같은 대가가 따르지 않는다면 항상 높은 품질을 선택한다.
• 장인과 함께 일하는 고객이라면 품질에 대해서는 걱정을 하지 않아야 한다.

---

이 장에서 내가 깨달은 것

• 가치를 제공할 수 있다면, 그것이 내가 바란 가치가 아니더라도 도울 의무가 있다.
• 성장하려는 마인드셋으로 계속 배워나가야, 요구하는 퍼포먼스를 채울 수 있다.

---

Chap 16. 소프트웨어 장인으로서의 커리어

• 어떻게 우리의 일을 자랑스럽게 생각하지 않을 수 있을까? 어떻게 우리의 일을 그저 출퇴근하는 생계수단으로만 치부할 수 있나? 이토록 중요한 일을, 어떤 때는 생명에 영향을 미치는 그런 일을, 어떻게 소중히 여기지 않을 수 있나? 소프트웨어 개발자들은 우리가 살고 있는 세상이 진화해 나가는 데 꼭 필요한 존재다.
• 장인의 길
  • 열정. 이 단어 하나가 모든 것을 요약한다. 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 열정적이다. 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다. 그들의 코드를 공유하고, 초보 개발자들을 멘토링하고, 블로그/책/동용상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다. 기술 커뮤니티 활동에도 열정적이다. 뿐만 아니라 소프트웨어 장인은 겸손하다. 항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다.
  • 다음 세대의 장인을 키우는 데 사회적 윤리적 의무감을 느껴야 한다. 그렇게 함으로써 소프트웨어 산업을 더욱 성숙하고 프로페셔널해지도록 만들어야 한다.
  • 장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다.
  • 장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 최선이라고 알려진 몇몇 조합들에 대해서는 완전하게 마스터하고 있어야 한다. 마스터한 도구들이 없다면 장인이라고 할 수 없다.
  • 진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. 코드를 짤 때는 높은 품질의 코드를 작성하는 데 집중한다. 테스트 가능하고 쉽게 이해할 수 있으며 수월하게 유지보수할 수 있는 코드를 작성하는 데 집중한다.
  • 장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다. 장인은 긍정적인 일들로 연상되는 존재여야 한다. 통찰력 있는 기여, 열정, 지식, 훌륭한 동료로서 인정받는다면 더할나위 없다.
  • 정직과 용기
    • 정직과 용기는 소프트웨어 장인이 갖추어야 할 핵심적인 자질이다. 여기서 말하는 정직과 용기란 필요한 상황에서 고객에게 '아니오'라고 말할 수 있는 것을 의미한다. 고객이 비현실적인 요구를 할 때 고객과의 껄끄러운 상황이 발생할 것을 알면서도 그 요구가 제대로 반영되기 힘들다라고 전달하는 것이다. 즉 고객이 나쁜 의사결정을 할 떄 그것이 적절치 못하다고 지적하는 정직함과 용기를 말한다. 장인은 스스로 판단하기에 무언가 올바르지 않은 결정을 그대로 추진하거나 책임지지는 않을 것이라는 점을 고객에게 분명히 밝힌다.
    • 모든 '아니오'에는 항상 대안을 제시해야 한다.
    • 장인의 커리어는 정직과 용기 위에 세워진다. 장인은 고객에게 무언가를 숨기지 않는다. 장인과 고객의 동반자 관계는 정직과 용기, 완전한 투명성에 의해서 이루어진다.
• 커리어의 진전
  • "당신의 커리어 목표는 무엇입니까? 몇 년 안에 어떤 위치에 있기를 바랍니까?" 라고 물었다. 계속해서 개발자이고 싶다라고 대답하는 사람은 없었다. 나는 "왜 개발자는 안 됩니까?" 라고 반문했다. "서른이 넘어서도 아직 개발을 하고 있다면 낙오자로 취급받을 겁니다." 긴 침묵이 이어지고 누군가 큰 목소리로 이야기했다. "저는 서른 다섯입니다. 저는 낙오자인 것이 매우 자랑스럽습니다."
  • 오늘날 회사들은 사실상 소프트웨어 회사다. 그 점을 이해하지 못하는 회사는 미래에 경쟁력을 가지는 데 어려움을 겪게 될 것이다. 개발자들을 고급 기술을 가진 프로페셔널로 인지하지 못하는 회사들은 그들을 위해 일할 장인을 구할 수 없을 것이다.
  • 다른 커리어 사다리
    • 훌륭한 관리자나 아키텍트가 되는 데 필요한 스킬과 훌륭한 개발자가 되기 위한 스킬이 꼭 서로 같을수는 없다. 관리자나 아키텍트가 되는 개발자는 소프트웨어 개발 직능의 사다리를 오른 것이 아니라 사다리 자체를 바꾼 것이다.
• 여정과 이정표
  • 회사 안에서의 커리어와 소프트웨어 장인으로서의 커리어에는 매우 큰 차이가 있다. 성공한 소프트웨어 장인은 스스로의 커리어를 매우 신중하게 계획한다. 무언가를 배우고 더 나은 프로페셔널이 되기 위한 기회들을 찾는다.
  • 직장은 급여 이상의 의미가 있다. 직장은 그들의 커리어를 위한 지속적인 투자다.
  • 우리의 열정과 헌신 그리고 업무 외 개인 시간을 들여 확보한 지식들을 투자하여 일터를 더 나은 곳으로 만든다. 일터를 더 나은 곳으로 만드는 데 투자한다는 의미는 우리의 커리어를 더욱 풍요롭게 할 수 있는 기회를 늘린다는 것과 같다.
  • 나는 항상 더 많은 것을 제공하고 더 많은 일을 수행해서 내 주변의 모두가 더 나아지도록 노력했다. 이런 것들은 나의 투자라고 생각한다. 내 일을 위한 투자일 뿐만 아니라 개인의 커리어를 위한 투자이기도 하다. 기대하는 이익의 종류는 나의 개인적인 또는 업무적인 삶의 변화에 따라 매번 달라진다. 여기서 금전적인 이익은 우선순위에서 높지 않다.
  • 커리어 전반에 걸쳐, 항상 신중하게 다음 직장을 찾았다. 내가 일하고 싶은 회사의 형태가 어떠해야 하는지 항상 생각했다. 내가 겪어온 모든 업무들은 나의 커리어를 진전시키는 데 도움이 됐다. 각각의 업무들은 나의 커리어가 놓인 긴 사다리의 계단이었고 프로가 되기 위한 여정이었다. 이러한 괒어을 '이력서 스펙 채우기'와 혼동해서는 안 된다. 그것은 회사의 업무를 하면서 그 업무에 맞지도 않은 기술을 자신의 이력서를 채우기 우한 목적으로 억지로 적용하는 것들을 말한다. 그러한 행동은 잘못되었을 뿐만 아니라 프로페셔널하지도 않다.
  • 커리어 만들어 나가기
    • 일을 선택하기 전에 스스로에게 하는 질문들
      • 나의 커리어로부터 나는 무엇을 원하는가?
      • 그것을 성취하기 위한 다음 단계는 무엇인가?
      • 이 일은 나의 커리어 방향과 합치하는가?
      • 내가 이 회사에 줄 수 있는 가치의 양은 어람나 되는가?
      • 그러한 투자에 대한 이익은 무엇인가?
      • 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?
      • 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?
      • 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?
      • 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?
    • 무엇이든 변한다. 무엇인가가 바뀌면 나는 회사에 이야기를 했고 회사는 회사가 할 수 있는 범위 안에서 내가 원하는 것을 최대한 주려 했다. 그럼에도 불구하고 내가 찾고 있는 것을 줄 수 없을 때가 있다. 반대로 내가 커리어에 대해 고민하는 와중에 내가 회사에 더 기여할 무언가가 없을 때도 있다. 한 두 가지 예외를 제외하고는 모두 훌륭한 회사였다. 하지만 어떤 시점에서는 서로 다른 길을 갈 수 밖에 없다.
    • 일을 선택하는 것은 매우 신중해야 한다. 재직하는 기간은 회사마다 매우 크게 다를 수 있다. 나는 개인의 커리어 열망과 방향이 합치하는 한 그 회사에 가능한 오랫동안 머무르길 권한다.
    • 앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면, 그때는 움직여야만 한다. 원하는 커리어 방향에 더 적합한 길을 찾아나서는 것은 자신은 물론 회사에도 도움이 된다.
  • 원하는 바를 모른다면 어떻게 해야할까
    • 내가 무엇을 원하는지, 어디로 가기를 원하는지, 다음에 무엇을 했으면 하는지 항상 알고 있을수는 없다. 그런 상황에 빠졌을 때 할 수 있는 것은 한 가지 밖에 없다. 마음을 열고 사람들을 만나는 것이다. 껍질을 벗고 뛰쳐 나와 할 수 있는 한 최대한 많은 문들을 열어 보아야 한다. 그렇게 하면 당신이 모르던 큰 세상이 있음을 알게 될 것이다. 이렇게 하다보면 당신이 어디로 가고 싶어 하는지 감이 잡힐 것이다.
• 다양성
• 소프트웨어 개발은 다양성이 상당히 높은 전문 분야다. 성공적인 장인이라면 넓은 방면으로 다양한 경험이 있다.
• 여러 종류의 프로젝트에서 일해보는 것은 미래의 장인을 준비시키는 것과도 같다. 다양한 종류를 경험하면 다재다능하고 경험 많은 프로페셔널로 성장할 수 있을 뿐만 아니라 미래에 전혀 생각지도 못했던 커리어 선택지를 가질수도 있게 된다.
• 소프트웨어 장인의 사명
  • 소프트웨어 장인은 자신만의 사명이 있다. 더 나아지는 데 집중하고, 계속해서 자신의 커리어에 투자하며, 배우고, 가르치고, 공유한다. 그가 맡은 고객에게 항상 가치를 전달할 수 있도록 해야한다. 고객을 위한 가치 창출은 사명의 일부일 뿐이다. 진정한 사명은 프로페셔널리즘, 열정, 관심으로 소프트웨어 산업의 수준을 높이는 것이다. 최종적인 목표는 전 세계적으로 소프트웨어 프로젝트들의 품질과 성공 비율을 오늘날보다 높아지도록 하는 것이다.
  • 소프트웨어 장인은 삶의 철학이다. 탁월함에 헌신하고, 탁월함의 추구를 본성처럼 만든다. 우리 사회의 진화를 이끄는 일에 무한한 자부심을 갖는다.

---

Appendix A. 소프트웨어 장인정신에 대한 오해와 설명

• 소프트웨어 장인과 소프트웨어 개발자
  • 모든 장인은 개발자이지만 모든 개발자가 장인은 아니다. 보통의 개발자와 장인의 차이점은 스스로의 직업을 대하는 태도에 있다. 누구든 자기 자신을 장인이라고 부를 수는 있지만 그것만으로 장인이 되었다고 할 수는 없다. 특정한 가치를 말하는 것과 그것을 항상 실천하는 것은 완전히 별개의 이슈다. 추구하는 가치는 말이 아니라 행동에 의해 규정된다.
  • 누군가가 스스로를 장인이라고 부른다면 그가 추구하는 가치와 프로페셔널한 태도를 지칭하는 것이지 능력을 지칭하는 것이 아니다. 반대로 누군가가 스스로를 장인이라 하지 않는다고 해서 그가 장인이 추구하는 가치와 태도를 가지지 않았다는 의미도 아니다.
• 장인정신 != 엘리트주의
• 견습생, 숙련공, 마스터
• 마스터 장인
  • 그 누구도 스스로 마스터라고 말하지 않는다. 어떤 프로페셔널들은 다른 프로페셔널을 특정 분야에 있어 마스터라고 부르기도 한다.
• 근시안적 개념으로 보는 시선
  • 소프트웨어 장인정신은 TDD 나 잘 작성된 코드 이상의 것을 의미한다. 린, 애자일, 장인정신은 서로 충돌 없이 같은 방향을 보고 있고 비슷한 가치를 공유하고 있다.
• 장인정신과 XP
  • 장인정신은 이데올로기이고 XP 는 방법론이다. 이데올로기는 가치, 태도, 행동 양식을 다루고 방법론은 실행 관례와 특정 문제의 해결을 다룬다.
• 실행 관례와의 관계
  • 소프트웨어 장인은 특정 실행 관례에 종속적이지 않다. 대신 추구하는 가치를 만들어내기 위해 실행 관례를 이용할 뿐이다.
  • 소프트웨어 산업은 계속해서 진화 중이다. 우리는 항상 소프트웨어를 개발하는 더 나은 방법, 더 효율적인 방법을 찾아나가야 한다. 실행 관례는 그것이 만들어내는 가치에 따라서 선택된다.
• 애자일 코치와 관리자
  • 부적합한 관리자 밑에서 일하고 부적합한 애자일 코치의 조언을 받는 것은 팀의 동기를 깎아내릴 수 있다.
  • 애자일 코치와 관리자들은 매우 중요하고 어떤 조직들에는 꼭 필요하다. 필자는 프로페셔널들이라면 그 업무의 종류와 관계 없이 깊은 존중과 경외감을 갖고 있다.
• 소프트웨어 도제 제도
• 비유로 인한 문제

---

이 장에서 내가 깨달은 것

• 추구하는 가치는 말이 아니라 행동에 의해 규정된다. 뼈 맞...