짝프로그래밍을 통해 자라기
프로그래밍을 ‘함께’ 할 수 있을까요? 커다란 시스템을 여러 개의 작은 부분으로 나눠서 각자 개발하는 분업 방식 이상으로 협업을 하는 것이 가능할까요?
딥네츄럴에서는 짝 프로그래밍을 활발하게 실천하고 있습니다. 짝 프로그래밍을 하면서, 아래와 같은 소감이 나오기도 하는데요.
이런 식의 접근은 처음 해봐요. 생각의 전환을 하게 된 새로운 경험이었어요.
나름대로 TDD를 실천해오고 있다고 생각했었는데, 짝 프로그래밍을 해보니, 제가 그 동안 엉터리로 해오고 있었구나 하는 생각이 드네요.
어떤 일이 있었던걸까요?
짝 프로그래밍과 사고 과정
실제로 짝 프로그래밍을 해보니, 이런 것들을 배우게 됩니다.
우선, 상대가 어떤 사고 과정을 거쳐서 프로그래밍을 하는지 엿볼 수 있습니다.
팀에 전문가나 시니어가 있어서 함께 일을 하는 경우에라도, 보통은 그들의 결과물만을 보고 감탄하거나 동경하는데서 그치곤 합니다. 또는 그 결과물에 담긴 품질을 목표로, 나는 어떻게 저렇게 할 수 있을까 노력하기도 합니다.
하지만 전문가는 많은 경우 초심자와 멘탈 모델이 다릅니다. 전문가는 초심자가 보지 못하는 단서(cue)들을 볼 수 있고, 다른 전략(strategy)을 사용합니다. 때문에 초심자가 자신의 멘탈 모델 안에서 노력하더라도, 전문가의 결과물만을 들여다봐서는 전문가가 그 결과물을 만들어내기 위해 사용한 사고 과정이나 멘탈 모델을 파악하기 어렵습니다.
그런데, 짝 프로그래밍을 할 때는 그 사고 과정을 엿보기가 훨씬 쉬워집니다. 만들어가는 과정을 실시간으로 함께 하기 때문입니다. 그 과정에서 전문가가 어떻게 생각하는지, 어떤 것을 알아채는지, 어떻게 접근해가는지를 파악할 수 있고, 훨씬 효과적으로 학습할 수 있습니다.
팀에 전문가나 시니어가 없더라도, 또는 짝을 꼭 주니어-시니어로 맺지 않더라도, 짝끼리 서로 다른 접근법, 다른 노하우, 다른 강점을 가지고 있을 수 있기 때문에, 서로 배우는 일이 생깁니다.
그러면, 전문가나 시니어 입장에서는 어떤 점이 좋을까요? 시니어는 그냥 봉사만 하는 것일까요?
전문가 입장에서는, 짝과 같이 프로그래밍을 하면서 자신의 접근법에 대해 좀 더 명확한 이해를 할 수 있게 됩니다. 마치, 빠른 기차를 타고 갈 때는 미처 인식하지 못하던 풍경이 찬찬히 자전거를 타고 갈 때는 보이는 것처럼, 자동적이고 무의식적으로 행하던 접근방법, 알아채던 단서들을 하나씩 찬찬히 조망하게 되면서 의식의 차원으로 끌어올릴 수 있습니다. 그렇게 의식의 차원으로 끌어올려진 노하우, 기술, 전문성, 멘탈 모델은, 이제 이야기되고 발전시키고 가르쳐질 수 있는 것이 됩니다.
마틴 파울러가 쓴 ‘리팩토링’ 책을 읽다보면, 마틴 파울러가 자신의 멘탈 모델, 접근 방식, 전략들을 조망하면서 발견하여 정리한 것이라는 것을 알 수 있고, 그래서 경험에 기반한(theory-in-use) 실용적이고 구체적인 조언들이 많이 들어있습니다.
나는 안전하고 효율적으로 리팩터링하는 방법이 잘 기억나지 않을 때 언제든 다시 찾아볼 수 있도록 노트에 정리해뒀다. … ‘절차’는 오랜만에 적용하는 리팩터링의 구체적인 단계를 잊지 않도록 개인 노트에 기록해둔 것이다.
짝 프로그래밍을 하면서, 나는 당연하다고 여겼던 것들이 짝에게는 당연하지 않다는 것에 새삼스럽게 놀라곤 합니다. 나는 별 감흥이 없었던 것들을 짝이 보고 ‘우와, 이렇게 접근할 수도 있군요!’라고 발견해주면, 그게 다른 사람에게도 당연한게 아니라 나에게 쌓여서 계발된 전문성의 요소라는 것을 깨닫게 됩니다.
짝 작업의 사례 #1
언젠가 했던 짝 프로그래밍이 기억납니다. 짝이 이미 작성한 함수가 있었는데, 그 코드가 썩 마음에 들지 않으나 어떻게 고쳐야 할지 모르겠다고 했습니다. 작성된 코드를 보니, if-else-elseif가 여러번 중첩된 코드였습니다.
코드를 개선하기 전에, 그 함수에 대한 단위 테스트 코드가 있는지 짝에게 물어보았습니다. 그분이 TDD를 실천하려고 노력하고 있다는걸 알고 있었거든요. 그런데, 아직 테스트 코드를 작성하지 않았다고 하더군요.
그래서, 우선 현재 동작 기준으로 테스트 코드를 작성하는 것부터 시작했습니다. if-else-elseif로 짜여진 로직을 여러 분기에 대해 어떻게 테스트하면 좋을지 고민하기 시작하니, 신기하게도 로직을 구조화할 아이디어가 테스트 코드에서부터 드러나기 시작했습니다.
일단 테스트 코드가 만들어지니, 기존 동작을 유지하며 원래 함수를 뜯어고치는 작업을 자신있게 할 수 있게 되었습니다. 처음에는 완성된 코드가 어떤 모양일지 상상이 가지 않았는데, 짝과 함께 주거니 받거나 하며 함수를 개선하면서 완성된 모습을 보니, 저도 짝도 기대했던 것 이상으로 우아하게 정리된 코드를 얻게 되었습니다.
짝 프로그래밍을 마치고 회고를 할 때 이런 얘기가 나왔습니다.
TDD를 책으로 읽고나서 나름 실천해오고 있다고 생각했는데, 직접 보니 ‘엉터리로 하고 있었구나’라는 생각이 들었어요. 코드 작성과 테스트 작성의 간극이 훨씬 더 짧아야 한다는걸 깨달았어요.
반대로 저도, 혼자서 코드를 작성했다면 어느 지점까지 하고 개선을 멈추었을겁니다. 그런데 짝 작업을 하면서 서로 이야기를 나누다 보니, 그것 이상으로 더 개선할 수 있는 여지가 있다는 것을 발견할 수 있었고, 항상 멈추곤 하던 그 너머까지 더 갈 수 있었습니다.
짝 작업의 사례 #2
서로 다른 분야의 사람들이 짝 프로그래밍을 하는 것도 가능할까요? 백엔드를 오랫동안 개발해온 제가 웹프론트 엔지니어분과 웹프론트 코드를 가지고 짝 프로그래밍을 한 적이 있습니다.
짝은 웹프론트 개발을 할 때, UI부터 접근하면서 퍼블리싱부터 하곤 했습니다. 저는 백엔드를 12년 가량 해왔기 때문에 도메인이나 데이터 모델, 비즈니스 로직부터 생각하는 경향이 있습니다. 그리고 백엔드 코드는 테스트 커버리지가 87% 정도를 유지하고 있습니다.
짝과 논의하면서 이번에는 항상 하던 방법 대신, 도메인 모델부터 만들어가보기로 했습니다. 도메인 모델은 가능하면 순수한 자바스크립트 로직으로 작성하고 Vue.js 같은 웹 프레임워크와 엮이지 않도록 했습니다. 그렇게 도메인 모델을 작성하여 데이터 처리, 이벤트 핸들링 등에 필요한 코드를 순수 자바스크립트 로직으로 작성한 후에, 단위 테스트를 붙여 동작을 확인했습니다. 그리고 Vue.js 컴포넌트에 도메인 모델을 붙여서 화면에서 발생하는 이벤트나 동작을 연결하도록 했습니다.
1시간 가량의 짝 프로그래밍이 끝나고 나서 회고를 할 때 이런 얘기가 나왔습니다.
이런 식의 접근은 처음 해봐요. 생각의 전환을 하게 된 새로운 경험이었어요. Spring을 할 때는 MVC 패턴을 사용한 적도 있었지만, Vue.js에서 이런 접근을 할 수 있을거라고는 생각을 안해봤어요.
코드 리뷰
협력적인 개발을 위한 활동으로 코드 리뷰도 많이 합니다. 요즘에는 GitLab의 pull request 기능을 통해 댓글을 주고받기보다는, 가급적 실시간으로 함께 대화하면서 진행하는 방식으로 코드 리뷰를 하려고 노력합니다.
코드 리뷰와 짝 프로그래밍은 약간 다릅니다. 짝 프로그래밍은 누가 이미 만들어 놓은 것을 리뷰하는게 아니라, 같이 만들어간다는 데 무게가 더 실려 있습니다.
물론, 누가 만들어놓은 것에서 출발해서 짝 프로그래밍을 하는 경우도 있습니다. 그런 경우에는 구조나 로직을 더 개선하는 일이 일어나곤 합니다. 또는, 버그가 발생했을 때 짝 프로그래밍을 통해서 같이 해결하기도 합니다.
딥네츄럴에서는 이렇게 개발자들에게 숨겨져 있는 전문성을 계발하며 실력을 갈고닦기 위한 많은 활동들을 하고 있습니다. 아래와 같은 내용들을 더 읽어보세요:
- 협력적으로 책 읽기: 같은 시간을 들여서 5–6배 더 많은 양을 읽기
- 동료들로부터 효과적으로 배우기: 동료들로부터 ‘잘’ 배우기
딥네츄럴은 더 나은 개발 문화를 고민하며 만들어가고 있습니다. 저희와 함께 하실 미래의 크루들을 찾고 있습니다.
웹프론트엔드 개발자에 지원해보세요.
