Pair Programming에 대한 기초 개념 부터. 실제적 활용. 그리고 그 내부에서 발생되는 문제 상황에 대한 대안까지. 의식적으로 ! 무심코 하던 Pair Programming을 잘 해보자는 이야기 ^^

1. Pair Programming
팀. 올림포스

2. Pair Programming is very simple.
Two programmers work together
at one computer on the same task.
Done!

3. 바로 이렇게 ?!

4. 둘 이서 한 키보드만 쓰는 게 아니
라면,
그 이상 뭐가 있는 것일까?

5. 실험 결과, 이 고무 인형과 Pair Programming 하는 것도 효과가
있었다.
debug his code by forcing himself to explain it, line-by-line, to the duck.
참고: http://en.wikipedia.org/wiki/Rubber_duck_debugging
We called it the Rubber Duck method of debugging. It goes like this:
1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck
(bathtub variety)
2) Place rubber duck on desk and inform it you are just going to go over
some code with it, if that's all right.
3) Explain to the duck what you code is supposed to do, and then go into
detail and explain things line by line
4) At some point you will tell the duck what you are doing next and then
realise that that is not in fact what you are actually doing. The duck
will sit there serenely, happy in the knowledge that it has helped you
on your way.
Works every time. Actually, if you don't have a rubber duck you could at
a pinch ask a fellow programmer or engineer to sit in.

6. 이 이상의 길은 성숙된 자를 위한 길입니다.
인격이 성숙되지 않았으면, 고무 인형과도
충분.
경 고!

8. 당장 나가서 오리 인형을 하나 사오
자!
오리 인형이 오히려 좋을 수도...

10. 효과가 있을까?
효과가 있음은 어떤 목표가 달성 되는 가를
의미.
우리가 Pair Programming을 하는 이유는?

13. 번갈아 가며, 백병전을
번갈아 가며, 전황 및 전략
을
번갈아 가며, 다른 시각을
Pair Programming 동작 기작
나를 기다리는 나의 짝.
나를 바라보고 있는 짝.
너를 실망 시키기 싫은
나.
동일한 목표와 계획은 가지
지만,
서로 다른 경험을 가지고 있
고,
서로 다른 지식을 가지고 있
고,
공동의 해결안을 찾아낸다.
지속적 리뷰는 지속적 학
습
한 명만 알 때는, 지식 전
파
문제를 설명하면
서
문제를 분석해가
고
간헐적 리뷰를 지속적 리뷰
로
지속적 리뷰는 조기에 디버
깅
조기에 디버깅 통해서 비용
절감

14. 이 모든 것에 있는 가장 중요한
것
사람 과 사람

15. 사람에 더 깊이 가기 전에
표면적인 구성에 방법에 대해서 우선!

16. 전문가
평균개발자
초심자
전문가
평균개발자
초심자
위와 같은 조합이 가능은 합니다.
그리고 각각 조합은 이를 통해, 얻어지는 효과가 다
릅니다.

17. 완전 복잡한 고난이도 문제를 풀어야 하는 경우?
전문가
평균개발자
초심자
전문가
평균개발자
초심자
● 상호 존중 필수이 성공을 가져온다.
● 설명하지 않아도, 다 알아요. 광속!!!
● 엄청 에너지 소진!
○ 웃으면서, 농담 하여 여유를
● 서로 배울 것이 여전히 있다.
● 비장의 무기로 사용하기를!
● 강한 Ego들 충돌은 서로 주의하자.

18. ● 전문가 시간 낭비라는 생각은 금물
● 초심자는 전문가의 행동과 생각 방식을 배
움
● 전문가도 설명을 하면서,
개선을 배움, 문제 발견 기회를 가질 수 있
다.
● 선생님이라는 마음을 가지고,
인내심을 가지고 대하는 것을 기본으로.
● 초심자가 위축되어, 질문 못 하는 분위기는
위험
교육을 하면서, 간단한 일도 처리하고 싶다면.
전문가
평균개발자
초심자
전문가
평균개발자
초심자

