페어 프로그래밍 vs 코드 리뷰 (feat. 코드기반 대화하기)

안녕하세요. yeTi입니다.
오늘은 페어 프로그래밍이나 코드 리뷰가 가지는 특성을 다른 시각으로 바라보고 시도해본 경험을 공유해보고자 합니다.

대화의 중요성

개발 활동이란 만들고자 하는 제품을 만들어내는 활동이고, 이는 대부분 하나의 서비스를 출시하기 위해서 다양한 분야의 사람들과 협의, 협업, 소통 이라는 활동을 진행합니다.

이 때, 중요한것은 서로의 생각을 일치시키고 공감하며 문제 해결을 위해 합심하는 것입니다.

하지만 현실에는 장벽이 존재합니다.
협업을 진행함에 있어서 언어라는 도구를 사용해서 소통을 하지만 생각을 온전히 일치시키기 힘들고, 물리적으로 떨어져있는 시람과도 소통해야합니다.

또한 사람의 기억에는 한계가 존재하기 때문에 기록을 통하여 이전에 합의했던 내용을 남겨둘 필요성도 있습니다.

이를 위해 소통하고 기록하기 위한 도구를 활용하고 있는데요.
제 경험내에서는 slack이나 confluence를 많이 사용하고 있었고 이에 대한 개인적인 활용법을 공유한적이 있습니다.

기능의 실현

개발자들은 정의된 기능이나 해결책을 실현하는 역할을 하는 사람들입니다.

그렇다면 개발자들에게 대화란 무엇일까요?

• 기획자와 협업하기?
• 개발자간 소통하기?
• 리더와 소통하기?
• QA와 소통하기?

물론, 기능이나 해결책을 합의하기 위해서 다른 사람들과 소통을 하지만 궁극적으로 개발자들은 코드로써 소통해야한다고 생각합니다.

• 서로가 협의한데로 구현을 했는지
• 개발자 의도대로 기능이 동작하는지
• 버그 가능성은 없는지
• 더 좋은 해결책은 없는지
• 새로운 사람이 조인했을 때 이력을 전달해 줄 수 있는지
• ...

다행이도 개발 문화에는 코드로써 소통을 위한 문화가 존재합니다. 바로 페어 프로그래밍 과 코드 리뷰 입니다.

페어 프로그래밍

페어 프로그래밍은 생각의 공유를 굉장히 직접적이고 적극적으로 공유하는 방식입니다.

XP 에서는 페어 프로그래밍을 다음과 같이 설명합니다.

페어 프로그래밍은 둘이서 동시에 프로그래밍을 (그리고 분석과 설계와 테스팅도) 하면서 프로그램을 더 낫게 만들려고 노력하는 두 사람 사이의 대화다.

그렇기 때문에 페어 프로그래밍을 하면 빠른 피드백과 직접적인 소통에 의해 의사결정을 정확하게 (혼자했을 때보다) 할 수 있고 정돈된 코드를 배포할 수 있습니다.

다만, 페어 프로그래밍의 아쉬운점은 원활한 소통의 기록이 정돈된 코드뿐이라는 것입니다. 가령, 두 사람의 다른 생각을 일치 시키는 과정이나 질문이 기록되지 않기 때문에 제 3자의 관점에서 흐름을 따라가기 위해서는 대상자들에게 질문을 다시 해야합니다.

코드 리뷰

코드 리뷰는 방식에 따라 오프라인으로 진행하는 동기식 방식과 도구를 활용하는 비동기식 방식이 존재하는데요.

동기식 방식은 페어 프로그래밍관 비슷한 특성을 가지기 때문에 비동기식 방식을 전제로 하겠습니다.

코드 리뷰라는 활동은 온전한 기능을 만들어 내기 위해서는 필요한 절차이지만, 개발 리소스가 타이트한 상황에서 오는 배포의 pending 상태는 리뷰어나 리뷰이가 부담을 느끼거나 스트레스를 만들 가능성이 있습니다.

또한, 사람에게 느껴지는 부담이나 스트레스는 업무 처리능력을 떨어뜨리고 생각의 폭을 좁게하기 때문에 코드 리뷰의 효율을 떨어뜨릴 수 있습니다.

따라서 저는 코드 리뷰는 비동기적으로 도구를 통하여 지식을 쌓아가는데 의미가 있다고 생각합니다 예를 들어, slack 과 비슷한 성격을 가지는거 같습니다.

