소프트웨어 장인

오래전 처음 회사에서 개발자로 일을 하고 있을때 이 책을 읽었던것 같다. 당시에는 애자일 방법론이 무엇인지도 TDD와 페어 프로그래밍을 어떻게 해야하는지도 모르고 기능을 만들어내기에 바빳던 시절이라 책에서 말하는 것들을 읽고 느끼는 바가 없었던 것 같다. 그러니 지금 다시 읽으니 이렇게 새로울 수 밖에…

이 책이 원서로는 2001년에 출판되고 2015년에 번역본이 출판되었다는 것이 믿어지지 않을 정도로 2021년인 지금 개발자들이 읽어도 전혀 어색함이 없고 가치있는 사례와 조언들로 구성되어 있다. 어쩌면 책에서 말하는 것처럼 클린 아키텍쳐나 클린코드, 리펙토링, 실용주의 프로그래머 등과 같이 일하는 방식이나 가치관을 바꾸는 혁명적 서적은 시대가 변하고 기술이 발전하여도 여전히 가치있는 것들을 제공해주지 않나 싶다. 이 책에서 소개한 실용주의 프로그래머, 맨-먼스 미신, GoF 디자인 패턴, 테스트 주도 개발, 익스트림 프로그래밍, 클린 코더, 소프트웨어 장인정신, 리펙토링 들은 꼭 책을 사서 두고두고 읽으면 좋을 것 같다.

이 책을 읽으면서 기억에 남는 키워드와 그 내용들을 적어본다.

장인정신

어쩌면 당연하다고 여길지 모르지만 지키기 참 어려운 것이 장인정신이라 생각이 든다. 솔직히 당연한 것들을 잘 지켜내기만 하더라도 장인이라 불릴만 하지 않을까 생각이 든다. 장인은 경력이 많고 적음을 떠나서 누구든 될 수 있고 반대로 아무나 될 수 없다. 요즘 주니어와 시니어를 많이들 나누고 있는데 이를 나누는 기준이 경력에 따라 나누는 모습들을 많이 볼 수 있어 아쉬울때가 많다.

이 책을 읽고 내가 느낀 장인정신은 프로다움이다. 내가 만든 제품에 대한 책임감을 가지고 업무에 적극적이며 더 나은 자신을 위한 노력을 아끼지 않는 그런 개발자 말이다. 내가 가진 기술력을 최대한 발휘해서 더 나은 제품을 만들기위한 노력을 어떻게 할 수 있는지 이 책을 통해서 가져가보자.

소프트 스킬

장인은 한쪽으로 치우치치 않는다. 개발자는 기술력도 뛰어나야하지만 지금은 더이상 혼자서 개발하지 않기 때문에 주변 동료들과 협업을 하는 능력도 중요하다. 어느것 하나 빠진다면 장인이라 할 수 있을까?? 내생각은 ‘아니오’이다. 많은 개발자들이 블로그나 이력서에 ‘성장’이라는 단어를 적은 것을 볼 수 있다. 그 ‘성장’이라는 곳에 기술 뿐만아니라 협업스킬도 함께 포함되었으면 좋겠다. 이 책에는 개발자들이 기술에 매몰되어 협업에 소홀하지 않은지 되돌아볼 수 있는 좋은 내용들이 담겨있다.

‘아니오’와 대안제시

내가 생각하는 주니어와 시니어의 큰 차이점은 ‘대안제시’라고 생각한다. 장인이라면 더 좋은 제품을 만들기 위해서 제품의 새로운 기능이나 변경되는 기능에 대해 우려되는 부분이 존재한다면 ‘아니오’라고 말할 수 있어야 하고 그에 대한 대안도 함께 제시해야 한다.

요구사항에 대해 제대로된 피드백을 제시하지 않아서 구현된 기능이 제대로되지 않아 사용되지 않거나 다시만들어지는 경우들을 많이 보았다. 반대로 무조건적인 반대(구현하기 힘들어서 또는 싫어서)로 인해 기능을 구현하지 않고 시간만 허비하는 경우도 겪어본적이 있다. 애자일 방법론을 도입하더라도 제때 피드백을 하지 않는다면 좋은 방법론으로 개발프로세스를 가지더라도 전혀 도움이 되지 않을 수 있다.

프로라면 요구사항에 대한 제대로된 분석과 이상적인 방법을 제시하기 위한 노력을 아끼지 않아야 한다.

태도

태도는 큰 차이를 가져올 수 있는 작은 요소이다. - 윈스턴 처칠

