[번역] 빠른 개발을 위한 기술 - 2

Published:

David Gilbertson의 The fine art of fast development을 저자의 허락 아래 번역한 글입니다.

1편에 이어 남은 챕터를 번역합니다.

4. 일을 한번에 처리하라

짧은 버전

버그를 만들지 마세요.

긴 버전

버팔로 떼가 달려가는 모습을 상상해 보세요. 우렁찬 발굽 소리를 내면서 달려가던 버팔로 중 하나가 자기 립밤을 떨어뜨렸습니다. 이제 그 녀석은 멈춘 뒤 뒤돌아가면서 ‘지나갑니다, 어이구 미안해요, 실례합니다’ 같은 이야기를 하며 촉촉한 입술을 되찾기 위해 나머지 버팔로 떼를 헤쳐나갑니다.

바보같은 버팔로 녀석, 나머지 팀 전체의 발목을 붙잡고 말았네요.

매 순간 버그를 고칠 때마다, 당신은 인파를 비집고 뒤로 가는 것처럼 행동하는 것 처럼 생산성을 크게 해치게 됩니다.

저는 버그 없이 제품을 출시하는 일이 가능하다고 믿습니다.

그리고 이 생각을 관철하기로 마음먹었는데요(방대한 반박 자료가 있음에도 불구하고), 제가 “버그는 (언젠가) 일어난다” 같은 티셔츠를 살 때마다 ‘버그 없는’ 기록을 만들기 위한 노력을 포기하는 것이기 때문입니다.

따라서 지난 수 년동안 제가 만들어낸 버그를 발견할 때마다, 고칠 수 있었던 코드에서 내 접근 방식에 무엇이 있었는지 찾아보는 식으로 나름의 근본적인 원인 분석을 합니다.

그 결과 조금 부끄럽지만 아래의 두 가지 결과가 크게 눈여겨볼만 했습니다.

  1. 며칠에 걸쳐 어떤 업무를 거의 다 끝내갈 때, 다음 업무로 넘어가고 싶어 몸이 근질근질합니다. 그러면서 참을성이 없어집니다. 그래서 마지막으로 작은 리팩터링을 하며 일을 마무리지은 뒤 전체 리테스트를 하지 않을 때가 있었습니다.
  2. 1번과 비슷하지만 이번엔 제가 (코드) 리뷰어일 때입니다. 다른 사람이 마지막에 작은 변경을 했는데 PR(풀 리퀘스트) 전체를 다시 검수하지 않았습니다. (제가 코드 리뷰에서 발견할 수 있는 버그를 지나쳤다면, 이 버그는 저 때문에 생긴 것이기도 합니다.)

이렇게 게으름 때문에 발생했지만 실제로는 막을 수 있는 버그들을 방지하기 위해, 지난 몇 년동안 ‘절대로 코드를 타이핑하는 것 부터 PR작성까지 한번에 하지 말 것’ 이라는 규칙을 따라왔습니다.

그 대신 산책을 조금 합니다. 거리 주변을 돌아다니거나, 회사 주변을 돌아다니거나 어디든지요. 1분에서 2분 정도 코드에 몰입되어있던 생각을 떼어놓습니다.

그러고 나서 자리로 돌아와, 제 자신의 최악의 비평가가 되어 방금 *얼간이 데이빗(역주: 저자 자신입니다)*이 만든 새 기능을 면밀히 파고듭니다. 얼간이 데이빗의 작업에서 문제점을 발견하기 위해 두가지 각도로 공격적인 접근할 수 있습니다.

먼저, 이래저래 탐색적인 테스팅을 합니다. 제가 중요하다고 알고있는 모든 인터렉션이나, 구현하기 까다로운 부분을 찾거나, 엣지 케이스를 찔러보거나, 지원되는 기기 중에서 가장 애매한 녀석을 가지고 돌려본다던가, 아주 긴 문자열을 이상한 문자와 함께 입력해보는 등의 작업이죠.

