안수찬의 개발이야기

짝 프로그래밍(Pair Programming)에 관한 효과적인 지침서

Introduction

안수찬 @dobestan

안수찬 @dobestan

소프트웨어 생태계에 기여할 수 있는 실용주의 프로그래머가 되고자 합니다. 나는 안수찬이다. 그러므로 나는 할 수 있다.


번역

짝 프로그래밍(Pair Programming)에 관한 효과적인 지침서

Posted by 안수찬 @dobestan on .
Featured

번역

짝 프로그래밍(Pair Programming)에 관한 효과적인 지침서

Posted by 안수찬 @dobestan on .

본 포스트는 #매일번역 시리즈 의 두번째 글입니다. #매일번역 이라는 이름으로 일주일간 번역을 하게 된 이유는 "2015년의 정리 - #매일번역을 일주일간 시작합니다." 에서 살펴보실 수 있습니다.

원글은 "Effective Navigation in Pair Programming" 에서 살펴보실 수 있습니다.

소프트웨어 마에스트로 과정이 끝나고 나서 가장 후회되는 점 중에 하나는, 개발을 빠르고 올바른 방향으로 배울 수 있는 수 없이 많은 기회가 있었는데 그 중 몇 가지 기회들을 놓쳤다는 것이다. 지금 생각해보면 그렇게 오랜 기간 동안 멘토님 밑에서, 그리고 열의있는 친구들과 개발을 같이 하는게 쉽지 않은 기회 였는데 많이 아쉽다는 생각이 든다. 그런 기회 중 하나의 꼭지로 살펴볼 만한 주제는 우리가 편하게 "짝코딩"이라고도 부르는 "짝 프로그래밍 ( Pair Programming )"에 관한 내용이다.

2014년 07월, 1단계 과정을 시작하면서 배권한 멘토님께서 몇 번 씩이나 "짝 프로그래밍"을 강조하고 해볼 수 있는 기회를 많이 마련해주셨는데 ( 물론 "테스트" 나 "자동화"에 대해서도 엄청나게 강조하셨다. 사실 "테스트"는 지금 돌이켜보면 그 당시 만족스럽게 하지는 못했는데, "자동화"는 꽤 잘 했던 것 같기는 하다. 지금 생각해보면 뭔가 하라는게 많았다. 이거 다 하면서 언제 프로젝트를 완성하나. 감사합니다 멘토님. ) 제대로 하지 않았다. 그 이유는 내적인 원인과 외적인 원인 모두 있었겠지만, 지금 이 시점에서 나는 그 원인을 "올바르게 짝 프로그래밍 하는 방법"에 대해서 몰랐던 나에게 둔다.

이러한 이유로 내가 좋아하는(?) 블로그인 ThoughtWorks Insights 에서 "Effective Navigation in Pair Programming" 라는 글을 번역하였다.

짝 프로그래밍(Pair Programming)에 관한 효과적인 지침서

다른 개발자와 하나의 워크스테이션을 사용하여 프로그래밍을 하는 것이 십 수 년 전부터 익스트림 프로그래밍(Extreme Programming) 열혈 팬들에 의해 유명해져서 ThoughWorks에 대규모로 적용되었습니다. 오늘날 짝 프로그래밍(Pair Programming)은 기사에서 서술하고 있듯이 사람들을 행복하게 만들고, 생산적이게 만들고, 학습시키는 효과적인 수단처럼 보입니다.

짝 프로그래밍은 광범위하게 적용 되었지만, 그 방식과 기술에 있어서 약간의 차이가 있습니다. 이 글은 현재 ThoughWorks에서 사용되는 가장 일반적인 방식의 짝 프로그래밍인 하나의 모니터를 사용하거나 복사된 두 개의 화면을 사용하는 방법으로 두 명의 프로그래머가 물리적으로 워크스테이션을 공유하는 방식에 집중할 것입니다.

이러한 방식을 사용하면 소프트웨어가 두 사람이 동시에 타이핑 하거나 클릭 하는 것을 알아내기 힘들기 때문에, 몇몇의 멀티-플레이어 게임을 제외하고는 입력 장치를 활발하게 공유하는 것에 문제가 발생합니다. 혼란을 피하고 불필요한 백스페이스 키 사용을 막기 위하여 짝 프로그래밍을 진행하는 사람들은 자연스럽게 어떤 순간에 누가 키보드를 사용하고 누가 마우스를 사용할지 정하게 됩니다. 사용 순서는 여러 요소들의 수에 의해 광범위한 방법으로 결정됩니다.

