소프트웨어 엔지니어링 분야 종사자들의 정신건강 문제

• 스타트업 리더 역할은 코드보다 불확실한 책임을 많이 다루며, 패닉 발작·불안·번아웃이 업무 성과와 삶 전체를 흔들 수 있음
• 직급이 올라갈수록 명확한 티켓 대신 바뀌는 요구, 겹치는 마감, 24/7 장애 대응처럼 끝이 흐린 압박이 늘어남
• “make it happen”식 문화는 무리한 마감 수용, 마이크로매니지먼트, 야간 PR 재작성, 결식과 회의 누적으로 번아웃을 키움
• 모든 마감이 같은 위험은 아니며, 규제·계약·자체 부과 마감을 구분하면 협상 가능한 압박과 실제 위험을 나눠 볼 수 있음
• 회복은 거창한 결심보다 조기 경고 신호 인지, 주말 보호, 위임, 알림 차단, 상담처럼 작게 반복 가능한 행동에서 시작됨

---

스타트업 리더 역할에서 시작된 불안과 번아웃

• 2017년 Head of IT 역할을 이어받으며 5명 규모 개발팀, 파트너에게 약속한 많은 일, “모든 것을 전달하고 아무것도 망가뜨리지 않으며 아무도 태우지 말라”는 압박을 함께 떠안음
• 당시에는 정신건강을 이유로 병가를 낼 수 있다고 느끼지 못했고, 회사 핸드북에 mental health day가 있어도 엔지니어들이 여전히 망설이는 경우가 있음
• 불안이 밀려올 때 Reddit의 r/Anxiety에서 비슷한 증상을 찾았고, 장기 해법은 아니었지만 사무실에서 뛰쳐나가지 않게 버티는 데 도움이 됨
• 결국 의사를 만나 정식 진단을 받고 천천히 기준 상태로 돌아왔으며, 지금도 비상 체크리스트를 가까이 둠

통제 가능한 개발 업무에서 불확실한 리더십 업무로

• 초기 개발 업무에는 명확한 티켓, 수용 기준, 테스트, 병합처럼 비교적 통제 가능한 흐름이 많았음
• 직급이 올라갈수록 업무 정의는 흐려지고, 마감은 겹치며, 이해관계자는 스프린트 중간에 마음을 바꾸고, 확률적 판단이 일상이 됨
• 인프라와 SRE 업무는 24/7 페이저를 안고 살기 때문에 제품 마감보다 더 강한 상시 긴장을 동반함
• CEO가 가장 큰 고객에게 약속한 기능을 최우선으로 만들라고 한 다음, 하루 뒤 그와 모순되는 다른 기능도 최우선이라고 요구하는 상황이 있었음
  • 두 기능이 동시에 최우선일 수 없다고 말해도 돌아오는 답은 “make it happen”이었음

“make it happen”이 만든 누적 손상

• 번아웃은 단일 대형 사고보다 수천 개의 작은 자기 손상이 쌓인 결과에 가까웠음
• 정신적 부담을 키운 행동은 반복적으로 나타남
  • 영업팀 체면을 세우려 모든 무리한 마감을 받아들임
  • 팀을 보호한다는 명목으로 직접 코드에 뛰어들며 마이크로매니지먼트를 함
  • 새벽 2시에 은행 계좌를 새로고침하며 급여 지급 가능 여부를 확인함
  • 당장 난 장애를 끄면서 동시에 미래 아키텍처를 계획하려 함
  • 주니어를 코칭하면서 밤에 몰래 PR을 다시 작성함
  • 연속 회의, 식은 커피, 거른 점심이 이어짐
• 주말 아침 처음 10초는 괜찮다가 곧바로 불안이 떨어지는 감각이 반복됨

모든 마감은 같은 위험이 아님

