0. 페어 프로그래밍은 분업이 아닌 협업

우아한테크코스에서는 약 2주마다 새로운 미션이 주어집니다. 이 미션을 페어와 같이 협업하여 해결해갑니다.
즉, 두 명이 하나의 컴퓨터로 같이 프로그램을 작성합니다. 한 명이 드라이버가 되어 주도적으로 코드를 작성하고 다른 한 명이 네비게이터가 되어 드라이버가 제대로 된 방향으로 가도록 안내합니다. 드라이버와 네비게이터는 일정한 주기로 번갈아가면서 진행합니다.

페어 프로그래밍
애자일 소프트웨어 개발 중 하나로 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법이다. 코드를 작성하는 사람이 진행자(driver)가 되고 다른 한 사람이 관찰자(observer, navigator)가 되어 코드 검토를 하며 프로그래밍을 작성한다. 두 프로그래머는 수시로 역할을 바꾼다.

약 2달반의 시간동안 페어 프로그래밍을 총 5회 진행하였습니다. 매번 페어 프로그래밍을 끝낸 후 좋았던 점, 아쉬웠던 점에 대한 회고를 진행합니다. 오늘 yu**와 페어 프로그래밍을 끝마친 후 회고를 진행하였습니다.
이때까지 쭉 받았던 피드백이 의외로 중복되는 내용이 많았습니다. 중복되는 내용의 피드백이 많다는 것은, 피드백을 받았으나 이를 고치지 않았다는 뜻이겠지요.

동일한 실수를 더이상 반복하지 않기 위하여, 같이 일하고 싶은 동료로 성장하기 위하여 피드백 받은 내용과 액션 플랜을 이 곳에 정리해보겠습니다.

1. 피드백 정리

페어 프로그래밍시 페어와의 대화는 논리가 중요한 게 아니라는 걸 깨달았습니다. 치열한 갑론을박이 있을때도 있지만, 대부분은 페어의 감정에 귀기울이면서 대화하는 것이 가장 중요한 것 같습니다.

1. 드라이버가 작성하는 코드에 집중하자

네비게이터를 할 때 드라이버가 코드 작성하는걸 보지 않고, 다른 것을 생각하고 있는 것처럼 보인다는 피드백을 받았습니다. 딴 짓을 한 것은 아닌데, 드라이버에게 코드 작성을 위임한채 너무 앞서서 설계에 대한 고민을 혼자서 하거나, 기존 코드 중에 수정할게 없나를 찾아보고는 했습니다. 페어 프로그래밍이면 같이 코드를 작성해야 하는데, 드라이버가 혼자서 코드를 작성하고 있다는 느낌을 받게 해서는 안되겠습니다.

2. 상대방의 말을 끝까지 잘 듣자

상대방의 말을 끝까지 듣지 않고 중간에 자르거나, 내가 하고 싶은 말을 막 내뱉는 경향이 있습니다. 또한, 인터넷 환경이 불안정하여 가끔 말이 끊길 때가 있는데, 정확하게 상대방이 뭐라고 말했는지 다시 물어보지 않고 대충 내용을 유추한 다음에 말을 이어간 적도 있습니다.
이는 상대방을 배려하지 않은 행동임을 다시 한번 깨닫습니다. 페어 프로그래밍의 결과물은 단순히 완성된 프로그램이 아니라, 페어와의 신뢰도 있습니다.

3. 페어가 작성한 코드를 마음대로 수정하지 말자

페어가 작성한 코드의 오탈자를 발견하면 임의로 수정하곤 하였습니다. 또한, 공백문자, 개행문자 등을 임의로 수정・추가하기도 하였습니다. 페어가 보기에는 이러한 행동들이 제가 딴짓하는 것처럼 보이게 만드는 것 같습니다.
페어가 작성한 코드는 공동의 소유물이지만, 일단 1차 소유자는 페어입니다. 페어가 작성한 코드를 페어에게 아무 의견을 묻지 않고 수정해서는 절대 페어로부터 신뢰를 받을 수 없습니다.

글 초반에서 나온 “리팩토링”은 두 가지 면에서 재앙이었습니다.

첫 번째는, 코드를 작성한 사람과 변경에 대해 논의하지 않았던 것입니다. 저는 코드 작성자들의 의견 없이 변경을 하고 그대로 코드를 올렸습니다. 만약 그것이 정말 개선을 이루어냈다 하더라도 (제 코드가 개선을 이루어 냈다고 생각하지는 않습니다^^.), 협업에서 이런식으로 업무를 처리하는 것은 최악이라고 할 수 있습니다. 훌륭한 엔지니어링 팀은 끊임없이 신뢰를 만들어 나갑니다. 별다른 상의 없이 동료의 코드를 변경하는 것은 언젠가 후폭풍을 불러 올 것입니다.

