페어 프로그래밍

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요
2. 경제성
3. 설계 품질
4. 만족도
5. 학습 효과
6. 팀워크 및 의사소통
7. 연구 결과
8. 비효율성 징후
9. 페어링 유형
10. 원격 페어 프로그래밍
11. 장점 (일본어 문서)
12. 단점 (일본어 문서)
13. 파생 (일본어 문서)
참조

1. 개요

페어 프로그래밍은 두 명의 프로그래머가 한 컴퓨터에서 함께 코딩하는 소프트웨어 개발 방법이다. 경제성 측면에서 페어 프로그래밍은 코드 결함 감소, 설계 품질 향상, 팀워크 및 의사소통 증진, 학습 효과, 만족도 증가 등의 이점을 제공한다. 연구 결과에 따르면 코딩 속도는 감소하지만 버그 수도 줄어들고, 복잡한 작업에서 높은 품질과 정확성을 달성하는 데 도움이 될 수 있다. 그러나 간단한 작업에서는 생산성 감소를 초래할 수 있으며, 비효율적인 징후가 나타날 수도 있다. 페어 프로그래밍은 전문가-전문가, 전문가-초보자, 초보자-초보자 등 다양한 유형으로 수행될 수 있으며, 원격 환경에서도 가능하다.

더 읽어볼만한 페이지

소프트웨어 리뷰 - 코드 검토
코드 검토는 작성된 코드의 품질 향상과 오류 감소를 위해 수행되는 검토 방식이며, 오류 제거, 디버깅, 유지보수, 기능 개선에 효과적이고 소프트웨어의 진화 가능성과 유지보수성에 영향을 미친다.
소프트웨어 리뷰 - 정적 프로그램 분석
정적 프로그램 분석은 소프트웨어 개발 시 코드를 실행 없이 분석하여 오류, 보안 취약점, 코딩 표준 위반 등을 탐지하는 기술로, 개발 비용 절감, 품질 향상, 시스템 신뢰성 확보에 기여하며 다양한 레벨로 분석 가능하다.
애자일 소프트웨어 개발 - 유스 케이스
유스 케이스는 시스템과 액터 간 상호작용을 통해 시스템 목표 달성에 기여하는 동작들을 나타내는 요구 사항 캡처, 모델링, 명세 기법으로, 객체 지향 소프트웨어 공학에서 기능 요구 사항을 캡처하는 데 중요한 역할을 하며 다양한 분야에서 활용된다.
애자일 소프트웨어 개발 - 스크럼 (애자일 개발 프로세스)
스크럼은 제품 개발을 위해 반복적, 점진적 접근 방식을 사용하는 애자일 소프트웨어 개발 방법론의 프레임워크로, 제품 책임자, 개발자, 스크럼 마스터로 구성된 팀을 중심으로 투명성, 검사, 적응의 원칙을 따른다.
익스트림 프로그래밍 - 워드 커닝햄
워드 커닝햄은 미국의 컴퓨터 프로그래머로, 최초의 위키 사이트 WikiWikiWeb을 만들고 기술 부채 개념을 창안했으며, 소프트웨어 개발 방법론 발전에 기여했다.
익스트림 프로그래밍 - JUnit
JUnit은 자바 환경에서 단위 테스트를 위한 프레임워크로, 반복적인 테스트 실행을 통해 버그 수정에 용이하며, 어노테이션 기반의 간편한 테스트 코드 작성과 IDE 통합을 지원하여 개발 효율성을 높인다.

페어 프로그래밍
개요
두 명의 프로그래머가 한 컴퓨터에서 협력하여 코딩하고 있다.
종류	소프트웨어 개발 기법
설명	두 명의 프로그래머가 한 워크스테이션에서 작업하는 소프트웨어 개발 기법
상세 내용
역할	드라이버: 키보드/마우스를 제어하며 코드를 적극적으로 구현하는 프로그래머 옵서버 (네비게이터): 드라이버의 작업을 지속적으로 관찰하여 전술적 (구문, 철자 등) 결함을 식별하고 작업 방향에 대해 전략적으로 생각하는 프로그래머
장점	코드 품질 향상 지식 공유 팀워크 증진
단점	시간 및 비용 증가 가능성 개인 선호도에 따른 비효율 발생 가능성
적용 분야	애자일 소프트웨어 개발 익스트림 프로그래밍 스크럼
관련 용어	코드 리뷰 테스트 주도 개발 지속적 통합
기타
주의사항	두 프로그래머 간의 원활한 의사소통이 중요함 역할 교대를 통해 집중력 유지 적절한 페어 프로그래밍 도구 활용

