소프트웨어 장인

소프트웨어 장인 책을 읽고 정리한 내용입니다.

어떻게 하면 더 나은 개발자가 될 수 있을까? 어떻게 하면 더 나은 소프트웨어 프로젝트 결과물을 낼 수 있을까? 라는 물음에 대해 도움이되는 조언들이 담긴 책이다.

2장 애자일

기업들은 애자일의 절차적인 부분(회의 방식, 작업 진척 속도 파악 방법, 비즈니스 피드백 방식 등)에 많은 관심을 기울이고 있지만 기술적 실행 관례(TDD, 페어프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등)에 대해서는 완전히 무시하고 있다. 완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다. 기업들이 소프트웨어 장인정신을 품어야 한다.

3장 소프트웨어 장인정신

소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다. 소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.

• 동작하는 소프트웨어뿐만 아니라, 정교하며 솜씨 있게 만들어진 작품을
  • 테스트 주도 개발, 단순한 디자인, 비지니스 용어로 표현된 코드는, 코드를 건강하고 잘 만들어진 상태로 유지하는 최선의 방법이다.
• 변화에 대응하는 것뿐 아니라, 계속해서 가치를 더하는 것을
  • 소프트웨어가 오래될수록 고통과 비용이 아닌 그 가치가 커져야 한다.
  • 애플리케이션의 수명을 오래 유지시키려면 소프트웨어의 품질에 최우선으로 집중해야 한다.
• 개별적으로 협력하는 것뿐만 아니라 프로페셔널 커뮤니티를 조성하는 것을
• 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를
  • 당신이 정규직이라면 고용주를 고객처럼 대해야 한다. 계약직이나 컨설턴트여도 마찬가지다.
  • 소프트웨어 장인은 공장 노동자가 아니다. 적극적으로 프로젝트의 성공에 기여해야 한다.
  • 코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 진정한 소프트웨어 장인이라고 할 수 없다.
  • 생산적 동반자 관계를 받아들일 준비가 되지 않은 기업들이 있다. 소프트웨어 장인도 일하기 좋은 기업을 원한다. 같이 일할 고객 또는 고용주를 선별하는 능력도 소프트웨어 장인에게 꼭 필요하다. 소프트웨어 장인의 가치나 역량에 관심이 없는 고객을 위해 열심히 일해봤자 공허함만 커질 뿐이다. 파트너십은 본디 쌍방향이다.

  소프트웨어 장인정신은 프로페셔널 개발자들이 수용하고 있는 마음가짐이자 삶의 자세다. 소프트웨어 장인은 소프트웨어와 함께 살고 숨쉰다. 그들은 소프트웨어를 장인의 작품으로 여기며 자신의 기술을 마스터하기 위해 모든 노력을 기울인다.

4장 소프트웨어 장인의 태도

끊임없는 자기계발

• 독서: 특히 고전부터 읽어보기를 권한다.
  • 특정 기술에 대한 서적: 자바, node.js, clojure 같은 기술 책들
  • 특정 개념에 대한 서적: TDD, 도메인 기반 개발, 객체 지향 설계, 함수형 프로그래밍
  • 행동양식에 대한 서적: 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발
  • 고전: 실용주의 프로그래머(앤드류 헌트), The Mythical Man-Month(프레드릭 브룩스), 디자인패턴(GOF, 에리히 감마), 테스트 주도 개발(켄트 벡), 익스트림 프로그래밍(켄트 벡), 클린 코더(로버트 C 마틴), 소프트웨어 장인정신(피트 맥브린), 리팩토링(마틴 파울러)
• 블로그
• 기술 웹사이트

팔로우할 리더 찾기

• 소셜미디어

끊임없는 훈련

• 코딩 카타
• 펫 프로젝트
• 오픈 소스
• 페어 프로그래밍

5장 영웅, 선의 그리고 프로페셔널리즘

우리는 전혀 프로답지 못했다. 한번도 ‘아니오’라고 말하지 않았기 때문이다.

• ‘아니오’라고 말하는 방법 배우기: 빠듯한 일정과 상급 관리자로부터의 많은 압박 속에서 상당수의 프로젝트가 진행된다. 이러한 일정들은 비현실적일 때가 대부분이다. 상급관리자에 대항하는 것을 두려워하거나, 아니면 그냥 논쟁자체를 피하려고 한다. 그 모든 기능들을 주어진 일정 안에 완료한다는 것이 불가능함을 알고 있으면서도 상급 관리자의 요구를 그냥 받아들이고 실행한다. 이에 따른 결과는 참혹하다.
  • 고객들에게 항의가 빗발쳤다. 몇 주가 지나서 모든 기능들이 안정화되었지만, 승진과 급여 인상은 커녕 개발팀원으로서 나쁜 평판만 생겼다.
  • 이미 불가능하다고 알고 있는 것에 대해 ‘해보겠다’라고 말하지 말았어야 했다. 그 일을 제대로 해내는 것이 어렵다는 것을 알았지만, 영웅이 될 수 있을 거라는 작은 가능성에 매달렸다.
  • ‘안 된다’, ‘할 수 없다’라는 부정적인 말을 하길 꺼린다. ‘아니다’라고 말할때 우리는 무언가 실패한 듯한, 무언가 협조하길 거부한 기분, 좋은 팀원이 되지 못한 듯한 기분이 든다. 우리는 같이 일하는 사람을 실망시키는 것을 가장 싫어한다. 성공하길 원하고 우리의 역량을 후회없이 최대한 발휘하고 싶어한다. 어뜻 보기에는 긍정적인 사고방식같지만, 그 이면에는 대단히 이기적인 욕구가 숨어있다. ‘네’라고 말할 때 사람들은 그 말을 믿고 그에 의존해서 계획을 짠다는 것을 반드시 기억해야 한다.
