[도서 리뷰] 소프트웨어 장인

우아한테크코스 레벨2가 끝나고 포비가 책을 한 권 추천해주었다.

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

이제 개발자를 지망하는 취준생이기 때문에 이 책으로 지금 당장 소프트웨어 장인이 되겠다라기 보다는 어떤 개발자로 살아가야 하는지 좋은 지표가 되어줄 것이라 생각했다. 개발자 지망생의 입장에서 내가 좋았던 부분과 새겨들어야 할 부분을 정리할 예정이다. 이 책은 개발자로 살아가면서 몇 년 주기로 읽어본다면 그때마다 느끼는게 다르지 않을까란 생각을 해본다.

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

고참 개발자

• 고참이란 그 업계에 얼마나 오랫동안 몸 담아 왔느냐가 아니라 일시적 이고 상대적 이다.

  나만 해도 15년 동안 크리퍼로 폭포수 모델 개발 방법론을 적용해 개발했지만, 현대의 모바일 애플리케이션 개발과 애자일 방법론에서는 '고참'이라 할 수 없다.

새로운 현실

이제 개발자는 코딩을 잘하거나 프레임워크에 매우 익숙한 것만으로는 부족하다. 훌륭한 개발자라면 아래와 같은 일들을 이미 해왔을 것이다.

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

소프트웨어 개발자가 개발 업무만 하던 시절은 지나갔다. 코딩과 관련된 것이 아니면 상관없다는 태도는 버려야 한다. 기업들은 소프트웨어를 빠르게 바꾸면서도 품질 유지가 가능해야 높은 경쟁 우위를 차지 할 수 있다. 이제 고객들은 작지만 더 기민한 서비스를 제공하는 회사를 선호하고 있다. 따라서 회사들은 시키는 일만 하는 값싼 코더가 아닌 프로페셔널 개발자를 원하고 있는 것이 현실이다.

소프트웨어 개발자의 권한 영역은 더 넓어지고, 책임은 무거워지고 있다. 이러한 변화는 소프트웨어 개발자로서 커리어에 자부심을 느끼고 발전하는 원동력이 되었다. 2001년, 소프트웨어 업계에 커다란 혁신이 있었다. 바로 애자일 방법론을 채택하여 업무 절차와 조직 구조, 사고 방식을 바꾼 것이다. 하지만 여전히 많은 기업들이 개발 역량 부족으로 느린 시장 대응, 높은 유지보수 비용, 버그 투성이의 저품질 제품, 역량있는 개발자 부족 문제에 시달리고 있다.

• 소프트웨어 장인정신은 왜 필요할까?
• 소프트웨어 장인정신이란 무엇일까?
• 우리는 프로페셔널 소프트웨어 개발자일까?
• 왜 애자일만으로는 부족할까?

위 질문들에 대한 생각들을 이어지는 장에서 풀어 나갈 것이다.

2장 애자일

애자일은 어떤 단일 개념이 아니다. 애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다. 소프트웨어 프로젝트는 변화 자체가 기본 속성이다. 그러한 많은 변화에 적응할 수 있도록 애자일이 돕는다. 애자일 원칙과 방법론들을 절차적인 부분과 기술적인 부분으로 나눌 수 있다.

• 절차적인 관점에서의 애자일 원칙: 올바른 목표를 향해 진행 중인지 확인
  • 회의 방식
  • 구성원 각각의 역할
  • 요구사항 파악 방법
  • 작업 진척 속도 파악 방법
  • 점진적/반복적으로 일할 때 취하는 방식
  • 진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에 전달하는 방식
  • 비즈니스 피드백 방식
• 기술적인 관점에서의 애자일 원칙: 목표한 것을 올바르게 실행하고 있는지에 대해 안심
  • 테스트 주도 개발(TDD)
  • 페어 프로그래밍
  • 지속적인 통합
  • 단순한 디자인 원칙

애자일에 따른다는 것