현업에 적용

현업에서는 페어 프로그래밍과 코드 리뷰를 선뜻 도입하지 못하고 있었습니다.

왜냐하면 두 방식 모두 개발 효율성에 의구심을 가지고 있었기 때문입니다. 가령 한 iteration에 파트의 100% 역량을 투입해야한다고 판단이 되는 상황에서 페어 프로그래밍이나 코드 리뷰의 도입이 명확한 개발 효율 증가의 결과로 나올것이란 확신을 가질 수 없었고 파트원들과 공감대를 만들 자신이 없었습니다.

하지만 두 활동이 코드의 품질을 높이고, 버그의 발견 가능성을 높이고 업무의 공유 측면에서는 효과가 있다는 확신은 가지고 있었기 때문에 포기하고 싶지 않았습니다.

그렇게 주도적으로 노력한 부분은 완전한 비동기식 코드 리뷰입니다.

공유 문서를 활용하여 조금이라도 리뷰를 하면 리뷰이가 응답하는 구조로 매우 적은 부분이나마 유지하고자 했습니다.

하지만 이 구조에 불만이 있었던 부분은 대화의 내용이 파트원에게 전파되지 않았고 누구든 대화에 끼어들 수 있는 구조가 아니라는 점이었습니다.

최종적으로 코드를 기반으로 슬랙과 같이 자유롭게 토의하면서 쓰레드로 토의의 깊이를 깊게 확장할 수 있는 구조가 있었으면 좋겠다는 생각이 들었습니다.

이에 컨셉을 잡고 파트내 생성한 문화는 코드기반 대화하기 입니다.

컨셉의 구조는 이렇습니다.

• 대화의 창구는 gilab의 커밋 단위이다.
• 대화 내용은 RSS 형태로 각 파트원에게 이벤트를 전달한다.

매우 간단한 구조이지만 효과는 좋습니다.

• RSS 피드만 보면 현재 진행되는 대화의 흐름을 파악할 수 있습니다.
• 상세한 내용이 궁금하면 링크를 통해 커밋에 접근하면 됩니다.
• 나중에라도 궁금한 부분이 있으면 기록을 찾아볼 수 있습니다.
• 이렇게 코드기반으로 생각의 공유가 가능해집니다.

코드기반 대화를 통해 해결할 수 있는 것은 다음과 같습니다.

• 크로스 체크 : 파트내 커밋 로그가 스트림되기 때문에 누구든 참여하여 크로스체크가 가능합니다.
• 지식의 전파 : 코멘트 로그가 스트림되기 때문에 코드기반의 모든 대화 내용이 전파됩니다.
• 기록의 공유 : 커밋 혹은 머지단위로 개발 의도나 문제점들이 기록됩니다.
• 생각의 공유 : 코드에서 발생한 이벤트에서 파생되는 개인의 생각이 파트차원에서 공유가 됩니다.
• 스타일의 공유 : 생각이 공유되는 수준에 따라 강제하지 않더라고 개발 스타일이 맞춰집니다.

단점은 이미 개발사항은 배포한 상황에서 진행하는 활동이기 때문에 잘못된 부분이 발생한다면 후처리를 하는 방식입니다.

해당 글은 현재 아기발걸음 수준에서 남긴 기록입니다. 불과 5일차??

하지만 해당 구조가 기존의 코드 리뷰나 페어 프로그래밍이 가질 수 없는 정보의 기록과 정보의 전파를 보완할 수 있다는 생각이 들어 지속적으로 시험해보고 싶다는 생각이 들었습니다.

또한 페어 프로그래밍이 가지는 실시간성은 가질 수 없지만 시간이 지날수록 그에 준하는 품질이 나올것으로 기대하며 개발 효율은 더 좋아질 것으로 생각됩니다. 결국 페어 프로그래밍도 협업의 한 형태라고 생각하기 때문입니다.

코드 리뷰의 단점은 배포의 pending 상태라고 생각하는데요. 이 부분은 배포의 역할을 전적으로 개발자에게 위임하기 때문에 해소된다고 생각합니다. 다만 이슈가 검토되시전 배포된다는 단점이 존재하지만 이도 결국 코드기반 대화를 통한 생각 맞추기로 인해 해소될것으로 기대합니다.

이상 코드기반 대화하기를 시도해본 소감이었습니다.
감사합니다.