<div id="readability-page-1" class="page"><div><p data-ke-size="size18"><i>글은 의식의 흐름대로 작성하였다.</i></p>
<h3 data-ke-size="size23">들어가기 전..</h3>
<p data-ke-size="size16">우아한유스방 세 번째 과제로 페어프로그래밍을 진행했다. 페어 프로그래밍을 진지하게 해본건 처음이라 느낀점과 회고를 글로 남겨보고자 한다. 우아한유스방은<span>&nbsp;</span>클린 코드와 페어 프로그래밍, 이력서 작성, 모의 면접과 상호 피드백 등을 경험하는 스터디이다. 미션을 수행한 후 참여자간의 상호 피드백을 수행하는 방식으로 과정이 진행된다.</p>
<p data-ke-size="size16">세 번째 과제는 페어프로그래밍을 통한 Wordle 게임 개발이었다. 개인적으로 과제를 진행하기 전에, 이 과제를 통해서 무엇을 느끼기를 바랄지 추측해보고, 나는 어떤 경험을 하고 싶은지 고민하는 시간을 갖는다.</p>
<p data-ke-size="size16">이번 과제의 목적은 라이브로 상호 피드백을 해보는 경험을 해보는 것이 목적이었던 것 같다. 페어 프로그래밍이 말로는 많이 들어도 직접 해볼 기회는 많지 않다. 항상 시작이 어렵기에, 여기서 시행착오를 겪으며 장단점을 직접 느끼고 최종적으로 나중에 회사에서 적용해볼 수 있는 발판이 되는 기회가 아니었을까 싶다.&nbsp;평소 내 스타일대로 개발할거였으면 굳이 페어로 개발을 진행하지 않았을 거라는 생각이었기에<span>&nbsp;</span>최대한 많은 의견 교환을 경험 포인트로 삼았다. 다른 사람들은 어떻게 생각하고 어떻게 일하는지 궁금했다. 이게 실천하기에는 좀 어려운 부분이 있었는데 느낀 점은 뒤에 작성하겠다.</p>
<p data-ke-size="size16">참고로 Wordle 게임은 단어 맞추기 게임이다. 자세하게는<span>&nbsp;</span><a href="https://github.com/woowahan-pjs/java-wordle">README</a>를 참고하면 좋을 것 같다.</p>
<p data-ke-size="size16"><span>페어 프로그래밍</span></p>
<p data-ke-size="size16">페어 프로그래밍은 짝 프로그래밍이라고도 부르고, <a href="https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C">애자일 소프트웨어 개발</a> 중 하나로 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법이다. 다른 방법이 또 어떻게 있는지는 모르겠지만 <a href="https://news.hada.io/topic?id=6142">이 글</a>을 참고하여 드라이버 / 네비게이터로 역할을 나눠서 진행했다.</p>
<p data-ke-size="size16">특이사항으로 우리 조는 3명으로 구성됐다. 이건 아마 <a href="https://www.moreagile.net/2014/12/mob-programming.html">몹 프로그래밍(Mob programming)</a> 이라고 부르는 듯 하다. 수많은 장점들이 있는데, 링크를 참고하면 좋을 것 같다. 우리는 드라이버 1명과 네비게이터 2명으로 역할을 정해 미션을 수행했다.</p>
<h3 data-ke-size="size23">느낀점</h3>
<p data-ke-size="size16">각 역할을 돌아가며 수행했고 내가 경험하고 느낀 점들은 다음과 같다.</p>
<h4 data-ke-size="size20">네비게이터</h4>
<p data-ke-size="size16">나에게는 네비게이터의 난이도가 더 높았다. 어떤 범위와 내용을 가이드 해야할지, 나와 생각이 다를땐 어떤 타이밍에 의견을 제시해야할지 기준을 만드는게 어려웠다. 네비게이터는 드라이버보다 손이 놀기에 인지영역이 좀 더 넓고, 이는 좀 더 뒤에서 멀리까지 볼 수 있게 해준다. 그리고.. 역시 직접 하는 것보다 훈수가 쉽다. 우리는 네비게이터가 두명이었기에 미리 맞추지 못한 부분에서 문제가 종종 있었다. 사공이 많으면 배가 산으로 간다.</p>
<p data-ke-size="size16">하지만 말로 하는 개발 훈수는 생각보다 많이 어렵다. 슬랙같은 메신저를 사용할때는 충분히 검색할 시간이 있고, 텍스트를 통해서 생각을 전달하기에 약간의 시간 텀이 있다. 하지만 드라이버로부터 질문을 받았거나, 내가 가고자 하는 방향을 설명해야 하는데 즉석에서 말로 진행하면 준비되지 않은 것들이 돋보인다. 현 상황에 대한 이해, 관찰과 해결 방안에 대해 빠르게 정리하고 전달해야 하기에 메신저를 통한 소통보다 난이도가 배 이상으로 높다고 느꼈다. 훈수도 아는게 많고 정리되어 있어야 두기 쉽다.</p>
<p data-ke-size="size16">알고 있어도 말로 설명하려다 보면 어버버 하다가 결국 적당히 타협하는 경우도 생겼다. 최대한 설명했다고 하더라도 드라이버가 이해할 수 있다고 장담할 수 없다. 이걸 약간이나마 해소할 수 있는 방법은 말보다는 코드로 보여주는 것이다. 생각해보면 무언가를 학습할 때 설명 문서보다 예시 코드를 먼저 찾지만 말로 진행하다보면 말만 하게된다. 네비게이터도 코드에 손을 대야한다. (thanks to 하현님)</p>
<p data-ke-size="size16">가장 중요하다고 생각하는 것으로 암묵지를 꺼내는 훈련이 필요하다. 그래야 내가 이럴때 어떻게 해왔고 뭘 하고싶고 드라이버는 뭘 하고있어요 라고 설명하기가 좀 수월해지는 것 같다.</p>
<p data-ke-size="size16">중간에 늦게 와서 서브 네비게이터(sub navigator)같은 역할도 한번 했었다. 메인 네비게이터와 드라이버의 의견을 조율하거나 큰 흐름을 보는 역할을 수행(했다고 생각)했고, 메인과 서브를 구분하여 진행해보는 것도 나쁘지 않은 것 같다고 느꼈다.</p>
<h4 data-ke-size="size20">드라이버</h4>
<p data-ke-size="size16">3명이서 진행했기에 네비게이터 비율이 더 높았다. 드라이버 맛을 좀 더 봤으면 느낌이 달랐을지 모르겠다.</p>
<p data-ke-size="size16">일단 드라이버는 체력 소모가 엄청나다. 코드의 흐름에 집중한 채로 말을 굉장히 많이 해야한다. 30분 떠들고 나면 입이 바싹바싹 마른다. 역할을 수행하는데에 있어 가장 힘든 점은 머리가 하얘진다. 조금 과장하면 면접관 앞에서 라이브로 코드를 작성하며 피드백을 받는 것이다. 그리고 우린 두명한테 라이브 피드백을 받았다. 타인에게 코드를 작성하는 모습을 보여주는 것이 익숙하지 않다면 엄청 부담스럽다.</p>
<p data-ke-size="size16">네비게이터가 흐름을 쉽게 이해하기 위해서는 드라이버가 작업 전에 무엇을, 어떻게, 얼마나, 왜 가급적 자세하게 설명하면서 코드를 작성해야 한다. 자동차 운전에도 숙련도가 필요한 것 처럼, 페어 프로그래밍 운전도 드라이버의 경험과 고민과 노력만큼 부드러운 드라이빙이 된다.</p>
<h3 data-ke-size="size23">아쉬운 점</h3>
<p data-ke-size="size16">이번에 진행한 페어프로그래밍은 짧은 기간에 과제를 수행해야 했기에 급하게 시작했던게 오히려 발목을 잡는 포인트였던 것 같다. 급할수록 돌아가라고, 시작하기 전에 최대한 서로의 개발 스타일, 생각, 목표와 결과물같은 우리가 하고자 하는 것들을 더 많이 정리하고 공유한 다음 진행했어야 했다고 느꼈다. 어떤 준비 과정이었어도 완벽할 순 없었겠지만, 조금 더 디테일한 설계와 단계별 목표를 세울 필요가 있었다.</p>
<p data-ke-size="size16">페어 프로그래밍을 시작하기 전에 미리 상상속에서 작업하다가 프로그래밍을 시작하는 경우가 많았다. 이게 문제가 됐던 것은 머릿속 내용을 풀어 설명하고 진행했어야 했는데 설명없이 급발진을 할 때가 있었다. 동승자들은 오늘의 여행을 지금 출발했는데 나는 한 시간 미리 출발해버렸으니 싱크가 안맞았다. 너무 급했다.</p>
<p data-ke-size="size16">유스방 활동은 일이 아니고 추가적인 과제이다. 최선을 다해야 함이 맞지만, 일보다 우선순위가 앞설 순 없었다. 시간을 맞추다 보면 하루 중 가장 힘든 시간대인 평일 업무를 모두 마치고 온 저녁이 되거나 주말 이른시간에 하는 경우가 많았다. 저녁에 진행하는 경우에는 그 날 하루의 경험과 상태가 과제에 영향을 미쳤을 것 같다. 아침은 잠이 덜깨서 뇌가 활성화가 안된 느낌이 들었다.</p>
<p data-ke-size="size16">약간만 더 여유가 있었다면 좀 더 즐겁게 과제를 진행할 수 있었을 것 같은데 아쉬웠다.</p>
<h3 data-ke-size="size23">잘한 점</h3>
<p data-ke-size="size16">못한점만 잔뜩있지만 그래도 한 가지 뿌듯했던 것이 있다.</p>
<p data-ke-size="size16">과제 진행중에 LocalDatetime.now() 코드를 필요로 하는 부분이 있었는데 이를 <a href="https://github.com/sang5c/problem-solutions/blob/main/test/%ED%85%8C%EC%8A%A4%ED%8A%B8-%EA%B0%80%EB%8A%A5%ED%95%9C-%EC%BD%94%EB%93%9C-%EB%A7%8C%EB%93%A4%EA%B8%B0.md">테스트 가능하도록 만드는 방법</a>을 조원 분들한테 설명했다. 예전에 NEXTSTEP의 TDD 수업에서 배웠던 전략 패턴이라는 디자인 패턴이다. 배울땐 이해 못하다가 언젠가부터 잘 써먹고 있었고, 이제는 알려줄 수 있어서 너무 뿌듯했다.</p>
<h3 data-ke-size="size23">페어 프로그래밍의 장단점</h3>
<p data-ke-size="size16">내가 느낀 페어 프로그래밍의 장점으로는 코드 리뷰보다 더 자세히 리뷰할 수 있고 즉각적인 의사소통을 통해 막힘 없이 개발이 가능하다는 것이다(리뷰는 피드백 텀이 일정하지 않다). 또한 같이 개발했기에 <a href="https://en.wikipedia.org/wiki/Bus_factor">버스 팩터(Bus factor)</a>를 높이고, 유지보수에 필요한 비용을 좀 더 줄일 수 있다.</p>
<p data-ke-size="size16">페어와 생각 동기화를 해나가는 과정은 많은 대화가 필요하다. 행복한 결말을 상상해본다면, 페어와 친밀도가 높아져 회사 생활이나 다른 업무에도 도움을 많이 줄 것 같다고 느꼈다. 뒤집어 생각하면 페어와 친하고 대화를 많이 해봤을 경우 페어 프로그래밍이 쉬워질 수 있는 것 같다.</p>
<p data-ke-size="size16">단점으로는 페어 프로그래밍도 기술이라는 것이다. <a href="https://medium.com/@ghilbut/%ED%8E%98%EC%96%B4%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D%EC%9D%84-%EC%A1%B0%EC%8B%AC%ED%95%98%EC%84%B8%EC%9A%94-4b4fd7d61150">블로그 글</a>에서 본 내용인데, 경험해보니 굉장히 공감했다. 기술이고, 러닝커브가 있다. 효율을 느끼기 위해서는 숙련도가 필요하다. 이번 글을 작성하면서 다시 읽어보니 공감가지 않는 내용이 없다.</p>
<p data-ke-size="size16">아쉬운 점에서 작성한 내용이 단점에 많이 속하는 것 같고, 대부분은 비용과 관련이 있을 것 같다. 만약 도입을 고민한다면 장단점을 저울질해서 고민하고 적용하는게 필요하다.</p>
<h3 data-ke-size="size23">마무리</h3>
<p data-ke-size="size16">파워리프팅(중량을 들어 힘을 겨루는 경기)에서는 큐, 큐잉(cue, <a href="https://en.dict.naver.com/#/entry/enko/ef7282592ade4b5487de3de1bc9818cc">cueing</a>)이라는 말이 있다. 정신을 집중한 상황에서 떠올리는, 상황을 개선시키는 포인트 단서, 단서를 주는 행위라는 의미인데, 예를 들어 break the bar(바를 부러뜨리듯 잡아라, 관절 부하를 줄이고 필요한 근육들 활성화됨) 같은 것들이 있다. 페어 프로그래밍에도 큐잉을 만들어서 적용했으면 더 효율적이지 않았을까 싶다. 아마 TDD 사이클을 따라서 드라이버를 교체해봤어도 재밌었을 듯 하다.</p>
<p data-ke-size="size16">짧은 시간이었지만 많은 고민과 경험을 했고, 이만큼 맞춰본 것도 대단하다고 생각한다.</p>
<p data-ke-size="size16">작성한 코드는 <a href="https://github.com/sang5c/java-wordle">여기</a>서 볼 수 있다.</p></div></div>

