To OO님,

번아웃이 온 것 같아서 걱정이 크다는 메일을 보니 예전의 내가 떠오르며 남일 같지 않더라. 나는 대략 3년 정도에 한 번씩 번아웃이 왔었거든. 어떻게 해결했냐고? 백엔드에서 iOS로 직군을 바꿔보기도 했고 이직을 통해 새로운 곳에서 환경과 업무에 변화를 주기도 했었어. 번아웃이 여러 이유가 있겠지만 가장 큰 이유는 현재 상황에 대한 불만이 개선되지 않는 상태에서 계속 업무를 해야하는 상황일 때 온다고 생각해. 경험상 엔지니어들은 아래 상황들이 지속될 때 번아웃이 오더라고.

  • 기술의 변화를 줄 수 없는 레거시 환경에서의 업무

  • 코드 리팩토링과 성능 개선을 못하고 계속 새로운 기능만 구현해서 기술부채에 대한 부담

  • 업무의 중요도와 내가 생각하는 중요도가 일치하지 않는 상황

  • 일정에 대해 주도권이 없어 엔지니어 의견과는 상관없이 결정되고 그 일정을 반드시 지켜야하는 상황

  • 문제의 해결 방법이나 사용하고 싶은 기술 스택이 조직의 방향과 맞지 않은 상태

자, 그럼 번아웃이 오면 어떻게 해야할까?

리드에게 번아웃 상태를 알리기

만약 팀에 리드와의 정기적인 1:1 시간이 있다면 그 시간을 활용하고 그렇지 않다면 면담을 요청해서 현재 상황을 알리도록 해. 중요한 것은 불만을 털어놓기 보다는 개선될 점에 초점을 맞춰서 얘기하는 것이 좋아. 자칫 잘못하면 리드 입장에서는 설령 그렇다하더라도 자신의 잘못을 지적하는 것으로 들릴 수도 있기 때문이야. 예를 들어, “레거시 환경에서 계속 작업하는게 쉽지 않아요. 현재 상황이 쉽지 않다는 것은 이미 설명해 주셔서 알고 있지만 언제쯤 새로운 기술 스택으로 구현할 수 있을지 궁금해요.” 또는 “최근 신규 기능 개발을 계속 하다보니 코드 리팩토링이나 성능 개선할 시간이 너무 부족해서 기술부채가 쌓이고 있어서 앞으로 퍼포먼스가 떨어질까봐 염려스러워요. 이런 작업들을 할 수 있게 업무 시간을 확보해 줄 수 있을까요?” 정도면 좋겠어. 리드가 경험이 있고 역할을 잘 하고 있다면 결과와 상관없이 가능한 빨리 피드백을 줄꺼야. 경험상 신기하게도 당장은 해결이 어렵다고 다소 부정적인 피드백을 줬음에도 번아웃에서 나온 엔지니어도 있었거든. 아마도 리드가 들어주고 공감한 것만으로도 본인 스스로가 마음을 잘 가다듬고 방향을 잘 잡은 것 같아. 리드 입장에서는 개선할 점을 얘기하는 팀원들이 참 고맙기도 해. 어찌되었든 앞으로 문제를 해결할 수 있는 실마리를 던져 준 것이니깐 고마울 수 밖에 없지. 이렇게 리드의 도움을 받는 것이 중요해.

업무의 중요도를 이해하기

예를 들어 지금 구현하고 있는 기능이 목표와도 관련이 없고 전혀 중요하지 않은데 주어진 업무이기 때문에 해야하는 경우가 지속적으로 반복되는 경우에 업무 만족도가 크게 떨어지면서 번아웃이 오는 경우가 있어. 이럴 때는 사실 본인 스스로가 더 주도적으로 나서서 PO, 기획자 또는 프로덕트 결정권자와 이 기능이 왜 중요해서 우선순위가 높은 지에 대해 서로 이해하는 노력이 필요해. 대부분 이런 상황은 조직의 일하는 방법과 연관이 있는데 기능의 필요성과 배경 등의 맥락이 팀원들에게 충분히 전달되지 않고 완료 일정만 주어지는 조직에서 발생하는 문제야. 전반적으로 목표에 대한 공유와 왜 이 업무를 해야하는 건지에 대한 공유가 이뤄지고 있지 않은거지. 이런 상황에서 엔지니어는 이 문제를 해결하기 위해 나서야해. 이런 상태에서는 업무를 계속하는 것은 성장을 더디게 할 수 밖에 없어.에라 모르겠다 그냥 주어진 기획대로 일정 지키면서 구현해야지 하는 수동적인 태도는 만족도가 떨어질 수 밖에 없고 번아웃이 오는 지름길이라고 생각하면 돼. 그렇기 때문에 업무의 맥락을 맞추고 중요도를 이해해야해.

