다른 표준시간대 다국적 개발팀에서 원격으로 일하는 법

우리팀은 모바일 개발자 9명으로 이뤄져있고 출신국이 정말 다양하다. 대한민국, 중국, 인도, 벨라루스, 이탈리아, 방글라데시 6개 국가에서 모였는데 비슷한 규모의 팀 중 사내에서도 손에 꼽히는 다양성인 것 같다. 원래는 모두 싱가폴이 근무지인데, 코로나로 인해 국가간 여행이 제한되기 직전 모국으로 휴가를 갔던 동료들이 여태 돌아오지 못했다. 그래서 팀원 두 명은 인도와 벨라루스에서 재택 근무를 하고 있다. 애초에 싱가폴 직원은 전부 재택 근무 중이기 때문에 크게 다를바가 없어 보였지만 시간대가 다르기 때문에 업무 방식에 변화가 생길 수 밖에 없었다. 생전 처음 원격으로 근무하랴, 시간대가 다른 팀원들과 협업하랴 정신없이 보내다가 이제 어느정도 안정적인 업무 방식을 찾은거 같다.

1. 시차 고려해서 메시지 보내기

미팅 시간을 잡을 때는 당연히 시차를 고려하게 된다. 두 시간 반 느린 인도 지사에 개발자가 많이 있기 때문에 평소에도 미팅은 오후에만 잡는 것이 생활화 돼있었다. 하지만 몇 달 업무를 해보니 채팅도 시차에 맞춰서 보내는 편이 좋다는걸 알게됐다. 처음에는 ‘메시지 보내놓으면 출근해서 보고 답장을 주겠지’ 라고 생각하고 내 편의에 맞춰 메시지를 보냈다. 그러다보니 상대방이 답장을 안주면 나도 잊어버리고 나중에 메시지를 다시 보내야하는 일이 잦았다.

생각해보니 나같은 사람이 많다면 메시지를 받는 사람 입장에서는 출근하자마자 메시지가 많이 와있을테고, 묻히는 메시지가 생겼을 것이다. 이제는 상대방 업무 시간에 맞춰서 메시지를 보낸다. 그랬더니 답장을 더 빨리, 확실하게 받을 수 있게 됐다. 이걸 잘하기 위해 쓰고 있는 도구가 두 개 있는데 하나는 맥 상태바에 여러 시간을 볼 수 있는 간단한 앱이고 다른 하나는 슬랙 리마인드 기능이다. 슬랙에서 특정 메시지에 알람을 걸어놓을 수 있어서 상대방 출근시간 즈음 맞춰놓으면 까먹지 않고 관련 내용을 참고해서 메시지를 보낼 수 있다.

👇 상태바에 여러 시간 표시해주는 맥 앱. 인도와 두시간 반, 벨라루스와 다섯 시간 시차가 있다.



👇 슬랙에 있는 메시지 리마인더 기능

2. 팀원 출근시간 전에 코드리뷰 남기기

서로의 업무에 가장 직접적으로 영향을 주는게 코드리뷰다. 일정 인원의 승인을 받아야만 마스터 브랜치에 병합할 수 있고 CI 작업이 두시간이나 걸리기 때문에 MR을 올리고 코드 리뷰를 받고 수정하고 승인을 받고 병합하는데에만 최소 반나절, 길게는 2~3일이 걸리기도 한다. 시차가 5시간인 벨라루스에서 일하는 팀원과 리뷰를 주고 받을때 특히 신경써야 했다. 리뷰가 늦어지면 코드 병합이 하루 이틀 더 늦어지기 십상이었다. 예를 들어 내가 오후 느지막이 리뷰를 남기고 퇴근을 하면 벨라루스 팀원은 댓글을 보고 코드를 수정하거나 아니면 의견을 댓글로 남긴다. 내 시각으론 밤 늦게거나 새벽이라 다음날이 돼야 확인할 수 있다. 그런데 내가 다음날에도 퇴근 직전에 MR을 검토하면 팀원의 두번째 응답은 또 그 다음날 확인할 수 밖에 없다. 이렇게 댓글이 한 두번만 오고가도 이틀이 지나가버린다.