애자일 방법론들은 모두 빠르고 짧은 피드백 루프 에 대한 것이다. 피드백 주기가 짧으면 문제를 신속하게 파악할 수 있어 상황 파악도, 적응도 빠르다. 애자일은 문제 자체를 해결해 주지 않는다. 애자일은 문제를 드러나게 한다.

3장 소프트웨어 장인정신

소프트웨어 장인정신에 대해 이야기하기 전에 소프트웨어 장인정신이 아닌 것들을 살펴보자.

• 아름다운 코드
• 테스트 주도 개발
• 스스로 조직화된 개발 그룹
• 특정 기술 또는 방법론
• 자격인증
• 종교

저자가 말하는 주관적인 정의

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

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

정의 이상의 의미

소프트웨어 장인정신은 어떤 이념이나 마음가짐에 더 가깝다고 생각한다. 많은 개발자들이 소프트웨어 장인정신에서 이야기하는 것들을 이미 실행하고 있다.

• 자신이 하는 일에 주인의식을 가지고 프로페셔널하게 행동한다.
• 고객이 원하는 것이 무엇이든 달성할 수 있도록 돕는다.
• 다른 개발자들에게 배운다.
• 자신의 지식을 나눈다.
• 경험이 부족한 개발자들을 멘토링한다.

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

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

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

내가 일하고 있는 회사에서 책을 사주지 않거나, 교육 프로그램이나 콘퍼런스에 전혀 보내주지 않는다면 어떻게 할 것인가? 우리가 새로운 것을 배우는 방법이 그것밖에 없을까? 이 때문에 그 회사는 나쁜 회사가 되는 것일까?

고객을 만족시키기 위한 투자는 스스로 해야 한다. 고객의 만족은 또 다른 고객을 얻기 위한 입소문에도 도움이 된다. 소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다. 회사가 새 지식을 가르쳐 주길 기대한다면 이는 프로페셔널하지 않다. 나 자신의 커리어의 주체로서 언제, 무엇을 배울지 스스로 결정해야 한다. 물론 회사들이 직원 교육을 하지 말라는 것이 아니다.

끊임없는 자기계발

1. 독서, 많은 독서
   기술 서적은 여러 가지 종류가 있다.

• 특정 기술에 대한 서적: 업무를 위해 어떤 프레임워크나 프로그래밍 언어 또는 특정 소프트웨어의 이용 방법을 급하게 알아야 할 때 꼭 필요하다.
  • 자바, Hibernate, Node.js, Clojure 같은 기술 책들
• 특정 개념에 대한 서적: 새로운 개념이나 패러다임 또는 실행 관례들을 소개한다. 당장 활용하기는 어렵고, 제대로 이해하고 습득하는 데 긴 시간이 필요하다.
  • 테스트 주도 개발, 도메인 기반 설계, 객체 지향 설계, 함수형 프로그래밍, NoSQL 데이터베이스 모델 등
• 행동양식에 대한 서적: 효율적으로 팀에서 일할 수 있게 안내하거나, 일반적인 상황에서 더 나은 프로페셔널이 될 수 있도록 조언한다.
  • 애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영에 관한 책 등
• 혁명적 서적(또는 고전): 일하는 방식이나 개인의 가치관을 바꾸는 책이다. 대부분 주류 사상으로 자리매김한다. 보통 어떤 개념이나 행동양식을 다룬 책들이 많다.
  • 실용주의 프로그래머 - 1999년 앤드류 헌트, 데이비드 토마스 저
  • The Mythical Man-Month - 1975년 프레드릭 브룩스 저
  • 디자인 패턴(GoF) - 1994년 에리히 감마 외 4인 저
  • 테스트 주도 개발 - 2002년 켄트 벡 저
  • 익스트림 프로그래밍 - 1999년 켄트 벡 저
  • 클린 코더 - 2011년 로버트 C. 마틴 저
  • 소프트웨어 장인정신 - 2001년 피드 맥브린 저
  • 리펙토링 - 1999년 마틴 파울러 외 5인 저

