소프트웨어 개발자로써 읽어야할 책이라길래 읽고 가볍게 정리해보았다.

소프트웨어 장인

PART1 이념과 태도

Chapter 1 - [21세기의 소프트웨어 개발]

코딩을 잘 하거나 특정 언어나 프레임워크에 매우 익숙하다고해서 고참 개발자가 되는 것은 아니라고한다. 이제 개발자들은 아래와 같은 여러가지를 할 수 있어야한다.

• 고객과 대화하기
• 테스트/배포 자동화하기
• 전체 비지니스에 영향을 미칠 기술 선정하기
• 지리적으로 분산된 팀들과 협업하기
• 고객을 도와 필요한 작업을 정의하기
• 우선순위 정하기
• 진척 상황 보고하기
• 변경사항과 기대일정 관리하기
• 잠재 고객 및 파트너에게 제품 소개하기
• 사전 영업 활동 지원하기
• 개발 일정과 비용 산출하기
• 채용 면접하기
• 아키텍처 설계하기
• 비기능적 요구사항과 계약조건 검토하기
• 사업 목표 이해하기
• 주어진 여건에서 최적의 결정하기
• 새로운 기술 주시하기
• 더 나은 업무 방식 찾기
• 고객에게 가치 있는 상품이 전달되고 있는지 고민하기

Chapter 2 - [애자일]

애자일은 어떤 단일 개념이 아니다. 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합니다.

• 절차적인 관점에서의 애자일 원칙
  • 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중한다. 이러한 방법론들을 통해 팀이 올바른 결과물을 만들어 가는지, 즉 올바른 목표를 향해 진행 중인지 확인할 수 있다.
• 기술적인 관점에서의 애자일 원칙
  • 개발, 확장, 유지보수, 제품을 출시(또는 납품, 서비스 배포)하면서 겪는 어려움들에 대해 틀정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드한다. (TDD, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등)
  • 즉 ** 목표한 것을 올바르게 실행하고 있는지**에 대해 안심할 수 있게 한다.
• 애자일 메니페스토
  • 절차와 도구보다는 개성과 화합을
  • 방대한 문서 작업보다는 동작하는 소프트웨어를
  • 계약 조건에 대한 협상보다는 고객과의 협력을
  • 계획을 따르는 것을 넘어서서 변화에 대처하는 것을
  • 더 가치있게 여긴다.

Chapter 3 - [소프트웨어 장인정신]

소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.

• 소프트웨어 장인을 열만하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.
  • 동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
  • 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
  • 개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는것을,
  • 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,
• 이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.
• 소프트웨어 장인은 고객과 고용자•피고용자 관계가 아닌 생산적인 동반자 관계를 기대한다.

Chapter 4 - [소프트웨어 장인의 태도]

오래 전에 작성했던 코드를 지금에 와서도 고칠 부분이 없어 보인다면, 그것은 그동안 배운 것이 없다는 뜻이다.