프로그래머가 타이핑을 하지 않을 때 무엇을 할 것인지에 대한 대답이 우리에게는 매우 중요한 일입니다. 운전자(Driver)와 상반되는 뜻의 내비게이터(Navigator)라는 용어는 이러한 역할을 설명하는데 적합합니다. 자동차 경주에서 내비게이터가 파일럿이나 운전자 옆에 앉아 주행 중에 좌표를 조정하고 골치 아픈 지점에서 주의를 주는 것과 같이 프로그래밍에서 내비게이터도 비슷한 역할을 합니다.

조금 더 자동차 경주와 비슷한 경우들이 있는데 주행 중 종종 운전자에게 신용과 주의력의 불균형이 발생하고, 훌륭한 내비게이터의 기술이 다소 무시되어왔다는 것입니다.

좋은 내비게이터는 무엇을 고려해야 하는가?

깨끗하고 안전한 환경

제일 중요한 것은 물리적으로든 가상적으로든 업무 환경을 다른 사람과 공유할 때 기본적인 에티켓이 반드시 있어야 한다는 것입니다. 또한 프로그래밍을 시작하기 전 업무 환경을 깔끔하게 하고 각자에게 안락함을 보장할 수 있어야 합니다.

업무를 공유하는 사람들은 불필요한 잡음이나 냄새 등으로 인해 방해 받으면 안 되고 서로의 개인 공간을 존중해야 합니다. 더군다나 피로로 인해 짝 프로그래밍이 요구하는 활발한 소통이 잘 일어나 개발 속도가 빨라질 수 있으므로 적절한 수의 휴식을 취하는 것을 고려해야 합니다.

일관성 있는 환경

물리적으로 깨끗한 공간 외에 가상 업무환경 역시 불필요한 환경 관련 방해물이 없도록 해야 합니다. 업무와 관련 없는 모든 것을 적어도 보이지 않게 치워야 합니다. 또한 워크스테이션은 다른 개발 환경과 함께 일관성 있게 환경 설정 되어야 하고, 개발자들이 기대하고 있는 상태를 유지해야 합니다.

편집 설정과 Dotfile은 팀원끼리 쉽게 공유하고 제어할 수 있어야 합니다. 그러나 다른 요소들 예를 들면 글자 크기, 화면 해상도, 동작하는 다른 어플리케이션들, 팝업 안내 설정들도 주의할 가치가 있지만 이러한 것들은 점진적으로 발생하여 종래에는 방해물이 될 것입니다. 내비게이터는 과도하게 열정적인 운전자에게 이러한 과도함을 수정하도록 상기시켜줘야 하고, 일관성과 개인의 취향 간의 이점과 트레이드오프를 다시 알려 주어야 합니다.

방향 설정

프로그래밍을 시작하기 전에 내비게이터가 동료들에게 목표를 알려주고, 확실하게 그들이 향할 방향을 말해주는 것은 매우 중요합니다. 생산물 혹은 프로젝트의 기술 담당자의 이야기와 업무를 포함하여 자세하게 논의하고 이러한 것들을 서술을 해야 합니다. 또한 커다란 일들을 작게 나누어 서술해야 합니다. 대부분 짝 프로그래밍을 함께 진행하는 사람들은 처음에 이러한 일을 함께 진행할 것이고, 내비게이터는 업무가 진행됨에 따라 최신의 목적 스택(Goal Stack)을 유지시켜야 합니다.

프로그래밍을 진행하면서 업무가 완료되어야 하는 순서를 생각 할 때, 백워드(어떤 상태를 시스템에서 남길 것인가?)와 포워드(다음에 무엇을 할 것인가?)를 넘나들며 생각해야 할 때 스택을 가지고 일을 하면 유리합니다. 또한 스택은 존재만으로 앞뒤 과정을 자연스레 보여준다는 장점이 있습니다.

