소프트웨어 장인 (프로페셔널리즘, 실용주의, 자부심) 책 정리

소프트웨어 장인 (The Software Craftsman)

- 산드로 만쿠소 지음

 

1. 21세기의 소프트웨어 개발

• 예전의 개발 문화
• 새로운 문화 (최근)
  • 소프트웨어 장인정신이 필요해졌다.

2. 애자일 (Agile, 민첩)

• 나오게 된 배경은 이전 시대의 워터폴 방식의 부족함에서 출발
• 분류
  • 절차적 관점: 올바른 목표를 향해 가는지 확인
  • 기술적인 관점: 목표한 것을 올바르게 실행하고 있는지 확인
• 애자일 메니페스토(menifesto, 선언문) 원칙들
• 실제 애자일을 실행할 때 기업들은 오해를 한다.
  • 절차적인 것을 중시하고 기술적인 것은 무시한다.
  • 소웨 개발자들의 기술은 완벽하고 절차만 고치면 된다는 식의 사고방식은 안된다.
  • 기업 차원에서 소웨 장인정신이 필요하다

3. 소프트웨어 장인정신

• 정의: 소프트웨어 개발의 프로페셔널리즘에 대한 것 (이념이나 마음가짐)
• 소프트웨어 장인정신 메니페스토 (menifesto, 선언문)
  • 스스로 끊임없이 기술연마, 다른 사람들의 기술연마를 도움
    -> 궁극적으로 Professional SW 개발 수준을 높인다.
  1. 동작하는 소프트웨어 뿐만 아니라, 정교하며 솜씨있게 만들어진 작품을,
  2. 변화에 대응하는 것 뿐만 아니라, 계속해서 가치를 더하는 것을,
  3. 개별적으로 협력하는 것 뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
  4. 고객과 협업하는 것 뿐만 아니라, 생산적인 동반자 관계를,

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

• 고객을 만족시키기 위한 투자는 스스로 해야한다.
• 자기계발
  1. 독서
  2. 블로그
  3. 기술 웹사이트
• 끊임없는 훈련
  1. 카타
  2. 토이프로젝트
  3. 오픈소스
  4. 페어 프로그래밍
• 사회활동 (다른 개발자와 어울림)
• 워라밸 (집중과 삶의 균형)

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

• 저자의 예시, 경험 (상파울루) : 손해보면서라도 해내고 싶다는 영웅심리 등
• '아니오' 라고 말하는 방법 배우기 (예시, 마케팅 - PM - 개발팀 간의 실패 이야기)
• 대안 제시: 아니오 라고 할 때는 대안을 준비해서 제시한다.
• 깨어있는 관리자는 개발팀과 동고동락 한다.

6. 동작하는 소프트웨어

• 최근에는, 동작하는 소프트웨어 -> 고품질의 동작하는 소프트웨어 로 변화하고 있다.
• 소프트웨어를 운영하는 것은 정원 돌보기와 유사함: 꾸준히 해야 일이 적음
• 코드 품질과 기능구현 시간의 상관관계는 반비례 관계
• 시간에 대한 인식
  • 기술적인 부채를 만들지 말자
  • 그러기 위해서 테스트 작성은 중요하다.
  • 단위테스트 작성은 별도로 스케줄 잡는 작업이 아니고, 코드 작성에 녹아있어야 한다.
• 레거시(legacy) 코드
  • 그린필드 프로젝트만 있지 않다. 브라운 프로젝트가 훨씬 많다.
  • 재미있는 도전으로 받아들이고, 부분으로 시작해서 확대해나간다.

7. 기술적 실행 관례

• 관리자나 개발자 등이 TDD, XP 등의 기술적 실행 관례에 관심을 가져야 하는 이유
  • 무슨 가치가 있는지, 동료를 설득하기 위함과 상통함
• 애자일은 빠르고 짧은 피드백 루프로 올바른 일(right things)을 하는 것을 확인.
• 소프트웨어 장인정신은 기술적 실행 관례에 집중해서 올바른 실행을 하는 것을 확인.
• 애자일의 기술적 실행 관례는 적용 전에 실상황 파악을 잘 해야한다.
• 절차적 관례 > 실행적 관례 라고 애자일 코치나 컨설팅회사들이 주장하지만 아니다. 둘 다 중요하다.
• 기술적 실행관례 도입으로 현재 일하는 방식과 비교해서 가져올 이익에 집중한다.
  • 빠른 피드백 루프
  • 요구사항과 비용에 대한 더 나은 이해
  • 지식 공유
  • 줄어드는 버그
  • 전체적으로 자동화되고 릴리즈가 빨라짐
