대상 독자
- 페어 프로그래밍이 뭔지 예시와 함께 알아보고 싶은 분
- 다른 사람은 페어 프로그래밍을 어떤 방식으로 진행하는지 궁금하신 분
시작하기에 앞서
최근 우아한유스방 스터디에서 세 번째 미션으로 10일간 페어 프로그래밍을 진행하였다.
페어 프로그래밍은 이전부터 관심이 많았던 협업 도구 중 하나였기에, 실무에 있을 때도 사내에서 처음으로 도입해보며 신입분과 진행해본 경험이 있었다. 하지만 그때 당시에는 너무 부족한 사전 지식과 준비로 효율적인 협업이 이루어지진 않았고, 신입 교육의 목적이 컸었던 것 같다.
따라서 이 기회를 통해 페어 프로그래밍을 조금 더 효율적으로 할 수 있는 방법이 무엇인지 알아보았고, 관련된 경험을 소개해보려고 한다.
페어 프로그래밍
페어 프로그래밍의 사전적 정의는 하나의 컴퓨터로 두 사람의 프로그래머가 같이 작업하는 애자일 소프트웨어 개발 방법 중 하나이다. 두 사람의 역할은 각각 관찰자(네비게이터)와 진행자(드라이버)로 나뉘고 수시로 역할을 교대하며 프로그래밍을 진행한다.
네비게이터는 숲을 보는 역할을 맡는다. 전체적인 방향성을 제시해주고, 막힌 곳이나 개선이 필요한 곳에서 적절한 전략과 아이디어를 제시하며 드라이버의 가이드가 되어준다.
드라이버는 직접 타이핑으로 구현하는 역할이다. 네비게이터의 가이드라인을 벗어나지 않게 수시로 커뮤니케이션을 하며 모든 집중을 프로그래밍에 쏟으며 기능을 구현한다.
규칙 정하기
본격적인 미션 진행에 앞서 페어 프로그래밍을 효율적으로 하기 위한 몇 가지 규칙을 페어(짝꿍)와 함께 정해보았다. 이 글을 참고하면서 우리가 하지 않아야 할 것들을 상기시키고 아래와 같은 규칙을 Github Wiki에 정리하였다.
- 공통
- 이해 못 했을 때 이해한 척 하지 말고, 둘의 싱크(생각)가 제대로 맞도록 한다.
- 평소의 습관대로 무조건 하려고 하지말고, 새로운 방식을 시도해보자.
- 네비게이터
- 마이크로 매니징은 지양한다.
- 피드백을 할 때 상대방에게 주입하려는 태도를 지양한다.
- 절대적으로 옳은 생각이 없으니, “나는 이런식으로도 한다”라는 식의 참고의 느낌으로 피드백을 진행한다.
- 드라이버
- 네비게이터의 의견을 열린 자세로 경청한다.
- 기계적인 수용을 하지 않도록 주의한다.
방법 정하기
페어 프로그래밍을 진행할 때 가장 좋은 방법은 오프라인으로 만나 하나의 컴퓨터에서 서로의 장비를 갈아 끼우며 번갈아 진행하는 것이다. 하지만 우리는 대부분 평일에 진행하고 거리가 멀기에 어쩔 수 없이 온라인으로 진행하였고, IntelliJ의 Code With Me와 게더타운을 사용하였다.
페어 방식은 포모도로(뽀모도로) 기법을 적용하여 네비게이터와 드라이버 교대 시간을 25분 단위로 설정하고 교대 전 5분~10분의 짧은 휴식을 통해 뇌가 과부하 되지 않도록 해주었다.
프로그래밍을 시작하기 전 구현해야 할 미션(기능)에 대한 요구사항을 정리하는 시간을 가졌다. 우리가 어떤 기능들을 만들어야 하고, 어떤 제약 조건들이 있는지 페어와 함께 싱크를 맞춘 후 Task 정리 및 일정 정리를 아래 링크에 정리하였다.
- 요구사항 정리: https://github.com/giibeom/study-java-wordle/wiki/1.-요구사항-정리
- Task 정리 및 일정: https://github.com/giibeom/study-java-wordle/wiki/2.-Task-정리-및-일정
또한 피드백에 대한 기준을 잡기 위해 소트웍스 엔솔러지 책에서 Chapter 6의 내용인 객체지향 생활체조를 참고하였다. 객체지향 생활체조 관련 내용은 아래 글에서 따로 정리해놓았다.
페어 프로그래밍의 장점
10일간 페어 프로그래밍을 통해 요구사항을 모두 구현해보면서 느낀 장점에 대해 말해보려고 한다. 참고로 실제 시간을 맞춰 진행했던 일수는 7일이고, 일별로 하루 안에 끝낼 수 있는 분량으로 나눠서 진행했다.
1. 지식 공유
네비게이터와 드라이버를 자주 교대하면서 가장 좋았던 점은 서로 간의 지식 공유였다. 내가 아는 것을 페어에게 알려주고, 반대로 내가 모르는 것을 페어가 설명해주는 것이 페어 프로그래밍에 가장 큰 장점이지 않을까 싶다.
그리고 무언가에 막혀있는 상황에서 같이 고민하며 서로가 찾아본 내용을 공유하여 빠르게 문제를 해결해나갈 수 있는 점도 정말 좋았다.
이런 점은 실무에서도 충분히 도움이 될 것 같다고 생각한다. 가령 내가 잘 모르는 도메인에서 새로운 프로젝트를 들어갈 때, 기존에 도메인을 잘 알고 사람과 페어 프로그래밍을 진행한다면 정말 빠르게 도메인에 적응할 수 있을 것이다.
또한 주니어에게 있어서 페어는 실력을 상승시킬 수 있는 최고의 기회일 것이다. 이를 통해 주니어는 빠르게 성장하여 생산성이 올라간다면 팀 자체에서도 큰 이득으로 돌아올 것이다.
2. 커뮤니케이션 스킬 향상
네비게이터와 드라이버, 어느 역할을 맡고 있든 커뮤니케이션은 항상 해야 한다. 이때 상대방에게 내 생각을 일목요연하게 전달하는 스킬이 매우 중요하다.
네비게이터는 전략과 개발 방향성을 제시해줄 때 논리 정연한 이유와 적절한 예시를 통해 드라이버가 이해하기 쉽게 전달해야 한다.
드라이버는 본인이 작성하고 있는 코드에 대해서 네비게이터가 놓치지 않게(체크 아웃) 잘 설명하면서 프로그래밍해야 한다. 만약 네비게이터가 놓쳐서 멍때리고 있는 경우에는 코딩을 잠시 멈추고 싱크를 맞추는 시간을 가져야 한다.
이런 상황들을 반복적으로 자주 경험하다 보면 자연스럽게 내 생각을 상대방이 이해하기 쉽게 전달할 수 있는 스킬이 향상된다.
3. 업무 집중도 상승
혼자 개발을 할 때보다 누군가와 같이 개발을 진행하면 자연스럽게 약간의 긴장감이 조성된다. 따라서 당연히 딴 짓을 할 수가 없게되고, 목표한 요구사항을 구현해내는데에만 오롯이 집중할 수 있다.
또한 고민되는 지점을 바로 토론할 수 있고, 피드백을 즉각적으로 받을 수 있어 불필요한 커뮤니케이션 비용을 낮출 수 있다.
페어 프로그래밍의 단점
모든 일에는 Trade-off가 따르기에 장점이 있다면 당연히 단점도 있을 것이다.
1. 극심한 체력 소모
페어 프로그래밍은 혼자 개발하는 것에 비해 훨씬 체력 소모가 심하다.
어떤 역할이든 끊임없이 말을 하며 소통해야 하므로 혼자 개발할 때 비해서 굉장히 빠르게 지칠 수 있다.
또한 업무 집중도가 상승하는 만큼 뇌를 쉬지 않고 돌리기 때문에 금방 배고파지는(?) 단점이 있다.
따라서 네비게이터, 드라이버 교대 시간에 적절한 휴식 시간을 갖는 것은 필수이다.
2. 생산성 감소
한 가지의 일을 두 명이 하니까 생산성이 반토막이 난다고 생각하는 사람들이 간혹 있다.
물론 두 명이 각자 개발을 하는 것보다는 생산성이 감소하는 건 사실이지만, 페어 프로그래밍이 숙련된 집단에서는 그렇게 많이 차이가 나지 않는다.
또한 비록 생산성이 조금은 감소할지라도 프로그램의 퀄리티는 올라갈 것이다. 네비게이터가 바로 결함을 찾아낼 확률이 높고, 즉각적으로 피드백을 바로 줄 수 있기 때문이다. 이는 곧 유지보수 비용 절약으로 이어진다.
따라서 사내에서 페어 프로그래밍을 주기적으로 진행한다면 생산성이 감소하는 것이 최소화되고, 프로그램 퀄리티는 증가할 것이다.
3. 의견 충돌
단순히 기술에 대한 의견이 안맞을 경우에는 논리적인 토론과 배려심 있는 소통 방식을 통해 합의점을 찾아가면 될 것이다.
하지만 만약 개발 스타일이나 관점, 소통 방식 등이 서로 너무 정반대라면 오히려 페어 프로그래밍이 독이 될 수 있다. 이런 경우에는 페어를 바꾸는 것도 하나의 방법이 될 수 있다.
(다행히 내 페어는 나와 너무 잘 맞는 분이라 정말 재밌게 진행하였다!)
해당 글에서는 실무에서 페어를 자주 바꾸는 것이 오히려 여러 측면에서 좋다고 설명한다.
후기
잘한 점
가장 잘했다고 생각하는 부분은 최근 수료한 NEXTSTEP ATDD과정에서 배운 내용들을 페어에게 잘 설명해줘서 본인의 것으로 만들도록 도와준 것이다. 페어 프로그래밍이 끝나갈 때쯤에는 TDD/BDD 싸이클을 잘 적용하시는 것을 보고 굉장히 뿌듯했었다.
또한 테스트 리펙터링에 대한 방법도 열심히 설명해주었다.
미션 진행 중에 현재 시간(LocalDate.now())을 이용해서 동작하는 테스트 하기 어려운 메서드가 있었다. 이때 테스트하기 어려운 영역을 외부에서 인자로 받는 형식으로 변경하는 리팩터링 방법이 떠올라서 관련된 내용을 설명해주고 네비게이터를 진행함으로써 문제를 해결했다.
마지막으로는 사소하지만 중요한 나만의 단축키와 팁들을 공유해준 것이다. 예를 들어 live template 같이 반복되는 코드 스니펫들을 설정해주는 기능, 기타 리팩터링에 유용한 단축키들을 많이 소개해주었고 다행히 페어는 흥미롭게 들어주었다.
좋았던 점
이번 미션에서는 평소에 자주 사용되는 MVC 패턴을 탈피하고 싶었다. 아무 생각 없이 사용하는 Controller-Service-Repository의 사고를 조금 깨보고 싶은 마음에서였다.
감사하게 페어가 동참해주어 각자 역할과 책임 기준으로 잘 분리된 객체 설계도를 그려보았다. 이때 페어가 정말 깔끔하게 잘 분리한 객체 설계도를 가지고 나에게 설명해주었을 때, 다시 한번 객체 지향에 대한 개념을 되짚어본 계기가 되었다.
또한 의도가 뚜렷하고 가독성 좋은 코드가 무엇인지 끊임없이 고민하며 재밌게 토론했다. 혼자 개발할 때는 항상 의문이었지만, 어디에 물어보기 애매한 궁금증들이 이 기회에 대부분 해소되었다.
(팀마다 다르겠지만, 카카오는 어떤 식으로 일하는지도 예시를 들을 수 있어서 더욱 좋았다!)
아쉬웠던 점
아쉬웠던 점은 초반에 너무 헤맸다는 것이다. 우리는 다른 팀들에 비해 시간이 오래 걸렸다.
테스트 코드를 세심하게 짜기도 했지만, 일반적인 REST API 형태가 아닌 것을 ATDD 방식으로 무작정 하려다 보니 중간에 객체 설계를 모두 변경했을 때 기존 테스트 코드가 모두 깨졌다.
따라서 테스트 전략을 바꾸어 TDD가 아닌 구현 -> 테스트 작성 순으로 깨진 테스트 코드들을 수정해 나갔다.
이때 페어에게 굉장히 미안했었다. 조금 더 내가 능숙하게 테스트 전략을 펼쳤다면, 시간을 많이 단축하고 효율적으로 요구사항을 모두 구현했을 텐데 나 때문에 괜히 시간이 더 걸렸던 것 같다.
하지만 지금 생각해보면 나에게는 굉장히 좋은 경험이기도 했다. 내가 사용하던 테스트 전략을 타인에게 설명해주고 같이 적용해보는 것이 처음이었는데, 이 기회로 시행착오를 겪으면서 전략을 보완하고 사고를 넓힌 계기가 됐다.
또한 실무에서 TDD에 대한 반응이 그다지 좋지 않은 이유에 대해서도 몸소 깨달았던 것 같다. 실무에서는 정말 복잡한 비즈니스 로직들이 얽히고설키게 돌아갈 텐데 테스트 코드부터 먼저 작성한다는 것 자체가 여간 머리 아픈 일이 아닐 것 같다는 생각이 들었다.
(실제로 테스트 코드 작성 대신, QA를 빡쌔게(?) 돌리는 서비스 기업들도 생각보다 많은 것 같다.)
앞으로도 다양한 상황에서 테스트 전략을 적용해보면서 더욱더 효율적이고 사용성 있는 테스트 전략을 만들어 나가고 싶다.
마치며
이번 미션에서의 내 페어 홀든님은 카카오를 다니신다. 그 덕분에 나는 좋은 자극과 정보들을 많이 받은 경험이었다.
최근에 혼자 개발하면서 생기는 고민 지점들을 서비스 회사에서는 어떤 식으로 할지 무척 궁금했었는데, 이 기회에 궁금한 것들을 마구 물어봤다. (Shout out to 우아한유스방 & 홀든)
미션이 끝나고 홀든님에게 페어 프로그래밍 피드백을 요청했다. 아쉬웠던 점이 있었다면 고쳐봐야겠다는 생각이었는데, 감사하게도 아래 사진처럼 칭찬만 해주셨다.
앞으로도 더욱 같이 일하기 좋은 개발자가 되기 위해 정진하자!
