---
title: "일을 덜 해야 더 큰 일을 잡는다는 엔지니어 생산성론"
published: 2026-06-08T08:57:11.000Z
canonical: https://jeff.news/article/4045
---
# 일을 덜 해야 더 큰 일을 잡는다는 엔지니어 생산성론

글쓴이는 엔지니어가 평소 100%로 꽉 차게 일하면 오히려 큰 임팩트 기회를 놓친다고 주장한다. 기본 80% 정도의 여유를 남겨야 대형 계약, 장애 대응, 고우선순위 출시 같은 순간에 바로 뛰어들 수 있다는 이야기다.

- 글쓴이는 많은 엔지니어가 일을 좀 덜 해야 한다고 주장함
  - 코드나 변경량을 줄이라는 뜻이 아니라, 실제 근무 시간과 속도를 의도적으로 낮추라는 얘기임
  - 본인은 평소 80% utilization을 목표로 하고, 고압 프로젝트가 없으면 하루의 20% 정도는 컴퓨터에서 떨어져 보낸다고 함

- 이유는 소프트웨어 개발 성과가 노력량보다 ‘이상치 이벤트’에 크게 좌우되기 때문임
  - 큰 엔터프라이즈 계약 직전에 작은 기능이나 버그픽스를 도와주면 계약 성사에 영향을 줄 수 있음
  - 장애 초기에 적절한 feature flag 하나를 끄는 것만으로 매출 손실과 고객 이탈을 막을 수 있음
  - 고프로필 기능 출시도 오래된 설정 화면에 필드 하나 추가하는 식의 사소하지만 난해한 변경에 막히는 경우가 있음

- 이런 일들의 공통점은 전부 타이밍 의존적이라는 점임
  - 아침에 로그인해서 ‘오늘은 대형 계약을 살려야지’ 하고 정할 수 있는 일이 아님
  - 기회가 보일 때 알아차리고, 바로 움직일 여유가 있어야 함
  - 이미 낮은 우선순위 티켓으로 꽉 차 있으면 그 순간을 놓침

- 백로그 티켓을 계속 갈아 넣는 방식은 두 가지로 손해를 만듦
  - 첫째, 다른 팀 업데이트를 읽거나 사고 상황을 지켜보거나 사람들과 대화할 시간이 없어져서 기회를 못 봄
  - 둘째, 항상 바빠 보이면 매니저나 PM도 “저 사람에게 맡기자”라고 생각하기 어려움
  - 매니저와 PM은 엔지니어가 들어가지 않는 회의에 있기 때문에, 어디에 임팩트가 있는지 더 잘 알고 있을 때가 많음

> [!TIP]
> 고성과는 항상 바쁜 상태가 아니라, 중요한 일이 생겼을 때 바로 주의를 전환할 수 있는 상태에서 나오기도 함. 특히 큰 조직일수록 ‘빈 시간’은 낭비가 아니라 옵션값에 가까움.

- ‘아무것도 안 하기’는 실제로 쓸모가 있다고 봄
  - 소프트웨어 엔지니어링은 항상 스트레스가 높은 직업이라기보다, 장애·긴급 작업·해고 같은 순간에 스트레스가 몰리는 직업임
  - 평소 낮은 압력의 일까지 긴급 모드로 처리하면 진짜 고압 상황에서 이미 지쳐 있음
  - 온콜 초보에게도 바로 뛰어들기보다 몇 번 숨을 쉬고 천천히 생각하라고 조언함

- 장애 대응에서도 느린 사고가 더 나을 때가 많음
  - 대부분의 사고는 어느 정도 스스로 안정화되거나, 최소한 무작정 바꾸는 것보다 관찰이 먼저임
  - 패닉 상태에서 던지는 “이거라도 해보자” 식 변경은 상황을 더 악화시키는 경우가 많음
  - 글쓴이는 단순히 패닉하지 않는 것만으로도 많은 엔지니어보다 나은 사고 대응을 할 수 있다고 봄

- 모든 빈틈을 글루 워크로 채우는 것도 경계함
  - 팀 간 조율, 본인이 리드하지 않는 문서 업데이트, 아무도 우선순위로 잡지 않은 기술부채 정리 같은 일이 대표적임
  - 조직이 정말 중요하게 여겼다면 공식적으로 우선순위를 줬을 것이고, 그렇지 않다면 개인이 몰래 떠안는 건 커리어와 멘탈에 나쁜 거래라는 설명임
  - 심각한 문제라면 조직이 고통을 느끼고 정책을 바꾸게 둬야 한다는 꽤 센 주장도 함

- 너무 친절한 엔지니어는 비공식 요청에 빨려 들어가기 쉬움
  - 다른 조직 PM이 “통계 좀 뽑아줄 수 있냐”고 DM하거나, 다른 팀 엔지니어가 pair를 요청해놓고 실제 코드는 전부 떠넘기는 식임
  - 이런 도움을 아예 하지 말라는 건 아니지만, 거절하거나 몇 시간·며칠 늦게 응답하는 backpressure가 필요하다고 말함
  - 공식 기록과 보상이 따라오지 않는 일로 하루가 잠식되면, 정작 본인 성과로 남는 일은 줄어듦

- 사라질 가능성이 큰 일에는 너무 빨리 뛰어들지 말라는 조언도 현실적임
  - 디자이너가 오전 9시, 10시, 11시에 계속 헤더 디자인을 바꾸고 있다면 매번 페이지를 다시 짤 필요가 없음
  - 오후에 최신 디자인 기준으로 한 번 반영하는 편이 낫다는 것임
  - 정치적 힘이 약한 매니저의 큰 아이디어도 시간이 지나면 취소될 수 있으니, 무조건 즉시 몰입하는 건 위험함

- 결론은 ‘항상 100%로 갈아 넣지 말라’임
  - 소프트웨어 엔지니어링 성공은 더 많은 기술적 노력을 동시에 쏟는 능력보다, 맞는 문제를 맞는 시점에 푸는 능력에 좌우됨
  - 글쓴이는 80% 노력으로도 high-performing engineer가 가능하고, 오히려 실수와 번아웃이 줄어 더 쉽다고 봄
  - 다만 1년에 두세 번 정도는 정말 보상이 큰 상황에서 100%로 몰입하는 모드를 예약해둔다고 함

## 핵심 포인트

- 소프트웨어 개발에서 노력량보다 중요한 건 적절한 타이밍에 맞는 문제를 푸는 것
- 백로그 티켓을 계속 처리하면 고임팩트 기회를 알아차리거나 맡을 여유가 사라짐
- 장애 대응에서는 서두르는 변경보다 침착하게 생각하고 패닉을 피하는 게 더 낫다는 주장
- 글루 워크나 보상받지 못하는 백채널 요청에는 의도적으로 압력을 걸어야 함
- 1년에 몇 번은 100% 몰입하되, 평소에는 80% 상태를 유지하는 게 지속 가능한 고성과라는 결론

## 인사이트

이 글은 ‘게으르게 일하라’가 아니라, 회사에서 실제로 보상받고 영향이 큰 일은 예측 불가능하게 튀어나온다는 현실론에 가깝다. 특히 시니어 엔지니어일수록 바쁘게 보이는 것보다 여유 있게 잡아낼 수 있는 문제의 크기가 더 중요해진다.