그래서 이제는 출근하면 가장 먼저 MR부터 확인한다. 내가 아침에 의견을 남겨 놓고 다른 일을 하다보면 오후에 팀원이 출근해서 확인하고, 당일에 한번 더 대화가 오고갈 수 있다. 합의가 빠르면 승인까지 할 수 있고 그날 병합을 할 수도 있다. 단지 서너 시간의 차이로 코드 병합이 하루 단위로 늦춰질 수 있다는걸 생각하면 업무 순서를 조정하는건 쉬운 일이다. 의식적으로 하다보니 습관이 들었다.

3. 1대1 또는 소규모 통화 하기

원격 근무를 하면 의사 소통이 예전만큼 활발하지 않다. 옆자리에 있었더라면 쉽게 대화를 시작했을 텐데 이제는 대답을 기다려야 해서 간단한 대화나 잡담이 힘들다. 그런데 소소한 대화의 중요성을 요즘 부쩍 느끼고 있다. 동료와 친밀감을 쌓을수도 있고 개인 업무에 직접적인 도움을 받기도 하고, 외국 생활에 필요한 정보를 주고 받기도 한다. 원격 근무 때문에 대화도 의도적으로 하지 않으면 교류가 너무 없다. 보통 줌 미팅에 들어가면 사람들이 다 모이기 전까지 시간이 약간 빈다. 자투리 시간에라도 인사를 나누고 근황을 묻는다.

별도로 시간을 마련하면 더 좋다. 최근에 큰 프로젝트를 끝낸 후 그 동안 배운 것들을 정리하고 팀의 지식으로 남길겸 문서를 만들었고, 팀원들에게 앞으로의 방향을 제안하고 아이디어를 공유하는 시간을 두어 번 가졌다. 긴 시간은 아니었지만 다른 팀원들의 의견을 다양하게 들어볼 수 있었고, 무엇보다 미팅 이후에도 관련 주제로 기술적인 논의가 계속 이어지는 것을 봤다. 그리고 업무 미팅과 달리 정보 공유차 부담없이 모이면 다양한 얘기가 오고간다. 그러는 와중에 새로운 주제가 떠오르기도 했고 서로의 문제를 해결해주기도 했다.

원격 근무하는 현 상황은 주니어 개발자에게는 특히 더 어려운 시기같다. 쉽게 도움을 요청할 수 있는 사람이 옆에 없어서 힘들 것 같다. 기회가 있을때 1대1 통화로 도움을 주고는 있지만, 예전보다는 많이 부족하지 않나 싶다. 주니어 개발자라면 더 적극적으로 도움을 요청하고, 시간을 잡아서 통화를 하는 등의 노력을 해서 다른 개발자들과 접촉을 더 늘려야 할 것 같다.

앞으로

우리팀 사무실의 임대차 계약이 만료됐는데 연장을 안했다고 한다. 아무래도 내년 중순 쯤 완공될 사옥에 입주하기 전까지 이런 근무 형태가 계속될 예정이다. 코로나로 인한 여행 제한, 이동 제한, 만남 제한 때문에 여러모로 힘들고 업무 방식도 급변해서 쉽지 않지만 이런 상황 속에서 더 행복하고 지속 가능하게 일할 수 있는 방법이 뭘까 계속 고민하게 된다.

Tags: WFH, multinational, multi-timezone, collaboration  

개발자와 라면 조리법

라면 봉지 뒷면에 써있는 조리법을 한번 들여다보자.

(1) 물 550ml와 건더기 스프를 넣고 물을 끓인다.
(2) 분말 스프와 면을 넣은 후 4분 더 끓인다.

3번은 먹는 방법에 대한 권장사항이니 제외하면 두 단계라고 볼 수 있다. 근데 실제로 라면을 끓이는 자신의 모습을 상상해보면 이보다 훨씬 많은 단계들이 숨어있다.

(1) 냄비를 꺼낸다.
(2) 냄비에 물 550ml와 건더기 스프를 넣는다.
(3) 물과 재료가 담긴 냄비를 가열한다.
(4) 물이 끓기를 기다린다.
(5) 물이 끓기 시작하면 면과 분말 스프를 넣는다.
(6) 4분 더 끓인다.
(7) 불을 끈다.
(8) 그릇에 옮겨 담는다.

