회사에서 아무것도 안 하기

본문은 요즘IT가 션 고데크(Sean Goedecke)의 글 <Doing nothing at work>를 번역한 글입니다. 필자는 GitHub의 스태프 소프트웨어 엔지니어(Staff Software Engineer)로, GitHub Copilot 관련 개발을 담당하고 있습니다. 수학 학사와 도덕철학 석사라는 이색적인 배경을 지닌 엔지니어로, Zendesk를 거쳐 2021년 GitHub에 합류했으며, 소프트웨어 엔지니어링과 대기업 조직의 역학을 주제로 한 인기 블로그를 운영하고 있습니다.

이 글은 '뛰어난 엔지니어일수록 오히려 일을 덜 해야 한다'는 도발적인 주장을 담고 있습니다. 필자는 기술 회사에서의 성과가 대형 계약, 장애 대응, 주목도 높은 기능 출시 같은 예외적인 사건들에 좌우된다고 봅니다. 그리고 이런 임팩트 큰 기회를 잡으려면 평소 가동률을 80%로 낮춰 여유를 남겨 둬야 한다고 말합니다. 글루 워크(glue work) 피하기, 보상 없는 노동 요구에 역압 걸기, 사라질 가능성이 큰 일에 투자하지 않기 등 '의도적으로 아무것도 하지 않는' 구체적인 전략을 함께 제시합니다.

필자에게 허락을 받고 번역했으며, 글에 포함된 링크는 원문에 따라 표시했습니다.

많은 엔지니어가 지금보다 일을 덜 해야 합니다. 코드를 덜 짜거나, 변경을 줄이라는 뜻이 아닙니다. 말 그대로 하루에 일하는 시간을 줄이라는 이야기입니다. 그리고 일할 때도 좀 더 느긋한 속도로 일하는 게 좋습니다. 저는 특별히 압박이 큰 프로젝트가 없는 한, 기본적으로 가동률 80%를 목표로 삼습니다. 하루 업무 시간의 20%는 컴퓨터에서 떨어져 있는 셈이죠.

임팩트가 큰 기회는 따로 있다

왜 그럴까요? 기술 회사에서의 성과는 예외적인 사건들이 좌우하기 때문입니다. 제가 지금까지 만든 변화 중 가장 임팩트가 컸던 것들을 떠올려 보면, 놀랄 만큼 사소한 작업이었던 경우가 많습니다. 소프트웨어 개발에는 '노력 점수' 같은 게 없습니다. 중요한 건 올바른 문제를, 올바른 시점에 푸는 것입니다.

규모가 큰 엔지니어링 조직에는 마음만 먹으면 할 수 있는 아주 사소한 작업인데도, 회사에 수천만에서 수억 달러를 벌어다 줄 수 있는 일들이 늘 존재합니다. 흔한 예시를 세 가지만 들어 보겠습니다.

• 첫째, 회사가 큰 규모의 엔터프라이즈 계약을 성사시키려 할 때, 기능 하나나 버그 수정 하나로 그 계약을 성사시킬 수 있습니다. 그 기능이 굳이 훌륭할 필요도 없습니다. 그저 구체적인 변경을 기꺼이, 그리고 실제로 만들어 낼 수 있다는 걸 보여 주는 것만으로 충분할 때도 있습니다.
• 둘째, 장애를 초기에 막거나 완화하면(그저 어떤 기능 플래그를 꺼야 하는지 아는 것만으로도) 막대한 비용을 아낄 수 있습니다. 장애가 진행되는 동안 당장 날아가는 매출은 물론, 그 일로 거래를 끊거나 검토 중이던 계약을 거절했을 고객에게서 미래에 잃었을 매출까지 아끼는 셈입니다.
• 셋째, 회사가 주목도 높은 기능을 출시하려 할 때, 그 성패는 사소하지만 아무도 잘 모르는 변경에 달려 있는 경우가 많습니다(예를 들어, 사용자 설정에 새 필드를 재빨리 추가하는 능력, 혹은 몇 년째 아무도 손대지 않은 낡은 엔터프라이즈 데이터 내보내기 기능을 업데이트하는 능력이 그렇습니다). 시스템에 익숙한지 아닌지에 따라, 이런 변경이 몇 시간짜리 일이 되기도 하고 일주일짜리 일이 되기도 합니다.

