페이지를 만든 이유- 승구님의 방법론이 매우 흥미로워서 더 명시적으로 정리해두기 위해,
- 혹시 이 주제 자체가 글감이 되지 않을까 하여 - 2022.11.10 형준
페어 라이팅 (pair writing):하나의 article을 완성할 때, 글의 개요를 잡고 본문을 작성하는 과정을 두 사람이 함께 하는 작업방식. '페어 프로그래밍'의 방법론을 차용한다.
페어 프로그래밍은 원래 - 하나의 모니터와 키보드로
- 두 사람이 한 공간에서, 각각 항해자와 운전자 역할을 번갈아가며 하는 작업이지만,
크리베이트 페어 라이팅의 경우, 주로 비대면 상황에서 활용되므로 - 두 사람이 각자의 모니터와 키보드로 진행하되
- 단락, 주제 별로 main writer(운전자)/sub writer(항해자) 역할은 명확히 정해본다.
페어 프로그래밍의 핵심위 링크의 내용 중, 중요하며 페어라이팅에 적용할 수 있을만한 것들을 긁어옴. - 페어 프로그래밍의 효과
- 일에 집중
- 생각을 명료하게 다듬음
- 한 사람이 막힐 때 주도권을 다른 사람에게 넘겨, 짜증을 방지함
- 실천 방법을 서로 책임지고 지키도록 함
- 조직 내 지식 확산을 촉진함
- 유의할 점
- 번갈아가며 키보드를 치는 것은 페어 프로그래밍의 일부에 불과함
- 방법이 불편하다면, 코드 리뷰로 대체해야 함
- ‘항해자’(키보드를 가지고 있지 않은 사람) 역시 자기 컴퓨터를 가지고 있어야 함. 개발을 하기 위해서가 아니라, 필요할 때 작은 스파이크(spike)를 해보거나(글에 직접 개입) ‘운전자'(키보드를 가진 사람)가 막히게 되었을 때 관련 문서 등을 살펴보기 위해서임.
- 페어 프로그래밍은 항해자와 운전자로 나뉜다. 코드를 직접 작성하는 사람이 운전자, 뒤에서 지도를 보며 조언하는 사람이 항해자.
- 추천하는 절차
- 페어프로그래밍 전의 상황과 페어프로그래밍 후 나와야 할 결과물을 정확하게 합의한다. 반드시 페어프로그래밍으로 하루 안에 끝낼 수 있는 범위여야만 한다.
- 페어프로그래밍에 필요한 기반 기술에 대한 이해도를 필요한 수준으로 싱크한다. 또한, 코드에 사용할 중요 단어들(도메인 용어들을 어떤 영단어로 사용할지)에 대해서도 미리 합의한다.
- 페어프로그래밍의 대상이 되는 패키지나 클래스의 디자인에 대해 함께 검토하고 합의한다.
- 코드를 막힘없이 작성하는데 필요한 기반 지식이 충분히 싱크 되었다고 합의한다면 코딩을 시작한다.
- 키보드와 마우스는 한쌍만 갖는다. 다만, 요즘은 IDE가 다양하기 때문에 상대방의 도구가 불편할 수 있다. 둘 모두 랩탑이라면 각자 장비를 가져와도 되지만 다른 사람이 코딩하는 순서에서는 자신의 랩탑을 닫도록 한다.
- 개인적으로 30분 코딩, 10분 회고+플래닝 싸이클을 선호한다. 30분 동안 코딩한 후 10분 동안 충분히 싱크되지 않았던 부분을 점검하고 디자인의 미비점이나 미처 생각하지 못했던 중요한 부분들에 대해 확인한다. 그리고 다음 코딩에서 그 부분들을 어떻게 처리할지 합의한다. 만약, 10분 안에 점검 및 합의가 불가능한 문제라면 코딩을 중단하고 1번으로 되돌아가야만 한다. 코딩을 30분으로 하는 이유는 하나의 작은 목표(함수, 클래스, 테스트 케이스 등)를 완료할 수 있으면서 운전자와 항해사 모두 집중력을 유지하는데 적절한 시간이라고 생각하기 때문이다. 추가로 운전자가 코딩을 하며 코딩하는 내용을 소리내어 설명하면 효과가 더 좋다.
- 페어프로그래밍 중 진행에 특별한 문제점이 감지되지 않는다면 적절한 휴식을 섞어가며 목표를 완료한다.
전체 절차를 진행할 때 가장 중요한 것은 6번의 싸이클을 돌릴 때 물흐르듯이 막힘이 없어야 한다. 코딩을 시작한 이후 키보드를 치는 시간보다 서로 의견을 나누는 시간이 더 많거나 코드를 삭제하고 재작성하는 상황이 빈번하게 발생한다면 1~4번을 제대로 하지 않은 것이므로 반드시 코딩을 중단하고 처음으로 되돌아가야 한다.
- 페어프로그래밍은 온전히 자신의 페이스대로 일을 이끌어가지 못하기 때문에 상당히 고단한 정신적 활동이다. 그렇기 때문에 집중력의 유지와 업무 컨택스트가 흐트러지는 것을 막기 위해 당일에 소화할 수 있는 단위로 자르는 것을 추천한다.
- 우리의 기술 수준은 비대칭적이며 각자의 지식 기반과 취향에 따라 함수나 클래스, 변수의 이름을 짓는 방법도 제각각이다. 둘이 함께 코딩을 할 때 이런 부분에서 논쟁으로 시간을 허비하면 안된다. 더 나쁜 케이스는 코딩 중 합의를 하지 못해 페어프로그래밍을 중단하는 것이다. 그럼 처음부터 혼자 작업하고 코드 리뷰를 받는 편이 서로 감정도 상하지 않고 진행 속도도 더 빨랐을 것이다.
- 2번과 같은 맥락이다. 페어프로그래밍의 최종 단계인 코딩을 시작하기 전에 최대한 논쟁 거리를 제거해야만 한다.
- 지식 수준과 구현에 필요한 내용을 충분히 합의하지 않는다면 후술하게 될 부작용이 나타나게 된다. 이 과정을 제대로 마치지 못했을 때 어떤 상황이 발생하는지는 따로 설명하겠다.
- 운전자는 코드 작성에 집중하고 항해사는 합의된 내용을 지키고 있는지 코드에 버그가 없는지를 확인해야 하기 때문에 코딩 중 다른 문서를 보거나 spike를 할 여유 따위는 없다. 타인이 지켜보는 코드를 짜는 운전자와 타인의 코드를 실시간으로 읽으며 점검하는 항해사 모두 매우 큰 집중력을 필요로 한다. 특히, 항해사는 절대 딴짓하면 안된다.
- 시간 배분은 상황에 맞게 조절하면 된다. 막힘없이 코딩이 진행되고 있는지 계속 신경을 쓰고, 흐름이 계속 끊긴다면 코딩을 중단하고 상황을 점검해야 한다. 흐름이 끊긴다는 것은 충분히 준비되지 않았다는 것이다.
- 만약, 1~4의 활동으로 충분한 준비가 되었고 코딩 컨벤션이나 여러 가지 그라운드 룰이 잘 되어 있다면 10분은 괜찮은 휴식 시간이 될 것이다. 그렇지 않다면 별도의 휴식 시간을 갖도록 하자.
- 페어 프로그래밍이 잘 안 될 때 나타나는 부작용
- 운전자는 열심히 코딩하지만, 항해사는 뭐가 진행되고 있는지 모르고 멍때리고 있다. 이와 같은 부작용은 두 사람의 작업 이해도 차이가 매우 클 때 나타난다. 주니어와 시니어 같이 기술적 경험 차이 때문일 수도 있고, 기존 구성원과 신규 입사자와 같이 도메인 이해도 차이 때문일 수도 있다. 어쨌든 문제의 핵심은 페어프로그래밍을 하면 자연스럽게 지식이 전달되고 상대방의 이해도가 올라갈 것이라고 착각하는데 있다. 하지만, 상황은 전혀 그렇지 않다. 항해사의 임무는 운전자의 실수를 보완하는 것이지 운전자의 코딩을 통해 학습하는 것이 아니다. 항해사가 운전자의 코딩을 실시간으로 따라갈 수 없다고 해서 빈번하게 코딩을 중단시키고 하나하나 물어볼 수는 없다. 그래서는 운전자가 코드를 몇 줄 짜지도 못한다. 결국 항해사는 자신의 존재 이유를 찾지 못하고 영혼이 탈출해 버린다. 운전자가 짜는 코드를 이해하지 못하는데 코드 품질을 더 향상시킬 수 있다는 기대는 비현실적이며, 항해사가 운전자로 역할을 바꾸게 된다면 자신이 이해하지 못한 코드를 이어 받아 계속 구현을 진행할 수 있을리가 없다.
- 항해사가 처음부터 끝까지 지시를 내리며 운전자는 받아 적는 타이핑 머신이 되어 있다. 이 상황은 1번에서 운전자와 항해사가 역할을 바꾸었을 때 나타난다. 처음에는 룰에 따라 운전자가 코딩을 하고 항해사는 서포트를 하려고 하지만, 항해사가 보기에는 시작부터 문제들이 보인다. 그럼 하나하나 지적하게 되고, 운전자는 위축되고 자신이 바보처럼 보이고 있다는 공포를 느낀다. 얼마 지나지 않아 항해사는 운전자가 스스로 코딩할 상황이 아니라고 판단하고 한줄한줄 작성할 코드를 말해준다. 그리고 운전자는 그 코드를 받아 적는다. 평범한 뇌는 타인의 코드를 정확하게 받아 적는 것과 그 코드를 곧바로 이해하는 두 가지 정신적 활동을 동시에 하기 힘들다. 특히 위축되고 불편함이나 공포심을 느끼는 상태라면 더더욱 그렇다. 이 상황에서 지식의 확산이 이루어질 것이라는 기대는 부질없다. 결국 항해사가 혼자 하면 될 것을 운전자의 귀중한 시간을 낭비하고 부정적 감정만 심어주는 결과를 얻을 수 있다.
- 결과물이 나오지 않았는데 페어가 나머지는 알아서 마무리하라며 페어프로그래밍을 마무리해 버린다. 이 경우는 정확한 설계와 결과에 대한 합의가 없이 페어프로그래밍을 시작했을 때 발생한다. 우리는 항상 대충 머리를 굴려보면 이렇게 하면 될 것 같다는 상이 떠오른다. 하지만, 간과하는 것은 대부분 실제로 실행해보면 디테일이 상당히 다르다는 점이다. 이 상황은 대부분의 경우 해당 이슈 티켓에 오너가 아닌 사람(보통 시니어)이 주니어의 업무 진행을 답답하게 느껴 페어프로그래밍을 제안한 후 실제로 해보니 옆에서 봤던 것 만큼 간단한 문제가 아님을 알고 황급히 손을 떼게 될 때 자주 발생한다. 이 상황이 반복되면 페어프로그래밍 요청자는 신뢰를 잃게 되고, 상대방은 페어프로그래밍을 자신의 일을 방해하는 도구로 불신하게 된다. 페어프로그래밍에서 설계를 합의해야 하는 이유가 이와 같은 상황을 방지하기 위함이다.
- 강제로 이슈티켓과 페어프로그래밍을 묶어버리면 일을 하는 사람만 하거나 일이 끝나지 않는다. 이는 페어프로그래밍 중 가장 잘못된 상황이라고 본다. 상황과 목적에 맞춰 써야하는 도구를 프로세스의 필수 요소로 강제해 버리면 업무 진행의 유연성을 잃게 되기 때문이다. 일을 완수해야 하는 책임이 둘로 나뉘게 되면 새로운 일에만 흥미를 느끼는 사람이 다른 사람에게 일을 미루거나 둘 모두 서로 알아서 하겠지라는 안일한 생각으로 결국 일이 좌초하는 상황이 발생할 수 있다. 우리는 항상 모든 일에는 한 명의 책임자가 있어야 하며 그 일에 대해서는 전적으로 책임자의 권한을 존중해야 한다는 것을 명심해야 한다. 페어프로그래밍이 문화와 프로세스의 일부로 강제되면 책임의 소재가 모호해지거나 책임자의 권한을 함부로 침해하게 될 수 있다.
|
|
