로그인

회원가입 | ID/PW 찾기

취재

[NDC 16] 좋은 개발자와 좋은 팀장의 차이점은? 훌륭한 개발팀장이 되는 법

NDC 2016 '소프트웨어 디벨로프먼트 매니저' 강연 정리

김승현(다미롱) 2016-04-26 22:11:44
다미롱 (김승현 기자) [쪽지]
/webzine/gallery/nboard/4/?n=61811 주소복사

[NDC 16] 좋은 개발자와 좋은 팀장의 차이점은? 훌륭한 개발팀장이 되는 법

NDC 2016 '소프트웨어 디벨로프먼트 매니저' 강연 정리

회사에서 평생 개발자로 일할 수 있을까? 내가 개발을 좋아해도, 내 실력이 뛰어나도 쉽지 않은 일이다. 회사는 좋은 개발자에게, 혹은 경력 있는 개발자에게 '관리자' 역할을 맡기니까. 개발자에게 관리자란, 회사 생활을 하는 이상 숙명과 같이 다가온다.

 

하지만 좋은 개발자, 아니 좋은 직원과 좋은 관리자 사이에는 하늘과 땅만큼의 차이가 있다. 좋은 관리자는 단순히 개발만 잘해서는 될 수 없기 때문이다. 과연 일선 개발자와 관리자는 뭐가 다른 것일까? 

 

좋은 관리자가 되기 위해선 어떤 것을 알아야할까? NDC 16에서 발표된 '소프트웨어 디벨로프먼트 매니저' 강연을 정리했다. 실제로 한글과 컴퓨터, 블리자드, 넥슨 등을 거치며 개발자에서 관리자가 된 넥슨 '박종천' 부본부장의 이야기를 들어보자. /디스이즈게임 김승현 기자


 

박종천 넥슨 플랫폼본부 부본부장

 

좋은 관리자가 되기 위해선 먼저 관리자가 하는 일부터 알아야 한다. 일반적으로 관리자란 오너와 일선 직원들 사이에서 프로젝트 일정과 개발, 인력 등을 관리하는 사람을 일컫는다. 

 

관리자의 임무는 크게 3가지로 나눌 수 있다. 하나는 오너나 클라이언트와 상대하며 '생산일정'을 관리하는 일, 다른 하나는 개발 '과정'을 관리해 결과물의 질을 올리는 일, 마지막은 팀원들을 행복하게 하게 성장하게 하는 일이다.

 

한 사람이 이 세 영역을 모두 커버한다는 것은 매우 힘든 일이다. 실제로 적지 않은 관리자들은 이 중 일부를 다른 이에게 부탁하기도 한다. 하지만 이와 별개로, 각 영역에 대한 경험이 쌓일수록 관리자는 더 많은 것을 보게 되고 더 많은 것을 이룩하게 된다.

 

 

■ 버릴 것은 버려라! 프로젝트를 잘 관리하는 법

 

일선 개발자에서 관리자가 돼 느끼는 가장 큰 차이는 '내가 프로젝트 자체를 관리'한다는 것이다. 일선에 있을 때는 나 자신에 대한 고민만 하면 된다. 시키는 것만 잘, 빨리하면 좋은 직원이다. 

 

하지만 관리자는 다르다. 오너나 클라이언트와 만나 상대가 원하는 것을 캐치해야 하고, 그러면서도 팀의 상황에 맞게 얼토당토 않은 요구를 설득하기도 해야 한다. 그리고 이 모든 것이 끝나면 인력을 어떻게 부리고 어떻게 활용해 결과물을 만들어야 하는지 고민해야 한다.

 

설명만 보면 쉬워 보이지만, 결코 쉽지 않은 일이다. 오히려 수많은 회사들이 이것을 못해 반쪽 짜리 게임을 내 자멸해가고 있는 실정이다. 게임사가 망하는 것은 게임을 못 만들어서가 아니다. 관리자가 자원을 효율적으로 쓰지 못했기 때문이다.

 


 

어떤 회사든 원대한 기획을 한다. 하지만 현실은 모든 것이 모자라다. 꿈을 현실로 만들기엔 시간도 모자라고 인력도 부족하다. 때문에 관리자가 하는 가장 많은 일은 필요한 것에 집중하고 불필요한 것은 잘라내는 것이다. 이 과정이 잘 진행된다면 단점은 있더라도 사랑 받는 게임이 나오고, 이 과정이 안되면 반푼이 같은 게임이 나와 시장에서 버림받는다.

 

