소프트웨어 장인

소프트웨어 장인 | 산드로 만쿠소 - 교보문고

 

챕터

• 이념과 태도
  • 21세기의 소프트웨어 개발
  • 애자일
  • 소프트웨어 장인정신
  • 소프트웨어 장인의 태도
  • 영웅, 선의 그리고 프로페셔널리즘
  • 동작하는 소프트웨어
  • 기술적 실행 관례
  • 길고 긴 여정
• 완전한 전환
  • 인재 채용
  • 소프트웨어 장인 면접하기
  • 잘못된 면접 방식
  • 낮은 사기의 대가
  • 배움의 문화
  • 기술적 변화의 실행
  • 실용주의 장인정신
  • 소프트웨어 장인으로서의 커리어

 

요약

• 애자일 매니페스토의 12가지 원칙
  • 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
  • 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
  • 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
  • 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
  • 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 자원을 제공하고 프로젝트가 완료될 때가지 믿고 맡긴다.
  • 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.
  • 프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다.
  • 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발 속도를 계속 수용할 수 있어야 한다.
  • 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.
  • 단순함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.
  • 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
  • 개발팀은 장기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.

 

• 학습 방법의 종류
  • 독서
    • 특정 기술에 대한 서적
    • 특정 개념에 대한 서적
    • 행동양식에 대한 서적
    • 혁명적 서적(또는 고전)
  • 블로그
  • 기술 웹사이트
  • 소셜 미디어
  • 카타
  • 펫 프로젝트 (사이드 프로젝트)
  • 오픈 소스
  • 페어 프로그래밍

 

• 잘못된 면접 방식
  • 똑똑한 척하는 면접관을 세운다
  • 수수께끼식 질문을 던진다
  • 답을 모르는 질문을 한다
  • 지원자를 바보로 만든다
  • 인터넷 접속을 막는다
  • 종이에 코드를 작성하게 한다
  • 알고리즘 문제를 낸다
  • 전화 면접을 한다

 

• 소프트웨어 장인정신의 정의
  • 위키피디아: 소프트웨어를 개발할 때 개발자 스스로의 코딩 개념을 강조하는 개념이다. 이러한 개념은 주류 소프트웨어 업계가 개발자의 역량보다는 다른 것들, 즉 예산과 같은 것들을 우선시하는 병폐에 대한 개발자들의 반발로 나타났다.
  • 저자의생각: 마스터가 되어가는 긴 여정이다. 소프트웨어 개발자가 스스로 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.

 

 

기억에 남는 문장

 

21세기의 소프트웨어 개발

같은 경험을 10년 동안 열 번 반복하는 것과, 10년 동안 매년 서로 다른 경험을 하는 것 사이에는 어마어마한 차이가 있다.
10년 동안, 다른 프로젝트, 다른 기술, 다른 회사에서 일한 것과 10년 동안 같은 회사, 같은 프로젝트, 같은 사람, 같은 기술로만 일한 것은 크게 다르다.
…
코딩을 잘하거나 특정 언어나 프레임워크에 매우 익숙하다고 해서 선임 개발자가 되는 것은 아니다.

-p32

애자일

애자일은 어떤 단일 개념이 아니다.
애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다.
…
애자일 원칙의 절차적인 부분들은 팀에 정말로 중요한 것, 비즈니스에 가치가 있는 것에 집중한다.
즉, 올바른 목표를 향해 진행 중인지 확인할 수 있다.
…
애자일 원칙의 기술적인 부분들은 소프트웨어의 품질에 집중하여 팀이 결과물을 올바르게 만들어 가는지
즉, 목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게 한다.

-p38 ~ p39

피드백 시스템이 동작하려면 자기가 하는 일에 충분히 주의를 기울이고 뭔가 잘못되고 있거나 더 나은 방법이 있다고 느낄 때 자기 목소리를 내는 재능 있고 프로페셔널한 사람들이 있어야 한다.
절차에만 집중하고 소프트웨어 개발을 공장 라인처럼 취급하면, 그저 시킨 일만 하고 출퇴근하는 공장 노동자와 다를 바 없는 개발자들만 생긴다.
이렇게 되면 비효율적인 피드백 시스템이 되어 전체 프로젝트에 해를 끼친다.

-p49

 

소프트웨어 장인정신

소프트웨어 장인정신은 어떤 이념이나 마음가짐에 더 가깝다고 생각한다.
…
자신이 하는 일에 주인의식을 가지고 프로페셔널하게 행동하고, 고객이 원하는 것이 무엇이든 달성할 수 있도록 돕는다. 다른 개발자들에게 배우고 자신의 지식을 나누며, 경험이 부족한 개발자들을 멘토링하는 것들이다.

-p58

장인정신이라는 이름 자체에 대한 논란이 있다.
…
하지만 정말 중요한 것은 비유가 아니라 그 비유가 상징하고, 장려하는 가치와 행동들이다.
소프트웨어 장인정신은 시켜야만 일하는 역량 미달의 노당자가 아니라 소프트웨어 프로페셔널의 수준을 높여, 프로의 모습으로 일하는 소프트웨어 개발자를 지향한다.