• 예전에는 모든 출시를 Mars Rover 착륙처럼 다뤘지만, 돌아보면 실제로 회사 존속을 좌우하는 마감은 소수였고 나머지는 자존심과 기대치 설정 실패에 가까웠음
• 회사의 현금흐름이 좋아지고 고객이 안정되자 워크라이프 밸런스가 덜 비현실적으로 보이기 시작함
• 금요일 밤 배포가 터져 6시간을 수습한 적이 있었고, 고객이 계약을 끊을 것이라 생각했지만 월요일에 고객은 항해 여행 중이라 스테이징 링크조차 열지 않았음
• 마감은 세 가지로 나눠 볼 수 있음
  • 규제 마감: 협상 불가
  • 계약 마감: 일찍 말하면 대체로 협상 가능
  • 자체 부과 마감: 주로 자존심에서 비롯됨
• 일부 회사는 4일 근무제와 퇴근 후 Slack 금지를 내세우며, 번아웃을 명예 훈장처럼 취급하는 회사에만 머물 필요는 없음

작동했던 개인적 대응법

• 의료 조언은 아니지만, 기능을 유지하는 데 도움이 된 행동들이 있었음
• 조기 경고 신호를 찾음
  • 본인에게는 doom-scroll 불면과 평소 좋아하던 코드 리뷰에 대한 갑작스러운 혐오가 신호였음
  • 이런 신호가 나타나면 속도를 낮춤
• “아니오”를 분명히 말함
  • 주말은 보호해야 하며, 페이저 알림이 아니면 월요일까지 기다리게 함
• 제대로 위임함
  • 붙잡고 있는 모든 PR은 멘토링 기회를 잃는 것이자 불안을 쌓는 일이 됨
• 카페인을 줄임
  • half-caf를 거쳐 decaf로 바꾸었고 심장이 편해짐
• 하루 12,000보를 걸음
  • 특별한 장비 없이 신발과 경로만 있으면 충분함
• 휴대폰 알림을 끔
  • 프로덕션이 정말 불타고 있다면 누군가 전화할 것이라고 봄

사람을 먼저 보는 리더십

• 감정 지능을 읽기 시작하면서 사람을 merge conflict 기계처럼 보지 않게 됨
• 먼저 듣고 나중에 고치는 방식이 또 하나의 스프린트 회고보다 더 도움이 될 때가 있음
• 치과 치료는 부끄러워하지 않고 맡기면서 정신건강은 혼자 리팩터링해야 한다고 기대하는 태도는 맞지 않음
• 전문가를 만난 시간은 가장 ROI가 높은 시간 중 하나였음
• 회복은 반복적인 과정이며, 여전히 늦게까지 일하거나 점심을 잊는 일이 있지만 이제는 알아차리고 고친 뒤 넘어감

코드보다 중요한 자산

• 코드는 다시 쓸 수 있지만 사람은 그렇게 다룰 수 없음
• 우울은 Kubernetes 업타임을 봐주지 않으며, 리더십이 사람을 갈아 넣으면 클러스터는 돌아가도 그 클러스터를 움직이는 사람은 버티지 못함
• 고객 티켓을 전부 직접 고치고 싶은 충동이 있어도, 이제는 “내 통제 범위 안에 있는가”를 먼저 묻고 아니면 넘김
• 그 결과 조금 더 차분한 엔지니어가 되었고, Apple Watch 기준으로 밤에 45분 더 잠을 자게 됨
• 힘든 시기라면 망가진 것이 아니고 혼자가 아니며, 도움을 요청하고 작은 실험을 시도하고 정신건강 휴가를 쓰는 편이 나음
• 번아웃 시간으로 가치를 측정하는 회사는 그 시간을 바칠 가치가 없으며, 가장 큰 자산은 작성된 코드가 아니라 그 코드를 쓰는 사람임

[GN⁺]

Hacker News 의견들

