🚴‍
소프트웨어 장인: 아마추어에서 프로페셔널로

책 『소프트웨어 장인(Software Craftsmanship)』을 읽고 작성한 서평입니다.

Posted by 재그지그 on April 04, 2019

Book Methodology


호미 아마존에서 호미를 판다?

최근에 미국 온라인 쇼핑 사이트 아마존에서, 한국산 농기구 호미가 이른바 ‘대박’을 쳤다는 기사를 본 적이 있습니다.

호미와 아마존이라는 생뚱맞은 조합에 이끌려 저도 모르게 기사를 눌렀습니다. 기사는 ‘외국에서 원예 도구로써 호미가 알려져 선풍적인 인기를 끌게 되었는데, 그 배경에는 대장장이 장인의 고단한 노력이 있었다’는 내용이었습니다.

장인에게는 굶주림, 값싼 중국산 농기구, 대장간 앞의 뜨거운 불처럼 많은 어려움이 있었습니다. 하지만 장인은 묵묵히 자신의 땀이 담긴 농기구를 만들었습니다. 심지어는 20년 전에 낫을 구매한 분이 아직까지도 그 낫을 갈아가면서 사용하고 있다고 하니, 그 품질이 어느정도인지 이해가 가시나요?

마찬가지로, 이 책에서는 소프트웨어를 만드는 개발자로써 가져야 할 장인정신에 대해 다루고 있습니다. 어떻게 행동하고, 어떤 능력을 가져야 하며, 어떻게 인정받아야 소프트웨어 장인이라 할 수 있을까요?

책 소개

책 표지. 저는 전자책으로 구매해 읽었습니다.

『소프트웨어 장인(산드로 만쿠소 저)』은 더 나은 개발자로 성장하고 싶은, 더 좋은 코드를 작성하고 싶은 이들을 위한 도서입니다.

우선 저자는 소프트웨어 개발자라면 알아야 하는 방법론들과 실행 관례들을 소개합니다. 숙련된 개발자가 애자일, 익스트림 프로그래밍, 테스트 주도 개발, 페어 프로그래밍을 어떻게 잘 활용하는지를 알려줍니다.

또한 책에서는 저자가 개발자로써 겪은 에피소드들을 함께 소개합니다. 누구나 수준 이하로 일을 마무리했다던가, 전혀 프로답지 않았다던가, 더 나아지고 싶지만 어떻게 해야할지를 몰랐던 경험들을 갖고 있습니다. 저자는 성장의 과정에서 겪을 수 있는 고통을 좀 더 프로페셔널하게 극복할 수 있는 방법을 제시합니다.

마지막으로 저자는 어떻게 하면 더 나은 개발자가 될 수 있는지를 소개합니다. 어떻게 해야 좋은 회사를 구할 수 있는지, 어떻게 해야 능동적인 개발자가 될 수 있는지, 어떻게 해야 상사의 힘든 요구를 거부할 수 있는지를 소개합니다. 덕분에 개발자들은 이 책을 통해 실용적인 도움을 얻을 수 있습니다.

지금부터는 책에서 특히 강조하는 주제들을 골라 소개해보도록 하겠습니다.

소프트웨어 장인이란

우리가 일반적으로 생각하는 장인. 하지만 마음가짐만큼은 소프트웨어 개발자도 똑같다!

우선 저자가 생각하고 있는 소프트웨어 장인의 마음가짐들을 책 곳곳에서 확인할 수 있었는데요, 인상 깊었던 문구를 몇 개 골라 소개해드리도록 하겠습니다.

커리어 패스를 정할 때는 내가 열정이 있는 것, 진정 즐겁게 할 수 있는 것을 따라야 한다는 것이다.

저자는 한 때 더 나은 커리어를 위해 개발자에서 아키텍트로 직군을 옮겼었는데, 일이 즐겁지 않음을 깨닫고 다시 개발자로 복귀한 에피소드를 이야기합니다. 이 부분은 본인이 진정으로 좋아하는 일을 하고 있는지에 대해 한 번 생각해보게끔 만드는 문구입니다.

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

프로페셔널은 항상 주인의식을 갖고 일합니다. 본인이 맡은 일이 나아질 수 있는 최선의 방법을 선택합니다. 뿐만 아니라 긍정적인 개발자 생태계를 형성하기 위해 노력합니다.