• 끊임 없는 자기계발

  • 독서, 많은 독서
    • 특정 기술에 대한 서적: 업무를 위해 어떤 프레임워크나 프로그래밍 언어 또는 특정 소프트웨어의 이용 방법을 급하게 알아야 할 때 꼭 필요하다. 당장의 업무에는 유용하지만 그 가치가 오래가지는 않는다. (java, Hibernate, Node.js, Clojure 등)
    • 특정 개념에 대한 서적: 커리어를 진전시킬 때 필요한 기초를 쌓을 수 있는책이다. 새로운 개념이나 패러다임 또는 실행 관례들을 소개한다. 장장 활용하기는 어렵고, 제대로 이해하고 습득하는 데 긴 시간이 필요할 때도 있다. (TDD, 도메인 기반 개발, 객체 지향 설계, NoSQL 데이터베이스 모델 등)
    • 행동양식에 대한 서적: 효율적으로 팀에서 일할 수 있게 안내하거나, 일반적인 상황에서 더 나은 프로페셔널이 될 수 있도록 조언한다. 팀 동료나 고객 등 사람들을 어떻게 대하고 일정을 어떤 방식으로 관리하면 되는지 설명한다. (애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 경영 등)
    • 혁명적 서적(또는 고전): 일하는 방식이나 개인의 가치관을 바꾸는 책이다. 이전과는 전혀 다른 가치나 원칙들을 제시해 다수에게 무시되거나 배척되지만 결국에는 주류 사상으로 자리매김한다. 소프트웨어 개발자라면 이미 읽어 보았음ㅇ직한 것들로 일상적인 업무 중 대화에서도 그 내용이 흔하게 언급된다. (실용주의 프로그래머, 디자인 패턴, 테스트 주도 개발 등)
  • 블로그
    • 블로그를 이용하면 항상 최신 정보를 습득할 수 있다.
    • 실제 경험, 개인적인 발견, 의견, 성공담, 실패담들이 짧게 담겨 있기 때문에 소프트웨어 장인정신이나 애자일 모델에 태생적으로 궁합이 잘 맞다.
    • 사전에 충분한 지식이 없는 사람에게는 블로그가 독이 될 수도 있다. 많은 연구 없이 깊이가 없는 글이 올라오는 블로그도 꽤 많기 때문이다.
  • 기술 웹사이트
    • 온라인 기술 잡지와 같은 많은 웹사이트들에서 새로운 트렌드나 기술들을 소개하고 있다.

Chapter 5 - [영웅, 선의 그리고 프로페셔널리즘]

프로답게 행동하고 고객을 만족시킨다는 것이 고객의 요구사항을 모두 받아들이라는 뜻은 아니다. 고객이 무엇을 가장 필요로 하는지, 그것을 얻기 위한 최선의 방법을 도우며 조언하는 것이 우리의 일이다.

• 의도한 대로 동작할 수 없거나, 실행 불가능한 무리한 일정에 대해서 “아니오” 라고 답하는 것은 우리의 의무다.
• 고객은 문제를 들고 프로페셔널을 찾아간다. 프로페셔널들이 그들의 경험과 지식을 활용해 그 문제를 다룰 방법들에 어떤 것들이 있고 각각의 장단점은 무엇인지를 알려주길 기대한다.

Chapter 6 - [동작하는 소프트웨어]

전통적인 관리자들과 비즈니스 컨설턴트들이 절차와 문서의 중요성을 아무리 강조하고 싶어하더라도 소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다. 나머지는 부차적이다.

• 프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다 (‘실용주의 프로그래머’ 인용)
  • 코드는 정원처럼 지속적인 유지보수가 필요하다.
  • 시간이 있어 개발자 스스로 자동화 테스트를 구현하지 않으려는 경우도있다. 이러한 개발자는 테스트하지 않아서 발생할 수 있는 파급 효과를 무시한 채 스스로 “나는 테스트 코드를 작성할 시간이 없다” 라고 단정한다. 자신의 작업 시간만 생각하고 전체 프로젝트에 관계된 다른 사람들이 시스템을 테스트하고 디버깅하느라 얼마나 많은 시간을 소모해야 하는지는 생각하지 않는 사람이다. 항상 프로젝트에 다른 사람들도 있다는 사실을 인식하고 전체 프로젝트에 미치는 영향을 감안하여 책임있게 행동해야 한다.
  • 자신이 짠 코드는 어떻게 동작하는 지 잘 알고 있고 문제가 없을 터이니 테스트 코드를 따로 안 만들어도 된다고 주장하는 개발자는 대단히 자기 중심적이고 이기적인 사람이다. 소프트웨어 프로젝트는 팀워크다. 특정 개발자 한 사람을 위한 것이 아니다. 특정 개발자에게 쉽고 분명한 것이 팀내 다른 개발자에게는 난해하고 불분명할 수 있다. 시스템이 커짐에 따라 프로젝트에 관계된 모든 사람들이 개인의 작은 이기적 행동들 때문에 피해를 입게 된다.

Chapter 7 - [기술적 실행 관례]

