소프트웨어 장인 - 산드로 만쿠소

Main Topic

개발자로서의:

• 경험담
• 조언

Summary

요즘 개발

• 개발자의:
  • 실력은 연차와 무관
  • 역할 변화
    • 과거: 단순한 코더(Coder)
    • 현재: 프로페셔널 ← SW 장인정신이 필요한 이유

애자일

• 주안점: 변화 → 빠른 피드백
• 분류
  • 절차적(올바른 방향)
  • 기술적(올바른 실행)
• 특징
  • (개발자들의) 책임과 권한이 많아짐 + 필요역량의 수준도 높아짐
• (애자일) 매니페스토

  우리는 스스로 소프트웨어를 개발하고, 다른 사람들이 개발하는 것을 도와주면서 더 나은 소프트웨어 개발 방법들을 찾고 있다. 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.

  • 절차와 도구보다는 개성과 화합을
  • 방대한 문서 작업보다는 동작하는 소프트웨어를
  • 계약 조건에 대한 협상보다는 고객과의 협력을
  • 계획을 따르는 것을 넘어서서 변화에 대처하는 것을

  더 가치있게 여긴다. 좌측의 사항도 가치가 있음을 인정하지만 우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.

• (애자일) 원칙
• 목적
  • (고객, 회사, 동료와의) 신뢰와 협력 → 시너시를 높이는 것
  • SW 개발에 있어, 투자 대비 효율을 높이는 것

소프트웨어 장인정신

• 정의
  • 개발자로서의 마음가짐 (책임감, 프로페셔널리즘, 실용주의, 개발자로서의 자부심)
• 비유
  • 대장장이, 장인 → 중요한 것은 이러한 비유가 상징하고 장려하는 것
• (소프트웨어 장인정신) 매니페스토

  소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.

  • 동작하는 소프트웨어 뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
  • 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
  • 개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
  • 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,

  이 앞의 항목들(일반 굵기)을 추구하는 과정에서, 다음 항목들(볼드체)이 꼭 필요함을 의미한다.

  • 핵심 주제(부제에 드러남): “프로페셔널 소프트웨어의 개발의 수준을 높인다”
  • 비판점
    • 애자일 매니페스토와 달리 너무 당연한 내용
    • 중요한 것은 (이런 당연한 매니페스토의) 실천

소프트웨어 장인의 태도

커리어의 주인은 누구인가?

커리어를 회사나 누군가에게 맡겨놓듯이 흘러가면 안되고, 최대의 효율로 고객을 만족시키는 방향으로 스스로 발전해 나갈 수 있어야 함

태도로 가져야 할 요소

• 자기계발
  • 독서, 블로그, SNS 등을 통한 읽기: 각기 장단이 있음.
• 커뮤니티
  • 커뮤니티에는 열정적인 사람이 많으므로, 배울점이 있음
• 호기심
  • 호기심은 개발자의 덕목
  • 스스로의 무지를 알고, 호기심을 가지고 모르는 것을 알아나가는 자세
• 워라밸
  • 시간이 없다는 것은 변명, 시간을 잘 배분하자

프로페셔널리즘

무엇이 프로페셔널한 것인가.

• 영웅이란 없다.
• 솔직해야 한다.
  • ‘아니오’ 라고 말할 수 있어야 한다. 그러나 대안도 함께 제시할 줄 알아야 한다.
  • 투명하게 상황을 고객이나, 팀메이트와 공유해야 한다.

불가능한 것에 대해서 ‘아니오’ 라고 말하지 않고, 프로젝트의 상황에 대해 고객에게 공유하지 않으며, 미련하게 야근하며 영웅이 되어보겠다고 하는 것은 결코 프로페셔널한 자세가 아니다. 옳지 못한 의사결정에 대해 ‘아니오’ 라고 말하며, 프로젝트의 상황을 투명하게 고객에게 전달하고, 고객이 진정 원하는 것을 달성할 수 있도록 조언하고 돕는 것이야말로, 진정 프로페셔널한 자세다.

동작하는 소프트웨어