• 대안 제시: 항상 ‘아니오’라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다. ‘아니오’라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다. 항상 실용적인 대안을 찾아낼 수 있는 것은 아니다. 그럴 때라도 최소한 브레인스토밍은 해보아야 한다.
  • 어떤 때는 단지 문제를 어떻게 풀어야 할지 방법을 모를 수도 있다. 이때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다. 그리고 문제 해결을 위해서 최선의 노력을 다하고 있음을 보여주어야 한다.

6장 동작하는 소프트웨어

• 동작하는 소프트웨어만으로는 부족하다.
• 정원 돌보기: 정기적으로 살피지 않으면 변화가 있을 때마다, 새 기능을 추가할 때마다 상태가 나빠진다. 점점 다른 파트의 코드들도 오염되고 결국 유지보수에 드는 비용과 노력이 감당할 수 없을 만큼 커져버린다.
• 보이지 않는 위협: 같은 작업량의 기능이라도 프로젝트 초기에는 금방 구현할 수 있었던 것이 나쁜 코드들이 쌓인 프로젝트 중후반에는 훨씬 더 오랜 시간을 들여야만 구현이 완료된다. 코드의 품질이 낮아질수록 새로운 기능을 추가하거나 버그를 수정하거나 어떤 기능을 테스트하는 일이 점점 더 어려워진다. 품질이 낮아질수록 애플리케이션의 강건성과 신뢰성이 낮아진다. 코드의 품질이 프로젝트의 성공을 보증하지는 못하더라도 실패의 핵심 요인이 될 수 있다.
• 시간에 대한 잘못된 인식
  • 기술적 부채: 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다. 백로그에 기술적 부채를 더하는 행위는 개발자가 코딩을 하던 당시에 아무런 죄책감 없이 잘못된 코드를 그대로 반영했다는 것밖에는 설명이 안된다.
  • 소프트웨어 개발자의 삶에 있어 압박은 피할 수 없다. 우리는 압박을 받는다고 느낄 때 중심을 잃고 고만고만해진다. 게으른 탓이 아니다. 더 빨리 해야 한다고 느끼기 때문에 그렇게 한다. 빨리 하는 것과 허술한 것은 다르다.
  • 개발 업무를 작은 단위의 업무들로 나눌 때 ‘단위 테스트 구현’을 별도의 작업 항목으로 정의하는 개발자들이 많다. 단위 테스트 구현에 정규적인 업무시간을 따로 할당하려는 의도이다. 절대 그래서는 안된다. 테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다.
  • 업무를 계획하고 일정을 추산할 때, 좋은 코드뿐만 아니라 좋은 개발 환경을 만드는데 필요한 것도 함께 고려해 두어야 한다. 고객들에게 단위 테스트나 리팩토링같은 것들을 빼먹어도 되는 선택 사항이라는 잘못된 인상을 주게 되면 고객에게 좋은 결과물을 제공하기 어려워진다.
  • 수동 테스트, 디버깅, 오래 걸리는 빌드, 까다로운 애플리케이션 배포, 복잡한 프로젝트 개발 환경 설정같은 것에 시간을 덜 빼앗길수록 애플리케이션의 품질에 더 신경쓸수 있고 고객을 행복하게 할 수 있다.
• 레거시 코드: 레거시 없는 백지 상태에서 시작하는 프로젝트는 항상 즐겁다.
  • 레거시 코드를 개선하고 이해도를 높이면 업무에 크게 도움이 된다. 보는 것 자체가 막막하기만 한 코드를 이해하려 든다는 것이 처음에는 무모할 수 있다. 작은 부분씩 집중해서 한번에 하나씩 이해해 나간다면 조금씩 개선 가능하다. 테스트 코드를 작성하고 메서드와 클래스를 정리하며 변수명을 적합하게 바꾸는 등 점차적으로 코드를 이해하기 쉽고 다루기 편하게 만들어 갈 수 있다.
  • 레거시 코드로 일하는 것은 거대한 직소 퍼즐을 푸는 것과 비슷하다. 모든 퍼즐 조각들을 한꺼번에 펼쳐놓고 맞추려 들면 도통 진도가 나가지 않는다. 각 조각을 그룹으로 나누고 모서리나 경계선부터 시작해야 한다. 조각들을 색상이나 패턴을 기준으로 분리해서 모아두어도 도움이 된다. 시작할 때는 한 무더기의 무작위적인 조각 모음이었지만 약간은 정리된 작은 그룹들의 조각 모음으로 만들 수 있다. 각각의 작은 그룹들에 대해서 조금씩 맞춘다. 즉 점진적으로 기존 코드에 대한 테스트 코드를 작성하면서 코드에 대한 이해도를 높이고 리팩토링을 해나간다.

7장 기술적 실행 관례

• 익스트림 프로그래밍의 역사: XP는 애자일 방법론의 하나로 보고 있지만, 애자일 전환을 수용한 회사들 중에서 XP의 실행 관례를 활용하는 경우는 매우 드물다. 많은 애자일 코치와 컨설팅 회사들은 애자일의 절차적인 관례가 XP 실행 관례보다 더 중요하다고 판단했다. 진실은 XP 실행 관례를 가르칠 만큼 충분한 역량이 있는 애자일 코치와 컨설팅 회사가 매우 드물다는 것이 문제다.
• 실행 관례와 가치: XP 실행 관례들은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법들을 제공한다. 실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다. 부분적인 것은 도움이 되지 않는다. XP 실행 관례로부터 성과를 얻으려면 진심으로 받아들이고 내재화해야 한다.
  • 실행 관례가 효율적이려면 반드시 모든 팀 구성원들에 의해서 그 가치가 납득되어야 한다. 예를 들어 모든 팀 구성원들은 원활한 정보 소통, 빠른 피드백, 빠른 결과물 생성, 실수 예방 고객 만족, 최선을 다하지 못하거나 배우지 못하는 것에 대한 부끄러움을 느낄 줄 아는 것, 이러한 것들에 가치를 느껴야 한다.
  • XP 실행 관례가 실천되고 있는지는, 가치를 실현하고 있는지 알아볼 수 있는 척도다.
  • 기술적 실행 관례들 그 자체를 직접적으로 팔려고 드는 것은 아무런 의미가 없다. 그렇게 해서는 상대방을 납득시킬 수 없다. 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다. 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다.
  • 몇 가지 실행 관례 예: 자동화된 테스트, 테스트 먼저, 테스트 주도 개발(테스트 먼저의 진화된 버전, 설계에 대한 실행 관례), 지속가능한 통합, 페어 프로그래밍, 리펙토링