19. 평이한 영역에 대해서, 서로 좋은 영향 주며 제품 개발
진행을 시키고자 하는 경우에는?
전문가
평균개발자
초심자
전문가
평균개발자
초심자
● 서로 애틋하다. 서로 동지애가 있다.
● 뭔가를 익히는데 좋은 조합.
○ 사수가 교육에 들이는 시간 절약
● 각자 아는 지식을 서로에게 전달
● 만약 둘 이 모르면, 혼자서 해결하려고
하지 않고, 주위에 질문을 한다. ^^
● 둘이 엉뚱한 방향으로 갈 수 있기 때문
에, 가이드를 해 줄 담당자의 주기적 관
심 필요.

20. 평균 개발자를 전문 개발자로 양성하고자 할 때에는?
전문가
평균개발자
초심자
전문가
평균개발자
초심자
● 이 조합은 효율성은 높지 않다.
● 중급을 넘어 전문 개발자로 발 돋움을
할려고 하는 경우에, 이를 가속화 시키
는데 도움이 되는 방법이다.
● 전문가도 새로운 생각 & 기술 접하게
된다.
● 전문가는 기술 자체에 대한 설명보다는,
기술 선택 및 적용 방법에 대한 의사 결
정 과정을 전파하게 된다.
● 평균 개발자는 이 기회에 열심히 질문
해야 한다. 그리고 방어하려 하지 말고,
받아들여야 한다.

21. 전문가
평균개발자
초심자
전문가
평균개발자
초심자
이 경우는 별도 특이 사항이 있다기 보다는,
일반적인 Pair Programming이 가져다 주는 장점과
발생할 수 있는 여러 문제점이 대상이 되는 경우들입니
다.
그래서, 별도 설명은 생략!

22. 외향적인
내향적인
외향적인
내향적인
외향적인 내향적인
● 완전 좋은 조합. 커뮤니케이션이 좋다.
● 적극적인 질문과 빠른 질문/응답
● 빠르게 방향을 찾아간다.
● 시끄러워서 주위 사람이 깜짝.
● 수다가 너무 많아서 시간 낭비.
● 서로 자기가 driver를 하려고 하는.
● 자기 절제를 기본 자세로 진행 필요
● 서로 특성을 미리 인지하고, 서로 배
려.
● 외향적인 사람은 말을 줄이고,
● 내향적인 사람은 좀 더 적극적으로 하
고.
● 서로 성향을 존중이 필수!
● 내향적이다는 것이 말이 없음 의미 안
함.
● 관심분야 외에 만 말을 아낄 뿐.
● 페어링에 시간이 걸린다.
● 실제 많은 비율 발생되는 Pair.
● 서로 의사소통을 배우게 되는 기회
● 세상으로 한 발 자욱 나올 수 있는 기
회
● 서로 위협적이지는 않다.
● 자기 의견을 확고히 표현하는 것을!
● pair에 저항을 하는 경우가 많으며,
강요하지 말고, 서서히 접근하자.
● 엉뚱한 방향으로 가도 침묵경우. 관심 필
요.

23. 도움이 되는 방법들
이런 방법들을 사용하면 도움이 되요.

24. Thinking Aloud Pair Problem
Solving (TAPPS)
This problem-solving collaborative structure
was introduced by Lochhead and Whimbey
(1987)
as a means to encourage problem-solving skills
by verbalizing to a listener one's problem-
solving thoughts.
The idea behind TAPPS is that presenting
aloud the problem-solving process helps
analytical reasoning skills.
1. 주어진 문제들에 대해서 페어를 만들자.
2. 각각 문제에 대해서, 매 문제마다 역할은 바꾼다.
3. 문제 해결자와 듣는 자가 있다.
a. 문제 해결자는 문제를 크게 읽는다. 그리고 큰
소리로 문제를 해결하는 과정을 이야기 하면서
문제를 풀어가보자.
b. 듣는 자는 문제 해결자가 문제 푸는 과정에서 오
류를 발견할 수 있다. 효과적으로 이해하도록 문
제 해결 단계 안에 숨겨진 사고 프로세스를 이해
해야 한다.
c. 듣는 자는 문제 해결자 해결 방식이 이해가 되지
않으면, 이에 대해서 질문을 하자.
i. 이러한 질문이 해결을 하지는 않아도 된다.
ii. 이러한 질문이 특정 에러를 구지 지적하지
않아도 된다.
4. 문제는 점점 해결되어져 간다.
http://www.wcer.wisc.edu/archive/cl1/cl/doingcl/tapps.htm