-p59

5년 정도된 애플리케이션을 생각해 보자.
별도의 테스트 코드도 없고 그 애플리케이션이 어떻게 동작하는지 아무도 정확히 모른다고 하자.
소스 코드에는 비즈니스 용어는 하나도 없고 기술 용어, 개발 인프라 관련 용어들로 가득하다.
클래스와 메서드는 수백 라인, 최악의 경우 수천 라인의 코드로 되어 있다.
이러한 애플리케이션에 새로운 기능을 추가한다고 생각해 보자.
…
이런 애플리케이션을 상대할 때 가장 큰 문제는 두려움이다.
당신이 소심해서가 아니다.
전혀 이해할 수 없는 애플리케이션을 수정했을 때의 영향을 파악하고, 잘못된 수정에 대해서는 책임을 져야 하기 때문이다.
어디가 어떻게 동작하는지 이해하지 못한 상태라서 이 코드의 일부를 수정할 때 어딘가 다른 쪽이 잘못되는 것은 아닐까 불안하다.
수정 자체가 두려운 일이다.
…
소스 코드는 예측가능하고 유지보수될 수 있는 상태여야 한다.
코드를 수정할 때 어떤 일이 일어날지 개발자가 알 수 있어야 하고 수정 자체가 두려운 상황에 처하지 않도록 해야 한다.

-p68 ~ p69

매니페스토의 계속해서 가치를 더한다라는 의미는 신규 기능을 추가하거나 버그 수정만을 뜻하지는 않는다.
코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고, 테스트 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것을 포함한다.

-p70

상대에게 배우는 것은 더 나아지기 위한 최선의 방법이다.
블로그에 글을 올리고, 오픈 소스 프로젝트에 기여하고, 작성한 코드를 공개하고, 지역 커뮤니티에 참여하고, 다른 개발자와 페어 프로그래밍을 하는 것은 업계의 발전을 위해 할 수 있는 방법들이다.
…
훌륭한 개발자는 더 뛰어난 개발자와 일하고 싶어 한다.
훌륭한 개발자는 뛰어난 기업에서 일하기를 갈망한다.
서로를 더 성장시킬 만한 사람들과 함께 일하고 지식을 나누며 상대에게 배우는 것, 그저 같은 사무실을 쓰는 동료이기보다 서로에게 영감을 주는 프로페셔널이자 친구를 기대한다.

-p72

 

소프트웨어 장인의 태도

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

-p77

내가 일하고 있는 회사에서 책을 사주지 않거나, 교육 프로그램이나 콘퍼런스에 전혀 보내주지 않는다면 어떻게 할 것인가?
…
고객을 만족시키기 위한 투자는 스스로 해야 한다.
…
보통 이러한 전문가들은 스스로의 돈과 시간을 들인다.
…
소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다.
이는 스스로 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다.
나 자신의 커리어의 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다.

-p78 ~ p79

꼭 경험 많은 프로페셔널만 블로그를 만들어야 한다고는 생각하지 않는다.
모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다고 본다.
경험과 발전을 공유함으로써 훌륭한 프로페셔널 커뮤니티를 이루는 데 도움이 되어야 한다.
…
우선 블로그는 우리의 배움과 자기 계발에 대한 기록의 장으로 두는 게 좋다.
…
나 자신을 위한 기록이 가장 우선이다.
…
현재 배우는 것이 무엇이든 글로 서서 기록을 남기는 것은 가치가 있다.
…
내가 쓴 글이 더 경험 많은 개발자들에게 평가받는 것에 대해서 걱정하지 말자.
그런 일은 일어나지 않는다.
구글로 검색할 때 첫 번째 링크가 도움이 안 되면 그저 아무 생각 없이 바로 다음 링크를 찾아간다.
개발자들은 무료로 공유한 다른 개발자들의 관점과 생각들에 대해 비판에 앞서서 감사하는 마음을 가질 것이고 그래야만 한다.

-p84 ~ p85

프로페셔널로서의 삶이 건강해야 가족의 삶도 건강해진다.
프로페셔널로서의 삶이 건강하지 못하면, 낮은 소득에 대해서 걱정하고, 업무에 대해서 걱정하고, 직장에서 해고되지는 않을지, 해고되면 다른 좋은 직장을 찾을 수 있을지 걱정 속에 살아야 한다.
이렇게 되면 개인 영역의 삶가지 심각하게 나쁜 영향이 간다.
경쟁력 있는 프로페셔널로서 좋은 인적 네트워크를 가지고 시장이 요구하는 기술을 습득하고 있다면 프로페셔널로서의 삶에 대해서 크게 걱정하지 않아도 된다.

-p102

 

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

항상 ‘아니오’라고만 얘기하는 것은 프로다운 태도가 아니다.
모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다.
…
아무런 대안 없이 그냥 안된다고만 하면 그 대답을 듣는 사람 입장에서는 뭔가 할 수 있는 여지가 없기 때문에 상황에 별 도움이 안 된다.

-p116

 

동작하는 소프트웨어

코드는 정원처럼 지속적인 유지보수가 필요하다.