2. 경제성

페어 프로그래밍은 프로그래머가 개별적으로 작업하는 것보다 작업 시간을 늘릴 수 있다. 그러나 결과적으로 생성되는 코드에는 결함이 적다.^[2] 코드 개발 시간 외에도 현장 지원 비용 및 품질 보증과 같은 다른 요소도 투자 수익에 영향을 미치는데, 페어 프로그래밍은 프로그램의 결함을 줄여 이러한 비용을 상쇄할 수 있다.^[2]

실수를 예방하는 것 외에도 다른 무형의 이점이 존재할 수 있다. 예를 들어, 함께 작업하는 동안 전화 통화나 다른 방해 요소를 거부하는 예의, 합의된 간격으로 휴식을 덜 취하거나 휴식을 공유하여 전화 통화에 응답하는 것 (하지만 누군가 기다리고 있으므로 빠르게 업무로 복귀하는 것)과 같은 이점이 있다. 또한 팀의 한 구성원은 다른 구성원이 모르는 주제나 기술에 대해 알고 있을 수 있으며, 이는 솔루션을 찾거나 테스트하는 데 걸리는 시간을 줄이거나 더 나은 솔루션을 허용하여, 혼자 작업하는 것에 비해 프로그래머의 기술, 지식 및 경험을 효과적으로 확장할 수 있다. 이러한 무형의 이점들은 정확하게 측정하기는 어렵지만 보다 효율적인 작업 시간에 기여할 수 있다.

페어 프로그래밍의 이점은 다음과 같다:

규범 의식 증대: 개인 작업보다 게으름을 피우지 않고 작업을 진행할 가능성이 높다.
더 나은 코드: 시너지 효과로 설계의 질이 향상될 것으로 기대된다.
작업 효율 향상: 혼자 작업할 때와 흐름이 달라진다. 예를 들어, 다음에 무엇을 해야 할지 생각하는 시간이 줄어든다. 또한, 외란 요인에 대해서도 내성을 보이며, 다른 사람이 끼어들더라도 한쪽이 응대하는 동안 다른 한쪽이 작업을 진행할 수 있다.
다수의 개발자에 의한 설계: 페어를 자주 교체하면 여러 사람이 하나의 기능 개발에 관여하게 된다. 이로 인해 더 나은 설계가 만들어진다.
근로 의욕 향상: 페어 프로그래밍이 혼자 작업하는 것보다 더 즐겁다고 느끼는 개발자도 있다.
집단적 코드 소유권: 프로젝트의 모든 사람이 페어 프로그래밍을 수행하고 빈번하게 페어를 교체하는 경우, 해당 코드 전체에 대해 모든 사람이 어느 정도의 지식을 공유하게 된다.
교육적 측면: 페어 프로그래밍에서는 불필요한 노력을 들이지 않고 지식을 팀 전체에서 공유할 수 있다.
팀워크: 페어 프로그래밍을 함으로써 팀의 각자가 서로를 더 잘 알게 되어 결속력을 쉽게 만들어낼 수 있다.
방해 감소: 혼자 작업하는 사람에게 방해를 하는 것보다 페어 프로그래밍 중인 두 사람에게 방해를 하는 것이 더 저항감이 들기 때문에, 방해가 줄어든다.
워크스테이션 수 감소: 두 사람이 하나의 워크스테이션을 사용하므로, 워크스테이션이 적게 필요하며, 남은 워크스테이션을 다른 용도로 활용할 수 있다.

솔트레이크시티 유타 대학교의 로리 윌리엄스에 따르면, 페어 프로그래밍에서는 두 명의 프로그래머가 개인적으로 작업하는 경우와 비교하여 코딩 속도가 15% 감소하지만, 버그의 수도 15% 줄어든다고 한다.

윌리엄스 외 (2000)의 조사에 따르면, 프로그램의 정확성은 15% 향상되었고, 시간적으로는 20%에서 40% 정도 절감되었으며, 최종적인 성과로는 15%에서 60%의 효율 향상이 있다고 한다.

최근의 대규모 연구(Arisholm 외 2007)에 따르면, 복잡한 시스템에서는 프로그램의 정확성이 48% 향상되었고, 큰 시간 절감은 나타나지 않았다고 한다. 반면, 단순한 시스템에서는 시간이 20% 절감되었고, 정확성에는 큰 변화가 없었다고 한다. 전체적으로는 시간 절감이나 정확성 향상의 경향은 다양하지만, 최종적인 효율은 84% 향상되었다고 한다.