25. 샤워와 입 냄새 제거는 기본
● 아무래도 물리적으로 가까이 일하
는 것. 위생이 은근 문제.
● Pair를 위해서, 샤워는 기본, 양치
도 열심히 하도록 합니다.
기회를 요청할 때에는 정중하게
● Navigator로서 잠시 키보드를 통해서 보여주고
싶을 때에는 정중하게 요청을 합시다. 확 뺏어가
는 행동은 금물.
● 정중한 요청을 하면, Driver는 이에 상대방을 존
중해서 건내도록 합니다.
● Timer로 건내는 시간을 합의하는 것도 좋습니다.
모르겠으면 바로 물어보기.
● 흐름을 놓치면, 바로 그 시점에 물
어보세요. 어떻게 작업 되는지.
● 언제든 내가 driver가 될 수 있어요.
내 의도를 살리는 공격적이지 않는 질문.
● 말 하는 어투나 어조는 굉장히 중요합니다.
● 공격할 의도는 아님에도, 말하는 어투로 인해서
공격을 받는다고 상대방이 느낄 수 있습니다.
● 명시적으로 공격할 의도가 아님을 밝히면서 이
야기 시작하는 것도 유치해 보이지만, 도움이 됩
니다.
● 이야기 하면서, 자신의 어투나 톤을 유념하면서
상대방 반응을 보면서 질문/설명 하도록 합니다.
적극적으로 듣습니다.
● 본인이 이해한 바를 지속적으로 요
약하고 확인하면서 듣습니다.
● 필요하면, 맞는 지 질문을 합니다.

26. 예전에 혼자서도 잘 했어요 ^^
● Pair Programming을 많이 하다 보
면, 혼자서 프로그램을 작성할 때
불안에 빠질 때가 있어요.
● 기억합시다. 우리 예전에는 혼자서
도 잘 했어요. ^^
Pair Programming은 자발적으로
● 강요 될 수 있는 것이 아니에요.
● 모든 이에게 적합한 방법은 아니에
요.
● 점차적으로 익숙해 질 시간이 필요
한 사람도 있어요.
● 요청을 하고, 참여에 대한 동의를
받아서 진행을 하면 좋아요.
● Daily Scrum에서 요청/수락하는 것
도 하나의 방법.
의견 차이가 있을 때에는
● 감정이 격앙 될 때에는, 휴정을 합시다.
○ 같이 손을 꼬옥 잡고, 같이 산책을 하면서 잡다
한 이야기를 나누면서 마음을 차분하게.
● 쉬면서 내가 주장한 바를 다시 한 번 생각하는 시간을
가지도록 합니다. 문제가 있다면, 문제 있었음을 시인.
● 새로운 대안이 있다면, 별도 시간을 가지고 이 시간
내에 이를 간단히 구체화 해서 보여주는 것도 효과적.
● 문제가 대립 된 상황을 컴퓨터를 떠나, 화이트 보드에
하나 하나 구체적으로 작성해서, 차이가 있는 점을 적
어봅니다.
● 구체적으로 적는 과정에서, 합의된 부분은 제거를 합
니다.
● 합의가 되지 않는 부분에 대해서는, 각자 판단과 그
판단의 가정과 근거를 기술합니다.
● 의견 차이가 큰 목적에 있어서 큰 문제인지를 생각.
● 최종적으로 합의가 가능한지를 판단

