대형 테크 기업에서 프로젝트를 출시하는 법
누군가 그 어려운 출시라는 일을 끝까지 책임지기 때문에
1. 모든 코드를 다 작성하고, Jira 티켓을 전부 닫았다고 해서 프로젝트가 저절로 출시되는 일은 없습니다.
2. 프로젝트가 실제로 출시되는 건, 누군가가 그 어렵고 섬세한 ‘출시’라는 일을 책임지고 끝까지 밀어붙이기 때문이에요.
3. 그래서 거의 모든 경우에 ‘출시’가 최우선 순위가 되어야 합니다. 다른 어떤 것도 1순위로 둘 수 없어요.
4. 많은 엔지니어들이 대형 테크 기업에서 ‘출시’가 실제로 무엇을 의미하는지조차 제대로 이해하지 못하는 경우가 많다고 생각합니다.
5. 단순히 코드를 배포하거나, 새로운 기능을 사용자에게 공개하는 것만으로는 충분하지 않습니다. ‘출시’란 회사 내부에서 형성되는 일종의 사회적 합의, 즉 사회적 구성물(social construct)입니다.
6. 구체적으로 말하면, 회사 내에서 중요한 사람들이 그 프로젝트가 출시됐다고 인정할 때 비로소 ‘출시’가 되는 겁니다.
7. 시스템을 배포했더라도, 매니저나 VP, CEO가 그 결과에 불만족한다면, 그건 출시가 아닙니다. 회사 리더십이 ‘출시’를 공식적으로 인정해줄 때만 진짜 출시했다고 할 수 있습니다.
8. 물론, 사용자들이 열광하고 회사에 큰 수익을 가져다주는 무언가를 배포했다면, 그건 분명히 출시한 게 맞습니다. 하지만 그게 맞는 이유는, 사용자를 만족시키고 돈을 버는 일이 회사 리더십을 기쁘게 만드는 일이기 때문이에요.
9. 출시를 단순히 요구사항을 충족하거나 코드를 배포하는 일로 생각하는 엔지니어들은, 결국 계속해서 ‘실패한 출시’를 반복하게 될 겁니다.
10. 출시 직전 이슈가 발생했을 때 다른 일에 치여 손을 쓸 수 없는 상황을 막으려면, 항상 일정에 여유를 두고 즉각 대응할 수 있는 상태를 유지해야 합니다.
11. 문제를 미리 발견하는 가장 좋은 방법은 가능한 한 빨리 배포해보는 것입니다. 항상 스스로에게 “지금 당장 이걸 출시할 수 있을까?”라고 질문해보세요.
12. 이번 주, 오늘이 아니라 바로 이 순간 기준으로 말이죠. 만약 당장 출시할 수 없다면, 무엇이 바뀌어야 지금 바로 출시가 가능해질지 고민해야 합니다.
13. 항상 기억해야 할 가장 중요한 우선순위는 리더십 팀과의 신뢰를 지키는 것입니다. 이런 신뢰를 쌓는 데 가장 효과적인 방법은 항상 백업 플랜(플랜 B)을 준비해두는 것입니다.
14. 긴급 상황이 닥쳤을 때 백업 플랜이 있다는 건, 상황을 충분히 통제하고 있다는 신호가 되기 때문이죠.
15. 많은 엔지니어들이 배포를 미루는 이유는 결국 두려움 때문인 경우가 많다고 생각합니다. 하지만 정말로 프로젝트를 출시하고 싶다면, 정반대로 행동해야 합니다.
16. 최대한 빨리, 최대한 자주 배포해야 하고, 가장 부담스럽고 두려운 변경사항일수록 오히려 초기에 먼저 시도해야 합니다.
17. 프로젝트 전체 맥락을 가장 잘 알고 있는 사람은 바로 당신이기 때문에, 오히려 이런 ‘큰 변화’에 대해 가장 덜 두려워해야 할 사람도 바로 당신입니다.
18. 만약 당신이 중요한 변경을 누군가 다른 엔지니어가 해주길 기다리고 있다면, 안타깝게도 그 사람이 진짜로 당신 프로젝트의 출시를 주도하고 있는 셈입니다.
