Life

페어 프로그래밍에서 두 사람이 판단하는 방식에 대한 고찰

약 5분조회수를 불러오고 있어요
#페어 프로그래밍

흑백요리사를 보며 인상 깊었던 장면이 하나 있었다.
심사위원이 두 명으로 팀을 이뤄 하나의 결정을 내린다는 점이었다.

각자 다른 기준과 경험을 가진 두 사람이 같은 요리를 보고 의견을 주고받는다.
그리고 즉각 결론을 내리기보다, 서로의 판단을 확인하고 조율한 뒤 하나의 결정에 도달한다.

이 구조는 단순히 공정해 보이기 위한 연출이 아니다.
한 사람의 직관에 의존하기보다, 판단 과정 자체를 검증 가능한 상태로 만들기 위한 협업 구조에 가깝다.
실제 연구에서도 두 사람이 함께 판단할 때 오류 가능성은 낮아지고, 결과의 품질은 높아진다는 점이 반복해서 확인되고 있다.

이 장면을 보며 자연스럽게 페어 프로그래밍이 떠올랐다.
프로그래밍에서 두 사람이 문제를 함께 해결하는 구조 역시 본질적으로는 같다.
정답을 빨리 찾기 위한 방식이라기보다, 불확실성을 줄이고 판단의 질을 높이기 위한 선택이다.

처음에는 페어 프로그래밍을 꽤 단순하게 이해했다. 두 명이 같은 코드를 보면 실수가 줄고 더 나은 결과가 나오지 않을까 정도였다.

하지만 실제로 페어를 해보니 이 설명만으로는 부족했다. 어떤 순간에는 분명 강력했지만, 어떤 순간에는 오히려 어색하고 느리게 느껴졌기 때문이다.

점점 분명해진 사실은 이것이었다. 페어 프로그래밍의 핵심은 코드 작성 자체보다 사고를 지속적으로 맞춰보게 만드는 구조에 있었다.

이 글에서는 왜 페어 프로그래밍을 '같이 코딩하는 방식'보다 '같이 판단하는 구조'로 이해하게 됐는지 정리한다.

페어 프로그래밍에 대한 흔한 오해

가장 흔한 오해는 페어 프로그래밍을 역할 분담으로 이해하는 것이다.
Driver는 코드를 치고 Navigator는 옆에서 지켜보는 방식이라는 생각이다.

이렇게 시작하면 페어 프로그래밍은 쉽게 실시간 코드 리뷰나 옆에서 알려주는 개발로 변질된다.
그리고 이 구조는 오래가지 못한다.

Navigator는 점점 답답해지고 Driver는 방어적으로 변한다.
결국 한쪽이 키보드를 가져가거나 말 없는 동반 작업이 된다.

이 상태는 페어 프로그래밍이 아니다.
이미 실패한 협업이다.

Driver와 Navigator의 진짜 역할

Driver와 Navigator는 단순한 역할 분담이 아니다.
이 둘은 관점의 분리에 가깝다.

Driver는 지금 이 순간의 구현을 책임진다.
현재 맥락을 코드로 정확하게 표현하는 역할이다.

Navigator는 더 높은 레벨에서 사고한다.
사전에 협의한 문서와 맥락을 기반으로 설계 방향, 리스크, 다음 선택지를 살핀다.

여기서 가장 중요한 점이 있다.
Navigator의 의견은 정답이 아니라 가설이다.

Driver는 그 가설을 무조건 따라야 하는 존재가 아니다.
대신 Driver에게는 하나의 중요한 책임이 있다.

왜 이 선택을 했는지 설명할 수 있어야 한다는 것이다.

설명 없는 구현은 독주가 되고,
설명된 선택은 협업이 된다.

페어 프로그래밍의 핵심은 전환이다

학습 과정에서 가장 크게 인식이 바뀐 지점은 여기였다.
페어 프로그래밍의 핵심은 누가 Driver인지가 아니라,
언제 어떤 기준으로 역할을 바꾸는가에 있다.

시간 단위 전환은 일정한 리듬을 만드는 데는 도움이 된다.
하지만 실제로는 "이거까지만 하고 바꾸자"라며 시간을 넘겨버리는 경우가 많다.

반면 커밋 단위나 TDD 사이클 단위 전환은 기준이 명확하다.
지금 우리가 같은 문제를 같은 수준에서 이해하고 있는지를 강제로 확인하게 만든다.

역할을 바꾸는 순간,
상대의 사고를 내가 직접 구현해야 한다.

이때 사고가 동기화되어 있지 않다면 즉시 드러난다.
바로 이 지점에서 페어 프로그래밍의 효과가 발생한다.

페어가 무너지는 순간은 정해져 있어요

가장 흔한 최악의 상황은 비교적 명확하다.
Navigator가 답답해져서
"이건 내가 직접 해야겠다"고 느끼는 순간이다.

이 문제는 개인 성향에서 시작되지 않는다.
구조 실패다.

Navigator의 의견이 제안으로 나오고,
검증되지 못한 채 설명 없이 무시되거나 거부될 때
이 상황은 발생한다.

그래서 페어 프로그래밍에는 반드시 지켜야 할 균형이 있다.

Navigator의 의견은 가설로 다룬다.
Driver의 선택은 반드시 설명 가능해야 한다.

이 균형이 깨지는 순간,
페어는 협업이 아니라 경쟁이 된다.

페어할 때 가장 중요한 것

처음에는 서로 친해지는 게 먼저라고 생각했다.
하지만 고민해보니 순서는 반대였다.

친해지기 전에 먼저 해야 할 것은
작업 방식에 대한 합의다.

목표는 무엇인지,
속도와 설명 중 무엇을 우선할지,
역할 전환은 어떤 기준으로 할지.

이 정도만 합의해도 페어의 절반은 성공한다.

아이러니하게도 같이 문제를 풀다 보면
굳이 노력하지 않아도 자연스럽게 친해진다.
공통의 문제 공간이 생기기 때문이다.

제가 정리한 페어 프로그래밍의 정의

이 과정을 거치며 페어 프로그래밍을 이렇게 정의하게 됐다.

페어 프로그래밍은 두 명이 하나의 코드를 작성하는 기법이 아니다.
의미 있는 단위로 역할을 전환하며, 서로의 사고가 같은 방향으로 정렬되어 있는지를 반복적으로 검증하는 협업 구조다.

이 구조 안에서
Navigator의 의견은 가설로 다뤄지고,
Driver의 구현은 설명 가능한 선택이 된다.

그 균형이 유지될 때,
페어 프로그래밍의 힘이 나온다.

마무리

페어 프로그래밍을 학습하며 느낀 점은 명확하다.
이것은 코딩 스킬이라기보다 사고를 드러내는 연습에 가깝다.

혼자서는 숨길 수 있었던 모호함이
페어에서는 그대로 드러난다.

그래서 어렵고,
그래서 가치 있다.

앞으로의 페어에서는
누가 더 잘 치는가보다
우리가 같은 문제를 보고 있는가를
더 자주 확인하려고 한다.

지금 남은 기준도 같다.
페어 프로그래밍은 속도를 올리는 기술이기 전에, 서로의 판단이 같은 방향을 보고 있는지 반복해서 확인하는 협업 구조라는 점이다.

참고 자료

이 글은 개인적인 학습과 경험을 바탕으로 정리했지만,
아래 자료들의 관점과 문제의식을 참고하며 이해를 확장했다.

댓글