27. 단독 질주 보다는 페이스를 맞추는 센스
● Pair Programming은 파트너와 같
이 가는 것.
● 내 흥에 취해서, 내 페이스로 마구
달려서 파트너를 멍하게 만들면, 의
미가 없어요.
드라이버에게도 기회를
● 드라이버도 실수를 자체적으로 수정할 시간을
주세요. 생각하고 고칠려고 하는데, 그 전에 마구
개입하면 자존감이 떨어지기 쉽습니다.
● 문제에 대한 진행을 차분히 바라보고, 놓치고 넘
어가는 것이 명확할 때 이야기를 해주세요.
● 물론 이 페이스는 사람마다 다르니깐, 그에 맞춰
서.지칠 때에는 교체를 해서 진행을
● 힘이 들고, 지칠 때에는 파트너가
있어요. 교체해서 진행 할 시점!
● 모두 지쳤으면, 쉬는 시간을 가집시
다.
자기 소개 시간을 가지도록 합시다.
● 우린 서로 아는 것 같지만, 잘 몰라요.
● 알게 되면 이해가 됩니다.
● 각자 약한 점, 이해해 주었으면 하는 점에 대해
서 이야기를 먼저하고 시작해요.
● 도와 주었으면 하는 점, 피해 주었으면 하는 점
을 서로 명시적으로 이야기를 합니다.
● 굉장히 좋은 접근 방식입니다.
공통된 개발 환경과 스타일을
● 너무 나에 맞춰진 개발 환경은 pair
를 할 때 효율성을 떨어트립니다.
● 팀 내 공통 개발 환경 정의 및 준수

28. 다시 돌아와서, 의견 대립이 발생한 경우엔
● 네이게이터는 바로바로 의견을 이야기 하기 보다는, 드라이버에게 도움이 될 수 있는 내용들을
명시적으로 기록을 합니다. 그리고 주기적으로 드라이버와 함께 이 목록을 검토하도록 합니다.
○ 이 방법은 진행이 되지 않는데에서 오는 심리적 압박감을 해소.
○ 이야기를 해 나갈 명시적 대상이 있어서, 문제에 좀 더 집중을 하는데 도움이 됩니다.
● 접근 방식에 차이가 있을 때에는 각자 솔로 프로그래밍으로 자신의 방법을 구현 후 이를 상호 검
토합니다.
○ 코드 관련된 이견이면, 다른 방법으로 코드를. (목표하는 명시적 효과를 이야기 하며)
○ 화면 디자인 경우에는 종이와 펜으로 그리고자 하는 것을 프로토타이핑해서.
○ 이렇게 좀 더 정리된 정보는 각자가 주장하는 바를 구체적으로 제시하여, 서로 의견을 충분
히 이해라고 서로 받아들이는 데 많은 도움이 됩니다.
■ 많은 의견 갈등은 정보 부족 상태에서, 가정와 의도를 알기 전에 자신의 기준으로 판
단하고 생각하기 때문에 발생이 되는 경우가 많습니다.
● 실전에 많이 사용되는 방법으로, 지정된 시간 동안 의견 제시자가 자신 의견을 맘껏 펼치게 합니
다.
○ 롤백을 할 수 있도록, 브랜치나 태그와 같은 장치는 합니다.
○ 지정된 시간(타이머를 건냅니다.) 동안, 드라이버는 자신 방법을 생각들을 이야기하면서,

29. 도움이 되는 자세.
Pair Programming은 성숙한 자세가 필수.

31. ● 휴식을 취합시다.
○ 굉장히 집중적인 과정이라, 쉽게 지칩니
다.
피로 방지 대안이 필요.
이는 Pair Scheduling 파트에서 추가 설명
○ 주기적으로 휴식을 취하는 것은 필수!
○ 휴식을 취하면서, 새로운 관점을 가지고
오기도 하고, 관련 조사도 하고 이메일도
확인하도록 하자.
● 사람에 대한 사랑하는 마음을 가집시다.
○ “My Way or The Highway” 경계
○ 다른 사람도 머리를 가지고 있고, 다들 자
신이 맞다고 생각하는 이유가 있습니다.
○ 나도 실수 할 수 있다는 진실에 대한 인정
○ Learn to laugh at yourself.
○ http://www.huffingtonpost.com/2013/11/14/10-
successful-people-who-_n_4262766.html
● 자신을 믿으면서도, 타인 의견도 수용할 줄 알
아야.
○ 내 자신을 방어하려 하지 마세요.
○ 틀리면 “아 틀렸네!”하고 인정합시다.
○ 그래도 내 길이 더 효율적이라고 생각하
면, 상대방을 존중하면서 그 이유를 설명
하도록 합시다.
○ “멍청해 보여도" 괜찮아요~
○ 파트너 끼리 서로 경쟁하는 것 아니잖아
요.
○ 우리는 한 팀! 우리는 한 목표! 품질 높은
제품을 만드는 그 하나를 위해서 같이 일
하고 있어요.