두 번째로, Github/BitBucket 등에서 내가 제일 싫어하는 개발자가 이 코드를 썼다고 상상하면서(제가 아는 한 정반대지만요) 한줄 한줄마다 브랜치 변경사항 비교를 할 겁니다. 이 작업은 반드시 온라인 도구로 이루어져야 하는데, 비교 화면의 녹색과 빨강색 배경화면이 저를 정말 깐돌이처럼 생각하게 만들어주기 때문입니다. 그러다 얼간이 데이빗이 어떤 줄의 코드를 주석처리 해놓은 것을 돌려놓지 않았거나, 변수의 이름을 짓는 방법이 일관되지 않는 등의 문제를 발견할 때마다 신이 나서 웃습니다.

이렇게 수 년 동안 모든 브랜치에서 셀프 코드 리뷰를 하면서 80%는 무언가 고쳐야 할 부분을 찾아냈습니다. 보통은 동료가 금새 찾아낼 법한 바보같은 실수인데, 만약 동료가 PR에 코멘트를 남기면 저는 그 부분을 읽고 고친 다음, ‘fixed’ 같은 커밋을 한 뒤 동료들에게 다시 브랜치를 리뷰할 상태가 되었다고 알려야 하죠. 이런 실수를 직접 찾게 되면 엄청난 양의 시간을 절약할 수 있습니다.

이제 제 목표는 PR에서 코멘트를 하나도 남기지 않아도 되게 만드는 겁니다. 당연히 언제나 그렇게 될 수는 없겠죠. 단순한 실수 말고도 리뷰할 것은 많으니까요. 하지만 작은 실수라도 만들지 않기 위해 노력하며 황소처럼 우직하게 나아가는 것은 큰 변화를 만들 수 있습니다.

따라서 다음에 PR을 올리실 때, 변경 사항 비교 창을 보며 ‘Create Pull Request’ 버튼을 누르기 직전에, 물 한 잔 드시고 팔과 다리 스트레칭을 한번 해 보세요. 그리고 정말로 실수한 게 없는지 잘 생각하며 변경 사항을 쭉 읽어 보세요.

5. 당신의 발목을 잡는 부분을 찾아서 고쳐라

짧은 버전

코딩과 연관된 활동 중 자기 생각보다 오래 걸리는 게 어떤 것인지 생각해 보세요. 문제를 찾아낸 다음 그 영역을 보완하기 위해(skilling up) 시간을 투자하세요.

긴 버전

이번 단락은 좀 어려운 부분일 수 있습니다. 어떻게 내가 원래 생각했던 시간보다 오래 걸리는지 아닌지 알 수 있을까요? 때때로 다른 사람이 똑같은 일을 자신보다 두 배로 빨리 하는 것을 보고 나서야 ‘더 나은 방법이 있다’ 는 것을 발견할 때도 있습니다. 제 경우는 어떤 사람이 크롬의 개발자 도구에 있는 ‘Performance’ 탭을 사용할 때였는데, 그 모습을 보고 완전 뿅 가고 말았습니다. 그래서 자리에 돌아가 관련된 문서를 쭉 정독했었죠.

(“너의 도구를 알라-Know your tools” 는 별도의 섹션이 될 수 있습니다만, 그리 길게 쓸 정도는 아닙니다. 그러니 자신의 도구를 제대로 알고 쓰세요.)

자기 성찰을 시작하기 위해, 하나의 업무를 끝내면 몇 분의 시간을 들여 어디에 어떻게 시간을 썼나 되돌아보세요. 확 떠오르는게 있나요? CSS에서 아이콘과 문자를 수평으로 정렬하는데 3시간 정도 쓴 적이 있나요? 아니면 glob 문법을 추측하고 확인하는데 갇혀 있었거나, 정규표현식을 해석하거나, FULL RIGHT INNER OUTER JOIN 같은 것 때문에 머리를 벅벅 긁고 있었을지도 모릅니다.

이렇게 완전히 이해가 되지 않는 부분에서 무슨 문제가 있는게 아닐까요?