개발자는 왜 테스트 주도 개발(TDD)이나 페어 프로그래밍 같은 익스트림 프로그래밍(XP)의 관례들에 관심을 가져야 할까 ?

• 자동화된 테스트
  • 자동화된 테스트는 클릭 한번으로 전체 시스템을 단 몇 분만에 검증할 수 있게 해준다. 자동화된 테스트가 있으면 코드를 수정한 지 몇 분만에 안심하고 상용 릴리즈에 반영할 수 있다.
• 테스트 먼저
  • 테스트 코드를 먼저 작성하면 여러 가지 장점이 있다. 아이디어를 생각 해내는 데도 도움이 되고 한 번에 하나씩만 집중할 수 있다.
• 테스트 주도 개발
  • 테스트 주도 개발(TDD)은 테스트 코드를 먼저 작성한다는 것의 진화된 버전이다. 가장 흔한 오해가 TDD를 단위 테스트와 동일하게 생각하는 것이다.
  • TDD의 이름 자체에 ‘테스트’가 들어 있기는 있지만 사실 TDD는 설계에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는것 자체가 어려워 진다.
    • 정확히 요구사항만큼만 만족시키는, 즉 테스트로 규정된 부분만 작성하게 되기 때문이다.
    • 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다.

Chapter 8 - [길고 긴 여정]

우리는 정말 커리어를 제대로 도보고 있는가? 어디로 가고 있는지, 어디로 가고 싶은지 진정으로 알고 있는가? 우리의 일을 투자로 바라보아야 하는가? 그렇다면 그 투자에 대한 보상은 무엇이어야 할까?

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

• 역량이 더 높아질수록, 스스로에게 기쁨을 주는 일을 찾기가 쉬워진다. 좋은 일감을 얻을 수 있는 위치에 도달하려면 커리어의 개발 과정 중에 많은 집중과 결단력이 필요하다. 성공적인 커리어는 공짜로 오지 않는다. 스스로 만들어 나가야 한다.

• 특정 회사 안에서의 커리어보다 개인으로서 우리 자신의 커리어가 항상 우선해야 한다. 물론 회사 안에서의 커리어가 개인의 커리어와 일치한다면 대단한 행운이지만 회사가 개인의 커리어를 통제하는 경우가 대부분이다.

• 일을 신중히 선택하고 고객들을 만족시켜 나가면, 소프트웨어 장인으로서 매우 성공적이고 즐거운 커리어를 만들 수 있다.

PART2 완전한 전환

part2 부분은 인재채용 및 면접에 관한 내용이 주로 나오기 때문에, 간단한 정리만 한다. 자세한 내용은 책을 읽기!

Chapter 9 - [인재 채용]

• 미래의 성공 가능성을 높이기 위해서는 열정적인 개발자를 찾아야한다. 열정적인 개발자는 개방된 사고로 항상 무언가를 배우기를 원하기 때문이다. 그들은 스스로 동기가 부여되어 혁신하고 기술 변화를 이끈다. 그들은 누가 무엇을 하라고 할 때까지 기다리지 않는다. 무언가를 시킬 때까지 그저 가만 있는 사람들은 회사를 정체 상태로 이끌어 피해야 할 사람들이다. 열정적인 개발자는 성장하기 위해 개인 시간을 기꺼이 투자한다.
• 당장 오늘은 미숙하더라도 그리 길지 않은 시간이 지나면 훌륭한 프로페셔널이 될 가능성이 매우 높다.

Chapter 10 - [소프트웨어 장인 면접하기]

