소프트웨어 엔지니어를 번아웃시키는 간단한 3단계 방법

해외 사례이기는 하지만, 국내 스타트업계에서도(아마 대부분의 IT관련 부서의 기업들도?) 크게 다르지 않을거 같습니다. 최고의 엔지니어를 소진시키고 리더십 기술에 대한 믿음을 무너뜨리고 싶은 관리자가 있다면 다음의 '번아웃 플레이북(?)'을 참고하세요. 1단계: 엔지니어를 믿지 마세요 첫 번째 단계는 엔지니어를 세밀하게 관리하는 것입니다. 스타트업에서 엔지니어링을 이끌던 시절, CEO는 매일 몇 시간씩 저에게 전화를 걸어 실제 사용자 경험에 영향을 미치지 않는 사소한 구현 세부 사항을 지적하곤 했습니다. DynamoDB를 사용해야 할까요? 이 람다 함수는 왜 노드 대신 파이썬을 사용하나요? 등등.. 2단계: 필요 없거나 시간 낭비인 프로세스 도입 스타트업에서 일할 때, 어느 날 갑자기 무언가를 구현하기도 전에 방대한 디자인 문서를 작성해야 했습니다. 작은 API 엔드포인트 하나하나를 만들 때마다 사전에 광범위하게 논의해야 했죠. 갑자기 기능을 출시하는 데 며칠이 걸리던 것이 몇 주가 걸리기도 했습니다. 스타트업은 구글이 아닙니다. 구글은 규모가 방대하고 사람들이 수시로 입사하고 퇴사하기 때문에 문서 작성 문화가 필요합니다.  물론 이러한 프로세스는 필요하지만 균형이 필요합니다. 엔지니어가 작업하는 모든 프로젝트가 이러한 프로세스를 거쳐야 하는 것은 아니며, 그렇게 해서도 안 됩니다. 3단계: 출시되지 않는 프로젝트 작업 or 지나친 완벽주의(?)(Don’t ship code to customers.) 8개월 동안 아무도 볼 수 없는 작업을 하는 것보다 더 나쁜 것은 없습니다. 더 나쁜 것은 그 8개월이 12개월, 16개월, 20개월로 밀려난다는 것입니다. 그렇게 되면 제품 개발이 중단되고 작업한 결과물은 누구도 사용할 수 없게 됩니다. 출시되지 않는 프로젝트 작업은 번아웃의 가장 큰 원인 중 하나입니다. 제가 일했던 스타트업에서는 1년이 넘도록 고객에게 단 한 번도 배송하지 못한 채 제품 개발에 매달렸습니다. 제품을 출시할 준비가 되었다고 생각할 때마다 CEO는 "몇 가지 기능만 더 추가해 달라"고 요청했습니다. 시간이 지나자 팀원들은 CEO의 실행 능력에 대한 믿음을 잃었습니다. 실제 사용자가 아닌 CEO의 아이디어로만 피드백을 받는 상황에서 깊은 관심을 기울이기가 어려웠습니다. 제품이 출시되면 버그가 없어야 하고 사용자 경험이 좋아야 합니다. 하지만 완벽할 필요는 없습니다. CEO가 완벽을 향해 계속 나아간다면 우리는 매우 나쁜 시간을 보내고 있는 것이나 마찬가지였습니다. 특히 아직 제품 시장 적합성에 도달하지 않았기 때문에 더욱 그렇습니다. 돌이켜보면 우리 CEO는 실제로 제품을 판매하고 비판적인 피드백을 받는 것을 미루고 있었던 것 같습니다. 제가 몸담았던 빅테크 팀에서는 이사와 부사장이 왔다 갔다 하면서 조직이 계속 개편되었습니다. 조직이 개편될 때마다 새로운 경영진이 부임했고, 새로운 경영진은 조직에 대한 새로운 비전을 가지고 있었습니다. 따라서 요구사항이 계속 바뀌었고, 몇 달 또는 몇 년 동안 작업한 많은 프로젝트가 폐기되었으며, 프로젝트의 실제 영향력을 확인할 기회도 없었습니다. 고객에게 제품을 출시하지 못하는 것은 집중력이 부족하기 때문입니다. 제품을 이끄는 강력한 비전이 없으면 그 제품은 실패할 수밖에 없습니다.