팀 내에서 팀장의 역할 (feat. YARN 하둡분산자원관리)

예전에 포프TV [1]를 보다가 팀장의 역할을 CPU Core를 관리하는 것(영상 찾기 실패ㅜ)과 비유한 것을 본적이 있습니다.

 

비슷한 관점으로 최근 빅데이터의 자원관리 도구인 YARN에 대해서 정리하다가, YARN의 리소스매니저도 팀장에 비유가 가능하다는 생각이 들었습니다. 또한, 매니징과 관련해 예전에 '실질적이다라는 느낌을 받으며' 읽은 책 "The Making of a Manager"[2]의 다양한 조언들도 그러한 관점으로 잘 정리될 것 같아 이 글을 작성하게 되었습니다.

 

Image from Amazon

이번 글에서는 위의 관점으로(팀장 역할을 해본적은 없지만), 미래의 팀장을 준비한다는 생각으로 팀장의 역할에 대해 기술해보겠습니다.

 

• 팀을 YARN에 비유해보기
• 팀장은 팀이라는 클러스터의 리소스매니저

 

---

팀을 YARN에 비유해보기

YARN은 빅데이터 하둡환경에서 작업을 분산되어 있는 여러 노드에서 실행되도록 도와주는 도구입니다. 먼저, Job에 해당되는 application이 리소스매니저에 제출됩니다. 그 애플리케이션은 앱 당 하나 존재하는 애플리케이션마스터라는 컴포넌트에 의해 여러 노드에서 컨테이너 형태로 처리되게 됩니다. 각 노드에 하나씩 존재하는 노드매니저는 노드의 자원을 관리하고 리소스매니저에게 보고하며 컨테이너를 생성관리하여 애플리케이션마스터가 컨테이너를 사용할 수 있게 합니다. 

 

팀장 역시도 분산된 팀원들의 관리를 담당합니다. YARN과 다른 점이 있으니, 현실에서의 외부 요청은 항상 팀장을 통하는 것은 아닙니다만 (대부분) 팀장의 허가와 팀원 할당에 의해 진행됩니다(또한, 그러한 방식이 바람직하다고 생각합니다).  요청된 업무에 대해 팀장은, (비공식적 용어인) 마도(업무를 주도적으로 책임지고 진행하는 사람) 역할과 함께 업무를 진행할 팀원을 할당(assign)합니다. 그렇게 업무는 마도의 책임하에 여러 팀원이 처리하게 됩니다. 팀장은 팀원 각 개인과 끊임없이 소통하며 얼라인(align) 되어야 합니다.

 

그리고, YARN과  팀이 공유하는 핵심적인 철학은 '여럿이 함께 일할 때 더 좋은 결과물이 나온다'는 점입니다. 그렇기에, 팀장의 핵심적인 역할은 '여럿이서 일하여 더 좋은 결과물을 얻도록' 하는 것입니다.

 

Your job, as a manger, is to get better outcomes from a group of people working together. [2]

Image from Author

 

위 그림에서 팀과 비유되는 YARN의 요소(괄호 안)를 구조화해보았습니다. 실제로 팀은 조금 더 '명시화, 구체화'되고, YARN의 요소는 좀 더 추상화된다면 둘 간의 비유가 잘 어울릴 수 있을 듯 합니다.

 

 

팀장은 팀이라는 클러스터의 리소스매니저

팀장은 위에서 보듯이 팀 내에서 2가지 주요한 역할을 담당합니다. 얼라인먼트와 업무관리가 바로 그 2가지입니다.

 

먼저 , 얼라인먼트는 끊임없이 그리고 주기적으로 진행되어야 하며 [2]에서 말하는 아래의 purpose, people, process 3가지 주요 부분에서 필요하다고 생각됩니다:

 