소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시절은 지나갔다.

계획에 따라 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 정기적인 피드백을 받는 단계까지 개발자가 수행하기 시작한 것이다.

코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.

소프트웨어 개발자의 역할과 책임이 보다 커졌음을 강조하는 부분입니다. 예전과는 다르게, 프로젝트를 더 넓은 시야로 이해하려는 노력이 필요하다고 강조합니다.

소프트웨어 프로페셔널이 할 수 있는 최대의 실수는 자신이 모르는 것을 모른다고 받아들이지 않는 것이다.

아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫 걸음이다.

결국 소프트웨어 장인정신은 항상 최선을 다하고 고객에게 좋은 서비스를 제공하려는 프로페셔널한 개발자들이 소신껏 가진 마음가짐과 삶의 자세입니다.

몇몇 소프트웨어 장인들은 소프트웨어 장인정신이 추구하는 가치를 조직적으로 관리할 필요성을 느끼고, 이에 따라 소프트웨어 장인정신 매니페스토가 만들어지게 됩니다. 매니페스토의 각 항목에 대해 좀 더 자세히 알아봅시다.

1. 동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을

그저 동작하는 소프트웨어라고 해서 잘 만들어진 애플리케이션이라 할 수 있을까요? 저자는 좋은 소프트웨어의 기준을 쉽게 이해할 수 있고, 쉽게 예측 가능하며, 유지보수에 어려움이 없어야 한다고 소개합니다.

소프트웨어는 민첩하게 변할 수 있어야 합니다. 동작하는 것을 넘어서서 비즈니스의 변화에 따라 빠르게 변할 수 있어야 합니다. 그래서 우리는 애자일이 필요합니다.

2. 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을

계속해서 가치를 더한다는 것은 신규 기능을 추가만을 의미하지 않습니다. 저자는 가치의 높인다는 행위에 코드를 정리하고, 구조를 개선하며, 확장성을 높인, 테스트가 가능하며 유지보수를 쉽게 만드는 것을 포함시킵니다.

3. 개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을

상대에게서 배우는 것은 발전하기 위한 최선의 방법입니다. 저자는 좋은 개발자로 성장하기 위해서는 서로를 더 성장시킬 수 있는 사람들과 함께 일할 수 있어야 한다고 조언합니다.

4. 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

소프트웨어 장인은 공장 노동자가 아닙니다. 적극적으로 프로젝트의 성공에 기여할 수 있어야 합니다. 코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 진정한 소프트웨어 장인이라고 할 수 없습니다.

아니오라고 말하기

불가능한 일 앞에서는 솔직해지세요. 노력이 불가능을 가능하게 하지는 않습니다.

소프트웨어 개발에서 시간에 쫓기거나 요구 사항이 바뀌는 일은 흔한 일입니다. 하지만 시간 내에 명백히 불가능한 프로젝트라면, 우리는 아니오라고 말할 수 있어야 합니다.

논쟁을 피하고 싶거나, 능력이 부족해보일 수 있다는 이유만으로 “노력해보겠다”라고 말해버려서는 안됩니다. 열심히만 한다고 해서 불가능한 일이 갑자기 가능해지지는 않기 때문입니다.

고객이 나쁜 의사결정을 할 때, 그것이 적절치 못하다고 지적하는 정직함과 용기를 말한다.

프로페셔널의 역할은 그들의 경험과 지식을 활용해 고객의 문제를 다룰 방법들을 효율적으로 제시할 수 있어야 하는 것이지, 프로답다라는 것이 고객의 모든 요구사항을 충족시킨다는 것을 의미하지는 않습니다.

여기서 할 수 있는 프로페셔널한 대답은, 실용적인 대안을 제시하는 것입니다.

항상 ‘아니오’라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다.

단순히 ‘아니오’라고 얘기하는 것은 빠른 피드백이긴 하지만 고객의 요구사항을 해결하는 데에는 전혀 도움을 주지 못합니다. 최소한 브레인스토밍이라도 해서 쓸만한 대안을 찾아 내는 것이 소프트웨어 장인의 역할입니다.

애자일

어떻게 빠르면서도 좋은 품질의 소프트웨어를 만들 수 있을까요? 애자일의 핵심은 빠른 피드백 루프입니다.

