본문으로 건너뛰기

번아웃 없이 10년 넘게 살아남는 엔지니어의 루틴

·936 단어수·5 분
작성자
Engineer

솔직히 말하면 나는 번아웃을 두 번 겪었다.

첫 번째는 7년 차 때였다. 하드웨어 스타트업에서 혼자 PCB 설계, 펌웨어, 서버 API까지 맡았던 시기다. 주 70시간씩 일했고, 그게 “열심히 하는 것"이라고 믿었다. 어느 날 아침에 일어났는데 키보드에 손을 올리는 것 자체가 싫었다. 컴퓨터를 켜면 구역질이 날 것 같은 느낌. 2달을 그렇게 버티다가 결국 회사를 나왔다.

두 번째는 11년 차 때다. 이번엔 내가 번아웃인 줄도 몰랐다. 코드는 쓰고 있었고, 회의에도 나갔고, 겉으로는 멀쩡했다. 하지만 새로운 기술을 배우고 싶다는 마음이 완전히 사라졌다. 일은 하는데 아무것도 흥미롭지 않은 상태. 이게 더 위험한 번아웃이다.

그 두 번의 경험 이후에 내가 만든 루틴이다.

번아웃 없는 엔지니어의 하루 루틴

번아웃의 진짜 원인 — 시간 부족이 아니다
#

흔히 번아웃을 “너무 많이 일해서"라고 생각한다. 맞는 말이기도 하지만, 더 정확한 원인은 자율성과 에너지의 불균형이다.

LeadDev의 2025년 엔지니어링 리더십 조사에서 22%의 엔지니어가 심각한 번아웃을 경험했다고 답했다. 그리고 번아웃의 주요 원인 1위는 “더 적은 사람이 더 많은 일을 해야 하는 상황"이었다. 단순히 많이 일하는 게 아니라, 통제할 수 없는 상황에서 강요된 과업이 문제다.

에너지를 쓰는 일에너지를 채우는 일이 있다. 어려운 기술 문제를 푸는 건 에너지를 쓰지만 동시에 채우기도 한다. 하지만 의미 없다고 느끼는 반복 회의, 내가 동의하지 않는 방향의 작업, 아무도 쓰지 않을 기능 구현 — 이것들은 에너지를 빼앗기만 한다. 이 불균형이 오래 지속되면 번아웃이다.

하루 구조 — 에너지 기반 시간 배분
#

“할 일 목록"이 아니라 “에너지 지도"로 하루를 설계한다.

딥 워크 블록 확보
#

아침 7시 30분부터 9시까지 90분이 내 골든 타임이다. 이 시간에 그날 가장 어렵고 중요한 기술 작업을 배치한다. 이메일은 열지 않는다. 슬랙 알림은 끈다.

왜 아침인가? Cal Newport의 딥 워크 연구와도 맞닿아 있지만, 내 개인 경험으로는 아침에는 아직 다른 사람의 요청과 문제가 쌓이기 전 상태이기 때문이다. 오후 3시의 집중력과 오전 8시의 집중력은 체감상 두 배 이상 차이난다.

90분 단위로 쓰는 이유는 인간의 울트라디언 리듬(ultradian rhythm) 때문이다. 약 90분 주기로 집중력의 고점과 저점이 반복된다. 90분 딥 워크 후 15~20분 휴식을 넣으면 오후까지 집중력이 유지된다.

반응적 작업을 몰아서
#

이메일, 슬랙, PR 리뷰, 짧은 질문 답변 — 이것들을 하루에 두 번으로 모은다. 오전 9시와 오후 2시. 이렇게 하면 딥 워크가 끊기지 않는다.

처음 이걸 시작했을 때 팀원들이 “왜 답장이 늦어요?“라고 했다. “딥 워크 블록 때는 2시간 안에 답장이 어렵습니다. 급한 건 전화 주세요"라고 명시적으로 말했다. 실제로 전화가 오는 경우는 극히 드물었다. 대부분의 “긴급한 것들"은 2시간을 기다려도 된다.

강제 종료 시간
#

17시 15분이 업무 종료다. 예외를 허용하지 않는 게 원칙이다. 정말 가끔 크리티컬한 상황에는 예외가 생기지만, 1주일에 한 번 이상이면 이미 뭔가 잘못된 것이다.

강제 종료가 왜 번아웃 방지에 효과적인가? 아이러니하게도 마감이 집중을 만들기 때문이다. 오늘 17시 15분에 무조건 끝난다는 걸 알면, 그 시간 안에 가장 중요한 것을 먼저 한다. 무한정 시간이 있으면 오히려 중요하지 않은 것에 시간을 쓰게 된다.

주간 리듬 — 회복 사이클
#

하루 루틴만큼 중요한 게 주간 리듬이다.

금요일 오후 = 정리 시간
#

금요일 오후 2시부터는 새로운 기술 작업을 시작하지 않는다. 이 시간에 하는 것들:

  • 그 주에 결정한 것들 문서화
  • 다음 주 Top 3 작성
  • 코드 정리, 주석 추가
  • 팀원 1:1 미팅 (짧게)