• 실용주의: 어떤 실행 관례가 다른 실행 관례보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해 보는 것이다. 나머지는 상관이 없다. 만약 비교 중인 두 실행 관례가 비슷한 가치를 준다면 팀에서 좀 더 편하게 받아들일 수 있는 것을 선택하면 된다. 기억해야 할 것은 꼭 이렇게 해야만 한다라는 법은 없다는 점이다.

8장 길고 긴 여정

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

• 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다.
• 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.
• 다른 개발자, 비지니스 맨들과 교류한다.
• 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.
• 오픈 소스 프로젝트에 참여한다.
• 프로젝트를 만들고 공개한다.
• 콘퍼런스에 참석한다.
• 콘퍼런스에 연사로 나선다.

돈은 충족되어야 할 기본 조건이고, 지식 노동자를 움직이는 것은 자율성, 통달, 목적의식 이렇게 세 가지이다.

• 자율성: 우리가 무엇을, 어떻게, 언제할지 통제할 수 있는 상태를 뜻한다. 제대로 된 애자일 개발 환경이라면 이러한 것들이 보장되어야 한다.
• 통달: 더 나은 프로페셔널, 더 나은 인간이 되기 위해 계속 배우고 진화하는 것을 뜻한다.
• 목적의식: 지금 하고 있는 일이 중요하고 무언가를 더 나아지게 하고 있다고 느끼는 것을 뜻한다. 아무론 이해없이 시키는 대로 일하는 거의 반대 개념이다.

일반적인 대규모 조직에서 커리어를 유지하려 할 때 잘못된 방향으로 가는 것을 많이 보았다. 그 회사를 위해 최선의 것이 무엇인지에 집중하는 대신에, 승진과 보너스에 필요한 것들에만 집중한다. 프로페셔널이 되기 위해 노력하는 대신 주어진 규칙과 질서를 지키는데 에너지를 쏟는다. 사내 정치 게임을 위해 스스로의 가치는 제쳐둔다. 어느날 문득 높은 직위에 있다하더라도 다른 회사에서 좋은 조건으로 갈 수 없는 퇴물이 되어 다니는 회사에만 목을 매는 붙박이 신세가 된다. 기술이 퇴보한 사람들은 현재의 급여 수준과 생활 안정을 유지할 수 있는 다른 직장을 찾을 수 없어 근심하게 된다. 직설적으로 말하면 역량이 부족한 사람들만이 일자리 걱정을 한다. 소프트웨어 장인은 직업을 잃는 것에 대해 걱정하지 않는다. 소프트웨어 장인은 자신의 커리어 방향과 일치하는 경우에만 회사 안의 커리어를 수용한다.

9장 인재 채용

투자 은행들의 채용공고는 틀에 박은 듯이 다들 비슷하다. 한 은행에서 시스템을 엉망으로 개발하고 떠난 개발자가 또 다른 은행에서 쉽게 일자리를 구할 수 있다는 이야기도 된다. 이러한 개발자는 더 많은 돈만을 쫓고, 일하는 방법을 개선하거나 자기계발에 공을 들이지 않는다. 이 목록에 합치만 되면 더 대우가 좋은 은행으로 얼마든지 옮겨 다닐 수 있다.

• 틀에 박힌 직무 요건
  • 절대적인 숫자: 5년 간의 자바 경력
  • 기술 목록의 나열: 불필요하게 너무 많은 기술 목록을 나열
  • 잘못된 기업 문화 설명: 보통 그 누구도 부정할 수 없는 아주 당연한 가치들을 나열
  • 잘못된 요구 항목: 기술, 경력 년수, 일한 산업군, 출신학교, 학점 이런 것들보다 그 직무에서 무엇을 책임져야 하는지 설명하는 것이 훨씬 낫다.
  • 승진 요건과 불일치: 승진 심사때, 특정 프레임워크의 API를 알고 있다거나 자바 경력이 몇 년 이상이라서 승진하지 않는다. 대신 그가 이룬 다른 중요한 이유들 때문에 승진을 한다.
• 효과적인 선별 조건의 정의: 일반적인 이력서만으로는 열정 수준을 가늠할 방법이 없었다. 그래서 다른 형태의 이력서를 요구했고 다음 사항들 중에 해당되는 것이 있다면 기술하도록 했다.
  • github 계정
  • 블로그
  • 오픈 소스 활동
  • 기술 커뮤니티나 사용자그룹 활동 내역
  • 펫 프로젝트 내용
  • 트위터 계정
  • 좋아하는 기술 서적 목록
  • 참석했거나 발표했던 컨퍼런스

채용 절차 중에는 최소한 주말을 투자 해야만 하는 코딩 과제를 제시했다. 모든 코드들이 매우 충실하게 리뷰하여 피드백할 것을 약속했다. 이렇게 함으로써 지원자 입장에서는 채용되지 못하더라도 최소한 그들의 코드에 대해 가치 있는 조언을 얻을 수 있고, 회사 입장에서는 기본적인 채용 절차를 통과한 실력있는 후보자들을 확보할 수 있었다.

광범위하게 채용 공고를 내기 위해 어쩔 수 없이 직무 요건을 기술해야만 한다면 회사의 문화나 가치, 프로젝트의 상세한 내용, 기대하는 역할과 책임, 사용된 기술(지원조건이 아닌 참고 자료로서)에 대해서 명확하게 설명할 것을 잊지 말아야 한다. 선별 조건으로서 특정 기술에 대한 경험이나 업무 경력년수, 전공, 학위 인증같은 것들은 적합하지 않다. 대신 열정에 집중해야 한다.