그렇다면 적은 시간, 적은 인력으로 효과를 내려면 어떻게 해야 할까? 먼저 '낭비'를 줄여야 한다. 불명확한 소통, 팀원 간의 불화, 취소된 스케줄, 잦은 회의 등등 우리는 생각보다 많은 곳에서 시간을 낭비한다. 어떤 식으로든 낭비가 없는 조직은 없다. 때문에 관리자가 낭비 요인을 하나라도 제대로 잡는다면 많은 리소스를 확보할 수 있다.

 


 

일례로 박 부본부장이 <하스스톤> 팀에 있을 무렵, 그의 팀은 의사소통 과정을 단순화하는데 총력을 다했다. 전체회의는 1주일에 2회로 제한했고, 팀원 간 의사소통도 메일 한 번 쓸 시간에 직접 찾아가 대화하는 방식으로 바꿨다. 그 결과, <하스스톤>은 블리자드 게임 중에서는 유례없을 정도로 빠르게 개발을 끝낼 수 있었다.

 

다음은 '집중'이다. 흔히들 세상 모든 일은 급한 일과 그렇지 않은 일, 그리고 중요한 일과 중요하지 않은 일로 나눠진다고 한다. 여기서 관리자가 해야 할 일은 다른 일은 모두 무시하고, 급하고 중요한 일과 급하지 않더라도 중요한 일을 꼽아 지시하는 것이다.

 

여기서 특히 신경 써야 할 것은 '급하진 않아도 중요한 일'이다. 급한 일은 누구나 그 중요성을 안다. 설사 중요하지 않지만 급한 일이라도, 많은 사람들은 오로지 '급하다는' 이유 하나만으로 이걸 먼저 처리할 정도다. 

 

하지만 '중요하지만 급하지 않은 일'은 다르다. 급한 일들을 먼저 처리하다 보니 '중요하지만 급하지 않은 일'은 하염없이 처리가 늦어지게 된다. 그리고 정신을 차렸을 때는, 이미 해결할 수 없을 정도로 '급하고 중요한 일'이 되어있는 경우가 부지기수다. 따라서 리더는 프로젝트 내내 어떤 일이 중요한지를 체크해야 한다.

 


 

 

■ 프로토타이핑은 필수! 개발을 잘 하는 법

 

프로젝트 관리가 시간, 일정에 대한 관리였다면, 개발 관리는 제품의 품질을 관리하는 일이다. 

 

개발 관리에서 중요한 것은 '결정'이다. 특히 '기술'을 잘 결정하는 것이 가장 중요하다. 의외로 제품의 질이 나쁜 것은 생각보다 심각하지 않다. 제품이야 다시 뜯어 고치면 되기 때문이다.

 

하지만 제품의 기반 기술, 즉 언어를 잘못했다면 문제가 심각해진다. 언어를 바꾸는 것은 사실상 불가능하다. 그렇다고 어울리지 않는 언어로 억지로 개발을 이어가면 효율도 떨어지고 결과물도 신통치 않다.

 

때문에 개발 관리는 잦은 프로토타이핑이 필수다. 아무리 허접 해도, 일단 구동되는 시제품만 있다면 이 방향이 옳은지 그른지, 옳다면 어떤 식으로 개선할 수 있는지 알 수 있기 때문이다.

 


 

이렇게 결정이 중요하기 때문에, 개발을 관리할 때는 어떤 식으로든 '미지의 영역'에 익숙해지는 것이 좋다. 사실 이 말은 모순이다. 하지만 개발은 그럴 필요가 있다. 언제 어떻게 오너, 클라이언트가 모르는 영역, 모르는 플랫폼에 대한 일을 시킬 지 모르기 때문이다. 그렇기에 개발 관리는 어떤 일이 들어와도 그에 대한 최소한의 판단 기준은 가지고 있어야 한다. 

 

개발자 출신 관리자가 주의해야 할 것이 있다면, 이제 자신은 자기 업무의 질이 아니라 팀 전체 생산물의 질을 관리해야 한다는 것이다. 때문에 어떤 때는 이를 위해 자신만의 미덕을 포기하기도 해야 하고, 어떤 때는 과정의 효율 대신 결과의 효율을 추구하기도 해야 한다.

 

