소프트웨어 장인 정신

소프트웨어 장인정신

• 읽은 책: 소프트웨어 장인

소프트웨어 장인정신

주관적인 정의

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

짧은 정의

소프트웨어 장인정신은 소프트웨어 개발의 프로페셜리즘에 대한 것이다.

이 부분이 소프트웨어 장인정신에서 가장 중요한 내용이다.

정의 이상의 의미

소프트웨어 장인정신은 어떤 이념이나 마음가짐에 더 가깝다고 생각한다. 자신이 하는 일에 주인의식을 가지고 프로페셔널하게 행동하고, 고객이 원하는 것이 무엇이든 달성할 수 있도록 돕는다. 다른 개발자들에게 배우고 자신의 지식을 나누며, 경험이 부족한 개발자들을 멘토링 하는 것들이다.

메니페스토

소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.

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

이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

기술적 실행 관례

올바른 일 vs 올바른 실행

일을 올바르게 제대로 수행하고 있다는 것은 어떻게 알 수 있을까? 코드의 품질과 설계에서는 빠르고 짧은 피드백 루프를 어떻게 만들 수 있을까? 소프트웨어 장인정신은 기술적 실행 관례에 집중함으로써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다. 기술적 실행 관례들은 우리가 일을 ‘올바르게’하고 있는지 알 수 있게 해준다.

실행 관례와 가치

비즈니스 가치 중심

어떻게 하면 팀(또는 관리자, 회사)에 TDD나 페어 프로그래밍같은 것들을 도입하도록 설득할 수 있는가?
기술적 실행 관례들 그 자체를 직접적으로 팔려고 드는 것은 아무런 의미가 없다.

현재 일하는 방식과 비교해서 그 것이 가져올 이익에 집중을 해야 한다.
빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행관례를 도입함으로써 얻을 수 있는 가치들이다.

자동화된 테스트

자동화된 테스트는 클릭 한번으로 전체 시스템을 단 몇 분만에 검증할 수 있게 해준다.
코드가 올바른지 알려주는 피드백 루프가 몇 주에서 몇 분으로 줄어 들면 실수를 거의 즉시 고칠 수 있다.
자동화된 테스트는 실제 측정 가능한 비즈니스적 가치를 가져다 준다.

테스트 먼저

아이디어를 생각해내는 데도 도움이 되고 한 번에 하나씩만 집중할 수 있다.
테스트 코드가 준비되어 있으면 각 테스트 작업들은 몇 msec(단위 테스트)에서 몇 초(상위 수준 테스트)정도 소요되어 피드백 루프가 상당히 빨라진다.
테스트 코드는 잘 정리된 요구사항의 역할도 하기 때문에 딱 필요한 만큼만 코딩하도록 유도한다.
이러한 것들이 바로 비즈니스적인 가치다.

테스트 주도 개발

사실 TDD는 설계에 대한 실행 관례다.
테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다.
정확히 요구사항만큼만 만족시키는, 즉 테스트로 규정된 부분만 작성하게 되기 때문이다.
첫 설계 단계에서는 요구사항을 확대 해석하고 미래에 있을지 모를 부가 조건들이 추가되기 쉬워 설계가 커지고 복잡해지는(BDUF: Big Design Up Front) 경향이 있다.
그렇게 되지 않도록 막아준다.
코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다.
TDD와 설계 리뷰 미팅이 서로 배타적인 것은 아니다. 둘 다 필요하다. 하지만 각각이 제공하는 가치와 피드백 루프의 주기가 다름을 이해하고 있어야한다.
TDD는 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다. 또한 코드에 대한 살아 움직이는 문서 역할을 한다.
회귀 테스트 역할도 해준다. 이런 것들이 TDD가 주는 비즈니스적인 가치다.

지속적인 통합

• 지속적인 통합은 TDD와 함께 수행되어 피드백 루프를 단 몇 분으로 줄일 수 있다.
  • QA팀을 통해서 변경점마다, 통합 때마다 테스트하는 것이다. 이 건 며칠에서 몇 주 후에 버그가 있는지 피드백을 받을 수 있다.
• 이러한 실행 관례는 ‘일단 멈추고 버그부터 수정한다는 태도가 필요하다.’
• 시스템이 항상 배포 가능한 상태로 유지되고 버그가 누적되지 않는다는 점에서 효율이 높다는 장점이 있다.
• 훌륭한 테스터는 자동화 하기 어려운 임의의 사용자 시나리오에 집중하여 개발자를 돕는다.

페어 프로그래밍