10장 소프트웨어 장인 면접하기

• 생산적인 파트너십을 알아보는 방법
  • 회사 입장에서의 관점: 성숙한 채용 문화의 회사라면 단순히 고용자/피고용자 관계가 아닌 파트너십을 기대한다. 어떤 식으로 일하는지, 무엇을 성취하길 원하는지, 당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까? 항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다. 질문을 많이 한다는 것이 더 능력있다는 증거는 아니지만 최소한 지원자 스스로 즐겁게 일할 수 있는 곳을 찾고 있다는 증거는 될 수 있다. 몇 가지 주의를 기울여야 할 사항들은 다음과 같다. 과거 수행한 프로젝트나 업무, 기술 또는 스스로 성취한 사항들을 이야기할 때 얼마나 열정적이고 애착을 보이는가? 실패 사례에 대해서 어떻게 표현하는가? 실패에 대해서 책임감을 느끼는가 아니면 남 탓을 하는가? 잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력해본 적이 있는가? 이전 업무에서 불평 불만 대신 그 상황을 개선하기 위해 스스로 노력한 적이 있는가? 어떤 종류의 업무 환경을 찾고 있는가? 회사에서 그러한 환경을 제공해줄 수 있는가?
  • 지원자 입장에서의 관점: 면접관들이 말하는 이런 저런 과장들은 모두 흘려 듣는게 좋다. 어떤 회사든지 HR 부서나 채용 담당, 면접관의 입을 통해 이야기될 때는 더할 나위없이 훌륭하게 묘사된다. 세부적인 요소들에 집중하면 진실이 무엇인지 힌트를 얻을 수 있다. 첫 번째 힌트는 관리층이 개발자들을 신뢰하는지의 여부다. 면접관들이 실무 개발자들이 아니라 관리자, 아키텍트, 팀 리더들로만 구성되어 있다면 계층 구조로 운영되는 회사이고 개발자를 신뢰하지 않을 가능성이 높다.
    • 면접관들의 질문들은 대개 면접관이 중요하게 생각하는 것들을 반영한다. 그 팀에 합류했을 때 지원자에게 기대하는 것들을 담고 있다. 채용하려는 직무 내용과 전혀 상관없는 질문을 던질 때도 흔하다.
• 바람직한 면접 방법
  • 올바른 집중: 테스트 주도 개발, 클린 코드, 리팩토링, 페어 프로그래밍, 애자일 방법론과 같은 것을 가치있게 여긴다면 면접 과정에서 그러한 내용이 포함되어야 한다. 전혀 상관도 없는 사항들을 확인하느라 면접 시간을 낭비하지 말자.
  • 마인드 맵핑 대화: 예를 들면 “잘 작성된 소프트웨어란 어떤 것이라고 생각합니까?” “소프트웨어 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까?” 이 질문들에서 ‘잘 작성된 소프트웨어’와 ‘가장 어려운 부분’이 마인드 맵의 뿌리가 된다. 이런한 개방형 질문에는 유지보수, 테스트, 가독성, 성능, 요구사항 등과 관련된 답변이 뒤따른다. 각 항목은 마인드 맵의 노드가 마인드 맵의 뿌리에서 뻗어나간다.
  • 페어 프로그래밍 면접: 페어 프로그래밍을 할 때는 지원자가 어디까지 해낼 것인지 현실적인 기대를 가져야 한다. 면접관은 해당 문제를 이미 알고 있어서 익숙하겠지만 지원자는 그렇지 않다. 지원자가 곧바로 결론을 내거나 솔루션을 찾을 것이라고 기대해서는 안된다. 면접관으로서 어떤 일을 하든지 간에, 지원자가 너무 오래 헤매도록 내버려 두어서는 안된다. 길어야 3~4분 정도 기다렸다가 도움을 주어야 한다. 지원자는 이미 압박 속에 있기 때문에 시간을 지체하면 상황만 나빠질 뿐이다.
• 번트 홈런: 지금 근무 중인 회사에서는 애자일이나 익스트림 프로그래밍이 허용되지 않는다고 이야기했다. 하지만 펫 프로젝트에서는 TDD를 시도하고 있다고 했다. 면접 시간을 그 펫 프로젝트들에 대한 이야기로 채웠다. 펫 프로젝트에 사용한 기술, TDD를 프로젝트에 적용하기 위한 접근 방법, 도전적인 문제들, 다르게 해볼 수 있는 여지들 등등에 대해서 말했다. 면접을 할 때 특정 기술에 대한 지식이 아니라 지원자의 재능, 태도, 열정 그리고 잠재성을 보아야만 한다.
• 지원자와 회사 모두 면접을 어떻게 하는지 알아야 한다: 경험 많은 개발자는 면접을 진행할 때 반드시 경험이 적은 주니어 개발자를 대동하여 참관하게 해야 한다. 복수의 면접관이 참석하거나 면접관을 로테이션하면서 팀원 모두가 채용 과정에 참여하도록 하는 것도 바람직하다. 새로운 개발자가 팀에 합류할 때 팀원들이 직접 면접을 보고 선별 과정에 참여하면 팀의 사기와 주인의식이 높아질 수 있다. 이러한 활동은 팀 구성원들이 누구와 함께 일할지에 대해 영향력을 행사할 수 있고, 프로젝트를 자신이 통제할 수 있다는 확신을 심어준다.

11장 잘못된 면접 방식

다음의 면접 방식들은 의식적으로 배제해야 한다.

