회사에서 아무것도 안 하기

게시일: 2026년 6월 8일 | 원문 작성일: 2026년 6월 8일 | 저자: Sean Goedecke | 원문 보기

많은 엔지니어가 일을 좀 덜 해야 해요. 코드를 덜 짜거나 변경을 덜 하라는 뜻이 꼭 아니라, 말 그대로 하루에 일하는 시간을 줄이라는 거예요. 그리고 일할 때도 좀 더 느린 속도로 일하는 게 좋아요. 저는 기본적으로 가동률 80%로 굴러가는 걸 목표로 삼는 편이에요. 압박이 심한 프로젝트가 걸려 있지 않은 한, 저는 근무 시간의 20%는 컴퓨터에서 떨어져서 보내요.

• • •

고임팩트 기회

왜냐고요? 테크 회사에서의 성과는 아웃라이어(outlier) 사건에 의해 좌우되거든요. 제가 지금까지 만들어낸 가장 임팩트 있는 변화들을 떠올려 보면, 그중 상당수는 의외로 사소한 양의 작업이었어요. 소프트웨어 개발에서는 노력에 대해 점수를 주지 않아요. 중요한 건 올바른 타이밍에 올바른 문제를 푸는 거죠.

큰 엔지니어링 조직에는 보통, 해내기만 하면 회사에 수천만에서 수억 달러를 벌어다 줄 사소한 엔지니어링 작업들이 굴러다녀요. 흔한 예를 세 가지 들어볼게요.

첫째, 회사가 큰 엔터프라이즈 계약을 체결하려 할 때, 기능 하나나 버그 수정을 들고 끼어드는 것만으로 그 계약을 성사시킬 수 있어요. 심지어 그게 좋은 기능일 필요도 없어요. 때로는 구체적인 변경을 기꺼이, 그리고 충분히 만들어낼 수 있다는 걸 보여주는 것만으로 충분하거든요.

둘째, 장애를 초기에 예방하거나 완화하는 것(끄면 되는 기능 플래그(feature flag)를 알고 있는 정도만으로도)은 엄청난 돈을 아낄 수 있어요. 장애가 지속되는 동안의 즉각적인 매출 손실은 물론, 미래의 매출 손실까지 말이에요. 장애만 없었다면 거래를 계속 이어 가거나 예정된 계약에 서명했을 고객들, 바로 그들에게서 들어왔을 돈이니까요.

셋째, 회사가 주목도 높은 기능을 출시하려 할 때, 그 성패는 사소하지만 잘 알려지지 않은 변경에 달려 있는 경우가 많아요(예를 들면, 사용자 설정에 새 필드를 빠르게 추가하는 능력이라든가, 몇 년 동안 아무도 손대지 않은 낡아빠진 엔터프라이즈 데이터 익스포트 기능을 업데이트하는 일이라든가요). 시스템에 대한 익숙함이, 이런 변경을 몇 시간 만에 끝낼지 아니면 일주일을 통째로 잡아먹을지를 가르는 차이가 될 수 있어요.

이 예들의 공통점은 뭘까요? 전부 타이밍에 달려 있다는 거예요. 아침에 로그인해서 “오늘은 큰 계약을 풀어줘야지”, “장애를 완화해야지”, “주목도 높은 기능을 빨리 끝내야지” 하고 마음먹는다고 되는 게 아니에요. 그렇다면 그냥 적절한 때에 적절한 자리에 있느냐의 문제일 뿐일까요? 꼭 그렇지만은 않아요. 한 가지 조건이 더 붙거든요.

적절한 자리에 있는 것만으로는 부족해요. 이미 바빠서는 안 된다는 조건도 충족해야 하거든요.

• • •

여유를 두기

저는 이 이야기를 몇 년 전에 JIRA 티켓을 쳐내는 건 임팩트로 가는 길이 아니라 파티에서 보여주는 잔재주다라는 글에서 한 적이 있어요. 만약 여러분이 늘 낮은 우선순위의 일을 끊임없이 처리하느라 가동률 100%로 돌아가고 있다면(예를 들어 백로그에서 티켓을 하나 집어 쳐내고, 또 다음 걸 집어 드는 식이라면), 고임팩트 업무를 할 기회를 두 가지 방식으로 놓치게 됩니다.