• 동작하기’만’ 하는 소프트웨어로는 부족
• 소프트웨어 개발은 정원돌보기와 같다
• ‘시간’ 이란 단순히 개개인의 시간이 아니라, 소프트웨어 전체에 들어가는 ‘시간’을 생각해야한다.
  • 테스트 코드를 작성하는 것도 ‘전체 시간’을 아끼기 위해서라는 방향으로 접근하는 것이다.

기술적 실행 관례

• 올바른 일과, 올바른 실행
  • 애자일이 올바른 일에 대해 피드백을 준다면, 기술적 실행 관례는 올바른 실행을 하고 있는지 피드백을 준다.
• 상황논리는 핑계
• 중요한 것은 빠른 ‘피드백’
  • TDD
  • TDD + 지속적 통합: 개발자가 코드를 올릴 때마다 테스트를 수행하여, 항상 시스템을 배포 가능한 상태로 유지
  • 페어프로그래밍: 실시간 코드리뷰
• 리팩토링

  실용주의적인 관념 없이 리팩토링 하는 것은 대단히 위험하다. 프로페셔널로 행동한다는 것은 트레이드오프를 이해한다는 것이다.

  • 리팩토링의 대상
    • 더 자주 변경되는 부분
    • 해당 부분을 이해하여 변경할 필요가 있는 부분

책임감

중요한 것은 실행 관례 자체가 아니라, 비지니스적 가치 에 있다.

• 실행관례를 따를 경우의 비지니스적 가치를 이해
• 실행관례를 따르지 않아야 하는 상황에서는, 그것이 어떤 비지니스적 가치가 있는지 이해하고, 더 나은 선택을 할 수 있도록 책임감 을 가져야 한다.

실용주의

• 현재 훌륭한 실행 관례도, 나중에는 더 좋은 것으로 대체될 수 있다.
• 중요한 것은 지속적으로 일하는 더 나은 방법을 찾고, 고객을 만족시켜야 한다는 것이다.
• TDD 가 되었든, 무엇이든 절대적인 진리로 바라보지 말고, 끊임없이 질문하고 더 나은 방향을 찾아야한다.
  • 실행관례 도입을 위한 도입을 해서는 안된다.

커리어와 동기

어디로 가고 있는지 모르면, 결국 가고 싶지 않은 곳으로 간다 - 요기 베라 Yogi Berra

결단과 집중

• 커리어를 하나의 큰 장기 프로젝트로 보고, 이를 향해 나아가야 한다.
• 그러나 나아가야 할 목표를 알 수 없다면, 다양한 방법으로 내게 열린 길을 확장해 두는 것도 좋은 방법이다.
  • 예를 들어, 컨퍼런스 연사로 참여, 개인 블로그, 기술 습득 등

투자로서의 일터

• 직장을 선택할 때, 내 커리어적인 측면의 투자로 생각해야 한다.
• 이기적으로 하라거나, 고객의 관점은 무시하고 이력서를 채우라는 말로 오해해서는 안된다.

개발자의 원동력

• 자율성, 통달, 목적의식

회사 안에서의 커리어

• 방향성의 일치
  • 소프트웨어 장인은 자신의 커리어 방향과 일치하는 경우에만, 회사 안의 커리어를 수용한다.
• 여정의 중요성
  • 소프트웨어 장인은 그들의 커리어가 긴 여정이며, 어떤 종착지에 도달하는 것보다 그 여정 자체가 중요함을 이해한다.

채용

채용의 방법

• 공고
• 커뮤니티
• 추천 채용

채용시 중요한 것

• 단순히 경험한 기술의 나열이 아닌, 열정
• 공고도 이러한 점을 고려

선별

• 열정을 중요하게 봐야 하지만, 이로는 선별 조건에 적합하지 않을 수 있기 때문에 아래와 같은 것들을 고려한다.
  • Github 계정
  • 블로그
  • 오픈 소스 활동
  • 기술 커뮤니티나 사용자 그룹 활동 내역
  • 펫 프로젝트 내용
  • 트위터 계정
  • 좋아하는 기술서적 목록
  • 참석했거나 발표했던 컨퍼런스

면접

• 면접은 쌍방의 이해 관계를 맞춰보는 과정
• 기술도 중요하지만, 개발자로서의 자질이 더 중요