코드에 필요한 변경사항을 검토하면 일반적으로 스택에 필요한 더 많은 항목과 세부사항을 추가할 수 있습니다. 순서를 배치하고 우선순위를 정하는 것은 일을 효과적으로 할 때, 특히 스택의 균형을 맞출 때 필요합니다. 즉, 너무 많은 추가 업무를 하지 않고 리팩토링을 고려할 수 있도록 보장합니다.

몇몇 팀은 수행 전 점검 항목(Pre-flight Check List)을 목표 스택(Goal Stack)의 최상위에 놓고 있습니다. 일을 시작하기 전에 미리 정의된 업무를 칸반 시스템에서 카드를 옮기는 것처럼 수행해야 합니다. 토글이나 브랜치를 만들거나, 배포 환경 데이터베이스의 복사본을 업데이트 한다던가 하는 것이 순환 예시가 될 수 있습니다. 비슷하게 수행 후 점검 항목(Post-flight Check List)도 생산물을 가지고 기술 담당자와 탁상 검사(Desk Check)를 수행하거나, 사용자에게 기능을 시연하는 등의 방식으로 개발자들이 카드를 다시 옮기는데 필요할 수 있습니다.

방향 수정

목표 스택을 향해 나아갈 때 운전자와 내비게이터는 시스템의 알지 못하는 부분이나 정상적 기능이 허용되는 기준에서 코너 케이스(Corner Case)에 해당 하는 부분에 빠질 수 있습니다. 이럴 때 내비게이터는 그들의 역할을 고려하고 계획한 업무로 나아가거나 그에 따라 계획을 수정할 수 있어야 합니다.

알 수 없는 상태에서 빠져나가 업무를 완료하는 것이 가능하단 사실을 알더라도 좋은 내비게이터는 언제 “지금은 안 된다”라고 말해야 하는지 알고 있습니다. 이러한 영향으로 다소 웃긴 DTSTTCPW, KISS, YAGNI등의 두문자어(Acronym)들이 생겨났습니다.

내비게이터(Navigator)는 이러한 두문자어(Acronym)를 명령어처럼 사용할 수 있습니다. “300미터 동안 왼쪽을 유지하십시오.” 라던가 믿을만하게 충분히 생각한 후에 “당신은 그것이 필요하지 않을 거야.” 라고 자동차 경주의 내비게이터가 말하는 것처럼 말입니다. 예를 들어 서드파티 라이브러리를 도입하는 것에 대해 토론할 때 불필요한 많은 스트레스를 방지할 수 있을 것입니다. 좋은 내비게이터는 운전 기술을 다루는 것에서 자유롭고, 이러한 순간들을 짚어줄 수 있어야 하고, 먼 곳에 있어 보이지 않는 위험을 볼 수 있어야 합니다. 이 경우 물론 운전자의 의견이 고려되지 않는다는 것이 아니라, 반드시 고려되어야 합니다. 이러한 결정을 조정하는 것은 운전자와 내비게이터 모두의 역할입니다. 하지만 궁극적으로 이러한 일을 효과적이고 체계적으로 하는 것은 내비게이터의 책임입니다.

일반적으로 내비게이터가 사용할 수 있는 다른 "명령어"는 "테스트 해보고 시작하자." 입니다. 처음에는 평범해 보일 수 있지만 우리는 내비게이터가 테스트 주도 개발을 책임지고 감독할 때 Red-Green-Refactor 사이클이 조금 더 유동성 있게 변한다는 것을 발견했습니다.

역주 : 다시 한번 반복하자. 네비게이터가 테스트 주도 개발을 책임지고 감독하자! 외쳐티디디!

명확하게 의도를 전달하는 것

초보 내비게이터들 심지어 숙련된 프로그래머들도 너무나 쉽게 특별히 무슨 일이 일어나고 있는지를 고려한 판단 없이 운전자를 주문 접수 직원(Order Taker)나 IDE 오퍼레이터(IDE operator)로 취급할 수 있습니다. 이러한 방식은 디자인과 구현을 융합하여 결정을 내리지 않으므로 짝 프로그래밍의 가치를 하락시킵니다.