• 소프트웨어 엔지니어링을 거의 30년 해보니, 대부분의 마감일은 완전히 임의적이라는 결론에 도달했음
  1주 늦거나 심지어 6개월 늦는다고 회사가 망하지는 않고, 정말 망한다면 반복적으로 자기 납기 예측을 깨는 수준으로 엔지니어링 조직이 망가진 게 아닌 이상 엔지니어링 탓도 아님
  규제, 고객 개념검증, 납품 같은 실제 마감은 있지만, 정상적인 엔지니어링/비즈니스 조직이라면 그런 마감은 훨씬 전부터 알고 있고, 충분히 여유를 둔 일정 안에 구현 가능한지가 핵심임
  고객이 제품이 일정 주기로 출시되지 않는다고 떠나는 경우는 거의 못 봤고, 오히려 자신들이 요청한 문제를 고치는 게 아니면 업그레이드를 반기지 않는 고객도 많음
  끝없는 주 80시간 근무는 대개 반대 효과를 내며, 계속 고장 나서 버리고 싶어지는 저품질 제품을 만들게 됨

  • 내 경험상 대부분의 작업 자체도 임의적임
    지난 30년을 돌아봤을 때 완전히 건너뛰었어도 장기적으로 아무 차이 없었을 작업이 몇 퍼센트였을까? 내 경우는 쉽게 50%를 넘고, 기분 나쁜 날이면 90%에 가깝다고 말할 듯함
  • 업계에 따라 다름
    비디오 게임은 아직 Target, Best Buy 같은 소매 매장에서도 팔리고, 매장은 몇 달 전부터 진열 공간을 조율해야 함. 11월 15일까지 패키지된 게임을 물류 도크에 갖다 놓겠다고 약속했는데 놓치면, 너를 위해 비워둔 선반이 그대로 비게 됨
    소비자 전자제품도 비슷하고, 광고 특히 TV 광고도 예전엔 훨씬 전에 예약해야 했음. 6개월 전에 광고 슬롯을 사지 않으면 다 팔리고, 광고가 나갈 때 제품이 구매 가능하지 않으면 큰돈을 날림
    일반적인 IT 프로젝트의 마감은 꽤 헛소리일 수 있지만, 소매 제품에서는 왜 마감이 생기는지 이해됨
    해결책은 제품이 100% 완성되기 전에는 선반 공간 협상을 시작하지 않는 것이겠지만, 회사들은 보통 그러지 못함. 주문 대금으로 급여를 줘야 하고, 제품 완성 뒤 광고와 선반을 잡아 6개월을 기다리면 그동안 직원들이 할 일이 애매해지며, 다음 제품으로 넘어갔다가 다시 이전 제품 지원으로 돌아오는 비용도 커짐
  • VirtualBox, Docker 같은 여러 소프트웨어를 쓰는 입장에서 업데이트와 이른바 업그레이드가 정말 싫음
    훨씬 덜 자주 갱신되는 안정 버전을 더 선호함
  • 회사는 마감 자체보다, 마감을 못 맞출 것이라는 충분한 사전 통보가 없을 때 더 괴로워함
    아무 경고도 없다가 엔지니어링이 임박한 마감을 못 맞춘다고 갑자기 발표하거나, “거의 끝났고 스프린트 하나만 더”가 계속 반복되는 게 더 답답함
    그래서 “이제 추정은 안 한다”, “끝나면 끝난 것” 같은 즉흥적 반응은 전혀 도움이 안 됨
  • 많은 관리자와 리더는 모든 작업에 마감일이 필요하다고 가정함
    자기 일정도 시간 구획과 임의 기한으로 관리하면서 생산적이라고 느끼고, 그 통찰을 회사 전체로 확장함. 시간 제한이 있는 위협이 없으면 작업이 제때 끝나지 않을 거라는 전제가 깔려 있음
    어떤 일이 정해진 날짜에 끝난다는 느낌은 인간적으로 매력적이고, 잘 기름칠된 기계가 예측 가능한 일정으로 돌아가는 듯한 따뜻한 감각도 있음
    하지만 누군가의 불안과 일정 강박을 관리하려고 많은 사람에게 강제 일정을 씌우는 건 잔인함. 현실은 복잡하고, 그것을 깔끔한 상자에 넣고 싶어 하는 욕망은 망상적이고 비생산적임