지금 가고 있는 길이 올바른 길인지, 일을 제대로 수행하고 있는 것인지 확인하는 방법은 결과물을 자주 확인하는 방법 뿐입니다.

나쁜 코드는 암과 같다. 처음에는 발견하기 어렵지만 문제로 드러난 이후에는 대응하기 어렵다.

애자일(Agile)은 빠르고 짧은 피드백 주기를 활용한 효율적, 실용적인 소프트웨어 개발 방법론입니다. 저자는 애자일이 추구하는 가치에 대해 매우 공감하면서, 특히 테스트 주도 개발(TDD), 페어 프로그래밍, 지속적 통합(CI) 등을 거의 필수적으로 활용해야 한다고 주장합니다.

하지만 이런 애자일의 등장에도 불구하고 많은 기업들은 애자일의 도입이 여전히 별 효과가 없다고 이야기하는데요, 저자는 이에 대해 이렇게 이야기합니다.

애자일의 배경이 되는 기본 원칙이 잊혀졌다. 애자일의 모든 절차에는 기술적 탁월함이 전제되어 있다.

자기가 하는 일에 충분히 주의를 기울이고, 뭔가 잘못되고 있거나 더 나은 방법이 있다고 느낄 때 자기 목소리를 내는 재능있고 프로페셔널한 사람들이 있어야 한다. 절차에만 집중하고 소프트웨어 개발을 공장 라인처럼 취급하면, 그저 시키는 일만 하고 출퇴근하는 노동자와 다를 바 없는 개발자들만 생긴다.

다시 말해, 기업들이 애자일의 절차적인 부분에는 많은 관심을 기울이고 있지만, TDD나 페어 프로그래밍과 같은 기술적 실행 관례에 대해서는 완전히 무시하고 있다는 것이 현실이라는 것입니다. 아직까지도 많은 사람들이 테스트 코드를 먼저 작성하는 TDD를 시간 낭비라고 생각하거나, 페어 프로그래밍을 인력 낭비라 여기긴다고 이야기합니다.

실행 관례가 효율적이려면 반드시 모든 팀 구성원들에 의해서 그 가치가 납득되어야 한다.

마지막으로 완전한 애자일의 도입을 위해서는 기업과 개발자 모두가 기술적인 실행 관례, 전문성, 도구들을 충분히 이해하고 있어야 한다고 주장합니다.

애자일(스크럼)에 대한 보다 자세한 설명이 궁금하신 분들은, 전에 작성한 애자일 스크럼 튜토리얼포스트를 참고해주세요.

구직과 면접

회사에서 내가 필요한 이유에 대해 고민해봅시다.

개발자는 더 좋은 환경의 기업에서 일하고 싶어하고, 기업은 더 뛰어난 개발자를 채용하고 싶어합니다.

성숙한 채용 문화의 회사라면 단순히 고용자, 피고용자의 관계가 아닌 파트너십을 기대한다.

재능있는 개발자를 채용한다는 의미는 그의 의견을 중요하게 생각하고 일하는 방식을 개선하는 데 그의 도움을 받겠다는 것이다.

특히 회사를 구하는 입장이라면 본인의 포트폴리오를 관리하는 것도 중요하지만, 개발자로서 넓은 시야를 기르는 것도 중요합니다.

좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 공유하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다.

누군가 나를 취조한다는 느낌으로 면접을 받아들이기보다는, 서로가 공통적으로 관심을 갖고 있는 기술에 대해 토의하는 시간으로 생각해봅시다.

면접을 할 때 특정 기술에 대한 지식이 아니라 지원자의 재능, 태도, 열정 그리고 잠재성을 보아야만 한다.

면접의 주요 관점은 재능, 태도, 열정 그리고 잠재성에 맞추어야지, 특정 기술이나 프레임워크에 대한 이해도여서는 안됩니다!

기업의 입장에서도 채용은 매우 중요한 과정입니다. 왜 그럴까요?

개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자다. 실력있는 개발자, 본받고 싶고 영감을 일으키는 개발자, 바로 소프트웨어 장인이야 말로 최고의 동기 부여가 될 수 있다.