• 면접은 쌍방향이다. 회사는 그들의 목적을 달성하는 데 도움을 줄 수 있는 개발자를 찾으려 하고, 개발자는 자신의 열망과 커리어 방향에 적합한 회사를 찾으려한다.
• 개발자 채용 면접은 개발자가 보아야 한다.
  • 좋은 개발자는 나쁜 개발자를 채용하지 않는다. 좋은 개발자는 그들 자신 보다도 더 훌륭한 개발자를 찾으려 노력한다. 좋은 개발자는 훌륭한 팀을 구성하는 것이 얼마나 중요한지 잘 알고 있다. 훌륭한 팀은 회사뿐만 아니라 개발자들 자신에게도 이익이 된다.
  • 회사는 개발자 채용 면접을 할 때 반드시 개발자로 하여금 면접관 역할을 하도록 해야 한다. 지원자 입장에서도 개발자가 아닌 사람이 면접을 하고 있다면 다른 회사를 찾아보는 것이 좋다.

Chapter 11 - [잘못된 면접 방식]

회사의 채용 절차를 하나하나 상세하게 뜯어보면 그 회사가 추구하는 가치와 문화를 엿볼 수 있다. 경험 많고 재능있는 개발자들은 자신이 일할 회사 또는 고객을 신중하게 가려서 선택한다.

• 잘못된 변접 방식
  • 똑똑한 척하는 면접관을 세운다.
    • 면접관의 사사로운 즐거움을 위해 지원자를 힘든 상황으로 몰아붙이고, 자신의 직함, 권한, 지식같은 것들로 지원자를 압도하고 싶어 해서는 안 된다.
    • 즉, 면접관이 거만하고 오만한 사람이 되어서는 안 된다.
  • 수수께끼식 질문을 던진다.
  • 답을 모르는 질문을 한다.
  • 지원자를 바보로 만든다.
  • 인터넷 접속을 막는다.
    • 솔루션들을 탐색하고 더 나은 문제 대응 방법을 찾는 것은 소프트웨어 개발자로서 갖추어야 할 핵심적인 능력이다.
  • 종이에 코드를 작성하게 한다.
  • 알고리즘 문제를 낸다.
    • 시스템 개발에 필요한 상당수의 업무들이 알고리즘에 대한 깊은 이해를 필요로 하지 않는다.
    • 물론 틀린 이야기는 아니지만 알고리즘 문제 대신 회사의 실제 프로젝트와 가까운 다른 연습문제를 통해서도 ‘문제 해결 능력’을 평가 할 수 있다.
  • 전화 면접을 한다.
• 요약
  • 좋은 개발자를 찾기는 꽤 어렵고 오랜 시간이 걸린다. 두뇌 장난같은 수수께끼를 내는 등 지원자를 바로처럼 느끼게 하는 면접은 훌륭한 지원자가 당신과 함께 일하기 싫어하게 만드는 지름길이다. 코딩 면접을 할 때 인터넷 접속을 끊거나 종이나 화이트보드에 코드를 작성하게 하는 것 또한 의미도 없고 지원자의 화를 복돋우기 십상이다.

Chapter 12 - [낮은 사기의 대가]

개발자들의 낮은 사기는 소프트웨어 프로젝트 실패의 주된 이유 중 하나다. 사기가 낮으면 회사 전체가 멈추기도 한다. 이장에서는 개발자들의 사기가 프로젝트와 회사에 어떤 영향을 미치는지 설명 되어있고, 맥 빠진 팀에 다시 열정을 불어 넣으려 할 때 소프트웨어 장인이 어떤 도움을 줄 수 있는지도 알아본다.

• 모든 회사들이 문제를 안고 있다. 어떤 구성원이든지 간에, 회사가 좀더 나아졌으면 하는 항목들을 쉽게 떠올릴 수 있다. 그렇다면 왜 그렇게 되도록 만들려는 노력들을 하지 않는 것일까? 그 이유에 대한 몇가지는 아래와 같다.
  • 자신에게 아무런 권한이 없다고 생각한다.
  • 그런 일을 이끌어가야 할 당사자가 되고 싶지 않다.
  • 그렇게 되기에는 복잡한 장애요인이 너무 많다.
  • 뭔가 바뀌는 것이 가능하다고 믿지 않는다.
  • 무엇이 더 나은 일인지 사람들의 동의를 받기 힘들다.
  • 아무 상관 없다. 그냥 출퇴근만 하면 된다.