이보다 더 자세하게 서술할 수도 있다. 들여다보면 ‘냄비를 가열한다’에도 여러 단계가 생략돼있다. 심지어 장비에 따라서도 다르기 때문에 분기가 필요하다.

(1) 인덕션이라면 전원을 켜고 버튼을 눌러 온도를 높인다.
(2) 가스레인지라면 가스밸브를 열고 다이얼을 돌려 점화한다.
(3) 휴대용 버너라면 가스통을 흔들어 넣고, 잠그고, 점화한다.

하지만 그 어떤 라면 조리법에도 위 같은 내용이 포함되진 않는다. 왜냐면 이정도 상세한 내용은 독자가 이미 알고 있다고 간주하거나, 실은 라면 회사가 알 바 아니기 때문이다. 너무 당연한 말이라고 생각할 수도 있겠지만 이런 류의 코드는 꽤 흔하다. 함수 이름에 표현된 것보다 더 많은 일을 하거나 지나치게 세부적인 구현부가 드러나기도 한다. 이런 경우 보통 if문, for문이 많고 코드가 장황하다.

가령 fetchRecentArticles 라는 함수를 마주쳤다고 상상해보자. 이 함수가 수행하는 작업은 아래와 같다고 예상할 수 있다.

(1) 저장된 아티클을 적당히 불러온다.
(2) 최근 X일 내에 생성된 것들을 골라낸 후 반환한다.

그런데 막상 함수를 들여다보니 함수 안에서 로컬 캐시를 확인하고, 없으면 서버 API 호출을 해서 데이터를 가져와서 파싱하고, 저장소에서 데이터를 불러오기 위한 키 값도 정의하고, switch문으로 아티클의 종류에 따라 각기 다른 필터링 로직을 생성하고 있다면 어떨까. 막상 핵심 부분은 장황한 코드 속에 파묻히게 된다. 코드를 수정하려고 해도 어디를 건드려야할지 한참을 찾아야한다. 라면 물을 끓인다는 것만 알면 되는데 불을 어떻게 지펴야 하는지까지 설명하고 있는 셈이다.

‘왜 자석은 서로 밀어내는가?’란 기자의 질문에 리처드 파인만이 대답을 한 영상에서도 비슷한 의미를 찾을 수 있다. 같은 질문이라도 질문자가 누구냐(물리학 전공자, 일반인, 외계인 등)에 따라, 또는 질문자가 무엇을 알고 싶어하느냐에 따라 설명은 천차만별이 된다. ‘그건 그냥 그런거야’와 같이 한마디 답변이 될 수도 있고, 설명이 꼬리에 꼬리를 물고 끝도 없이 자세하게 설명할 수도 있다.

본인이 쓴 코드가 적절한 수준의 로직만 드러내고 있는지 고민해보자. 함수의 역할에 맞는 작업만 하고 있는지, 아니면 온갖 세부 로직을 장황하게 늘어놓고 있는게 아닌지 살펴보고 손봐야 한다. 그런데 ‘적절한 수준’이란 것엔 정답이 없다. 코드가 속해있는 클래스나 모듈에 따라 다르다. 코드를 읽는/쓰는 사람의 역량에 따라서도 달라질 수 있다. 누구에게는 간결한 코드가 누구에게는 더 이해하기 어려운 코드일 수 있다. 코드를 리팩토링 하다보면 또 기준이 바뀔 수도 있다. 모든게 유동적이다. 딱 떨어지는 기준은 없지만 독자의 입장에서 자신의 코드를 한번이라도 더 읽어보고, 함수를 짧게 만드는 연습을 하고, 동료끼리 코드 리뷰를 하면서 적절한 수준으로 맞춰갈 수 있다.

객체는 하나의 책임만 가져야 한다는 단일 책임 원칙을 지키는게 결코 쉽지는 않지만 함수 단위에서부터 시작해보자. 함수를 간결하게 만들수 있게 됐다면 다음으로 클래스 수준에서도 적용해본다. 단일 책임 원칙은 모든 패턴이나 아키텍처의 시작이다. 즉 단일 책임 원칙을 지키지 못하면 어떤 패턴을 쓰던, 어떤 아키텍처를 도입하던 시간이 흐를수록 결국 스파게티 코드가 될 확률이 높다. 언어 문법도 코드를 더 간결하게 표현하기 위한 수단으로써 공부를 하면 길을 잃지 않을 수 있다. 함수를 짧게 만들고 클래스를 작게 만드는 연습을 많이 하자.

