로버트C마틴 시리즈 <소프트웨어 장인>

​

#1

기술이 퇴보한 사람들은 현재의 급여 수준과 생활 안정을 유지할 수 있는 다른 직장을 찾을 수 없어 근심하게 된다. 직설적으로 말하면 역량이 부족한 사람들만이 일자리 걱정을 한다. 소프트웨어 장인은 직업을 잃는 것에 대해 걱정하지 않는다. 소프트웨어 자인은 자신의 커리어 방향과 일치하는 경우에만 회사 안의 커리어를 수용한다. 

#2

소프트웨어 장인은 어떤 종착지에 도달하는 것보다 그 여정 자체가 훨씬 더 중요함을 알고 있다.

#3

지식은 일에서 얻을 수 있는 가장 흔한 투자 이익이다. 개발자들은 그들이 배우고 싶은 것을 따라서 일을 선택한다. 그 일을 떠날 때는 생각하는 커리어 방향과 맞지 않아서일 때도 있지만 배울 것이 더는 없기 때문에도 그렇게 한다. 

개인적인 삶도 커리어 결정에 중요한 역할을 한다. 어떤 때는 그냥 돈이 조금 더 필요할 뿐일 때도 있다. 그렇다고 해서 전혀 문제될 것은 없다. 조금 더 많은 돈을 통해 크게 나아질 수 있는 경제 상황이라면 금전적 보상이 좋은 조건으로 커리어를 쫓는 것이 나쁠 이유가 없다. 어떤 때는 그저 좀더 안정적인 직장이 절실할 때도 있다. 가족을 새롭게 꾸리거나 자녀가 생기거나 할 때 특히 그렇다. 어떤 때는 그냥 일에 지쳐서 여행만 다니고 싶을 수도 있고, 어떤 때는 사랑하는 가족과 함께하고 개인적인 기술을 연마할 이유가 있는 야근과 휴일 근무가 적은 직장이 필요할 수도 있다.

커리어에서 옳고 그른 것은 없다. 지식은 영원하고 돈과 안정은 영원할 수 없다는 것만은 마음에 새기고 있어야 한다. 어떤 이유에서든 직장을 떠날 때 남는 것은 오로지 지식과 경험뿐이다. 항상 배우고 더 나은 소프트웨어 장인이 되는 것에 집중한다면, 단순히 돈만 좇을 때보다 좋은 직장을 얻기가 오히려 더 수월하다. 

#4

자율성, 통달, 목적의식

다니엘 핑크의 저서 "원동력: 동기부여에 대한 놀라운 진실"에서 돈은 충족되어야 할 기본 조건이고, 지식 노동자를 움직이는 것은 자율성, 통달, 목적의식 이렇게 세 가지라고 이야기하고 있다.

자율성 : 우리가 무엇을, 어떻게, 언제할지 통제할 수 있는 상태를 뜻한다. 제대로 된 애자일 개발 환경이라면 이러한 것들이 보장되어야 한다.

통달 : 더 나은 프로페셔널, 더 나은 인간이 되기 위해 계속 배우고 진화하는 것을 뜻한다.

목적의식 : 지금 하고 있는 일이 중요하고 무언가를 더 나아지게 하고 있다고 느끼는 것을 뜻한다. 아무런 이해없이 시키는 대로 일하는 것의 반대 개념이다. 

​#5

​돈은 기본적으로 충족되어야 하는 조건이라는 것이 매우 중요하다. 기본적인 생활 요건이 만족되지 않은 상황에서는 일에 집중하기가 상당히 어렵다. 저임음으로 싸게 부려지고 있다고 느끼면 항상 씁쓸한 느낌으로 일하게 된다. 회사를 좋아하더라도 결국은 정당하게 대우받고 있는지 의문을 품을 수밖에 없다. 

#6

직장은 단순히 돈을 버는 곳이 아니라 큰 목표를 향해 다가가는 단계 중 하나다. 소프트웨어 장인은 거치는 자리마다 끊임없이 지식과 열정과 몰입, 그리고 프로페셔널로서의 태도를 키워나간다. 따라서 다른 형태의 투자로서 우리가 기대하는 보상이 어떠한 것인지 명확히 할 필요가 있다. 투자가 계속되는 동안 정기적으로 투자의 성과를 평가해야 한다. 

#7

우리는 지속적으로 그 결정을 재평가하고 다시 목표를 세워야 한다. 이때 단지 나의 열정만 고려하는 것이 아니라 개인적인 삶, 프로페셔널한 삶 속에 나타나는 모든 사건들을 고려해야 한다. 

어디로 가고 싶은지 커리어의 방향을 확신할 수 없을 때는 모든 문들을 열어보기 시작해야 한다. 우리에게 기회가 나타날 수 있는 상황들을 만들어낼 필요가 있다. 