• purpose: 팀은 어떤 것이 팀의 성공인지 잘 알고 있어야 하며 그것에 마음을 쓰고 이해하고 있어야 합니다. '이해'는 왜(Why)를 알고 있는 것에 해당됩니다. (개발자 사이에서) 왜 다양한 언어를 사용하는 대신 한 가지 언어를 고수하는지, 왜 시스템을 확장하기보다 좀 더 단순하게 정리하는 부분에 집중하는지, 왜 데이터를 삭제하여 연간 비용을 몇 천만원 줄이는 대신 데이터를 계속 보존하는지 알고 있어야 conflict과 mismatch를 피할 수 있습니다.

 

• people: 팀원 각 개인이 성공을 위해 준비되었는지, 적절한 스킬을 가지고 있는지, 그러한 일을 하기 위한 motive가 있는지 '사람'으로 잘 알고 있어야 합니다. 그 근본에는 '신뢰(Trust)'가 바탕이 되어야 하며, 그 신뢰를 바탕으로 팀원에게 (뒤에서 다시 언급될) 업무 또는 역할에 대한 진심어린 피드백을 주고, 반대로 받을 수 있어야 합니다.

 

• process: 어떻게 '팀'으로 일하는지 알고 그것이 잘 공유되어야 합니다. 프로세스가 없는 상황은, 누구든지 아무런 제약없이 장벽없이 오버헤드 없이 가장 '빠르게' 목적을 달성하기 위해서만 일하도록 부추기는 것입니다. 그것은 '혼자'일하는 것이지 '팀'으로 일하는 것이 아닙니다. '팀'은 여럿이서 일하여 더 좋은 결과를 만드는 것입니다. 그렇기에 전자와 같이 일하는 것은 팀이 없는 것과 마찬가지라고 할 수 있습니다.

 

두 번째로 '업무관리'는 '좋은 피드백'과 '피드백을 잘하고 있는지 돌아보기' 2가지로 구성됩니다 [2](The Art of Feedback).

 

좋은 피드백은 아래와 같은 특성을 지닙니다:

 

• 일을 시작하기 전의 명확한 기대치 설정하기: 피드백 프로세스는 일이 진행되기 전에 시작합니다. 팀원과 팀장 모두 '성공이 어떠한 모습인지'에 대해 같은 모습을 가지고 동의하고 있어야 합니다. 그것을 바탕으로 생산적인 피드백이 가능하기 때문입니다.

 

• Task-Specific한 피드백을 가능한 자주 전달하기: task-specific한 피드백은 업무가 진행되고 있을 때 매우 효과적이며, 전달하기에도 어렵지 않은 형태의 피드백입니다. 이메일, 채팅, 대면 등 모든 형태로 가능합니다.

 

• (현재 관점으로는 첫 번째 파트에 포함될) 행동에 대한 피드백은 심사숙고해서 정기적으로 전달하기: 팀원이 결정을 천천히하는지 너무 빨리하는지, 팀원이 너무 단기적인 또는 장기적인 문제에만 골몰하는지와 같은 사항들은 어떤 컨택스트에서 이해했는지, 그 예시는 어떠한지 등 personal한 부분이 포함됩니다. 짧은 시간 안에 담기도 어렵고 팀원을 사람으로 깊이 이해해야할 필요성도 있기에 형식과 시간을 두고 전달하는 것이 좋습니다.

 

• 객관성을 위해 360도 피드백을 전달하기: 팀에 소속된 모든 인원 서로에게 진실하고 사려깊은 '피드백 문화'가 존재하여야 합니다.

 

피드백은 언제나 더 낳은 결과를 위한 피드백이 되어야 합니다. 그렇기에 항상 피드백을 되돌아보며 자문할 수 있어야 합니다:

 

• 피드백을 충분히 주고 있는지
• 피드백의 의미가 제대로, 그리고 충분히 전달되고 있는지
• 피드백이 긍정적인 액션을 이끌고 있는지

 

위 3가지를 중심으로 체크하여야 합니다.

 

 

 

Reference

[1] www.youtube.com/c/PopeTV/videos

[2] The Making of a Manager: What to Do When Everyone Looks to You

[3] joulee.medium.com/