David Gilbertson의 The fine art of fast development을 저자의 허락 아래 번역한 글입니다.
번역 서문: 슥 훑어보니 내용이 마음에 들어 저자에게 허락을 받았습니다만, 내용이 생각보다 너무 길어서 두 편으로 나누어 발행하려고 합니다. 결론을 빨리 얻고 싶으시다면 서문에 쓰인 대로 ‘짧은 버전’ 만 슥슥 읽으셔도 되긴 합니다.
이 글은 아주아주 긴 글이라서 효율적으로 읽을 수 있도록 매 단락마다 축약한 버전을 같이 써 두었습니다. 그저 훑어보고 싶으시다면 100초 안에 다 읽으실 수 있을 겁니다. (여러분의 독해 능력과 스크롤 속도에 따라 다르겠지만요)
만약 당신이 개발자는 아니지만 개발자의 퍼포먼스(역주: 앞으로는 업무 효율이라고 하겠습니다.)를 관리해야 하는 입장이라면, 쭉 내려가서 “거꾸로 보기” 단락을 보면 됩니다.
시작합니다!
길고 두서없는 서문
제가 사람들에게 빠른 개발에 대해 이야기하면(실제로 자주 합니다), 어떤 사람들은 빠른 이라는 개념을 근시안적인 관점에서 처음엔 빠르지만 결국 느린 방법일 것이다 라는 뜻으로 받아들이는 독특한 경향이 있습니다.
보통 이런 경향을 NND(Negative Nelly Disorder, 징징이 증후군 / 역주: Negative Nelly는 매사에 부정적인 사람을 일컫는 속어라서 징징이로 번역했습니다) 때문이라고 지적할 수도 있지만, 저는 더 근본적이고 역사적인 원인이 있다고 생각합니다. 유명한 우화 토끼와 거북이 말입니다.
이 우화는 불규칙적인(혹은 충동적인) 토끼와 우직한 거북이가 끝장을 볼 때까지 겨루는 이야기입니다.
천천히, 꾸준히 하면 경주에서 이긴다
라는 교훈은 (느린) 어린이들에게 자신감을 심어줍니다만, 저는 감히 이 우화에 새로운 요소를 추가했으면 합니다. 토끼와 거북이, 그리고 황소 떼(The Tortoise, the Hare, and the Herd of Buffalo) 라고 말이죠.
새로운 버전의 우화에서 토끼와 거북이가 몰아치는 황소 떼를 가로지르면서 이리 뛰고 저리 뛰느라 정신이 없습니다. 황소 떼가 발을 구르며 생긴 먼지 구름을 뚫고 이기기 위해 달려갑니다. 이번 버전의 우화에서 얻을 수 있는 교훈은 아래와 같습니다.
빠르고, 꾸준히 하면 경주에서 이긴다
에필로그: 토끼와 거북이는 열심히 뛰다 죽어버렸습니다. 남은 유해는 크림 챠우더가 되어버렸고, 사람들은 거북이는 등껍질에 담긴 크림 차우더를 먹었습니다. (재밌는 사실은 찰스 다윈스가 멋진 갈라파고스 거북이의 존재를 문서로 기록하고 나서, 집으로 돌아가는 길에 간식 삼아 먹으려고 두어마리를 가져갔다고 합니다. 진짜로요.)
그래서 우리는 ‘빠르고 꾸준히’ 가 ‘느리고 꾸준히’ 하는 것을 언제나 이긴다는 사실을 알았습니다.
하지만 안 좋은 소식이 있는데요…
세상은 천천히 움직이는 사람을 선호한다
사람이 북적이는 인도를 서둘러 걸어가 보신 적 있나요? 이리저리 인파 속을 비집고 들어가고, 앞질러 갈 수 있는 위치를 파악하고, 폰 쳐다보느라 앞도 안보는 사람들을 옆으로 슥슥 피해다녀야 하죠.
그렇게 가야하는 경로를 상상해보세요. 만약 위에서 아래로 조감해본다면 굉장히 복잡하고 꼬인 선처럼 되어있을 겁니다.
제일 천천히 걷는 사람은 정반대로 아주 편안합니다. 빠르게 걷는 사람을 신경쓸 필요도 없고, 자기 자신만 신경쓰면 됩니다. 완벽하게 직선으로 된 단순한 경로를 둥둥 떠다니듯 걷기만 하면 됩니다.
느린게 기본이 됩니다. 느린게 쉽고요. 빠른 것은 어렵습니다.
정확히 무엇을 얘기하려 하는가
이 포스트는 사실 행복에 대해 이야기합니다. 진짜로요. 제가 제목에 ‘빠른’ 이라는 단어를 쓴 이유는 “당신이 말하는 ‘빠르다’ 라는 방법이 실제로 느려요” 라고 생각하고 글을 보려는 사람들을 낚기 위해서였습니다(click-bait).
여러분이 더 빠르게, 더 생산적으로 움직일 수록 성취한 것을 자랑스럽게 여길 것입니다. 인생의 삼분의 일 정도는 고스란히 바쳤겠지요.
하루만에 모든 일이 한꺼번에 몰려들었는데 이걸 기어코 해치워버렸을 때 의 느낌, 이런 느낌을 한번 쯤은 경험해봤어야 합니다. 아마 코드를 작성할 때였을 수도 있고, 정원을 손질할 때였을 수도 있고, 자동차의 어떤 부분을 수리할 때일 수도 있습니다. 이게 뭐였든지 침대에 누웠을 때 성취감에 고양된 기분이 들었을 겁니다.
저는 그 기분을 느끼는 것이 아주 중요하고, 가치 있는 목표라고 주장합니다.
아 그리고 당신이 빠르게 움직인다면 돈을 더 벌 수도 있습니다. 돈은 모든 행복의 근원이죠.
이제 작은 부분부터 차차 조언해보겠습니다.
1. 당신이 시간을 어떻게 쓰는지 측정하라
짧은 버전
당신이 어떻게 시간을 쓰는지 기록하고 알려주는 소프트웨어를 사용하세요. 집중을 흐트러뜨리는 자잘한 유혹을 떨쳐낼 수 있는 동기부여가 됩니다.
긴 버전
빠른 개발의 첫 단계는 시간을 정리하는 겁니다. 그리고 정리의 첫 단계는 측정입니다.
당신이 사용하는 시간을 측정할 수 있는 도구는 아주 많이 있습니다. 저는 그 중에 RescueTime 이라는 녀석을 쓰는데 나쁘지 않습니다. 열려있는 애플리케이션 창과 URL을 기록하고, 직접 활동을 그룹으로 나눌 수도 있습니다. 아래 그림처럼 매일 제가 시간을 어떻게 사용하는지 한 눈에 볼 수 있습니다.
[또렷하지 않은 범례를 싫어하지 않았으면 좋겠군요]
이런 도구를 사용해서 행동 가능한 단위를 측정해야 합니다. 이거이거를 좀 바꿔야겠다 고 생각이 드는 정보 말입니다.
제 경우에는 “내가 진짜로 어제 슬랙 하는데 2시간을 쓴건가? 실제로는 더 적지 않을까?” 같은 질문을 합니다. 또한 때때로 지라에 한 시간은 쓰게 될 것(태스크를 작성하고 필요한 요구사항을 정의하는 등)이라는 통계 결과를 파악하기도 합니다. 전문적으로 요구사항을 작성하는 사람이라면 응당 그래야 할 겁니다.(이 얘기는 나중에 8번째 섹션 소음을 일으켜라 에서 더 자세히 다루겠습니다.)
개인적으로 몇 주동안 이 앱을 사용하면서 자신이 개선할 수 있는 부분에 대해 힌트를 얻었고, 그 후부터 제한적으로 사용하고 있습니다.
2. 멀티태스킹을 그만둬라
짧은 버전
최소 30분 이상 방해되는 요소 없이 코딩할 수 있는 시간 단위를 확보하세요. 2시간정도면 제일 좋습니다.
긴 버전
이 단락은 명백하게 자기 계발의 영역을 다루고 있습니다만, 잘 실천하면 큰 차이를 만들 수 있고 실제로 일부 사람들만 실천하고 있기 때문에 더 자세히 이야기 할 필요가 있다고 생각합니다. 출근해서 업무를 보는 어떤 하루를 생각해 보겠습니다. 정해진 시간 동안 여러분은 코드를 작성하고, 나머지 시간동안 동료와 이야기 하거나 이메일을 작성하고, 회의에 참여하는 등 다른 일을 처리합니다. 이 시간을 어떻게 정리하느냐에 따라 하루에 처리 가능한 일의 양이 엄청나게 차이날 수 있습니다.
아래의 두 그림은 같은 작업을 처리할 때 들어간 활동 영역별 타임라인입니다. 파랑색은 개발에 쓴 시간이고, 나머지 색상은 여러분이 평상시에 쓰는 다른 종류의 영역별 시간이라고 합시다.
[멀티태스킹]
[모노태스킹]
저기 멀티태스킹이라고 적혀있는 타임라인대로 대부분의 사람들이 움직일겁니다. 전화가 울리면 받고, 동료가 당신의 책상으로 다가와 말을 건네면 헤드폰을 벗고 무슨 말을 하는지 듣고, 화면에 채팅 알림이 뜨면 그 순간 이 세상 그 무엇보다 알림을 클릭해서 내용을 읽어보는 것이 제일 중요한 일이 됩니다.
(최악의 경우입니다. 알림이란 녀석은 메세지의 예고편만 보여주는건데, 그래서 더더욱 여러분이 하던 일을 멈추고 다른 일로 전환하도록 유혹합니다. 우린 정말 시간 관리에 실패할 수 밖에 없는 환경에 놓여있는겁니다.)
우리가 ‘멀티태스킹’ 을 할 때, 주의를 분산시키는 모든 요소에 반응하는 속도가 빨라집니다. 그래서 기분이 좋습니다. 멀티태스킹을 하면서 빠르게 반응하고 있으니, 생산적으로 일하고 있는거죠!
하지만 당연하게도 실제론 그렇지 않습니다. 멀티태스킹은 굉장히 비생산적입니다. 특히 코드를 작성하고 있을 때는 두 배로 안좋습니다.
코드를 작성하는 행위에는 많은 단기 기억력이 필요하기 때문에 특별합니다. 수 백줄의 코드를 표현할 수 있는 parseResults() 같은 작은 문자열들로 머릿속을 가득 채워야 합니다. 만약 parseResult 라는 함수가 무슨 일을 하는지 기억하고 있지 않다면, 그 코드가 선언된 위치로 가서 어떤 역할을 수행하는지 해석해야 합니다. 그러면 작업 속도가 느려지죠. 만약 그 코드가 무슨 역할을 하는지 외워뒀다면, 더 빠르게 작업할 수 있습니다. 마치 디스크에서 읽어들일 때와 RAM에서 읽어들일 때의 속도 차이 처럼 말이죠.
아래의 스니펫을 보시죠.
const rawResults = await goGetResults();const results = parseSortAndFilterResults(rawResults);
if (status === "READY") { render(results);} else { messages.on("ready", data => render(data.results));}만약 여기 있는 코드 내용에서 이미 알고 있는 사전 지식이 하나도 없다면, goGetResults 가 무슨 역할을 하고 parseSortAndFilterResults 가 어떤 역할을 하는지 파악하고 results 라는 변수에는 어떤 객체가 할당되는지 찾아내야 합니다. 그리고 status 라는게 뭔지 이해한 다음에 언제 어디서 이게 바뀔지 파악해야 합니다. 그리고 ready 라는 이벤트가 어디서 발생할지, 어떤 페이로드와 함께 발생할지 등등을 알아야겠죠.
처음 이 코드 앞에 앉아서 코드를 보게 되면, 코드에 익숙해지기 위해 여기저기 다른 탭을 돌아다니게 될 겁니다. 그러다 5~15분정도 지나면 더 많은 로직이 단기 기억 공간에 들어오게 되고 여러분의 뇌는 멋지게 그 로직을 펼쳐 하나의 지도를 만들기 시작할 겁니다.
생각이 흐름을 타기 시작하고 집중하는 타이밍에 들어서기 시작합니다.(You’re in the zone.)
그런데 전화가 울립니다.
전화를 받고, 중요한 내용에 대해 대화를 합니다. 다시 코드를 볼 때는 이미 뇌가 가비지 컬렉션을 마쳤고 일부 정보는 까먹었다는 사실을 깨닫습니다. 빌어먹을 휘발성 기억력이네요.
이제 다시 코드 여기저기를 둘러봐야 합니다. 로직을 뇌 속의 Disk에서 RAM으로 옮기는 작업을 또 하는거죠. 그렇게 5분 정도 걸려서 기억력이 살아나기 시작하고, 다시 집중하기 시작합니다.
그런데 슬랙 알림이 뜹니다.
그리고 이메일도 오고요. 거기다 동료가 와서 어깨를 두드립니다. 문자도 오네요? 기타 등등 다양한 일이 일어납니다.
제가 어떤 조언을 할 것인지 예상하셨겠지만, 좀더 자세하게 말씀드리겠습니다. 최소한 30분의 시간을 오롯이 코드만 작성하는데 집중할 수 있도록 하세요. 타이머를 써서요.
스마트폰은 비행기 모드로 설정해 두시고(과학자들은 아예 다른 방에 두라고도 하네요), 알림을 울리는 모든 애플리케이션을 닫아버리세요. macOS와 윈도우 모두 “방해 금지 모드” 가 있지만, 간접적으로라도 탭이나 앱의 아이콘에 새 알림이 왔다고 표시되는 것은 제 집중력을 갉아먹더군요. 그래서 될 수 있는 한 모든 탭과 앱을 닫는 것을 선호합니다.
아마 일생동안 멀티태스커였다면 하루에 30분짜리 세션을 두세번 짜내어 일하는 것 만으로도 큰 변화를 겪게 될 겁니다.
30분 타이머를 맞춰두고 정해놓은 시간이 끝나면 잠깐 스트레칭을 하세요. 그리고 이메일, 문자, 채팅, 트위터 등을 확인하지 않고도 계속 진행할 수 있을지 생각해보세요. 할 수 있다면 머리속에서 가비지 컬렉션이 일어나기 전에 쭉 진행하세요.
30분은 좋은정도지만, 2시간을 오롯이 집중하는건 아주 훌륭한 일입니다. 그 주에 따라 다르지만 저는 아마 매일 3~4시간정도 이런 시간을 가집니다.보통 오전 9시 30분부터 11시 30분까지 일이 잘 되더군요. 캘린더에 ‘집중 근무 시간’ 같은 일정을 등록해둘 수도 있습니다. 이러한 생산성 기법에 대해 더 자세히 알아보고 싶다면 Cal Newport의 Deep Work 라는 책을 읽어보세요. (역주: 국내 번역서가 있습니다)
알림에 대해 더 이야기를 해보겠습니다. 작년 즈음 어떤 깨달음을 얻었는데 이 깨달음이 제 생산성에 큰 변화를 주었기 때문입니다.
저는 알림을 어디서든 전혀 받지 않습니다. 제 폰은 수신음이 없습니다. 저는 새 이메일, 채팅, 트윗 등의 알림을 제 폰이나 컴퓨터 어디서도 받지 않습니다. 어디서나요.
저는 모든 디지털 커뮤니케이션을 아날로그 커뮤니케이션과 같다고 받아들이고 있습니다.(제 우편함 처럼요) 제가 확인할 필요가 있을 때 확인합니다. 업무 이메일의 경우 아침에 열어보고 그 날 안에 닫습니다. 집중 근무 시간 외, 특히 집에서 일할 때는 슬랙을 열어둡니다. 하지만 알림은 꺼 둡니다.
폰을 다루는 방법은 좀 흥미롭습니다. 편지봉투같은 아이콘이나 채팅 버블같이 제가 확인할 게 있다고 알려주는 요소가 전혀 표시되지 않기 때문에, 확인할 때까지 몇 주가 걸릴지 몇 달이 걸릴 지 모릅니다. 하지만 덕분에 저는 더 이상 집착하듯이 폰을 건드려서 내 주의를 흐트러뜨릴 요소가 있는지 확인하지 않게 되었습니다. 그럴 요소가 없으니까요. 이제는 잠깐 멀리 놓여있는 폰이 트위터 알림땜에 켜졌다고 착각했는데 알고보니 창밖에 새가 비친 경우를 겪을 일도 없습니다.
제가 의식적으로 실천하는 것 중 하나는 ‘급하다’ 라는 개념을 부정하는 겁니다. 만약 자신이 급하다고 느낀다면 디지털 기기가 ’뭔가 아주 급한게 있다’ 고 알리는 상황을 거부하기 힘들어집니다.
‘급하다’ 는 개념으로부터 벗어나고 싶다면 재밌는 연습법이 있습니다. 급하다고 생각되는 일의 목록을 노트에 정리하고 어디 보관해 두세요. 그리고 매달 말에 다시 읽어보면서 자신에게 “내가 이 일과 관련된 메세지를 25분쯤 뒤에 받는다고 아주아주 큰 일이 일어날까?’ 하고 물어보는 겁니다. 만약에 그런 종류의 일이 있다면 이 글을 읽는 다른 분들도 볼 수 있게 코멘트로 남겨주세요. 당신은 굉장히 흥미로운 삶을 살고 있는겁니다!
마지막으로, 집중 근무 시간에 들어서서 다른 사람들과 연락하기 어려운 상태가 될 때 신경써야 할 것이 있습니다. 생산성을 발휘하는 것과 이기적으로 행동하는 것 사이에 균형을 유지해야 한다는 것입니다. 저는 되도록이면 팀에게 악영향을 줄 수 있는 시기에는 집중 근무 시간을 가지지 않으려 합니다. 물론 여러분들도 각자의 균형을 찾아야 합니다.
3. 업무를 연결하라
짧은 버전
하나의 업무가 끝나면 다음 업무로 자연스럽게 넘어갈 수 있나요? 만약 업무를 전환하면서 시간을 쓸데없이 소비하고 있다면 git과 애자일 프로세스 사이에 충돌이 발생하고 있는 걸지도 모릅니다.
긴 버전
저는 주로 각각 개별적인 업무(Task)를 다룹니다. (지라 티켓과 깃헙 이슈 등) 업무는 하나의 단위로 구성되어 무엇을 할 지 선택한 뒤, git의 feature 브랜치로 나누어 작업한 뒤 master 브랜치로 머지(merge, 병합)됩니다. (역주: 이후에 나올 용어와 맥락 상 어울리도록 머지라는 단어를 씁니다)
그래서 업무를 처리할 때 대부분의 시간동안 두 가지를 다룹니다. 업무의 정의와 범위가 어떻게 정의되었는지 확인하는 작업과, 실제로 업무를 처리하고 배포되하는데 활용하는 git 프로세스 입니다.
만약 위의 두 가지를 잘못 적용하게 되면 지속적으로 생산성을 갉아먹을 수 있습니다.
한 가지 예를 들어보죠. 몇 년 전 일이라고 가정해 보고, 제가 Medium의 박수치기 버튼을 구현하면서 이전에 있던 한번만 눌리는 하트 모양 버튼을 교체한다고 생각해 보겠습니다. 이 작업은 두 가지 업무로 나누기로 했습니다. 하나는 클랩의 숫자를 받는 새 API를 개발하는 것이고, 다른 하나는 하트 모양 버튼을 새로운 박수 모양 버튼으로 변경하는 UI 업데이트 작업입니다.
제가 clap-api 라는 기능 브랜치를 따서 API 작업을 완료했고 풀 리퀘스트(이하 PR)을 올렸습니다. 그러면 이 PR이 코드 리뷰를 거쳐 QA까지 한 다음 마스터 브랜치에 머지되기까지 하루이틀이 걸릴 겁니다. 그 동안 저는 UI 작업을 시작합니다. 하지만 이 작업을 하려면 현재 clap-api 브랜치 안에만 있는 코드를 활용해야 합니다.
문제를 해결하기 위한 접근법 중 하나는 clap-ui 라는 브랜치를 clap-api 를 부모로 삼아서 생성하는 겁니다. 그러면 지난 번 작성한 코드부터 이어서 계속 작업을 할 수 있겠죠. 어차피 clap-api 브랜치는 조만간 머지될거니까, clap-ui 도 금새 뒤따라 마무리하여 두 작업을 끝낼 수 있게 됩니다.
두 작업 사이에 멈추는 시간이 전혀 없었네요. 아주 좋습니다.
대부분의 경우 이런 방식으로 작업하는게 잘 됩니다. 하지만 이따금씩 어깨너머로 웅성거리는 소리가 들려서 고개를 돌려보면 git이란 녀석이 나타나 여러분의 뺨을 때리고 있을겁니다.
일반적인 git의 사용법인 리베이스(rebase)와 스쿼시(squash) 중 하나라도 사용하게 되면 문제를 겪을 수 있다는 이야기입니다.
좀 더 어려운 예를 들어보겠습니다. 이 예가 친숙하다면 아마 어떻게 시간낭비를 한 적이 있는지 금새 떠오를겁니다. 제가 만약 clap-api 브랜치 기반으로 clap-ui 를 만들었다면, 저는 UI 브랜치 안에 API 브랜치의 내용이 포함된 커밋을 가지고 있게 됩니다(master 와 diff 를 비교할 때). 그리고 제가 clap-api 브랜치를 리베이스하거나(커밋을 제거함), 스쿼시 한 다음 master 브랜치로 머지한다면(마찬가지로 커밋을 제거함) 실제로 clap-ui 브랜치에서 이루어지지 않은 변경 사항이 담긴 커밋을 계속 남겨놓게 됩니다. 이제 다른 개발자가 이런 커밋에 해당되는 파일 하나라도 변경하게 되면 문제가 발생합니다. git이 보는 관점에서 브랜치에 직접적인 관련이 없는 파일도 어쨌든 바꾸고 싶은 거로 여겨집니다. 어쨌든 제가 관련없어보이는 커밋을 남겨놓았으니까요. 가끔은 이 때문에 불필요한 충돌(Conflict)이 일어나기도 합니다. 그보다 더 심한 것은 때때로 다른 개발자들이 적용한 변경 사항을 덮어쓸 수 있다는겁니다. 이 결과물이 퀄리티 체크를 통과하게 된다면 저 때문에 프로덕션에서 버그가 발생하게 되죠.
그래서 저는 결과적으로 충돌을 해결하거나 버그에 대처하는 등 시간 잡아먹는 일이 생기지 않도록 하기 위해 master 브랜치 외에 다른 브랜치에서 새 브랜치를 따지 말아야한다는 교훈을 얻었습니다.
위의 API/UI 브랜치 사례에서 저는 API작업을 끝내고 master 브랜치에 머지되길 기다린 다음에야 UI 작업을 시작할 수 있었습니다. 기다리는 시간 동안 다른 일을 처리하긴 했습니다. 아마 다른 작업들이 API 작업 때문에 막혀 있어서 스프린트(sprint) 안으로 다른 작업을 자꾸 끌어들이게 되지 않나 싶습니다.
이런 버벅이는 작업들은 버팔로 떼가 달려나가듯 잘 진행된다기보단, 토끼가 깡총깡총 뛰어다니듯 버벅이는 모양새로 보입니다.
저는 수 년동안 이렇게 불필요한 충돌을 해결하거나 다른 작업이 머지될때까지 기다리는 등 비효율적인 방식으로 작업해왔습니다. 그러면서 한 번도 이 상황을 개선할 방법이 없나 생각해본 적이 없었습니다. 그냥 git 커밋이 좀 망가지는게 만악의 근원 수준까지는 아니었으니까요.
그러다 새로운 직장으로 이직을 하고 전환점을 맞이합니다. 이 곳 사람들은 다른 방식으로 일하고 있었습니다. “잠깐, 당신들이 git을 다루는 방법이 훨씬 생산적이네요. 이제 이 방법을 잘 써먹어야겠어요.”
새 접근방식은 모든 문제 요소를 제거합니다. 더 이상 커밋을 없앨 필요도 없습니다. 커밋이 어떤 브랜치에서 만들어졌으면, 그 커밋은 언젠가 master 로 병합됩니다. 스쿼시도 하지 않고, 리베이스도 하지 않습니다.
첫 번째 단계(시작부터 맘에 들지 않을 겁니다)는 master 에 어떠한 커밋 히스토리도 남기지 않는겁니다. 제가 현재 작업하고 있는 사이트의 커밋 로그를 보시죠.
[여기저기 진흙탕에 드나든 듯 한 흔적. 하지만 생산적입니다.]
이 방법의 단점은 명확합니다. master 브랜치에 있는 커밋은 더 이상 ‘릴리즈 노트’ 의 역할을 하지 못합니다. 아마 공개된 소스 코드에 이런 식으로 관리하지 않을 겁니다. 대부분의 커밋은 제대로 동작하는 코드로 이루어져있지 않아서 git bisect (역주: 명령어의 상세 설명은 링크 참고) 명령어도 쓸 수 없습니다. 그런데 당신이 git bisect 명령어가 뭔지 알 정도라면 애초에 master 브랜치에서 버그가 많이 발생하고 있었으리라 생각합니다.
이 부분 외에는 신경쓸 게 별로 없습니다. 그냥 일을 하는 대로 착착 커밋을 하세요. 커밋 이름에다 관련 이슈 번호를 남겨서 git blame 커맨드를 입력하면 노출될 수 있도록 하고, 절대 스쿼시나 리베이스를 하지 마세요. 다른 브랜치에서 가져다 쓰고 싶은 코드가 있으면 머지해서 쓰세요. 아직 머지되지 않은 브랜치 3개에서 코드를 가져다 쓰고 싶다고요? 다 머지하세요! 머지한 커밋들은 다른 브랜치가 master 로 머지될 때까지 지금 작업하고 있는 브랜치에서 보이겠지요. 합쳐지고 나면 아무 문제 없습니다.
이런 git 사용 방식이 이 글을 읽고 있는 많은 사람들에게 불편한 기분을 주리라는 사실을 잘 알고 있습니다. 하지만 이런 방식으로 일하는 방식을 전환하면 생산성을 향상시킬 수 있습니다. 생산성과 커밋 이력의 깔끔함 중 어떤 가치를 더 우선시하는지 생각해보시길 권합니다.
잘못된 애자일 방법론을 적용하면 생산성에 좋지 않은 영향을 미친다
업무 처리에 관한 주제를 다루면서 .. 제가 일하던 몇몇 회사에서 ‘애자일 개발’ 이라는 이름 아래 생산성을 해치고 있는 두 가지 관행을 보았습니다.
첫 번째는 위에서도 암시했지만, 업무 단위는 반드시 최대한 작은 단위로 쪼개져야 한다는 믿음을 지니는 것이었습니다. 어떤 사람은 그날 하루가 지날 때까지 업무 하나를 처리하지 못했다면 그 업무의 단위가 너무 큰 것이라고 지적하기도 합니다. 이렇게 작게 쪼개진 업무를 처리하면서 여러분의 생산성에 나쁜 영향을 끼치고 있지 않다면 문제가 없습니다. 하지만 생산성에 좋지 않은 영향을 주고 있다면, 왜 굳이 이런 방식으로 업무를 나누는 걸까요?
두 번째는 스크럼의 경우입니다. 스프린트를 한번 시작했다면, 어떤 업무도 중간에 추가해서는 안된다는 생각을 하는 것이죠. 만약에 개발자가 스프린트에 등록한 업무를 다 끝냈다면 새로운 업무를 추가하기 보다 기술 부채를 해결하거나, 문서화를 하거나 (한숨) ‘다른 개발자들을 도와야’ 한다는 겁니다.
이 생각은 비논리적이고 생산성을 해치는데다, 결정적으로 스크럼이라는 것을 크게 오해하고 있어서 나타난 것입니다.
스프린트에서 계획한 업무를 끝내던지 끝내지 못하던지 그 결과가 나타내는 것은 얼마나 정확하게 업무량을 측정했나 이지, 얼마나 많은 일을 했는지가 아닙니다. 스프린트 안에서 정해진 일을 빨리 끝냈다는 것은 업무 단위를 너무 비관적(방어적)으로 측정한 것에 지나지 않습니다. 업무를 제때 끝내지 못했다는 것은 반대로 너무 낙관적으로 업무 단위를 측정한 것이죠. 스프린트 기간 안에 팀이 얼마나 좋은 퍼포먼스를 내었는지랑 전혀 상관 없습니다.
스프린트 안에 주어진 일을 끝내는 것은 좋은 일이고, 그렇지 못한 것은 나쁜 일이라 여기는 것은 좋지 않고 바보같을 뿐 아니라 비생산적인 생각입니다. 최선의 경우에는 단지 비관적으로 일정을 산정할 뿐이고, 최악의 경우에는 ‘일을 적게 해야한다’ 는 좋지 않은 문화가 뿌리내릴 수 있습니다.
(이 주제에 대해 저는 좀 열 받은 상태입니다. 그래서 좀 더 이야기하자면 여러분이 스프린트 기간 안에 달성한 스토리 포인트도 마찬가지로 성과 지표로 의미가 없다고 생각합니다. 스프린트 안에서 일어나는 ‘속도’ 변화는 업무 추정의 정확도 변화를 나타냅니다. “팀원 여러분, 잘 했어요 우리가 이번 스프린트에서 45포인트를 쳐냈습니다!” 같은 감상이나, “우리가 이번에 겨우 37포인트밖에 쳐내지 못했네요” 라고 낙담하는 일 모두 무의미합니다. 의미 있는 코멘트라고 한다면 “이번 스프린트의 속도 오차는 지난 스프린트 대비 20% 이내였습니다. 여러 불확실한 요소 속에서도 최대한 정확히 일정을 측정하느라 고생하셨습니다. 이 결과물은 앞으로의 일정 산정을 더 정확히 하는데 도움이 될 것입니다.” 같은 내용을 남기는 겁니다.)
음, 얘기하다 보니 주제를 좀 벗어났네요. 어쨌든 이 질문과 함께 단락을 마무리하고자 합니다. 여러분의 애자일/스크럼 방법론이 결과적으로 일을 줄여주었나요?(생산성을 향상시켰나요?) 혹시 그렇다면, 어떻게 그럴 수가 있죠(WTF)?