이 글은 처음으로 페어 프로그래밍(Pair programming)을 시도해본 두 사람의 이야기입니다. 둘 다 처음 진행해본 페어 프로그래밍인 만큼 매우 잘 이해하고 진행한 것도 아니며 최적의 방식으로 진행하지도 못했습니다. 하지만 1주일간 진행해보며 페어 프로그래밍을 처음 접해본 사람의 입장에서 진행한 방법과 느낀 점들을 적어보았습니다. 페어 프로그래밍을 시도해보고 싶으나 시도해보지 못한 분들에게 도움이 되는 글이었으면 좋겠습니다.

배경

등장인물

Tom

• 리멤버 PC웹 버전 개발
• Backbone.js를 이용하여 Single-page application(이하 SPA)  개발 경험 있음
• 올해 초에 AngularJS를 처음 접하여 리멤버 PC웹 버전을 AngularJS로 개발(SPA)
• 리멤버 PC웹 버전의 서버 사이드를 Ruby on Rails(이하 RoR)로 개발

Jaden

• 리멤버 백오피스(타이피스트, 어드민 시스템 등. 이하 B/O), API 등의 프로젝트들 개발
• 특별한 JavaScript 프레임워크 없이 jQuery만 이용하여 직접 프레임워크을 만들어서 사용
• B/O 프로젝트들을 SPA가 아닌 매번 페이지 로드를 하는 Multi-page application(이하 MPA)으로 개발
• 모든 B/O 프로젝트의 서버 사이드를 RoR로 개발

상황

상황 1

MPA로 B/O 제품들을 개발하던 Jaden은 시스템 속도 개선, 생산성 향상 그리고 유지 보수성의 향상을 위하여 기존 프론트 부분의 재개발과 신규 개발에 대하여 AngularJS를 도입하려 했습니다. 그중 가장 먼저 도입하기로 결정된 부분은 타이피스트의 타이핑 화면을 SPA로 변경하는 작업이었습니다.

상황 2

입사 이래 몇 개월간 플랫폼이 달라 고독하게 개발하던 Tom과 마찬가지로 몇 년간 고독하게 개발하던 Jaden은 다른 사람과 같이 머리를 맞대고 고민을 하며 개발할 기회에 매우 목말라 있었습니다.

상황 3

마침 몇 개월 전에 API 개발을 맡게 된 분들이 페어 프로그래밍을 처음 시도하셨었고, 그 경험에 대한 좋은 피드백을 주셨었습니다.

이런 세 가지 상황에서 Tom과 Jaden의 페어 프로그래밍은 좋은 해답으로 다가왔습니다. 이렇게 이번 작업에 대하여 주저 없이 약 1주일간 페어 프로그래밍을 진행하기로 했습니다.

기대

이번 페어 프로그래밍을 진행하기 전에 저희가 기대했던 부분들은 크게 네 가지가 있었습니다.

첫 번째, 이번 작업은 AngularJS의 부분이 매우 큰 비중을 담당했기 때문에 AngularJS에 조금 더 익숙한 Tom이 아직 덜 익숙한 Jaden이 더 빨리 AngularJS에 적응할 수 있게 도와줄 수 있을 것이다. 또한, 반대로 RoR에 훨씬 더 익숙한 Jaden과 함께 하면서 Tom도 RoR에 더 쉽게 적응할 수 있을 것이다.

두 번째, 개발을 진행하면서 개인이 하나의 프로젝트를 맡다 보니 문제에 부딪혔을 때, 상의할 사람이 없어서 답을 내면서도 이게 최선인지 찝찝한 느낌이 들었던 부분들을 해소할 수 있을 것이다.

세 번째, 혼자서 개발할 경우 귀차니즘에 의하여 생기는 나쁜 습관들을 고칠 수 있는 기회가 될 것이다.

네 번째, 더욱더 끈끈한 동료애!

페어 프로그래밍

위키피디아에서 페어 프로그래밍을 검색하면 다음과 같은 장점들을 얘기하고 있습니다.

• 경제성 – 페어 프로그래밍을 진행하면 약 15%의 시간이 더 걸리지만, 결과물은 약 15%의 결함이 줄어든다.
• 디자인 품질 – 혼자보다 둘이서 머리를 맞댈 경우 더 좋은 디자인 품질이 나온다.
• 만족도 – 약 96%의 프로그래머들이 혼자 일하는 것을 더 선호하지만 95%의 프로그래머들은 페어 프로그래밍을 할 경우 더 코드에 대하여 만족감을 느낀다.
• 배움 – 서로 다른 지식을 가지고 있는 프로그래머들이 같이 일을 하게 되면서 지식 공유가 활발히 이루어진다.
• 팀빌딩, 커뮤니케이션 – 서로 문제 해결을 하면서 좀 더 커뮤니케이션이 잘 된다.