• 소프트웨어 엔지니어링이 의사, 변호사, 영업, 엔지니어, 프로 운동선수, 교사 같은 다른 화이트칼라 직업보다 정신 건강에 더 나쁘다고는 크게 확신하지 않음
  이런 직업들은 모두 고유한 스트레스 요인이 있고, 힘들어서 떠나는 사람이 많다는 글도 넘쳐남. 경계를 세우지 않으면 여가 시간을 잡아먹고, 마감 때문에 스트레스를 받는 것도 공통임
  “정신적으로 힘들어서 하루 쉬겠다”고 팀에 말해 병가를 낼 수 없다는 부분은 읽기 괴로웠음
  경력 20년 동안 그런 태도를 한 번도 본 적이 없고, 사람들은 정신 건강 때문에 병가를 자주 냄. 그렇게 말할 수 없다고 느꼈다니 안타깝지만, 그건 규칙이 아니라 예외에 훨씬 가까움
  지난 20년 동안 정신 건강에 반대한다고 나선 회사가 있었나?

  • 군대 환경에서는 오히려 이런 상황을 적극적으로 막으려 함
    정신 건강 문제가 있는 18~20세 아이들이 많은데, 너무 쉽게 쉬게 해주는 게 도움이 되지 않을 때가 많음. 전문가들은 집에서 술 마시고 게임만 하게 두는 것보다 계속 일하게 하려 함
    어떤 아이들은 업무 스트레스가 늘었을 때 오히려 잘 반응했음. 훈련소처럼 열심히 일하고 지쳐서 집에 가면 잠을 자지만, 피곤하지 않은 상태로 집에 보내면 술과 심야 게임으로 이어지고 다음 날 좀비처럼 출근함
    모두에게 통하는 방식은 아니지만, 우리가 꼭 자기 자신에게 최고의 치료자는 아니라는 점은 받아들여야 함. 휴가가 늘면 부정적 행동이 증폭되는 사람도 많음
    더 나은 답은 “하루 쉬어야겠다”가 아니라 “내일 08:00에 상담 예약이 잡혀 있다”에 가까움
  • 의학에서 넘어온 입장에서 보면 소프트웨어 엔지니어는 정말 좋은 처지임. 가진 것을 소중히 여겨야 함
    나쁜 관리, 비현실적인 일정, 흥미 없는 프로젝트에 대한 개인 경험은 인정하지만 그런 건 어디에나 있음
    여기에 매일 환자와 가족이 인생 최악의 날을 겪는 현장에 있어야 하고, 고압적인 의사결정을 해야 하며, 근무 내내 앉거나 화장실 갈 기회조차 거의 없는 상황을 더해보면 다름
    게다가 컨디션이 안 좋은 하루가 길고 긴 조사나 법정 사건으로 이어질 수도 있음
    무감하게 들릴 수 있지만, 소프트웨어 엔지니어링은 많은 의료 직군만큼 복잡하거나 스트레스가 심하지 않음. 정신적으로도 육체적으로도 덜 소모적임
  • 소프트웨어 엔지니어링이 변호사보다 정신 건강에 덜 해롭다고는 생각하지 않음
    거의 10년 동안 변호사들과 함께 일하며 비엔지니어링 전문 서비스를 제공했고, 소프트웨어 엔지니어링과 스타트업 경험도 수십 년 있음
    소프트웨어 엔지니어링의 압박은 법률 환경에서 겪은 것과 완전히 다르고 훨씬 나빴음
    대체로 변호사는 관리자라기보다 변호사임. 주니어 어소시에이트부터 최상위 파트너까지 위계는 있지만, 위아래 모두 변호사임. 변호사가 관리자 밑에서 일하는 구조와는 다름
    법률 환경에도 압박과 긴 근무시간은 있고 배우자들은 변호사가 늘 회사에 있거나 집에서도 딴생각한다고 불만을 갖지만, 그곳에서는 불안 발작이나 정신 건강 문제를 겪지 않았고 소프트웨어와 스타트업 환경에서는 겪었음
    법률 쪽에서는 모두가 절차를 알고 그 절차를 수행하며, 상사도 그 절차를 해본 사람임
    소프트웨어에서는 그 절차를 모르는 경우가 많고, 직접 갈려본 적 없는 사람을 만족시키려고 계속 갈리기 쉽다. 예전에 다닌 성공한 상장사는 바로 이 이유로 시니어 소프트웨어 엔지니어 채용 공고가 늘 열려 있었음
  • 많은 사람이 관리자에게 건강/의료상 이유로 쉰다고만 말하면 되고, 독감인지 허리 문제인지 정신 건강인지 추가 정보를 제공할 필요가 없다는 걸 모름
    학교에서 고용과 관련한 기본 법률을 가르치면 많은 사람에게 도움이 될 듯함
  • 누가 소프트웨어 엔지니어링이 더 힘들다고 했는지가 왜 중요한가?
    똥을 밟았든 무릎까지 빠졌든 결국 똥 속에 있는 건 같음. 누가 더 많이 뒤집어썼는지 겨루지 말고 서로 닦아주는 편이 낫지 않나?
    비교를 멈춰야 함. 지금은 분류 배정이 필요한 상황도 아니고, 평균적으로 더 나은 처지인 사람에게도 동정하거나 공감할 수 있음. 우리는 모두 인간이고, 함께할 때 이득을 봄

