페어프로그래밍(Pair Programming) 후기

🌞 1. 서론

  2명이서 프로젝트를 진행해야 할 일이 있었다.

  지금까지는 협업을 한다고 하면 '분업을 하고 각자 맡은 일을 하는 방식'으로 협업을 진행하였다.

  하지만 이 프로젝트를 하기 전에 '함께 자라기 - 애자일로 가는 길'이라는 책을 읽었고, 위에서 언급한 방식이 협력을 위한 방식이 아니라는 걸 알게 되었다. 

사람들은 협력이 중요하다고 합니다.
그래서 프로젝트를 할 때 협력적으로 하자고 합니다.
그러나 실제 모습을 들여다보면 초반에 일을 세밀하게 나누고 선을 긋습니다.
그리고 안녕이죠.

각자 진행하고 나중에 만나서 서로 합쳐봅니다.
그 속을 들여다보면 협력은 거의 없습니다.

- 함께 자라기 중 일부 내용 -

  그래서 이번 기회에 애자일 방법론 중 하나인 페어프로그래밍(Pair Programming)을 도입해보고자 하였다.

  그래서 페어에게 "혹시 페어프로그래밍을 안 해봤으면 한번 해볼까?"라고 물어봤는데 생각보다 너무 흔쾌히 수락해 주었다. (그러고 보니 아직까지도 내가 왜 페어프로그래밍을 제안했는지 페어에게 설명을 안 해주었는데 이 글을 공유하는 걸로 설명을 대체해야겠다.😅)

  그렇게 우리의 페어프로그래밍이 시작되었다.

day1

day2

day3

  기간은 '2023년 05월 17일(수요일) ~ 2023년 05월 19(금요일)', 총 3일 동안 진행하였다. 시간은 하루에 6시간 내외로 작업을 하였다.

  페어프로그래밍을 하면서 여러 가지 느낀 점이 있었지만 그중 가장 기억에 남는 3가지를 적어보고자 한다.

 

 

🌞 2. 느낀 점

📌 1. 배운 것을 적용하려고 더욱 애써야 한다.

  Entity를 만드는 과정에서 나의 페어가 자연스럽게 빌더 패턴(Builder Pattern)을 사용하였다. 이전까지 나는 생성자를 쓰거나 조금 더 고려할 상황이 있으면 점층적 생성자 패턴을 사용해 왔었다. 그래서 빌더 패턴을 왜 쓰는지 물어봤고 빌더 패턴을 어떤 상황에 쓰면 좋은지에 대한 의견을 들을 수 있었다.

 

  그런데 잠시?... 듣다 보니 어디서 본 내용이었다?...

  알고 보니 이펙티브 자바의 아이템 2인 '생성자에게 매개변수가 많다면 빌더를 고려하라'에서 다룬 내용이었다. 해당 내용을 읽고 블로깅까지 했었는데 까맣게 잊어버리고 있는 것이었다. 블로깅한 글을 보자마자 내용들이 생각나긴 했지만, 너무 까맣게 잊어버리고 있어서 조금 충격이기는 했다.

 

  그래서 코드를 짤 때 '조금 더 나은 방법이 없을까?', '배웠던 것을 이런 상황에서 쓰면 되지 않을까?'라는 고민들을 의도적으로 해야겠다는 생각이 들었다.

 

📌2. 논리적으로 사고하는 연습을 하자.

  @RequestBody를 이용해서 2개의 객체를 받을 일이 있었다.

