숙련된 개발자의 역할
TDD를 배우기 어려운 이유
개발 관련된 강의, 발표 등을 하다 보면 온라인이나 강단에 서서 설명하는 것이 효과가 없다고 느끼는 경우가 있다. 하나의 모니터를 같이 보면서 키보드를 공유하고, 이면지나 화이트보드에 서로의 생각을 공유해야 제대로 의도가 전달되는 경우가 있다. TDD, 리팩터링 등이 대표적인 예인 것 같다.
왜 그럴까? 왜 책이나 온라인 강의 등으로 체득하기 어려울까?
이 질문에 대해서 몇 가지 사례를 통해 답을 찾아보겠다.
What TDD Looks Like In A REAL PROJECT (With Code Examples)
이 영상에서 Dave Farely( Modern Software Engineering , Continuous Delivery의 저자)는 TDD를 교육하는 데 존재하는 딜레마들에 대해서 설명한다.
흔히 Coding Kata라고 알려진 단순한 문제들은 기본 원칙을 가르치는 것은 쉽지만, 실제 프로젝트에 적용하기에는 부족하다.
반면, 복잡한 문제를 사용하면 학습자들이 문제의 복잡성에 압도되어 TDD 학습이라는 본래 목적에 집중하기 어려워진다.
Coding Kata: FizzBuzz, Mars Lander, Anagrams, Bowling Game, Leap Years, Gilded Rose, Magic Square, Mine Field, Number Chains, Add Fractions, Word Wrap
이 영상에서 Dave Farely는
단계적 학습 접근방식 채택
실제 프로젝트의 작은 부분부터 TDD 적용
레거시 코드의 점진적인 리팩토링과 TDD 도입
실제 프로젝트에서의 TDD 적용 사례 연구
등을 통해 TDD의 실질적인 가치를 이해하고, 실제 프로젝트에서도 성공적으로 적용할 수 있는 기반을 마련할 수 있다고 말한다.
맞는 말이지만 당장 내일부터 실천하기 만만치 않다.
How SOLID & TDD Paved the Way to Success at Ferrari
소프트웨어 개발에서 TDD(Test-Driven Development)와 SOLID 설계 원칙은 코드 품질을 높이는 데 중요한 역할을 한다. 이 영상에서 Emily Bache는 Ferrari의 개발팀이 어떻게 실전에서 SOLID 설계 원칙을 체득될 수 있는지를 보여준다.
Ferrari 팀은 표준 OOD(Object-Oriented Design) 교육(standard training course)만으로는 SOLID 설계 원칙을 체득하지 못했다. 그러나 테크니컬 코치와의 협력, 앙상블(Ensemble) 프로그래밍, 짝(Pair) 프로그래밍을 통해 TDD를 수행하면서 SOLID 설계 원칙을 팀이 내재화할 수 있었다. 이는 단순한 이론적 이해를 넘어 실전에서의 적용이 얼마나 중요한지를 보여준다.
표준 교육의 한계
교육 후에도 팀의 코드 스타일이 크게 변하지 않았다.
이론을 이해하는 것과 원칙을 실전에 적용하는 것 사이에는 큰 차이가 있었다.
테크니컬 코칭의 효과
숙련된 개발자들(테크니컬 코치)이 팀에 합류하여 밀접하게 프로덕션 코드를 작성하며 지속적인 개선을 이루었다.
코치들은 처음 합류했을 때 회의실에서 1주를 보내며 앙상블을 했음
해당 스프린트의 모든 타스크를 가지고 작업을 하고, 1주 후 모두 인도(Deliver) 했음
코치들은 TDD 같은 실용적인 기술을 가르치면서 팀의 역량을 높였다.
TDD의 실전 적용
TDD는 코드 품질에 큰 영향을 미쳤으며, SOLID 원칙에 대한 이론적 이해보다 실전 적용이 더 중요했다.
이 사례에서는 표준 교육으로는 불가했던 객체지향 설계 원칙 습득을 테크니컬 코치들과 앙상블 프로그래밍, 짝 프로그래밍을 하면서 체득했다는 점이 시사점이다.
Emily Bache이 Scala 도입 경험
출처가 기억이 나지 않은 사례인데, Emily Bache가 속한 팀이 Scala를 도입한 경험에 대한 것이다.
팀은 scala를 도입하기로 결정을 하고, 교육 기관에서 팀이 교육을 받았다고 한다.
업무에 돌아온 팀원들은 scala에 조금 더 익숙한 팀원의 도움을 받으며 어렵지 않게 scala를 팀에 도입할 수 있었다고 한다.
하지만 유사하게 TDD를 어느 팀에 도입하려 할 때는 scala를 도입할 때와 달리 큰 어려움을 겪었다고 한다.
어떤 기술은 교육을 통해 도입할 수 있지만, 어떤 기술은 그렇지 않은 것 같다. 이론이 중요하거나 과정이 중요치 않은 경우는 교육으로 도입할 수 있지만, 경험(Empirical)이 중요한 경우는 교육으로 도입하기 어려운 것 같다.
맺음말
Dave Farely의 영상을 보니 내 고민이 나만의 것이 아니라는 것을 알게 되었다. 알려진 Coding Kata로 설명하면 설명은 매우 효과적이라고 느껴진다. 하지만 수강하는 사람들 입장에서는 현실적이지 않다고 느낄 것이기 때문이다. 이 문제에 대해서 고민을 해 보고 내린 결론은 난이도가 있는 알려진 kata를 적절하게 보여주는 것이 좋겠다는 것이었다. 현실적인 문제로는 TDD, 리팩터링에서 설명할 기법들을 설명하기 어렵기 때문이다. 하지만 이런 강의를 들은 개발자들이 실무에 적용하는 것은 쉽지 않을 것이다.
Ferrari 팀의 영상에 나오는 테크니컬 코치를 보면서 내가 경험한 효과가 떠올랐다.
코드 리뷰를 하다 보면 온라인에 글로 설명하기 어려운 경우가 있다. 가능은 하겠지만 효과가 없을 것 같은 그런 경우 말이다. 이때 같이 PR을 작성한 개발자와 함께 앉아서 코드를 수정하면서 보여주는 것이 효과적인 경우가 있다. 이 경우가 Ferrari 팀의 경우와 비슷한 것 같다. 또 이런 경우가 현업의 실제적인 문제로 TDD, 리팩터링 등을 알려주는 경우인 것 같다.
Dave Farely가 보여준 TDD 실무 적용의 어려움도 테크니컬 코치가 있다면 큰 도움이 될 것이다. Ferrari팀이 보여준 것처럼 말이다.
온라인 강의, 책 등의 교육으로 체득할 수 있는 지식과 기술도 있지만, 그렇지 않은 경우들도 있는 것 같다.
이러한 기술 중에 TDD, 리팩터링 등이 있는 것 같다. 온라인 강의, 책 등으로 완전하게 체득할 수 없고, 팀 동료와 함께 하면서만 체득할 수 있는 것 같다. 팀에서 체득이 불가하다면 코치(숙련된 개발자)의 도움을 받는 것이 필요할 것 같다. 그것도 어렵다면 워크숍 형식도 해 볼만할 것 같다. 이때 강사, 코치 들이 단순한 문제로 기법을 알려주고, 수강생들이 자신들의 문제를 가지고 와서 같이 해 보면 어떨까 하는 생각이 든다.