참 공감이 많이되어서 가져왔다. 어느회사를 가던 창업을 하지 않는 한 레거시는 필수적으로 직면하게 된다. 이때 레거시를 대하는 태도에 따라서 상황은 많이 바뀌게 된다. 여러 복합적인 이유가 있었지만 부끄럽게도 전에 잠깐 근무했던 회사에서는 레거시코드를 거의 모르고 업무를 했던적이 있었다. 그러다보니 문제에 대한 해결방안과 작업에 대한 예상 소요시간조차 제대로 산출하지 못하는 상황이 자주 발생했었다. 지금 돌이켜보면 당시 레거시 코드가 너무 복잡해서, 언어가 익숙하지 않아서라기 보다 마음가짐의 차이였던것 같다. 왜냐하면 지금 재직중인 회사도 주로 사용했던 언어가 아니고 시스템의 복잡도도 비슷하기 때문이다.

채용공고

요즘 채용을 담당하고 있다보니 열정적이고 재능있는 개발자를 끌어들이기 위한 채용공고를 작성하는 방법이 소개된 부분에 집중해서 읽었었다. 이 부분에는 개발자가 얼마나 열정적인지, 우리가 원하는 개발방법이 어떤것인지를 잘 제시해주고 지원자들이 어떻것들을 함께 만들어가며 자신의 커리어를 키울 수 있는지를 제시할 수 있는 방법에 대해 설명하고 있다.

동기부여

주변 동료들이 열정적인 개발을 하기 위한 동기부여를 어떻게 하면 좋을지 고민이 많이 된다. 어느 회사를 가든 주변에 열정적이고 생산적인 토론을 할 수 있는 동료가 있다면 얼마나 좋겠는가. 매번 그런 동료들이 있을 거란 기대를 가지기 보단 지금 주변의 동료들이 열정적으로 변할 수 있는 동기를 부여할 수 있는 방법을 찾는게 좀 더 현명하다고 생각이 든다. 물론 회사차원에서의 도움이 필요할 수 있겠지만 먼저 나부터 열정적인 모습을 보여줌으로써 주변에 열정을 전파해 나가는 것이 좋아 보인다. 이 책에서는 함께 페어 프로그래밍을 해보고 새롭고 재미있는 과제들을 해보는 등 동료들의 열정을 불어넣을 수 있는 방법을 제시해 준다.

기술 변화

현재 회사에서 코드리뷰를 하지 않고 TDD를 하지 않는다면 어떻게 할 것인가? 코드리뷰와 TDD를 하지 않는 동료와 회사를 탓하며 다른곳으로 이직할 것인가, 강력하게 코드리뷰와 TDD를 해야한다고 설득하고 억지로 도입할 것인가? 아마 첫번째는 자신에게 아무 도움이 되지 않으며 아마 이곳저곳 이직만 하다가 지쳐 포기할 가능성이 있어 보이고(또는 운좋게 코드리뷰와 TDD를 수행하는 회사에 입사하거나), 두번째는 코드리뷰와 TDD를 한다고는 하지만 구성원의 적극적인 참여가 이루어지지 않아 반쪽자리 방법론이 될 가능성이 있다.

책에서는 개발자, 관리자, 아키텍트들의 기술 변화를 이끌려면 이들의 성향을 파악하고 어떻게 다루어야 하는지 먼저 알아야 한다고 한다. 회의론자들은 무지, 대중, 냉소주의, 트라우마, 너무바쁜, 몰상식, 무념무상, 피해망상, 무능력, 상아탑 아키텍트, 좌불안석, 팬보이 등으로 나누어지는데 이들의 특징과 어떻게 대응해서 원하는 바를 이룰 수 있는지 설명해준다.

품질은 선택사항이 아니다.

소프트웨어 장인정신을 가져야할 이들이 머릿속에 항상 지니고 있어야 할 말이 아닐까 싶다. “TDD를 해야하는데 시간이 없어요”, “리펙토링은 배포하고나서 할께요” 와 같은 말들은 장인정신과는 맞지 않다. 지금 상황에서 가장 효율적이고 효과적인 선택을 하기 위해 더 나은 방법이 있다면 그것을 위해 최선을 다해야 하지 않을까? 이 책은 더 나은 방법을 찾아가기 위한 보편적인 방법들을 제시해 주면서 마치 소설을 읽는 듯이 술술 잘읽혔던 책이다. 잊혀질 때 쯤 또 읽어보고 싶은 책이다.