• 똑똑한 척하는 면접관을 세운다: 지원자를 프로페셔널 개발자로서 대하고, 채용을 위한 평가나 취조가 아니라 당신이 존중하는 누군가와의 유익한 기술 토론이 되도록 이끌어야 한다. 무엇보다도, 지원자의 이야기를 경청하고 그에게 마음을 여는 것이 중요하다.
• 수수께끼식 질문을 던진다: 비행기에 골프공이 몇 개나 들어갈까? 같은 질문들
• 답을 모르는 질문을 한다: 면접 전에 구글에서 질문과 답변을 검색해보는 것은 의미 없는 행위다.
• 지원자를 바보로 만든다: 내가 설명을 마치자 수석 아키텍트는 임원을 잠깐 쳐다보고는 나를 향해 “너무 단순하네요. 그건 제대로 된 실제 아키텍처가 아닙니다.”라고 무시하는 말투로 말했다. 경멸하는 태도를 확실히 느꼈다. 나는 그 임원에게 면접을 계속하는 것이 의미가 없음을 설명했고 면접 기회를 준 것에 감사를 표하고 자리를 떠났다.
• 인터넷 접속을 막는다
• 종이에 코드를 작성하게 한다
• 알고리즘 문제를 낸다: 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치 있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.
• 전화 면접을 한다: 전화 면접은 제대로 된 대화보다는 매우 딱딱한 질문과 답변으로 흐르기 쉽다.

12장 낮은 사기의 대가

• 낮은 수준의 동기가 만드는 제약
  • 자신에게 아무런 권한이 없다고 생각한다.
  • 그런 일을 이끌어가야 할 당사자가 되고 싶지 않다.
  • 그렇게 되기에는 복잡한 장애요인이 너무 많다.
  • 뭔가 바뀌는 것이 가능하다고 믿지 않는다.
  • 무엇이 더 나은 일인지 사람들의 동의를 받기 힘들다.
  • 아무 상관 없다. 그냥 출퇴근만 하면 된다.

13장 배움의 문화

• 배움의 문화 만들기
  • 북 클럽에 가입하기: 책을 하나 선택해서 동료들에게 그 책을 읽기 시작할 거라고 공표하자. 동료 중 한명이라도 관심을 보인다면 북 클럽을 시작할 수 있다. 아무도 관심이 없다면 동료들이 어떤 종류의 책이나 주제에 관심이 있는지 탐색해본다. 그 중 하나를 선정하여 그룹을 만들고 첫 번째 미팅 일정을 잡는다. 그래도 아무도 관심이 없으면 그냥 본인이 원하는 책을 읽기 시작한다. 대신 책의 내용을 공유하고 대화를 시도해보자.
  • 테크 런치 진행하기: 일주일에 한 번 정도 점심 시간에 기술과 관련된 난상 토론회를 가지는 것을 제안해보자. 이 토론회는 그 어떤 형식도 갖출 필요가 없다. 현재 진행 중인 프로젝트의 개선 방향을 이야기하는 것도 좋지만 이 토론회를 업무의 연장으로 만들지는 않는 것이 좋다.
  • 그룹 토론회에 참여하기
  • 업무 교환하기
  • 그룹 코드 리뷰하기
  • 코딩 실습하기
  • 내부 학습 모임을 만들기: 두 사람만 있으면 내부든 외부든 커뮤니티를 시작할 수 있다. 한 가지 주의사항이 있다. 절대로 모임의 규모를 키우는 데 집착해서는 안된다.
  • 회사에서 펫 프로젝트 시간을 허용하기
  • 외부 기술 커뮤니티와 교류하기
• 아무도 참여하려 하지 않는다면
  • 모범을 보여라
  • 관심을 보이는 사람에게 집중하라: 그들과 페어 프로그래밍을 하고, 테스트를 작성하고, 서로의 코드를 리뷰한다. 유익한 토론들을 하고 아이디어와 정보를 나눈다.
  • 강제하지 마라: 강제로 참석시키면 상황은 극도로 안 좋아진다. 대신 계속 초대장을 보내자.
  • 모두를 변화시키려 들지 말라
  • 모임에 대한 약속을 제때하라: 모임을 언제 어디서 할지 참여자 간 일정 조율이 어렵다는 점은 학습 모임 자체를 어렵게 만드는 가장 큰 장애요소다. 가능하면 모두가 참여할 수 있도록 개별 일정을 모두 협의하는 것도 좋기는 하지만, 어떤 때는 그냥 특정 날짜를 정해서 모임을 진행하는 것이 좋다.
  • 허락을 구하지 마라: 개인 시간을 들여 공부하고 연습하는 데 상사의 허락을 구할 필요는 없다. 심지어 업무 시간에 공부를 하더라도 상사에게 허락을 구하지 않는다. 책임있게 행동하면 될 뿐이다.
  • 리듬을 만들라: 정기적으로 항상 어디서 모임이 열리는지 모두가 안다면 참여하기가 훨씬 쉽다.

14장 기술적 변화와 실행

• 준비: 진정으로 당신을 둘러싼 것들을 바꾸고 싶다면 몇 가지 꼭 갖춰야 할 것들이 있다. 가장 중요한 것은 용기다. 동료 개발자, 관리자, 기술 리더와 언성이 높아지는 논쟁을 두려워해서는 안된다. 의견 충돌이 없는 마음 편한 대화만을 기대할 수는 없다. 싸울 준비가 되어 있어야 한다. 당신이 생각하는 내용이 어떤 것이든 말할 수 있는 용기가 있어야 한다. 정직함과 투명함은 소프트웨어 장인이라면 반드시 가져야 할 핵심 가치다. 자기가 하는 말이 무엇인지 스스로 제대로 모르면서 다른 사람을 설득할 수는 없다.
  • 단순함을 추구해야 한다: 아이디어나 제안은 아주 명료하고 단순해야 한다.
  • 상대방의 언어로 말해야 한다: 관리자나 제품 오너에게 소스 코드나 프레임워크의 세세한 부분을 이야기하려 들어서는 안된다. 대신 당신의 제안이 가져올 이익을 그들의 관점에서 그들의 언어로 말해야 한다. 관리자나 제품 오너가 대상이라면 유지보수 비용 절감, 릴리즈 주기 단축, 릴리즈 신뢰성 증대 이런 것들을 말한다.
  • 말할 내용에 대해 스스로 제대로 이해하고 있어야 한다: 연구하고, 실험하고, 연습해야 한다.
  • 상대방을 존중해야 한다
  • 경청하는 법을 배운다: 당신만이 좋은 아이디어를 갖고 있다고 오판해서는 안 된다.