다른 최근 연구에 따르면, 상급자 1명의 경우와 상급자끼리의 페어 사이의 생산성 향상보다, 초보자 1명과 초보자끼리의 페어를 비교했을 때 생산성 향상이 더 크다고 한다.

3. 설계 품질

페어 프로그래밍에서 두 프로그래머는 서로 다른 경험과 관점을 바탕으로 문제에 대해 다양한 해결책을 제시할 수 있다. 이들은 목표와 계획을 공유하고 의견 충돌 시 함께 해결 방안을 모색하며 더 많은 해결책을 고려한다.^[3] 이 과정에서 잘못된 방법을 선택할 가능성이 줄어 프로그램 설계 품질이 향상될 수 있다.^[3]

4. 만족도

2000년에 실시된 온라인 페어 프로그래밍 설문 조사에서 프로그래머의 96%가 페어 프로그래밍을 할 때 혼자 프로그래밍하는 것보다 더 즐겁게 일한다고 답했다. 또한 95%는 페어 프로그래밍을 할 때 자신의 작업에 대해 더 자신감을 느낀다고 답했다. 그러나 이 설문 조사는 자발적으로 페어 프로그래밍을 하는 프로그래머들을 대상으로 했기 때문에, 강제로 페어 프로그래밍을 하는 프로그래머들은 고려하지 않았다.^[4]

5. 학습 효과

페어 프로그래밍은 업계나 교실에서 프로그래머 간 지식을 지속적으로 공유하게 한다.^[4] 프로그래밍 언어 규칙, 전반적인 설계 기술 등 많은 것을 배울 수 있다.^[5] "무차별 페어링"은 각 프로그래머가 한 파트너와만 짝을 이루는 대신, 팀의 다른 모든 프로그래머와 소통하고 함께 작업하여 시스템에 대한 지식이 전체 팀에 확산되도록 한다.^[2] 페어 프로그래밍을 통해 프로그래머는 파트너의 코드를 검토하고 피드백을 제공할 수 있으며, 이는 자신의 학습 활동을 모니터링하는 능력을 향상시킨다.^[5]

6. 팀워크 및 의사소통

페어 프로그래밍은 팀 구성원들이 정보를 빠르게 공유할 수 있도록 하여, 서로에게 숨겨진 의제를 가질 가능성을 줄여준다. 이는 페어 프로그래머들이 더 쉽게 의사소통하는 법을 배우도록 돕는다. "이는 프로젝트 내 의사소통 대역폭과 빈도를 높여, 팀 내 전반적인 정보 흐름을 증가시킨다."^[2]

7. 연구 결과

페어 프로그래밍의 효과에 대한 여러 연구와 메타 분석이 존재한다. 메타 분석에 따르면, 페어 프로그래머는 혼자 작업하는 프로그래머보다 더 많은 설계 대안을 고려하고, 더 단순하고 유지보수가 쉬운 설계를 도출하며, 설계 결함을 더 일찍 발견하는 경향이 있다. 그러나 "페어 프로그래밍에 대한 출판된 연구에서 출판 편향의 징후" 때문에 연구 결과가 영향을 받았을 수 있다는 우려도 제기되었다.^[6]

페어 프로그래머는 혼자 작업하는 프로그래머보다 작업을 더 빨리 완료할 수 있지만, 총 작업 시간은 증가한다. 따라서 관리자는 작업 완료 시간 단축, 테스트 및 디버깅 시간 감소와 같은 이점과 코딩 비용 증가를 비교해야 한다.

페어링의 이점은 프로그래머가 시작 전에 완전히 이해하지 못하는 복잡한 작업, 즉 창의성과 정교함이 요구되는 도전적인 작업과 전문가에 비해 초보자에게 더 크다.^[7] 페어 프로그래밍은 복잡한 프로그래밍 작업에서 높은 품질과 정확성을 달성하는 데 도움이 될 수 있지만, 개발 노력(비용)도 크게 증가시킬 수 있다.^[6]

반면, 페어가 이미 완전히 이해하고 있는 간단한 작업의 경우, 페어링은 생산성 감소를 초래한다.^[8] 코드 개발 시간을 줄일 수 있지만 프로그램의 품질을 떨어뜨릴 위험도 있다.^[6] 충분한 멘토의 지원 없이 초보자끼리 페어링하는 경우에도 생산성이 감소할 수 있다.^[9]

