소프트웨어 장인

소프트웨어 장인 - 산드로 만쿠소 지음 권오인 옮김 길벗

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

주변 사람들이 괜찮다는 얘기를 많이 하고 표지 디자인이 맘에 들어서 읽기 시작한 책이다. 기술서적이나 글만 보다 보니 좀 가볍게 읽고 싶은 마음도 있었다. 소프트웨어 장인(Software Craftsmanship)에 대한 글로 저자는 런던에서 소프트웨어 장인에 대한 단체를 만들어서 운영하면서 소프트웨어 장인이란 무언인가를 설명한 글이라고 할 수 있다. 책을 읽어보면 애자일과 꽤 비슷한 느낌을 받을 수 있는데 둘 다 더 좋은 소프트웨어를 만드는 방법이나 더 좋은 소프트웨어 개발자가 되는 방법에 대해서 다루고 있으므로 실제로도 크게 다르지 않다. 다만 대부분의 애자일 책들이 애자일의 개념을 담은 XP나 스크럼 같은 실행관례 같은 것을 다루고 있다면 이 책은 소프트웨어 장인이 된다는 것이 어떤 것인가를 다루고 있고 실제로 책에서도 애자일의 실행관례 중 많은 부분을 다루고 있다. 내용 중에는 애자일과 소프트웨어 장인정신의 차이를 "애자일과 소프트웨어 장인정신 간에 중복되는 부분이 있기는 하지만, 소프트웨어 장인정신은 기술적 실행 관례에 집중함으로써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다."라고 설명하고 있다.

소프트웨어 프로페셔널이 할 수 있는 최대의 실수는 자신이 모르는 것을 모른다고 받아들이지 않는 것이다. 모르고 있다는 것을 인지하지 못한 상태를 '2단계 무지'라고 한다. 아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫걸음이다.

모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다고 본다. 경험과 발견을 공유함으로써 훌륭한 프로페셔널 커뮤니티를 이루는 데 도움이 되어야 한다.

지식은 일에서 얻을 수 있는 가장 흔한 투자 이익이다.

특정 회사 안에서의 커리어보다 개인으로서 우리 자신의 커리어가 항상 우선해야 한다. 물론 회사 안에서의 커리어가 개인의 커리어와 일치한다면 대단한 행운이지만 회사가 개인의 커리어를 통제하는 경우가 대부분이다.

어떤 면에서 책의 내용은 뻔하다고 할 수 있다. 뻔하다는 게 별로라는 의미라기보다는 애자일에 관심이 있었다면 이 책을 보았을 때 포함되어 있을 것 같은 내용이 거의 그대로 들어있고 아주 좋은 내용만 있어서 이 책의 내용을 보고 동의 안 할 수 있을까 하는 생각마저 든다. 그래서 좀 심심한 느낌이 들 수도 있지만, 정리가 잘되어 있어서 생각을 다시 한 번 정리할 수 있었고 나 같은 경우는 세부 실행방법 등에서도 동의하는 부분이 많아서 더 재미있게 읽었다. 특히 개인 커리어 관리를 위해서 힘써야 하는 부분은 내가 그동안 해온 내용이나 생각하는 부분과 일치해서 좋았다.

• 동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
• 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
• 개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
• 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,

책의 처음에는 유명한 애자일을 설명하고 자신의 사례를 들면서 소프트웨어 장인 정신에 대해서 설명한다. 애자일 소프트웨어 개발 선언처럼 소프트웨어 장인 선언도 존재한다.(위의 내용이 소프트웨어 장인 선언이다.) 이후부터는 구체적인 내용을 설명한다. 소프트웨어 장인이라면 일을 할 때 어떤 태도를 가져야 하고 자신의 커리어 관리를 어떻게 하고 소프트웨어 개발을 할 때는 어떤 자세를 취해야 하는가를 설명하면서 개인이 소프트웨어 장인이 되는 방법을 설명하고 있다.

회사 입장에서 사내의 개발자들이 마음에 들지 않는다면, 그 개발자들을 탓하는 대신 먼저 회사가 그들을 어떻게 채용했었는지 회사의 채용 방식에 의문을 품어야 한다.

제대로 된 애자일 조직이라면 지식 노동자들이 일을 즐겁게 할 수 있게 하는 요건들, 즉 자율성과 목적의식을 제공할 수 있어야 한다.

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

2부에서는 개인보다는 조직에 대해서 집중하고 있는데 좋은 개발자를 뽑고 면접하려면 어떻게 해야 하고 좋은 개발자가 팀에 필요한 이유 등을 설명한다. 그리고 조직 내에서 새로운 것을 시도하기 위해서 회사나 팀의 분위기나 문화를 바꾸는 방법 등을 설명하고 있다. 책을 읽고 나니 왠지 실용주의 프로그래머를 다시 읽어보고 푼 생각이 들었다.

소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 나 자신의 커리어의 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다.

전체적으로 흥미롭게 보았지만 애자일에 도입에 대한 부분이 개인적으로 인상이 깊었다. 난 애자일 선언문에 동의하고 여러 실행 관례들을 따르고 있기는 하지만 애자일을 열심히 주장한다거나 하는 편은 아니라서 아주 자세히 알지는 못한 편인데 이 책의 저자는 애자일 도입이 실패하는 주요한 이유는 애자일 도입이 더 좋은 소프트웨어를 만들기 위함이지만 실제 개발자 등의 역량을 높이는 노력은 없이 단순히 절차를 변경하는 수준에 머무르고 있어서 실제로 소프트웨어의 품질이 좋아지지 않는다고 얘기하고 있다. 애자일 도입에 힘쓰고 하지 않아서 깊게 생각해 보지 않았는데 중요한 지적이라는 생각이 든다.

