2주간의 온라인 페어프로그래밍 회고
안녕하세요 파파고 iOS 개발자 홍성호 입니다. 팀을 이동하고 나서 처음으로 페어프로그래밍을 하게 되었습니다. 하나의 기능을 조각으로 나눠서 개발한 적은 있었지만 한 화면을 같이 보면서 나란히 개발할 적은 없어서 많은 기대가 되었어요. 특히 온라인으로 이루어지는 협업이라서 완전히 새로운 경험이었습니다.
페어 프로그래밍
저처럼 페어 프로그래밍이 낯선 분들을 위해 이게 도대체 뭔지 간단히 얘기해볼게요. 페어 프로그래밍은 2명의 프로그래머가 짝이 되어서 함께 코드를 작성하는 방법입니다. 한명은 코드를 작성하는 Driver가 되고 한명은 전략을 제시하고 함께 논의하는 Navigator가 됩니다. 아래의 글에서도 페어 프로그래밍 장단점을 설명해주고 있는데 여전히 낯선 분들은 읽어봐도 좋을 것 같아요.
페어 선정
스프린트를 시작할 때 저희 팀 실력자 근수님과 제가 페어가 되었고 특정 기능을 할당받았습니다. 근수님은 저희 팀 신입이지만 저보다 두달 정도 앞서서 팀에 합류해서 저보다 훨씬 프로젝트를 잘 파악하고 있어서 많은 도움이 되었습니다.
제가 조금 더 경력이 있기에 뭔가 알려줘야하는건가? 하는 마음도 있었어요. 실제로 진행해보니 토론을 통해 서로서로 부족한 부분은 채워지는 것을 느꼈습니다. 경력 차이가 많이 나는 경우도 있겠지만 A가 B를 가르쳐줘야겠다는 마음으로 진행하면 서로에게 손해가 될 것 같았어요. 너무 부담 갖지말고 가볍게 시작해보기! 가 좋은 것 같습니다.
진행 규칙
첫번째 시간에는 진행하는 규칙을 정했어요. 코딩하는 시간과 휴식하는 시간을 얼마나 가져갈지 정했습니다. 처음에는 코딩 시간을 50분 + 휴식 10분 정도로 생각했던 것 같아요. 나중에는 컨디션 따라서 조절해나가는게 좋더라구요. 저는 코딩 30분 + 휴식 10분 정도의 시간이 적절했습니다. (서로 컨디션 체크를 해주면 좋습니다!)
진행 시간은 상황에 따라 다를 것 같아요. 오프라인으로 짝코딩을 진행하면 10분 정도의 짧은 간격을 두고 역할을 교체하는 것으로 알고있어요. 오프라인에서는 똑같은 작업 환경을 유지하고 키보드만 넘겨 받으면 됩니다. 하지만 온라인에서는 역할이 교체되면 코드를 커밋하고 경우에 따라 클린 빌드하고 화면 공유를 전환하는 시간이 소요됩니다. 그래서 온라인의 경우 코딩 시간을 좀 더 길게 가져가는게 낫다고 생각합니다.
코딩 시간
누군가 지켜보는 중에 코드를 작성하는 경험이 많지 않다보니 처음에는 코드를 빨리 작성해야할 것 같은 마음이 들기도 했어요ㅋㅋ;; 결과물은 없더라도 생각을 일치시키는 시간도 필요하다고 생각합니다. 이 시간에 객체 역할 분리와 네이밍 고민, 파일 위치 고민, 일의 방향성을 함께 논의할 수 있어서 좋았습니다.
진행하면서 공통의 코드 라는 생각이 더 강하게 들었는데요. 제가 혼자서 작품 활동을 하는 것 마냥 코드에 공들여서 PR을 올리게 되면 해당 부분에 대한 애착이 자연스럽게 생기게 되는 것 같아요. 그러면 리뷰받을 때 현재의 코드를 완전히 갈아엎는 것은 거부감이 생기게 됩니다ㅠㅠ 페어 프로그래밍을 하면 혼자서 작성한 부분이 줄어들게 되어서 코드 오너쉽이 팀에 있다는 것을 은연 중에 알게됩니다.
쉬는 시간
쉬는 시간이 정말 중요하다고 생각해요. 페어 프로그래밍을 하면서 느낀 가장 큰 단점은 체력이 빨리 떨어진다는 점입니다… (두 번째 단점은 나란히 재택 근무하는 와이프의 눈치가 보인다는 점… 👀) 오프라인이었으면 조금 덜 했겠지만 줌으로 접속하면서 페어를 맞추려니 상대방의 반응에 귀 기울이고 제 의견을 말하는게 에너지가 꽤 많이 들었습니다. 혼자 일할 때는 알게 모르게 완급 조절을 했던 것 같아요. 그래서 정해진 쉬는 시간을 가지는게 정말 좋습니다. 코딩 시간이 마무리 될 때 쉬는 시간을 얼마나 가질지 얘기해보고 필요하면 더 쉽니다.
만약 쉬는 시간에 체력이 남는 경우가 있다면, 코딩 시간에 전달하지 못했던 외부 문의 사항을 남겨두는 것도 좋은 것 같아요. 저희 팀은 슬랙으로 대부분의 소통을 하는데 쉬는 시간에 남겨둔 질문에 대한 답변이 대부분 코딩 시간 전에 올 때가 많았어요. 그러면 코딩 시간에 답변을 참고해서 또 진행할 수 있었어요.
데일리 회고
페어로 작업을 하던 중반 쯤 부터 데일리 회고를 시작했습니다. 하루를 마치면서 작업 방식에 대한 정리를 할 수 있었고 매일 발전하고 있다는 느낌을 받았습니다. 서로 좋았던 부분 아쉬웠던 부분을 들어볼 수 있어서 좋았습니다. 저희는 이슈에 코멘트로 업데이트 했습니다.
장단점 정리
앞에서도 느낀점을 적었지만 좀 더 정리를 해볼게요. 제가 느낀 장단점은 뚜렷하긴 해서 매 스프린트 마다 진행하기 보다는 집중적으로 논의가 필요한 기능에 대해서 진행하는 것도 좋을 것 같아요.
장점
- 두 사람의 스타일을 빠르게 파악할 수 있다.
- 프로젝트 구성에 빠르게 익숙해질 수 있다.
- 불필요한 오버 엔지니어링을 방지할 수 있다.
- 때로는 오버 엔지니어링을 허용하며 함께 실험해 볼 수도 있다.
- 일이 막혔을 때 혼자 과도하게 스트레스 받지 않을 수 있다.
단점
- 체력이 빨리 떨어진다.
- 두 사람의 스케줄을 맞춰야하는 번거로움이 있다.
- 화상회의가 많다 보니 회의 + 페어 프로그래밍 하면 하루 종일 줌에 붙어 있는 기분이 든다.
- 같이 재택하는 분의 눈치가 보인다.
마무리
예전부터 짝코딩을 너무 해보고 싶었는데 코로나도 오고… 기회를 갖기가 쉽지 않았는데 이번에 경험을 해볼 수 있어서 너무 좋았습니다. 그리고 온라인 페어프로그래밍에 대한 회고가 더 많이 늘어나면 좋겠습니다. 코로나 상황이 계속 길어지기도 하고 재택 근무가 많아 지니 온라인 페어프로그래밍에 대한 니즈가 많아질 것 같아요. 이 글도 누군가에게 도움이 되면 좋겠네요!
