TIL: 코드스테이츠 백엔드 부트캠프 5일차 - 페어프로그래밍

오늘은 하루 종일 페어프로그래밍을 했기 때문에 TIL은 회고 형식으로 남겨볼까 한다.

220429_TIL

---

오늘은 하루 종일 페어 프로그래밍을 진행했다. 처음 경험한 페어 프로그래밍의 여운이 가시기 전에 회고 형식으로 TIL을 남겨볼까 한다.

1. 준비

---

얼마 전에 유튜브에서 강형욱 님이 나오는 방송 클립을 본 적이 있다.
뼈를 엄청 좋아해서, 뼈를 뺏으려고 하면 공격성을 드러내는 강아지였다. 제일 좋아하는 간식을 줘도 뼈만 가져가려고 하면 짖고 물었다.

강형욱 님이 잠시 개와 함께 시간을 보내면서 관찰하다가, 주인에게 이렇게 말을 했다.

'ㅇㅇ이'는 뼈를 좋아하는 게 아니에요. 뼈를 뺏기는 걸 싫어하는 거에요.

강형욱 님은 곧장 뼈를 뺏지 않고, 뼈 옆에서 'ㅇㅇ이'와 함께 놀다가, 조금 옆에 가서 놀다가, 다른 곳에 가서 놀았다. 뼈는 마룻마닥 한 구석에 남아있었고 잠시 후 돌아온 강형욱 님이 집어서 치웠다. 'ㅇㅇ이'도 같이 있었지만 별로 신경쓰지 않았다. 'ㅇㅇ이'는 정말로 뼈를 좋아하는 게 아니었다.

페어프로그래밍을 앞두고 나는 내 급한 성격이 염려가 되었다. 머릿속에서 답을 찾으면 곧장 실행해봐야 직성이 풀리는 성격. 혼자 있을때야 '나쁘게 말하면 성급한거고, 좋게 말하면 실행력이 좋아'라고 말할 수 있지, 누군가와 같이 있으면 그냥 성격 급한 사람일 뿐이었다(그래서 일상생활 속에서도 계속 교정하는 중이고).

'페어 과제를 미리 풀어볼까?'
'난 풀어봤는데 상대가 하나도 모르는 상태면, 더 답답하게 느껴지려나? 그럼 아예 미리 보지 말까?'
'회사 일도 아니고 학습인데, 꼭 목표 달성에 목을 매야 할까?'

생각이 마지막 줄까지 다다르니까('결과물에 집착할 이유가 전혀 없는데?'), 내가 마치 'ㅇㅇ이'처럼 불안해하고 있다는게 느껴졌다. 결과에 집착하지 않는데, 결과를 망칠까봐 걱정할 이유가 뭐란 말인가!
스스로가 좀 우스워져서, 단순하게 생각하기로 했다.

과제는, 궁금하니까 미리 풀어보자. 궁금한건 해결해야 하니까.
그리고 페어프로그래밍은, 결과가 중요한 게 아니니까 결과는 전혀!! 신경쓰지 말자.

그렇게 결심을 세우고 나니 마음이 좀 가벼워졌다.
이런 류의 불안감를 버리는 데에 늘 도움이 되는 리사손 님의 영상도 두 번이나 보았다(리사손님의 강연들은 정말 좋다, 언제 한 번 책과 함께 소개해보고 싶다).

2. 경험

---

아이스브레이킹은 특별히 준비하지 않았다. 첫 만남에서 어색한 연기는 안 하느니만 못하니까.

대신에 오늘 진행하면서 팁이 될만한 것들 몇 가지를 준비해서(사용하는 도구들의 숏컷이라든지), 필요한 게 나올 때마다 하나씩 알려드렸다. 다행히 신기하고 좋아하셨다. 이미 아는 건데 나때문에 좋아해주신거라면, 감사하다(???...ㅋㅋㅋ).

어쨌든.
우리 페어는 같은 회사에서 일을 하고 있거나, 같이 한참 교육을 진행해서 서로 암묵적으로 통하는 컨벤션 같은게 전혀 없기 때문에, 프로토타이핑을 컨벤션처럼 삼기로 하고 와이어프레임을 짜는 데에 시간을 좀 많이 들였다. 네비게이터도 드라이버도 경험없는 사람들이기 때문에(무면허), 마구잡이로 시작했다간 주차 한 번 하자고 전진과 후진을 수없이 반복해야할 것 같았기 때문이다.
와이어프레임을 짜면서 서로 노하우를 나누거나, 서로 놓친 부분들을 노티해주면서 보완했는데, 이 내용들은 따로 정리해서 올리겠다.

어쨌든 해당 전략은 아주 성공적이었다.
우리는 9시에 만나서 9시 반쯤 시작했는데 11시가 조금 넘어서 한 페이지의 구현이 끝났다.
네비게이터/드라이버 역할을 바꾼 오후 시간에는 박스모델을 재배치하고, 디자인 요소를 더했다. 페어님과 나의 미적 감각이 망했을 뿐, 충분히 꾸몄다. 나는 페어님께 뼈속부터 개발자라는 의미로 뼈발자라는 별명을 붙여드렸다. 웹 개발에서 디자이너의 역할은 매우 중요하다.

편의 기능을 위한 스크립트도 조금 첨가했는데, 잘 동작하다가 발표할 시간 쯤 되어서 갑자기 동작을 멈춰서(ㅋㅋㅋ) 발표는 하지 못했다. (근데 끝나고 나서 눌러보니까 또 됐다. ㅋㅋㅋㅋ)

정리하자면,

1. 학습 목적의 페어프로그래밍은 결과에 집착할 필요가 전혀 없다. 설령 과제를 제출해야 한다고 할 지라도!
2. 커뮤니케이션의 시작은 합의점을 찾는 것이다. 일치하는 지점을 만들어놓지 않으면, 겉보기엔 서로 잘 대화중인 것 같지만 각각 다른 이야기를 하고 있는 건지도 모른다(그렇게되면 그 페어는 어딘가 산에 오르다가 중턱쯤에서 깨닫게 되겠지).
3. 네비게이터와 드라이버의 역할에 치중할 필요도 없다. 서로 의견을 세우면서 난잡해지면 안된다는 의식, 그 생각만 저변에 깔려있으면 충분하다. 우리도 네비게이터와 드라이버를 명확히 구분하지 않았지만, 수시로 의견을 빠르게 주고 받을 수 있도록 합의하고 진행한 터라, 오히려 빠르게 결과를 만들 수 있는 기반이 되었다.
4. 잘한 점: 서두르지 않고 경청하려고 노력했다. 디테일한 와이어프레임 제안한 것. / 보충할 점: 경직된 것보다는 자유롭게 아이디어를 낼 수 있도록. / 아직 궁금한 점: 확고하게 정답이라고 생각하는 부분에 대해 더 나은 방식을 제안할 수 있는 방법은 무엇이 있을까? / 과감히 버릴 점: 도 아직 잘 모르겠다.
5. 강형욱 님은 위대하다. 디자이너도 위대하다.
6. 설령 망한 페어 경험이라도 괜찮을 것 같다. 페어 프로그래밍에서 얻을 수 있는 건 말 그대로 '경험'인 것 같으니까.

---

즐거운 경험이었습니다.
이 경험이 즐거울 수 있도록 노력해준 오늘의 페어, 뼈발자 쫑쫑님께 진심으로 감사드립니다.