• 예전에는 젊은 대학 중퇴 CEO들에게 어느 정도 경외심이 있었지만, 몇 명 밑에서 일해본 뒤로는 20대가 꼭대기에 있는 스타트업에서는 일하지 않기로 했음
  그들은 정말 관리나 리더십을 모름. 실패에 대한 두려움에 동기화되어 있고, 아직 이룬 게 없어서 다른 사람들을 쓰레기처럼 대함. 피하는 게 좋음

  • Stanford에 나타나 21살에게 네가 예수 그리스도라고 말하며 수백만 달러를 주겠다는 현상은, 기업 사냥꾼만큼이나 미국 비즈니스 문화의 종기임
    대학 미식축구/농구 리크루팅의 괴짜 버전임
  • 25살이 훌륭한 스타트업 CEO가 될 수 없을 이유는 없다고 봄
    까다로운 핵심은, 25살이 전반적으로 똑똑하고 보기 드물게 자기 인식과 겸손을 갖췄으며 큰 문제에 도전하더라도, 언제 팀이나 조언자를 들어야 하고 누구 말을 들어야 하는지, 언제 자기 판단대로 반대로 가야 하는지를 알기 어렵다는 데 있음
    좋은 자질을 모두 갖추고 좋은 팀과 조언자에게 노출된다면 어느 정도 가능할 수도 있음
    다만 여러 분야가 나쁜 관행과 조언, 노골적 기만과 조작으로 가득한 것도 도움이 안 됨. 예전 PG 글을 읽던 시기에는 같은 기술자이자 사업가가 똑똑하고 선의 있는 조언으로 성공을 바라줄 거라고 기대할 수 있었지만, 이제는 전혀 표준이 아님
    지금은 어디를 봐도 나쁜 조언을 받을 가능성이 훨씬 크고, 개인과 기관이 조작하려 드는 경우도 더 많음. 직접 걸러낸다 해도, 영향을 허용한 똑똑하고 괜찮은 사람들을 통해 2차로 흘러들어오는 영향까지 받게 됨
  • 다른 사람을 쓰레기처럼 대하는 사람에게는 20살이든 60살이든 경외심을 가질 필요가 없음
    49살 창업자/CEO와의 경험에서 막 빠져나왔고, 앞으로는 쓰레기 같은 신호를 전부 찾게 될 듯함
  • 젊은 중간관리자들 중에도 정말 짜증 나는 경우가 있었음. 아주 젊지도 않은 20대 후반~30대 초반의 불안한 워커홀릭들이 모두의 삶을 비참하게 만듦
    그들은 승진하려고 미친 듯이 일했고, 이제 자기 같은 사람들로 팀을 채울 수 있다고 생각함
    하지만 그렇지 않음. 그 “같은 사람들”은 건강을 해치지 않을 만큼 현명했거나, 그러고 싶지 않았기 때문에 승진하지 않은 것임
    더 잘했고 돈과 권한도 더 많이 얻었으니 축하하지만, 이제 모두가 시트를 걷어내고 부스러기를 흘린 그 침대에 누워야 함
  • 이론상으로는 맞지만 실제로도 그런가? Amazon과 Oracle이 Facebook과 Stripe보다 일하기 좋은 곳인가?