• 실행관례 (XP 등) 예시 및 장점
  • 자동화된 테스트: 피드백 루프 빠름, QA를 패스하여 비지니스 시간 단축
  • 테스트 먼저: 하나씩 집중, 잘 정리된 요구사항 역할, 오버엔지니어링 줄임
  • TDD: 테스트가 코딩 방향을 주도하면 복잡한 코딩 불가함
  • 살아있는 문서역할을 함 설계, 단순성, 유지보수 용이성에 빠른 피드백
  • 지속가능한 통합: 코드 통합 시 전체 테스트 -> 버그가 쌓이지 않게, "일단 멈추고 버그부터 수정"
  • 페어프로그래밍: 코드리뷰는 피드백 루프 주기가 길다.
    즉각적인 피드백, 코딩 표준 정의/유지에 도움
  • 리팩토링: 자주 건드리는 곳의 작은 부분에서 시작 (꼭 필요한 부분)
    유지보수 쉬운 클린코드는 개발속도를 높이고, 버그 가능성을 낮춘다.
• 실용주의
  • 진리는 없고 계속 더 나은 방법을 찾아서 고객을 만족시킨다.
  • 개방적인 사고방식을 갖는다.
  • 항상 무엇을 하고 있고, 왜 하고 있는지를 질문한다.
• 실행관례 적용 전, 무엇을 이루려는지 논의한다.
  • 그 이후에 달성하기 위한 실행 관례를 설정한다.

8. 길고 긴 여정

• 저자 경험 (브라질~ 영국)
• 어디로 가고 싶은지 (어떤 목표인지) 설정하고 해나간다.
  인생을 큰 장기 프로젝트 개념으로 생각한다.
• 기회를 만들기 위해 할 수 있는 활동들
  • 컴포트 존을 벗어나서 새로 공부, 기술적 지식 확장 (새로운 프로그래밍 언어나 기술 배움)
  • 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여
  • 다른 개발자, 비지니스 맨들과 교류
  • 새로 배운 것, 지금 하는 것들을 블로깅
  • 오픈소스 플젝 참여
  • 프로젝트 만들고 공개
  • 컨퍼런스 참석, 연사로 참석
• 회사 등의 일도 커리어 투자의 개념으로 접근 (이기적 마음으로 커리어 활동 x)
• 지식은 영원하고 돈과 안정은 영원 할 수 없다.
• 좋은 개발자의 원동력
  • 돈: 기본
  • 자율성, 통달, 목적의식
• 일(직장)을 신중히 선택하고 고객들을 만족시켜 나가면, SW장인으로서 좋은 커리어 가능

9. 인재 채용

• 새 인재 채용 시, 기업에서는 현재의 문제를 더 키우지 말아야 한다.
  • 문제를 파악하고, 해당 문제가 없는 사람을 채용해야 한다.
• 채용 결과는 뽑힌 사람 책임보다는 뽑은 사람 책임이 된다.
  • 면접관 중요, 기준 설정이 중요
• 전형적인 직무요건만 나열하는 것을 지양
  • 열정, 미래의 성공 가능성을 높여준다.

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

• 생산적인 파트너십이 중요함
• 면접은 적합한 사람 + 회사에 남아있을 수 있는 사람을 찾는 것
  • 회사/프로젝트 장단점을 다 설명해줄 필요가 있다.
• 지원자/회사 모두 서로 파악해나가는 시간
  • 원샷면접/다단계면접, 질문의 내용 등으로..
  • 좋은 면접은 자유토론과 같다. -> 이를 통해 실제 경험을 알아내기 좋다.
• 회사에선 필요한 가치를 먼저 찾고, 필요한 것만 면접 과정에 넣는다.
• 방법: 토론식, 마인드맵핑, 페어프로그래밍 등
• 면접은 서로에게 중요한 시간이다.

11. 잘못된 면접방식

• 똑똑한 척하는 면접관
• 수수께끼식 질문
• 본인도 답 모르는 질문 (직무 연관이 없는 질문)
• 지원자를 바보 만듦
• 인터넷 접속 금지 (코드 작성 시)
• 종이에 코드 작성
• 알고리즘 문제
• 전화면접 (불가피하면 가능)

12. 낮은 사기의 대가

• 개발팀 사기는 중요함. 기운 빠진 팀에 소프트웨어 장인이 어떤 도움을 줄 수 있을까? 열정.
• 애자일: 절차적 + 기술적 쏠림없이 다 중요하게 적용되어야 한다.
• 낮은 동기부여 -> 회사의 일하는 방식 개선이 불가하다.
  -> 소프트웨어 장인이 열정을 불어넣을 수 있다.

13. 배움의 문화

• 사람들 스스로 모든 것을 더 나아지게 하고 싶어하는 동기부여
  • 개발자들에게 권한을 위임하고 스스로 배움의 문화를 만들어 갈 수 있게 한다.
  • 개발자들이 할 수 있는 일
    • 북클럽 가입
    • 테크런치 (기술 관련 난상토론)
    • 그룹 토론회
    • 업무 교환 (얼마의 기간동안)
