서론
지난 11월에 E2E 프로젝트가 한창 진행되고 있었던 즈음에 자바자기님이 Kernel360 1기에 특강 연사로 다녀가셨습니다. 개인적으로 이후에 기회가 된다면 현재 자바지기님이 속해계신 NEXTSTEP에서 TDD 특강을 듣고 싶을 정도로 궁금했었는데 이번 기회를 통해서 평소에 강의를 진행하는 방식에 대해 살짝 엿볼 수 있었습니다.
또한, 이 특강을 통해 앞으로 개발을 배움에 있어서 어떤 스탠스를 취하는게 좋을지, 테스트 코드는 어떻게 짜야할지, TDD는 어떤 식으로 진행하는지에 대한 감을 잡을 수 있었습니다. E2E 프로젝트 진행 중에 페어 프로그래밍을 약 2주간 짝을 바꾸어가며 진행했었는데, 페어 프로그래밍을 진행할 때는 잘 이해가 가지 않았지만 특강 이후에 깨닫게 된 점들에 대해 이번 후기를 통해 정리하고자 합니다.
개발자로 성장하는 동안..
개발자가 되기 위해 공부를 하면서 수많은 소스들 (실제 코드일 수도 있고, 어딘가에 떠돌아다니는 블로그 글, 혹은 유명한 개발자의 유명한 저서, 현업에서 행해지고 있는 작업 방식에 대한 고찰 등등..) 을 접하고 습득하게 됩니다. 이 과정을 통해서 좋은 글과 나쁜 글에 대해 거를 수 있다면 참 좋겠지만 불행히도 대부분의 우리는 경험이 부족하거나, 그런 것을 고민할 여유가 없기 때문에 있는 그대로의 글을 받아들여 "저게 맞겠구나"라는 생각을 하고는 합니다. 저도 그렇게 생각할 때가 많고 종종 운이 나쁜 경우에는 블로그에 있는 코드를 보고 작성했다가 오히려 시간이 더 많이 낭비되는 경우도 있었습니다.
특강을 진행하시기 전에 연사님은 자기가 하는 말도 믿지 말고 여기 과정에 있는 디렉터들의 말도 믿지 말라는 말과 함께 시작하셨습니다. 이러한 이유에 대해 조금 풀어서 설명을 해보자면 스스로 생각할 거리를 주고 어떤 기술이나 선택에 대한 본인의 이해도나 이유 없이 사용하지 말라는 뜻입니다.
우리는 그동안 조금은 주도적이지 못한 학습방법을 성장기를 통해 경험하고 이러한 학습 방식은 뿌리깊게 자리 잡고 있어 쉽게 고치기 어렵습니다. 조금 극단적으로는 "질문"은 일종의 범죄나 비행처럼 여겨지기도 하고, 그런 행동을 반복하는 아이는 또래에게 괴짜 취급을 받거나 때로는 어른들에게도 이상한 애 취급 받기 망정이었습니다. 하지만, 개발자는 본인 선택에 대한 이유를 설명할 수 있어야 하고, "왜?" 라는 말을 항상 품고 살아야 합니다. 상대가 면접관일 수도 있고, 상사일 수도 있고, 내 옆에서 일하는 동료일 수도 있지만 언제든 내 선택에 대한 설득을 충분히 할 수 있는 상태에서 작업을 진행해야 해당 선택에 대한 지식을 나눌 수 있을 뿐만 아니라 그 선택에 대한 최소한의 책임을 지는 것이라 생각합니다.
따라서 내재된 비 주도적인 학습 방식은 개발자에게 있어서 상당히 치명적일 수 있다고 생각합니다. 컴퓨터 과학처럼 대부분의 경우가 불변인 지식이라면 얘기가 달라지지만, 많은 기술들은 하루가 다르게 변하고 그를 쓰는 방법 또한 달라지기 마련입니다. 이러한 상황에서 있는 그대로의 지식을 생각없이 받아들이기만 한다면, 개발자라는 직업이 본인에게 맞는지 부터 다시 한 번 생각해 볼 필요가 있습니다.
위의 얘기와 이어지는 유튜브 영상입니다.
https://www.youtube.com/watch?v=th7n1rmlO4I
페어 프로그래밍에 대해..
널리 알려져 있듯이 페어 프로그래밍은 두 명의 개발자가 하나의 컴퓨터를 통해 개발을 진행하는 방식입니다. 한명은 진행자(driver)가 되어서 코드를 직접 작성하고 다른 사람이 관찰자(navigator)가 되어서 프로그램을 작성합니다. 이번 프로젝트에서 진행했던 페어 프로그래밍 역시 동료와 수시로 역할을 바꾸어 가며 진행했습니다.
당시 진행하면서 저 뿐만 아니라 많은 크루원들이 왜 이렇게 생산성이 떨어지고 고된 일을 강요하는지에 대한 의문이 들었습니다. 실제로 저희 아나바다 팀과 같은 경우 프로젝트 팀원이 한 명 부족했고, 프로젝트 일정에 맞추기 위해서 생산성 하락은 피해야 했습니다. 그럼에도 불구하고 과정에서는 페어 프로그래밍을 진행하기를 격려했으며 이후 특강을 통해서 왜 페어 프로그래밍을 진행하는지 이해하게 되었습니다.
페어 프로그래밍을 왜 해야할까?
- 새로운 기술이나 선택에 대한 내 의견을 조리있게 세워서 전할 수 있는 연습
- 사람마다 다른 문제에 대한 접근 방식
- 소프트 스킬을 연습하고, 가장 작은 단위의 협업 경험을 통해서 내가 어떤 성향의 개발자인지 확인하기
- 상대방의 다른 의견을 끝까지 듣고 이해하는 연습
위 스킬들은 나중에 개발자로써 커리어를 이어가려고 한다면 필수적이라고 생각합니다. 만약 이전의 협업 경험이 없다면 페어프로그래밍은 개발자가 할 수 있는 가장 작은 단위의 협업 경험이자 이후 더 큰 단위의 협업에서도 본인의 역할을 할 수 있게 해주는 일종의 연습 게임입니다. 실제로 프로젝트 진행 중 다른 페어의 의견을 통해 더 나은 의도에 맞는 코드를 작성할 수 있었습니다.
저희 프로젝트에서는 교환에 대한 교환 요청을 사용자가 달 수 있는 기능이 존재합니다. 이 중에 교환 요청의 상태를 기존에 존재하던 Enum인 TradeStatus (교환 상태)로 제가 진행자일 때 수정하려고 했었지만 페어는 이를 보고 교환 요청은 교환과는 별개의 entity이니 추가적으로 Enum을 만드는게 좋을 것 같다고 설명하였고 저는 이 의견을 받아들였습니다.
위와 같은 경우에서처럼 앞서 언급했던 페어 프로그래밍은 한 사람이 개발할 때는 생각하지 못했던 걸 가져오고 서로간 의사 소통을 통해서 성장할 수 있다는 큰 장점을 가지고 있습니다. 연사님은 이에 덧붙여 주니어를 단기간에 성장시키려면 사수와 페어 프로그래밍을 시키는 것 또한 좋은 방법이라고 설명하셨습니다.
Disclaimer
위의 내용은 Kernel360에서 진행했던 박재성님의 특강을 듣고 올린 후기입니다. 온전히 제 의견인 후기가 담겨있고, 박재성님이나 Kernel360의 의견을 대표하지 않습니다. 글에 대한 의견은 댓글로 남겨주시거나 제 메일로 보내주시면 확인하겠습니다.