2. 블로그
   블로그를 이용하면 항상 최신 정보를 습득할 수 있다. 실제 경험, 개인적인 발견, 의견, 성공담, 실패담들이 짧게 담겨 있으므로 소프트웨어 장인정신이나 애자일 모델과 궁합이 잘 맞는다. 하지만 사전에 충분한 지식이 없는 사람에게는 독이 될 수도 있다. 많은 글들이 연구 없이 깊이가 얕은 부분이 많다.

모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다. 경험과 발견을 공유함으로써 훌륭한 프로페셔널 커뮤니티를 이루는데 도움이 되어야 한다. 블로그 초기에는 보는 사람이 없다고 하더라도 자신의 배움과 자기계발에 대한 기록의 장으로 두는 게 좋다. 유익한 글을 많이 올리는 경험 많은 개발자들도 과거에 같은 주제에 대해 이미 많은 글을 써보았기 때문에 좋은 글이 나오는 것이다.

3. 기술 웹사이트
   기술 관련 웹사이트들도 시장의 최신 동향을 알아보기에 좋은 수단이다.

팔로우할 리더 찾기

예를들어 Java나 Ruby를 업무에 사용한다면 해당 기술에 대한 가장 좋은 자료들을 누가 만들어 내고 있는지 알아야 한다. 이러한 전문가들이 영감을 얻은 부분과 생각의 바탕이 어땠는지 그 배경을 이해하는 것이 중요하다.

끊임없는 훈련

실행 관례와 새로운 기술들을 배우는 것은 자동차 운전과 같다. 더 많이 훈련할수록 더 편안해지고 별도의 주의 집중과 의식적인 노력없이 자연스럽게 할 수 있다. 그러면 이를 이용하여 우리가 달성할 수 있는 목표에만 집중할 수 있다.

훈련할 때는 작성 가능한 최선의 코드를 만드는데 집중해야 한다. 테스트를 하나 만드는 데 몇 분이 걸리든 몇 시간이 걸리든 상관없다. 훈련할 때는 그 훈련이 완벽하도록 노력해야 한다.

1. 카타
   카타는 '품세' 라는 뜻으로 일본 무예 훈련 용어다. 소프트웨어 카타는 작은 훈련용 코딩을 의미한다. 같은 코딩 카타를 반복하더라도 매번 다른 테크닉, 다른 언어, 다른 기술, 다른 접근 방법을 사용해야 효과를 최대화할 수 있다. 다음의 웹사이트들에서 유익한 코딩 카타들을 찾을 수 있다.

• codeingkata.org
• codekata.pragprog.com
• kate.softwarecraftsmanship.org

2. 펫 프로젝트(토이 프로젝트)
   저자가 추천하는 최고의 자가 학습, 자가 훈련 방법은 펫 프로젝트이다. 펫 프로젝트는 실제 프로젝트의 몇 가지 측면을 미리 경험할 수 있다는 점에서 중요하다. 무엇보다 펫 프로젝트는 재미있어야 한다. 프로젝트의 주제는 일상에 수천 개가 있는 애플리케이션도 상관없다. 자신의 취미에 맞춰서 만드는 것도 추천한다.

3. 오픈소스
   오픈 소스 프로젝트의 좋은 점은 훌륭한 개발자들이 어떻게 일하는지 체험할 수 있다.

4. 페어 프로그래밍
   페어 프로그래밍은 기술적인 실행 관례라기 보다는 사회적 활동에 더 가깝다. 페어 프로그래밍을 시작하는데 가장 큰 어려움은 자신이 코딩할 때 누군가가 옆에서 지켜본다는 것이다. 이는 누구나 불편하고 두려움을 느낀다. 이러한 것은 나의 한계가 드러날 수 있다는 걱정에서 온다. 이를 극복하는 것이 매우 중요하다. 혼자서 배우는 데는 한계가 있다. 페어 프로그래밍은 새로운 내용을 빨리 배울 수 있다는 점이 큰 장점이다.