여전히 운전자는 익숙하지 않은 툴을 사용하는 보다 덜 추상적인 문제들을 해결할 때 어떻게 진행해야 할지 막히곤 합니다. 언어 혹은 API에서 이러한 문제가 보다 자주 발생합니다. 좋게 말해 경험이 부족한 내비게이터는 꽤나 자주 일이 일어나자마자 조언을 합니다. 좋은 내비게이터는 어딘가 누락된 세미콜론을 지적하기 전에 좀 기다릴 줄 알고 자연스럽게 멈출 수 있을 때 그것을 지적합니다. 비록 방해하는 시간이 짧더라도, 운전자와 친숙하지 않은 방해를 많이 하는 것은 행동을 바꿔야 할 순간이라는 것을 의미합니다.

숙련된 내비게이터는 명확하게 의도를 전달할 줄 압니다. 그들은 좀 더 흥미롭고 추상적인 사항들에 대해 어떻게 가 아니라 무엇을 해야 할지 전달합니다. 또한 "나"나 "너"가 아닌 "우리"라는 조금 더 유대감이 느껴지는 단어를 사용해 표현할 줄 압니다. 그래서 운전자는 그들이 반드시 동의하지 않은 사항들에 대해 다시 생각해 볼 수 있습니다.

비록 의도를 명확히 전달했을지라도, 질문하여 확인하는 작업은 이해의 가치를 높이고 운전자로부터의 피드백을 수용한다는 점에서 좋은 시도가 될 수 있습니다.

과정을 시각화 하는 것

이러한 점에서 내비게이터(Navigator)가 자유롭게 사용할 수 있는 다른 도구는 오래된 펜입니다. 설계하고 그리는 것들은 경로의 모양에 무언가 표시하여 보여주는 가장 좋은 방법입니다.

의사코드 ( Pseudocode )

몇몇 알고리즘과 데이터구조는 UML로 표현하면 조금 불명확할 수 있습니다. 의사코드는 캐싱 전략 구현 등의 코드 일부분을 논할 때 자주 이용되는 방법입니다. 비록 간단하지만 목표 스택을 설계하는 프로그래밍 초기 단계에서 매우 효과적입니다. 이때 의사코드의 각 줄은 스택의 구성 요소가 될 수 있습니다.

개념도 ( Boxes and Arrows )

대부분의 시스템은 특정 아키텍처 패턴에 따라 구현될 수 있습니다. 통상적인 데이터베이스 기반 웹 어플리케이션을 예로 들면, 대부분의 특징들이 다음 그림에 세부사항들을 추가해서 표현할 수 있습니다. 새로운 상자와 화살표를 추가하여 이러한 개념도를 종이조각에 적는 것은 짝 프로그래밍을 진행하는 동료와 현재 시스템의 상태나, 어떤 부분을 바꿔야 하는지, 추가할 부분은 무엇인지 함께 생각하기 시작할 때 효과적입니다.

UML과 UI 스케치하기

약간 구식 같지만 UML은 시스템을 시각적으로 기술하는데 매우 효과적입니다. 우리는 클래스의 계층구조나 시스템 사이의 관계를 설명할 때 UML을 사용하는 것을 선호합니다. 일부 특정 UML을 사용하여 포워드 엔지니어링(Forward Engineering)과 리버스 엔지니어링(Reverse Engineering) 모두 잘 설계할 수 있습니다. 예를 들어 보다 큰 리팩토링 과정에서 화이트보드에서 선택적으로 몇몇 부분을 제거하는 것이 세부적인 진행 방법이 될 수 있습니다.

ThoughWorks 에서

우리는 짝 프로그래밍이 개발자의 생산성을 증가시키고 지식과 경험을 나누는 가장 효과적인 방법 중 하나라는 것을 알았습니다. 짝 프로그래밍은 우리가 강력한 팀을 꾸리고, 실수할 확률을 줄이고, 행복할 수 있게끔 도와줍니다. 짝 프로그래밍에서 각자 특정한 자신의 역할을 해야 하고 책임이 따르지만 똑같이 중요하다는 것을 기억해야 합니다. 게다가 운전자나 내비게이터의 역할은 영원히 유지됩니다. 짝 프로그래밍을 진행할 때 운전자와 내비게이터는 역할을 여러 번 바꾸어야 하고 두 바퀴 모두 좋은 모양이 될 수 있도록 해야 합니다.

안수찬 @dobestan

안수찬 @dobestan

https://dobest.io/

소프트웨어 생태계에 기여할 수 있는 실용주의 프로그래머가 되고자 합니다. 나는 안수찬이다. 그러므로 나는 할 수 있다.

View Comments...