같이 읽어볼만한 글

스위프트로 다시보는 객체지향 프로그래밍: 피해야할 코딩 습관

Sourcery 개발자로부터 배우는 모바일 아키텍처와 개발자 경험

iOS 개발자라면 한번은 들어봤거나 써봤을 오픈소스 툴 Sourcery를 만든 Krzysztof Zabłocki와 팟캐스트 녹음을 했는데 작년 엉클밥을 봤을 때와 비슷한 큰 자극와 영감을 얻었습니다. Krzysztof는 좋은 앱 아키텍처와 개발자 툴을 만들어서 개발자 경험을 개선하는 것에 목표를 두고 여러 툴을 만들면서 현재 뉴욕타임스에서 iOS 팀을 리딩하고 있는 개발자입니다.

잘못된 선택보다 올바른 선택을 하는게 더 쉬운 구조가 좋은 아키텍처다.

이 분은 모바일 아키텍처와 프로그래밍을 굉장히 실용주의적인 관점으로 해석하고 실행에 옮기시는 분이란 인상을 받았습니다. 그는 좋은 아키텍처를 구분하는 기준은 그 아키텍처를 쓰는 개발자가 얼마나 행복한가로 판단해야 한다고 합니다. 또한 좋은 아키텍처란 ‘잘못된 선택보다 올바른 선택을 하는게 더 쉬운 구조’라고 합니다. 왜냐면 인간은 여러 갈래가 있을때 쉬운 길을 택하는 경향이 있기 때문이죠. 좋은 코드를 짜기 위해 아키텍처와 싸워야하는게 최악의 상황이라고 합니다.

그래서 이분이 지금까지 만든 것들을 보면 의외로 간단한 아이디어에서 시작하지만 매일 매일 프로그래밍하는 개발자들의 생산성을 증가시켜주거나, 불필요한 반복 작업을 줄여서 실수를 줄여주거나, 코드를 좀 더 좋은 구조로 짜게 강요(?)하는 마법을 부리는 것 같습니다. Protocol extension으로 앱 로깅을 담당하는 싱글턴 객체를 숨기면서 유닛테스트도 할 수 있게 해주는 방법이라던지, 유저가 버그 리포트를 했을 당시 유저의 앱의 상태를 복원할 수 있는 데이터 스냅샷 기능 등을 보면 기존 코드를 많이 뜯어고치지 않는 간단한 방식으로 팀 전체의 개발 및 디버깅 경험을 개선시켜줍니다.

애플 엔지니어들마저 베껴간 Sourcery

더 대단하고 인기 많은 툴도 있습니다. Sourcery라는 툴은 스위프트에서 Equatable이나 Codable 프로토콜 등을 쓸 때 자동으로 구현 코드를 생성해주는 툴입니다. 지금이야 스위프트 자체에서 지원하는 부분이 있지만 초창기에는 디폴트 구현를 지원하지 않아서 모든걸 다 수동으로 구현해줘야 했을때 만들었다고 합니다. 이걸 만들고 얼마 지나지 않아 애플 엔지니어들마저 내부에서 사용하기 시작했다고 합니다. 재밌게도 그걸 알게된건 애플 엔지니어들이 회사 정책 때문인지 오픈소스에 직접 PR을 보내진 못하고 트위터 비공개 DM으로 패치를 보내주면서 버그를 고쳐 달라고 요청이 들어오기 시작했다네요.

애플의 거짓말을 들춰낸 Objective-C Playground

또 하나 놀라운 일화는 애플이 WWDC에서 스위프트 플레이그라운드를 발표하면서 옵젝씨로는 이런거 못한다고 말한걸 듣고 빡쳐서 불과 12시간만에 옵젝씨 플레이그라운드를 만들어버림으로써 애플이 틀렸다는걸 증명해버렸습니다. 이 프로젝트는 옵젝씨 뿐 아니라 스위프트까지 지원하고, 애플에서 만든 스위프트 플레이그라운드와는 비교도 안되게 훨씬 빠르다고 자랑합니다. 심지어 플러터처럼 앱 hot reloading도 할 수 있게 해버렸네요. ‘Code Injection’이라는 키워드를 처음 배웠습니다.