CSS는 특히 문제가 많은 부분인데요. 왜냐면 사람들이 문서도 제대로 읽어보지 않고 ‘할 수 있다’ 라고 생각하는 것 중 1순위이기 때문입니다. 하지만 말도 안되는 소리인게, CSS의 스펙은 자바스크립트의 세 배나 되며 심지어 2019년에도 열 받을 정도로 브라우저 사이에 맞지 않는 부분 때문에 고통을 줍니다.

(‘세 배’ 라는 말은 지어낸 겁니다. 인터넷에서 보는 모든 정보를 믿지 마세요.)

사진과 따옴표가 있다고 해서 인터넷에 있는 모든 것을 그대로 믿지 마라

시간을 많이 낭비한다고 의심되는 부분을 찾았다면, 이렇게 되물을 수 있습니다. “내가 앞으로 몇 년이나 이 분야의 일을 더 하면서 이 부분의 개념을 깊이 이해하는게 (금전적으로/시간적으로) 도움이 될까?”

아마 답은 “그렇다” 겠죠. 그러니 입술 꽉 깨물고 빌어먹을 문서를 읽으세요(bite the bullet and RTFM-Read the fucking manual).

플러그인 사용 전과 후 [뻔뻔한 플러그인 추천: 대부분의 웹 스펙 문서(w3c, csswg, ecma-262 등)는 끔찍한 모양으로 보이기 때문에 저는 이 문서들이 읽기 좋게 보이는 크롬 확장을 만들었습니다.]
[페이지마다 스크롤 위치를 기억하는 다른 확장도 만들었습니다. 하루에 30분정도씩 기나긴 웹 스펙을 읽을 때 유용합니다.]

또 무언가 배울게 있다고 알려주는 신호 중 하나는 애플리케이션이 ‘이상하거나’ ‘무작위로’ 동작하고 있다는 느낌이 들 때입니다.

컴퓨터는 이상하거나 무작위로 동작하지 않습니다. 하지만 사람은 그렇습니다. 만약 어떤 요소에 대해 왜 이렇게 동작하는지 이해하지 못하고 있다면, 그 부분을 제대로 익혀서 생산성을 끌어올릴 수 있다는 말이 됩니다.

오랜 시간동안 매일 처음 한 시간은 읽기에 투자하면서, 제가 제일 헤메던 부분에 대한 글을 중심으로 읽고 있습니다. 보통 오전 7시에 일어난다 치면 오전 8시까지 읽습니다. 빠짐없이요. 이 방법을 강력히 추천합니다. 문제를 해결하는 속도가 점점 빨라지는 것을 느낄 것이며, 계속 읽는 한 그 흐름도 이어질 것입니다.

물론 저는 다 알게 되었으니 더 이상 이 방법을 쓰지 않습니다.

6. 빠르게 구조를 잡고, 그 다음 다듬어라

짧은 버전

주어진 업무에서 큰 부분을 먼저 추려내세요. 코드를 어떻게 정리할 것인지 생각하고, 필요하다면 최선의 방법에 다다르기 전에 여러 다른 방법을 시도해 보세요.

그 구조가 바뀌지 않을 거라는 확신이 들기 전까지 코드를 다듬고자 하는 집착(UI 스타일, 코드 스타일, 테스트 등)을 잠시 접어두세요.

긴 버전

코드를 지우는 행위는 개발을 하면서 자연스러운 것입니다. 하는 만큼 배우게 되죠. 밤에 잠 잘 자고 일어나서 새로운 접근 방식을 떠올리기도 하고, 어떤 일이 실현되기 전에 올바른 사항을 고려하지 못하기도 하고, 아주 드물게(once in a blue moon) 요구사항이 작업 진행 중에 바뀌기도 합니다.

코드 좀 작성하고, UI를 픽셀 단위로 완벽하게 맞추고, 메서드 사이의 공백을 넣어주고, 유닛 테스트를 작성한 다음에 그제서야 더 나은 방법이 있고 많은 양의 코드를 지우고 다시 정리해야 한다는 사실을 깨닫는 경우가 그리 달갑진 않을 겁니다.

