Engineering Lead, Architect, Product Owner 에 대한 견해

회사에서 SCRUM 형태로 팀을 운영을 하고 있다. 일반적으로 하나의 SCRUM 팀에 1명의 Product Owner (PO)가 있고 Scrum Master (SM)은 여러 팀이 공유를 한다. DR (Development Representative)도 각 SCRUM 팀마다 한명이 있다. People 관리를 하는 Engineering Lead (EL)도 여러개의 스크럼을 가지고 있고 Architect는 System Architect (SA) 팀이 따로 있고, 여러개의 SCRUM 팀이 묶인 Domain 개념이 있는데 이 Domain에 속한 Architect 즉, Domain Architect (DA)도 있다.

 

간단하게 그림으로 표현하면 위와 비슷한 구조이다. 가끔 역할이 애매할 때가 있어 이번 기회에 개인적으로 생각하는 각자의 역할에 대해 정리해 보려고 한다.

EL (Engineering Lead)

하나의 조직을 가진 팀장이고 모든 팀원들을 관리한다. 팀원의 급여 및 성과를 결정하고 승인하며 장기적으로 하고자하는 미래에 대한 고민도 같이 한다. 즉 사람을 관리하는 People Manager이다. 가끔 위로 이슈를 받아오고 올리기도 해서 PO와 역할이 겹치기도 한다. 한국 조직에서는 많이 push를 하지만 일하고 있는 독일에서는 급하지 않을 때는 많이 쪼지는 않는다. PO가 대부분의 우선순위를 관리한다. 보통 PO 다음 단계가 EL인 경우가 많다. EL 위로는 Senior EL -> Head 로 간다.

PO (Product Owner) 

각 SCRUM 팀의 업무 리스트와 우선순위를 관리한다. 외부 다른팀과의 협업, PM들과의 업무 조율을 하여 팀에 업무 리스트를 가지고 와서 관리를 한다. 관리자 경로로 가는 친구들이 PO를 하고 의사소통 능력, 우선순위 관리, 업무에 대한 이해도가 필요하다.

DR (Developer Representative)

각 SCRUM 팀의 Technical Lead로 활동을 하고 팀을 대표해 다른 팀과의 기술적인 미팅 및 의사결정을 하는데 참여를 한다. 팀의 중장기적인 방향성을 EL, PO와 함께 결정하고 보통 이슈를 받아 우선적으로 분석하여 팀의 업무인지 확인하기도 한다.

DA (Domain Architect)

각 SCRUM팀 마다 있는 것은 아니고 여러개의 SCRUM 팀의 아키텍트 대표가 된다. 항상 아키텍트에 대해서 생각하지만 신뢰가 없으면 일하기 정말 어려운 직책이다. 본인 각자가 개발팀에 신뢰를 얻어야 하고 그래야 의사 결정한 내용이 실제 개발에 반영이 된다. 그렇지 않고 단지 타이틀로만 일하게 되면 무시당하기 정말 쉬운 직책이다. 안타깝지만 여러 회사에서 많이들 봐왔다.

정리

현재 팀의 DR로 일을 하고 있고 일부 아키텍트 업무까지 회사에서 병행하면서 일을 하고 있다. 당연한 것이지만 조직이 크기 때문에 담당자가 없는 부분도 많이 있어 메꾸려고 노력을 하고 있다. 그러면서 팀에 어떻게 해야지 영향력을 주고 올바르게 끌고 갈 수 있을지도 고민이다. 그리고 많은 부분에서 EL, PO등의 역할과 겹치고, 가능하면 서로 평화롭게 일을 하고 싶은데 그들이 어떻게 생각하는지도 궁금해 자주 미팅을 하고 있다. 결국은 모든 일들은 사람들과의 관계라서 EL, PO, SM, 개발자들과 항상 오픈하여 이야기를 하는 것이 중요하다.