GitHub Copilot과 같은 AI 지원 도구를 사용하는 프로그래머에 대한 연구에 따르면, 일부 프로그래머는 AI 지원을 페어 프로그래밍과 유사하다고 생각했지만, 실제로는 프로그래머 경험 측면에서 이러한 도구의 사용은 매우 다르며, 인간 프로그래머는 드라이버와 네비게이터 역할을 반복적으로 전환해야 했다.^[10]

로리 윌리엄스의 연구에 따르면, 페어 프로그래밍은 코딩 속도가 15% 감소하지만, 버그 수도 15% 줄어든다.^[2] 테스트나 디버깅에는 코딩보다 시간이 더 걸리므로, 이는 주목할 만한 결과이다.

윌리엄스 외 (2000)의 조사에서는 프로그램의 정확성이 15% 향상되었고, 시간적으로는 20%에서 40% 정도 절감되었으며, 최종적으로는 15%에서 60%의 효율 향상이 있었다고 한다.

최근 연구(Arisholm 외 2007)에 따르면, 복잡한 시스템에서는 프로그램의 정확성이 48% 향상되었고, 큰 시간 절감은 나타나지 않았다. 반면, 단순한 시스템에서는 시간이 20% 절감되었고, 정확성에는 큰 변화가 없었다. 전체적으로는 시간 절감이나 정확성 향상의 경향은 다양하지만, 최종적인 효율은 84% 향상되었다고 한다. 다만, 이러한 연구 결과는 다른 조건이 동일하다는 보장이 없고, 다른 요인을 배제하지 않았다는 한계가 있다.

다른 최근 연구에서는 상급자 1명의 경우와 상급자끼리의 페어 사이의 생산성 향상보다, 초보자 1명과 초보자끼리의 페어를 비교했을 때 생산성 향상이 더 크다고 보고되었다. ("Int J. of Human Computer Studies Vol (64) 2006").

8. 비효율성 징후

페어 프로그래밍이 제대로 수행되지 않고 있다는 징후는 다음과 같다.

불참: 한 사람이 키보드에서 물리적으로 떨어지거나, 이메일을 확인하거나, 심지어 잠이 드는 형태로 나타날 수 있다.
"주인 바라보기": 한 사람이 다른 사람보다 경험이 많을 경우 발생할 수 있다. 이 경우, 경험이 적은 사람은 관찰자 역할을 하며, 코딩 활동의 대부분을 경험이 많은 파트너에게 위임한다. 이는 쉽게 불참으로 이어질 수 있다.

9. 페어링 유형

페어 프로그래밍에서 페어링 유형은 다음과 같이 나눌 수 있다.^[11]^[2]

'''전문가-전문가''': 전문가-전문가 페어 프로그래밍은 가장 높은 생산성을 낼 수 있지만, 두 프로그래머 모두 기존 방식에 익숙하여 새로운 통찰력을 얻기 어려울 수 있다.
'''전문가-초보자''': 전문가-초보자 페어 프로그래밍은 전문가가 초보자를 지도하며 지식을 공유할 수 있는 좋은 기회이다. 또한 초보자가 기존 방식에 대해 질문함으로써 새로운 아이디어를 얻을 수도 있다. 하지만, 초보자가 위축되어 소극적으로 참여하거나, 전문가가 인내심이 부족하여 초보자의 참여를 어렵게 만들 수도 있다.^[11]
'''초보자-초보자''': 초보자-초보자 페어 프로그래밍은 두 초보자가 함께 작업하며 서로에게 도움을 줄 수 있지만, 일반적으로 권장되지 않는다. 적절한 역할 모델이 없어 좋은 습관을 배우기 어렵기 때문이다.^[2]

10. 원격 페어 프로그래밍

'''원격 페어 프로그래밍'''은 '''가상 페어 프로그래밍''' 또는 '''분산 페어 프로그래밍'''이라고도 하며, 두 프로그래머가 다른 위치에 있으며, 실시간 공동 편집기, 공유 데스크톱 또는 원격 페어 프로그래밍 IDE 플러그인을 통해 작업하는 페어 프로그래밍이다.^[12] 원격 페어링은 대면 페어링에는 없는 어려움을 야기하는데, 조정에 대한 추가적인 지연, 인덱스 카드와 같은 "경량" 도구 대신 "헤비급" 작업 추적 도구에 더 많이 의존, 그리고 누가 "키보드를 가지고 있는지"와 같은 문제에 대한 혼란과 갈등을 야기하는 언어적 의사 소통의 손실 등이 있다.^[13]