따라서 올바른 접근 방법을 찾았다고 확신할 수 있는 제일 작은 부분부터 핵심적인 일을 나눌 수 있다면, 그 부분을 완벽하게 만들고 리팩토링을 하기까지 적은 시간과 노력이 필요할 것이고, 시간을 적게 들였으니 이전 코드 스타일을 갖다 버리는데 주저하는 일이 더 줄어들 것입니다.

만약 업무가 많이 복잡하다면, 핵심적입 부분을 먼저 작업하고 최소한의 부분으로 코드 리뷰를 요청하세요(아니면 동료들에게 그 부분을 들고 가서 의견을 물어보세요). 무언가에 한 주씩 통으로 매몰되어 완벽하게 만들고, 다듬고, 100% 커버하는 테스트를 작성했는데 코드 리뷰에서 ‘더 쉬운 방법이 있다’ 라는 소리를 듣지 않도록 하세요.

7. 항상 미래에 시선을 두고 있어라(Keep one eye on the future)

짧은 버전

앞으로 하지 않았으면 하는 일은 지금도 하지 마세요. 리팩토링 하기 쉬운 코드를 쓰세요.

긴 버전

이 단락은 장황한 이야기가 되겠습니다. 뭔가 일반적인 ‘조언’ 으로 정리하기 어려운 이야기인데, 여러분이 코드를 작성하는 환경에 크게 좌우되기 때문입니다.

좀 광범위한 제안을 하자면

관심사 분리에 대해 좀 더 신경써서 아주 간단한 규칙 하나를 제안할 수 있습니다. 바로 ‘다른 역할을 하는 코드는 다른 파일로 나누어라’ 입니다. 데이터베이스 동작, API 호출, 데이터에 변경을 가하는 동작, 유틸리티, UI 랜더링, 이 모든 다른 것들을 각자 고유한 파일에 담아두는 겁니다. (다시 말씀드리지만 아주 간단하게 이야기한 것이기 때문에 충분한 시간과 노력을 들여 여러분의 애플리케이션 설계를 구상해야 합니다.)

대부분의 코드베이스는 몇 번인가의 대형 리팩터링을 세대마다 한 번씩 거치게 될 겁니다. 서버에서 HTML을 랜더링해서 내려주는 방식에서 클라이언트의 자바스크립트가 HTML을 랜더링하는 방식으로 간다던가, SQL을 NoSQL 기반으로 바꾼다던가, 대형 서비스(monolith)를 마이크로서비스 구조로 바꾼다던가.

이렇게 큰 변경을 하게 되는 순간이 올 때(그렇게 될 겁니다), 업데이트 해야 하는 코드의 영역이 잘 분리되어 각각의 모듈 담당하고 있는 영역(UI, DB, API 등)만 신경쓸 수 있다면 몇 달치의 노력을 절감할 수 있습니다. 코드를 정리하는 방식에 있어 작은 변화도 꽤 큰 보상이 뒤따를 수 있습니다.

CSS는 여기서 또 특수한 경우 중 하나입니다. 왜냐면 이 녀석은 전역으로 동작하고, 계층적으로 적용된다는 끔찍한 특성이 조합되어 있기 때문입니다. 하나의 CSS 규칙이 HTML 파일 어디서든 참조되고 사용될 수 있습니다. 그리고 다른 CSS 파일의 규칙과 합쳐질 수도 있고, 작은 리팩터링만 거쳐도 이미 HTML 트리 어딘가에 정의된 클래스 참조와 합쳐져 헤아릴 수 없는 의존성의 조합을 만들어내기도 합니다. 아 그리고 두 가지의 경우 모두 적용될 때가 있는데, 82개쯤 되는 CSS 파일을 조합되고 난 뒤에야 CSS 규칙이 선언된 순서를 무시하고 특정한 알고리즘에 의해 선택된 규칙에 따라 예상 밖으로 동작하는 경우도 있습니다.

이런 경우 정말로, 진짜로, 순식간에 다른 부분의 인터페이스를 무너뜨리지 않기 위해 노력하면서 엄청난 시간을 낭비하는 상황으로 치닫게 됩니다.