iOS 아키텍처와 테스팅

마지막으로 이 분은 iOS 개발을 하기 전에는 게임 엔진도 만들고 그래픽 개발도 하고 웹/백엔드 개발도 해봤는데, 모바일 진영이 그 중 제일 테스트코드 짜기를 꺼려하는 분위기라고 합니다. 그 이유 중 하나는 아마도 애플이 제시하는 MVC가 테스트하기 극도로 안좋은 아키텍처이기 때문인거 같다고 하네요. 일단 테스트가 잘 되려면 UIKit과 완전히 분리된 로직만 담당하는 클래스가 있어야하는데 “애플의 MVC”는 기본적으로 injection도 없고 composition도 없어서 그게 어렵다는 의견을 제시합니다. 그럼 대체 애플은 왜 십 수년간 MVC만 미는가, 좀 더 나은 아키텍처를 밀어주는 변화는 없을까란 질문에 대해서도 꽤 그럴듯한 답변을 내놨습니다.

일단 MVC 외에 인기있는 주류 아키텍처로는(2017년 발표 당시) MVVM과 VIPER(또는 여타 unidirectional architecture)가 있는데요. 먼저 MVVM은 FRP스러운 바인딩이 있어야하는데 이건 잘 만들기도 어렵고 당장 UIKit과 잘 맞지 않아서 후보가 될 수 없고, VIPER는 어려워서 배우기 쉽지 않다고 합니다. 애플은 신규 개발자들이 애플 플랫폼에 쉽게 들어오기를 바라기 때문에 이렇게 어려운 아키텍처를 밀어줄리는 없다고 하네요. 아키텍처에 대한 폭넓은 인사이트는 몇 년 전에 했던 인기 많았던 발표를 참고하시면 되겠습니다. Good iOS Application Architecture: MVVM vs. MVC vs. VIPER. 2020년 현재, Combine과 SwiftUI가 생겼으니 MVC를 벗어나기 쉬워졌을까요?

바로 오늘 도움이 되는 실용적인 코드와 툴을 만들어내는 개발자

이분은 프리랜싱과 컨설팅을 한 적이 있어서 그런지 개발 생산성과 코드 재사용성을 끌어올리는 아키텍처와 tooling에 전문가셨고, 특히 본인이 필요해서 만든 툴로 인해서 얼마를 벌었다는걸 구체적인 액수로 말하는게 정말 인상적이었습니다. 왜냐면 프리랜서는 시간이 수입으로 직결되니까 툴을 만들어서 매일 반복 작업으로 쓰이던 시간을 줄이거나 예전 프로젝트에서 썼던 코드를 재활용할 수 있게 되면 그게 곧바로 수입으로 계산될 수 있기 때문이겠죠. 엉클밥이나 GoF 옹들이 이론과 이상향을 제시하는 분들이라면 Krzysztof는 그 이론과 디자인 패턴을 바탕으로 당장 오늘 도움이 되는 실용적인 코드와 툴을 만들어내는 개발자 같았습니다. 특히, 매일 해야하는 디버깅과 코딩에서 최대한 반복 작업을 없애고 좋은 아키텍처가 퍼질 수 있게 꾸준히 무언가를 만들고 고민하는 모습에서 정말 큰 영감을 얻을 수 있었습니다.

Tags: mobile architecture, developer experience, Krzysztof Zabłocki  

개인과 팀이 성장하는 모바일 개발 환경

