[사내발표] 혼자보다 둘이 작업하는, 페어 프로그래밍을 해볼까?

( 이 글은 사내에서 발표한 자료를 바탕으로 작성했습니다.  )

 

안녕하세요! 입사 6개월차를 향해 달려가는 서비스 프론트엔드 팀의 ted입니다. 👋🏾👋🏾

 

입사 4개월 정도까지 새로운 기능 및 디자인 추가/수정하는 작업을 맡았으나, 최근엔 오래된 패키지를 새로운 패키지로 대체하는 작업(e.g. MUI-DateAndTimePickers -> TC-DateInput), 오래된 버전을 최신 버전으로 업그레이드하는 작업(e.g. TF 패키지 ^1.34.0 -> 9.6.0), 어드민 페이지에 새로운 기능을 추가하여 각 프로젝트에 적용하는 작업(e.g. 아티클 어드민 이미지 분할, 카탈로그 어드민 라운드 탭 기능 적용)등을 담당했습니다. 제 관점에서는 작업이 쉽지 않다 보니 빠른 속도로 결과물을 만들기 어렵고 설사 결과물을 만들어도 비효율적인 로직으로 구성하는 때가 종종 있어 난감했는데요.

 

이를 해결하기 위해 팀원에게 도움을 요청해볼까 하다가도, 로직이 복잡한 경우엔 어디서부터 얼마만큼 설명해야 할지 고민이었고, 함께 고민하는 시간만큼 동료의 시간을 빼앗는 것 같아 미안한 느낌이 드는 경우가 있었습니다. 게다가 작업의 히스토리가 깊다면 비슷한 경험을 했던 동료를 찾는 것 또한 쉽지 않았는데요. 이보다 더 효율적인 방법이 없을까 고민하던 중 애자일 방법론의 페어 프로그래밍(Pair programming)을 적용해보자는 의견이 있어 도입해봤습니다.

 

 

결론적으로 원활한 개발과 성취감을 느끼며 페어 프로그래밍을 마쳤는데요. 그렇다면 페어 프로그래밍이 무엇이고, 어떤 점이 좋았고, 앞으로 어떤 점을 개선하면 좋을지 알아보는 시간을 가져볼까요??

 

페어 프로그래밍(Pair Programming)이란, 단어 뜻 그대로 짝을 이뤄 프로그래밍하는 것을 의미하는데요. 기본적으로 하나의 workstation에 두 명의 프로그래머가 짝을 이뤄 한 명은 키보드를 이용해 코드를 작성하는 드라이버(driver) 역할을 맡고, 다른 한 명은 코드를 리뷰하는 역할(navigator)을 맡게 됩니다. 드라이버는 작업의 목표와 방향과 같은 거시적 관점보다 현재 마주하고 있는 문법, 에러 등을 처리하는 미시적 관점에 집중하고 반대로 네비게이터는 드라이버가 타이핑하는 동안 코드를 검토하고 작업의 전략적인 방향과 아이디어를 제시합니다.

 

드라이버와 네비게이터로 역할을 나누는 이유는 코드에 대해 각각 다른 관점을 갖게 하기 위함인데, 드라이버는 코드를 직접 다루면서 더 전술적이고 디테일하게 코드에 접근하는 반면, 네비게이터는 보다 전략적으로 접근하며 큰 그림을 염두에 두고 가이드하기 때문입니다. 여기까지 보면 피드백이 오고 간다는 점에서 언뜻 코드리뷰(CodeReview)와 비슷해 보일 수 있으나 코드의 결과만을 보고 평가하는 대신 짝과 함께 처음부터 시행착오를 겪으며 로직을 이해하고 문제가 생기면 즉시 수정하고 해결한다는 점에서 코드리뷰와 차이점이 있습니다.

 

 

페어프로그래밍을 채택해야 하는 이유에 대해서도 알아볼까요?