도구 지원은 다음과 같은 방법으로 제공될 수 있다.

전체 화면 공유 소프트웨어^[14]^[15]
터미널 멀티플렉서
특수 분산 편집 도구
화면 공유 소프트웨어가 양방향 오디오 기능을 제공하지 않을 경우, 오디오 채팅 프로그램 또는 VoIP 소프트웨어가 도움이 될 수 있다. 헤드셋을 사용하면 프로그래머의 손이 자유롭게 유지된다.
클라우드 개발 환경
협업 페어 프로그래밍 서비스

원격 근무 등, 어떠한 이유로 원격지에서 작업하는 경우, 문자를 입력할 때마다 상대방 컴퓨터에 변경 사항이 실시간으로 반영되는 에디터나 통합 개발 환경의 플러그인을 사용하거나, 화면 전송을 위한 소프트웨어를 사용하여 진행한다.

git, docker 등을 이용하여 동일한 소스의 설계와 시험을 동시에 분담하여 작성하거나, 서로 issue를 발행하면서 서로 close하는 등의 방법을 사용하기도 한다.

11. 장점 (일본어 문서)

페어 프로그래밍은 다음과 같은 장점들을 가진다고 알려져 있다. 아래에 나열된 항목들은 중요도 순서와는 무관하다.^[2]^[4]^[5]

규범 의식 증대: 혼자 작업할 때보다 페어 프로그래밍을 할 때, 게으름을 피우지 않고 작업을 진행할 가능성이 더 높다.
더 나은 코드: 두 사람이 함께 작업함으로써 시너지 효과를 내어 설계 품질이 향상될 수 있다.
작업 효율 향상: 혼자 작업할 때와는 다른 작업 흐름을 보인다. 예를 들어, 다음에 무엇을 해야 할지 생각하는 시간이 줄어든다. 또한, 외부 방해 요인에 대한 내성이 강해져서, 다른 사람이 끼어들더라도 한쪽이 응대하는 동안 다른 한쪽은 작업을 계속할 수 있다.
다수의 개발자에 의한 설계: 페어를 자주 교체하면 여러 사람이 하나의 기능을 개발하는 데 참여하게 된다. 이는 더 나은 설계를 유도한다. 예를 들어, 한 페어가 해결하지 못하는 문제에 직면하여 작업이 중단되더라도, 다른 페어에서는 해결 방법을 찾을 수 있다.
근로 의욕 향상: 혼자 작업하는 것보다 페어 프로그래밍을 더 즐겁게 느끼는 개발자들도 있다.
집단적 코드 소유권: 프로젝트의 모든 구성원이 페어 프로그래밍을 하고 페어를 자주 교체하면, 모든 사람이 코드 전체에 대한 지식을 어느 정도 공유하게 된다.
교육적 측면: 초보자도 자신만의 고유한 지식(프로그래밍 기술 등)을 가지고 있다. 페어 프로그래밍을 통해 이러한 지식을 팀 전체와 불필요한 노력 없이 공유할 수 있다.
팀워크: 페어 프로그래밍을 통해 팀원들이 서로를 더 잘 이해하게 되어 팀 결속력을 높일 수 있다.
방해 감소: 혼자 작업하는 사람에게 방해하는 것보다 페어 프로그래밍 중인 두 사람에게 방해하는 것이 더 어렵기 때문에, 방해가 줄어드는 경향이 있다.
워크스테이션 수 감소: 두 사람이 하나의 워크스테이션을 사용하므로, 필요한 워크스테이션 수가 줄어들고, 남는 워크스테이션을 다른 용도로 활용할 수 있다.

유타 대학교의 로리 윌리엄스의 연구에 따르면, 페어 프로그래밍은 코딩 속도가 15% 느려지지만, 버그 수도 15% 감소한다. 테스트와 디버깅에는 코딩보다 더 많은 시간이 소요되므로, 이 결과는 주목할 만하다.^[5]

윌리엄스 외 (2000)의 연구에서는 프로그램의 정확성이 15% 향상되고, 시간은 20%에서 40% 정도 절감되어, 최종적으로 15%에서 60%의 효율 향상을 보였다. 그러나 다른 조건이 동일하다는 보장은 없으며, 다른 요인들을 배제하지 않았다.