훌륭한 개발자는 다른 어떤 개발자가 보더라도 이해할 수 있는 코드를 작성한다. 페어 프로그래밍을 하다보면 최소한 페어가 이해할 수 있는 코드를 작성해야 하므로 가독성 높은 코드를 작성하는 연습이 된다.

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

'아니오'라고 말하는 방법 배우기

상당수의 프로젝트는 빠듯한 일정과 상급 관리자로부터의 많은 압박 속에서 진행된다. 그러다보면 무리한 일정을 그대로 끌고 가는 경우가 매우 많다. 특히 젊은 개발자들은 그러한 무리한 요구에 자의든 타의든 하고만다. 이러한 프로젝트의 결과는 대부분 참혹하다. 릴리즈 버전 소프트웨어에 버그가 가득하고 고객은 화를 내며 신뢰는 추락한다.

불가능한 일에 무리하게 '해보겠다'하는 것 역시 프로페셔널하지 않은 행동이다. 빠듯한 일정과 부딪혀야 하는 상황은 흔히 일어난다. 빡빡한 일정을 다루는 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터넣고 관계자들과 소통하는 것이다. 가장 중요한 것은 주어진 일정을 준수할 수 있을지에 대해 어느 정도 자신감을 가지고 있는지 꾸준히 표명해야 한다. 자신감을 갖는 다는 것은 모든 기능이 테스트되고, 실제 사용 서비스와 최대한 비슷한 환경에서 충분히 검증된 상태 인 소프트웨어가 전달되야 함을 말한다.

대부분 개발자들은 '안 된다', '할 수 없다'라는 부정적인 말을 하길 꺼린다. '아니다'라고 말할 때 우리는 무언가 실패한 듯한, 무언가 협조하길 거부한, 좋은 팀원이 되지 못한 기분이 든다. 우리는 같이 일하는 사람을 실망시키는 것을 가장 싫어한다. 언뜻 보기에는 긍정적인 사고방식같지만, 그 이면에는 대단히 이기적인 욕구가 숨어 있다. '네'라고 말하는 순간 상사는 그 말을 믿고 계획을 짠다는 것을 반드시 기억해야 한다.

항상 '아니오'라고만 얘기하는 것 역시 프로다운 태도가 아니다. 모든 '아니오'에는 반드시 하나 이상의 대안이 따라와야 한다. '아니오'라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다. 항상 실용적인 대안을 찾을 수 없지만 최소한 브레인스토밍은 해보아야 한다. 어떤 때는 단지 문제를 어떻게 풀어야 할지 방법을 모를 수 있다. 이때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다.

8장 길고 긴 여정

어디로 가야 할지 모른다면

커리어의 다음 여정을 어디로 해야 할지 모를 때 다른 사람 다른 회사들에서 나에게 선택지를 제안할 수 있는 환경을 만들어야 한다.

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

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

지원자 입장에서의 관점

지원자에게 면접은 그 회사와 회사의 사람들(잠재적으로 같이 일하게 될)에 대해 알 수 있는 대단히 중요한 기회다. 다음은 면접에서 관심을 두어야 할 사항들이다.

• 면접관은 누구인가?(프로젝트 관리자? 개발자? 팀 리더? 아키텍트?)
  • 관리층이 개발자들을 신뢰하는지 여부를 알 수 있다.
• 얼마나 많은 지원들자들을 면접보고 있나?
• 원샷 면접인가 다단계 면접인가?
  • 원샷 면접은 급하게 뽑고 있는 가능성이 크다.