오늘날, 애자일이 별 효과가 없다고 이야기하는 기업과 개발팀들이 많다. 애자일로 전환했음에도 이전과 비교해 실제로 크게 나아진 것이 없다고 말한다. 소프트웨어 프로젝트에서 가장 중요한 결과물이 소프트웨어 자체라는 점을 잊은 것 같다.

기업들은 컨설턴트나 애자일 코치를 고용하여 개발 절차를 바꾸는 데는 도움을 받지만, 더 높은 품질의 소프트웨어를 작성하는 데는 거의 도움이 안 되고 있다. 보통 애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않는다. 즉 개발자의 역량을 키우는 데는 도움이 안 된다.

그리고 해외의 소프트웨어 개발 환경보다 국내가 몇 년 정도 뒤처져 있다고 생각하는 편인데(점점 줄어드는 것 같긴 하지만...) 이 책에도 그런 내용이 많이 나온다. 국내에서 해외의 개발자나 개발 문화에 대한 내용은 보통 온라인으로 보다 보니 아주 좋은 회사나 유명한 사례 위주로 보게 되는데 이런 내용이 최소 상위 10%의 얘기라는 생각이 든다. 이 책의 2부의 사례에서 나오듯이 외국에도 아주 전통적이고 꽉 막힌 문화를 가진 회사나 개발자를 하찮게 취급하는 IT 회사들도 많이 있고 팀 내에서도 개선하고자 하는 노력에 반대하고 찬물을 끼얹는 사람들도 많이 있음을 보게 된다. 이 책을 쓴 저자가 소프트웨어 장인정신을 주장하는 이유도 이런 부분을 해결하기 위함이고 그런 면에도 국내 환경도 앞으로 나아가야 할 부분이 많이 있다고 본다. 좋은 점이라면 해외에 참고할 수 있는 성공 사례들이 있다는 부분이다.

우리 업계는 이제서야 코드의 품질이 프로젝트의 성공을 보증하지는 못하더라도 실패의 핵심 요인이 될 수 있다는 것을 배우고 있다.

아래는 책에서 인상 깊었던 문구들이다.(내가 나중에 참고하기 위해서...)

"일을 하는 것도 중요하지만 그에 못지 않게, 일을 어떻게 하느냐도 중요합니다."

소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시절은 지나갔다. 코딩과 관련된 것이 아니면 개발자와 상관없는 문제라는 태도는 이젠 용납되지 않는다.

일을 할 때의 방법은 그 실행 결과만큼이나 중요하다. 품질이 좋은 코드를 능숙하게 작성하고 싶다면 높은 품질의 코드를 작성하는 방법을 훈련해야 한다. 훈련 외에 다른 수단은 없다.

단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다.

프로페셔널로서 행동한다는 것은 트레이드오프를 이해한다는 것이다. 전체 시스템을 더 좋게 만들 수는 있겠지만 그럴 필요 자체가 없을 수 있다. 몇 년 동안 바뀐 적이 없는 부분을 리펙토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리펙토링해야 할 이유도 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다. 보이스카웃 규칙은 모든 것이 아니라 해당 부분을 이해하여 변경할 필요가 있을 때, 적용해야 한다.

훌륭한 개발자들에게 일은 그냥 일이 아니다. 일은 취미이자 열정이다. 좋아하는 일을 하면서도 돈을 벌 수 있어서 행운이라고 느낀다. 일은 단순한 의미의 일 이상이기 때문에 훌륭한 개발자들은 회사도 같은 방식으로 생각하기를 바란다. 개발자들은 그들이 빛날 수 있는 기회와 재미난 일거리를 많이 제공해 줄 회사를 찾는다.

장인이라면, TDD와 같은 XP 실행 관례들을 절대 불변의 진리라고 믿어서는 안 된다. 지금 당장 우리가 XP를 추구한다고 해서 더 나은 다른 방법을 찾아 보는 것을 멈춰서는 안 된다. 소프트웨어를 개발하는 방법이 하나밖에 없다고 생각하는 순간, 다시 말해 우리가 활용해야 할 실행 관례들이 정해져 있다고 믿는 순간 우리는 진화를 멈추게 된다.

소프트웨어 장인이라면 아키텍처, 디자인 패턴, 제네릭 솔루션 등을 떠올리기 전에 켄트 벡이 말한 '단순한 설계를 위한 네 가지 원칙'을 먼저 생각해야 한다. 작성되는 모든 코드들이 이 원칙들을 따를 수 있도록 노력해야 한다.

1. 모든 테스트를 통과해야 한다.
2. 명료하고, 충분히 표현되고, 일관되어야 한다.
3. 동작이나 설정에 중복이 있어서는 안 된다.
4. 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

범용 코드는 확장성이 더 좋을지는 몰라도 특정된 코드보다 더 복잡하다. 무조건적으로 범용 코드를 추구해서는 안 된다. 대신 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다.

단순히 좋은 코드를 작성하고 비즈니스 가치를 전달하는 것만으로는 좋은 개발자는 될 수 있지만 장인은 될 수 없다. 장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다. 항상 최고의 코드를 만들도록 다른 것들을 희생해서라도 계속해서 배우고 남을 도우리라는 각오를 하는 것이다.