[번역] 빅테크의 프로젝트 관리 방식, 그리고 스크럼의 기이한 부재

빅테크의 프로젝트 관리 방식, 그리고 스크럼의 기이한 부재 (How Big Tech Runs Tech Projects and the Curious Absence of Scrum) 글을 읽고 느낀 점이 많아, 내용을 요약해 보았습니다.

전체적으로는 스크럼으로 대표되는 복잡한 프로세스를 가진 프로젝트 관리 방법과, 그와 상반되는 자유롭고 간단한 프로젝트 관리 방식을 오고가며 각 방식의 존재 의의를 짚어보는 글이었습니다. 인상 깊었던 부분은 빅테크 기업에는 프로젝트 일정을 관리하는 프로젝트 관리자 역할이 따로 없고, 해당 역할을 엔지니어가 직접 맡아서 한다는 점이었습니다. 이렇게 일을 하는 것이 스크럼과 같은 복잡한 프로세스를 버리는 데에 도움이 된다고 합니다. 개인적으로는 그렇게 일해본 적이 없어서, 이렇게 일하는 방식도 있구나, 과연 이러한 방식이 내가 일하는 팀에서도 통할까 하는 생각을 해 볼 수 있었던 기회가 되었습니다.

아래 요약은 글 전체의 완전한 번역이 아닙니다. 글의 순서대로 요약했지만, 중간중간 제 개인의 취향에 따라 생략된 부분들이나 제 마음대로 한 의역이 많습니다. 내용에 관심이 있다면 원문을 꼭 읽어보시길 추천드립니다!

원문 링크: https://blog.pragmaticengineer.com/project-management-at-big-tech/

스카이프, 스크럼, 그리고 정말로 중요한 사실들에 대한 알림

• 스카이프는 2012년부터 스크럼 방식으로 일하기 시작했고, 이는 프로덕트를 성공으로 이끌었다. 대표적으로, 배포 주기가 분기당 한 번에서 2-4주당 한번으로 줄어들었다
• 그 후, 왓츠앱이 갑자기 급부상해서 시장 지분을 급속도로 가져가기 시작했다. 왓츠앱은 스크럼과 같은 무거운 절차들 (heavyweight processes)를 의도적으로 무시했고, 결과적으로는 더 나은 결과물을 통해 메세징 앱의 대결에서 승리했다.
• 이 스토리에서 알 수 있듯이, 기업의 성공과 프로젝트 관리 방식은 항상 연관되어 있는 것은 아니다. 좋은 결과물을 만드는 데에 영향을 주는 요소는 많고, 프로젝트 관리 방식은 그 중 하나일 뿐이다.

업계의 프로젝트 관리 접근법

• 조사 결과, 기업들이 프로젝트를 관리하는 방식은 모두 달랐다. 회사의 규모에 따라 더 효과적인 방식이 있었고, 같은 규모의 기업에서도 다른 방식을 시도하는 쪽이 있었다. 다만 아래와 같은 인사이트를 얻을 수 있었다.
  • 전문 프로젝트 관리자가 있는 팀은 보통 만족도가 낮았다.하지만 투자를 받지 않은 기업이나 논테크 기업에서는 반대로 프로젝트 관리자에 대한 만족도가 높았다.
  • 일하는 방식을 자유롭게 선택할 수 있는 팀은 보통 빅테크 기업이나 시리즈 B 이상 스타트업에서 더 흔했다.
  • 팀의 자율성과 만족도는 연관되어 있었다.
  • 팀이 힘들어하는지 여부는 보통 프로젝트 관리 방법론과는 연관되어 있지 않았다. 기업 비전의 부족, 좋은 개발자의 이직, 낮은 투명성 등등 기타 요소의 영향이 더 컸다.
  • Jira에 대한 언급은 보통 부정적이였다.
• 팀원들이 불만족스러워하는 프로젝트 관리 방식은 보통 아래와 같은 공통적인 특징을 가지고 있었다.
  • 엔지니어들이 일정 산정에 참여하지 않는 것: 이는 엔지니어가 동기부여를 잃게 하는 가장 쉬운 방법이다.
  • 프로젝트 관리자가 따로 있음에도 불구하고, 요구사항이 빈번하게 변하는 것: 프로젝트 관리자가 따로 없는 팀에서는 엔지니어가 요구사항 변화에 더 원활하게 대응할 수 있었지만, 프로젝트 관리자가 있음에도 불구하고 요구사항이 빈번히 변하는 것은 팀에 악영향을 주었다.
  • 실패한 프로젝트 관리 방식을 바꿀 권한이 팀에 없는 것: 소프트웨어 엔지니어링과 같은 창의성이 필요한 작업에서는, 자율성을 부여하는 것이 효과적이다.