• 요약
  • 직원들의 사기가 낮으면 회사가 파괴되기 쉽다. 동기부여가 되지 않는 사람들은 혁신을 창조하고 적용할 에너지가 없다. 일을 제대로 하고 책임을 지는 데도 관심이 없다. 그 사람들이 원래 그랬던 것은 아니다. 상황이 그렇게 만들어간다. 사람들의 열정을 없애는 데 정말 능숙한 회사들도 있다. 다행인 것은 관리층으로부터의 진심 어린 지원이 있다면 점진적으로 ‘낮은 사기’ 에 빠져 있는 상황을 역전시킬 수 있다는 점이다.
  • 개발자 들이 생각하는 커리어와 열정에 대해 공유해야 한다. 개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자다. 실력있는 개발자, 본받고 싶고 영감을 일으키는 개발자, 바로 소프트웨어 장인이야 말로 최고의 동기 부여가 될 수 있다. 개발팀에 열정을 불어넣고 동기를 부여하고 싶다면 소프트웨어 장인 몇 명을 팀에 영입해야 한다.

Chapter 13 - [배움의 문화]

배움의 문화를 하기에 시간이나 장소가 없다는 것은 변명이 될 수 없다. 관리자로부터의 지원이 없더라도 개발자들 스스로 서로 배우고 공유하는 배움의 환경과 문화를 쉽게 만들 수 있다. 장소가 없다면 가까운 카페를 찾아가자. 시간이 없다면 점심 시간이나 업무 전 시간을 이용하자. 매일 할 수는 없다면 일주일에 한 번만 하자.

• 많은 회사들과 관리자들은 다르게 생각하고 있지만, 배움의 문화를 만드는 것은 쉽고 비용이 거의 안 드는 일이다. 열정적인 개발자들에게 좋은 환경을 제공하기만 하면 된다. 그러면 그들 스스로 무엇을 배우고 공유 할지 여러 가지 방법을 찾을 것이다.
• 회사에도 품질과 혁신을 가져다 줄 것이다.

Chapter 14 - [기술적 변화의 실행]

개발팀에 기술적 변화를 도입하는 일은 참 어렵다. 사실 대단히 어렵다. 성공적으로 변화를 일으키려면 여러 종류의 사람들마다 어떻게 다르게 대응하고 어떻게 설득할지 알고 있어야 한다. 사람들은 바보가 아니다. 스스로가 믿고 있는 것들에 대해 서로 다른 이유와 서로 다른 의견을 가지고 있을 뿐이다. 그들의 의견은 과거의 경험을 바탕으로 하고 있거나, 당신이 모르는 정보를 알고 있거나, 자신감이 부족하거나 어쩌면 두려움때문일 수 있다.

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

Chapter 15 - [실용주의 장인정신]

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다.

• 고객이 소프트웨어 프로젝트를 통해 무엇을 성취하려 하는지 반드시 이해해야 한다.
• 품질은 비싼 것이 아니다. 스킬 부족이 잘 작성된 코드를 비싼 것으로 만드는 원인이다.
• 시간이나 비용과 같은 대가가 따르지 않는다면 항상 높은 품질을 선택한다.

Chapter 16 - [소프트웨어 장인으로서의 커리어]

• 열정. 이 단어 하나가 모든 것을 요약한다.
  • 개발과 자신의 직무에 열정적이다.
  • 문제를 단순한 방법으로 푸는 데 열정적이다.
  • 배우고 가르치고 공유하는 데에 열정적이다.
  • 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다.
  • 코드를 공유하고, 초보 개발자들을 멘토링하고, 블로그/책/동영상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다.
  • 기술 커뮤니티 활동에도 열정적이다.
  • 겸손하다.
  • 항상 무언가를 배울 자세가 되어있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다.
• 소프트웨어 장인의 사명
  • 더 나아지는 데 집중하고
  • 계속해서 자신의 커리어에 투자하며, 배우고, 가르치고, 공유한다.
  • 맡은 고객에게 항상 가치를 전달할 수 있도록 해야 한다.