👨‍🦱 페어 : 객체 2개가 넘어오는데, @RequestBody 2개 쓰면 되지?
💬 나의 생각 : 객체가 1개일 때 @RequestBody를 1개 썼으니깐, 객체가 2개일 때는 @RequestBody를 2개 쓰자.
👱‍♂️ 나의 답변 : 응. 2개 쓰면 될꺼같은데?

  위의 대화에서 '페어의 질문, 나의 생각, 나의 답변'이 너무나도 자연스럽게 흘러갔다. 실행을 했는데 당연히 원하는 값을 얻지 못했다. 그렇게 하면 안 되는 거였다.

  @RequestBody는 HTTP 요청의 Body를 그대로 받아 자바 객체로 변환해 주는 것이다. 그리고 단일 객체만을 처리할 수 있기 때문에, 여러 객체를 받고 싶을 경우에는 하나의 요청으로 구성한 후 여러 객체로 쪼개서 처리하는 등의 방식을 사용해야 한다.

 

  문제를 해결하는 것은 어렵지 않았지만, 위에서 내가 페어에게 답변을 하는 과정에서 고칠 점이 있다고 생각한다. 나의 생각의 흐름이 조금은 더 논리적이어야 한다는 것이다.

👨‍🦱 페어 : 객체 2개가 넘어오는데, @RequestBody 2개 쓰면 되지?
💬 나의 생각 : HTTP Body는 한 개다. → @RequestBody를 2개 쓰면 Http Body가 2개여야 할 거 같은데, 이건 말이 안 된다. → 요청에서 하나로 묶어서 보내고, 요청을 받아서 나누자.
👱‍♂️ 나의 답변 : @RequestBody를 2개 쓰면 HTTP Body가 2개여야 할 거 같은데, 객체 2개를 하나의 요청에 묶어서 하는 게 맞을 거 같은데? 그렇게 해서 한번 실행해 보고, 더 좋은 방법이 있는지 같이 찾아보자.

  물론 모든 상황에서 항상 논리적으로 답변을 할 수는 없을 것이다. 하지만, 알고 있는 것을 바탕으로 최대한 논리적으로 사고하도록 연습해야 할 것이다.

 

📌 느낀 점 3. 일과 휴식의 밸런스

  이전까지 작업을 할 때는 '집중될 때까지 일하고, 쉬고 싶을 때까지 쉬는 방식'으로 작업을 하였다. 그렇다고 계속해서 쉬는 게 아니라, '1시간 30분 일하고, 20분 쉬기', '2시간 30분 일하고, 30분 쉬기' 정도의 비율을 맞추기는 했다...😅

 

  하지만, 페어프로그래밍을 할 때는 한 사람의 작업 리듬에만 맞춰서 진행할 수는 없기 때문에 '50분 일하고, 10분 쉬는 방식'으로 진행하였다.

  새로운 방식이라서 그런지, 아니면 이 방식이 조금 더 적합해서 그런지는 몰라도 작업을 할 때 집중력이 올라간다는 느낌이 들었다. (물론 옆에 페어가 있기 때문에 집중력이 올라갔을 수도 있다.)

 

  변수가 너무 많기 때문에 아직까지 어떤 게 맞는지 확신할 수는 없다. 하지만, 여러 상황에서 여러 가지 시간 사용 패턴을 적용해 보면서 어떤 게 좋은지 확인하고 수정할 필요는 있다고 생각된다.

 

 

🌞 3. 마무리

  '내가 아직 잘 모르네?'라는 생각을 100번 넘게 할 정도에 페어프로그래밍이 끝이 났다.

  좋은 페어를 만난 덕분에 현재 나는 페어프로그래밍의 장점만 알고 있는 건 아닐까라는 생각이 들기도 한다. 음... 배부른 소리다...😂

  페어프로그래밍을 통해 새로운 경험을 하고 새로운 것을 배울 수 있어서 좋았다.

  이 글을 통해 즐겁게 페어프로그래밍을 하게 해 준 페어에게 다시 한번 고맙다는 말을 하고 싶다.

 

  그리고 페어프로그래밍을 하면 아래의 뱃지(Achievement)를 얻을 수 있다.

  페어프로그래밍도 하고 '공동작업자 기능'도 사용해 보면서 다들 해당 뱃지도 얻을 수 있었으면 좋겠다.