방식

• 자유토론과 같아야한다. (준비할 수 있는 종류의 것이 아니기 때문)
• 면접시 정말 필요한 능력에 대해 물어볼 것
  • 설계능력이든, 가치있게 여기는 점이든, 중요하게 생각하는 것을 물어보고, 이외에 불필요한 것들은 질문할 필요가 없다.
• 마인드맵 방식 질의
• 페어 프로그래밍(압박 X, 실력발휘할 수 있도록 도와줘야 한다.)
• 개인 컴퓨터를 지참한 면접

면접 전에, 스스로에게 “소중하게 생각하는 가치”, “동료들로부터 기대하는 태도”, “직무의 핵심 스킬” 등을 질문해보자. 이것이 채용의 기본 요건이 된다.

• 새로운 프로젝트를 위한 인원을 뽑을 경우
  • 과거 프로젝트를 성공적으로 이끈 경험
  • 노련함(특정 분야의 스페셜리스트보다 폭넓게 조예있는 기술분석 전문가도 필요하다.)
• 지원자와 회사 모두 면접을 어떻게 하는지 모두가 알아야 한다.
• 개발자 채용은 개발자가 해야한다.

내 요약

• 팀에 “필요한 역량”을 가진 “열정” 있는 개발자를, “함께 일할 개발자들”이 뽑는 것

면접관이 피해야 할 것

• 똑똑한 척 하는 것
• 면접자를 배려하지 않는 것
  • 항상 면접자를 프로페셔널로 생각하고, 존중해야 한다.
• 의미 없는 코딩
  • 인터넷 연결 끊기
  • 종이 손코딩
  • 알고리즘 테스트
• 전화 면접

낮은 사기

현상

애자일 행오버 라고 불리는 문제

• 목적없이 출근”만” 하는 개발자
• 원인
  • 동기와 목적의식의 부재

사례 소개

• 동기부여에 실패해, 고객이 손실을 얻게 된 사례
• 동기부여에 성공해, 프로젝트를 다시 성공적으로 이끈 사례

극복(개발자들에게 열정 불어넣기)

• 소프트웨어 장인을 동료로 채용 -> 최고의 동료가, 개발자들에게 열정을 불어넣는 최선의 방법이다.

배움의 문화

• 공유
  • 북 클럽, 테크 런치, 그룹 토론회 등 여러가지 방법을 책에서 제시하고 있지만 핵심은 “공유”
  • 스스로 가진 지식을 다른 개발자와 적극적으로 공유하고, 적극적으로 “피드백(지식의 공유)”을 주고받는 것 (페어 프로그래밍 등)
• 열정
  • 결국 모든 방법들을 동원해도, 배움의 문화를 만드는게 쉽지 않을 수 있으나, 중요한 것은 1부 내내 이야기했던 것처럼 “열정”
  • 공유하는 모임이 아니어도 스스로 공유하는 자리를 만들어둔다는 느낌으로 접근할 수도 있다. 즉, “열정”있는 개발자들이 스스로 올 수 있는 자리를 마련하는 것이 중요하다.

기술적 실행

기술적 실행을 하는 데에는 상사나, 동료 개발자 모두를 설득하는 일이 쉽지 않을 수 있다. 어떤 종류의 장애물들이 있고, 어떻게 준비하고 실행해 나가야 하는지를 설명한다.

• 장애물
  • 회의론(냉소주의, 무지, 트라우마, 팬보이, 상아탑 아키텍트)
    • 위 예시의 성향을 가진 개발자, 상사, 비지니스 팀을 설득하는 것
  • 두려움
    • 두려움은 우리를 둘러싼 일들을 올바로 변화시킬수 없게 한다.
    • 이는 이기적이고, 부도덕적이기까지도 하다. 잘못된 것에 대해서 피드백 하지 않는 것은 결코 프로페셔널한 자세가 아니다.
