효율적인 페어 프로그래밍 (with. 부스트캠프)
과거의 저는 혼자 문제를 고민하고 프로그래밍을 진행하는 것에 많이 익숙하였습니다.
그러던 중 SSAFY 6기 교육에서 처음 페어 프로그래밍을 접하게 되었는데, 내가 아닌 누군가와 함께 프로그래밍을 한다는 것에 매우 낯설었습니다.
처음 접했을 때 "두 명의 개발자가 하나를 진행하니까 당연히 비효율적이지 않을까??" 라는 생각이 강했습니다.
그렇지만 실제로 페어 프로그래밍으로 진행하는 경우도 있고, 추천하는 이유가 있지 않을까? 싶은 생각에 직접 경험해보고 결정하자는 생각을 갖게 되었습니다.
이번 포스트는 페어 프로그래밍에 대한 경험과 생각의 변화에 대해 다루어보겠습니다.
제가 겪은 경험으로 더 효율적인 방법에는 무엇이 있을지, 성장하기 위해 무엇에 집중할지 생각해보는 시간을 가져보겠습니다.
첫 페어 프로그래밍 경험
페어 프로그래밍을 진행하기 이전에 여러 개발자들의 블로그 글을 읽어보았습니다.
많은 글들은 장단점과 필요한 사항 등 내용들이 있었으나, 직접 경험하지 않다보니 크게 와닿지 않았습니다.
그렇게 시작한 첫 페어 프로그래밍은 불편하고 부정적인 시선이 강해졌습니다.
SSAFY에서 진행한 페어 프로그래밍은 1주일 중 하루만 진행했습니다.
당일 페어를 구하고 주어진 시간(약 5시간) 동안 요구사항을 구현하는 방식으로 진행이 되었습니다.
페어를 처음 만나서 그라운드룰을 정하고 요구사항을 구현하였는데 아래의 문제점들이 자주 발견되었습니다.
1. 서로 의견을 제시하지 않음 (의사소통 부재)
2. 페어의 실력이 모두 부족한 경우, 작업 진행이 거의 불가능함
3. 페어간 실력 차이가 있는 경우, 실력이 더 좋은 페어가 리드 경험이 적다면 혼자 작업을 진행하게 됨
4. 한정된 시간 내에 목표 달성이 필요한 경우, 코드의 퀄리티가 떨어짐
이러한 문제들이 발생한 원인들은 여러가지가 있었습니다.
원인으로는 매일 새로운 페어를 만나고 작업 진행은 4~5시간밖에 없어서 친밀감을 쌓기 어려웠습니다.
또한, 짧은 시간에 목표를 달성해야하기에 고민과 생각을 나누기 보다 구현 방법을 아는 사람이 혼자서 작업을 진행하였습니다.
이 외에도 다양한 문제들이 발견되면서 저의 첫 페어 프로그래밍은 불편하며, 다시 진행하고 싶지 않은 경험으로 남게 되었습니다. 😱
페어 프로그래밍 재도전
첫 페어 프로그래밍 이후 부스트캠프 과정에서 다시 한번 페어 프로그래밍을 진행하게 되었습니다.
이 소식을 듣자마자 과거의 기억이 떠오르며 힘든 시간을 보내겠구나 싶었습니다.
부스트캠프에서는 2주간 함께 진행할 페어를 정하고, 요구사항을 구현하는 방식으로 진행되었습니다.
이전과 유사하게 페어를 처음 만났을 때, 그라운드 룰을 정하고 요구사항을 구현하는 방식으로 진행했습니다.
큰 기대없이 시작했던 페어 프로그래밍은 의외의 장점들을 발견하며 긍정적인 생각으로 바뀌게 되었습니다.
이번 페어 프로그래밍은 요구사항 구현을 위해 필요한 라이브러리를 선정하는 것부터 프로젝트 구조, 코드 스타일, 로직 등을 하나하나 의견을 말하며 진행했습니다.
페어 프로그래밍을 다시 진행하며 느낀 장점들은 아래와 같습니다.
1. 구현하기 위해 필요한 부분과 흐름을 공유하는 과정에서 나의 생각을 정리할 수 있음
2. 페어의 생각을 공유받아 내가 생각하지 못한 관점에서 바라볼 수 있음
3. 구현 진행 중, 문제가 생겼을 때 페어의 도움으로 빠르게 수정 가능, 오타와 실수를 빠르게 파악 가능
4. 버그 발생 시, 페어와 각자 생각을 말하며 원인을 파악 가능
이 외에도 여러 장점들이 있었지만, 저는 페어와 의견을 나누면서 나의 생각을 정리할 수 있다는 장점이 가장 인상 깊었습니다.
예시로 저와 페어는 소켓 통신과 관련된 요구사항을 구현해야 했습니다.
서버와 클라이언트의 소켓 통신을 진행하는데, 서버와 클라이언트가 수시로 통신하여 페어와 저는 흐름이 머릿속으로 복잡한 상태였습니다.
이때 페어에게 내 생각을 올바르게 전달하기 위해 천천히 다시 생각하고 함께 그림을 그리며 이해하는 과정이 생겨났습니다.
이러한 과정 이후에 논리적으로 흐름을 이해하고 구현하는데 어려움을 해소할 수 있었습니다.
우아콘 발표 (페어 프로그래밍)
페어 프로그래밍을 진행하던 와중에 우아콘을 참여하여 온라인으로 여러 발표들을 볼 수 있었습니다.
여러 발표 중 "기획서도, 시간도 없다! 나만의 카드를 선물하기 위한 여정!" 의 발표를 시청하게 되었습니다.
해당 발표는 배달의 민족에서 선물하기에서 나만의 카드를 제작하는 과정을 담은 이야기입니다.
이전에 진행한 "말듣꾸(말하기, 듣기, 꾸미기)" 프로젝트를 진행하였을 때, 비슷한 기능을 제작한 경험이 있어서 따로 다루어 보겠습니다.
해당 영상에서는 프론트엔드 개발자들이 페어 프로그래밍을 진행하여 개발한 내용에 대해 다루었습니다.
영상에서 알려준 그라운드 룰 정하는 것과 현재 저와 페어가 정한 그라운드 룰이 비슷한 부분이 많아 인상적이였습니다.
페어 프로그래밍 진행을 위해 필요한 그라운드 룰은 아래와 같습니다.
1. 화면 공유하기
저와 페어는 줌을 이용하여 화면 공유를 켜고, 페어는 공유된 화면을 보면서 의견을 나누었습니다.
페어는 공유된 화면 외에도 브라우저를 열어 필요한 내용을 바로 검색하여 도와주며 진행하였습니다.
2. 프로그래밍은 번갈아가며 (약 30분씩)
한 명이 코딩을 진행하는 시간은 페어와 의논하여 시간을 유동적으로 변경하였습니다.
저와 페어는 30분은 너무 짧고, 자주 변경하는 번거로움으로 1시간씩 정해서 프로그래밍을 진행하였습니다.
3. 지속적으로 메모하고 공유하기
발표 영상에서는 사소한 내용들(기능 완성, 할 일, 이슈, 생각, 학습 등... ) 모두 메모하고 공유하는 것을 권장하였습니다.
저와 페어는 이 부분이 다소 아쉬운것 같습니다.
발생한 이슈와 해야하는 일 정도의 중요한 내용만 메모를 진행하고 있어, 시간이 흘러서 내용을 종종 잊는 경우가 발생했습니다.
4. 코드, 다이어그램으로 말하기
온라인으로 진행하는 페어 프로그래밍은 화상과 음성에만 의존할 수 밖에 없습니다.
저와 페어 역시 문제가 발생하면 대화로면 의견을 공유하면 잘못 이해하는 경우가 있었습니다.
꼭 자세한 코드나 다이어그램이 아니더라도 서로 생각을 쉽게 이해할 수 있도록 그림을 그리면 서로의 의사소통에 도움이 되었습니다.
5. 무턱대고 붙어있지 않기 (분위기 환기)
프로그래밍을 진행하면서 문제가 발생하면 해결하기 위해 붙잡고 버티는 경우가 많이 있습니다.
개인적인 의견일 수 있으나, 혼자보다 페어와 함께 고민하고 버티는 경우에 에너지 소모가 더 크게 와닿았습니다.
저희의 경우 40분~1시간 정도 해결되지 않는 깊은 문제이면 10~15분 가량 휴식을 취하고 다시 프로그래밍을 진행하였습니다.
위의 사항외에도 여러 그라운드 룰을 정할 수 있습니다.
저희는 위 사항 외에도 작업 시간대(오전/오후) 를 정하여 함께 집중할 수 있는 시간에 작업을 진행하였습니다.
페어 프로그래밍은 페어와 함께 진행한다는 점에서 서로를 배려하고 모든 부분에 대해 서로의 생각을 공유하는 과정이 중요하다고 생각합니다.
이번에 페어 프로그래밍을 진행하면서 페어와 많은 의사소통 덕분에 더 빠르고 효율적으로 작업을 진행할 수 있는 경험이였습니다.