애자일과 소프트웨어 장인정신
코드 리뷰를 왜 해야 하나?
가끔 애자일을 구성원들에게 교육하고 애자일 코치를 통해 애자일 기법이나 절차(스크럼, 스탠드 미팅 등)를 조직에 도입하여 조직이 애자일하게 일하게 하려고 하는 시도를 본다. 나는 이렇게 어떤 절차(애자일 기법, 애자일 코치 등)를 통해 조직을 애자일하게 일하도록 만들 수 없다고 생각해 왔다. 그분들이 하자는 애자일은 내게는 너무 형식적으로 느껴졌고, 조직의 구성원들이 충분히 준비되지 않았다면 그렇게 체계적, 대대적으로 하기보다는 좀 작게 반복적으로 해서 정착했으면 좋겠다고 생각을 해 왔다. 이런 의견을 내 비치면 혹자는 내가 애자일을 싫어해서 못하게 한다고 얘기하기도 한다. 나는 2008년 즈음 XP(eXtreme Programming)를 알고 너무 감동을 받아서 꽤 많이 책을 통해 공부했고, 업무에서 수행해 왔다고 생각하고, TDD를 신봉하고 Refactoring을 사전 설계 방식보다 훨씬 선호하고 가끔 코딩할 때는 src/main/java가 아니라 src/test/java에서 시작하는데 말이다.
최근에 내가 slideshare에 올린 자료를 보시고 "코드 리뷰"에 대한 강의 요청이 있어서 자료를 정리하게 되었다. 강의를 요청한 곳에서는 다음과 같은 부분에 대해서 언급되었으면 좋겠다는 요청이 있었다.
외부에서는 어떤 코드 리뷰 활동을 하는지. 좋은 사례들을 공유해 달라
코드 리뷰 안 하고 있는 사람들을 어떻게 코드 리뷰 할 수 있도록 활성화시킬지
코드 리뷰 관점에서 개발 문화 차이점
코드 리뷰 개발 문화를 정착시키는데 어떤 어려움이 있었고 어떻게 극복했는지
코드 리뷰 tip, 좋은 리뷰어가 되기 위해 어떤 점을 노력해야 하는지
이러한 요청에 모든 답을 할 수 있는 수준은 아니지만 몇 가지 팁을 정리해서 자료를 만들었다. 그런데 사실 내가 하고 싶은 얘기는 아키텍처의 중요성과 건전한 아키텍처를 유지하기 위한 개발 관련 활동(Clean Code, OOP, TDD, Refactoring, Pair Programming, Code Review)이었고 이러한 활동 중 코드 리뷰는 일부였다. 그래서 코드 리뷰만으로 한 시간 가량 설명을 하려면 내게는
코드 리뷰를 왜 하고? 대체 무슨 효과가 있나?
가 명확치 않으면 설명이 어려울 것 같았다. 그러다 어렴풋이 알고 있던 소프트웨어 장인정신(Craftmanship)에 대해서 좀 더 살펴보게 되었다. 참고자료의 아티클에서 "소프트웨어 장인 /프로페셔널리즘, 실용주의, 자부심"이라는 책을 정리한 내용을 읽고 코드 리뷰의 중요성에 대해서 정리를 해 본다.
소프트웨어 장인정신
먼저 위키피디아에서는 아래와 같이 정의하고 있었다.
Software craftsmanship is an approach to software development that emphasizes the coding skills of the software developers. It is a response by software developers to the perceived ills of the mainstream software industry, including the prioritization of financial concerns over developer accountability.
즉
소프트웨어를 개발할 때 개발자의 코딩 역량을 강조하는 소프트웨어 개발 접근법
개발자의 의무보다 재무적 관심을 우선시하는 등과 같은 소프트웨어 산업에 인지된 잘못에 대한 소프트웨어 개발자의 응답
으로 이해할 수 있을 것 같다. 즉 소프트웨어 장인정신은 개발자의 개발 역량 증대를 강조하고 있다.
참고한 블로그 글들을 보면 소프트웨어 장인정신은
개발 마스터가 되어가는 긴 여정
개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐
책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미
등과 같은 정의도 볼 수 있다.
소프트웨어 장인정신은 애자일과 마찬가지로 더 좋은 소프트웨어를 만드는 방법, 더 좋은 소프트웨어 개발자가 되는 방법에 대해서 다루고 있다. 그리고 소프트웨어 장인정신을 애자일이 제대로 정착되기 위한 필수 조건으로 다루고 있다.
애자일 도입이 실패하는 주요한 이유
일부 책이나 기업이 컨설턴트, 애자일 코치 등을 통해 스크럼, 스탠드 미팅, 백로그 관리툴, 조직 구조 개편 등만 강조를 하면서 애자일 전환이라는 표현을 하고 있다.
애자일 도입이 더 좋은 소프트웨어를 만들기 위함이지만 실제 개발자 등의 역량을 높이는 노력 없이 단순히 절차를 변경하는 수준에 그친다면 실제로 소프트웨어 품질이 좋아지거나 애자일이 정착될 수는 없다.
기업들은 컨설턴트나 애자일 코치를 고용하여 개발 절차를 바꾸려고는 하지만, 더 높은 품질의 소프트웨어를 작성하는 데 이러한 접근은 거의 도움이 안 된다. 보통 애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않는다. 즉 개발자의 역량을 키우는 데는 도움이 안 된다.
소프트웨어 장인정신은 기술적 실행 관례에 집중함으로써 코드의 품질에 대한 빠르고 짧은 피드백 루프를 제공해 애자일을 보완하는 효과가 있다. 즉 소프트웨어 장인정신을 통한 개발 역량 확보 없이는 애자일을 행하기 어렵다.
기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다. 완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다. 이들은 기술적 실행 관례, 기술적 전문성 그리고 관련 도구들을 마스터하고 있어야 한다. 지속적으로 배포되는 소프트웨어에 대해서도 높은 품질을 유지시키며, 완벽하게 테스트되고 쉽게 변경할 수 있는 소프트웨어를 개발할 수 있어야 한다. 완전한 애자일 전환을 위해서는 기업들이 소프트웨어 장인정신을 품어야 한다.
왜 코드 리뷰가 소프트웨어 장인정신을 갖추기 위해 필요한가?
책에서 저자는 소프트웨어 장인정신에서 중요한 것은 지식 공유라고 말한다. 지식 공유를 통해 전문성을 갖춘 개발자를 육성할 수 있다고 말한다. 고대의 장인들이 후임자를 정해서 비법을 전수하듯 소프트웨어 장인들도 후배, 동료들에게 비법을 전수해야 한다. 커뮤니티 등을 활용해서 가급적 많은 사람들에게 공유해야 한다.
저자는 아래와 같은 말을 했다.
"소프트웨어는 점점 복잡해지고 있습니다. 소프트웨어는 더 많이 활용되고, 더 많은 전문 개발자가 필요합니다. 지금 전문성을 가진 개발자를 육성하는 방법은 하나입니다. 선배 개발자가 후배 개발자를 도와주는 것입니다. 굳이 교실에 안 가도 됩니다. 블로그를 쓰는 것, 커뮤니티에 참석하고 토론하는 것도 신입 개발자를 도와주는 것입니다."
꼭 선배이거나 더 잘하는 개발자가 아니어도 다른 개발자가 성장하도록 도울 수 있다.
내가 아는 것을 알려줘서 성장시킬 수도 있고, 내가 모르는 것을 공유해서 그 문제를 해결할 수 있는 사람이 고민하고, 학습하고, 정리해서 공유를 한다면 그것도 성장의 기회를 제공하는 것이다.
개발자들이 업무에서 공유를 할 수 있는 방법은 위키, 지라, 슬랙 등도 있겠지만 가장 좋은 것은 코드 리뷰일 것이다. 처음 온라인 코드 리뷰를 했을 때는 코드로 SNS 댓글 놀이를 하는 느낌이어서 재밌고, 정말 좋은 지식과 경험을 주고받는 느낌이었다. 개발 역량 증대를 위해서 TDD(Refactoring), Pair Programming, Clean Code, Design Pattern, Architecture 등에 대한 강의, 교육 등도 좋겠지만 우리 모두가 매일매일 할 수 있는 가장 좋은 것은 코드 리뷰라고 생각한다. 장인은 후배들에게 지식과 경험을 공유하여 그들을 성장시킨다. 코드 리뷰는 장인이 되거나 장인이 기여할 수 있는 수단이다.
불안정하고, 모호하고, 급변하는 시장에서 비즈니스는 빠르게 혁신을 해야만 하고 이를 위해 우리는 소프트웨어 장인정신을 토대로 애자일한 접근을 해야 한다. 이를 위해 바로 지금부터 행할 수 있는 것이 코드 리뷰일 것이다.
참고자료
https://blog.outsider.ne.kr/1186