자 이렇게 좋은 것이라는 것은 이제 알겠으니, 어떻게 진행해야 하는 걸까요? 사실 어디에도 그 방법에 대한 정형화된 확실한 룰이 존재하지는 않습니다. 누구는 ‘운전자’와 ‘조수’ 역할을 구분하여 30분 간격으로 자리를 이동하면서 운전자가 운전(코딩)을 하고 조수가 옆에서 조수일(의견 제시)을 하라고 합니다. 하지만 다른 곳에서는 또 다른 방법을 제시합니다.
저희는 다음과 같은 규칙을 정하여 진행했습니다.

• 1대의 컴퓨터로 진행한다
• 1시간 단위로 번갈아가며 키보드를 잡는다 (턴제)
• 무엇이든 타이핑 하기 전에는 둘 다 무엇을 적을지 합의를 하고 적는다
• 즉 타이핑만 번갈아가며 할 뿐 생각의 역할은 별도로 두지 않는다

미리 말씀드리면 아무래도 키보드를 잡고 있지 않는 사람이 조금 집중도가 떨어지는 느낌이 들어서 키보드와 트랙패드를 두 개씩 놓고 둘 다 동시에 키보드를 잡는 방식으로 변경했습니다.

진행 일기

Day 1 (월)

우선 Jaden이 일부 만들어놓은 명함 타이핑 화면의 코드에 대한 설명과 그 구조나 코드에 대한 질의가 이뤄졌습니다. 또한 기존 네이밍 룰이나 코딩 컨벤션에 맞춰서 확실한 규칙을 정했습니다. 어느 정도의 설명과 약속이 이뤄진 후에는 기존에 일부 짜여있던 코드들에 대해서 완전히 처음부터(변수명부터) 다시 짚고 넘어가며 변경이 필요한 부분들을 변경했습니다.
그리고 전체 아키텍처, flow의 초안을 내놓았습니다. 기존의 뼈대에서 전체 생명 주기에 대한 로직들을 쭉 훑고 변경해야 할 부분들을 계속 변경해 나갔습니다.
그 결과 첫날에는 핵심이 되는 컨트롤러에 대한 리팩토링이 완성되었고, 전체 구조나 flow들에 대한 초안이 나왔습니다.

피드백

• Tom – 혼자 작업을 할 때 계속 손이 먼저 가서 생각을 적게 하는 버릇을 고칠 수 있게 되었다.
• Jaden – 페어 프로그래밍은 처음이라 뭐부터 어떻게 해야 할지 막막했지만 일단 내가 기존에 구현하면서 고민했던 부분부터 얘기를 시작하니 좋았다.

Day 2 (화), Day 3 (수)

어제의 핵심 컨트롤러 구현을 완료한 데 이어서, 다른 서비스들을 다시 돌아 보며 여러 상황들에 대한 처리를 어떻게 효율적으로 처리할 수 있을까에 대하여 여러 방안을 모색하며 고민을 했습니다.

턴제 방식의 페어 방식의 페어 프로그래밍을 진행하던 중, 둘 다 아무래도 처음 정했던 1시간이 애매한 시간이라는 생각이 들었습니다. 1시간이 집중도가 한참 높아질 때여서 1시간 마다 턴 변경을 자주 놓치게 되었고 그러다 보니 키보드를 잡고 있지 않은 사람의 집중도가 약간 떨어지는 경향이 있었습니다. 그래서 방식을 동시제로 변경했습니다. 다음 사진을 보시죠.

사진 왼쪽의 노트북에서는 설계와 관련된 내용을 작성, 가운데의 모니터로 코드를 공유, 오른쪽의 노트북으로는 결과 실행을 합니다. 가운데의 키보드와 트랙패드는 우측 노트북과 연결하여 Tom이 사용하고 Jaden은 우측의 노트북으로 코드를 작성합니다.

<혼자가 아닌 둘이니 개발 설계에 대해 토의도 하면서 화이트보드에 적을 수도 있습니다>

피드백

• Tom – 확실히 생각을 멈추지 않게 된다. 형은 노트북, 나는 키보드를 이용하면서 동시에 코딩할 수 있는게 한 시간씩 번갈아 가는 것보다 더 집중되지 않을까? 이틀째라 그런지 약간의 집중도 저하는 있었던 것 같다.
• Jaden – 같은 코드를 보고 같이 고민을 하고 같이 논의를 하고 이러한 것이 첫날 보다 많이 자연스러워졌다고 느껴졌다. 코딩할 때도 한 번 더 생각하게 되고 좀 더 좋은 코드를 만들 수 있도록 노력하게 되는 것 같아 좋았다. 탐 덕분에 하루하루 AngularJS랑도 가까워지는 느낌이 든다. 짜증 나게만 느껴지던 디버깅도 번갈아 가면서 진행하니 재미있었다.