• 지원자에게 어떤 종류의 질문들이 주어지고 있나?
  • 그 팀에 합류했을 때 지원자에게 기대하는 것을 담고 있다.
  • 직무와 전혀 상관없는 내용에도 예의를 벗어나지 않는다면 딱히 나쁠 것 없다. 반응을 보려하는 것이다. 지원자와 대립적인 논쟁을 편하게 할 수 있는가와 같은 것을 볼 수 있다.
• 특정된 질문인가 개방형 질문인가?
• 면접관이 기술적 질문에 대해 yes/no 단답형을 좋아하는가?
• 좀더 상세하게 지원자의 생각들을 파보려 하는가?

15장 실용주의 장인정신

• TDD 등 XP에 능숙한 개발자들은 TDD로 인해 개발 시간이 부족하다고 하지 않는다.
  • 대부분 개발자들이 TDD와 같은 XP 실행 관례에 익숙하지 않기 때문에 TDD를 하면 개발 시간이 늦어진다고 한다. 하지만 이는 거짓이 아니다. 익숙하지 않은 개발 방식을 하면 시간이 오래 걸리는 것이 당연하다. 하지만 이를 개발자 스스로 지속적으로 연습해야 한다. 프로젝트가 커질수록 유지보수를 위해 TDD로 개발한 프로젝트가 유리한 것은 당연하다.
• 리펙토링을 위한 리펙토링은 시간낭비이다.
  • 레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래 보다 깨끗해야 한다.
  • 새롭게 추가할 기능이 레거시 코드에 큰 영향을 준다면 사전에 영향이 가해지는 부분을 리펙토링해야 한다.(OCP 원칙에 따라)
  • TDD의 레드/그린/리펙터 라이프 사이클에 마추어 작은 리팩토링을 연속해서 적용한다.
  • 분명한 필요에 의해 시스템을 변경하고, 그 와중에 작은 리펙토링을 꾸준히 하는 것이 바람직하다.
• 개발자로서의 여정을 이제 막 시작해서 어떤 것이 좋은지 판단할 경험이 부족한 사람들에게는 소프트웨어 장인정신 운동에서 권장하고 있는 실행 관례들을 따르길 권장한다.
• 단순한 설계를 위한 네 가지 원칙
  • 모든 테스트를 통과해야 한다.
  • 명료하고, 충분히 표현되고, 일관되어야 한다.
  • 동작이나 설정에 중복이 있어서는 안된다.
  • 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

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

저자는 일을 선택하기 전에 다음과 같은 질문들을 스스로에게 던진다.

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

이 모든 질문에 대한 대답을 고용계약서에 서명하기 전에 파악하기는 거의 불가능하다. 최대한 사전에 파악한 후 회사에서 일하면서 지속적으로 답을 알아가야 한다.

회사에서 하는 일이 당신의 가진 커리어 열망과 방향이 합치하는 한 오랫동안 머무르길 권한다. 만약 이 방향이 틀어지거나, 앞으로 나가가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면 그때는 회사를 옮겨야 한다.

마치며...

아직까지 현업에 있어본 적이 없다보니 확실히 큰 공감을 가지지는 못했다. 하지만 소프트웨어 장인이라는 현업에서 훌륭한 개발자의 생각을 엿볼 수 있어서 좋았다. 내가 이러한 상황에 닥치면 이렇게 해야겠구나라는 생각을 많이 했던 것 같다. 특히 '아니요'를 말하기 위해서는 적절한 대안이 필요하는 것에 많은 공감을 했다. 항상 저자가 직접 겪은 경험을 자세히 설명해주어서 재밌게 읽을 수 있었고 쉽게 이해했다. 아직까지 우리나라 현업에서도 TDD와 페어프로그래밍 같은 실행 관례가 이루어지지 않는 것이 대부분이라고 알고 있다. 이 책에서는 이러한 실행 관례를 바꾸기 위해서 설득하는 방법과 경험을 이야기 해주었는데 언젠가는 나도 할 수 있었으면 하는 바램이다. 물론 그 전에 나부터 꾸준히 연습을 해야한다!