지난 10여 년 동안 테크 업계에서 정말 다양한 프로젝트를 실제로 세상에 출시해 왔어요. 중요한 프로젝트를 꼭 성공적으로 완수해야 할 때마다 저에게 리더십을 맡기는 경우가 많은데, 그건 제가 이런 일을 잘 해내기 때문이죠. 대형 테크 기업에서 프로젝트를 ‘출시’하는 역량은 단순히 코드를 잘 짜는 것과는 완전히 다른 능력입니다. 실제로, 코딩 실력이 뛰어난 사람들 중에도 ‘출시’에는 영 소질이 없는 경우가 많아요.
제가 프로젝트를 이끌 때 항상 염두에 두는 점들과, 많은 사람들이 흔히 실수하는 부분에 대해 이야기해보려 합니다.
출시는 어렵습니다
가장 흔하게 보는 실수는, ‘출시’가 쉽다고 생각하는 거예요. 사실 프로젝트의 기본 상태는 ‘출시되지 않은 상태’입니다. 대부분의 프로젝트는 끝없이 지연되거나, 중간에 취소되거나, 아니면 제대로 준비되지 않은 채 억지로 출시됐다가 문제를 일으키곤 하죠. 모든 코드를 다 작성하고, Jira 티켓을 전부 닫았다고 해서 프로젝트가 저절로 출시되는 일은 없습니다. 프로젝트가 실제로 출시되는 건, 누군가가 그 어렵고 섬세한 ‘출시’라는 일을 책임지고 끝까지 밀어붙이기 때문이에요.
그래서 거의 모든 경우에 ‘출시’가 최우선 순위가 되어야 합니다. 다른 어떤 것도 1순위로 둘 수 없어요. 예를 들어, 고객 경험을 다듬는 데만 온 신경을 쏟는다면, 결국 출시하지 못하게 됩니다! 팀의 엔지니어로서 UX에 집착하는 태도는 칭찬받을 만하지만, 프로젝트 리더라면 그건 큰 실수예요. 그런 세심한 부분을 챙기는 팀원들은 정말 소중한 존재이니, 그들이 잘 일할 수 있도록 최대한 지원해주면 됩니다. 하지만 리더로서 당신이 가장 신경 써야 할 일은 프로젝트를 ‘출시’하는 거예요. 이 일은 남는 시간에 틈틈이 할 수 있을 만큼 쉬운 일이 아닙니다.
제 경험상, 거의 모든 프로젝트는 결국 한 사람이 끝까지 책임지고 밀어붙이기 때문에 출시됩니다. 물론 그 사람이 모든 코드를 직접 짜거나 모든 일을 혼자 해낸다는 뜻은 아니고, 팀 전체의 협력이 반드시 필요하다는 점도 분명히 하고 싶어요. 하지만 프로젝트 안에 반드시 한 명은, 전체를 처음부터 끝까지 완벽하게 이해하고 있는 사람이 있어야 합니다. 즉, 이 프로젝트가 기술적으로 어떻게 구성되어 있는지, 그리고 어떤 제품이나 비즈니스 목표를 위해 존재하는지까지 모두 파악하고 있는 사람이 필요하다는 뜻이죠. 좋은 팀과 회사는 이런 점을 잘 이해하고 있어서, 모든 프로젝트마다 단 한 명의 책임 엔지니어(보통 ‘테크 리드(Technical Lead)’나 ‘DRI(Directly Responsible Individual)’라고 부릅니다)를 꼭 지정합니다. 반대로, 그렇지 않은 팀이나 회사는 이런 역할을 명확히 정하지 않기 때문에, 누군가가 자발적으로 이 역할을 맡아 나서지 않으면 프로젝트의 성패가 그때그때 달라질 수밖에 없습니다.
출시란 무엇인가?
왜 이렇게 많은 엔지니어들이 출시(Shipping)가 쉽다고 생각할까요? 다소 극단적으로 들릴 수 있지만, 많은 엔지니어들이 대형 테크 기업에서 ‘출시’가 실제로 무엇을 의미하는지조차 제대로 이해하지 못하는 경우가 많다고 생각합니다. 그렇다면, ‘출시한다’는 건 도대체 무슨 뜻일까요? 단순히 코드를 배포하거나, 새로운 기능을 사용자에게 공개하는 것만으로는 충분하지 않습니다. ‘출시’란 회사 내부에서 형성되는 일종의 사회적 합의, 즉 사회적 구성물(social construct)입니다. 구체적으로 말하면, 회사 내에서 중요한 사람들이 그 프로젝트가 출시됐다고 인정할 때 비로소 ‘출시’가 되는 겁니다. 시스템을 배포했더라도, 매니저나 VP, CEO가 그 결과에 불만족한다면, 그건 출시가 아닙니다. (뭔가를 배포하긴 했겠지만, 진짜 프로젝트 자체를 출시한 건 아니죠.) 회사 리더십이 ‘출시’를 공식적으로 인정해줄 때만 진짜 출시했다고 할 수 있습니다. VP가 Slack에서 축하 메시지를 남기거나, 사내 블로그에 성공적으로 끝냈다는 글이 올라오는 게 대표적인 신호죠. 규모가 작은 프로젝트라면, 매니저의 간단한 칭찬 한마디 정도로도 충분할 수 있습니다.
이게 좀 돌고 도는 얘기 같지만,, 정말 중요한 포인트라고 생각해요. 물론, 사용자들이 열광하고 회사에 큰 수익을 가져다주는 무언가를 배포했다면, 그건 분명히 출시한 게 맞습니다. 하지만 그게 맞는 이유는, 사용자를 만족시키고 돈을 버는 일이 회사 리더십을 기쁘게 만드는 일이기 때문이에요. 반대로, 사용자들이 싫어하고 돈도 못 버는 무언가를 출시했더라도, 리더십이 만족한다면 그 역시 ‘출시’로 인정받습니다. 이게 마음에 들지 않을 수도 있지만, 현실이 그렇습니다. 만약 이런 기준이 마음에 들지 않는다면, 정말로 사용자 만족을 최우선으로 생각하는 회사에서 일하는 게 더 맞을 수도 있어요.
출시를 단순히 요구사항을 충족하거나 코드를 배포하는 일로 생각하는 엔지니어들은, 결국 계속해서 ‘실패한 출시’를 반복하게 될 겁니다.
커뮤니케이션
결국 프로젝트를 출시할 때 가장 중요한 역할이 회사 리더십을 만족시키는 것이라면, 실제로 그게 무슨 의미일까요? 가장 먼저 해야 할 일은, 이 프로젝트를 통해 회사가 진짜로 얻고자 하는 것이 무엇인지 명확하게 파악하는 것입니다.
회사가 프로젝트를 통해 얻고자 하는 목표는 상황마다 다릅니다. 예를 들어, 일부 사용자(주로 엔터프라이즈 고객)에게서 더 많은 수익을 얻기 위해 특정 기능을 개발할 수도 있고, 반대로 무료 플랜 등으로 전체 사용자 수를 늘리기 위해 비용을 들여 화려한 기능을 추가할 수도 있습니다. 때로는 아주 큰 고객사의 요구를 맞추기 위해 그 고객만을 위한 기능을 만들어야 할 때도 있고, 단순히 영향력 있는 VP나 CEO가 관심을 갖고 추진하는 ‘사내 주요 인사의 개인 프로젝트’일 수도 있죠. 이렇게 다양한 이유가 있을 수 있으니, 프로젝트를 제대로 출시하려면 이번 프로젝트에 어떤 동기가 적용되는지 반드시 파악해야 합니다. 그리고 그에 맞게 일의 우선순위와 커뮤니케이션 방식을 맞춰야 하죠. 예를 들어, 엔터프라이즈 기능은 화려한 UI가 필요하지 않지만 요구사항은 절대적으로 지켜야 하고, 일반 사용자 대상 기능은 완성도와 다듬어진 경험이 중요합니다. 만약 주요 인사의 개인 프로젝트라면, 그 사람과 긴밀하게 소통하며 비전을 맞추는 게 핵심입니다. 이런 식으로 프로젝트의 목적에 따라 일하는 방식과 소통 방식도 달라져야 합니다.
둘째, 프로젝트의 목표가 무엇이든 간에, 리더십 팀(즉, 당신의 보고 체계에 있는 프로젝트 관련 의사결정자들)은 당신에 비해 기술적인 맥락을 거의 알지 못한다는 점을 항상 기억해야 합니다. 그래서 그들은 일정 산정, 기술적 질문에 대한 답변, 그리고 잠재적인 기술적 문제 예측까지 모두 당신에게 의존하게 됩니다. 이 신뢰를 유지하는 것이 최우선 과제입니다. 만약 리더십이 당신이 일을 제대로 해낼 수 있고, 필요한 정보를 잘 전달해줄 거라는 믿음을 갖지 못한다면, 프로젝트는 절대 출시되지 않습니다. 리더십은 리스크를 줄이기 위해 프로젝트를 취소하거나, 아무런 관심이나 축하 없이 조용히 배포해버릴 수도 있어요(축하받지 못한 론칭은 진짜 출시가 아니라는 점을 기억하세요!). 혹은 당신을 배제하고 다른 엔지니어에게 주도권을 넘길 수도 있는데, 그렇게 되면 공식적으로든 비공식적으로든 그 사람이 실제로 프로젝트를 출시하는 역할을 맡게 됩니다. 어느 쪽이든, 연말 평가 때 그 결과를 체감하게 될 것이고, 다음 프로젝트에서는 리더십이 당신이 아닌 다른 사람을 찾게 될 겁니다.
리더십 팀의 신뢰를 어떻게 유지할 수 있을까요? 이 주제만으로도 한 편의 글, 아니 책 한 권이 나올 수 있겠지만, 요약하자면 이렇습니다.
- 가장 좋은 방법은 과거에 실제로 프로젝트를 성공적으로 출시한 경험(트랙레코드)을 쌓는 것입니다.
- 프로젝트에 대한 자신감을 보여야 합니다. 당신이 불안해 보이면 리더십도 똑같이 불안해집니다.
- 프로젝트를 완벽하게 통제하고 있다는 인상을 주는 것도 중요합니다. 마치 NASA 미션 컨트롤 센터처럼 모든 상황을 파악하고 있다는 느낌을 주는 게 이상적이죠.
- 전문적이고 간결하게 소통해야 하며, 리더십이 먼저 진행 상황을 물어보게 만들지 말고, 일일 또는 주간 단위로 어디엔가 진행 상황을 꾸준히 공유하는 것이 좋습니다.
프로젝트를 완벽하게 버그 없이, 정해진 기한에 맞춰 출시하는 것보다 위에서 말한 신뢰를 쌓는 일이 훨씬 더 중요합니다. 만약 기술적인 이유로 프로젝트 일정이 늦어질 수밖에 없다면, 제 경험상 미리 명확하고 자신감 있게(가능하다면 사전에) 그 사실을 잘 소통하기만 하면 불이익을 받지 않습니다. 오히려 역설적으로, 일정에 차질이 생겨서 문제를 해결해야 하는 상황이 생기면, 평소에 사고를 미리 막는 엔지니어보다 긴급 상황에서 문제를 해결하는 엔지니어가 더 큰 인정을 받는 것과 같은 이유로, 당신에게 더 유리하게 작용하는 경우도 많습니다.
운영 환경에 반영하기
프로젝트를 실제로 프로덕션(운영 환경)에 반영하는 과정에서도 여전히 넘어야 할 산이 많습니다. 이 단계에서 가장 흔하게 발생하는 문제는 중요한 디테일을 하나 놓치는 경우입니다. 예를 들어, 기술적인 문제라면 사용자 문서를 Memcached에 저장하려고 했는데, 실제로는 문서 크기가 여러 메가바이트에 달해서 Memcached의 블록 크기 제한을 초과해버릴 수 있습니다. 또, 협업과 관련된 문제일 수도 있습니다. 예를 들어, Memcached를 관리하는 플랫폼 팀이 우리 프로젝트에서 발생할 트래픽의 10분의 1만 예상하고 있었다면, 이로 인해 VP들과의 긴급 미팅이 잡히고 프로젝트 일정이 뒤로 밀릴 수 있습니다. 혹은 법적인 문제도 발생할 수 있습니다. 예기치 않게 사용자 데이터가 민감한 정보로 분류되어, 우리 시스템이 이를 안전하게 처리할 수 있는 통제 장치를 갖추지 못했다는 사실이 드러나는 경우도 있죠. 이런 문제들은 어디에서든 불쑥 튀어나올 수 있고, 미리 예측하기도 매우 어렵습니다. 이런 상황에 대처하려면 시스템에 대한 깊은 기술적 이해와, 문제가 생겼을 때 빠르게 방향을 전환할 수 있는 능력이 필요합니다.
예를 들어, 앞서 언급한 사례를 보고 “문서를 여러 개의 Memcached 키로 나눠서 저장하면 되지 않을까?”, “블록 크기를 늘리면 되지 않을까?”, “아니면 Redis로 옮기면 되지 않을까?” 같은 다양한 해결책이 떠오를 수 있습니다. 이런 방법들은 모두 가능성이 있는 대안입니다. 하지만 그중 어떤 방법이 실제로 효과가 있을지, 더 중요한 건 어떤 방법이 프로젝트 일정을 크게 지연시키지 않고 적용할 수 있을지 판단하려면, 시스템에 대한 깊은 이해가 반드시 필요합니다.
이런 기술적 이해가 특히 더 중요한 이유는, 실제로 문제가 발생하지 않았더라도 비슷한 상황이 얼마든지 생길 수 있기 때문입니다. 프로젝트 출시를 앞두고 있으면, 다른 팀이나 엔지니어들이 “사용자 데이터가 정말 Memcached에 다 들어갈 수 있는지 확실한가요?”처럼 잠재적인 문제를 제기하는 일이 아주 흔합니다. 이런 상황에서 아무도 나서서 “이건 문제가 되지 않는다”고 설명해주지 않거나, 만약 진짜 문제라면 “어떻게 출시 전에 해결할 계획인지”를 명확하게 답하지 않으면, 프로젝트는 지연될 수밖에 없고 그 책임은 결국 당신에게 돌아갑니다. 왜냐하면 당신의 매니저(혹은 그 위의 매니저)는 이 문제가 정말 심각한 건지 아닌지 알 방법이 없기 때문입니다. 바로 그런 판단을 내리라고 당신을 고용한 거죠! 만약 당신이 앞장서서 이런 이슈를 해결하지 않는다면, 리더십은 당연히 조심스럽게 행동할 수밖에 없고, 결국 프로젝트는 출시되지 않습니다.
이런 이슈가 발생했을 때 다른 일에 치여 손을 쓸 수 없는 상황을 막으려면, 항상 일정에 여유를 두고 즉각 대응할 수 있는 상태를 유지해야 합니다. 즉, 프로젝트 진행 중에 모든 구현 작업에 몰두하지 말고, 가능한 한 다른 엔지니어들에게 실무를 적절히 분배하는 것이 필요합니다. 이상적으로는 프로젝트 초반에는 전체 시간의 최소 20% 정도는 구현에서 벗어나 여유를 두고, 프로젝트가 막바지에 다다를수록 이 비율을 90~100%까지 점점 늘려야 합니다. 이렇게 해야 실제로 문제가 터졌을 때, 온전히 그 문제에 집중해서 신속하게 대응할 수 있습니다.
지금 당장 출시할 수 있을까?
제가 경험한 바로는, 이런 상황에서는 기능 플래그(Feature flag)를 활용하는 게 가장 효과적입니다. 물론 스테이징 환경 등 다른 방법도 있지만, 핵심은 지금 만들고 있는 기능을 최대한 많은 사람들에게 직접 보여주는 데 있습니다. 본인뿐만 아니라, 다른 엔지니어들, 그리고 가능하다면 리더십, 프로덕트, 디자인팀 등 다양한 사람들이 실제로 기능을 만져볼 수 있도록 하는 것이 중요합니다. 아무리 미완성된 상태라도, 실제로 기능을 5분만이라도 사용해보면 미처 예상하지 못했던 문제들이 곧바로 드러나게 됩니다. 또, 리더십 입장에서도 직접 눈으로 확인할 수 있으면, 당신이 모든 상황을 잘 관리하고 있다는 신뢰가 훨씬 더 커집니다.
문제를 미리 발견하는 가장 좋은 방법은 가능한 한 빨리 배포해보는 것입니다. 항상 스스로에게 “지금 당장 이걸 출시할 수 있을까?”라고 질문해보세요. 이번 주, 오늘이 아니라 바로 이 순간 기준으로 말이죠. 만약 당장 출시할 수 없다면, 무엇이 바뀌어야 지금 바로 출시가 가능해질지 고민해야 합니다. 만약 배포가 필요한 상황이라면, 기능 플래그(Feature flag)를 이용해 비공개로라도 바로 배포할 수 있는지 확인해보세요. 혹시 다른 팀에서 무언가를 변경해줘야만 출시가 가능한 상황이라면, 그 팀의 작업이 끝나지 않아도 시스템이 돌아가도록 설계를 바꿀 수는 없는지 생각해보세요. 예를 들어, 플랫폼 팀이 캐시 레이어를 세팅 중이라면, 캐시를 찾지 못하더라도(속도는 조금 느려지겠지만) 내 기능이 기본적으로는 동작하도록 만들어둘 수 있습니다.
항상 기억해야 할 가장 중요한 우선순위는 리더십 팀과의 신뢰를 지키는 것입니다. 이런 신뢰를 쌓는 데 가장 효과적인 방법은 항상 백업 플랜(플랜 B)을 준비해두는 것입니다. 긴급 상황이 닥쳤을 때 백업 플랜이 있다는 건, 상황을 충분히 통제하고 있다는 신호가 되기 때문이죠. 만약 정말 최악의 상황이 벌어져서 예정된 날짜에 출시하지 못하게 되더라도, 매니저가 상위 리더에게 “우리는 4일 출시를 미루거나, X를 포기하고 내일 바로 출시하는 두 가지 선택지가 있다”라고 보고할 수 있다면 훨씬 더 안심할 수 있습니다. 설령 X를 포기하는 게 현실적으로 불가능한 옵션이라 해도 마찬가지입니다. 이렇게 하면 매니저 입장에서는 이번 지연을 어쩔 수 없는 문제를 잘 관리한 결과로 받아들이게 되고, 당신이 실수해서 더 이상 믿을 수 없다는 식으로 생각하지 않게 됩니다.
많은 엔지니어들이 배포를 미루는 이유는 결국 두려움 때문인 경우가 많다고 생각합니다. 하지만 정말로 프로젝트를 출시하고 싶다면, 정반대로 행동해야 합니다. 최대한 빨리, 최대한 자주 배포해야 하고, 가장 부담스럽고 두려운 변경사항일수록 오히려 초기에 먼저 시도해야 합니다. 프로젝트 전체 맥락을 가장 잘 알고 있는 사람은 바로 당신이기 때문에, 오히려 이런 ‘큰 변화’에 대해 가장 덜 두려워해야 할 사람도 바로 당신입니다. 다른 사람들은 당신보다 모르는 부분이 더 많으니, 당연히 대담한 결정을 내리는 데 훨씬 더 소극적일 수밖에 없습니다. 만약 당신이 이런 중요한 변경을 누군가 다른 엔지니어가 해주길 기다리고 있다면, 안타깝게도 그 사람이 진짜로 당신 프로젝트의 출시를 주도하고 있는 셈입니다.
요약
- 출시(Shipping)는 정말 어렵기 때문에 반드시 최우선 순위로 두어야 합니다.
- 출시는 단순히 코드를 배포하는 것이 아니라, 리더십 팀이 만족하도록 만드는 일입니다.
- 프로젝트를 출시하려면 리더십 팀의 신뢰를 얻는 것이 필수적입니다.
- 진짜 중요한 기술적 업무는 문제를 미리 예측하고, 백업 플랜을 마련해두는 데 있습니다.
- 출시가 가까워질수록 직접 구현하는 일은 줄이고, 마지막 순간에 발생할 수 있는 문제에 바로 대응할 수 있도록 여유를 확보해야 합니다.
- 항상 “지금 당장 출시할 수 있는가?”를 스스로에게 물어보아야 합니다.
- 그리고, 용기를 가지세요!
원문: How I ship projects at big tech companies
blog by ash에서 더 알아보기
구독을 신청하면 최신 게시물을 이메일로 받아볼 수 있습니다.
