GN⁺: 빅테크에서 프로젝트를 Ship 하는 방법
(seangoedecke.com)출시(Shipping)가 어려운 이유
- 많은 사람들이 ‘출시’가 쉬운 일이라고 착각하지만, 기본 상태는 출시가 지연되거나 취소되거나, 혹은 완성도가 낮아 문제가 발생하는 경우가 많음.
- 코드를 모두 작성하거나 Jira 티켓을 모두 해결했다고 자동으로 출시되는 것이 아님. 출시를 위해 누군가가 리드 역할을 맡아야 함.
- 출시가 최우선 과제가 되어야 함. 사용자 경험(UX)에 지나치게 집중하면 오히려 출시가 지연됨.
- 프로젝트를 성공적으로 출시하려면, 기술적인 리더나 DRI(Directly Responsible Individual)가 필요함. 이러한 역할을 맡는 엔지니어가 있는 팀은 성공 확률이 높아짐.
‘출시’란 무엇인가?
- 많은 엔지니어들은 ‘출시’를 단순히 코드 배포나 기능 활성화로 생각하지만, 이는 큰 테크 회사에서는 다르게 정의됨.
- 출시는 회사 내 중요한 사람들이 ‘출시되었다’고 믿을 때 이루어지는 것임. VP나 CEO가 만족하지 않으면, 코드가 배포되었더라도 실제로 ‘출시된’ 것이 아님.
- 프로젝트가 사용자에게 큰 성공을 거두거나 수익을 올리면 출시된 것이지만, 사용자 반응이 좋지 않더라도 리더십이 만족하면 출시된 것으로 간주됨.
커뮤니케이션의 중요성
- 프로젝트의 목표가 무엇인지 명확히 파악해야 함. 목표에 따라 작업 방식과 커뮤니케이션 전략이 달라짐.
- 회사의 리더십은 프로젝트의 기술적 세부사항을 거의 모름. 따라서 신뢰를 유지하기 위해 정확한 예상, 문제 해결, 그리고 적절한 업데이트가 중요함.
- 신뢰를 유지하는 방법:
- 과거 성공적인 출시 경험이 있는 경우 유리함.
- 자신감 있는 태도를 보여야 함.
- NASA의 미션 컨트롤처럼 전문적이고 간결하게 소통해야 함.
- 일일 또는 주간 업데이트 스레드를 통해 능동적으로 정보를 제공해야 함.
프로덕션 배포 문제 해결
- 대부분의 문제는 예상치 못한 세부 사항에서 발생함. 예를 들어, Memcached의 블록 크기 문제나 트래픽 예측 오류, 민감한 사용자 데이터 문제 등이 있음.
- 문제를 빠르게 해결하기 위해 시스템에 대한 깊은 기술적 이해가 필요함.
- 예상되는 문제에 대해 빠르게 대응하고, 문제가 심각한지 아닌지를 명확히 설명할 수 있어야 함.
지금 당장 출시할 수 있는가?
- 지금 당장 출시할 수 있는지 스스로 질문해보는 것이 중요함. 만약 그렇지 않다면, 무엇이 변경되어야 가능한지 고민해야 함.
- 기능 플래그와 스테이징 환경을 활용해 가능한 빨리 피드백을 받을 수 있도록 해야 함.
- 출시 직전에는 기술 작업을 줄이고, 문제가 발생했을 때 빠르게 대응할 수 있도록 준비해야 함.
요약
- 출시 작업은 매우 어렵고, 최우선 과제로 삼아야 함.
- 출시의 의미는 단순한 배포가 아니라 리더십 팀이 만족하는 것임.
- 리더십 팀의 신뢰를 얻는 것이 성공적인 출시의 핵심임.
- 문제를 예상하고 대처할 수 있는 백업 플랜이 중요함.
- 출시 직전에는 개발 작업을 줄이고 문제 해결에 집중할 수 있어야 함.
- 항상 “지금 당장 출시할 수 있는가?”라는 질문을 던져야 함.
- 두려움을 버리고 용기를 가져야 함.
Hacker News 의견
- "Shipping"은 회사 내 사회적 구성물이라는 관찰이 인상적임. 중요한 사람들이 프로젝트가 완료되었다고 믿을 때 완료된 것임
- 이 기사는 소프트웨어 배포가 아닌 경영진을 만족시키는 것에 관한 것임. 사용자들이 싫어하고 시장이 비웃어도 경영진이 좋아하면 배포된 것임
- 스포츠에서 승리가 모든 문제를 해결하듯, 소프트웨어에서는 배포가 모든 문제를 해결함. 완벽한 제품은 없지만, 일찍 배포하면 사용자들이 만족할 수 있음
- 문제를 예방하는 것보다 문제를 해결하는 엔지니어가 더 많은 인정을 받는 경우가 있음. 문제를 예방하려고 노력하지만, 리더들은 이를 인식하지 못할 때가 있음
- 대기업에서는 "배포"가 단순히 기능을 현실화하는 것이 아닌, 더 큰 맥락에서 이해되어야 함. 일부는 이를 비윤리적이라고 할 수 있지만, 대기업에서는 일종의 "게임"임
- 많은 프로젝트를 배포했지만, 구체적인 사례가 없어 신뢰하기 어려움. 실제 프로젝트 사례가 포함되었으면 더 이해하기 쉬웠을 것임
- 이 기사는 자기 홍보성 블로그 스팸임
- 경험과 일치하지만 실질적인 조언이 부족함. 리더십의 인정을 받는 방법에 대한 구체적인 사례가 필요함
- 대기업에서의 경험과 다름. 경영진의 지원 없이도 사용자 피드백이나 지표가 긍정적이면 성공으로 간주됨. 작은 프로젝트도 가치가 있을 수 있음
- 주장을 정량화하고 정성화해야 신뢰할 수 있음. "대기업에서 배포한다"는 광범위한 진술이며, 구체적인 설명이 필요함
인상적인 의견 발췌해봤습니다.
“어떤 사람들은 단지 자신들만을 위한 기술 영역을 구축하거나, 어떤 계층에서든 자신보다 위에 있는 사람들로부터 칭찬을 받고 싶어합니다. 이게 "게임이 진행되는 방식"입니다. 이 게임을 하는 것은 결국 조직의 죽음으로 이어지고, 이것이 바로 우리가 애초에 기업 라이프 사이클을 갖는 이유입니다. 결국 이런 사람들은 조직을 내부에서 망가뜨리고, 실제 의견을 가진 사람이나 실제로 일을 처리하기 위해 최적화하는 사람을 밀어냅니다.”
“게임에서 이기는 방법은 게임을 플레이하지 않는 것입니다”