첫째, 너무 바빠서 그런 기회를 알아차릴 여유조차 없어요. 다른 일을 하는 사람들과 잡담을 나누거나, 팀 업데이트를 읽거나, 진행 중인 장애를 살펴볼 틈이 없는 거죠. 그래서 고임팩트 업무에 참여하는 가장 좋은 방법, 즉 자기 전문성을 자발적으로 내미는 길을 놓치게 됩니다.

둘째, 늘 바빠 보이면 여러분의 매니저가 여러분을 끼워 넣고 싶어 하지 않아요. 이게 고임팩트 업무에 참여하는 두 번째로 좋은 방법인데요, 매니저나 프로덕트 매니저(PM)가 “아, Sean이 여기 도와줄 여력이 있겠네, 한번 태그해 보자”라고 말해 주는 거예요. 왜 이게 더 좋을까요? 매니저와 프로덕트 매니저(PM)는 보통 어떤 고임팩트 업무가 돌아가고 있는지를 훨씬 잘 파악하고 있거든요. 그들은 여러분이 들어가지 못하는 회의에 들어가 있으니까요.

• • •

아무것도 안 하기

고임팩트 업무를 위해 시간을 비워둬야 하고, 그렇다고 티켓만 갈아 넣어서도 안 된다면, 분 단위로 보면 도대체 뭘 하고 있어야 할까요? 그냥 아무것도 안 하면 될까요? 네, 맞아요!

아무것도 안 하는 건, 사실 좋은 일이에요. 소프트웨어 엔지니어링은 스트레스가 많은 일일 수 있지만, 보통 지속적으로 스트레스가 심하지는 않아요. 스트레스는 가끔 터지는 장애나, 압박이 큰 급한 업무, 아니면 (요즘 같으면) 정리해고에서 오죠. 비교적 압박이 덜한 업무를 급박한 강도로 처리하다 보면, 정작 압박이 큰 업무를 다뤄야 할 때 이미 지치고 너덜너덜해진 상태가 되어버려요.

압박이 큰 업무라 해도 아무것도 안 하는 게 여전히 좋을 수 있어요.

아무것도 아닌 상태(nothing)는 무언가가 일어날 수 있는 공간이에요¹. 뇌에 쉴 틈을 주면, 새로운 아이디어가 떠오를 가능성이 더 높아진다는 걸 알게 될 거예요. 누군가 중요한 일을 맡기면, (백그라운드에서 돌리던 다른 세 가지 일과 함께 저글링하듯 굴리는 대신) 온전히 집중해서 그 일에 매달릴 수 있어요. 바쁘지 않을 때라야, 그냥 이것저것 들여다보고 새로운 데이터를 받아들일 여유가 생기죠.

• • •

의도적으로 어떤 일은 하지 않기

많은 엔지니어가 해야 할 일이 눈에 보이는데도 그걸 안 하고 넘어가는 걸 불편해해요. 저도 그래요. 이 얘기는 쓸모 있는 사람이 되는 것에 중독됐어요라는 글에서 다룬 적이 있어요. 많은 소프트웨어 엔지니어가 공유하는 심리적 버릇인데, 그 버릇이 (어느 정도까지는) 여러분을 이 일에 잘 맞는 사람으로 만들어 주기 때문이에요. 아무것도 안 하는 시간을 확보하려면, 때로는 끼어들지 않도록 스스로를 억눌러야 할 때가 있어요.

예를 들어 저는 엔지니어가 글루 워크(glue work)T2는 대체로 피하는 게 좋다²고 생각해요. 사람들끼리 대화가 오가도록 챙기는 일, 내가 주도하지도 않는 작업의 문서를 업데이트하는 일, 기술 부채를 해결하겠다고 자원하는 일 같은 대부분의 글루 워크는, 조직이 그 일을 명시적으로 우선순위에 두지 않았다는 사실을 보여줘요. 만약 우선순위에 뒀다면, 누가 자원할 필요도 없었겠죠. 그렇다면 둘 중 하나예요. 그래도 괜찮은 일이거나, 아니면 큰 실수거나. 괜찮은 일이라면, 나서서 그걸 하면 안 돼요. 시간만 낭비하고 매니저를 짜증나게 할 뿐이거든요. 큰 실수라면, 그래도 하면 안 돼요. 회사가 자기 실수의 결과를 직접 맞닥뜨리지 않도록 막아 주는 셈인데, 그 대가로 여러분의 커리어와 정신 건강이 갈려 나가니까요.