#8 

​아래와 같은 활동을 하면 기존에 고려해보지 못한 새로운 기회에 노출되는 상황이 생긴다. 커리어의 다음 여정을 어디로 할지 결정할 때도 도움이 된다. 

- 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다.

- 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.

- 다른 개발자, 비즈니스맨들과 교류한다.

- 새롭게 배운것, 지금 하고 있는 것들에 대해 블로깅한다 :) 

- 오픈 소스 프로젝트에 참여한다.

- 프로젝트를 만들고 공개한다.

- 컨퍼런스에 참석한다.

- 컨퍼런스의 연사로 나선다. 

​#9

결단과 집중

​요기 베라는 "어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다" 라는 말을 남겼다. 소프트웨어 장인으로서 스스로의 커리어를 가치있게 여기고 아끼고 보살펴야 한다. 커리어가 개인의 삶 전체에 이어지는 긴 여정이며 각자의 선택에 따라 마스터가 될 수 있음을 이해해야한다. 

#10

우리의 의사 결정에 책임감을 가져야 한다. 여기에는 실행 관례를 도입하지 않는 결정도 포함된다. 이것은 개발자만의 이야기가 아니다. 관리자 역시 팀이 특정 실행 관례를 따르지 못하도록 할 때 그에 대한 책임감이 있어야 한다. 우리는 이러한 결정들을 기록하고 문제가 있을 때 에스컬레이션 해야 한다. 

#11

무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다. 지금 하는 방법보다 더 나은 다른 방법은 없는가? 우리가 선택한 실행 관례가 우리 프로젝트에 적합한가? 그 실행 관례의 가치는 무엇인가? 

#12

개발 문화, 실행 관례에 대한 도입을 이야기하기 전에, 먼저 우리가 이루려는 것이 무엇인지 논의해야 한다. 소프트웨어 개발/납품 절차 중에서 어떤 부분을 얼마만큼 개선하길 원하는가? 이러한 것이 정의되고 나면 그것을 달성하기 위해 어떤 실행 관례를 도입할지 말할 수 있다. 

​#13

실용주의는 소프트웨어 장인이 가져야 하는 최선의 역량 중 하나다. 누군가가 이야기했기 때문에, 또는 그 실행 관례 도입을 위한 도입을 해서는 안된다. 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다. 그 결론이 TDD를 도입하는 것이라면 그렇게 해야한다. 언제든지 TDD보다 더 나은 가치와 더 빠른 피드백 루프를 줄 수 있는 다른 것이 있다면 그것을 TDD 대신 도입해야한다.

#14 

역량이 더 높아질수록, 스스로에게 기쁨을 주는 일을 찾기가 쉬워진다. 좋은 일감을 얻을 수 있는 위치에 도달하려면 커리어의 개발 과정 중에 많은 집중과 결단력이 필요하다. 성공적인 커리어는 공짜로 오지 않는다. 스스로 만들어 나가야 한다. 특정 회사 안에서의 커리어보다 개인으로서 우리 자신의 커리어가 항상 우선해야 한다. 물론 회사 안에서의 개인​의 커리어와 일치한다면 대단한 행운이지만 회사가 개인의 커리어를 통제하는 경우가 대부분이다. 일을 신중히 선택하고 고객들을 만족시켜 나가면, 소프트웨어 소프트웨어 장인으로서 매우 성공적이고 ㅅ즐거운 커리어를 만들 수 있다. 

#15

일반적인 대규모 조직에서 커리어를 유지하려 할 때 잘못된 방향으로 가는 것을 많이 보았다. 그 회사를 위해 최선의 것이 무엇인지에 집중하는 대신에, 승진과 보너스에 피요한 것들에만 집중한다. 프로페셔널이 되기 위해 노력하는 대신 주어진 규칙과 질서를 지키는 데 에너지를 쏟는다. 사내 정치 게임을 위해 스스로의 가치는 제쳐둔다. 자신의 승진에 영향력이 있는 사람들과 다툼을 피하기 위해 정직한 의견을 말하지 않고 회사에 해가 되더라도 ㅡㅇ진에 도움되는 일이라면 기꺼이 한다. 회사 안에서 잘못된 일에 집중하고 있는 동안 업계는 계속 진화한다. 어느 날 문득 높은 지위에 있다하더라도 다른 회사에서는 좋은 조건으로 갈 수 없는 퇴물이 되어 다니는 회사에만 목을 매는 붙박이 신세가 된다. 할수 있는 것이라고는 그저 경기가 나빠지거나, 회사가 어려워지지 않기를 기도하는 것뿐이다.

#16