1. 지식공유: 한 명은 repo의 히스토리를 잘 알고, 짝은 구현에 필요한 기술들을 잘 알고 있다면 서로가 몰랐던 부분을 많이 배울 수 있습니다. 만약, 새로운 동료가 입사했을 때 페어 프로그래밍으로 작업한다면 개발문서를 읽는 것보다 더욱 빠르게 팀에 녹아 들 수 있고, 지식 또한 빠르게 공유할 수 있겠죠.
2. 같이 고민하기: 히스토리가 깊어 어디서부터 살펴봐야 할지 모른다면 처음부터 같이 고민하며 대화를 통해 논리적으로 접근하고 빠르게 작업하여 작업 시간을 줄일 수 있습니다. 특히 혼자 어려운 작업을 마주하였을 때 이렇게 접근하는 게 맞나..?라는 걱정과 함께 도전을 망설이는 경우가 많지만, 페어 프로그래밍을 통해 짝과 함께 여러 가지 새로운 도전을 할 수 있습니다.
3. 업무에 대한 집중도 상승: 짝과 함께 작업을 하다 보니 업무시간에 사적으로 소비하는 시간이 많이 줄어들고 오로지 업무에만 집중하게 됩니다.

코드를 완성하는 것도 중요하지만, 페어 프로그래밍의 중요 포인트는 소통을 많이 하여 서로의 지식을 공유하는 것입니다. 특히, 내가 알고 있는 내용을 짝에게 설명하고 반대로 짝은 해당 내용을 이해하기 위해서 높은 집중력을 발휘해야 하는데, 이 집중력이 무의식적인 코딩을 방지합니다. 혼자서 개발할 때 좋은 습관을 지녔다면 무의식적인 코딩이 득이 될 수 있지만 나쁜 습관을 지닌 상태로 무의식적인 코딩을 하다 보면 득보다는 실이 많겠죠. 하지만 페어 프로그래밍을 하면 상대방과 소통을 하면서 맹점을 줄이고 나쁜 습관을 교정할 수 있습니다.

 

팀에 페어 프로그래밍을 무조건 도입해야 할까요? 팀과 팀원의 상황을 고려하여 도입하여야 하는데요, 페어 프로그래밍의 단점도 한번 살펴보죠!

1. 키보드 성애자: 시니어와 주니어 개발자가 페어프로그래밍을 하다 보면 드라이버와 네비게이터의 역할이 수시로 변경되어야 하지만, 시니어 개발자의 마음에 들지 않아 키보드를 반지의 제왕의 절대 반지로 착각하여 코드를 완성하고 싶은 욕망에 사로잡혀 키보드를 놓지 않는 일도 있습니다. 이렇게 되면 시니어 개발자 혼자만 개발하게 되고, 지켜보는 주니어 개발자는 어떤 기능인지 파악하고 이해하기보다는 코드를 따라가기에 벅차지죠. 결과적으로 기능은 완성되겠지만, 주니어 개발자는 흥미를 잃게 되고, 더는 페어를 하고 싶지 않을 것입니다.
2. 체력 소모: 혼자 일할 때는 내가 원할 때마다 휴식을 취할 수 있지만, 페어와 함께 온종일 대화를 하며 개발에 집중하면 많은 에너지를 소모하게 됩니다. 이를 위해 정기적으로 휴식을 취하는 것이 중요한데, 헤일리와 페어프로그래밍을 하면서 50분 작업, 10분 휴식을 알리는 알람시계를 사용하여 작업했고, 필요하면 휴식시간을 더 늘리기도 했습니다.
3. 부족한 자기 개발 시간: 대부분의 개발자는 혼자서 개발하는 시간도 필요합니다. 만약, 내향적인 사람이라면 더욱 그렇겠지요. 이럴 땐, 업무시간 8시간 전체를 페어 프로그래밍에 쏟는 대신 5시간은 페어 프로그래밍, 3시간은 자가 학습 시간을 할당하는 방법은 어떤가요?

마지막으로 22~24번째 스프린트의 작업을 헤일리와 페어 프로그래밍으로 진행하면서 느낀점과 개선점을 작성해봤습니다.