팀 결과물의 질이 중요하기 때문에 개발 환경을 체크하는 것도 중요한 업무다. 인터넷을 검색해 '조엘 테스트'(The Joel Test) 같은 것으로 팀을 체크해도 개발 환경을 굉장히 많이 개선할 수 있다. 참고로 조엘 테스트를 해 9개 이상 해당하면 그 조직은 좋은 개발 환경을 가지고 있다고 봐도 무방하다.

 

 

■ 좋은 팀장이란 팀원을 키우는 팀장이다, 사람을 잘 관리하는 법 

 

관리자의 마지막 역할은 '사람 관리'다. 사람 관리란 채용부터 인사, 이후 팀원 관리 모두를 포함하는 개념이다.

 

먼저 채용이나 인사 시 중요한 것은 최대한 다양한 유형의 사람을 뽑으라는 것이다. 사람들은 기본적으로 자신과 다른 유형의 사람을 꺼려한다. 하지만 사람은 다른 유형의 사람과 만나야만 시너지를 만들 수 있고, 자신의 강점과 약점도 알 수 있다. 건강한 조직을 위해선 다양한 유형의 사람이 필수다. 

 


 

이런 이들을 채용한 뒤도 중요하다. 사람은 매우 까다로운 자원이다. 수시로 만나 이야기를 나누지 않으면 그가 일에 대해 어떻게 생각하는지, 그의 삶은 어떤지, 그가 발전은 하고 있는지 알 수 없다. 그리고 이 사소한 것들 하나하나가 바로 업무 효율에 직결된다.

 

때문에 박 부본부장은 2개월에 한 번은 사람들과 1:1 면담을 가지라고 조언한다. 여기서 중요한 것은 '물음'이다. 회사 다니는 것은 즐거운지, 그동안 자신이 한 일을 어떻게 평가하는지, 자신의 어떤 점이 좋고 어떤 점이 나쁜지, 앞으로 어떤 사람이 되고 싶은지 등등. 어떤 때는 아예 세부적으로 카테고리까지 짜 물음을 던지고 스스로에 대한 평가를 들어야 한다.

 

그리고 이렇게 얻은 정보들은 팀원들을 성장시키는 밑천이 된다. 고민이 많은 팀원에게 자신의 경험을 얘기해 줄 수도 있고, 커뮤니케이션 쪽에 향상심을 가지고 있는 이라면 스스로 교육 목표를 세우게 해 면담 때마다 확인해 줄 수도 있다. 그리고 이렇게 키우고 보듬은 팀원들은 그대로 팀의 역량이 된다.

 


 

이렇게 팀원들을 보듬고 성장시킬 때 명심해야 할 것이 하나 있다. 바로 사람은 한계를 넘어서야만 발전한다는 것이다. 마치 근육이 찢어져야 발달할 수 있듯이, 사람 또한 자신의 역량 한계를 넘어서야만 발전할 수 있다. 

 

물론 그것이 무모한 도전을 권하라는 의미는 아니다. 프로젝트의 실패는 곧 회사의 실패니까.  오히려 여기서 관리자가 신경 써야 할 것은, 팀 프로세스 딴에서 팀원들에게 꾸준히 도전의 기회를 주는 것이다. 자잘한 도전, 자잘한 실패가 쌓일수록 팀원들의 역량은 상승한다. 물론 이 자잘한 실패란 프로세스가 감당할 수 있는 실패를 말한다.

 

성장의 뒤는 행복이다. 행복하지 않는 사람은 자신에게도, 주위 사람에게도 악영향을 끼친다. 때문에 관리자는 누구보다도 더 팀원들의 행복에 민감해야 한다. 팀원들에게 일은 즐거운지, 일하며 성장하고 보람은 느끼는지, 이 일을 통해 어떤 그림을 그리고 있는지를 꾸준히 물어야 한다.

 

종합하면 관리자란 프로세스 일정, 제품의 질, 팀원 관리 모두를 해야 하는 사람이다. 물론 이 셋을 다 잘하기는 힘들다. 하지만 이와 별개로, 세 영역 중 하나라도 부족하면 바로 팀의, 관리의 균형이 깨지게 된다. 때문에 박 부본부장은 청중에게 만약 일부 영역을 다른 이에게 맡기더라도, 주기적으로 담당 영역을 바꿔 세 분야에 대한 경험을 골고루 쌓으라고 조언했다.

 

 

최신목록 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10