이렇게 하면 주말에 “월요일에 뭐해야 하지?“라는 불안이 없다. 다음 주 월요일 아침에 바로 딥 워크 블록으로 들어갈 수 있다.

일요일 저녁 = 주간 리뷰
#

30분짜리 개인 리뷰다. 노트 앱(Obsidian)을 열고:

  • 지난 주에 잘 된 것 세 가지
  • 에너지가 드레인된 순간들
  • 다음 주에 집중할 것

번아웃의 초기 신호는 이 주간 리뷰에서 잡힌다. “잘 된 것 세 가지"를 쓰는데 아무것도 생각나지 않거나, “에너지 드레인"이 계속 같은 원인이면 뭔가 바꿔야 한다는 신호다.

번아웃 초기 신호 체크리스트
#

내가 경험으로 만든 자가 진단 목록이다. 아래 항목 중 3개 이상이 해당되면 즉시 뭔가를 바꿔야 한다:

  • 새로운 기술이나 프로젝트에 흥미가 전혀 없다
  • 출근(또는 업무 시작)이 생각만 해도 무거운 기분이다
  • 작은 문제에 과도하게 짜증이 난다
  • 지난 2주간 새로운 걸 배운 기억이 없다
  • 코드 품질에 대한 자기 기준이 낮아지고 있다
  • 팀원들과의 대화가 귀찮다
  • 취미나 운동을 2주 이상 안 했다
  • 잠을 자도 피로가 풀리지 않는다

이 중 하나라도 2주 이상 지속되면 휴가를 내거나, 담당 업무를 줄이거나, 상사와 대화할 것을 강력히 권한다. 버티면 회복 기간이 기하급수적으로 늘어난다.

커리어 지속성을 위한 마인드셋
#

“마라톤이지 100m 달리기가 아니다”
#

13년을 돌아보면, 가장 빠르게 성장했던 시기는 가장 많이 일했던 시기가 아니었다. 오히려 여유가 있어서 새로운 것을 탐색했던 시기였다.

스타트업 초기의 과도한 투입이 의미 없다는 게 아니다. 스프린트가 필요한 시기가 있다. 하지만 그 스프린트 후에는 반드시 회복 기간이 있어야 한다. 계속 스프린트만 하면 마라톤을 완주할 수 없다.

기술적 호기심 유지하기
#

번아웃의 가장 무서운 형태는 기술적 호기심이 죽는 것이다. 새로운 언어를 보면 “어차피 다 비슷해"가 되거나, 새로운 아키텍처를 보면 “그냥 잘 되는 거 쓰지 왜?“가 되는 상태.

이걸 막기 위해 나는 20% 탐색 시간을 의도적으로 만든다. 주간 업무의 약 20%는 현재 프로젝트와 직접 관계없는 탐색에 쓴다. Rust로 토이 프로젝트를 만들거나, 새로운 ML 논문을 읽거나, 이번 블로그처럼 배운 것을 글로 정리하는 것들.

이게 “업무 시간 낭비"가 아닌 이유는, 탐색에서 얻은 것들이 결국 본 업무에 돌아오기 때문이다. 그리고 더 중요하게는, 엔지니어링을 직업으로 지속하게 해주는 원동력이 여기서 나온다.

경계선은 말로 해야 효과가 있다
#

“저는 저녁 6시 이후에는 슬랙을 안 봅니다"를 행동으로만 하면 상대방은 내가 무례하다고 느낄 수 있다. 말로 명시적으로 선언해야 한다.

처음엔 어색하다. 하지만 한번 말하고 나면 오히려 관계가 더 명확해진다. 상대방도 내가 언제 연락 가능한지 알고 그에 맞게 기대를 조정한다. 경계선 없이 모든 시간에 반응하면 단기적으로는 “좋은 팀원"처럼 보이지만, 장기적으로는 소진된다.

10년 이상 버티는 엔지니어가 되려면
#

결국 이 모든 것의 목적은 하나다: 오랫동안 이 일을 좋아하면서 할 수 있는 상태를 유지하는 것.

10년 차가 넘으면 주변에서 번아웃으로 업계를 떠난 사람들을 꽤 많이 보게 된다. 뛰어난 사람들도 있다. 소진은 능력과 관계없다. 구조의 문제다.

그 구조를 바꿀 수 없는 상황이라면 — 회사가 문화를 바꾸지 않는다면 — 결국 다른 환경을 찾는 것이 맞다. 하지만 많은 경우 구조는 내가 생각하는 것보다 더 바꿀 수 있다. 명시적으로 말하기 전까지는.

13년을 해오면서 가장 좋았던 순간들은 모두 에너지가 차 있을 때였다. 어렵고 재미있는 문제를 만났을 때 “이거 한번 파봐야지"라는 느낌이 드는 상태. 그 상태를 유지하는 게 커리어 관리의 본질이라고 생각한다.