안녕하세요. 현재 뉴닉에서 백엔드 엔지니어로 일하고 있는 윌리 👀 와 젠 🌏 입니다. 각각 입사한 지 1년, 6개월이 되었어요. 올해 1월에 런칭한 뉴닉 iOS 앱과 안드로이드 앱, 그리고 뉴닉 웹사이트를 지탱하는 서버를 단단히 만들고 있습니다.
뉴닉 개발팀은 어떻게 일하고 있을까 시리즈 1편: <뉴닉은 페어 프로그래밍으로 일합니다>
뉴닉 개발팀에서는 페어 프로그래밍을 적극적으로 도입해서 실무에서 활용 중입니다. 벌써 6개월째 페어 작업을 이어가고 있어요. 종종 페어를 하는 개발팀을 몇 팀 들어봤지만, 저희만큼 페어를 완전히 실무에 정착시킨 개발팀은 많이 보지 못했어요. 오늘은 저희의 일상이 된 페어 프로그래밍을 소개해보려고 합니다.
도입 배경: 어쩌다 이걸 하게 되었나?
백엔드 엔지니어 젠: “애자일 워크숍에서 배운 것을 실무에서 써보고 싶어”
젠의 얘기를 먼저 해볼게요. 젠은 작년에 국내 IT 애자일 컨설팅의 대가로 손꼽히는 김창준 님의 애자일 코치 워크숍 과정을 이수했어요. 스무 명이 넘는 동료들과 석 달간 교육과 코칭을 이수하며 다양한 주제를 맛보았는데요. 조직 내에서 협업하는 방법, 작업의 피드백 루프를 설계하는 법, 비폭력대화를 통한 갈등 해결, 야생학습을 통해 스스로 성장하는 법, 인지적 작업 분석(CTA)을 통한 상대의 전문성 끌어내기 등 애자일 방법론의 원칙을 사용해 개인과 조직을 변화시키는 방법에 대해 깊이있게 배웠어요.
젠은 개발자다 보니 그중에 페어 프로그래밍과 TDD(테스트 주도 개발) 등을 통한 개발 프로세스의 개선 과정에 특히 관심이 컸답니다. 이론에서 그치지 않고 실제로 사람들과 시뮬레이션하며 배우니 그 효능을 실감할 수 있었어요. 그때 배운 것들이 꽤 감명 깊었던 지라 실무에 애자일의 요소를 도입해보고자 하는 마음이 가슴 한켠에 생겼죠. 그러던 중 작년 말에 뉴닉의 개발팀으로 이직하게 되었고, 새로운 시도를 해볼 만한 절호의 환경을 만났습니다. 온보딩을 준비하던 윌리 덕분이었죠.
백엔드 엔지니어·개발팀장 윌리: “온보딩을 페어 프로그래밍으로 해볼까?”
윌리의 경우, 젠이 오기 전에 6개월 이상 혼자 뉴닉의 백엔드를 책임지고 있었어요. 작년 말에 젠이 입사하면서 윌리는 젠의 온보딩 과정에 대한 고민이 컸습니다. 고민 끝에 페어 프로그래밍이 떠올랐고, 온보딩 기간 동안만 페어로 작업해 볼 생각으로 젠과의 페어를 시작했어요. 시작부터 이상하게(?) 합이 잘 맞고 개발 생산성 측면에서 장점이 많아 온보딩이 끝나고 몇 달이 지난 지금까지도 계속하게 되었어요. 그 장점 중 몇 가지만 소개해볼게요.
페어로 작업해봤더니 이런 게 좋더라구요
페어로 일하면서 저희가 직접 느낀 효용은 크게 세 가지인데요.
먼저 메타인지 능력이 향상됩니다. 혼자 개발할 때 특정 버그를 만나 그 문제를 해결하려고 깊은 곳으로 빠져들어 두세 시간 넘게 헤어나오지 못한 경험들이 다들 있으실 겁니다. 혼자 작업을 하면 너비우선탐색(BFS) 방식으로 여러가지 옵션을 타진해보기가 쉽지 않습니다. 반면 다른 동료와 함께 같은 문제에 봉착하는 경우는 조금 다릅니다. 타인에게는 비교적 쉽게 비판적 사고를 견지할 수 있기 때문이죠. ‘이 부분 그만 파고 잠시 돌아나가요’, ‘여기서 잠깐 끊고 다른 방법을 시도해볼까요’, ‘이건 개발 일정에 이슈가 있을 수 있으니, 라이브러리를 더 찾아보는 것보다 PM과 먼저 사안을 공유하고 다른 기획적 방법을 찾아보는 게 어떨까요’ 같은 대화를 옆자리 동료가 먼저 해주면 쉽게 수렁에서 빠져나올 수 있습니다.
두 번째는 몰입감과 높은 생산성입니다. 혼자 작업할 때는 집중력을 오랜 시간 유지하는 것이 순전히 개인의 몫이라 쉽지 않을 때가 많습니다. 코드를 작성하다가도 잠시 팀 슬랙을 확인했다가 괜히 이메일도 체크했다가, SNS에 올라온 기술 관련 뉴스 링크를 클릭해서 열어보다가 다시 코드로 돌아와 작업을 했다가 몇분 지나지 않아 다시 슬랙을 봤다가… 하는 식으로 말이죠. 그와 달리 페어로 프로그래밍할 때는 순식간에 한 시간이 지나가버립니다. 옆에서 지켜보고 있는 동료가 있으니 딴짓할 겨를 없이 작업에 몰입할 수 있어요. 눈이 많아진 만큼 실수도 빠르게 잡아낼 수 있게 되면서 짧은 시간 내에 작업 생산성도 확연히 올라갑니다.
세 번째는 학습의 전파입니다. ‘암묵지’라는 것이 있죠. 오랜 경험을 통해 몸에 배어있는데, 말로 설명할 수 없는 지식을 말합니다. 결과물인 코드만 봤을 때는 이 사람이 어떤 생각과 과정으로 이런 작업을 했는지 알기 힘듭니다. 비동기 코드 리뷰를 통해서는 동료들 간에 암묵지까지는 공유가 쉽지 않고요. 좋은 습관과 아이디어들이 팀 내에 전파되기 어렵죠. 한자리에 모여 페어 작업을 하며 작업에 대한 논의를 진행하다 보면, 이 학습의 전파가 아주 쉽고 빠르게 진행되어 팀 전체의 생산성에 긍정적인 영향을 끼칩니다.
이 세 가지 효능은 페어 프로그래밍의 보편적 장점으로 여겨지는 요소들이랍니다. 아직 페어를 해보지 않은 개발자분들, 솔깃하지 않나요?
페어 작업 자세히 톺아보기
페어 프로그래밍을 할 때 우리의 모습은 어떨까?
저희는 작업을 할 때 쉼 없이 대화를 나눕니다. 코드를 입력하고 있지 않은 사람이라고 가만히 있는 것이 아니라, “53번 행과 54번 행 사이에 조건문을 하나 추가합시다“, “이건 이 파일 말고 아예 다른 모듈로 뺄까요” 같은 식으로 코드를 계속 팔로우하면서 의견을 제시합니다. 그리고 함수명과 변수명, 커밋 메시지까지도 한 글자 한 글자 옆에서 불러주는 식으로, 키를 잡은 사람의 부담을 함께 나눕니다.
뉴닉 개발팀의 페어 원칙 세 가지
페어를 꾸준하게 하다 보니 저희 안에서도 나름의 원칙이 생겼어요. 첫째는 중요하거나, 불확실성이 높은 작업일 수록 페어로 작업한다는 것입니다. 어려운 작업일수록 같이 한다고 생각하면 마음의 부담도 적어집니다. 일의 난이도가 높아도 혼자 할 때보다 해결의 실마리를 쉽게 찾을 수 있습니다.
두 번째는 자주 끊는다는 것입니다. 규칙적으로 브레이크타임을 가집니다. 저희는 50분 정도 작업하면 10분을 무조건 쉽니다. 단순히 물 마시고 화장실 다녀올 시간을 갖는 차원을 넘어, 주기적인 휴식은 서로 간 메타인지를 높이는 효과가 있습니다.
세 번째는 수시로 물어본다는 것입니다. 함께 작업을 하던 중에 이해가 안 되는 부분이 있거나 흐름을 놓치면, “어, 저 놓쳤어요. 이 부분은 이해가 안 되네요. 이건 OO 때문에 이렇게 된 건가요?” 같은 질문을 수시로 던집니다. 페어 작업에서 한번 포커스를 잃으면 상대와의 이해도 차이가 벌어지기 때문에 수시로 싱크를 맞추고 발맞춰 가는 노력이 필요합니다.
+) 이 세 가지 원칙은 뉴닉 개발팀의 유니크한 컬처이긴 하나, 애자일(Agile) 방법론에서 많이 차용해왔답니다.
원격으로도 가능한 페어
페어 작업을 시작한 초기 몇 달 간은 사무실에 있는 작은 회의실을 개발팀 아지트로 삼아 작업을 했습니다. 서로 말을 계속해야 하다 보니, 동료들이 일하고 있는 오픈된 책상보다는 소음이 차단되는 조용한 회의실이 필요하더군요. 그러다가 백엔드 개발자 중 한 명이 코로나19에 확진되면서 원격으로 근무하게 되었고, 그렇게 원격 페어가 시작되었습니다.
그전까지는 같은 공간에서 해야 페어가 더 잘 될 거라는 막연한 인식이 있었는데요. 직접 해보니 원격으로도 페어 프로그래밍이 잘 되더라구요. 구글 행아웃의 화면 공유 기능뿐만 아니라, VScode의 Live Share나 인텔리제이(IntelliJ)에서 지원하는 ‘코드 위드 미(Code With Me)’, 노션 공동 편집 등의 기능을 활용했습니다. 원격 환경에서 함께 작업할 수 있는 플랫폼도 최근 많이 늘어나고 있고요.
원격 페어에는 두 가지 장점이 있습니다. 오디오와 작업 스크린에 집중하게 되니 코드가 눈에 더 잘 들어옵니다. 또, 사무실에서 페어할 때는 한 번에 한 사람이 키보드를 잡게 되는데 원격 페어일 때는 동시 편집도 가능합니다. 다만 동시 편집의 편리함에도 불구하고 페어 프로그래밍 중에는 가급적 한 번에 한 사람이 편집하는 걸 더 추천합니다. 포커스를 일치시키는 데 도움이 되거든요.
페어, 과연 프로그래밍에만 적용될까?
애자일 구루 김창준 님도 그렇게 말씀하셨죠. “페어의 장점을 알게 되면, 모든 것을 페어로 하고 싶어질 것이다.” 그 말이 상당히 공감됩니다. 저희는 API 문서도 페어로 작성합니다. 그뿐 아니라 셀 차원의 공지나, 기술블로그도 페어로 작성하고 있습니다. 일을 시작하는 부담도 줄고, 짧은 시간 내에 알찬 결과물이 나오기 때문입니다.
함께하는 인원도 다양해지고 있어요. 근래 들어 백엔드 팀원뿐 아니라 프론트엔드 팀원들과도 페어 프로그래밍을 자주 하고 있습니다. 이런 걸 몹 프로그래밍(Mob programming)이라고 하더군요. 많을 때는 프로덕트 디자이너까지 다섯 명이 참여한 적도 있었습니다. 서로의 목소리를 자주 듣는 만큼 그 틈에 개발 프로세스에 대한 논의도 자주 하게 됩니다. 공유하는 것들이 늘어나면서 팀 내 커뮤니케이션이 풍부해지는 느낌도 받습니다. 개발 작업 자체도 더 재밌어졌어요.
페어할 때 우리가 자주 하는 말들
여기까지 읽어주시느라 고생하셨습니다. 마지막으로 재밌는 것 하나를 보너스로 보여드릴게요. 저희가 페어를 할 때마다 자주 하는 말들을 모아봤어요. 쓰다 보니 저희도 웃음이 나오더군요. 생생한 현장감을 살짝 맛보기로만 전해드립니다. 출발해볼까요?
“페어 기차 출발합니다”
구글 캘린더에 미리 페어 스케줄을 등록해놓는데 저희끼리 우스갯소리로 ‘페어 기차 탄다’라는 표현을 써요. 그 시간에 되어 슬랙에 기차 출발한다고 말하면 우르르 탑승하죠. 장시간의 페어는 꽤 멀미 난답니다. 손잡이를 꽉 잡으셔야 돼요.
“노션 링크 다들 들어오셨나요?”
시작할 때 작업 문서를 다 같이 보면서 이번 작업의 목적과 상세 내역을 함께 싱크 맞춥니다. 노션 문서는 동시에 편집이 가능해서 각자의 작업 체크리스트를 관리하기에도 편리합니다.
“LiveShare 링크 좀”
원격으로 페어할 때는 VScode 라이브쉐어나 InteliJ의 코드위드미 같은 실시간 원격 개발 환경을 이용할 때가 있는데요. 키를 잡은 사람이 본인의 작업 환경에서 링크를 만들어 다른 동료에게 전달해줍니다. 그 링크를 타고 들어오면 같이 소스코드를 편집할 수 있게 되죠.
“어… 이거 변수명 뭘로 할까요?”
집단지성의 힘이 발휘되는 순간입니다. 변수명, 함수명 등 요소들의 이름을 짓는 것이 개발 업무의 최대 병목(?)인데요. 여러 사람의 머리가 합쳐지면 더 적절한 이름을 더 빠른 시간 내에 지을 수 있답니다.
“OO (동료의 이름) 오라고 할까요?”
작업을 하다 보면 의사결정이 필요할 때가 많아요. 프로덕트 매니저에게 기획 디테일을 체크해야 할 때도 있고, 프론트엔드 개발자에게 어떤 형태로 API를 전달하면 좋을지 논의해야 할 때도 있고요. 피그마 파일에서 이해가 안 된 부분을 프로덕트 디자이너에게 문의해야 할 때도 자주 있습니다. 이때 저희는 당사자에게 메시지를 보내 괜찮은 시간에 페어 기차에 탑승(?)해달라고 합니다. 작업 문서와 코드를 화면으로 보며 논의하면 서로 이해도 잘 되고, 덕분에 의사결정도 빠르게 이뤄질 수 있더라구요. 동시성의 장점을 최대한 활용하는 셈입니다.
“잠깐 끊었다 할까요? 10분 뒤에 뵈어요”
페어의 세 가지 원칙에서도 적었지만, 중간중간 브레이크는 페어의 필수입니다. 휴식 시간을 통해 몸도 쉬면서 잠시 정신을 환기할 수 있어요. 메타인지를 확보하는 데에도 큰 도움이 되죠. 저희는 이 휴식 시간을 꼭 사수하려고 합니다.
“아 커밋하기 전에 Co-author 넣어주세요”
커밋 메시지 작성할 때, Co-author (공동 작성자)를 추가하면 깃헙에 여러 명이 동시에 contributor로 등록돼요. VScode 등 여러 IDE는 이를 저장해두는 기능을 지원합니다. 같이 작업하고 같이 기록을 남길 수 있어서 정말 좋은 기능입니다.
어때요? 저희 팀의 목소리가 들리는 것 같지 않나요? 😉 그렇게 오늘도 뉴닉의 페어 기차는 열심히 달리고 있습니다 🚄.
채용합니다
저희 팀에 관심이 생기셨나요? 지금이 기회입니다. 뉴닉 제품팀에서 현재 채용을 진행 중입니다. 뉴닉 제품팀에서 함께 성장하고 싶은 분이라면 주저하지 말고 지원해주세요!