• 어느 시점부터는 그냥 대기열을 만들고, 다음으로 우선순위가 높은 일을 시작해야 함
  진행 중인 작업이 너무 많으면 망함

  • 그래서 Kanban이 내가 가장 좋아하는 프로젝트 관리 방법론 중 하나임
    “새 최우선 기능이군요. 짧게 탐색해보니 이 일은 스티키 노트 20개로 표현될 것 같습니다. 우리 팀의 과거 처리 속도는 2주에 스티키 노트 10개입니다. 그러니 기존 진행 중 작업을 전부 내리면 아마 4주 뒤 끝납니다. 각 기존 스티키 노트를 보면서 정말 멈춰도 되는지 확인해 주세요”
    이해관계자는 여전히 결정을 내릴 수 있지만, 팀에게 무엇을 요구하는지 현실적으로 이해하게 만드는 효과가 있음
  • 몇 년 전 어느 회사에서 엔지니어링 디렉터로 일하며 제품의 주요 새 버전을 준비하던 때가 있었음
    몇 주 뒤 CEO에게 새 릴리스의 범위와 어려움을 꽤 잘 이해한 것 같다고 말했더니, CEO는 “아니, 모른다”고 했음
    이유를 묻자 주말 동안 새로 생각해낸 “필수” 기능이 있다고 했고, 그건 명백히 기술적으로 매우 어려웠음. 그러고는 무엇이든 48시간 안에 만들 수 있다고 단언함
    그 직장에서 그렇게 오래 버틴 게 놀라움
  • 관리자로서 위에서 우선순위를 바꿔도, 지금 하던 일이 거의 끝났다면 그냥 끝내버림
    나중에 원래 일로 돌아오면 이미 완료됐다는 사실에 항상 놀라워함
  • 예전 직장이 딱 그랬고, 그런 위치에 필요한 것보다 오래 있는 사람은 다른 역할을 찾아야 함
    결국 번아웃이나 무관심으로 가는 길임
    당시 X-Files를 많이 보고 있어서 “금주의 괴물”이라고 불렀고, 아직도 그 표현이 마음에 듦
  • 비즈니스를 상대하는 개발자에게 가장 강력한 기술 중 하나는 아니라고 말할 수 있는 능력임

• 아주 짧은 시간이라도 하던 일에서 분리되는 능력이 정말 중요함
  산책을 하거나, 커피를 내리거나, 그냥 눈을 감고 숨을 쉬면 됨
  스트레스는 인위적으로 만들어지는 경우가 많고, 성과를 해치며 사고 능력도 떨어뜨림
  회사가 계약이나 매출을 따낼 수 있다며 일이 “긴급”해지고, 이 “크런치”를 해내면 모두가 슈퍼스타가 된다는 상황을 여러 번 겪었음
  2개월 동안 밤샘과 3~4시간 수면을 반복해 프로젝트를 조기 납품하면, 경영진과 의사결정자가 이런 “선물” 같은 크런치를 계속 주면서 무감각해지기 시작함
  회사를 돕고 한 걸음 더 가는 건 대부분 해봤고 앞으로도 할 수 있지만, 모든 일이 긴급하고 모든 작업을 지금 당장 해야 한다면 더 큰 문제가 있는 것임
  돈, 시간, 노력에는 보통 한계와 예산이 있음. 그 한계와 허용치를 남용하면 사람들은 늑대가 왔다고 외치는 사람을 존중하지 않게 되고, 일에도 덜 힘을 쏟게 됨

  • 내 경력에서는 그런 것들이 한 번도 보상으로 돌아오지 않았음
    “이걸 납품하면 엄청난 대형 계약이 확정”이라는 식의 극적인 긴급 작업으로 크런치를 할 때마다 결국 계약 실패로 끝났음
    영업 담당자는 장기 도박 하나에 연구개발 조직 전체를 몇 달 동안 돌리고 사람들을 태워버려도 잘리는 것 같지 않음
    물론 그 영업 담당자가 그 기간 내내 몇 주씩 초과근무를 하는 것도 아님
    이제는 내 실수를 만회하려고 추가로 일하는 경우가 아니면 초과근무를 거의 거부함. 다른 멍청이의 비현실적 마감을 맞추려고 다시는 더 일하지 않겠음
  • 가장 배우기 어려운 교훈임
    회사, 제품, 고객을 위해 “제대로” 할 기회가 주어지지 않을 때가 있음. 결국 오늘 가장 중요한 게 무엇인지 묻고 그 일을 한 뒤, 일이 끝나면 완전히 퇴근하기로 하게 됨
    의미와 개인적 만족은 사생활에서 찾아야 함. 운동하거나 자원봉사하거나 취미를 갖거나 가족에게 집중하면 됨
    일과 삶의 균형을 얻는 가장 좋은 방법은 둘을 분리하는 것임. 그래서 재택근무를 싫어하는 이유 중 하나도 여기에 있음. 출퇴근 운전은 내게 훌륭한 분리 장치이자 감압 장치임

