간만에 짝 프로그래밍(Pair Programming)을 해보고 있다. (이후부터는 그냥 페어 프로그래밍)

이 방법을 에자일과 XP 책들을 읽으면서 “아, 이런 방법도 있구나~” 하고 배웠다.  그러고 보면 이 시절에 페어 프로그래밍과 TDD를 포함해 새로운 지식들이 넘쳐나던 시절이었다.  어줍잖은 자신감으로 진행했던 프로젝트의 실패와 더불어 회사의 자금 사정 악화로 경제적으로 빈궁한 시절이었다. 하지만 실패를 곱씹는 과정에서 챙긴 지적 호기심은 이후에 참 많은 도움이 됐다.

사설이 길었지만 페어 프로그래밍을 실제로 시작한 건 네이버에서 일하기 시작한 이후다.  그것도 시작은 하다가 아예 공중 분해된 프로젝트를 진행할 때!!! (우연일지 필연일지 모르겠지만 망한 프로젝트에서 개인적으로 건져지는게 많은 듯…)  당시의 “나”라는 사람은 에자일(Agile)과 TDD라는 선진 문물에 신기해하면서 제대로 개발자의 궁색을 갖추는 중이었다.  아무래도 역량 부족.  페어의 정당한 짝꿍이라기에는 부족한 관전자일 수 밖에 없었다.  (이런 찌질함이었음에도 불구하고  2009년에 이따구 글을 적었다라는게 참… )

그 시절 이후로 시간이 많이 지났다. 제대로 개발하기 위한 몇 년의 시간이 있었고 때아닌 질풍같은 시간이 휩쓸고 지난 이후 현재의 자리에 있게 됐다.  잘 하는건 아니지만 나름 백엔드 개발에 대해서는 나름 코딩을 할 수 있다는 생각도 있고.  ^^;

최근에 시작한 새로운 프로젝트가 있어서 함께 하는 친구와 페어로 진행하고 있다.  진행하면서 느낀 “제대로 하기 위해 이런 것들이 꼭 필요하겠구나?” 하는 생각이 들어 정리해본다.

1. 서로를 존중해야 한다.

한 컴퓨터를 가지고 두 사람이 붙어 작업하는 것을 페어의 원칙이다.  세상에는 동일한 인간이 존재할 수 없다.  일란성 쌍둥이라고 하더라도 인격은 다를 수 밖에 없다. 특히나 프로그래머들의 경우에는 자신만의 이고(Ego)를 가진 사람들이 흔하다. 그렇기 때문에 긱스(Geeks)들이 널리고 널린 분야다.

둘이 하는 작업이다. 서로 양보하지 않고 부디친다면 충돌은 피할 수 없다.  기술에 대한 논쟁의 충돌은 환영할만한 일이다. 그러나 말이 전도되어 감정적인 언어가 이야기 사이에 끼어들면 폭망한다.

특히나 대화를 매개로 한 두 사람의 공동 작업에 나이나 직위가 끼어들지 않도록 해야한다. 권위주의가 대화에 개입하면 제대로 된 말이 이뤄지지 못한다.

2. 적극적으로 대화를 한다.

같이 작업을 하는 친구가 부끄럼쟁이지만 술만 먹으면 이야기를 또 나름 하는 친구다.  물론 실력도 출중하다. 그래서 페어를 할 때 이야기를 많이 한다. 말빨에 관련해서는 나도 밀리지는 않는 사람이기 때문에 또한 이야기를 많이 한다.

코드가 생긴 모양새나 왜 이렇게 코딩을 해야하는지에 대해 이야기하는 그 시간은 개인적으로 행복한 시간이다. (되려 게임하는 것보다도 이 시간이 더 재미있는 것 같기도 하다.)  특히 어떤 방식의 코드의 구조가 좋은지, 잘 읽히는 코드를 작성하기 위한 서로의 생각을 이야기는 정말 좋다. 너가 옳다 내가 옳다 이야기를 많이 하지만 결론적으로 각자 방식에서 장점을 취한다.  애도 아닌데 뭐가 결국 올바른지 몇 마디 말을 주고 받다보면 자연스럽게 알게 된다.  이런식의 대화가 길어지다보면 결국 쌓이는 건 지식이다.

3. 대등한 기량이면 더욱 좋다.

개발 능력이 되도록이면 비슷한 편이 좀 더 페어를 하기에 이점이 있다는게 개인적인 생각이다. 이전에 주니어 친구와 페어를 해봤다. 하지만 페어가 아니라 한 사람은 훈계를 하고 있고, 한 사람은 그 이야기를 주눅든 상태로 듣고 있었다. 아무래도 성질이 드러웠던 모양이다. -_-;;  이 시간이 물론 의미가 없는 건 아니다.  그렇다고 “두 사람 모두에게 발전적인 시간이었냐?” 라는 질문에는 “글쎄???” 라는 답변이 나올 것이다.