• 소웨 장인들의 배움의 문화 조성을 위한 조언
  • 모범을 보인다.
  • 관심 보이는 이들이게 집중한다.
• 배움의 문화는 개발자 포함 모두가 해나가야 할 일

14. 기술적 변화의 실행

• 개발자, 관리자, 아키텍트들이 기술적 변화를 이끌려면, 맹신에 빠진 개발자들을 잘 다루어야 한다.
• 기술적 변화에 대한 회의론 종류들
  • 무지, 대중(팔로워), 냉소주의, 트라우마, 너무 바쁜, 상사, 몰상식, 피해망상, 무능력 등등
    • 바꾸려면 논쟁이 필요하고 -> 따라서 용기가 필요하다.
    • 논쟁의 방법: 상대의 언어로 말하기, 말할 내용에 대해 스스로 잘 이해하기, 상대방 존중, 경청하는 법 알기
• 기술적 변화를 시작하는 방법
  • 신뢰를 쌓으라
  • 전문성 확보
  • 모범을 보여라
  • 부분적으로 시작한다
  • 점진적 반복/관찰/수용
• 소프트웨어 장인으로서 기술적 변화 도입을 위해서.. 소통을 명확히 하고, 신뢰를 이끌어낸다.

15. 실용주의 장인정신

• 고품질은 고비용이다 -> 편견
• 품질은 선택사항이 아니고, 최소한의 품질을 유지한다.
• 소프트웨어 장인은 TDD 같은 실행 관례들을 마스터하고 있고, 시작부터 짧은 주기로 고객에게 전달하는 것을 목표로 한다.
  • 딜리버리 속도가 빠르다.
  • 애플리케이션 크기가 커질수록 XP 실행관례를 체득한 소웨 장인이 훨씬 빠르다.
• TDD는 항상 필요한 것은 아니다? (그렇다, 그렇지만 논의가 무의미하다)
  • 적응되고 체득하면 모든 부분에서 훨씬 좋다 (UI 제외)
• 리팩토링 -> 레거시 수정 시 or 새로 추가 시 영향 받는 레거시
  위의 상황들에 대해 리팩토링 (불필요한 리팩토링 지양)
• 소프트웨어 프로젝트는 개발자를 위한 것이 아니다
  • 개발 이 후 참여자 등 모두를 고려해서 만든다 (단준하고 쉽게)
• 비범함과 평범함
  • 비범함: 가장 훌륭한 코드는 작성할 필요없는 코드. 단순하게 문제를 해결한다.
  • 평범함: 복잡하게 해결
• 단순한 설계를 위한 네가지 원칙 (켄트 벡)
  1. 모든 테스트 통과 (모든 테스트를 통과해야 한다)
  2. 명료성의 최대화 (명료하고, 충분히 표현되고, 일관되어야 한다)
  3. 중복의 최소화 (동작이나 설정에 중복이 있어서는 안된다)
  4. 구성요소의 최소화 (메서드, 클래스, 모듈의 수는 가능한 적어야 한다)
• 디자인패턴: 범용화를 위함
  • 범용화가 될 수록 복잡해진다.
  • 필요할 때 수정하면서 적용한다.
• 새로운 스킬, 실행 관례 등을 배우는 것은 병목점이 될 수 있지만,
  TDD 자체 (타이핑) 가 병목점이 되진 않는다.
• 장인으로서의 역할은 특별히 이슈가 되지 않을 정도까지 품질 비용을 낮추는 것

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

• 소프트웨어 장인: "열정", "겸손", "정직과 용기"
• 장인에게 직장은 커리어를 위한 지속적인 투자 개념도 갖는다.
• 커리어 관련해서 스스로에게 질문해본다.
  1. 나의 커리어로부터 나는 무엇을 원하는가?
  2. 그것을 성취하기 위한 다음 단계는 무엇인가?
  3. 이 일은 나의 커리어 방향과 합치하는가?
  4. 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
  5. 그러한 투자에 대한 이익은 무엇인가?
  6. 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?
  7. 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?
  8. 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?
  9. 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?
• 위의 질문들에 대한 답들은 상황에 따라 계속 변한다.
  • 이를 맞추어 보면서 계속 생각한다.
• 본인에게 맞는 답들을 잘 모르겠다면 -> 사람들을 만나서 물어라

---

소프트웨어 장인은 사명을 갖는다.

더 나아지는데 집중하고, 계속 커리어에 투자하고, 배우고, 가르치고, 공유한다.

고객에게 항상 가치를 전달한다.

그러면서, 자부심을 갖는다.