빅테크는 어떻게 프로젝트를 돌릴까

빅테크 기업은 프로젝트 실행 방식에 몇 가지 공통점이 있었다.

• 엔지니어가 프로젝트를 주도한다.
• 팀에는 프로젝트 관리 방식을 정할 수 있는 권한이 있다.
• 팀 전문 프로젝트 관리자는 없다. 몇 개의 팀이 같이 작업하는 큰 프로젝트의 관리에는 보통 TPM이 개입한다.
• 개발자의 생산성을 향상시키는 개발자 도구들(First-class developer tooling)이 주어졌다. 이런 도구들은 빠른 프로젝트 이터레이션에 큰 도움이 되었다.

프로젝트에 영향을 주는 빅테크 조직 구조

• 빅테크가 프로젝트를 관리하는 방식을 이해하기 위해서는, 먼저 빅테크에 주어진 환경을 보아야 한다.
  • 소프트웨어 엔지니어와 개발팀에 부여된 자율성. 전통 기업에서는 개발자가 단순히 주어진 일을 완료하기를 원하지만, 실리콘밸리 스타일의 기업에서는 개발자가 비즈니스 문제를 해결하는 사람이 되기를 기대한다. 이는 개발자의 일하는 방식에 큰 영향을 준다.
  • 생각 없는 자원이 아닌, 궁금증이 많은 문제 해결사. 동기부여된 엔지니어는 단순히 부여된 일을 하기만 하는 “공장 노동자" 에 비해 몇 배의 임팩트를 손쉽게 낼 수 있다. 공장 노동자 태도를 가진 조직은 보통 복잡한 절차를 가진 프로세스에 더 치우치는 성향이 있다.
  • 내부 데이터, 코드, 문서의 투명성. 엔지이어 외의 직원도 실시간으로 사업 지표를 확인하고, 커스텀 쿼리와 리포트를 만들 수 있다.
  • 누군가를 거쳐서 커뮤니케이션 하기 보다, 엔지니어 대 엔지니어의 직접 커뮤니케이션. 전통 기업은 보통 위계있는 커뮤니케이션 방식을 격려하고, 이는 느린 소통과 결정을 만든다.
  • 원활한 개발 경험에 대한 투자. 엔지니어들을 신경쓰는 기업은 빠르게 플랫폼 팀을 구성해 엔지니어들이 더 좋은 개발 경험을 할 수 있도록 돕는다.
  • 높은 임금, 그리고 이를 정당화하는 높은 영향력. 엔지니어들이 높은 영량력을 행사할 수 있는 회사는 무리없이 시장 최고 임금을 제시할 수 있다.
  • 채용된 인재들의 높은 퀄리티. 위 요소들의 조합 덕분에 빅테크 기업은 무리없이 좋은 인재를 채용할 수 있다.
• 권한과 자율성이 부여된 팀, 그리고 명확한 오너십이 있는 팀은 이런 기업을 만드는 중요한 구성 요소이다.
• 짚고 넘어가야 할 점은, 빅테크의 경험 있는 개발자 중 대부분은 넓은 범위의 개발 업무를 수행할 수 있고, 이러한 제너럴리스트에 대한 선호도는 채용에도 반영된다.

프로젝트 관리자가 아닌, 제품 관리자

• 빅테크와 기타 기업의 또다른 기이한 차이점은 프로덕트 관리자(Product Manager)의 역할 차이, 그리고 팀 전문 프로젝트 관리자(Project Manager)의 부재이다.
• 빅테크에서의 프로덕트 관리자는 팀의 전략을 정의하고, 어떤 과정을 통해 전략을 실행할지를 정의한다. 대부분의 상황에서 프로덕트 관리자는 프로젝트를 관리하는 업무를 맡지 않는다. 실행 단계의 책임을 지는 것은 팀과 팀 리드(일반적으로는 엔지니어)이다.
• 전문 프로젝트 관리자의 부재는 여러 질문이 들게 한다. 과연 엔지니어들이 이에 만족할까? 이에 대한 답변은 아래와 같다.
  • 팀 내의 프로젝트에서, 전문 프로젝트 관리자의 부재는 프로세스를 단순화하고 개인간의 관계를 더 친밀하게 한다.
  • 복잡한 프로젝트에서(서로 다른 사무실에 걸쳐 있는 여러 팀들간의 협업이 필요한 것), 보통은 TPM(Technical Program Managers)이 프로젝트 관리 업무를 맡아 엔지니어의 업무를 덜어준다.
  • 전문 프로젝트 관리자가 빅테크에 있긴 하다. 다만 이들은 보통 외부 소통이나 장기 계획에 집중한다. TPM이 각 엔지니어링 팀에 할당되지 않듯이, 프로젝트 매니저도 팀에 할당되지 않고 대신 여러 팀들과 함께 일하게 된다.