Day 4 (목), Day 5 (금)

이날은 남은 일부 부분들을 마무리하고 종일 디버깅을 진행했습니다.

피드백

• Tom – 사실 개발하면서 단위단위로 개발과 동시에 테스팅을 진행하는 게 맞고 또 보통은 각자 그렇게 진행했는데, 이번 페어때는 페어 프로그래밍에만 집중해서 그런지 그러지 못했다. 이젠 서로 호흡을 알아 좀 더 잘 맞게 되는 것 같다. 같은 프로젝트를 따로 개발해도 코드나 팀워크 면에서 모두 잘 맞을 수 있을 것 같다.
• Jaden – 온종일 디버깅을 진행했다. 그래서 그런지 온종일 정신적인 데미지를 좀 입었다. 그래도 둘이 같이하니 빨리 진행되긴 했다. 이젠 서로 코딩 스타일도 알게 되어 한 프로젝트에서 각자 개발을 진행해도 될 거 같다는 생각이 들었다.

결론

Tom

• 같이 구현한 코드들에서 버그가 없었다(!! 원래는 이게 더 무섭다)
• 혼자 일하는 것보다는 속도가 더딘 느낌은 났지만, 그만큼 한발 한발 안전하게 코딩을 하게 된 것 같고 테스팅, 유지보수까지 포함한 프로젝트 전체 싸이클에서는 시간이 적게 들어간 것 같다.
• 물론 전체적인 싸이클을 보면 시간이 많이 단축되었으나, 그건 한사람이 작업했을 때를 기준으로 한 것이다. 아무리 페어 프로그램이 130 혹은 그 이상의 효율성을 내도 둘이 각자 일을 하는 200의 업무량을 따라가기는 힘들다. 현실적으로 얼마나 자주, 어떤 조합으로 페어 프로그래밍을 진행해야 할지는 고민을 많이 해야 할 듯하다.
• 결과물을 보면 매우 만족스러운 설계나, 코드 품질이다.
• 고독하게 고민하고 코딩하던 외로움이 많이 해소되었다
• 지식 공유의 측면에서 Jaden이 혼자 AngularJS를 배우는 것보다 더 효율적으로 배울 수 있지 않았을까?
• 매우 만족스러운 결과를 가져왔지만, 이는 Jaden과 많이 친하고, 서로를 꽤 잘 아는 상황이었기 때문에 더 호흡이 잘 맞았던 것 같다. 모든 페어 프로그래밍이 이와 같은 좋은 결과만을 가져오지는 못할 것 같다.
• 새로 들어온 입사자와 페어 프로그래밍을 하면 좋을 것 같다. 코딩 컨벤션, 설계 방법들에 대해서 잘 맞출 수 있고, 또 기존의 코드도 가장 잘 알려줄 수 있는 방법인듯하다. 그리고 무엇보다도 보다 새로 오신 분이  더 적응하기 쉬워지고 빠르게 끈끈한 동료애가 생기지 않을까?

Jaden

• 처음 진행했던 Pair programming임에도 불구하고 개인적으로 매우 만족이였다.
• 우리가 목표로 한 기능을 개발하는데 예상보다 시간은 조금 더 들었지만, 작성한 코드들에 대해서 전반적인 품질이나 만족도도 높았다.
• AngularJS를 보다 빨리 습득할 수 있었다.
• 그 이유에서는 오랫동안 혼자 개발을 해온 탓에 좋지 않은 코딩 버릇도 생겼었고, 무엇보다 속도 위주의 개발을 해왔었는데, 둘이서 하니 코드 한 줄을 작성하는데도 신중해지고 다른 사람이 봐도 이해 가능한 코드를 작성하도록 노력하게 되는 것이 아닐까 하는 생각이 든다.
• 기회가 있다면 자주 이러한 개발을 진행하고 싶다는 생각이 들었다.

이렇게 일주일간 페어 프로그래밍을 진행해보았습니다. 이번 경험에 대하여 저희 둘은 만족도가 매우 높았습니다. 하지만 저와 Jaden은 평소에도 아주 친한 사이라 서로 성격이나 스타일을 잘 알고 있었기 때문에 더 높은 효율이 나왔을 수도 있습니다.
비록 저희와 같은 상황이 아니더라도 개인적으로는 시니어와 주니어의 지식 공유, 신규 입사자의 적응 등의 상황에서는 페어 프로그래밍이 매우 효과적일 것으로 생각합니다.