CSS를 작성하면서 모듈화된 CSS를 작성하지 않고 있다면, 좋은 소식을 하나 알려드리겠습니다. 당신은 끔찍하게 비생산적으로 일을 하고 있으며 이 구덩이에서 벗어나게 만들어줄 좋은 방법들이 몇 개 있습니다. 단연코 CSS 모듈이 으뜸이고, BEM은 최적의 대안이 될 것이며, CSS in JS도 그 중 하나입니다(CSS in JS의 좋은 점은 몇몇 사람들을 열 받게 한다는 건데, 언제나 구경하는 재미가 있습니다).

8. 소리를 질러라(Make some noise)

짧은 버전

당신의 생산성이 치명적으로 위협받을 정도로 많은 일을 넘겨받고 있다면, 마음 속으로만 비명을 지르지 말고 관리자에게 이야기하세요.

긴 버전

언제나 완벽히 구성되지 않은 팀에서 일하게 될 확률이 있습니다. 제일 잘 정돈된 팀에서 저는 보통 하루에 5시간 정도 코드를 작성할 수 있었으며, 제일 정돈되지 못한 팀에서는 그 절반 정도 되는 시간밖에 얻지 못했습니다.

생각 해 보세요. 어떤 회사는 경쟁사보다 두 배나 빨리 나아갈 수 있다는거죠!

그러니까 지금 최적의 생산성을 낼 수 없게 만드는 일에 시간을 쓰고 있고, 그 상황을 직접 해결할 수 없다면, 소리를 지르세요. 이 문제를 해결할 수 있는 능력을 가진 사람에게 이야기하세요.

궁극적으로 모든 구성원은 같은 편입니다. 경영진은 제품을 신경쓰고, 당연하게도 ‘생산성’이라는 단어가 제일 먼저 바라보는 목표는 제품입니다.

다른 말로 생산적으로 일하지 못하는 문제가 생겼다면, 경영진은 제품에 문제가 생긴 것이며, 더 좋은 제품을 만들 수 있었음에도 불구하고 여기저기 생긴 구멍으로부터 버그 리포트를 받게 될 것입니다.

제가 본 대부분의 회사들이 저지르는 실수가 있는데요(아마도 그 사람들은 이게 ‘실수’라는데 동의하지 않겠지만요). 바로 개발자들이 개발 이외에 다른 작업에 투입되어야 한다는 겁니다.

제 얘기 좀 들어보세요…

당신(역주: 관리/경영진으로 추정)이 개발 팀에게 할당하던 모든 종류의 주요한 지원 업무를 치워버리면, 개발자들은 계속 코드를 만들어낼 수 있습니다.

당신이 이터레이션 매니저나 스크럼 마스터를 치워버리면, 개발자들은 공백을 메꿀 것입니다. 혹은 디자이너를 없애버리면 개발자들이 알아서 어떻게 제품이 동작해야하는지 만들어 낼 것입니다. 심지어 프로덕트 매니저/프로덕트 오너/BA 혹은 어떠한 식이던지 요구 사항을 문서화하고 정리하는 직군을 둘 필요도 없습니다. 개발자들이 코드를 작성하면서 디테일을 정리하겠죠. 또한 정말로 QA(Quality Assurance) 직군에 돈을 낭비할 필요도 없습니다. 개발자들이 문제가 생길 수 있는 부분에 직접 QA를 구현하게 만들면 됩니다. 그 사람들이 직접 자신이 만든 것에 QA를 진행할 수 있으니까요.

자, 개발자들은 똑똑하고 유연한 사람들이라서 저 위의 모든 일을 수행할 수 있습니다. 하지만 개발자들이 저 위의 일을 하고 있다면 코드를 작성하고 있지 않겠죠. 따라서 회사가 QA, 이터레이션 매니저, 디자이너, 프로덕트 오너 등을 채용해야 하는겁니다. 결정적인 차이점은 경영진이 위에서 이야기 한 개발 외의 일을 숙련된 전문가에게 돈 주고 시키는게 아니라, (확실히 임금이 절대 저렴한 직군이 아님에도 불구하고) 개발자들에게 시키고 있다는 겁니다.