-p128

기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다.
이미 깨끗한 상태를 더럽혀서는 안 된다.
즉, 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다.

-p132

 

기술적 실행 관례

실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다.
테스트 주도 개발(TDD)을 한다면 그것을 하거나 하지 않거나 둘 중 하나다.
지속적인 통합도 하거나 하지 않거나 둘 중 하나다.
어떤 사람들은 “우리는 어떤 때는 TDD를 한다.”라고 말한다. 부분적인 것은 도움이 되지 않는다.
…
실행 관례를 꾸준히 실행하지 않고 부분적으로 하다가 안 한다면 그것이 실제 효과가 있는지는 알 수가 없다.

-p152

실용주의는 소프트웨어 장인이 가져야 하는 최선의 역량 중 하나다.
…
무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다.
항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다.
지금 하는 방법보다 더 나은 방법이 없는가?
우리가 선택한 실행 관례가 우리 프로젝트에 적합한가?
그 실행 관례의 가치는 무엇인가?
무언가 다른 것을 시도해 볼 시점인가?

-p162

 

길고 긴 여정

어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다.
이것은 장기적인 목표이고 중간에 많은 것이 바뀔 수 있다.
커리어를 몇 년짜리 프로젝트라 여기고 어떻게 관리할지 생각해 보자.

-p169

거쳐가는 모든 직장, 프로젝트들 하나하나를 투자로 인식하는 것이 가장 중요하다.
직장은 단순히 돈을 버는 곳이 아니라 큰 목표를 향해 다가가는 단계 중 하나다.

-p171

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

-p172

 

낮은 사기의 대가

항상 그렇지만 상황이 안 좋아지면 제일 먼저 가장 능력 있는 개발자들이 떠나간다.
-p233

구성원들이 동기 부여가 되어 있지 않고 그들의 일이 어떻게 되든 상관하지 않으면 조직을 변화시킬 방법이 없다. 구성원들에게 새로운 방식으로 일하기를 설득하기 전에 다음의 것들을 먼저 생각해보아야 한다.
일을 제대로 할만한 동기 부여가 되어 있는가?
스스로의 일을 개선하는 데 진정 관심을 가지고 있는가?
일을 더 잘할 수 있도록 지속적으로 자기 계발을 하고 있는가?
회사가 하는 일이 사회에 기여하고, 해야 할 가치가 있다고 느끼고 있는가?
회사가 해내는 일을 좋아하는가?

-p236 ~p237

 

배움의 문화

개발자들을 학습 모임에 강제로 참석시키면 상황은 극도로 안 좋아진다.
대신 계속 초대장을 보내자.
…
참여하기 싫은 사람을 참여시키려고 기존에 자발적으로 참여하고 있는 사람들이 흥미를 잃게 만드는 상황을 만들지 않는다.
사람들이 참여하기 싫어한다면 그냥 그대로 둔다.
…
참여하지 않는 사람들에게 실망하거나 화내지 말자.
참여자의 숫자가 많든 적든 애초의 동기를 꾸준히 유지해야 한다.
개방된 커뮤니티의 원칙 중 하나는 ‘들어오는 사람이 초대받은 사람이다’라는 태도다.

-p256

개인 시간을 들여 공부하고 연습하는 데 상사의 허락을 구할 필요는 없다.
…
심지어 업무 시간에 공부를 하더라도 상사에게 허락을 구하지 않는다.
책임 있게 행동하면 될 뿐이다.
팀이 스스로 더 나아지기 위해서 훈련하는 것에 대해 민감하게 반응하고 불평할 관리자는 없다.
…
단, 학습 활동 때문에 업무를 소홀히 해서는 안 된다.
상식적으로 책임있게 행동해야 한다.

-p257

 

기술적 변화의 실행

당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다.
준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야 한다.
무슨 일이 일어나든 항상 진실을 말해야 한다.
유일한 충고는 인격적으로 못돼 먹은 사람이 되지 말라는 것 하나뿐이다.

-p273

틈틈이 공부하고 준비해서 기술의 사용법을 시연할 수 있을 정도로 역량을 키우면 변화를 이끌어 나가는 데 큰 힘이 된다.
‘무지’에 빠진 사람에게 지식을 주고,
‘대중’에게 방향을 제시하며,
‘냉소주의자’를 납득시키고,
‘트라우마’에 빠진 사람을 이해할 수 있다.
‘너무 바쁜’ 이들이 걱정하는 시간 소모를 학습 곡선을 짧게 하는 방법으로 해결할 수 있다.

-p276

 

실용주의 장인정신

추상화를 도입할 때마다 즉, 간접처리 단계가 추가될 때마다 비용이 발생한다.
이전에 순서대로 읽기만 하면 쉽게 이해되던 코드들이(간접 호출도 없고 급여처리 방식도 하나뿐인), 이제는 좀 더 이해하기 어려워졌다.
…
당장의 합당한 이유 없이 단지 ‘미래를 대비해야 한다’는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션이 엉망이 된다.

-p304

 

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

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

-p309

앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면, 그대는 움직여야만 한다.

-p318