어제 페북에 들어갔다가 어느 회사 iOS팀의 채용 공고를 보게 됐다. 보통 채용 공고는 훑어보면 복지, 기술 스택 등의 키워드 위주로만 몇 개 눈에 띄는데 이 채용 공고는 기술 블로그처럼 내용이 술술 읽혔다. 예전 팀에 있을때 도입하고 싶었던 많은 것들이 이미 구축되어 있었다. 혼자서 팀원들을 설득해가면서 조금씩 도입해봤기 때문에 이만큼의 모바일 개발 환경을 구축하는데에 많은 노력과 시간과 시행착오가 들어갔을 거라는걸 알았다. 고개를 끄덕이면서 읽다가 문득, 내가 쪼렙일때 이 글을 읽었다면 어땠을까란 생각이 들었다. 경험이 부족하고 아는게 별로 없으니 뭐가 좋은건지, 이게 나한테 어떤 영향을 주는지 잘 몰랐을거 같다. 그동안 이런 개발 환경이 있을 때와 없을 때를 다 경험해 봤기 때문에 이제는 안다. 이런 크고 작은 것들이 모여서 내가 회사에서 보내는 시간의 질을 결정한다. 단순하고 반복적인 일이 적고, 개발 도중 흐름을 끊는 사건이 적어야 한다. 그래서 개발에 집중할 수 있는 시간이 많이 확보되는게 업무 시간의 질이고 이 시간이 개발자의 성장과 연결된다.

배포 자동화

“매 커밋마다 모든 코드가 테스트되며, 하루에도 수십 번 구성원들에게 개발 중인 빌드가 공유됩니다.”

배포 자동화는 클릭 한번(혹은 0번)으로 앱을 빌드하고 내부 사용자나 외부 스토어까지 바로 전달할 수 있는 환경을 의미한다. 배포는 단순하고 반복적이면서 자잘하게 시간이 오래걸린다. 예전 팀에 처음 갔을때는 반만 자동화되어있었다. 앱을 배포하려면 먼저 앱 버전이나 빌드 넘버를 올려줘야하는데 이걸 누군가가 수동으로 커밋을 하고, PR을 만들고 규칙에 따라 굳이 테스트도 다 통과해야하고, 마지막으로 또다른 개발자가 PR을 승인 해줘야 비로소 버전을 올릴 수 있었다. 프로세스가 이러하다 보니 구성원들에게 앱을 전달하려고 할때마다 무려 개발자 두 명의 업무 흐름이 끊어졌다. 이런 방법에 문제를 느껴서 꾸준히 개선을 해나갔고 결국에는 시리로 배포를 할 수 있을 정도로 자동화를 해서 배포에 소요되는 노력과 시간을 엄청 줄였다.

개발에 몰입하려면 방해받지 않는 연속된 시간이 정말 중요하다. 특히 개발자에게 30분 두 번은 1시간과 결코 같지 않다. 하루에 수십 번 빌드가 공유된다는건 배포가 완전히 자동화돼있어서 개발자는 업무 중에 배포에 신경쓸 일이 없다는 뜻이고 구성원들도 다른 팀원을 방해할 필요없이 가장 최신의 앱을 설치해볼 수 있다는 뜻이다. CI/CD가 구축되어 있어서 이런 종류의 자잘한 방해 업무가 최대한 없는게 좋은 환경이다.

피쳐 플래그

“피쳐 플래그를 도입하여 사용자에게 매주 배포할 수 있는 환경을 만들었습니다.”

피쳐 플래그란 백엔드가 내려주는 불리언 값으로 앱의 기능을 껐다 켰다 할 수 있는 장치다. 피쳐 플래그가 없으면 어떤 기능이 개발되는 동안에는 마스터 브랜치에 코드를 밀어 넣을수 없어서 별도로 피쳐 브랜치를 관리해야 한다. 기능이 규모가 크고 개발이 오래 걸릴수록 점차 마스터와 피쳐 브랜치가 멀어져서 나중에 합칠때 많은 고생을 한다. 심지어 머지 컨플릭을 잘못 수정해서 코드가 유실되고 기능이 망가지는 일도 겪어봤다. 이런 일을 겪고나면 마스터 브랜치에 코드를 병합하는 일이 중대한 일이 돼서 걱정과 두려움도 생긴다. 열심히 개발해서 테스트까지 잘 마쳤는데 코드 머지하는 마지막 단계에서 문제가 발생할 수 있다는건 개발자를 위축시킨다.

