일을 덜 해야 더 큰 일을 잡는다는 엔지니어 생산성론

글쓴이는 많은 엔지니어가 일을 좀 덜 해야 한다고 주장함

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

이유는 소프트웨어 개발 성과가 노력량보다 ‘이상치 이벤트’에 크게 좌우되기 때문임

• 큰 엔터프라이즈 계약 직전에 작은 기능이나 버그픽스를 도와주면 계약 성사에 영향을 줄 수 있음
• 장애 초기에 적절한 feature flag 하나를 끄는 것만으로 매출 손실과 고객 이탈을 막을 수 있음
• 고프로필 기능 출시도 오래된 설정 화면에 필드 하나 추가하는 식의 사소하지만 난해한 변경에 막히는 경우가 있음

이런 일들의 공통점은 전부 타이밍 의존적이라는 점임

• 아침에 로그인해서 ‘오늘은 대형 계약을 살려야지’ 하고 정할 수 있는 일이 아님
• 기회가 보일 때 알아차리고, 바로 움직일 여유가 있어야 함
• 이미 낮은 우선순위 티켓으로 꽉 차 있으면 그 순간을 놓침

백로그 티켓을 계속 갈아 넣는 방식은 두 가지로 손해를 만듦

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

‘아무것도 안 하기’는 실제로 쓸모가 있다고 봄

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

장애 대응에서도 느린 사고가 더 나을 때가 많음

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

모든 빈틈을 글루 워크로 채우는 것도 경계함

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

너무 친절한 엔지니어는 비공식 요청에 빨려 들어가기 쉬움

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

사라질 가능성이 큰 일에는 너무 빨리 뛰어들지 말라는 조언도 현실적임

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

결론은 ‘항상 100%로 갈아 넣지 말라’임

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