소프트웨어 플랫폼에 대해서 - 3부 (Delivery 조직)

앞에 소프트웨어 플랫폼에 대해서 1부와 2부까지 글을 쓰고 다 끝난줄 알았다. 하지만 지금 다시 글을 쓰는 이유는 요즘 다시 회사 내부에서 조직에 관한 고민과 지금 프라하에서 열리고 있는 EOSS (Embedded Open Source Summit)에서 BMW 개발자들과 이야기 한 후 생각의 정리가 필요해서 블로그를 열었다.

 

어제도 간단히 BMW의 소프트웨어 플랫폼 node0에 대해서 글을 썼다. 이번 글을 소프트웨어 플랫폼의 제목을 달았지만 현재 프로젝트 상 조직에 대한 고민이 더 커서 이에 대해 글을 써보고자 한다.

 

출처: https://www.softkraft.co/software-development-team-structure/

 

플랫폼 조직, 제품 조직, 개발 조직 등에 대해 플랫폼과 엮어 여러가지로 고민 중에 있다. 위의 그림은 개발 조직 구조 중에 하나를 검색하다가 가지고 왔다. 

현재 상황

• 제품: 인포테인먼트
• 간단한 아키텍처: 하이퍼바이저 기반에 여러 Guest OS
• 양산 계획: 현재, 다음, 그 이후

 

플랫폼이라고 하는 것에서 제품을 만들 때 가지고 가서 살을 붙여 최종 제품을 만드는 형태가 될 수 있을 것이다. 그러면 이 때 플랫폼을 어떻게 정의해야할까? BMW의 node0와 같은 경우는 리눅스 플랫폼이고 이를 가지고 여러 ECU에 적용하려고 하기 때문에 서로 다른 제품 (인포테인먼트, RSU/RSE, 컨트롤러, 텔레메틱스 등)에 모두 필요한 공통 컴포넌트를 가지고 하드웨어 의존성을 최소화 하여 개발하려고 한다.

 

하지만 지금 필자가 처한 상황은 인포테인먼트 플랫폼을 만들려고 하고 그 파생으로 현재, 다음, 그 이후 제품을 만들려고 한다. 이때 어떻게 Delivery 및 Maintanance 조직을 운영하면 좋을지 고민 중이고 여러 가지 옵션을 생각하고 있다.

조직 구조

Subsystem (Guest OS)별 Delivery 조직

Subsystem 별로 품질을 책임을 지는 조직을 만들고 그 안에 Owner, Build Engineer, Testers, Issue/Performance 분석 Engineer 등을 두는 구조를 생각해봤다. 물론 이 조직은 현재, 다음, 그 다음 프로젝트의 품질을 모두 책임을 진다.

 

이론적으로 좋아보일 수 있지만 Subsystem 간의 의존성이 있어 이를 관리하기엔 좋아보이지 않는다. 그리고 서로 다른 특징을 가진 여러 세대 제품을 동시에 관리하는 것도 모든 세대의 제품에 전문성을 가져야 하기 때문에 현실적으로 어렵다.

제품/세대 별 Delivery 조직

이 구조가 흔한 구조라고 생각한다. Mainline을 책임을 지는 Mainline(master) Delivery 팀, 각각의 세대 제품을 책임지는 제품별 Production Delivery 팀을 두는 구조이다. Mainline Delivery 팀은 각 제품팀의 테스트 품질에 대해서는 약간 관대하게 하고 개발 속도를 빠르게 한다. 물론 SOP 직전에는 품질을 좀 더 강화 시키는 기간을 가지는 것도 좋다.

 

이 때 노력해야할 점은 각 제품 PM과 Align을 정말 잘 맞춰야하고 개발자들과의 소통을 정말 잘해야한다. 예를 들어 무조건 Production에 들어가는 수정사항은 Mainline에 넣어야하는 원칙을 지켜야 한다는 것이다. 그렇지 않으면 mainline에 대해 그 누구도 신경 쓰지 않고 결국 망가질 수 있게 된다.

 

그래서 현실적으로 생각했을 때 Mainline = Platform으로 생각하고 관리를 잘 하는것이 좋지 않을까 생각한다. 그렇지 않으면 양산할 때 개발팀이 노력을 들여 가지고 가려고 하지 않기 때문이다. 대부분의 회사에서 Platform팀의 힘이 양산 팀보다 약하다. Google과 같이 Android를 꽉잡고 있고 그것을 삼성 등 가지고 가서 직접 업그레이드하고 자기 제품에 맞게 커스터마이즈를 하는 구조가 아닌 이상 같은 회사내에서는 더더욱 어렵다.

결론

정답은 없고 회사의 상황에 맞기 조직 구조를 만들어가야 하지만 많은 것을 사전에 고려해야한다. 지금 제품 세대 별 Delivery 조직을 제안하려고 생각하고 있고 이를 하는데 어떤 역할들이 필요한지, 왜 이렇게 해야하는지를 좀 더 정리해야한다.

 

제목은 소프트웨어 플랫폼이라고 적었지만 조직도에 대해서 좀 더 이야기했고 Platform = Mainline, Mainline = Platform 이라는 것만 살짝 적어봤다. 아무리 생각해도 공통으로 사용하는 것을 나누는 작업은 당연히 해야하지만 이를 플랫폼으로 정의하고, 이것만 딸랑 제품 만드는 조직에 주면 사용하지 않을 것 같아 현실적으로 어려운 것 같다.

 

다음 소프트웨어 플랫폼에 대해서 4부에서는 Delivery 조직에 어떤 역할을 가진 구성원이 있는지를 정리해보려고 한다.