32. ● 경청을 합시다.
○ Seek first to understand,
then to be understood.
○ 바로 반응하기 보다는, 상대방이 이야기
하는 것을 이해하도록 합시다.
○ 왜 상대방은 이렇게 이야기 하는 것일까?
○ 상대방이 내 생각을 모욕하거나, 비난하
려고 할 것이라 생각하지 마세요. 그런 의
도는 아니랍니다.
○ 인간은 유한한 존재라서, 아는 것도 한계
가 있다는 진실을 인정합시다.
○ 내가 틀릴 가능성도 항상 염두를 합시다.
● 팀 플레이어가 됩시다.
○ 우린 같은 목표를 가지고 일하는 팀.
○ 이건 내 코드, 이건 늬 코드.
이건 늬 버그, 이건 내 버그.
○ 이런 생각들로 선을 그어서 나를 내세우
려 하지 마세요. 우리가 같이 제품을 만들
어 가는 것이에요.
○ 최고의 제품을 만드는 것. 이 하나의 목표
를 같이 달성하기 위해서, 팀과 동료 그리
고 나를 최고가 되는데 집중을 하세요.
○ “그래 하고 싶은 데로 해라”는 태도는 결
국 내 자신을 섞게 만드는 것일 뿐.

33. 문제가 되는 경우들
아주 위험한 대표적 사례를 살펴 봅니다.

34. Professional Driver Problem!
키보드를 독점하는 자 !
● 본인이 최고의 Driver라고 하더라도, 본인 만을 바라본다면,
○ 상대방을 열 받게 하고, 자신감을 떨어트리게 한다.
○ 같이 Pair Programming 하는 재미도 없앤다.
○ 최악은 navigator 말도 듣지 않는 경우도 있다.
○ 차라리 혼자 프로그램 작성을 하는 게 낫다.
● 개선을 위해서는
○ 다른 최고의 Navigator가 파트너와 Pair 하는 모습을 보
고 느끼게 하는 방법이 효과적
○ 진정 최고의 Driver를 경험하게 하자.
■ 진정 최고 Driver는 Navigator가 성장을 할 수 있
도록 기꺼이 자신의 자리를 내어 준다.
■ 서로 성장하는 Driver와 Navigator 관계를 보여준
다.

35. “My Partner Is a SO Smart”
and Other Too Little Ego Problem
● 자신이 가지고 있는 기술에 대해 자신감이 없는 경우.
● 이들은 대부분 침묵과 무조건 인정만으로 일관.
○ 이렇게 하는 것은 파트너도 지루하고, 힘들게 한다.
○ 서로 발전을 유도하는 관계로 발전하지 못한다.
○ 팀 속도를 저해하는 요소
● 개선안
○ 이런 이들을 Driver로 우선 앉히고, 작은 일이라도
잘 마무리 하도록 유도를 해주자.
○ 성공 경험들을 쌓음으로서, 이런 이들을 세상 밖으
로 데리고 나올 수 있다.
○ 이런 이들과 같이 페어를 하는 경우에는, 농담을 건
네면서 분위기를 편하게 해주는 것도 도움이 된다.
○ Navigator로 역할 할 때에는 간단한 질문들을 수시
로 물어보고 성공적인 대답을 하게 하고, 칭찬하자.
○ 세상에 천재는 없다. 단지 조금 더 알 뿐이다.
“Easy to assume that you are dumb and everyone else
is smart. But in pair programming everyone has
something to contribute, and nobody knows it all.”

36. “My Partner Is a Total Loser”
and Other Excess Ego Problem
● 이 문제는 Pair Programming 현장을 둘러보
면, 쉽게 찾아낼 수 있는 문제.
● 가장 심각한 문제이며, 시급히 해결될 문제
상황.
● Excess Ego에 대해서는 No Tolerance.
● 폰 노이만도 Pair 및 Review를 신청했었다.
● 개선안
○ 뛰어난 능력을 보이는 자와 Pair
■ 그는 인정, 나머지는 인정 X
■ 결국, 해결안이 되지 않음
○ 잘 알려진 뛰어난 Partner가 서로 성장
하는 모습을 바라보게 한다.
○ 지속적 문제가 발생되는 경우에는,
단독 작업을 하도록 조처. 이도 임시 방
안.
○ 결국은 개인이 Excess Ego가 문제임
을 인정하고 변화하는 것 만이 유일한

