요즘 개발자 몸값이 이슈다. 인공지능 및 메타버스, 자율주행 차 등 새로운 산업의 중심축인 개발자들이 점점 중요해지고 이들의 몸값이 올라가는 것은 어쩌면 당연한 일인줄도 모르겠다. 이 책은 그런 개발자들이 프로로서, 직업인으로서 어떤 마인드를 가져야 하는지 어떻게 살아가는지 다루고 있는 책이다. 단순히 높은 연봉에만 혹한게 아니라 진진하게 직업으로서 개발자를 생각하고 있다면 이들의 이념과 태도가 어때야 하는지 이 책을 통해 배워보자

아픔에 대한 책이기도 하다. 당신과 나 그리고 모든 프로그래머가 겪는 아픔을 생생하게 전달한다. 수준 이하로 일을 마무리했던 경험, 전혀 프로답지 않았던 경험, 더 나아지고 싶지만 어떻게 해야 하는지 몰랐던 아픔 등에 관한 일화와 그 치유법을 담았다.

프로그래머로서 프로페셔널리즘을 갖춘 이를 소프트웨어 장인이라 일컫고 있는데, 이 책에서 저자는 1990년대부터 개발자로 겪어온 경험을 바탕으로 소프트웨어에도 장인정신이 꼭 필요하다고 강조한다. 보통의 관리자들은 소프트웨어 개발을 공장 라인처럼 취급하기 때문에 프로젝트가 실패하게 된다면서 말이다. 이제 소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시절은 지나갔으며, 소프트웨어 업계는 소프트웨어 개발 방식이 프로페셔널하게 바뀌도록 압력을 받고 있다고 설명한다. 오늘날 프로젝트들은 여러 가지 기술들을 복합적으로 사용하고 복수의 정합 포인트를 두어 점진적이고 반복적으로 개발하고 있으며, 과거에는 사용자가 회사 내부인이거나 업무적 관계가 있는 사람이 대부분이었지만 오늘날에는 전세계 수백만 명의 일반인들이 애플리케이션을 사용하기 때문이라면서 말이다. 기업에서도 소프트웨어를 빠르게 바꾸면서도 품질 유지가 가능하다면 높은 경쟁 우위를 차지할 수 있기 때문에 애자일 원칙을 도입하는 곳이 늘고 있다고 한다. 이걸 기술적으로 뒷받침하는 테스트 주도 개발, 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙도 함께 말이다.

애자일은 문제 자체를 해결해주지는 않지만 그 문제를 드러나게 한다면서, 중간 결과물이나 수정 중인 프로토타입이라도 사용자에게 빨리 보여준다면 피드백을 속히 받을 수 있다고 언급한다. 애자일 환경에서 개발자들은 코딩뿐만 아니라 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 릴리즈, 우선순위 조정, 시연, 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지 수행해야 한다는 점도 지적한다. 하지만 많은 기업과 개발팀들이 애자일 전환 전에도 있던 문제들이 전환 후에도 여전하다고 언급하고 있다. 릴리즈된 제품에 수정사항을 적용하는 데도 너무나 오랜 시간이 걸리곤 하는데, 자신이 지켜보았던 거의 대부분의 애자일 전환 프로젝트들은 부분적으로만 전환하는 문제를 안고 있었다고 한다. 기업들은 컨설턴트나 애자일 코치를 고용하여 개발 절차를 바꾸는 데는 도움을 받지만 더 높은 품질의 소프트웨어를 작성하는 데 거의 도움이 안되고 있다면서 말이다. 보통 애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않기 때문에, 결국 애자일의 모든 절차에는 기술적 탁월함이 전제되어야 한다는 것이다.

한편 소프트웨어 장인은 고객 또는 고용주와 생산적인 동반자 관계를 맺어야 하며, 고객을 만족시키기 위한 투자는 스스로 해야 한다고 강조한다. 또한 이미 불가능하다고 알고 있는 것에 대해 해보겠다고 말하지 말아야 하며, 그렇게 아니오 라고 말할 때는 반드시 하나 이상의 대안들이 따라와야 한다고 말한다. 어떤 때는 단지 문제를 어떻게 풀어야 할 지 방법을 모를 수도 있다면서, 이 때는 최대한 이른 시점에 그 사실을 정직하게 알려야 한다고 조언한다. 그리고 문제 해결을 위해 최선의 노력을 다하고 있음을 보여주어야 한다는 것이다. 즉, 무언가 약속은 할 수 없더라도 문제 대응이 어떻게 되고 있는지 진척 상황을 계속 공유해야 한다는 말이다. 또한 코드의 품질을 돌보아야 하는 책임은 바로 개발자에게 있다면서 QA 전담 팀은 지양해야 할 안티 패턴이라 언급한다. 테스터는 아무런 문제도 발견할 수 없어야 하며, 테스터가 버그를 발견하는 것은 개발자로서 대단히 수치스러운 일이라 말한다. 예전에는 코드를 얼마나 잘 디버깅할 수 있느냐가 능력 있는 개발자를 구분하는 기준이었지만 지금은 좀 다르다고 설명하고 있다.

즉, 코드 수준에서 디버깅을 해야 하는 상황 자체가 당혹스러운 일이 되었다는 말이다. 그런 상황이 발생하면 즉시 문제를 해결해 관련 코드를 리팩토링하고 테스트 코드를 만들어서 다시는 그런 일이 발생하지 않도록 해야 한다고 말한다. 저자 자신은 테스트 주도 개발 방법론에 익숙해지고 레거시 코드에 테스트를 만들어 넣은 이후로는 코드 자체를 디버깅해야 하는 상황이 거의 없었다고 한다. 이 책에서 저자는 소프트웨어 장인정신을 통해 기술적 실행 관례에 집중함으로써 코드 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다고 설명한다. 그리고 사람들에게 새로운 절차나 새로운 실행 관례를 강제한다고 조직을 변화시킬 수 없으며 배움의 문화를 만들어내야 한다고 언급한다. 사람들 스스로 모든 것을 더 나아지게 하고 싶어하는 동기를 부여할 수 있어야 한다는 말이다. 전반적으로 이 책에서 언급하고 있는 소프트웨어 장인은 애자일 방법론의 기술적 측면을 실천하면서 프로페셔널로서의 태도를 지녀야 함을 강조하고 있는 것이다.