• 두려움과 자신감 부족: 당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야 한다. 무슨 일이 일어나든 항상 진실을 말해야 한다. 유일한 충고는 인격적으로 못되먹은 사람이 되지 말라는 것 하나뿐이다.
• 상사를 설득하는 법: 상사를 어떻게 설득할 수 있을까? 답은 ‘설득할 수 없다’이다. 그냥 가서 하고 싶은 것을 하면 된다. 기술적 실행 관례라면 굳이 관리자가 관심을 가질 이유가 없다. 관리자들은 일정에 맞추어서 제품이 딜리버리되고, 예산을 지키고, 버그가 없는 것에 관심을 가질뿐이다. 관리자들이 원하는 것은 고객과 이해관계자들의 만족이다. 개발자들이 TDD를 하든 페어프로그래밍을 하든 지속적인 통합을 하든 상관하지 않는다. 고객은 개발자에게 높은 품질의 소프트웨어, 훌륭한 솔루션을 기대한다. TDD, 페어프로그래밍, 연속된 통합 등의 실행 관례들은 모두 그러한 것들을 달성하도록 돕기 위함이다. 누군가에게 물어볼 것 없이 그냥 실행하면 된다. 공식적인 작업 항목에 ‘단위 테스트 코드 작성’이라고 올릴 필요도 없다. 관리자에게 리팩토링이나 단위 테스트 업무를 위해 시간을 달라고 요청하는 것 자체가 의미가 없음을 말하고 싶다.
• 팀이 TDD를 수용하도록 설득하는 방법
  • 항상 무언가를 배우는데 열성적인 사람에게 TDD를 전파하기는 매우 쉽다. 내가 TDD에 능숙하지 않아도 같이 공부하면 된다. 반면에 매사에 의심이 많은 사람에게 TDD를 전파하기는 매우 어렵다. 이 경우, 먼저 스스로 TDD에 통달해야 한다. 힘들게 페어 프로그래밍을 하며 TDD를 소개한 결과가 “TDD는 어렵고 느려서 가치가 없다”는 확신을 심어주는 최악의 상황은 피해야 한다. 실행관례를 전파하는 가장 효율적인 방법은 모범을 보이는 것이다. 당신과의 페어 프로그래밍에 초대해서 어떻게 하는 것인지 보여주자.
• 회의론을 상대하는 방법: 커뮤니케이션을 상대방의 수준에 맞게 잘 하는 것도 중요하다. 상사를 내편으로 만들려면 상사의 언어로 이야기를 해야 한다. 개발자의 수준 문제를 끄집어 내어서는 안 된다. 상사의 수준에 맞게 대화의 수준을 올려야 한다. 생상선 향상, 비용 절감, 매출 증대, 일정 준수, 버그 감소, 예측 가능하고 꾸준한 개발 속도, 비지니스 요구사항의 충족 등 이런 것들이 상사의 사항이다. 무언가 바꾸고 싶다면 그 변화들이 상사가 관심을 가지는 요소들에 어떤 영향을 미치는지 생각해야 한다. 의사 결정 과정에 모두가 참여하도록 만드는 데 주의를 기울이자. 나의 의견을 일방적으로 요구해서는 안된다. 작업 주기가 전환되는 시점에 새로운 것을 시도해 볼 것을 제안하자. 이때 누군가의 자리를 위협하는 것처럼 보여서는 안된다. 무언가를 더 나아지게 만드는 데 목적을 두어야 한다.
• 진정한 소프트웨어 프로페셔널은 권한에는 항상 책임이 따른다는 것을 이해하고 있다. 권한을 갖고 싶다면, 책임질 수 있는 준비를 해야 한다. 이미 책임이 주어져 있다면, 관련된 의사결정이 권한도 가질 수 있도록 해야 한다.

일을 잘 해내려면 소통을 명확히 해야 한다. 무엇보다도 개발자들과 신뢰를 쌓는 방법을 알고 있어야 한다. 신뢰야말로 변화를 이끌기 위한 핵심적인 요소다. 대화하는 상대방을 이해하고, 그 사람의 생각의 바탕에 어떤 이유들이 있는지 공감할 수 있어야 한다. 자신을 준비시키고 용감해지고, 주도하자.

15장 실용주의 장인정신

소프트웨어 장인은 익스트림 프로그래밍(XP)의 실행 관례와 애자일 원칙을 습관화 하고 있다. 소프트웨어 장인이 개발 및 진행 중인 프로젝트라면 첫날부터 동작하는 소프트웨어가 고객에게 전달된다. 소프트웨어 장인은 지속적인 통합과 프로젝트 초기부터의 제품 딜리버리를 목표로 하기 때문에 소프트웨어 품질로 인해 상용 릴리즈가 지연되는 일은 가정에 없는 사항이다. 소프트웨어 장인은 테스트 주도 개발과 같은 실행 관례들을 마스터하고 있어서 실행 관례의 준수로 인해 업무 속도가 늦어진다는 것은 있을 수 없는 일이다. 큰 애플리케이션의 복잡한 테스트라 하더라도 소프트웨어 장인이 작성한 자동화 테스트는 몇 초 안에, 늦어도 몇 분 안에 완료된다. TDD에 능숙한 개발자들은 TDD 때문에 개발이 지연되었다거나 시간이 없어서 테스트를 작성하지 못했다는 변명은 절대 하지 않는다. TDD등 XP 실행 관례를 전파하고 싶다면 먼저 스스로 충분히 능숙해져야 한다.