37. Pair Rotation
Pair 구성을 바꿔가는 방법에도 효과적인 방
법이.

39. Pair Rotation = 지식의 전파 및 확대 재
생산
● 편한 사람하고 지속적으로 Pair를 하는 것도 안 하는 것보다는
좋다.
● 고정된 Pair에서 경계 되는 점. (반대로 생각하면 기대되는 효
과 ^^)
○ 관점 및 지식 단편성에서 오는 성장 한계성.
○ Pair Pressure 상실에서 오는 Pair 작업 효율성 저하.
○ 팀 내 고립된 섬 구축에서 오는 팀 Communication 저하
● See new places and embrace new experiences.
○ Pair Rotation을 시작할 시간!

41. Pair Rotation에도 의도에 따른 방법 있
다.
의도 1. 신규 영입된 인원 팀 적응도 향상
의도 2. 관련 분야에 대한 작업 이해도 및 품질 증가
의도 3. 새로운 분야에 대한 기술 습득
무의식적 Rotation 보다, 의도적 Rotation

42. 의도 1. 신규 영입된 인원 팀 적응도 향상
DB에서 DTO 생성
DTO 활용 BO 관리 및 BO 구
현
API 구성 Front End 개발
1. 신입 사원 기술 교육 비용 절약
2. 신규 사원에게는 팀 익숙해지기
3. 전문 분야 선정에 도움

43. 의도 2. 관련 분야에 대한 작업 이해도 및 품질 보완
증가
DB에서 DTO 생성
DTO 활용 BO 관리 및 BO 구
현
API 구성 Front End 개발
1. 유관 부분에 대한 기술 습득에 용
이
2. 자연스러운 기술 흐름 및 전파
Logical Partners.

44. 의도 3. 새로운 분야에 대한 기술 습득
DB에서 DTO 생성
DTO 활용 BO 관리 및 BO 구
현
API 구성 Front End 개발
1. 전혀 새로운 영역에 대한 기술 습
득
2. 기술 진입 장벽을 낮추는 효과

45. Cross Functional Team으로 가는 길.
Full Stack Developer로 가는 길.
자신을 선 긋지 않고, 지속 성장/배움의 길.

46. 방법 1. Daily Scrum
1. Daily Scrum에서 진행 상황 공유
단계 및 예정 작업을 이야기 하면
서, Partner 모집
2. 수집이 안 되는 경우에, 목적에 따
라서 적합한 인원을
Team Leader나 Manager가
Pair Partner 결정해 주기.
Rotation을 원활히 하는데 도움 되는 방
법
방법 2. Say Yes!
● 아주 간단한 방법.
● Task owner가 필요한 팀원에게
Pair 요청을 하면, 지정 당한 팀원
은 무조건 “Say Yes!”
● 일정 조율 문제가 있는데, 원칙 하
나를 취할 때, 선 지정자에게 우선
진행.
● 중복된 지정을 받는 사람은 그만
큼 매력!
예제로 사용하는 방법일 뿐, 이를 바탕으로 개선을 적절히 하는 것을 권장.

47. 기타 Pair Rotation 제안 방법
● Pair History를 만들어서, 너무 고착화된 Pair가 유지되는 사례를 발견, 조
정 권장
● 동일 Pair 가 연속해서, 다른 작업 투여에 대한 금지 권장.
○ 이미 Pair 자체 문화가 성숙해 있고, 팀 내 Communication Block이 녹
은 상태에서 수행을 권장
○ 예) 짐과 톰이 Pair로 OLY-84 작업을 수행했는데, 다음 OLY-85 작업
도 짐과 톰이 Pair로 수행을 하는 것은 금지, 다른 Pair로 진행을 권장
● Sprint 별로 무조건 Pair를 유지하고, 해당 Pair가 작업들을 바꿔가면서 진
행을 하는 방법
● Pair 지정권을 팀 내에 일정 수를 배포, 해당 이들이 지정을 하면 지정권을
지정 받은 이에게 넘겨주는 방법을 통한 Say Yes 확장 버전.
● 여러 방법이 있을 수 있다. 원하는 목표를 달성하는 것에 집중하기.

