본문 바로가기
IT/소프트웨어

IT 개발자 업무 효율, 80%만 일해야 고성과를 내는 역설적인 이유

by DrKo83 2026. 7. 14.
300x250
반응형

AI 시대 개발자, 왜 80%만 일해야 성과가 오를까? 💡

요즘IT 커뮤니티에서 꽤 시끄러운 이야기가 하나 있어요. "많이 일할수록 성과가 오른다"는 오래된 믹임이 사실은 틀렸다는 겁니다. 그것도 실리콘밸리 시니어 엔지니어가 직접 한 말이라 더 화제가 됐어요.

저도 처음 이 이야기를 들었을 때 살짝 의아했습니다. 코딩량, 티켓 처리 건수, 야근 시간이 곧 성과라고 배워온 사람들에게는 꽤 도발적인 주장이잖아요. 그런데 GitHub 엔지니어 션 괴데케가 쓴 "Doing nothing at work"라는 글을 읽어보니, 이게 단순한 게으름 예찬이 아니었습니다. 오늘은 이 내용을 한국 IT 현장에 맞게 풀어볼게요.

80% 업무 원칙이란 무엇인가

핵심은 간단합니다. 하루 업무 시간의 20퍼센트는 의도적으로 비워두는 겁니다. 코딩, 티켓 처리, 회의 준비 같은 정해진 일에 100퍼센트를 다 쏟지 않는 거예요.

그런데 이게 말처럼 쉽지가 않아요. 개발자들은 대부분 쓸모 있는 사람이 되고 싶은 마음이 강하거든요. 백로그에 티켓이 쌓여 있으면 손이 근질거리고, 옆 팀이 힘들어 보이면 자연스럽게 도와주러 가고 싶어집니다. 그 마음 자체는 좋은 개발자의 특성이지만, 무조건 발현되면 오히려 독이 됩니다.

한 줄 정리하면, 80퍼센트만 일하는 건 게으름이 아니라 결정적인 순간에 100퍼센트를 쓰기 위한 전략적 여유라는 거예요.

성과는 노력의 총량이 아니라 타이밍에서 나온다

이 원칙의 핵심 논리는 이렇습니다. 테크 회사에서의 성과는 얼마나 꾸준히 일했느냐보다, 결정적인 순간에 무엇을 했느냐로 결정된다는 거예요.

예를 들어볼게요. 큰 거래가 성사되기 직전에 핵심 기능 하나를 빠르게 구현해서 계약을 성사시키는 경우, 개발 자체는 몇 시간이면 되는데 임팩트는 수백억 원 단위입니다. 서비스 장애가 터졌을 때 시스템을 잘 아는 사람이 피처 플래그 하나를 재빨리 꺼서 장애를 조기에 막는 경우도 마찬가지예요. 수억 원의 손실을 수십 분 만에 막는 겁니다.

공통점이 보이시나요? 모두 시간에 종속된 기회입니다. 아침에 출근해서 오늘 큰 임팩트를 내겠다고 결심한다고 되는 일이 아니에요. 기회가 왔을 때 그걸 알아보고 즉시 뛰어들 수 있는 여유가 있어야 합니다.

항상 100% 바쁜 사람이 기회를 놓치는 이유

백로그 티켓을 꺼내서 처리하고, 또 꺼내서 처리하는 방식으로 늘 꽉 차게 일하는 개발자는 두 가지 방식으로 고임팩트 기회를 놓칩니다.

첫째, 기회 자체를 인지하지 못해요. 다른 팀에서 무슨 일이 벌어지는지, 어디서 장애가 생기려는지 알아채려면 여유가 있어야 하거든요. 둘째, 매니저가 나를 떠올리지 않습니다. 항상 뭔가에 치여 있어 보이는 사람에게 도움을 요청하는 리더는 없어요. 반면 약간 여유 있어 보이는 사람은 자연스럽게 레이더에 들어옵니다.

저장하고 싶은 문장이 하나 나오네요. 항상 바빠 보이면, 좋은 기회가 와도 당신에게 올라오지 않습니다.

아무것도 안 하는 시간이 실제로 왜 좋은가

여기가 가장 반직관적인 부분이에요. 개발 업무의 스트레스는 일정하지 않습니다. 평소엔 조용하다가 장애나 급한 프로젝트가 생기면 갑자기 고강도 집중이 필요한 순간이 옵니다. 평소에 이미 100퍼센트로 달리고 있었다면, 정작 그 순간엔 지치고 예민한 상태로 대응하게 되는 거죠.

장애 대응이 좋은 예시입니다. 신입 개발자들이 인시던트 콜에 합류하면 패닉 상태로 이것저것 변경 사항을 마구 적용하는 경우가 많은데, 사실 대부분의 장애는 침착하게 원인을 찾아보면 단순한 경우가 많아요. 오히려 서두르다가 추가 장애를 만드는 경우가 더 흔합니다.

여유 있는 뇌는 새로운 아이디어를 냅니다. 중요한 문제를 맡았을 때 온전히 집중할 수 있고, 데이터를 있는 그대로 볼 여유도 생깁니다.