최근의 대규모 연구(Arisholm 외 2007)에 따르면, 복잡한 시스템에서는 프로그램 정확성이 48% 향상되었지만, 큰 시간 절감은 없었다. 반면, 단순한 시스템에서는 시간이 20% 절감되었고, 정확성에는 큰 변화가 없었다. 전체적으로는 시간 절감이나 정확성 향상의 경향은 다양하지만, 최종적인 효율은 84% 향상되었다고 하지만, 이 역시 다른 조건이 동일하다는 보장은 없으며, 다른 요인들을 배제하지 않았다.

다른 최근 연구에서는 상급자 한 명과 상급자 페어의 생산성 향상보다, 초보자 한 명과 초보자 페어의 생산성 향상이 더 크다고 보고되었다.

12. 단점 (일본어 문서)

숙련된 개발자는 초보자와의 페어 프로그래밍을 지루하게 느낄 수 있다.^[16]
일부 기술자는 혼자 작업하는 것을 선호하며, 페어 작업을 귀찮게 느낄 수도 있다.^[16]
페어 프로그래밍으로 생산성이 반드시 향상된다는 보장은 없다.^[16]
숙련된 기술자는 매우 정확한 코드를 작성하므로, 페어를 이루더라도 다른 한 명이 기여할 부분이 없을 수 있다. 그러나 페어 프로그래밍의 목적은 정확성 향상뿐만 아니라 지식 및 기술 공유라는 측면도 있다.^[16]
코딩 스타일의 차이로 인해 충돌이 발생할 수 있다. 익스트림 프로그래밍에서는 코딩 스타일을 통일해야 한다.^[16]
각자의 일정이 다른 프로젝트에서는 일정이 맞는 경우에만 페어 프로그래밍이 가능하다. 따라서 페어 프로그래밍을 채택하면 작업에 소요되는 공수가 증가하고, 페어 프로그래밍에 할애할 수 있는 시간이 제한되어 완료까지의 기간이 길어질 수 있다. 익스트림 프로그래밍에서는 코드를 특정 개인이 독점하지 않고, 30분에서 수 시간^[17] 간격으로 페어를 교환해야 한다. 즉, 작업 가능한 두 명이 태스크를 수행한다. 이는 익스트림 프로그래밍 자체의 태스크 세분화에 기인한다.^[16]

13. 파생 (일본어 문서)

원격 근무 등 어떤 이유로 원격지에서 작업하는 경우, 문자를 입력할 때마다 상대방 컴퓨터에 변경 사항이 실시간으로 반영되는 에디터나 IDE 플러그인을 사용하거나, 화면 전송 소프트웨어를 사용하여 진행한다.^[12] git, docker 등을 이용하여 동일한 소스의 설계와 시험을 동시에 분담하여 작성하거나, 서로 issue를 발행하고 close하는 방법을 사용하기도 한다.

참조

_[1] 간행물 Integrating pair programming into a software development process 2001-02-19
_[2] 논문 The Costs and Benefits of Pair Programming http://collaboration[...]
_[3] 서적 Empirical Studies of Programmers: Fourth Workshop Ablex
_[4] 논문 Strengthening the case for pair programming http://sunnyday.mit.[...]
_[5] 논문 In support of student pair programming
_[6] 논문 The Effectiveness of Pair Programming: A Meta-Analysis 2009-07
_[7] 논문 Pair programming productivity: Novice–novice vs. expert–expert http://www.cs.utexas[...] 2012-11-18
_[8] 논문 Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise http://simula.no/res[...] 2008-07-21
_[9] 웹사이트 Will Pair Programming Really Improve Your Project? http://www.methodsan[...] 2011-05-28
_[10] 논문 What is it like to program with artificial intelligence? https://www.ppig.org[...] 2023-03-27
_[11] 서적 Pair Programming Illuminated https://books.google[...] Addison-Wesley Professional 2003
_[12] 논문 Globally distributed software development and pair programming
_[13] 논문 Understanding Tools and Practices for Distributed Pair Programming http://www.jucs.org/[...] 2010-04-30
_[14] 웹사이트 Agile Ajax: Pair Programming with VNC http://blogs.pathf.c[...]
_[15] 웹사이트 Pair Programming – The Ultimate Setup and the other options we tried. – Jonathan Cogley's Blog http://weblogs.asp.n[...]
_[16] 문서 en:Extreme_programming_practices#Coding_standard
_[17] 웹사이트 Pair Rotation Frequency http://c2.com/cgi/wi[...]
_[18] 간행물 Integrating pair programming into a software development process 2001-02-19