페어(짝) 프로그래밍에 대해서

또 하나의.. 나?

페어 프로그래밍

말 그대로 짝(페어)로 진행하는 프로그래밍을 의미한다..

네이버 부스트캠프 9기 챌린지 과정에서 페어 프로그래밍을 몇차례 진행했고, 꽤나 많은걸 느꼈던 터라 포스팅을 하게 되었다.

나는 기존에 다른 동료와 협업 개발을 진행해본적이 있던터라, '어 나도 그럼 그때 했던게 페어 프로그래밍인가?' 라고 생각했는데 아예 다른 개념이었다. 😓

 

기존에 내가 둘이서 협업을 해야할때 주로 진행한 방법은 아래와 같았다.

나 : 동료님, 저희 역할분담 어떻게 할지 생각해볼까요?
동료 : 좋아요! 같이 한번 보시죠.

내용 파악 후 ...

나 : 음, 일단 A, B, C 기능이 우선적으로 개발할 필요가 있어보이네요. 이거 역할분담 하실까요?
동료 : 좋아요. 제가 B기능을 사용해본 경험이 있어서, B기능을 담당해볼까 싶은데 어떻게 생각하세요?
나 : 넵, 그럼 제가 A, C 할게요.
동료 : 좋습니다. 그럼 각자 작업 들어가시죠!

 

근데 위 방식은 오늘 내가 이야기하고자 하는 페어프로그래밍 방식이 아니다.

본 포스팅에서 이야기하는 페어 프로그래밍이란 두 사람이 마치 한사람이 된 것 처럼 개발을 진행하는 방식을 뜻한다.

 

드라이버 - 네비게이터

카레이싱에서 드라이버와 네비게이터의 팀워크는 매우 중요하다.

페어 프로그래밍을 할때, 두가지의 역할을 나누어서 진행한다.

드라이버와 내비게이터로 나뉘는데, 이 둘은 목표 달성을 위한 프로그래밍 과정에 있어 적극적으로 참여해야 한다.

대화를 나누는것에 있어서 소극적이면 안되고, 적극적으로 의견을 나누고 같은 내용을 생각중인지 자주 체크한다.

역할은 20~30분 주기로 자주 바꾼다. (가급적이면 시간을 정해놓고 시간이 되면 역할을 바꾼다.)

작은 목표 (테스트 통과 등....)을 이룰때마다 기쁘고 성취한 감정을 적극적으로 표현한다.

 

내비게이터

운전자 옆에서 가야할 길을 알려주는 조수를 의미한다.

프로그래밍을 진행할때는 코드를 작성하는 드라이버 옆에서 서포트 해주는 사람을 의미한다.

 

- 해야할 것

옆에서 드라이버가 어느 부분을 어떻게 작성할지 안내한다. 즉, 무엇을 어떤코드로 해결할지 고수준으로 설명 해야한다.

하나의 문제를 해결하는데에는 여러가지 방법이 있는데, 왜 그런 해결책을 제시했는지 의도를 설명한다.

드라이버가 진행중인 작업보다 추상화된 높은 수준의 사항이나 고려사항들을 요약해서 전달할 수 있도록 한다.

 

- 하지 말아야할 것

드라이버가 실수를 할때, 너무 빨리 교정해주려 하지 말자. (드라이버가 직접 찾아 수정할 시간을 줄 수 있도록 하자. 너무 작은 에러를 연속적으로 지적하면 집중력이 깨진다.)

지시 사항을 너무 상세하게 설명하지 말자. (가능한 최대한 추상화해 전달하자. 최악의 상황 - 코드를 직접 읊어줌)
딴 짓을 하지 말자.

절대로 드라이버의 역할을 침범하지 말자. (간단한 사항이더라도 가능하면 키보드 제어권을 가져오지 말자.)

내비게이터가 드라이버의 통제권에 속한 기어봉을 조작하고 있다. (이렇게 하면 안됨!)

 

드라이버

운전대를 잡고있는 운전자를 의미한다.

프로그래밍을 진행할때는 키보드를 잡고 직접 코드를 치는 사람을 의미한다.

 

- 해야할 것

내비게이터를 신뢰하자. (내가 해야할 사항은 모두 내비게이터가 전달해 줄 것이라고 믿어야 한다.)

이해되지 않는 사항이나 해석의 여지가 다를 수 있는 문장이 있을때는 적극적으로 질문한다.

내비게이터의 이야기에 동의할 수 없을때는 다른 대안을 제안해 볼 수 있다. (하지만 합의가 진행되지 않을때는 내비게이터의 의견을 존중하고 따르도록 한다.)

큰그림을 보기 보다는 일단 눈앞에 있는 가장 작은단위의 문제 해결에 집중하자.

가능한 코드를 깔끔하고 합의된 형태로 작성할 수 있도록 노력하자.

 

- 하지 말아야할 것

너무 빨리 진행하지 말자. (코드 편집기 사용에 능숙해 작성이 너무 빠르게 진행되면 내비게이터가 못따라 갈 수 있다. 다만, 그렇다고 해서 무조건 천천히 하라는 것이아니라, 내비게이터가 잘 따라고 있는지를 지속적으로 확인 하라는 뜻이다.)

내비게이터가 집중을 잃었다고 판단될때는 과감히 코드 작성을 중단하고 대화를 나눈다. (절대 혼자 앞서 나가지 말고, 내비게이터와 같이 간다.)

 

서포터가 한눈판 사이에 비전을 하는 우리팀 이즈리얼... (아군이 당했습니다.)

느낀점

처음에는 드라이버와 내비게이터라는 역할의 로테이션이 불편하게만 느껴졌다. (아니 그냥 혼자했으면 훨씬 빨랐겠는데...? 라는 생각의 반복) 드라이버를 할때는 내비게이터의 지시사항을 이해하는데 많은 비용을 쏟아야 했고, 내비게이터를 할때는 내 지시사항을 이해시키려 많은 비용을 써야 했다.

 

근데 두 역할을 교체하는 횟수가 많아지며 점차 역할별로 잘되는 작업과 잘 안되는 부분들이 느껴지기 시작했다.

내가 드라이버를 할때는 코드를 작성하며 자연스레 요구사항에 위배되는 코드를 짜거나, 부작용이 발생될 우려가 있는 부분을 자주 놓쳤지만, 내비게이터를 하면서 코드를 작성하는 것을 보기만 하는 입장에서는 이러한 사항들이 너무나 잘보였고 다음에는 무엇을 해야할지도 쉽게 까먹지도 않았다.

 

나는 그동안 어떤 작업을 누군가와 함께 진행하는 것을 별로 내켜하지 않는 타입이었다. 내 생각과 상대방의 생각을 병합하는 작업에 소모되는 비용이 너무 크게 느껴졌고, 더군다나 의견이 충돌까지 할때는 더욱 머리아파 지기 일쑤였기 때문이다.

 

하지만, 사실 위에서 언급한 <내 생각, 동료의 생각>을 병합하는 작업은 협업을 필수적으로 요구하는 현업 환경에 적응하기 위해 필수불가결하게 길러야 하는 능력이며, 이로 인해 발생하는 비용들을 감수하더라도 페어프로그래밍 원칙을 잘 지키며 수행하면 얻는 이점을 확실히 느꼈고 지금보다 숙련된 페어프로그래밍을 진행하면 발생할 이점을 기대할 수 있게 되었다.

 

페어프로그래밍을 통해 훌륭하게 목표를 달성해내는 내 모습을 상상해본다.

다음에 내가 동료에게 페어프로그래밍을 해보자고 권유할 그날을 위해 이날의 느낀점과 학습한 내용들을 잊지말자 :)