하다보면 잘하겠지

sang5c

글은 의식의 흐름대로 작성하였다.
들어가기 전..
우아한유스방 세 번째 과제로 페어프로그래밍을 진행했다. 페어 프로그래밍을 진지하게 해본건 처음이라 느낀점과 회고를 글로 남겨보고자 한다. 우아한유스방은 클린 코드와 페어 프로그래밍, 이력서 작성, 모의 면접과 상호 피드백 등을 경험하는 스터디이다. 미션을 수행한 후 참여자간의 상호 피드백을 수행하는 방식으로 과정이 진행된다.
세 번째 과제는 페어프로그래밍을 통한 Wordle 게임 개발이었다. 개인적으로 과제를 진행하기 전에, 이 과제를 통해서 무엇을 느끼기를 바랄지 추측해보고, 나는 어떤 경험을 하고 싶은지 고민하는 시간을 갖는다.
이번 과제의 목적은 라이브로 상호 피드백을 해보는 경험을 해보는 것이 목적이었던 것 같다. 페어 프로그래밍이 말로는 많이 들어도 직접 해볼 기회는 많지 않다. 항상 시작이 어렵기에, 여기서 시행착오를 겪으며 장단점을 직접 느끼고 최종적으로 나중에 회사에서 적용해볼 수 있는 발판이 되는 기회가 아니었을까 싶다. 평소 내 스타일대로 개발할거였으면 굳이 페어로 개발을 진행하지 않았을 거라는 생각이었기에 최대한 많은 의견 교환을 경험 포인트로 삼았다. 다른 사람들은 어떻게 생각하고 어떻게 일하는지 궁금했다. 이게 실천하기에는 좀 어려운 부분이 있었는데 느낀 점은 뒤에 작성하겠다.
참고로 Wordle 게임은 단어 맞추기 게임이다. 자세하게는 README를 참고하면 좋을 것 같다.
페어 프로그래밍
페어 프로그래밍은 짝 프로그래밍이라고도 부르고, 애자일 소프트웨어 개발 중 하나로 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방법이다. 다른 방법이 또 어떻게 있는지는 모르겠지만 이 글을 참고하여 드라이버 / 네비게이터로 역할을 나눠서 진행했다.
특이사항으로 우리 조는 3명으로 구성됐다. 이건 아마 몹 프로그래밍(Mob programming) 이라고 부르는 듯 하다. 수많은 장점들이 있는데, 링크를 참고하면 좋을 것 같다. 우리는 드라이버 1명과 네비게이터 2명으로 역할을 정해 미션을 수행했다.
느낀점
각 역할을 돌아가며 수행했고 내가 경험하고 느낀 점들은 다음과 같다.
네비게이터
나에게는 네비게이터의 난이도가 더 높았다. 어떤 범위와 내용을 가이드 해야할지, 나와 생각이 다를땐 어떤 타이밍에 의견을 제시해야할지 기준을 만드는게 어려웠다. 네비게이터는 드라이버보다 손이 놀기에 인지영역이 좀 더 넓고, 이는 좀 더 뒤에서 멀리까지 볼 수 있게 해준다. 그리고.. 역시 직접 하는 것보다 훈수가 쉽다. 우리는 네비게이터가 두명이었기에 미리 맞추지 못한 부분에서 문제가 종종 있었다. 사공이 많으면 배가 산으로 간다.
하지만 말로 하는 개발 훈수는 생각보다 많이 어렵다. 슬랙같은 메신저를 사용할때는 충분히 검색할 시간이 있고, 텍스트를 통해서 생각을 전달하기에 약간의 시간 텀이 있다. 하지만 드라이버로부터 질문을 받았거나, 내가 가고자 하는 방향을 설명해야 하는데 즉석에서 말로 진행하면 준비되지 않은 것들이 돋보인다. 현 상황에 대한 이해, 관찰과 해결 방안에 대해 빠르게 정리하고 전달해야 하기에 메신저를 통한 소통보다 난이도가 배 이상으로 높다고 느꼈다. 훈수도 아는게 많고 정리되어 있어야 두기 쉽다.
알고 있어도 말로 설명하려다 보면 어버버 하다가 결국 적당히 타협하는 경우도 생겼다. 최대한 설명했다고 하더라도 드라이버가 이해할 수 있다고 장담할 수 없다. 이걸 약간이나마 해소할 수 있는 방법은 말보다는 코드로 보여주는 것이다. 생각해보면 무언가를 학습할 때 설명 문서보다 예시 코드를 먼저 찾지만 말로 진행하다보면 말만 하게된다. 네비게이터도 코드에 손을 대야한다. (thanks to 하현님)
가장 중요하다고 생각하는 것으로 암묵지를 꺼내는 훈련이 필요하다. 그래야 내가 이럴때 어떻게 해왔고 뭘 하고싶고 드라이버는 뭘 하고있어요 라고 설명하기가 좀 수월해지는 것 같다.
중간에 늦게 와서 서브 네비게이터(sub navigator)같은 역할도 한번 했었다. 메인 네비게이터와 드라이버의 의견을 조율하거나 큰 흐름을 보는 역할을 수행(했다고 생각)했고, 메인과 서브를 구분하여 진행해보는 것도 나쁘지 않은 것 같다고 느꼈다.
드라이버
3명이서 진행했기에 네비게이터 비율이 더 높았다. 드라이버 맛을 좀 더 봤으면 느낌이 달랐을지 모르겠다.
일단 드라이버는 체력 소모가 엄청나다. 코드의 흐름에 집중한 채로 말을 굉장히 많이 해야한다. 30분 떠들고 나면 입이 바싹바싹 마른다. 역할을 수행하는데에 있어 가장 힘든 점은 머리가 하얘진다. 조금 과장하면 면접관 앞에서 라이브로 코드를 작성하며 피드백을 받는 것이다. 그리고 우린 두명한테 라이브 피드백을 받았다. 타인에게 코드를 작성하는 모습을 보여주는 것이 익숙하지 않다면 엄청 부담스럽다.
네비게이터가 흐름을 쉽게 이해하기 위해서는 드라이버가 작업 전에 무엇을, 어떻게, 얼마나, 왜 가급적 자세하게 설명하면서 코드를 작성해야 한다. 자동차 운전에도 숙련도가 필요한 것 처럼, 페어 프로그래밍 운전도 드라이버의 경험과 고민과 노력만큼 부드러운 드라이빙이 된다.
아쉬운 점
이번에 진행한 페어프로그래밍은 짧은 기간에 과제를 수행해야 했기에 급하게 시작했던게 오히려 발목을 잡는 포인트였던 것 같다. 급할수록 돌아가라고, 시작하기 전에 최대한 서로의 개발 스타일, 생각, 목표와 결과물같은 우리가 하고자 하는 것들을 더 많이 정리하고 공유한 다음 진행했어야 했다고 느꼈다. 어떤 준비 과정이었어도 완벽할 순 없었겠지만, 조금 더 디테일한 설계와 단계별 목표를 세울 필요가 있었다.
페어 프로그래밍을 시작하기 전에 미리 상상속에서 작업하다가 프로그래밍을 시작하는 경우가 많았다. 이게 문제가 됐던 것은 머릿속 내용을 풀어 설명하고 진행했어야 했는데 설명없이 급발진을 할 때가 있었다. 동승자들은 오늘의 여행을 지금 출발했는데 나는 한 시간 미리 출발해버렸으니 싱크가 안맞았다. 너무 급했다.
유스방 활동은 일이 아니고 추가적인 과제이다. 최선을 다해야 함이 맞지만, 일보다 우선순위가 앞설 순 없었다. 시간을 맞추다 보면 하루 중 가장 힘든 시간대인 평일 업무를 모두 마치고 온 저녁이 되거나 주말 이른시간에 하는 경우가 많았다. 저녁에 진행하는 경우에는 그 날 하루의 경험과 상태가 과제에 영향을 미쳤을 것 같다. 아침은 잠이 덜깨서 뇌가 활성화가 안된 느낌이 들었다.
약간만 더 여유가 있었다면 좀 더 즐겁게 과제를 진행할 수 있었을 것 같은데 아쉬웠다.
잘한 점
못한점만 잔뜩있지만 그래도 한 가지 뿌듯했던 것이 있다.
과제 진행중에 LocalDatetime.now() 코드를 필요로 하는 부분이 있었는데 이를 테스트 가능하도록 만드는 방법을 조원 분들한테 설명했다. 예전에 NEXTSTEP의 TDD 수업에서 배웠던 전략 패턴이라는 디자인 패턴이다. 배울땐 이해 못하다가 언젠가부터 잘 써먹고 있었고, 이제는 알려줄 수 있어서 너무 뿌듯했다.
페어 프로그래밍의 장단점
내가 느낀 페어 프로그래밍의 장점으로는 코드 리뷰보다 더 자세히 리뷰할 수 있고 즉각적인 의사소통을 통해 막힘 없이 개발이 가능하다는 것이다(리뷰는 피드백 텀이 일정하지 않다). 또한 같이 개발했기에 버스 팩터(Bus factor)를 높이고, 유지보수에 필요한 비용을 좀 더 줄일 수 있다.
페어와 생각 동기화를 해나가는 과정은 많은 대화가 필요하다. 행복한 결말을 상상해본다면, 페어와 친밀도가 높아져 회사 생활이나 다른 업무에도 도움을 많이 줄 것 같다고 느꼈다. 뒤집어 생각하면 페어와 친하고 대화를 많이 해봤을 경우 페어 프로그래밍이 쉬워질 수 있는 것 같다.
단점으로는 페어 프로그래밍도 기술이라는 것이다. 블로그 글에서 본 내용인데, 경험해보니 굉장히 공감했다. 기술이고, 러닝커브가 있다. 효율을 느끼기 위해서는 숙련도가 필요하다. 이번 글을 작성하면서 다시 읽어보니 공감가지 않는 내용이 없다.
아쉬운 점에서 작성한 내용이 단점에 많이 속하는 것 같고, 대부분은 비용과 관련이 있을 것 같다. 만약 도입을 고민한다면 장단점을 저울질해서 고민하고 적용하는게 필요하다.
마무리
파워리프팅(중량을 들어 힘을 겨루는 경기)에서는 큐, 큐잉(cue, cueing)이라는 말이 있다. 정신을 집중한 상황에서 떠올리는, 상황을 개선시키는 포인트 단서, 단서를 주는 행위라는 의미인데, 예를 들어 break the bar(바를 부러뜨리듯 잡아라, 관절 부하를 줄이고 필요한 근육들 활성화됨) 같은 것들이 있다. 페어 프로그래밍에도 큐잉을 만들어서 적용했으면 더 효율적이지 않았을까 싶다. 아마 TDD 사이클을 따라서 드라이버를 교체해봤어도 재밌었을 듯 하다.
짧은 시간이었지만 많은 고민과 경험을 했고, 이만큼 맞춰본 것도 대단하다고 생각한다.
작성한 코드는 여기서 볼 수 있다.

나의 첫 페어 프로그래밍 회고

댓글