⚠️ 개인적인 의견이 잔뜩 담겨 있는 글이며, 생각을 담은 글이기에 글이 다소 정리되지 않았으며 옳지 않은 부분이 있을 수 있습니다.

페어프로그래밍을 접한 계기

• 부스트캠프에서 학습 스프린트를 진행하면서 페어프로그래밍을 권장했다. 처음에 내게 페어프로그래밍의 도입은, 당장 어떤 문제를 해결하기 위해서가 아닌 하나의 방법론을 경험해보기 위해서 시작했다. 그렇게 나와 페어로 할 분이 정해졌고, 풀스택 프로젝트를 다루는 와중 다행히도 상대방분의 관심사는 FE쪽으로 나와 다른 분야를 잘하셔서 다행이라 생각했다.

🤔 서로 다른 관심사를 갖는 페어가 좋은 페어라 볼 수 있을까??

• 사람마다 관심 있는 분야가 다르고, 같은 분야의 개발자라 하더라도 분명 그 안에서 세부 배경지식의 차이가 존재한다.
• 배경지식을 어느정도 sync 하는 것이 페어프로그래밍을 시작하는 단계에서 중요하게 여겨지는 데, 나는 경험해보기 전엔 과연 이게 중요한가? 라는 의문을 가졌었다.
• 사실 이는 경험이 많지 않아 답을 내리긴 어려우나, 위의 질문에 대한 대답은 좋은 성과를 어떻게 정의하느냐에 따라 다를 것 같다.

🤔 좋은 성과란? (= 기대하는 점)

• 🏃 생산성 (속도 측면)

  • 당연히 속도 측면에서는 매우 빠른 결과가 나왔다. FE 부분은 해당 페어분이 driver를 맡아주셨고, 나는 상세한 문법까지는 관여하지 않고(못하고) 방향성에 대해서만 같이 논의하고 제안했다. 반대도 마찬가지 였다.
  • FE 의 전문성이 없는 내가 페어분처럼 능숙하게 컴포넌트를 구분할 수 있었을까? 그 분이 오랜시간 동안 축척한 노하우를 내가 단 시간에 흉내낼 수는 없으며, 이는 반대도 마찬가지일 것이다.
  • 즉 혼자서 프로젝트를 진행했을 때 보다는 훨씬 좋은 생산성을 보였다. 이 점에서 나는 페어프로그래밍이 매우 성공적이라고 생각했었다. (오해)

• ⚒️ 코드 품질 및 완성도

  • 사실 이 부분에서 아쉬움이 많이 남았다. 서로 서로만큼 서로의 분야에 전문성이 크지 않다보니, 태클을 걸기가 쉽지 않았다. Driver인 페어분께서 작성중인 코드에서 bad smell이 나는 것 같다고 하셨는데, 그 분이 해결 못하면 우린 해결을 못하는 것이었다.
  • 그래서 코드를 작성하며 “아 내가 더 FE를 잘 알았다면 같이 고민할 수 있었을 텐데” 라는 아쉬움이 남았다. 그러나 실제로 만약 그랬다면 반대로 상대방이 나한테 위와 같은 질문을 하고 있지 않을까? 라는 생각 또한 들었다.
  • 그래도 물론 혼자하는 것 보단 많은 부분에서 같이 의논하며 진행하다보니, 완성도적인 면에서는 도입한 효과를 크게 보긴 했다.

🤔 의문점

• 사실 페어프로그래밍을 도입한 이유는 생산성만 바래서 그런 것이 아니다. 사실 생산성을 챙기는 것은 ‘회사와 Team’의 관심사라고 생각한다. (디자이너는 디자인만 담당하고, 개발자는 개발을 하는 것과 같이 직무를 고려하여 팀을 구성하는 것)
• 이미 회사는 생산성이 좋게 구성되어 있는데, 그들을 각자 맡은 일에 몰두하게 하는 것이 가장 생산성이 좋은 것 아닌가? 왜 Tool 세팅 및 지식 sync에만 많은 시간이 걸리는 페어프로그래밍을 하는 것일까?

협업 VS 분업

• 사실 내가 처음에 페어프로그래밍에 관해 오해 했던 것은 위의 두 개념을 혼용했기 때문이다. 페어프로그래밍은 분업이 아니라 협업이다. 우린 회사에서 분업 중이던 두 명의(혹은 그 이상의) 직원을 한 업무에 같이 투입시킨 것이다. 이는 협업이라 봐야한다.
• 따라서 내가 느낀 페어프로그래밍에서의 생산성 측면에서의 기분 좋음은 사실 오해에서 비롯된 것이었다. (가짜였다)

느낀 점

• 2주간의 페어프로그래밍을 하면서 나름 적지 않은 깨달음을 느꼈다. 협업은 불편하다. 서로 맞춰가야하는 자잘한 세팅에서부터, 의사소통, 수 많은 협업 툴 등 혼자 음악들으며 코드를 작성할 때 보다 신경쓸 것이 많다.
• 그래도 페어프로그래밍은 중요하다. 중요한 이유는 많은 이점을 가져오기 때문이다. 생산성 + 완성도 그리고 내가 아직 정립 하지 못한 많은 부분에서 혼자 작성하는 것과는 차원이 다른 결과물을 가져온다. 개인적으로 “내가 만약 프로씬에 있는 회사의 직원이라면, 세세한 것 마저 팀으로 해결하는 게 당연한 것 아닌가?” 라는 생각이 들 정도이다.
• 페어프로그래밍이 무조건 좋은 것은 아니다. 최고의 효율을 얻기 위해 페어 구성, 문화, 방식 등에서 어떠한 선택이 좋을 지 고민해보고 도입해보자.

아이돌 음악은 호불호가 갈릴 순 있어도 음악 퀄리티적인 면에서는 부정하는 사람은 많지 않을 것이다. 이는 시스템적으로 ‘그럴 수 밖에’ 없기 때문이다.

1. 회사는 자본을 투자하여 드럼, 베이스, 멜로디, 작사 등 각 분야의 전문가를 데려와 곡을 완성시킨다.
2. 연주자, 가수, 작곡가는 자신의 위치에서 최선을 다하여 맡은 바를 다한다.
3. House Producer와 회사의 A&R들, 위의 모든 참여진들은 최종적으로 위의 요소들을 점검하고 편곡하며 곡을 완성한다.

과거에 오래 작곡을 했던 경험자로써 대부분의 음악의 퀄리티는 3번 과정에서 끌어올려진다. 이유는 가장 많은 사람이 같은 것을 보고 의논을 하는 과정이기 때문이다. 가장 많은 의견을 배출하고 그 만큼 의견대립도 가장 많은 부분이다. 이 의견 대립이 결과물을 좋게 만든다. 혼자 생각에 매몰되지 말자. 팀원들과 최대한 공유해보자.