48. Pair Rotation History 정리 예.
질문 1. 내가 Pair를 통해서 얻고자 하는 것은?
질문 2. 현재 얻고자 하는 것을 다른 파트너를 통해서 더 얻을 수 있을까?
질문 3. 얻을 수는 있는데, 나를 막는 것은?

49. Pair Scheduling
+ 실전에 발생되는 이슈들

50. 하루 종일 하기에는 너무 힘들어요.
● Pair Programming은 제대로 하면,
집중도가 높은 활동.
○ 하루 종일 Pair Programming 하는 것은 진
정 힘들기 때문에, 오히려 하루 종일 수행이
불가능하기 때문에 처음 도입 시에 하루 종
일 한다는 부담감을 버리고 도입하라고 권
장할 정도.
○ 의도적인 휴식이 필요합니다.
■ 지정 시간 후 강제 휴식을!
■ 상대방이 힘들어 보이면, 바로 휴식!
■ 그리고 역할 변경을 제안.
● 그럼에도 넘 힘들면, 다른 방법이 필요합니다.

51. Full Time Pair 안 해도 되요.
모든 작업을 Pair로 라는 압박에서도
벗어나요.

52. Pair를 하면서 피로도를 조금 줄이면서, 효과적인 접근을.
Pair Programming 통한
문제 핵심 부분에 대한
집중 작업 수행
동일 문제
다른 부분
개별 작업
동일 문제
다른 부분
개별 작업
개별 작업한 부분에 대해
서, 공동 리뷰를 통한 통
합.
합의된 약속 시간
• Pair Programming을 하는 목적이, 서로 작업에 대한 지속적인 리뷰에 더 중심을 둔다
면
효과적 대안이 될 수 있습니다.
• 개별 작업에 대해서, 별도 공동 리뷰를 하는 시간이 필요한 만큼, 명확한 목적 기반 리

53. Pair를 하면서 피로도를 조금 줄이면서, 효과적인 접근을.
Pair Programming 통한
문제 핵심 부분에 대한
집중 작업 수행
개별 작업 수행
개별 작업 수행
앞 시간에 이어서,
Pair
Programming
연계 수행
합의된 약속 시간
• 합의된 약속 시간이 다음 날이 될 수도 있습니다.
• Pair Programming을 피로도 감당이 되지 않는 경우에, 개별 작업으로 전환.
• 하루 작업 계획을 할 때, 별도 개별 진행 가능한 작업을 미리 확보하는 것도 방법.
• 피로도가 Pair Partner에서 오는 경우가 있는데, 이는 협의하에 서로 개선.

54. Partner와 시간이 잘 맞춰지지 않아서 지체가 되는 느낌.
Pair Programming 통한
문제 핵심 부분에 대한
집중 작업 수행
?
개인 일
정
앞 시간
에 이어
서,
Pair 진
행
• 파트너와 협의 되지 않은 개인 시간/활동은 작업 진행을 지체.
• Pair를 하는 동안은 파트너와 세부 일정을 공유하고, 작업 Context 전환은 최소화를 하도
록 한다.
• 이를 위해서, 매일 작업을 시작할 때, 파트너 간에 Pair 일정을 합의하고, 이를 준수.
?
사라짐
앞 시간
에 이어
서,
Pair 진
행
대기
대기

55. Partner가 없이 장시간 방치 되어야 하는 경우에는?
Pair Programming 통한 문제 핵심
부분에 대한 집중 작업 수행
?
파트너가 장시간 자리를 비울 때에는
● 시간을 허비하지 마라. 내가 허비하는 시간은 바로 팀의 시간이다.
● 미리 일정을 알았다면, 하루 시작할 때 다른 작업들에 대한 계획으로 대체 가능 (Daily
Scrum 활용)
● 갑작스러운 상황 발생이라면,
○ 진행하던 작업에 대해서, 다른 Pair 참가 가능한 자를 모집
○ 다른 작업에 대해서, Pair Navigator로 참가
개인 일정