제품에 집중하는 문화, 그리고 스크럼 포기하기

• 스카이프는 결과적으로 스크럼을 포기했다.
• 처음에는 스카이프는 스크럼 방식으로 일했고, 2주 단위의 스프린트를 돌렸다. 또한 소프트웨어 엔지니어와 QA 엔지니어는 분리되어 있었다. 팀원들은 2주 단위의 릴리즈 주기를 더욱 가속화하고 싶었다.
• 이를 위해 처음으로 한 일은 QA를 개발 과정에 녹이는 것이였다. QA 엔지니어도 소프트웨어 개발에 참여하도록 했고, 대신 개별 엔지니어가 자신의 코드를 테스트하는 것에 대한 책임을 맡았다. 이는 개발과 검증 사이의 시간 간격을 극적으로 줄였다.
• 다만, 이 후로 스크럼이 일 단위 릴리즈의 걸림돌이 되었다. 스프린트의 시작에 어떤 일을 할지 정하고 스프린트가 끝날 때 이를 정리하는 것이 빠르게 움직이는 팀에 맞지 않았다. 이 후로 스카이프 팀은 칸반으로 전환하며 스크럼의 프로세스를 대부분 버렸다.
• 스크럼을 버리는 것에는 인프라와 개발자 도구(Infrastructure and developer tooling)가 도움이 되었다. 스크럼 방식은 프로덕트 오너가 소프트웨어 스펙을 검증하고, 그 전에는 소프트웨어가 배포되지 않는 것을 가정하지만, 이러한 가정은 스카이프의 문화에 맞지 않았다. 스카이프는 자동화 테스트를 작성하고, 피쳐 플래그로 보호된 기능을 작성하며, 기능을 점진적으로 릴리즈하였다.
  • CI/CD, 피쳐 플래그, 그리고 실험 도구는 프로덕트 오너에 의존하는 것보다 더 빠른 피드백 사이클을 가능하도록 했다.
  • 빅테크는 인프라와 개발자 도구가 엔지니어의 효율성에 큰 도움이 된다는 사실을 알고 있다. 이는 30%~40%의 개발자가 플랫폼 팀에서 일하는 이유이다. 인프라와 개발자 도구는 팀이 각자의 핵심 업무에 집중할 수 있도록 돕는다.
• 스카이프 팀의 모든 팀원은 그들이 무엇을 만드는지에 대해서 명확히 알고 있었다. 프로덕트 매니저가 높은 수준에서의 전략을 설정하면, 엔지니어가 각 프로젝트를 실행하는 역할을 맡았다. 그 과정속에서 엔지니어들은 스크럼의 불필요한 부분을 제거할 수 있는 권한이 있었고, 그 후의 프로세스는 더 이상 스크럼과 같지 않았다.

스크럼 그 너머

• 빅테크 엔지니어는 보통 스크럼을 사용해본 적이 없다. 그 이유는 아래와 같다.
  • 능력 있고 자율적인 사람은 일의 구조가 덜 필요하다. 빅테크는 이런 사람을 채용하고 임금을 지불할 수 있다.
  • 능력 있는 팀에 자유를 부여하면 자연스레 높은 영향력을 발휘한다.