개발자는 동료 개발자들과 긴 시간을 보내고, 많은 영향을 받기 때문입니다. 따라서 팀과 기업에 긍정적인 시너지를 일으킬 수 있는 개발자를 채용할 수 있도록, 채용 과정에 공을 들여야 합니다.

능동적인 커리어

내 앞길은 내가 닦자.

소프트웨어 장인정신에서는 본인이 능동적으로 본인의 커리어를 관리해야 한다고 이야기합니다. 왜일까요?

직장은 그들의 커리어를 위한 지속적인 투자다.

언제, 어디서, 누구와 일하고 나의 일에 대한 가치를 스스로 결정할 수 있기 때문입니다.

이때, 일을 선택한다는 것은 단순히 돈을 좇는 것이 아니라, 해야할 일을 스스로 통제할 수 있는 환경인지(자율성), 이 일을 통해 내가 배울 것이 있는지(통달), 지금 하고 있는 일의 목적에 공감할 수 있는지(목적의식)를 확인하는 것이 중요합니다.

스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 나 자신의 커리어와 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다.

좋은 일감을 얻을 수 있는 위치에 도달하려면 많은 노력이 필요하다고 강조합니다. 그러면서 독서하기, 블로그 만들기, 특정 분야의 리더 팔로우하기, 소셜 미디어 잘 활용하기, 토이 프로젝트 시작하기, 오픈 소스에 기여하기, 페어 프로그래밍 등 자기계발을 위해 할 수 있는 몇 가지 방법들을 소개합니다.

편안하고 익숙한 상태에서 벗어나 나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아야만 한다는 것을 깨달았다. 나의 인생이고 나의 커리어이고, 내가 주인이어야 했다.

우리는 배움의 문화를 만들어 나가야 한다. 사람들 스스로 모든 것을 더 나아지게 하고 싶어하는 동기를 부여할 수 있어야 한다.

배움의 문화를 만드는 것은 개발자를 포함해서 모두가 해야 할 일이다.

배움과 훈련이 멈추는 순간, 우리의 커리어도 멈춰버립니다.

느낀 점

우물 밖으로 나가려는 시도 없이는 아무것도 바뀌지 않더라구요. 우리의 목표는 왜 우물을 나가야 하는지 스스로 알아가는 것입니다.

이제 막 1년차를 넘긴 주니어 개발자로서, 여태껏 제가 가진 마음가짐과 태도를 반성하게 되었습니다. 특히 책을 읽는 동안 남에게 보여주었을 때 부끄럽지 않은 코드를 작성해야겠다고 많이 생각했습니다. 특정한 기술에 얽매이지 말라고 했을 때는 정곡을 찔려 머리를 한 대 맞은 느낌까지 들었습니다.

저 역시도 한 때는 항상 열등감에 시달린 적이 있습니다. 의미없이 흘려 보낸 저의 대학 생활을 되돌아보면서, 무엇을 공부해야할지 모르고 후회에 빠져 방황한 적이 있습니다. “과연 내가 개발자로 살아갈 수 있을까? 개발자라는 직업이 나에게 맞기는 한걸까? 재능이 없는 건 아닐까?”

책의 마지막 부분에서는 이런 이야기가 나옵니다.

원하는 바를 모른다면 어떻게 해야 할까?

마음을 열고 사람을 만나는 것이다. 껍질을 벗고 뛰쳐 나와 할 수 있는 한 최대한 많은 문들을 열어보아야 한다.

답은 결국 원하는 답을 얻어낼 때까지 끊임없이 도전을 하고, 많은 사람들을 만나보는 것이었습니다. 본인이 무엇을 모르는지 모르는 상태에서 벗어나면, 스스로 어떤 분야를 공부해야 할 지를 알 수 있습니다. 물론 저도 깊은 경험을 갖고 있지는 않지만, 발전하기 위해서는 어떤 분야를 더 공부해야 하는지 정도는 알 수 있는 수준이 되어서 다행이라고 생각합니다.

그만큼 제 커리어를 다시 한 번 되돌아 볼 수 있는 계기가 되었습니다. 특히 개발자로 취업한 지 얼마 되지 않은 분들께 이 책을 추천해주고 싶습니다. 본인이 걸어온 길을 객관적으로 짚어보는 데 큰 도움이 될 것이라 생각합니다.