코드 리뷰는 시스템에 대한 지식과 유용한 코딩 스킬을 팀 전체에 전하는 데도 좋다. 중요한 것은, 설계 리뷰와 마찬가지로 얼마나 자주 하느냐다. 여러가지 문제들로 인해서 피드백 루프의 주기가 길어질 가능성이 높다. 하지만 페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 페어 프로그래밍은 팀의 지식을 공유하고, 코드의 품질을 높이며, 팀의 생산성을 높이는데 도움이 된다. 이러한 것들이 비즈니스적인 가치다. 즉각적인 피드백 루프가 만들어진다.

리팩토링

레거시 애플리케이션을 대상으로 일을 할 때, 전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다. 이럴 때는 수정되는 부분에 한정해서 리펙토링을 집중하는 것이 더 나은 접근 방법이다. 프로페셔널로써 행동한다는 것은 트레이드오프를 이해한다는 것이다. 몇년동안 바뀐 적이 없는 부분을 리팩토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리팩토링해야 할 이유도 없다. 유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다. 이 것이 리팩토링의 비즈니스적인 가치다.

책임감

각 실행 관례들의 가치를 설명함에도 불구하고 여전히 많은 사람들이 받아들이기를 거부한다.
“그런 것들은 다른 데서 그렇게 하고 있다는 사례에 지나지 않는다. 그 중 많은 것들이 필요없다. 실행 관례들 없이도 좋은 소프트웨어를 쉽게 개발할 수 있다” 라는 말들이 여전히 반복해서 들리고 있다.
그 것이 사실일 수도 있다 하더라도, 대단히 모호한 주장이다. 구글에서 실패한 소프트웨어 프로젝트 비율을 검색해보면 얼마나 많은 프로젝트들이 이런 저런 형태로 실패했는지 여러 보고 자료와 통게를 찾아볼 수 있다.
출처에 따라 다르지만 실패 비율이 30%에서 70%에 이른다.
개발자이든 프로젝트 매니저이든, 비즈니스 담당이든, 이러한 실행 관례를 원하지 않는다고 하면 귀담아 들어야 한다. 기분 나쁘게 생각하거나 그 사람의 지식 부족을 의심할 이유는 전혀 없다. 우리는 그런 사람들과의 대화에서 배워야한다.
하지만 앞서 설명된 가치들을 이야기한 후 “이러한 가치와 최소한 동등한 수준의 가치를 만들어 내기 위해 당신은(혹은 우리는) 무엇을 하고 있습니까? 이러한 실행 관례보다 더 나은 방법이 있습니까?”
우리의 의사 결정에 책임감을 가져야 한다. 여기에는 실행 관례를 도입하지 않는 결정도 포함된다.
관리자들 역시 팀이 특정 실행 관례를 따르지 못하도록 할 때 그에 대한 책임감이 있어야 한다.

실용주의

언제든지 TDD보다 더 나은 가치와 더 빠른 피드백 루프를 줄 수 있는 다른 것이 있다면 그 것을 TDD 대신 도입해야 한다. 무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야한다. 어떤 실행 관례가 다른 실행 관례보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해보는 것이다.

소프트웨어 장인 정신은 전이된다.

실제로 글쓴이가 경험한 일을 기반하여 말하자면, 소프트웨어 장인 정신은 전이된다. 한 회사에서 있었던 일인데, 글쓴이 본인이 문제가 산재해있었던 조직에 소프트웨어 장인을 여럿 모아서 일을 했던 경험이 있다. 여러가지 방법들로 다시금 버그, 딜리버리 속도 등이 점진적으로 개선되었다.

모든 변화를 추진하기 전에, 그런 변화들의 영향에 대해서 고려해야한다. 많은 사람들에게 이야기를 하고 여러 종류의 회의론자들이 던질 수 있는 난감한 질문들에 답할 준비가 되어 있어야 한다.

작업을 구현과 테스트로 나누어서는 안 된다. 실행 관례를 전파하는 가장 효율적인 방법은 모범을 보이는 것이다.

나의 생각

읽으면서 답답하고 불편한 마음이 계속 든다. 나는 소프트웨어 장인이 되고 싶다. 소프트웨어 장인이라는 단어를 생각하면 가슴이 두근 거린다. 앞으로 나는 어떻게 해야할까? 어떻게 하면 소프트웨어 장인이 될 수 있을까?

• 첫번째로는 블로그 포스트를 작성하면서 나의 생각을 정리하고, 다른 사람들과 소통하고 싶다.
• 두번째로는 책을 읽는 것에만 그치는 것이 아닌 읽은 것을 정리하고, 일과 내 삶에 적용해볼 것이다.
• 세번째로는 새로운 기술을 배우고, 적용해보며 나의 역량을 키워나갈 것이다.
• 네번째로는 다른 사람들과 소통하며, 서로의 생각을 공유하고 배울 것이다.
• 다섯번째로는 나의 목표를 세우고, 그것을 달성하기 위해 노력할 것이다.