56. 집중화 된 Pair 요청에 대한 대응. (나도 내 일을 하고 싶다고
~)
● 자신의 시간 중에서, Pair 참여 가능한 시간을 나누어서 공식적으로 공유
○ 개인적인 성장을 위해서, 본인 진행하고자 하는 작업에 대한 Pair도 필요.
● Pair가 진행하기 위한 이들은 공개된 Pair 가능 시간에 신청을 해서, 일정 조
율
● Pair가 요청되는 매력적인 부분에 대해서,
○ Pair 파트너들 성장에 기여하는 것이 팀 효율성 및 본인 부담을 더는 길.
○ 특정 후보자를 선정, 해당 후보자와 집중 Pair를 통해서,

57. ● Pair를 수행하는 목적성을 명시적으로 시작 전에 알려주는 것이 필요.
○ 스트레스를 받지 않아도 된다는 것을 명시적으로 확인해 주어,
파트너 부담을 덜어주는 배려
○ 이번 기회를 통해 압박감을 느끼면서 성장하기 위해서, 노력을 해서 빠르게 성장
하는 것이 팀 발전을 위한 길임을 명시적으로 이야기 해주기.
● 초심자 성장을 목표하는 측면에서,
○ 파트너는 초심자가 편하게 자기 이야기를 이야기 할 수 있도록, 편한 분위기를.
■ “우와! 이걸 몰라?”, “혹시 이건 아나?”: 공격적인 반응 보다는.
■ “이 부분에 대해서, 이 책으로 공부를 해야 겠다. 이 부분은 이렇게 공부를 하
면 좋겠다. 잠시 이 부분 공부 하고 다시 Pair 하자.” 같은 교육적 접근.
○ 초심자가 하나 하나 해나가고, 이를 통해 조금씩 자아를 생성해 가는데 도움을 주
자.
초심자 경우, Pair로 인해서, 전체 생산성을 떨어트리는 것 같이
느껴짐.

58.  Pair를 안 해보기도
 이러한 경우에는 코드 품질 떨어짐
실감.
 혼자 하니깐 잘 되던 것이 안 된다.
 따로 따로 하다 합치는 것
 피로도는 해소 되었으나, 씽크에
비용이. 또한 코드 품질도 떨어진다.
 예약해서 시간 정의 후 하니깐
 정신없이 일이 진척되던 것을
정리하고 내 것으로 만드는 시간으로
활용
 특히 학습자 입장인 경우 좋음
 피로도는
 개인간 스타일 차이에서 오는 것 같은
 키보드에서 부터 프로그래밍 스타일
 배움의 기회가 되는 것은 확실
 타이머를 활용한 페어

59. 그럼, 우리는 어떻게 해볼까?
실천 방안을 간단히 도출해 봅시다.

61. 명시적 시간 구분 통한
역할 변경.
+ 명시적 휴식 가능.

62. 가끔은
컴퓨터에서 떨어져서,
생각을 하나 하나 적으면서

63. ● 내가 Pair를 하는 목적 규정
● Pair 파트너가 이해해 주거나, 지켜주었으면 하는 사항 정리.
● Daily Scrum에서 합의된 방법과 나의 목적성 따라서,
Pair Partner를 찾거나 요청
● 지정된 Partner 일정을 고려, 하루 Pair 작업 일정 선정
경우에 따라서, 오전/오후 각기 다른 파트너와 각기 다른 Pair를 수행할 수도.
● 서로 전달할 메시지 전달과 함께 Pair 시작
o 큰 소리로 내가 문제 푸는 과정을 공유 및 검증
o 서로가 개선할 수 있는 부분에 대한 의견 제시 및 받아들이기
o 대립이 발생한 경우.
 대립 되는 부분, 상호 가정과 의도를 가시화 통한 이해
 합의 가능한 부분과 의사 결정이 필요한 부분 구분.
o 필요에 따라서, 간섭 없이 자신이 생각한 것을 직접 보여줄 수 있는 시간을 가지기도.
o 빈번하게 (주기적으로) 서로 역할을 바꾸면서 서로 관점 전환 및 성장
 30분 이내에 역할을 교체해가는 것을 권장
 Test 코드와 Test 통과 구현을 번갈아가면서 수행하는 것도 권장 (Ping-Pong
Method)

64. Pair Programming은 쉽지 않습니다.
믿음을 가지고,
나를 보이는
시간.
그리고
믿음을 가지고,
다른 이를 받아들이는 시간.
그 끝에 우리 모두의 발전이 있습니다.
우선 여기까지.. ^^