이 예시들의 공통점은 무엇일까요? 모두 시점에 달려 있다는 것입니다. 아침에 로그인해서 "자, 오늘은 큰 계약을 풀어 볼까" 하거나, 장애를 완화하거나, 주목도 높은 기능의 개발 속도를 끌어올리겠다고 마음먹는다고 되는 일이 아닙니다. 그러면 그저 운 좋게 적절한 때 적절한 자리에 있으면 되는 문제일까요? 꼭 그렇지만은 않습니다. 여기에 더해, 당신이 이미 바쁘지 않아야 합니다.

여유를 남겨 두기

몇 년 전에 저는 이 주제를 다룬 글을 쓴 적이 있습니다. 늘 100% 가동률로 우선순위 낮은 일을 끊임없이 처리하고 있다면(예를 들어, 백로그에서 티켓을 하나 집어 쳐내고, 또 하나 집어 쳐내기를 반복한다면), 두 가지 방식으로 임팩트가 큰 일을 할 기회를 놓치게 됩니다.

첫째, 너무 바빠서 그런 기회를 알아차리지도 못합니다. 다른 일을 하는 사람들과 이야기를 나누거나, 팀 업데이트를 읽거나, 진행 중인 장애를 눈여겨볼 여유가 없기 때문입니다. 그래서 임팩트가 큰 일에 발을 들이는 가장 좋은 방법, 즉 자기 전문성을 자발적으로 내미는 기회를 날려 버리게 됩니다.

둘째, 늘 바빠 보이면 매니저도 당신을 끌어들이려 하지 않습니다. 이것이 임팩트 큰 일에 참여하는 두 번째로 좋은 방법인데요. 매니저나 프로덕트 매니저가 "아, 이건 션이 도와줄 여력이 있겠네. 불러 볼까" 하고 말해 주는 것 말입니다. 이 방법이 왜 더 좋을까요? 매니저와 프로덕트 매니저는 지금 어떤 임팩트 큰 일이 벌어지고 있는지 대체로 훨씬 잘 파악하고 있기 때문입니다. 그들은 당신이 들어가지 않는 회의에 들어가 있습니다.

아무것도 안 하기

임팩트 큰 일을 위해 시간을 비워 둬야 하고, 그렇다고 티켓만 갈아 넣어서도 안 된다면, 분 단위로 도대체 무엇을 하고 있어야 할까요? 그냥 아무것도 안 하고 있어야 할까요? 그렇습니다. 아무것도 안 하는 건 사실 좋은 일입니다. 소프트웨어 엔지니어링은 스트레스가 큰 직업일 수 있지만, 대개 그 스트레스가 지속적이지는 않습니다. 스트레스는 이따금 터지는 장애나, 압박이 큰 급한 작업, 혹은 (요즘이라면) 정리해고 같은 데서 옵니다. 비교적 압박이 적은 일까지 급박한 강도로 밀어붙인다면, 정작 압박이 큰 일을 다뤄야 할 때는 이미 지치고 신경이 곤두선 상태일 겁니다.

압박이 큰 일을 할 때조차 아무것도 안 하는 게 좋을 수 있습니다. 온콜을 처음 맡는 엔지니어에게 제가 권하는 것 하나는 서두르지 말라는 겁니다. 통화에 참여하기 전이나 입을 열기 전에 숨을 몇 번 고르고, 전반적으로 "슬로모션으로 생각하기"를 시도해 보시기 바랍니다. 대부분의 장애는 알아서 해결됩니다. 그리고 장애가 진행되는 동안 다급하게 던지는 "이러면 나아질지도" 식의 변경은 대부분 상황을 낫게 하기는커녕 악화시킵니다. 원칙적으로, 그저 패닉에 빠지지 않는 것만으로도 당신은 이미 대다수 엔지니어보다 장애 대응을 잘하고 있는 셈입니다.