이러한 행동을 하게 되는 조직이라면 관리자 층이 관료주의와 무능함으로 가득한 상태일 것이다. 이러한 조직의 관리자들은 그들보다 더 역량있는 부하직원들이 수행하는 정교한 업무를 제대로 이해하지 못한다. 이러한 현상을 "피터의 원리"라고 한다. 자신의 무능력이 드러날 때까지 승진하려는 경향으로도 표현된다. ​다르게 말하면 어떤 사람들은 정치 게임, 권한 남용, 책임 전가와 비난, 부정직하고 프로페셔널하지 않은 태도를 통해 감당할 능력이 전혀 없는 자리까지 승진한다. 

#17

테스트 코드를 먼저 작성하면 여러가지 장점이 있다. 아이디어를 생각해내는 데도 도움이 되고 한 번에 하나씩만 집중할 수 있다. 모듈, 클래스 함수를 구체적으로 정의하도록 강제하여 일을 점진적으로 진행할 수 있다. 코드 작성 완료 후 실제 환경에서 기대한 대로 동작할 것이라고 강하게 확신할 수 있다. 테스트 코드가 준비되어 있으면 각 테스트 작업들은 몇가지 단위 테스트에에서 몇 초정도 소요되어 피드백 루프가 상당히 빨라진다. 테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 딱 필요한 만큼만 코딩하도록 유도하여, 코드가 불필요하게 복잡해지 않게 한다. 

#18

TDD는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다. 그 첫 번째 이유는 정확히 요구사항만큼만 만족시키는, 즉 테스트로 규정된 부분만 작성하게 되기 때문이다. 첫 설계 단계에서는 요구사항을 확대 해석하고 미래에 있을지 모를 부가 조건들이 추가되기 쉬워 설계가 커지고 복잡해지는 (BDUF: Big Design Up Front) 경향이 있다. TDD는 그렇게 되지 않도록 막아 준다. 두번째는 코드가 복잡해지고 방대하면 테스트 자체가 어렵기 때문이다. 테스트 대상 코드를 작성하기가 점점 어려워진다. 이렇게 테스트 자체가 어려우면 설계를 재검토하고 코드를 단순하게 리팩토링하는 긍정적인 원인이 된다. 

​#19

설계 리뷰는 물론 좋은 것이지만 TDD와 비교하면 두 가지 면에서 단점이 있다. 첫번째는 설계 리뷰가 너무 잦으면 무엇이라도 기여하고픈 참여자의 욕구로 인해 객관성을 잃고 오버 엔지니어링이 되기 쉽다. 설계 리뷰 미팅은 주제가 구체적으로 잘 정의되었을 때 효과가 있다. 예를 들어 변경하기 힘든 모듈의 성능 문제, 새로운 정부 규제 사항 지원과 같은 것들이다. 설계 리뷰는 반드시 큰 변화가 시작되기 전에 있어야 하고, 큰 모듈의 작업 진행 중에 몇 차례 정도가 적당하다. 설계 리뷰 미팅을 자주 하는 것은 바람직하지 않다. 변경 사항이 너무 크다면 더 작은 단위, 점진적인단계로 나누어서 다루어야 한다. 반면에 TDD는 코드 한 줄마다 유용하게 활용되어 문제가 발생하는 즉시 피드백을 준다. TDD와 설계 리뷰 미팅이 서로 배타적인 것은 아니다. 둘 다 필요하다. 하지만 각각이 제공하는 가치와 피드백 루프의 주기가 다름을 이해하고 있어야 한다. 

#20

소프트웨어 장인정신 모임에서 "어떻게 하면 팀에 TDD나 페어 프로그래밍같은 것들을 도입하도록 설득할 수 있는가?"라는 질문을 자주 듣는다. 기술적 실행 관례들 그 자체를 직접적으로 팔려고 드는 것은 아무런 의미가 없다. 그렇게 해서는 상대방을 납득시킬 수 없다. 실행 관례의 도입 자체를 관리자나 팀 구성원들에게 설득하려 하지 말고 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다.

빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다. 

#21

어떤 팀은 2주에 한 번씩 코드 리뷰를 하고 어떤 팀은 아예 하지도 않는다. 코드 리뷰를 아예 하지 않는 팀은 버그를 가득 안은 코드가 문제를 일으킨 몇 달 뒤에나, 손을 쓸 수도 없는 상태에서 피드백을 받을 것이다. 

페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다. 개발자가 테스트를 작성하거나 변수 이름을 짓는 순간 다른 개발자가 즉시 "이 부분은 이해가 안 됩니다. 어떤 의미죠?"라고 말하며 유지 보수 용이성과 명로성에 대해서 피드백을 한다.

같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 그렇게 하면 전체 시스템에 대한 이해도가 높아질 수 있다. 

​