그건 여러분에게 손해 보는 거래고, 주니어 동료들에게는 나쁜 본보기이며, 여러분이 결국 번아웃됐을 때³ 같은 자리에 또 누군가가 뛰어들도록 만드는 나쁜 선례예요. 만약 그 결과가 정말로 심각하다면, 그냥 일어나게 두세요. 그래야 조직이 고통을 느끼고 정책을 바꿀 수 있어요.

저는 또 너무 도움을 많이 주면 약탈자들에게 취약해진다고 믿어요. 테크 기업에는 소프트웨어 엔지니어에게서 보상 없는 노동을 뽑아내려는 사람들⁴이 가득해요. 이건 정상적인 경로로 들어오는 일, 그러니까 승진과 보너스(그리고 그냥 여러분의 정규 급여)로 보상받는 일과는 달라요. 제가 말하는 건 뒷채널로 들어오는 일이에요. 그 일이 여러분 이름으로 공식 기록에 남도록 챙겨 줄 능력도, 의지도 없는 사람들이 떠넘기는 일이죠. 예를 들면, 다른 조직의 프로덕트 매니저(PM)가 “데이터 쿼리를 정말 잘하시던데, X에 대한 통계 좀 뽑아 주실 수 있을까요?”라고 메시지를 보내는 것, 또는 다른 팀의 엔지니어가 어떤 작업을 같이 “페어”로 하자고 청하지만 결국 코드는 전부 여러분이 작성하고 그 사람은 변경을 슬그머니 자기 이름으로 제출하는 것 같은 일이요.

이런 종류의 일을 어느 정도 하는 건 괜찮아요. 할 수 있을 때 남을 돕는 거야 좋은 일이죠. 하지만 제동을 걸 수 있어야 해요. 거절을 하든, 아니면 그냥 답장을 몇 시간이나 며칠쯤 미루든 말이에요.

사라질 가능성이 큰 일에 너무 많이 투자하지 않는 것도 좋은 생각이에요. 예를 들어, 자기가 원하는 걸 실시간으로 정해 가는 프로덕트 디자이너와 일한다고 해 봐요. 오전 9시에 페이지 헤더를 이렇게 하고 싶다고 메시지를 보내고, 10시에는 수정 사항이 생기고, 11시에 또 바꾸고, 이런 식으로 계속되는 거죠. 매 시간마다 페이지 전체를 다시 짜는 데 자신을 갈아 넣으면 안 돼요. 대신 아무것도 하지 말고(이를테면 산책을 나가고), 오후에 가장 최신 디자인을 바탕으로 페이지를 딱 한 번만 다시 짜야 해요. 이런 일의 또 다른 흔한 사례는 “끝까지 밀어붙일 정치적 영향력은 없는 매니저의 큰 아이디어”예요. 종종 여러분은 그 프로젝트가 결국 취소될 때까지 그냥 시간만 끌면 돼요⁵.

• • •

마치며

소프트웨어 엔지니어링 조언과 도구의 상당수는 기술적 노력을 쏟는 능력을 키우는 데 초점을 맞춰 설계돼 있어요. 동시에 더 많은 일을 처리하고, 더 큰 규모의 프로젝트를 떠맡고, 그냥 코드를 더 많이 짜는 것 말이죠. 하지만 소프트웨어 엔지니어링의 성공은 그런 것들로 결정되지 않아요. 맞는 일을 맞는 타이밍에 하는 능력으로 결정되죠. 그러려면 평소 일할 때 자기 노력의 일부를 의도적으로 아껴 둬야 해요.

제 경험상, 80% 노력으로도 “고성과 엔지니어”가 되는 건 여전히 가능해요. 사실 더 쉬워요. 스트레스 때문에 어이없는 실수를 저지를 가능성이 줄어들고, 또 큰 수익을 가져다주는 고임팩트 업무에 곧바로 뛰어들 수 있는 위치에 서게 되니까요.

그렇다고 100% 노력으로 절대 갈아 넣지 말라는 얘기는 아니에요. 저도 1년에 두세 번 정도는 할 수 있는 한 최대로 열심히 일하는 것 같아요. 긴 근무 시간, 강도 높은 집중, 아침에 눈을 떠서 밤에 잠들 때까지 그 문제만 생각하는 거죠. 다만 저는 이런 모드를 보상이 정말 클 때를 위해 아껴 둬요. 나머지 1년 동안은 비교적 여유롭게 갑니다.