'아무것도 아닌 것(nothing)'은 무언가가 일어날 수 있는 공간입니다. 뇌에 쉴 틈을 주면, 새로운 아이디어가 떠오를 가능성이 더 커집니다. 누군가 중요한 일을 맡기면, (뒤에서 돌리고 있던 다른 세 가지 일과 저글링하는 대신) 온전히 집중해서 그 일에 달려들 수 있습니다. 바쁘지 않을 때, 그저 이것저것 바라보며 새로운 정보를 받아들일 시간이 생깁니다.

어떤 일은 일부러 하지 않기

많은 엔지니어가 해야 할 일이 눈앞에 보이는데도 하지 않는 상태를 불편해합니다. 저도 그렇습니다. “나는 쓸모 있는 사람이 되는 것에 중독됐다”라는 글에서 이 이야기를 쓴 적이 있는데요. 많은 소프트웨어 엔지니어가 공유하는 심리적 특성인데, (어느 정도까지는) 바로 그 특성 덕분에 이 직업에 잘 맞기 때문입니다. 아무것도 안 하는 시간을 보내려면, 때로는 나서지 않도록 스스로를 억눌러야 합니다.

예를 들어, 저는 엔지니어가 대체로 글루 워크(glue work, 조직이 원활하게 굴러가도록 돕는 필수적이지만 눈에 잘 띄지 않는 업무)를 피해야 한다고 믿습니다. 사람들이 서로 대화하도록 챙기고, 자기가 이끌지도 않는 일의 문서를 업데이트하고, 기술 부채를 해결하겠다고 자원하는 것 같은 접착 작업 대부분은, 조직이 그 일을 명시적으로 우선순위에 두지 않았다는 사실을 반영합니다. 

정말 중요하게 여겼다면 당신이 자원할 필요도 없었을 것입니다. 이 상황은 둘 중 하나입니다. 그래도 괜찮은 상황이거나, 아니면 큰 실수이거나. 괜찮은 상황이라면, 나서서 그 일을 해서는 안 됩니다. 시간을 낭비하고 매니저를 성가시게 할 뿐이니까요. 반대로 큰 실수라면, 그래도 그 일을 해서는 안 됩니다. 당신의 커리어와 정신 건강을 대가로, 회사가 자기 실수의 결과를 느끼지 못하도록 감싸 주는 꼴이 되기 때문입니다.

그건 당신에게 손해인 거래일뿐더러, 후배들에게 나쁜 본보기가 되고, 당신이 결국 번아웃으로 쓰러졌을 때 누군가 똑같은 자리에 뛰어들도록 만드는 나쁜 선례가 됩니다. 결과가 정말로 심각하다면, 그냥 벌어지게 두시기 바랍니다. 그래야 조직이 그 고통을 느끼고 방침을 바꿉니다. (왜 필연적일까요? 제 생각에 번아웃은 보상받지 못하는 고된 노동이고, 직장에서 신경 쓰지 않는 사적인 대의를 위해 나서는 것은 보상받지 못하는 일을 많이 하게 되는 지름길이기 때문입니다.)

또한 저는 너무 도움이 되려 하면 포식자에게 취약해진다고 믿습니다. IT 회사에는 소프트웨어 엔지니어에게서 보상 없는 노동을 뽑아내려는 사람들이 넘쳐납니다. (이 주제에 대한 참고 글) 이것은 정상적인 경로로 들어와 승진과 보너스(그리고 그냥 당신의 정규 급여)로 보상받는 일과는 다릅니다. 제가 말하는 것은 뒷경로로 들어오는 일, 즉 그 작업을 당신 이름으로 공식 기록에 남길 능력도 의향도 없는 사람들에게서 오는 일입니다. 