1. 무작정 코딩부터 하지 말고 계획을 세우자: TF와 admin 프로젝트가 익숙하지 처음 작업할 때 계획을 세우지 않고 작업부터 시작했는데요, 이렇게 작업하게 되면 체계적으로 접근하기가 힘들고, 문제를 어떤 방식으로 풀어야 할지 정리가 잘 안 되는 듯한 느낌이 들었습니다. 그래서 처음 문제를 접할 때 문제를 이해하고, 문제에 대해 잠재적인 해결책이 무엇인지 브레인스토밍을 하고, 문제에 어떤 방식으로 접근할 것인지와 같은 일련의 순서를 만들어 체계적으로 접근한다면 개발 시간이 많이 줄어들지 않았을까 합니다. 추가로 작업 계획을 구두로 주고받는 것 보다 문서로 만든다면 기억에 더 잘 남을 것입니다.
2. 시간과 체력관리를 효과적으로 하자: 페어 프로그래밍으로 하루 8시간 동안 짝과 대화하면서 코드에 집중하다 보면 집중력과 체력이 급속도로 저하됩니다. 나와 짝의 체력과 컨디션도 다르고 페어링 작업 외에 슬랙 확인, 미팅 참석, 스크럼과 같은 부가적인 업무를 하는 경우도 있습니다. 작업시간과 휴식시간을 정해두고 작업 하는 것은 어떨까요? 하루 최대 작업시간은 6시간으로 정하고 시간당 50분 작업, 10분 휴식을 취하는 것처럼 말이죠. 혼자서 과제를 연구하고 싶은 시간이 필요하다면 페어링을 중지하고 시간을 정하여 각자 연구 후에 다시 페어링을 진행하는 것도 좋습니다. 효율적으로 시간관리를 위해 뽀모도로기법을 적용하는 것도 좋은 대안입니다.
3. 미니 회고전 열기: 정신없이 페어 프로그래밍을 하고 나면 체력적으로 지쳐 그날 무슨 작업을 했는지 까먹는 경우가 많고 쉬고 싶은 생각만 드는 경우가 많았습니다. 그래서 페어 프로그래밍이 끝난 당일에 서로 작은 피드백이 오가는 회고를 하는 것은 어떨까요? 예를 들면, 페어링을 하면서 어떤 점을 느꼈고, 어떤 점이 편안했고, 어떤 점이 불편했고, 계획된 목표를 달성했는지, 키보드를 자주 바꾸며 작업했는지, 다음에 도전해보고 싶은 목표가 있는지와 같은 내용입니다. 대화가 많이 오갈수록 팀을 더욱 단단하게 만들어주게 되고, 좋은 결과로 이어지게 되니까요!
4. 기념하기: 긴 시간 동안 페어프로그래밍을 통해 힘든 작업을 완료했을 때 바로 다음 작업으로 넘어가기보다 지친 서로를 위해 축하하는 시간도 필요하다고 생각합니다. 오프라인으로 만났을 땐 하이파이브를 하거나 커피 타임을 즐길 수도 있겠지만, 온라인으로 만났을 때는 쉽지 않을 것입니다. 그래서 PowerPosing를 취하는것은 어떨까요? (파워포징을 취하면 긍정적인 삶의 변화를 촉진한다는 주장이 있습니다.) 아니면 원하는 물건(커피, 노트북, 키보드 등등)을 들고 사진을 찍으며 기억에 남기는 것입니다.(도넛으로 성공을 기념하는 방법도 있네요!)

 

 

지금까지 페어 프로그래밍에 대해 간략하게 알아보는 시간을 가졌는데요 무조건 페어 프로그래밍을 도입하기보다 팀이나 팀원이 처한 상황, 컨디션, 환경 등을 따져보고 팀 분위기에 신선한 바람을 넣고 싶거나, 작업이 예정대로 되지 않을 때, 히스토리가 깊은 프로젝트일 때 등과 같은 상황에서 페어 프로그래밍을 조금씩 적용한다면 마침내 팀워크도 좋아지고 성과도 낼 수 있다고 생각합니다.

 

여러분들은 페어 프로그래밍에 대해 어떻게 생각하시나요? 발표를 듣고 나서 체험하거나 적용하고 싶은 분이 계신가요? 페어 프로그래밍에 대한 본인의 의견이나 피드백을 말씀해주시면 감사하겠습니다.

 

긴 발표 들어주셔서 감사합니다. 🙇🏾‍♂️ 🙇🏾‍♂️

❑ Reference

1. PairProgramming - WikiPedia
2. On Pair Programming - MartinFowler
3. The importance of donuts - larahogan
4. Power posing - WikiPedia