페어 프로그래밍도 일하는 방법 가운데 하나이다. 일을 하는 누구라도 일이 생산적이길 희망한다.  앞서 이야기한 것처럼 페어 과정의 토론은 서로의 성장에 큰 도움이 된다.  하지만 이것이 어느 일방의 가르침이라면 어떨까?  가르침을 받는 입장에서는 1:1 과외를 받는 특전일 수 있다.  일방적인 강의를 대학때에도 많이 들었다. 하지만 금방 잊혀지더라는 것이 개인적인 진리라고 본다.

4. 코드는 돌아가면서 작성한다.

내가 작성하는 코드를 누가 옆에서 혹은 뒤에서 쳐다보는 경험은 해보지 않은 사람에게는 매우 낯선 광경이다.  하지만 관찰 대상의 입장과 관찰자의 입장에서 이 광경은 모두 흥미롭다.  관찰 대상의 관점에서 본다면 코드 작성 과정과 툴 사용 과정들을 보여줘야한다.  그만큼 숙달된 조교의 솜씨를 강제한다. 관찰자의 관점에서 역시 다른 사람의 코딩하는경쾌한 키보드 소리를 듣거나 겁내 빠른 툴 사용을 위한 단축키 신공을 눈으로 볼 수 있다.

서로가 보여주고 보는 과정은 코드를 작성하는 본인의 자세를 그대로 까발린다.  얼마나 직관적으로 코드를 작성해나가는지? 술술술 코드를 적어나가는지를 볼 수 있다.  물론 이 과정에서 본인의 코딩 습관도 방청객에게 생얼굴로 보여준다.

관찰자는 민낯에서 얻는 것이 많다.  내가 작성하는 코드 대비 어떤 방식으로 다른 친구는 코드를 작성하는지 혹은 코딩 스타일은 어떤지를 배울 수 있다.  따라서 누구 하나가 독점적으로 키보드를 독차지하는 건 불합리하다.  종종 의자에 붙히는 엉덩이의 주인을 바꾸자.

5. 표준을 정하고 지킨다.

개발자는 코드를 작성한다. 하지만 인간인 이상 개성이 있고, 그 개성이 코드에 묻어나기 마련이다.  지금 작업하는 친구와 의미있는 페어를 하지만 이후에는 다른 친구와도 이런 의미있는 시간을 가져야 한다.  다른 친구의 만남에서 어떻게 상호 절충을 해야할까?  그리고 이런 상호 절충을 계속해야 하는 건가?

이것보다는 “표준안“이라는게 있는게 좋다. 왜 공통의 표준안을 따라야 하는가?  배려심이다.  자신이 작성한 코드를 다른 사람이 편안하게 읽을 수 있도록 혹은 다른 친구가 편안하게 수정할 수 있도록 맞춰주면 정말 좋아하지 않을까?

다른 이야기지만 내부 공유 시간에 나온 JS Framework에 대한 코딩 컨벤션을 무조건 체크하기 위해 lint를 사용했고, 하자는 의견이 있었다.  좋은 움직임이고 자바에 대해서도 이런 툴을 적용해보기로 했다.  표준안이 없다면 정립된 Defacto를 따르고, 그걸 팀의 현실에 맞춰 조정해나가는게 좋지 않을까 싶다.

6. 시간을 맞춘다(혹은 정한다)

이번 페어를 하면서 같이 하는 친구에게 미안한 점은 함께 진행할 수 있는 시간이 길지 않다는 것이다.  상대적으로 참석해야할 미팅이 많다보니 하루에 길게 진행하더라도 2시간 이상은 진행이 어려웠던 것 같다.  서로 시간을 할애해주지 않는건 내가 저지른 실수이긴 하지만 민폐다.

제대로 한다면 하루에 2시간 정도의 시간을 정해두고 페어를 하는게 좋다고 생각한다. 페어를 통해 공통적으로 해야할 일들, 예를 들어 핵심적인 내부 구조를 잡는다던지 서로 알고 있어야 할 업무 로직을 작성해야하는 일을 함께 하는게 좋다. 그리고 이외의 시간에 각자 작업한 부분을 코드 작성하고 이후에 각자 리뷰하면 일도 나름 효과적으로 할 수 있지 않을까 생각한다.

여기까지 정리해봤다. 아마도 가장 중요한 건 “서로에 대한 존중과 이해“일 것이다.  만약 이걸 갖추고 있지 않으면 절대로 페어를 하지 않는게 좋다.  무시하고 시기하고 결국에는 쌈난다.  본인이 다른 사람을 존중할 줄 안다면 그럼 바로 페어를 해봐라.  존중과 이해 다음에 본인이 갖춰야 할 점이 바로 “실행“이다.

오늘 하루도 좋은 일이 있으시길~~~~