• 엔지니어 조직의 규모를 키우는 것의 어려움은 팀 단위 프로세스에서 오지 않는다. 큰 엔지니어 조직이 진짜로 집중해야 하는 문제는 애초에 스크럼과 같은 무거운 프로세스를 도입하는 걸로 해결되지 않는다. 그 예시는 아래와 같다:
  • 개발자 생산성: 어떻게 하면 더 많은 시간을 비즈니스 문제와 직결된 코드를 짜게 할 수 있을까
  • 기술 부채의 상환: 어떻게 하면 적시에 적절한 정도의 기술 부채를 상환할 수 있을까
  • 조직 목표를 반영하는 팀 구조: 조직의 목표와 팀 구조 모두 주기적으로 변경된다. 어떻게 하면 팀의 혼란을 최소화하면서 팀 구조를 조직의 목표와 맞출 수 있을까
  • 창의적인 성과를 위한 여유 시간: 혁신을 만들어야 하는 팀은 여유 시간이 필요하다. 어떻게 이 여유 시간을 만들 것인가
  • 팀이 커져도 효율성을 유지하는 것: 팀이 커지면서 커뮤니케이션과 결정의 오버헤드는 더 커져간다. 어떻게 하면 전체 조직의 규모와 무관하게 각 팀이 빠르게 결정할 수 있도록 할 수 있을까?
  • 지속 가능한 뛰어남: 성과를 장기적으로 개선하면서도 엔지니어가 행복하게 할 수 있을까?

스크럼에 대한 옹호

• 빅테크가 스크럼과 같은 프로세스를 포기하는 것이 모든 기업이 그렇게 해야 한다는 것은 아니다. 아래와 같은 팀은 스크럼으로 전환하는 것이 좋은 결정이 될 수 있다:
  • “부엌 싱크대 팀(Kitchen sink teams)": 모든 것에 대한 책임을 떠맡은 싱크대 같은 팀은 이해관계자를 관리하기 위해 스크럼을 사용할 수 있다. 스크럼을 사용하면 이해관계자에게 스프린트 중간에 요구사항이 변경될 수 없다는 것을 교육시킬 수 있고, 여러 모순되는 우선순위를 가진 팀은 스프린트 도중에 더 적은 인터럽트를 만나게 된다. “부엌 싱크대 팀”은 보통 Non-테크 기업과 초기 스타트업에 더 흔하다.
  • 조직된 지 얼마 되지 않은 팀: 처음 팀이 조직되었을 때는 서로에 대해 익숙하지 않다. 이럴 때는 스크럼과 같은 잘 문서화된 기성 프로세스를 사용하는 것이 더 올바른 결정이다. 팀이 성숙해지면 자연스레 스크럼을 버리게 된다.
  • 몇 주에 한번으로 릴리즈 속도를 가속화시켜야 할 때. 대부분의 Non-테크 기업에 해당된다.
  • 기업 단위의 획일화된 프로젝트 진행 과정 보고가 필요한 팀. 대표적으로는 스카이프가 스크럼을 채택하면서, 획일화된 프로젝트 진행 과정 보고를 통해 많은 이점을 얻었다. 다만 권한이 부여된(empowered)팀에 대해서는 OKR이나 KPI가 팀간 얼라인을 맞추는 더 좋은 방법이라 생각된다.

어떻게 팀을 운영해야 할까?

• 팀을 어떻게 운영해야 할지는 개별 팀의 상황에 달려 있다. 결정에 관련된 요인은 조직 구조, 같이 일하는 사람, 그들의 자율성과 능력, 경쟁 상대, 그리고 지금이 “전시(wartime)”인지 여부 등등등... 에 달려 있다. 결정에 앞서 몇 가지 고민해볼만한 점들은 아래와 같다.
  • 점진적인 변경은 항상 한번의 큰 변경보다 낫다.
  • 물고기를 잡는 법을 가르치는 것은 물고기를 대신 잡아주는 것보다 더 힘들다.
  • 지시하기, 멘토링하기, 코칭하기는 모두 각각의 쓸모가 있다.
    • 팀이 어떻게 하는지 이미 알고 있을 때, 지시하는 것은 곧 마이크로매니징이 된다. 하지만 팀이 어떻게 해야 할지 모를 때, 지시하는 것은 팀에 도움이 된다. 장기적으로는 거의 지시하지 않아야 올바르지만, 어쩌면 지시하는 것에서 시작하는 것이 좋은 방법일지도 모른다.
  • 결정에 필요한 사람이 적을수록 더 빠른 결정을 내릴 수 있다.
    • 엔지니어가 직접 결정을 내리는 것을 장려하면 좋다.
  • 보고를 위한 최적화는 신뢰가 낮은 환경에 대한 최적화와 같다.
  • 개발 컨설턴트는 자신을 증명하기 위해 측정할 수 있는 지표를 만드는 것에 집중할 것이다.
  • 경쟁사로부터 배워야 한다.
  • 훌륭한 엔지니어는 마이크로매니징을 당할 바에는 퇴사하고 만다.