GN⁺: CTO에게 거짓말을 하고 위기를 모면한 사건

개발자가 CTO에게 거짓말한 사연

• 몇 년 전, 포춘 500대 기업에서 일했던 시절의 이야기임
• 당시 CTO는 개인적 인맥이 있는 중요 고객을 위해 큰 프로젝트를 수주했고, 핵심 부분을 대형 기술 서비스 업체에 아웃소싱하기로 결정함
• 하지만 벤더의 "제품"은 실제로는 요구사항에 맞추려면 대대적인 커스터마이징이 필요했고, 이는 가장 안 좋은 선택이었음
• CTO와의 상태 확인 회의에서는 아무도 이 아이디어가 좋다고 생각하지 않았지만, 모두 "좋은 생각이에요 보스"라고만 했음
• 결국 벤더가 "제품"을 납품했을 때는 이미 9월이었고, 10월 출시를 위한 데드마치가 시작되었음
• 테스트 중 성능 문제와 MongoDB 16MB 문서 제한에 걸리는 등 심각한 버그가 발견되었음
• 고객에게는 1달 지연되어 출시한다고 하면서, 동시에 벤더 통합을 대체할 비밀 프로젝트를 시작하기로 함
• 젊고 열정적인 개발자였던 나는 팀원 3명을 배정해 대체 시스템 개발을 시작함
• 12월 중순, 지난 한 달간 대체 소프트웨어를 거의 완성했지만 모두 번아웃 상태였음
• 그때 CTO가 와서 휴가를 취소한다고 했고, 나는 "알겠습니다"라고 대답함
• 하지만 아버지의 조언을 떠올리며 팀원들에게 휴가를 가라고 한 뒤, 혼자서 CTO와의 데드마치 상태 확인 회의에 참석해 거짓말을 했음
  • "팀이 열심히 일하고 있어요. 오늘 73번째 마일스톤 통합 지점에 도달했죠"
  • "팀이 어제 좋은 진전을 이뤘어요. 또 다른 웹 서비스를 끝냈거든요"
• 일주일 후 휴식을 취한 팀원들이 돌아왔고, 1월에 기한을 맞춰 성공적으로 출시할 수 있었음

GN⁺의 의견

• 열악한 환경과 무리한 요구 속에서도 프로젝트를 성공적으로 이끈 리더십이 돋보이는 사례임. 특히 팀원들의 컨디션 관리에 신경 쓴 점이 인상적임
• 다만 CTO에게 거짓말한 것은 바람직하지 않음. 장기적으로는 조직 내 신뢰를 잃고 더 큰 문제를 야기할 수 있음
• 벤더 선정과 아웃소싱 관리에 실패한 것은 CTO의 책임이 크지만, 이를 바로잡는 과정에서 보다 투명하고 적극적인 커뮤니케이션이 필요했을 것 같음
• 개발자들의 번아웃을 막기 위해 애초에 더 현실적인 일정을 세우고, 충분한 인력을 투입했어야 함. 크런치 모드는 지양해야 할 관행임
• 유사한 문제 상황에 처했을 때 참고할 만한 대안으로는 애자일 방법론이 있음. 짧은 주기로 개발하고 피드백 받는 과정을 반복함으로써 위험을 최소화하고 팀원들의 업무 강도를 조절할 수 있음

[neo]

Hacker News 의견

• 과로와 휴가 취소:
  • 비현실적인 기한을 맞추기 위해 과로하고 휴가를 취소하는 것은 현명하지 않으며 나중에 후회하게 됨
  • 직원들이 휴가를 희생하여 제품을 제공하는 데 의존하는 회사는 문제가 있는 직장 문화에 기여하고 있음
• 건강한 회사 vs 건강하지 않은 회사:
  • 건강한 회사에서는 경험 많은 사람들이 아웃소싱 접근 방식의 문제점을 예측하고 일찍 우려를 제기했을 것임
  • 개방적 의사소통, 해결책을 찾기 위해 함께 노력하는 것, 팀의 복지를 위해 관리자가 옹호하는 것은 건강한 환경의 징후임
  • 이야기는 관리자가 반복적으로 상급자에게 거짓말을 하는 건강하지 않은 상황을 묘사하고 있음
• 황당한 벤더 관행:
  • 거대한 JSON 문서에 모든 트랜잭션을 저장하고 각 업데이트마다 전체를 읽어야 하는 벤더의 접근 방식은 어처구니없는 것임
  • 또 다른 예는 사용자 테이블에 추가 열로 사용자 티켓 데이터를 저장하여 수백 개의 열이 생기는 스타트업임
• 역기능적인 상황과 리더십:
  • 팀 리더가 휴가에 대해 거짓말하는 접근 방식은 용납할 수 없으며 해고될 수 있는 위반 행위임
  • 더 나은 접근 방식은 불합리한 초과 근무 요구에 반대하고 건전한 프로젝트 범위와 벤더의 책임을 주장하는 것임
  • 팀 리더는 자신의 직업을 위험에 빠뜨리더라도 팀을 미친 요구로부터 보호할 책임이 있음
• 아무도 혜택을 보지 못함:
  • 벤더는 낮은 품질을 제공했고, CTO는 무지했으며, 개발자들은 과로했고, 주인공은 거짓말에 의지했음
  • 이는 아무도 용인해서는 안 되는 미친 상황임. 더 나은 직장으로 떠나는 것이 바람직함
• 정직과 투명성:
  • 기술적 문제, 성능 문제, 범위 변경 등에 대해 경영진에게 정직하게 말하는 것이 일부 사람들에게 잘 작동했음
  • 동떨어진 리더십이 설정한 임의의 기한을 맞추기 위해 거짓말하는 것은 좋은 접근 방식이 아님
• 개발자-경영진 간 신뢰 격차:
  • 개발자와 비기술 경영진 사이에는 종종 정보 불균형과 신뢰 부족이 있음
  • 관리자는 진행 상황을 쉽게 평가할 수 없고 프로젝트 성공에 대해 불확실함을 느낌
  • 위험이 비즈니스 측면에 있기 때문에 개발자는 이 신뢰 격차를 메우기 위해 밀어붙이고 결과물을 제공해야 함
• 과소 약속하고 초과 달성하기:
  • 주인공이 이미 완료된 작업을 완료했다고 거짓말하는 것은 어느 정도 "과소 약속하고 초과 달성하기"로 볼 수 있음
  • 미완성 작업에 대해 거짓말하는 것은 더 위험하고 팀원들이 다시 돌아오는 것에 대해 사기를 떨어뜨릴 수 있음
• 무력한 조직과 로우코드 도구:
  • 벤더의 형편없는 관행과 겸손한 프로젝트 범위는 일부 대기업이 소프트웨어 프로젝트에 대해 얼마나 무력감을 느끼는지 보여줌
  • 이는 엔지니어는 아니더라도 기술 리더십에게 Retool과 같은 로우코드 도구의 인기를 설명할 수 있음
• 정직성과 거절하기:
  • 진정한 "록스타"는 정직성을 갖추고 어리석음과 불합리한 요구를 거절할 용기가 있음
  • 비상한 무능력을 보완하거나 팀 전체의 부담을 떠안는 것은 개인의 책임이 아님