개발 인원이 적어서 한번에 기능 하나만 개발할 수 있고 그 사이 앱을 배포할 일이 없다면 이런 환경의 필요성을 느끼지 못할 수 있다. 그러나 피쳐 플래그가 구축되어 있으면 여러 개발자가 동시에 각자 다른 기능 개발을 하면서도 마스터 브랜치 하나만 유지하면 되기 때문에 브랜치 관리가 훨씬 쉽고 그 와중에 실배포도 무리없이 할 수 있다. 개발이 덜 된 코드가 있더라도 백엔드 값을 통해 미완성 기능을 유저한테 숨길 수 있기 때문이다. 이렇게 되면 개발자는 브랜치 관리나 머지 컨플릭 등에 신경을 덜 쓰고 온전히 개발에 더 집중할 수 있다. 피쳐 플래그의 또 다른 장점은 출시된 기능에 문제가 발견됐을때 임시 방편으로 기능을 꺼버려서 유저한테 미치는 영향을 줄일 수 있다는 점도 있다.

코드 리뷰와 짝 프로그래밍

“코드 리뷰는 iOS 팀의 핵심 문화입니다. (중략) 페어 프로그래밍을 종종 활용합니다.”

이민석 이노베이션아카데미 학장님은 ‘리뷰 없이 만들어진 코드는 사채다’라는 말을 하셨다. 정말 공감가는 말이었다. 업계에서 기술 부채라는 용어를 쓰는데, 개발자 한명이 혼자서 만든 코드는 고리대금 악성 사채처럼 기술 부채를 많이 발생시킨다는 뜻이다. 자신이 짠 코드를 자신과 동일시 하거나 지나친 애착을 가지고 변화로부터 보호하려는건 정말 좋지 않다. 코드는 팀원들 모두와 공동명의로 된 자산이라는 생각으로 다뤄야한다. 코드 리뷰를 하면 기술 공유가 되고 팀이 전체적으로 같이 성장한다. 개발하다 보면 가끔씩 자만감에 ‘이건 진짜 완결성 있게 만든거같다. 리뷰에서도 별다른 의견이 나올만한 부분이 없겠지’ 싶은데도 다른 동료의 눈에서 개선점이 발견되고 새로운 아이디어가 생기고 몰랐던 기술을 배울수 있다. 서로의 코드를 보여주지 않고 지적하지 않으면 개인으로나 팀으로나 성장할 수 없다.

짝 프로그래밍은 코드 리뷰의 상위 호환이다. 개발 실력이 비슷한 두 명이 하는것보다는 비대칭적인 실력을 가진 두 명이 하는게 효과적이다. 구글에서는 짝 프로그래밍을 거쳐 만들어진 코드는 코드 리뷰 승인을 받은 것으로 간주한다고 한다. 짝 프로그래밍까지는 아니지만 내가 신입일 때 사수님이 옆자리에 앉혀놓고 코딩을 하고 디버깅을 하는 모습을 보여준 경험에 대해서는 예전 글에서도 언급한 적이 있는데 정말 큰 도움이 됐고 아직까지 기억에 남는다. 얼마 전에는 내가 알려주는 입장에서 신입 개발자와 짝 프로그래밍을 했는데 반응도 좋았고, 나도 생각을 정리하고 설계를 더 탄탄하게 할 수 있는 좋은 계기였다. 시니어 개발자와 하는 짝 프로그래밍은 주니어 개발자에게 정말 값진 시간이다. 나보다 잘하는 사람으로부터 기술과 노하우를 1대1로 전수받고 질문도 마음껏 할 수 있는 기회는 어디가서 돈 주고도 못 산다.

단순하고 반복적인 일이 적고, 온전히 개발에 오래 집중할 수 있는 시간이 많은게 좋은 환경이다.

그러기 위해서는 반복적인 업무를 자동화하는게 필수적이다. 또한 코드 리뷰 문화가 자리 잡혀 있으면 개인은 물론 팀이 전체적으로 같이 성장할 수 있다. 위 기준와 사례를 통해서 어떤 회사를 가야할지, 어떤 팀에 가야할지, 혹은 어떻게 자신의 주변 상황을 개선해야 더 성장할 수 있을지 고민인 주니어 개발자분들에게 도움이 됐으면 한다.

Tags: mobile platform, growth, mobile ci/cd