리팩토링을 위한 리팩토링은 시간낭비다. 레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래보다 깨끗하게 만들어 놓아야 한다. 새로운 기능을 추가할 때마다 코드를 분석하고 필요한 경우 리팩토링을 하여 레거시 코드가 새로운 기능을 자연스럽게 받아들일 수 있도록 해야 한다. 새롭게 추가할 기능이 레거시 코드에 큰 영향을 준다면 사전에 영향이 가해지는 부분을 리팩토링하는 것이 바람직하다. 새로운 기능을 추가하기 전에 다음과 같은 질문들을 던져 보아야 한다. 레거시 코드는 새 기능을 받아들일 준비가 되어 있는가? 수정해야 할 코드량은 어느 정도 되는가? 이 두 질문에 대한 답이 ‘아니오’와 ‘아주 많이’라면 먼저 레거시 코드를 리팩토링하여 새로운 기능을 받아들이기 쉬운 상태로 만들어야 한다. 받아들이기 쉽다는 것의 의미는 기존의 동작 방식을 전부 파헤치거나 변경하지 않고 새로운 기능으로 인한 영향을 최소화한다는 것을 의미한다. 즉 ‘확장에는 열려있고 변경에는 닫힌’ OCP 원칙을 준수할 수 있도록 코드를 리팩토링한 후에 신규 기능을 추가한다.

장인이라면, TDD와 같은 XP 실행 관례들을 절대 불변의 진리라고 믿어서는 안된다. 지금 당장 우리가 XP를 추구한다고 해서 더 나은 다른 방법을 찾아 보는 것을 멈춰서는 안 된다. 소프트웨어를 개발하는 방법이 하나 밖에 없다고 생각하는 순간, 다시 말해 우리가 활용해야 할 실행 관례들이 정해져 있다고 믿는 순간 우리는 진화를 멈추게 된다. 소프트웨어 장인은 여러 가지 훌륭한 도구들을 포용하면서 맡은 일의 맥락에 가장 적합한 것을 꺼내어 적용할 수 있어야 한다.

비범함과 평범함

그 어떤 바보 같은 개발자도 뭔가를 동작하게 만들 수는 있다. 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다. 문제를 단순하고 우아한 방법으로 해결하는 것은 복잡하고 과잉된 방법으로 해결하기보다 훨씬 더 어렵다. 잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다. 그리고 가장 중요한 부분으로 코드가 해야 할 일을 해낸다. 코드는 버그와 고통의 근원이다. 더 적게 작성할수록 좋다.

단순한 설계를 위한 네 가지 원칙

소프트웨어 장인이라면 아키텍처, 디자인 패턴, 제네릭 솔루션 등을 떠올리기 전에 켄트 벡이 말한 ‘단순한 설계를 위한 네 가지 원칙’을 먼저 생각해야 한다. 작성되는 모든 코드들이 이 원칙들을 따를 수 있도록 노력해야 한다.

• 모든 테스트를 통과해야 한다.
• 명료하고, 충분히 표현되고, 일관되어야 한다.
• 동작이나 설정에 중복이 있어서는 안된다.
• 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

많은 사람들이 이 네가지 원칙을 다른 방식으로 표현하고 있다.

• 모든 테스트의 통과
• 중복의 최소화
• 명료성의 최대화
• 구성요소의 최소화

소프트웨어 장인이 TDD를 일상적으로 실천한다고 가정한다면 첫 번째 원칙은 너무 자명해서 무시할 수 있다. 두 번째 원칙, 중복의 최소화를 하다보면 자연스럽게 구성요소가 줄어든다. 따라서 네 번째 원칙도 무시할 수 있다. 그렇다면 아래 두 가지 원칙만 남는다.

• 중복의 최소화
• 명료성의 최대화

나는 중복 제거보다는 명료함을 항상 우선시한다. 단순한 설계를 위한 가이드 라인으로 좋은 네이밍과 비지니스 컨셉트를 잘 투영한 추상화에 집중한다. 그 다음에 중복을 제거하면서 코드의 응집성과 독립성을 높인다. 중복을 제거하다 보면 새로운 구조가 떠오르고 다시 명료성을 높인다. 다시 중복을 없애다. 이러한 사이클을 매우 짧은 반복 주기로 작업이 완료될 때까지 계속한다. 이 접근 방법이 도메인 기반 설계, SOLID 원칙과 결합되면 꽤 괜찮은 코드를 만들어 낼 수 있다. 이 접근 방법은 불필요한 여러 가지 설계적, 아키텍처적 패턴들로 코드가 오염되는 것을 막아준다.

디자인 패턴

1990년대에는 디자인 패턴(GoF:Gang of Four)책을 참고하지 않고 단 한줄이라도 코드를 작성할 생각은 할 수가 없었다. 모든 것이 범용적이도록 설계했기 때문에 과잉 엔지니어링에다가 상당히 복잡한 솔루션을 유도했다. 미래를 위해 모든 것이 일반화, 범용화해야 했다. 오늘날 흔히 볼 수 있는 레거시 코드들을 생각해보자. 충족시켜야 할 실제 비즈니스 기능보다 개발자가 적용한 디자인 패턴을 알아보는 것이 훨씬 더 쉽다. 범용 코드는 물론 좋다. 하지만 공짜가 아니다. 코드가 범용화될수록 더 복잡해진다.

TDD를 기본으로 하여, 애자일과 XP 실행 관례를 몸에 익히면 미래에 대비한 범용 코드를 작성하는 일에서 당장의 필요를 충족시키는 구체적인 코드를 작성하는 것으로 옮겨가게 된다.

패턴을 위한 리팩토링

TDD에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다. 테스트 코드는 비지니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것은 아니다. 코드는 테스트 통과에 꼭 필요한 만큼만 작성된다. 이러한 작업 방식은 구체적이고 특정적이면서도 매우 단순한 솔루션을 만들어낸다. 꼭 필요한 만큼의 코드만 작성되고 그 이상은 없다. 리팩토링 단계는 TDD 라이프 사이클을 따라서 중복되는 모든 부분이 제거되고 문제 도메인에 적합하게 코드가 표현되었는지를 확인한다.

