대형 기술 기업에서 프로젝트를 성공적으로 출시하기 위해 필요한 우선순위, 소통, 신뢰, 문제 예측 및 대비책에 관한 글입니다.
기술 업계에서 지난 약 10년 동안 아주 다양한 프로젝트를 출시해 왔습니다. 제대로 해내는 것이 중요할 때 새로운 프로젝트를 이끌어 달라는 요청을 자주 받는데, 제가 그 일을 잘하기 때문입니다. 대형 기술 기업에서 출시는 코드를 작성하는 것과는 매우 다른 기술이며, 코드 작성에는 뛰어난 많은 사람이 출시에는 형편없습니다.
프로젝트를 이끌 때 제가 생각하는 것과 사람들이 잘못하는 모습을 보아 온 지점을 정리해 보겠습니다.
제가 보는 가장 흔한 오류는 출시가 쉽다고 가정하는 것입니다. 프로젝트의 기본 상태는 _출시되지 않는 것_입니다. 무기한 연기되거나, 취소되거나, 미완성 상태로 나가서 불길에 휩싸입니다. 코드가 모두 작성되거나 Jira 티켓이 모두 닫혔다고 해서 프로젝트가 자동으로 출시되지는 않습니다. 누군가가 그것을 출시하는 어렵고 섬세한 일을 맡기 때문에 출시되는 것입니다.
이는 거의 모든 경우에 출시가 최우선이어야 한다는 뜻입니다. 다른 어떤 것도 최우선 순위로 둘 수 없습니다. 예를 들어 고객 경험을 다듬는 일만 걱정하며 모든 시간을 쓴다면, 출시하지 못합니다! 팀의 엔지니어일 때 UX에 집착하는 것은 칭찬할 만한 행동이지만, 프로젝트를 이끌고 있다면 실수입니다. 그런 일을 하는 팀의 다른 엔지니어들을 소중히 여기고 가능한 한 많은 지원을 제공해야 합니다. 하지만 여러분의 주된 관심사는 프로젝트를 출시하는 것이어야 합니다. 여가 시간에 해낼 수 있을 만큼 쉬운 일이 아닙니다.
제 경험상 프로젝트는 거의 언제나 한 사람이 출시되도록 만들기 때문에 출시됩니다. 분명히 하자면, 그 사람이 모든 코드를 작성하거나 모든 일을 하는 것은 아니며, 전체 팀의 뒷받침 없이 프로젝트가 출시될 수 있다는 말도 아닙니다. 그러나 프로젝트의 한 사람이 전체를 처음부터 끝까지 이해하는 것은 정말 중요합니다. 기술적으로 어떻게 맞물리는지, 어떤 제품 또는 사업 목적을 위해 존재하는지를 말입니다. 좋은 팀과 회사는 이를 이해하고, 모든 프로젝트에 단 한 명의 책임 엔지니어가 있도록 보장합니다. 일반적으로 이 직책은 “기술 리드” 또는 “DRI” 역할이라고 불립니다. 나쁜 팀과 회사는 그렇게 하지 않으며, 엔지니어가 자발적으로 이 역할을 맡느냐에 따라 프로젝트의 성패가 갈립니다.
왜 এত 많은 엔지니어가 출시가 쉽다고 생각할까요? 극단적으로 들리는 건 알지만, 많은 엔지니어가 대형 기술 기업 내부에서 출시가 무엇인지조차 이해하지 못한다고 생각합니다. 출시한다는 것은 무엇일까요? 코드를 배포한다는 뜻도 아니고, 기능을 사용자에게 제공한다는 뜻조차 아닙니다. 출시는 회사 내부의 사회적 구성물입니다. 구체적으로 말하면 회사에서 중요한 사람들이 프로젝트가 출시되었다고 믿을 때 프로젝트는 출시된 것입니다. 시스템을 배포했더라도 관리자나 VP 또는 CEO가 그것에 매우 불만족한다면, 여러분은 출시하지 않은 것입니다. 무엇인가를 출시했을 수는 있지만, 실제 프로젝트를 출시한 것은 아닙니다. 회사의 리더십이 여러분이 출시했다고 인정할 때에만 출시했음을 알 수 있습니다. VP가 Slack에 축하 메시지를 남기는 것은 좋은 신호이며, 승리를 선언하는 사내 블로그 글도 마찬가지입니다. 작은 출시라면 관리자의 칭찬이면 충분합니다.
이는 아마 순환 논증처럼 들리겠지만, 정말 중요한 지점이라고 생각합니다. 물론 사용자가 좋아하고 막대한 돈을 버는 무언가를 배포했다면 출시한 것입니다. 하지만 이는 사용자 만족과 수익 창출이 리더십 팀을 만족시키기 때문일 뿐입니다. 사용자가 싫어하고 돈도 벌지 못하는 무언가를 출시했지만 리더십 팀이 만족한다면, 여러분은 여전히 출시한 것입니다. 이에 대해 어떤 감정을 느끼든 상관없지만, 사실입니다. 마음에 들지 않는다면 사용자가 얼마나 행복한지를 정말 중요하게 여기는 회사에서 일하는 편이 좋을 것입니다.
출시가 명세를 전달하거나 코드를 배포하는 것이라고 생각하는 엔지니어는 반복해서 실패한 출시로 스스로를 몰고 갈 것입니다.
그렇다면 무언가를 출시할 때 여러분의 주된 일이 회사 리더십이 프로젝트에 만족하도록 만드는 것이라면, 실무에서는 무엇을 뜻할까요? 첫째, 회사가 이 프로젝트를 통해 무엇을 얻으려 하는지 명확히 파악해야 합니다. 때로는 소수의 사용자에게서 더 많은 돈을 얻는 일입니다. 예를 들어 엔터프라이즈 기능이 그렇습니다. 때로는 전체 사용자 집합을 늘리기 위해 돈을 쓰는 일입니다. 예를 들어 눈에 띄는 무료 요금제 기능이 그렇습니다. 때로는 특정 대형 고객을 위해 기능을 만들어 그 고객을 달래는 일입니다. 때로는 영향력 있는 VP나 CEO의 개인 프로젝트일 뿐이고, 그들의 비전에 맞춰야 합니다. 가능한 이유는 많으며, 프로젝트를 출시하고 싶다면 이 경우에 어떤 이유가 적용되는지 알아야 합니다. 그에 맞춰 업무와 소통을 정렬하세요! 예를 들어 엔터프라이즈 기능에는 눈에 띄는 UI가 필요하지 않은 경우가 많지만 요구사항에는 완전히 유연성이 없고, 최종 사용자용 기능은 세련되어야 하며, 개인 프로젝트라면 그 프로젝트의 주인인 특정 영향력 있는 인물과 적극적으로 소통해야 합니다.
둘째, 프로젝트 목표와 관계없이 여러분의 리더십 팀, 즉 프로젝트에 관심을 두는 보고 체계상의 사람들은 언제나 여러분에 비해 프로젝트의 기술적 맥락을 사실상 전혀 알지 못합니다. 즉, 그들은 추정치, 기술적 질문에 대한 답변, 기술적 문제의 예측을 여러분에게 의지하게 됩니다. 그 신뢰를 유지하는 일이 여러분의 최우선 순위여야 합니다. 일을 해낼 능력과 계속 상황을 알릴 능력에 대한 믿음이 없다면, 출시하지 못할 것입니다. 그들은 위험을 줄이기 위해 프로젝트를 취소하거나, 아무런 관심이나 축하 없이 출시되도록 내버려 둘 것입니다. 축하받지 못한 출시는 출시가 아니라는 점을 기억하세요! 또는 여러분을 옆으로 밀어내고 다른 엔지니어에게 갈 것이며, 그 엔지니어가 공식적으로든 비공식적으로든 실제로 프로젝트를 출시하는 사람이 될 것입니다. 어느 쪽이든 평가 시기에 그 영향을 느끼게 될 것이며, 다음 프로젝트에서는 그들이 다른 사람을 찾을 것입니다.
리더십 팀과의 신뢰는 어떻게 유지할까요? 이것만으로도 글이나 책 한 권이 될 수 있지만, 요약하면 다음과 같습니다.
이런 일을 하는 것이 프로젝트를 정확한 마감일에 버그 하나 없이 출시하는 것보다 훨씬, 훨씬 더 중요합니다. 기술적 이유로 프로젝트를 연기해야 한다면, 제 경험상 이를 명확하고 자신 있게, 이상적으로는 어느 정도 미리 경고하며 소통하기만 하면 불이익을 받지 않을 것입니다. 실제로는 역설적으로, 지연을 강제하는 어떤 문제가 있는 편이 여러분에게 더 나을 때도 많습니다. 사고를 막은 신중한 엔지니어보다 사고를 긴급 수정한 영웅적인 온콜 엔지니어가 더 많은 공을 인정받는 것과 같은 이유입니다.
그렇더라도 일반적으로 프로젝트를 프로덕션에 올려야 합니다. 여기서 가장 흔한 문제는 핵심 세부 사항 하나를 놓치는 것입니다. 때로는 기술적 세부 사항입니다. 사용자 문서를 Memcached에 저장하는 데 의존하지만, 많은 문서가 여러 메가바이트여서 Memcached 블록 크기보다 클 수 있습니다. 때로는 조율의 세부 사항입니다. Memcached를 담당하는 플랫폼 팀은 프로젝트가 보낼 트래픽의 10분의 1을 예상하고 있었고, 그래서 VP들과 회의를 소집해 프로젝트를 지연시킬 수 있습니다. 때로는 법적 세부 사항입니다. 사용자 데이터가 예상보다 민감한데, 시스템에는 이를 안전하게 처리하는 데 필요한 통제 수단이 없을 수 있습니다. 이런 문제는 어디서든 발생할 수 있고 예측하기가 매우 어렵습니다. 이를 해결하려면 시스템에 대한 깊은 기술적 이해와 빠르게 방향을 전환할 능력이 필요합니다.
예를 들어 첫 번째 예시를 읽고 이제 “문서를 여러 Memcached 키에 나누어 저장하거나, 블록 크기를 늘리거나, Redis로 옮기는 등의 방법이 있겠네…”라고 생각할 수 있습니다. 모두 가능한 해결책입니다! 하지만 그중 어떤 해결책이 작동할지, 그리고 더 중요하게는 어떤 해결책이 프로젝트 일정을 망가뜨리지 않을지를 아는 것은 깊은 이해 없이는 불가능합니다.
문제가 실제일 필요조차 없기 때문에 이는 두 배로 중요합니다. 프로젝트 출시를 앞둔 시점에는 다른 팀이나 엔지니어가 잠재적인 문제를 제기하는 일이 매우 흔합니다. 예를 들어 “이 사용자 데이터가 Memcached에 들어갈 거라고 확신하나요?”라고 말할 수 있습니다. 이것이 문제가 아닌 이유를 설명하거나, 문제라면 출시 전에 어떻게 해결하고 있는지를 설명하는 사람이 아무도 나서지 않으면 프로젝트는 지연되고, 그것은 여러분의 책임이 됩니다. 왜일까요? 관리자는, 또는 관리자의 관리자도, 이것이 심각한 문제인지 알지 못하기 때문입니다. 그것이 그들이 여러분에게 급여를 지급하는 이유입니다! 여러분이 나서서 이를 해결하지 않는다면, 그들은 자연스럽게 신중한 쪽을 택해 출시하지 않을 것입니다.
이런 문제가 생겼을 때 다른 일에 깊이 파묻혀 있지 않도록 민첩함을 유지해야 합니다. 보통 이는 구현에 완전히 몰두하지 않는 것을 뜻합니다. 즉, 프로젝트의 다른 엔지니어에게 작업을 위임하는 것입니다. 이상적으로는 프로젝트 초기 단계에서 시간의 최소 20%를 구현으로부터 비워 두고, 마지막 며칠에는 90~100%까지 늘려야 합니다. 그렇게 한다면 문제가 발생했을 때 온전히 주의를 기울일 수 있습니다.
제가 본 방식 중에는 기능 플래그가 이를 위한 가장 좋은 방법이지만, 스테이징 환경도 효과가 있고 그 밖의 방법도 있습니다. 핵심은 여러분이 만드는 것을 가능한 한 많은 사람의 눈앞에 두는 것입니다. 여러분 자신뿐 아니라 다른 엔지니어들, 이상적으로는 리더십, 제품, 디자인 등의 사람들 앞에 두어야 합니다. 아주 거친 상태일지라도 실제 기능을 5분간 사용해 보면 아무도 예상하지 못했던 문제가 드러납니다. 그들이 직접 볼 수 있게 하는 것 역시 여러분이 상황을 통제하고 있다는 확신을 리더십에 주는 데 큰 도움이 됩니다.
문제를 예측하는 최선의 방법은 일찍 배포하는 것입니다. 일반적으로 유용한 질문은 **지금 당장 이것을 출시할 수 있는가?**입니다. 이번 주도 아니고 오늘도 아닙니다. 바로 이 순간입니다. 그렇지 않다면, 무언가를 출시할 수 있으려면 무엇이 바뀌어야 할까요? 출시하려면 배포가 필요한가요? 기능 플래그 뒤에서 지금 배포할 수 있을까요? 다른 팀이 자기들 쪽에서 변경하기를 기다리고 있다면, 결국 그 변경이 시스템에 꼭 필요하지 않도록 만들 수 있을까요? 예를 들어 플랫폼 팀이 캐시 계층을 구축하고 있다면, 캐시를 찾을 수 없더라도 기능이 조금 느리게나마 작동하도록 만들 수 있습니다.
여러분의 주된 우선순위는 리더십 팀의 신뢰를 유지하는 것임을 기억하세요. 대비책을 갖추는 것만큼 신뢰를 쌓는 일은 없습니다. 비상 상황에서 대비책은 상황에 대한 통제력을 보여 주기 때문입니다. 최악의 일이 벌어져 당일에 출시할 수 없더라도, 관리자가 자신의 관리자에게 “우리의 선택지는 4일 연기하거나, X를 포기하고 내일 출시하는 것입니다”라고 말할 수 있다면 훨씬 더 만족할 것입니다. X를 포기하는 것이 선택 불가능한 일이라 해도 말입니다. 그러면 그들은 지연을 여러분이 효과적으로 처리한 불가피한 문제로 해석할 가능성이 커집니다. 여러분이 저질러서 그들이 여러분을 신뢰할 수 없다는 뜻이 된 실수로 해석하는 대신 말입니다.
많은 엔지니어가 본질적으로 두려움 때문에 배포를 미룬다고 생각합니다. 출시하고 싶다면 정확히 반대로 해야 합니다. 가능한 한 많은 것을 가능한 한 일찍 배포해야 하며, 가장 무서운 변경은 가능한 한 일찍 해야 합니다. 프로젝트의 처음부터 끝까지의 맥락을 가장 많이 아는 사람은 여러분이라는 점을 기억하세요. 즉, 여러분이 무서운 변경을 가장 덜 두려워해야 합니다. 다른 모든 사람은 더 많은 미지수를 다루고 있으며, 큰 레버를 당기려는 의지도 더 적을 것입니다. 이 모든 것을 파악하고 있고 여러분이 기다리는 다른 엔지니어가 있다면, 나쁜 소식입니다. 그 사람이 실제로 여러분의 프로젝트를 출시하는 사람일 가능성이 큽니다.
수정: 이 글은 많은 댓글과 함께 Hacker News에서 논의되었습니다.
수정: 과정이 궁금하다면, 이 글에 관해 Writing About Writing과 인터뷰를 했습니다.
이 글이 마음에 들었다면, 새 글에 관한 이메일 업데이트를 구독하거나 Hacker News에서 공유해 보세요.
다음은 이 글과 태그를 공유하는 관련 글의 미리보기입니다.
장애를 지루하게 유지하라
인터넷에는 흥미진진한 장애 전쟁 이야기가 가득합니다. 잠이 부족한 개발자들이 압박 속에서 해결하는 어려운 엔지니어링 문제들입니다. 최고의 코드가 대개 가장 지루한 구현인 업계에서, 멋진 아이디어를 급히 해킹해 만드는 일이 무책임한 행동이 아니라 영웅적 행동이 되는 곳이 적어도 하나는 있다는 생각은 좋습니다. 저를 포함한 일부 엔지니어에게 온콜은 정말 매혹적인 매력이 있습니다. 압박 속에서 일하는 것은 재미있고, 장애를 해결하는 사람이 되는 데에는 즉각적인 인정이 많이 따릅니다. 다른 사람들은 이런 영웅 심리의 문제를 많이 썼습니다. 엔지니어는 빠르게 단일 장애점이 되어 번아웃에 이르고, 조직은 장애 _대응_보다 장애 _예방_에 불리한 유인을 갖게 됩니다. 저는 그 모든 것에 동의합니다. 하지만 전쟁 이야기의 만연함은 효과적인 장애 대응자가 되는 일이 실제로 어떤 것인지도 잘못 보여 준다고 생각합니다. 거의 어떤 장애도 흥미롭지 않습니다. 높은 압박은 있지만, 엔지니어링 관점에서는 대개 지루합니다.
계속 읽기...