• “정신적으로 힘들어서 하루 쉬겠다”고 병가를 낼 수 없다는 말은 맞지 않음
  정신 건강의 날이 필요하다고 말할 수 있고, 어른들은 이해함

  • 내가 일한 대부분 회사에서는 “오늘 몸이 좋지 않아 하루 쉬겠습니다”면 충분했음
    아무도 세부 내용을 묻지 않았음
  • “어른들은 이해한다”는 건 꽤 거품 안의 경험임
    대다수 직업에서는 그렇지 않음
  • 당신이 일하는 곳에서는 그럴지 몰라도, 나는 그냥 출근하지 않겠다고 말함
    내 리드나 상사에게 저렇게 말하면 왜 안 나오냐고 따질 것임
  • 같은 이유로 웰니스 데이를 쓸 수도 있음

• 소프트웨어 개발이라는 실천 자체에 정신 질환을 일으키거나 일으킬 수 있는 무언가가 있다고 믿게 됐음
  수십 년 동안 몇몇 동료들이 아주 심각한 문제를 겪는 걸 봤고, 우리 업계에서는 정말 꽤 심각한 문제라고 생각함

  • 소프트웨어 엔지니어링은 신경다양성을 가진 사람들을 끌어들이는 것 같음
    나는 ADHD가 있는 소프트웨어 엔지니어이고, ADHD 소프트웨어 엔지니어를 비정상적으로 많이 알고 있음
    그 정도의 실행 기능 장애와 “따라잡기”는 문제가 됨
  • 기분이 좋아지려면 승리 경험이나 끝이 있는 프로젝트가 필요함
    하지만 많은 프로젝트는 회사나 본인이 기력이 떨어지거나, 다른 회사로 옮겨 같은 일을 반복하기 전까지 해마다 끝없이 이어짐
    웹 개발에서는 출시일이 가장 가까운 결승선이지만 진짜 결승선은 아님. 핵심 지표 목표 달성도 어느 정도는 해당하지만, 테이블이나 도자기를 완성하거나 작물을 수확해 팔거나 저녁으로 내놓는 것만큼 심리적으로 만족스럽지는 않음
  • 이 업계는 근본적으로 의식적 사고를 자본으로 전환하는 일을 가능한 효율적으로 하는 곳임
    그래서 마음에 나쁘다는 건 말이 됨
  • 스트레스의 많은 부분은, 동료의 변덕, 선견지명 부족, 나쁜 계획 때문에 그 “무언가”의 정의가 급격히 바뀔 수 있는데도 그것을 작동하게 만들어야 한다는 책임에서 옴
  • 결국 우리가 하는 일은 대부분 글쓰기임
    다른 작가들이 얼마나 잘 적응하고 사는지 보면 됨. 특히 월세 때문에 가치 없다고 아는 글을 많은 시간 써야 하는 사람들 말임

