소프트웨어 플랫폼에 대해서 - 5부 (Subsystem Delivery 조직 구성)

이전 글에서는 Delivery Team 에 대한 다양한 구성 방법에 대해서 이야기했다. 이 글에서는 실제로 회사에서 진행하려는 Subsystem Delivery 조직 구성에 대해서 조금 더 이야기해보고자 한다. 이렇게 글로 쓰면 생각이 좀 더 정리되어 조직을 구성하는데 쉬울 것 같아서 블로그를 열었다. 다음 그림은 완전히 일치하지는 않지만 곧 출시할 벤츠 E Class의 인포테인먼트 구조와 비슷하다.

 

출처: https://tenxos.com/qnx-hypervisor-and-guest-oses-bring-up/

용어 설명

• Sub System: 각각의 Guest OS, 즉 QNX, Linux, Android, RTOS 가 각각의 Sub System 이다.
• System: 모든 Sub System을 통합

조직 구성

각각의 Sub System 별로 Delivery 팀을 구성할 예정이고, 전체를 통합하여 릴리스하는 System Delivery Team도 따로 있다.현재는 하나의 큰 System Delivery Team이 있어서 통합하기 전에 Pre-integration Test를 실제 차에서 진행을 하고 있는데 너무 시스템이 커서 Sub System 단위의 테스트를 진행하여 빠른 통합과 함께 품질을 보장하고자 하는것이 Sub System Delivery Team의 주 목적이다.

 

• Sub System Owner: 각 Sub System의 통합 및 품질을 담당
• Integration Lead: Sub System Owner을 도와 Pre-integration 및 통합에 대한 계획을 수립하고 실행
• Defect Manager: Pre-integration 및 통합 후 문제가 발생하였을 경우 문제 관리
• Pre-integration Tester: 통합 전 Review가 된 변경사항을 묶어서 실차 테스트 진행
• Build Engineer: Pre integration 이미지 생성 및 최종 통합 담당.
• Performance/Issue Engineer: Pre integration 및 통합 후 문제가 발생했을 경우 실제 문제를 최초로 분석하여 관련팀에 전달
• Reviewer Team: 통합을 요청한 MR (Merge Request)에 대한 리뷰를 담당
• CI/CD Team: CI/CD Pipeline 및 Infra 관리

 

모두 한 팀에 있는 것은 아니고 Reviewer Team, CI/CD Team 같은 경우 여러 팀을 지원하기 때문에 별도로 있고 Sub System Delivery Team을 지원한다. Sub System Delivery 팀도 Virtual로 둘지, 실제로 하나의 팀으로 둘지는 실제 인원 구성이 현재 기준으로 서로 다른 팀에 있기 때문에 여전히 고민중에 있다.

 

이전 글에서도 이야기했지만 테스트 커버리지, 품질 관리 수준, 의존성 문제 해결 등 팀 구성 이후에 System Delivery Team과 다른 Sub System Delivery Team 과의 조율이 필요하다. 예를 들어, 각 Sub System 간 의존성이 있는 수정사항은 System Delivery Team에서 테스트하여 결과를 전달해야 한다던지와 같은 것들을 말이다.

 

고민하고 생각해야할 것은 많지만 이것들을 다 풀고 가기에는 한도 끝도 없을 것 같고, 어느정도 선에서 타협을 봐야할 것 같다. 여름이 지나 올 가을 쯤 시작할 수 있지 않을까? 라는 개인적인 생각이다. 물론 이 팀에 대해 비관적인 시각을 가진 매니지먼트들도 있다. 개인적인 입장은 솔직히 반반이지만 일단 회사 차원에서 진행하고 있으니 잘 만들어봐야겠다.