예를 들어, 다른 조직의 프로덕트 매니저가 "데이터 쿼리 정말 잘하시던데, X에 대한 통계 좀 뽑아 주실 수 있을까요?"라고 메시지를 보내는 경우, 혹은 다른 팀 엔지니어가 "페어로 같이 하자"고 청하지만 결국 코드는 당신이 다 짜고 변경은 그 사람이 조용히 자기 이름으로 제출하는 경우입니다.

이런 일을 어느 정도 하는 건 괜찮습니다. 도울 수 있을 때 남을 돕는 것도 나쁘지 않으니까요. 하지만 역압(backpressure)을 걸 줄 알아야 합니다. 거절하든지, 아니면 그냥 답을 몇 시간이나 며칠 미루든지 하는 식으로 말입니다.

어차피 사라질 가능성이 큰 일에 너무 많이 투자하지 않는 것도 좋은 자세입니다. 예를 들어, 무엇을 원하는지 실시간으로 정해 가는 프로덕트 디자이너와 일한다고 해 보겠습니다. 오전 9시에 페이지 헤더를 이렇게 해 달라고 하고, 10시에 손을 좀 보고, 11시에 또 바꾸고, 계속 이런 식입니다. 이럴 때 매시간 페이지를 처음부터 다시 짜는 데 몸을 던지면 안 됩니다. 대신 아무것도 하지 말고(산책을 다녀오거나), 오후에 가장 최근 디자인을 기준으로 페이지를 한 번만 다시 짜야 합니다. 

또 비슷한 경우로는 "밀어붙일 영향력은 없는 매니저의 거창한 아이디어"가 있는데요. 이럴 땐 그 프로젝트가 결국 취소될 때까지 그냥 시간을 흘려보내면 됩니다. (물론 이 전략을 사용할 때는 주의해야 합니다. 만약 이 전략을 시도했는데 프로젝트에 대한 영향력 수준에 대해 잘못 판단했다면, 게으른 사람처럼 보일 거고, 결국에는 급하게 결과물을 내놓아야 할 겁니다.)

마치며

소프트웨어 엔지니어링에 관한 조언과 도구들은 대부분 기술적 노력을 확장하는 능력을 키우는 데 초점을 맞춥니다. 동시에 더 많은 일을 하거나, 더 큰 범위의 프로젝트를 맡고, 그냥 코드를 더 많이 짜는 능력 말이죠. 하지만 소프트웨어 엔지니어링의 성공은 이런 것들로 결정되지 않습니다. 성공은 적절한 시기에 적절한 일을 해내는 능력으로 결정되며, 그러려면 평소 업무에서는 자기 역량의 일부를 의도적으로 아껴둬야 합니다.

제 경험상, 80%의 노력만으로도 여전히 "뛰어난 성과를 내는 엔지니어"가 되는 것은 가능합니다. 오히려 더 쉽습니다. 스트레스 때문에 어이없는 실수를 저지를 가능성이 줄고, 큰 보상을 주는 임팩트 있는 업무에 더 적극적으로 참여할 수 있기 때문이죠.

그렇다고 100%의 노력을 절대 하지 말라는 뜻은 아닙니다. 저도 1년에 두세 번쯤은 낼 수 있는 최대한으로 열심히 일합니다. 긴 시간 일하고, 온 힘을 다해 집중하며, 눈뜰 때부터 잠들 때까지 그 문제에 대해 생각하죠. 다만 저는 이런 방식은 보상이 정말로 클 때만 사용합니다. 나머지 기간에는 비교적 여유롭게 일하고요.

덧붙임: 이 글은 해커뉴스(Hacker News)에서 몇 가지 댓글을 받았습니다. 댓글에서는 여유 시간을 확보할 때 매니저와 문제가 생기지 않으려면 어떻게 해야 하는지(제 경험상 대체로 생산적이기만 하면 괜찮지만, 매니저마다 편차가 큽니다), 그리고 엔지니어가 정말로 자기 업무량을 통제할 수 있는지 등을 논의했습니다. 참고해 보세요!

<원문>

Doing nothing at work
 

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.