일하는 방식의 변화를 주도하기

프로덕트팀 내에서 팀원들이 함께 우선순위와 일정을 정한다면 업무의 중요도의 맥락을 팀원들이 모두 알고 있기 때문에 중요도가 맞지 않아 번아웃이 오지는 않을텐데 이런식의 일하는 방식이 아니라면 팀원들과 함께 일하는 방법을 바꾸는 것도 좋아. 물론, 변화가 쉽진 않겠지만 중요한 것은 일정 내 기능을 찍어내는 프로젝트 중심의 방식으로는 사용자에게 프로덕트의 임팩트를 전달할 수 없다는 점이야. 결국 프로덕트팀의 목표는 분명하기 때문에 그 목표를 잘 달성하기 위해 우선순위가 가장 높은 기능부터 순서대로 사용자에게 전달하는 것이지. 왜 이런 시도를 엔지니어가 해야 하냐고? 계속 반복하는 얘기지만 결국 성장을 위해서야. 더 성장하려면 이런 팀에 들어가던가 이런 팀을 주도해서 만들던가 해야해. 이도저도 아니면 성장이 더뎌 질 수 밖에 없기 때문이야.

직군 변경 요청하기

기술 스택을 바꿔보는 것도 방법이야. FE 엔지니어로서 3년 동안 React를 경함했더니 이젠 왠만한 기능을 구현하는데 전혀 문제가 되지 않는다면 새로운 직군의 기술에 대해 도전해 보는 것도 좋아. 아무래도 이직을 하면서 직군을 변경하는 것은 쉽지 않기 때문에 같은 조직에서 비즈니스 도메인을 이해한 상태에서 직군을 변경하는 것이 여러모로 안정적이고 팀원들도 잘 아니깐 쉽게 배워나갈 수 있을거야. 그리고 나중에 테크리드나 CTO 포지션으로 성장하기 위해선 주력 기술에 한 두가지 기술의 경험을 더해 풀스택으로 프로덕트를 바라보는 관점이 필요한 역량이기 때문이야. 직군 변경이 가능한지는 조직의 상황 마다 다르기 때문에 어려울 수도 있겠지만 시도해 보는 것은 좋다고 생각해.

남거나 떠나거나

결국 조직의 방향과 맞지 않거나 더 이상 성장할 수 없을거라 판단이 선다면 대부분 이직을 해. 예를 들어 입사시에는 주력 프로덕트가 코인 거래소였는데 여건상 조직의 비즈니스 방향이 바뀌어 피벗하기로 결정이 되서 앞으로 커머스 서비스를 출시한다고 하는 경우가 되겠지. 블록체인 엔지니어로 성장하기를 위해서 입사를 했는데 상황이 바뀌다 보니 상당히 어려운 상황이 된 것이지. 물론, 백엔드나 다른 직군으로 도전한다면 남아서 성장하는 방법도 있지만 쉬운 결정은 아니니깐.

문제 해결이 즐거운지 고민해보기

가끔 번아웃을 해결하기 위해 코딩을 안하고 있어요. 좀 쉬면 괜찮아지더라는 얘기를 들은 적이 있는데 내가 계속 설명하고 있는 번아웃은 이것과는 조금 달라. 리프레시가 필요한 것과 번아웃이 온 것은 다르다고 생각해. 번아웃은 리프레시 휴가를 다녀온다고 해결되지 않아. 나의 불만족이 해결되는 것이 중요해. 번아웃이 왔다면, 나는 문제 해결을 즐기는가?란 질문을 해보길 바래. 문제를 해결하는 과정과 노력이 기꺼이 즐겁지 않다면 엔지니어란 직업이 나와 맞지 않기 때문에 생기는 어려움을 번아웃이라고 생각할 수도 있기 때문이야.

지금까지 번아웃에 대해 설명을 해봤는데 궁금한 점들은 해결되었니? 너무 걱정은 하지 않았으면 해. 엔지니어로 커리어를 만들어가다보면 번아웃은 몇 번은 기본이야. 감기라고 생각하는 게 맘이 편할듯 해.

From. OO님의 번아웃이 얼른 끝나길 바라는 Rock