• 준비
  • 실력과 태도
    • 스스로 “실력” 을 갖추면 상기의 장애물들을 극복할 수 있다.
    • 스스로 먼저 모범을 보이는(TDD 정착을 원한다면, 본인부터 TDD로 코드를 작성하는 것) “태도” 역시 중요하다.
  • 장소
    • 바꾸고 싶은 부분이 많이 있더라도, 결국 모든 것을 혼자 바꾸려고 하는것은 어리석은 일이다.
    • 중요한 것과 그렇지 않은 것(일종의 장소)을 적절히 나누어야 한다. 물론 이는 비지니스나 팀이 추구하는 가치에 따라 다를 수 있다.
• 방식
  • “점진적” 으로 바꾸어 나가면, 회의론자들을 설득하기에 훨씬 저항이 적다.
  • “상사를 설득할 필요는 없다”
    • 테스트를 별도의 아이템으로 보지 않고, 아이템 안에 내제된 것으로 봐야 한다.
    • 버그가 가득한 코드를 작성하라고 말하는 상사는 없기 때문
  • “모범” 을 보여서, 설득해 나가자.
    • 이를 통해 내가 전파하려는 기술적 실행 방법에 대한 장점을 이해시킬 수 있을 것이다.
• 장애물 극복
  • 본인의 “역량” 을 키우는 것이 전제가 되어야 한다.
  • “열정”을 “공유”하고, “모범”을 보임으로써 회의론자들을 설득해 나갈 수 있다.
    • 예시) 자신이 공부한 것을 적극적으로 가르쳐주어, 다른 사람의 학습곡선을 줄여주는 등
  • 또한 모든 사람이 이러한 기술적 실행의 주체가 될 수 있도록 해야 한다.
• 권한과 책임
  • 상기에 언급한 기술적 실행을 수행한다는 것은 “권한” 과 “책임” 을 모두 가지는 것임을 알아야 한다.

실용주의

소프트웨어 장인정신을 어떠한 방법론이나 실행만을 의미하는 시각으로 바라봐서는 안된다. “항상” 이나 “절대” 같은 것은 없으며, 그 때의 상황이나, 고객이 필요한 것에 맞추어 최대의 가치를 추구하는 방향이 되어야 한다. 예를 들어 항상 최대한을 추상화하고 확장을 고려한다거나, 항상 특정 디자인 패턴을 추구한다거나, 리팩토링을 위한 리팩토링을 하는 등등의 방향은 그다지 실용적이라고 볼 수 없다. 우리는 항상 단순하고 빠른 솔루션을 추구해야한다. 이를 위해 실행 관례들의 가치를 이해하고, 몸에 익힐 필요가 있다.

• “품질” 은:
  • 선택사항이 아니다.
  • 비싸지 않다.(예를 들어 TDD를 익히기까지의 시간은 길 수 있지만, 이후에 TDD 를 이용하는 것이 개발에 더 많은 시간이 든다고는 할 수 없다.)
• “항상” 이나 “절대” 해야할 것이란 없다. 실용주의적인 태도를 가져라
  • 당시의 상황이나, 요구사항에 의해 얼마든지 달라질 수 있다.
  • TDD 등이 강조되는 것은, 대부분의 상황에서 더 나은 방향이기 때문이지, 절대 지켜야할 규약이기 때문이 아니다.
• 단순한 설계를 위한 4가지 원칙
  • 모든 테스트의 통과
  • 중복의 최소화
  • 명료성의 최대화
  • 구성요소의 최소화

소프트웨어 장인의 커리어

앞선 모든 챕터에서 강조되었듯 소프트웨어 장인에게 필요한 것은 “정직” 과 “용기” 같은 것들이다. 잘못된 요구사항에 대해 잘못되었다고 “정직”하게 피드백하고, “대안을 제시” 할 수 있어야 한다.

또한 고객에게 “비지니스적 가치”를 제공하려 노력하는 프로페셔널이 되어야 한다. 커리어를 추구함에 있어서는 소프트웨어 장인 정신은 어떠한 방법론이 아니라 이데올로기적인 것이라는 것을 알아야한다.

• 커리어를 추구할지 모르겠으면, 이것저것 다 해봐라
• 소프트웨어 장인은 소프트웨어 업계의 발전을 추구해야 한다.

---

이 책의 핵심 주제

문제를 단순한 방법을 풀어내는 것에 “열정”적이어야 한다.