출처: Overreacted - 잘가, 클린 코드

4. 간단명료하게 핵심을 먼저 얘기한다

어떤 사안에 대해서 A부터 Z까지 장황하게 얘기하는 습관이 있습니다. 단적인 예로는 JS에서 string을 감싸는 문자를 Single Quote(')로 할지 Double Quote(")로 할 지에 대한 논의가 있었습니다. 저는 이러한 얘기를 할 때, 왜 JS에서는 Single Quote를 쓰는 것이 일종의 컨벤션이 되었던건지 그 히스토리부터, Double Quote를 썼을때의 이점들을 주욱 나열합니다.
핵심은 Double Quote를 쓰자는 것인데, 이를 빙빙 둘러서 얘기하게 됩니다.
간단명료하게 두괄식으로 Double Quote를 쓰자고 얘기하고, 페어가 이에 동의하지 않은 경우에, 나의 근거도 간단하게 축약해서 얘기하면 될 것인데 말입니다. (히스토리는 페어가 궁금해하면 말해주면 되겠죠?)
페어와의 소통은 티키타카형식의 대화가 되어야지, 한 쪽의 일방적인 설명이 되어서는 안될 것입니다.

5. 모든 선택을 페어에게 떠넘기지 않는다

저는 기본적으로 특정 기술에 대한 선호도가 없는 편입니다. 따라서, '이것도 좋고 저것도 좋아'식으로 얘기를 한 후 페어가 선택하는 것을 따르는 편입니다. 하지만, 선호도가 없지는 않습니다. 애초에 선호도가 없다면 페어가 제시하는 것에 무조건 Yes 를 외쳤을 것입니다.
처음부터 나는 어떤 것이든 괜찮다는 전제를 열고 대화를 하니, 페어 입장에서는 그래서 어떻게 했으면 좋겠다는거야? 라는 인상을 받을 수도 있는 것 같습니다. 일단은 두괄식으로 먼저 한가지를 제시한 후, 페어의 의견을 듣고 제가 수용을 할지, 더 설득을 해나갈지를 정해야겠습니다.

> In a single word: 상대방을 세심히 배려하자

2. 액션 플랜 정리

1. 라이브 셰어를 켜지 않는다

라이브 셰어를 켜지 않고 페어 프로그래밍을 수행합니다. 이렇게 하면, 드라이버만이 코드를 수정할 수 있으므로, 네비게이터는 임의로 코드를 수정할 수 없게 됩니다. 따라서 수정을 원한다면 드라이버에게 수정을 원하는 부분을 다 말을 해줘야하므로, 드라이버의 동의를 얻은 사항에 대해서만 수정할 수 있게 됩니다.
어떤 의미에서는 효율성이 떨어질 수도 있겠지만, 이로 인해 얻게 되는 페어와의 신뢰는 더 값질 것입니다.

2. 사전에 충분한 Reference를 준비한다

많은 Reference를 바탕으로 옳고 그름에 대한 저만의 기준이 생기지 않은 것에 대해서는, 특별히 호불호 없이 페어의 의견을 수용하는 경향이 있는 것 같습니다. 대부분의 FE 기술이 저에게는 낯선 만큼, 저만의 기준이 생긴 기술, 또는 컨벤션이 많지 않습니다.
정말 좋은 기술이라고 주관적으로 생각되더라도 페어를 설득할 정도로 객관적인 Reference가 충분히 확보되지 않으면, 자신있게 주장하지 못하는 경향이 있는 것 같습니다. 그렇다면, 저의 주장을 강하게 펼치기 위해서 사전에 충분한 Reference를 준비하여야 겠습니다.

추후 추가

3. 나의 성향을 구체적으로 페어에게 먼저 공유한다

논의한 내용이 반드시 코드로 반영되어야 된다고 생각하지 않습니다.
논의를 했다는 것, 그로 인해 페어간의 컨센선스가 생겼다는 것이 중요합니다.
따라서 제가 선호도가 없다는 것은, 논의에 따라 결정한 내용에 대하여 선호도가 없다는 것이지,
논의 내용 자체에 대하여 선호도가 없다는 뜻이 아닙니다. 이를 페어에게 분명히 밝혀야겠습니다.

3. 정리

페어 프로그래밍의 결과물은 단순히 완성된 프로그램 뿐만 아니라 페어와의 신뢰도 있습니다.