의도적으로 하지 말아야 할 세 가지

이 부분은 한국 IT 환경에서 특히 공감될 것 같아요.

먼저 글루 워크를 스스로 자처하지 마세요. 팀이 돌아가도록 붙여주는 잡다한 작업들, 예를 들면 내가 주도하지 않는 프로젝트의 문서를 업데이트하거나 아무도 신경 안 쓰는 기술 부채를 자원해서 처리하는 일들이요. 이게 필요하다면 조직이 공식적으로 우선순위를 둬야 합니다. 개인이 자원해서 하는 순간, 조직은 문제가 없다고 착각하고 그 비용은 본인의 번아웃으로 쌓입니다.

다음으로 비공식 백채널로 들어오는 무보상 업무를 조심하세요. 데이터 좀 뽑아줄 수 있냐, 잠깐 같이 봐줄 수 있냐 같은 요청들이요. 반복되면 내 시간과 에너지를 가져가는 구조가 됩니다.

마지막으로 취소될 가능성이 높은 일에 전력투구하지 마세요. 시안이 하루에도 몇 번씩 바뀌는 상황이라면, 매번 전면 재구현하지 않아도 됩니다. 최신 시안으로 한 번만 구현하면 충분해요.

한국 IT 개발자가 특히 주목해야 하는 이유

한국의 IT 직장 문화는 여전히 빨리빨리와 성실하게 오래를 미덕으로 봅니다. 그런데 최근 데이터를 보면 이야기가 좀 다릅니다. 스탠퍼드 AI 인덱스 2026을 인용한 분석에 따르면 미국에서 22~25세 소프트웨어 개발자 고용이 2022년 후반 정점 대비 약 20% 감소했다고 해요. 반면 시니어 인력에 대한 수요는 오히려 늘고 있습니다.

이유가 흥미롭습니다. AI가 특정 직업 전체를 없애는 게 아니라, 그 직업 안에서 주니어가 담당하던 반복적 코드 작성이나 버그 수정 같은 업무를 흡수하고 있다는 거예요. 반면 아키텍처 설계나 비즈니스 요구사항 해석처럼 시니어가 담당하는 영역은 아직 AI가 대신하지 못합니다. PwC가 2026년 6월 발표한 조사에서도 AI 노출이 높은 신입 직무일수록 리더십이나 대면 소통 같은 전통적인 시니어급 역량을 요구할 확률이 7배 높다고 나왔어요. 결국 기업이 22살에게 35살 수준의 판단력을 요구하기 시작한 셈이죠.

국내에서도 비슷한 흐름이 보입니다. 한 국회 간담회에서 나온 분석에 따르면 이미 주니어 엔지니어 채용이 급감하는 등 인력 감소가 현실화되고 있다는 진단이 나왔어요.

시니어 개발자는 결국 코드를 많이 짜는 사람이 아니라, 맥락을 읽고 올바른 문제를 골라내고 결정적인 순간에 집중력을 발휘하는 사람입니다. AI가 코딩의 상당 부분을 대체해 가는 지금, 개발자의 가치는 얼마나 많은 코드를 짰느냐가 아니라 언제 어떤 판단을 내렸느냐로 옮겨가고 있는 거예요.

사람들이 가장 많이 놓치는 부분, 바쁜 척의 함정

많은 개발자들이 실제로 고임팩트 업무보다 성실해 보이는 업무를 선택합니다. 이유는 간단해요. 전자는 보상이 불확실하고, 후자는 즉각적인 안도감을 줍니다.

티켓을 꺼내서 처리하면 완료 표시가 뜨고 진척이 눈에 보이죠. 반면 다음 주에 올 수도 있는 중요한 기회를 위해 지금 여유를 남겨두는 건 눈에 보이지 않아요. 그래서 불안하고, 계속 바쁘게 움직이게 됩니다.

괴데케는 연간 두세 번 정도는 정말 전력을 다해 일한다고 말합니다. 하지만 그런 모드는 보상이 정말 높을 때를 위해 아껴두고, 나머지 시간에는 비교적 편하게 지낸다는 거예요. 항상 전력질주하는 사람은 결승선에서 지쳐 있습니다. 속도를 조절하는 사람이 마지막에 웃습니다.

마무리

AI 코딩 도구가 보편화되면서 개발자의 단순 구현 업무는 빠르게 자동화되고 있습니다. 이런 흐름에서 80퍼센트 업무 원칙은 더 중요해집니다. AI가 코드를 대신 짜줄 수 있다면, 개발자의 핵심 역량은 언제 어디에 힘을 쓸지 판단하는 능력으로 이동하니까요.

번아웃 예방 관점에서도 마찬가지입니다. 항상 최대치로 달리는 개발자는 결국 소진됩니다. 오늘 업무 목록에서 20퍼센트를 의도적으로 비워두는 것부터 시작해 보세요. 그 여백이 다음 커리어 하이라이트를 만들어 줄 수 있습니다.

300x250
반응형