페어 프로그래밍에 대한 애증

팀에서 페어 프로그래밍을 도입했다

새 팀으로 이동했더니 매주 화목에 페어 프로그래밍을 한다고 했다. 처음 들었을 때 솔직한 반응은 "생산성 떨어지는 거 아닌가"였다. 두 명이 하나의 키보드를 쓴다는 건, 한 명의 생산량이 0이 된다는 뜻 아닌가. 단순 계산으로 손해 같았다.

6개월 해보니까 그렇게 단순한 문제가 아니었다.

첫 페어링: 민망했다

첫 파트너는 나보다 2년 차 높은 시니어였다. 내가 네비게이터(방향 제시), 시니어가 드라이버(코딩)로 시작했다. 근데 내가 방향을 제시해야 하는데, 시니어의 코딩 속도가 너무 빨라서 따라가기 바빴다. "잠깐, 거기서 왜 그렇게 했어요?"라고 물어보고 싶었는데, 흐름을 끊을까 봐 참았다.

나중에 알았는데, 흐름을 끊는 게 페어링의 핵심이었다. 네비게이터는 드라이버가 놓치는 걸 잡아야 하니까, 질문하고 멈추는 게 당연한 거다.

(첫날 페어링 후 너무 지쳐서 집에 가서 아무것도 못했다. 정신적 에너지 소모가 장난이 아니었다.)

생산성 논쟁

페어 프로그래밍 도입 3개월 후 팀에서 데이터를 뽑아봤다. 버그 수는 37% 줄었고, 코드 리뷰 시간은 52% 단축됐다. 근데 기능 개발 속도는 약간 느려졌다. 순수 코드 작성량으로 보면 솔로 프로그래밍이 빠른 게 맞다.

핵심은 "뭘 기준으로 생산성을 측정하느냐"다. 코드 줄 수로 보면 페어링이 손해다. 근데 버그 포함한 전체 개발 사이클로 보면, 나중에 디버깅하는 시간이 줄어서 오히려 이득일 수 있다.

좋았던 점

지식 전파가 빨랐다. 한 명이 아는 패턴을 다른 한 명이 자연스럽게 배운다. 키보드 단축키, 디버깅 기법, 코드 구조화 방식 같은 것들이 전염된다. 시니어와 페어링하면서 배운 Vim 단축키가 내 개발 속도를 올려줬다.

집중도도 높아졌다. 혼자 코딩하면 슬랙 보고, 유튜브 보고, 딴짓하기 쉬운데 옆에 사람이 있으면 그럴 수가 없다. 2시간 페어링이 혼자 4시간 코딩한 것보다 실질적 작업량이 많은 경우가 있었다.

싫었던 점

솔직히 매일은 못하겠다. 에너지 소모가 크다. 내 생각을 실시간으로 말로 표현해야 하는 게 피곤하다. 가끔은 혼자서 조용히 코드와 씨름하고 싶을 때가 있다.

파트너 궁합도 중요하다. 코딩 스타일이 비슷한 사람과는 시너지가 나는데, 너무 다른 사람과는 충돌이 생긴다. 한 파트너가 세미콜론을 안 쓰는 스타일이었는데, 나는 항상 쓰는 스타일이라 사소한 부분에서 계속 마찰이 있었다.

실수: 말을 너무 안 했다

처음 한 달 동안 네비게이터 역할을 할 때 내 생각을 말하는 걸 주저했다. "틀리면 어쩌지"라는 두려움 때문에. 근데 페어 프로그래밍에서 틀린 생각을 말하는 게 아무 말 안 하는 것보다 100배 낫다. 틀리면 바로 교정이 되니까. 안 말하면 드라이버가 방향을 잘못 잡아도 모른다.

내 결론

페어 프로그래밍은 만능이 아니다. 단순 반복 작업에는 비효율적이고, 깊은 사고가 필요한 설계 작업에는 혼자가 나을 때도 있다. 근데 복잡한 로직, 새로운 도메인, 신입 온보딩에는 확실히 효과적이다.

주 5일 중 2일 정도가 적당한 빈도인 것 같다. 매일은 지치고, 안 하면 팀의 지식 공유가 끊긴다. 근데 이것도 팀마다 다를 수 있다.