이렇게 생산성이 떨어지고 있지만, 이런 문제가 흔히 발생하는 이유는 생산성이 떨어지면 초래할 결과에 대해 좀처럼 경종이 울리지 않기 때문이라고 생각합니다. 차를 만든다고 생각해보면, 생산 결과 보고서를 읽고 “왜 지난 달에 고작 45,000대밖에 생산하지 못했지?!” 같이 물을 수 있지만, 결과물이 코드라면 가변적인 특성 때문에 자연스럽게 격차가 가려집니다. 아무도 “왜 지난 달에 새 버튼을 34.5개밖에 만들지 못했지!?” 같이 소리치지 않습니다.

또한 애자일 ‘속도(velocity)‘도 그닥 도움이 되지 않을 것인데, 개발자들이 업무를 진행할 때 측정, 포함, QA, 요구사항 정리 등의 모든 측면을 고려하도록 신경 쓸 것이기 때문입니다. 만약 어떠한 일이라도 더 하는 것 같이 느껴진다면, 원래 추적하기 힘들었던 일이 갑자기 표면 위로 떠오른 것입니다.

많은 단체가 생산성에 부정적인 영향을 주는 결정을 하리라 생각하고 있습니다. 왜냐면 그 결정이 생산성에 악영향을 줄 수 있다는 것을 모르기 때문입니다. 유일하게 개발자가 최고 속력으로 달릴 수 있는지 아는 방법은 개발자 스스로 그렇다고 말할 때 뿐입니다.

따라서 만약 이 글을 읽는 당신이 개발자이고, 훈련 받은 전문가가 한다면 더 잘 할 수 있는 영역에 많은 시간을 쏟고 있다면, 소리를 지르세요.

뒤집어 봅시다

여태 이야기한 내용을 종합하여 상상해 볼 수 있는 최악의 생산성을 가진 팀을 만들어 보겠습니다.

위의 모든 사항에 노력을 기울인다면 원래 팀이 가지고 있는 잠재 능력의 절반 정도만 끌어낼 수 있습니다.

하지만 아직 끝난게 아닙니다. 숨겨진 보너스가 있지요! 운이 좋으면, 이렇게 강제된 무기력감은 사기를 떨어뜨리고, 더 많은 정신력 소모로 이어지며, 결국 회전문 피드백 사이클(역주: 입사-퇴사가 반복되는 사이클로 추정되는데 명확한 설명을 찾지 못했습니다)로 악화되어 생산성이 더 추락할 겁니다!

읽어줘서 고마워요, 인터넷 친구들!

세구에(segues, 역주: 음악 용어에서 유래한 것으로, 앞의 악장에서 끊어지지 않고 계속 되는 것을 의미합니다)에 대해 이야기 하다 보니, 소설 읽으시나요? 제가 쓰고 있는 소설 한번 읽어 보실래요? 좀 못나긴 했지만 여러분도 여기 맞을 만큼 못난 유머 감각을 가지고 있을 수도 있죠. 한번 살펴보세요.

그럼 진짜로 안녕!

번역 후기

정말 긴 글이었지만 쭉 읽고 번역할만한 가치가 있다고 느낀 글이었습니다.

저도 나름 열심히 일을 해 왔다고 생각했지만 분명 ‘무언가 일이 제대로 돌아가고 있지 않다’ 고 느끼는 순간들이 있었습니다. 하지만 정확히 어떻게 그 문제를 헤쳐나가야 할지 정리하지 못했었는데, 이 글을 읽고 훨씬 머리가 맑아진 느낌을 받았습니다.

여러분이 일하고 있는 팀은 어떻게 운영되고 있나요? 당당히 “현재 내가 낼 수 있는 최고의 생산성을 내고 있다” 라고 이야기하실 수 있나요? 당장 팀은 커녕 제 자신도 개선할 부분이 많네요.

여러분들도 각자 자신만의 생산성 관련 팁이 있다면 함께 공유해주세요 🤗