추상화를 도입할 때마다 즉, 간접처리 단계가 추가될 때마다 비용이 발생한다. 이전에 순서대로 읽기만 하면 쉽게 이해되던 코드들이 이제는 좀더 이해하기 어려워졌다. 당장의 합당한 이유없이 단지 ‘미래를 대비해야 한다’는 모호한 전제로 초기부터 추상화를 하면 애플리케이션이 엉망이 된다. 미래에 어느 부분에서 수정이 필요할지 모르기 때문에 모든 부분에서 추상화(복잡도 증대)를 적용해버린다. 애플리케이션이 진화 및 변경할 수 있도록 모든 가능성에 대비하는 것을 똑똑한 대응이라고 생각할 수도 있다. 진실은 반대로 매우 바보같은 짓이다.

실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화를 도입하는 것이다. 그렇게 하면 전체적인 복잡도를 낮추는 데 도움이 된다. 당연하지만 복잡도가 낮은 시스템이 높은 시스템보다 유지보수 비용이 낮다. 디자인 패턴 자체가 나쁜 것은 아니다. 분명 우리가 활용해야 할 도구 중 하나다. 무조건 사용해야 할 도구는 아니다. 패턴이 먼저가 아니다. 내가 좋아하는 패턴에 문제를 끼워 맞추기 전에, 문제에 적합한 리팩토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다. 그 다음에 리팩토링으로 만들어진 솔루션이 특정 디자인 패턴과 거의 동일하다면 그 패턴을 지향하도록 리팩토링할 수도 있다. 범용 코드는 확장성이 더 좋을지는 몰라도 특정된 코드보다 더 복잡하다. 무조건적으로 범용코드를 추구해서는 안된다. 대신 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

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

열정. 이 단어 하나가 모든 것을 요약한다. 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 열정적이다.

장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다. 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다. 특정 도구를 종교적으로 신봉하지는 않더라도 최선이라고 알려진 몇몇 조합들에 대해서는 완전하게 마스터하고 있어야 한다. 마스터한 도구들이 없다면 장인이라고 할 수 없다. 진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. 코드를 짤 때는 높은 품질의 코드를 작성하는데 집중한다. 테스트 가능하고 쉽게 이해할 수 있으며 수월하게 유지보수할 수 있는 코드를 작성하는데 집중한다.

여정과 이정표

나는 항상 더 많은 것을 제공하고 더 많은 일을 수행해서 내 주변의 모두가 더 나아지도록 노력했다. 내 역할과 직급이 무엇이든 상관없이 내가 할 수 있는 최선의 도움을 주려 노력했다. 이런 것들은 나의 투자라고 생각한다. 내 일을 위한 투자일 뿐만 아니라 개인의 커리어를 위한 투자이기도 하다. 모든 종류의 투자가 그러하듯이 나 역시 투자에 따른 이익을 바라고 있다. 기대하는 이익의 종류는 나의 개인적인 또는 업무적인 삶의 변화에 따라 매번 달라진다. 특정 기술이나 산업을 접하거나, 새로운 형태의 프로젝트를 경험하거나, 다른 스킬을 개발할 수 있는 기회를 얻거나, 다른 역할 또는 다른 형태의 책임을 수행하거나, 그리고 더 많이 금적적 이익이 생기거나 하는 것들이 기대하는 이익들의 종류다.

나는 일을 선택하기 전에 아래와 같은 질문들을 스스로에게 던졌다.

• 나의 커리어로부터 나는 무엇을 원하는가?
• 그것을 성취하기 위한 다음 단계는 무엇인가?
• 이 일은 나의 커리어 방향과 합치하는가?
• 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
• 그러한 투자에 대한 이익은 무엇인가?
• 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?
• 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?
• 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?
• 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나? 위의 질문들은 계약 형태와는 아무런 관련이 없다. 나는 대부분 정규직으로 고용되었지만 계약직이나 컨설턴트라고 해서 위의 질문들이 달라질 것은 없다.

필자는 왜 그렇게 신중하게 고른 회사들을 그만 두었나? 여기에는 몇 가지 이유가 있다. 시간에 지나면서 나의 커리어 열망이 바뀌었다. 개인적인 삶도 바뀌었다. 일부는 회사가 바뀌기도 했다. 무엇이든 변한다.

일들 하나하나가 여정에서 우리가 더 멀리 나아갈 수 있게 해준다. 일을 선택하는 것은 매우 신중해야 한다. 재직하는 기간은 회사마다 매우 크게 다를 수 있다. 몇 달 혹은 몇 년이 될 수도 있다. 나는 개인의 커리어 열망과 방향이 합치하는 한 그 회사에 가능한 오랫동안 머무르길 권한다. 회사에서 하는 일이 당신이 가진 커리어 열망과 방향에서 틀어진다면 회사와의 동반자 관계가 약해지고 서로로부터 얻을 수 있는 이익이 적어진다. 앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면, 그때는 움직여야만 한다. 회사와 동료들을 사랑한다는 것만으로 그 일을 계속해야 하는 충분한 이유가 되지 못한다. 사람들도 움직이고 회사도 움직인다.

다양성

컨설팅 회사에서 일하는 것은 서로 다른 프로젝트와 환경들을 접해볼 수 있는 좋은 기회다. 그것이 유일한 방법이라는 것은 아니다. 하지만 분명 매우 좋은 방법이다. 컨설팅 회사는 다수의 서로 다른 고객들을 상대하기 때문에 개발자에게 여러 가지 서로 다른 기회들을 줄 수 있다. 맡게 되는 프로젝트에 따라서 새로운 기술, 새로운 도구, 새로운 절차를 접할 수 있다. 무엇보다도 인적 네트워크를 확대하기에 좋다.