• 2017년에 주변의 모든 불확실성을 통제하려 했다는 묘사는, 형편없는 회사의 악몽 같은 직장에서 버티려다 스스로를 탓하는 것처럼 들림

• 이런 사람은 리더 자리에 있어서는 안 됐음
  이런 유형 밑에서 일해봤는데, 본인은 훌륭한 엔지니어였지만 리드는 형편없었음
  팀을 신뢰하지 않고, 항상 직접 처리하고, 논의도 없고, 뒷문으로 이야기하며, 경영진 뜻에는 늘 굽힘. 모든 것이 “중요”하거나 “치명적”이고, 최악의 마이크로매니징임
  동시에 나도 그 자리에 놓이면 정도는 덜해도 비슷하게 실패했을 가능성이 있음. 경영진은 “X에게 잘 보이기 위해” 말고는 딱히 좋은 이유도 없이 우리를 불가능한 위치에 밀어 넣는 경우가 많음
  이름도 없는 중간 임원에게 점수 따려고 그런다면 더 최악임
  그래서 기술 업계에 노조가 있으면 좋겠다고 봄. 현실적 기대치를 세우고, 경영진에 집단적 관점으로 접근할 수 있음
  안타깝게도 요즘 회사들은 빠른 엑싯과 IPO로 벤처자금을 회수하는 것만 노림. 독수리들 사이의 일반적 정서는 노조가 빠른 엑싯 가능성을 낮춘다는 쪽인 듯함

  • 이건 조직의 실패임
    조직이 누군가를 리더로 훈련하지도 않고 승진시켰기 때문임
    비기술 배경 관리자가 그냥 코딩을 시작하길 기대하지 않으면서, 왜 코더가 그냥 관리를 시작하길 기대하는가?
  • “팀을 신뢰하지 않고 항상 직접 한다”는 건 내가 배우기 가장 어려웠던 교훈 중 하나였음
    예비 리더들을 코칭할 때도 자주 장애물이 됨
    리더 역할로 옮겨가면 사람들이 내가 할 방식이 아닌 방식으로 일을 해도 괜찮다고 받아들이는 법을 배워야 함
    부하 직원의 결과가 거의 충분하거나 충분히 좋으면 받아들여야 함. 그리고 그 “충분함”의 허용 폭은 배우기 전 생각보다 훨씬 클 것임
  • 나도 그런 상사를 둔 적이 있음
    회사가 특히 기능장애적이었을 수도 있지만, 배정받은 프로젝트와 작업에 대한 경험이 많지 않았고 숨기지도 않았음
    그런데 혼자 파악하려고 시간을 쓰면 상사가 그냥 직접 해버리고 피드백은 주지 않았음
  • “절대 리더가 되어서는 안 됐다”고 말하는 건 지나친 단순화임
    실제로는 우선순위 설정, 위임, 감성 지능에 대한 구체적 훈련이 필요했을 수 있음
    이런 훈련은 드물게 제공됨. 대신 성과 좋은 사람들을 깊은 물에 던져 넣고 버틸 수 있는지 보는 식임
  • “항상 직접 한다”는 건 리더십 역할에서 가장 직관에 반하는 부분 중 하나임
    보통 개별 기여자 역할에서 많은 일을 직접 해냈기 때문에 승진함. 그런데 리더가 된 뒤에는 직접 하는 일이 적을수록 본인, 회사, 팀원 모두에게 더 좋음
    그래서 예전보다 한가하게 느껴지는 것이 일을 못하고 있다는 신호가 아니라는 점을 배워야 함

• “정신적으로 힘들어서 하루 쉬겠다”고 팀에 말해 병가를 낼 수 없다는 건 가능함
  나는 몇 년 전부터 그렇게 하기 시작했고 전반적으로 긍정적인 경험이었음. 내가 먼저 내 어려움을 열어 보였기 때문에 팀의 다른 사람들도 자기 어려움을 이야기해줬음