<div id="readability-page-1" class="page"><div><div><h2 id="be6d">좋은 매니저로 가는 길</h2><div><a rel="noopener" href="/?source=post_page-----f9637ee30644--------------------------------"><div><p><img alt="조은, Eun Cho" src="https://miro.medium.com/fit/c/56/56/1*rWr6lzT5Ce1UGmteY0YPYw.jpeg" width="28" height="28"></p></div></a></div></div><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/3900/1*tJUTwe-NzwLDblcgipdirA@2x.jpeg" width="1950" height="1300" role="presentation"></p></div></figure><p id="509a">엔지니어링 매니저도 다른 매니지먼트와 비슷한 역할을 수행하지만, 무형의 자산을 관리한다는 측면에서 소프트웨어 엔지니어링 매니지먼트는 조금 더 어렵다고 생각한다. 무엇보다 리소스는 제한적인데 해야하는 일은 많고, 일단 사람을 많이 투입하면 일단 눈 앞의 문제는 해결되기 때문에 간과하는 포인트도 많다.</p><p id="95cd">이 글에서는 엔지니어링 매니저로 일하면서 겪었던 크고 작은 이슈들을 정리하며 내가 스스로 매니저로서 주의하는 점들에 대해서 기록한다.</p><h2 id="e56b">인간을 리소스화 시키지 않기</h2><p id="6b23">여러 사람들을 관리해야하는 입장이 되어보면 언제부터인가 인간을 리소스처럼 부리기 시작하는데, 여기서 말하는 리소스처럼 부린다는 건 개인의 피로도, 성격, 개성을 고려하지않고 단순히 MM (Man Month) 단위로만 바라본다는 것이다.</p><p id="c423">이전에도 여러번 이야기한 적 있지만<span id="rmm"><span id="rmm"> </span></span>현대의 매니지먼트는 개인에 대한 신뢰도를 높이고 그 사람이 일을 잘하게 만드는 것이 무엇보다 중요하기 때문에, 매니저가 개인에 대해서 잘 알고 있는 것이 곧 생산성을 향상시키는 데에 큰 도움을 준다.</p><p id="872e">개인의 상황을 고려하지않고 인간을 리소스화시키는 순간 그 사람의 장점은 크게 사라지는 데 비하면 단점은 크게 부각되는 경우가 많다. 이는 매니저가 직원에게 신뢰를 주지 못한 것에 대한 사이드 이펙트에 가깝다고 생각한다.</p><p id="f1ab">그러니 어떤 프로젝트가 바쁘게 지나갔다면 다음 프로젝트를 하기 전에는 조금의 여유를 주는 것도, 야근으로 사람들이 힘들어하고 있다면 조금씩 풀어주는 것도, 혹은 개인의 사정이나 문제에 대해서 같이 고민해주는 것도 매니저의 역할이다.</p><h2 id="b371">기술을 놓지않기 (전문성을 잃지 않기)</h2><p id="2ce0">트위터나 페이스북에도 몇 번 쓴 적이 있지만 엔지니어링 매니저는 기술을 잘 이해하는 데에서 시작하고, 같이 일하는 사람들에게 상징적인 인물로서 존재할 수 있어야한다 생각한다.</p><p id="c02d">주니어들에게는 ‘저 사람에게 물어보면 적어도 내가 원하는 답변이 나오겠지?’ 라는 확신을 줄 수 있어야하고 시니어들에게는 ‘같이 기술 고민을 할 수 있는 좋은 동료’ 라는 확신을 줄 수 있어야 한다. 그렇기 때문에 매니저가 되어서도 기술을 놓쳐서는 안된다.</p><p id="ac8e">다만 매니저가 되고서는 특정 도메인에 제한된 지식보다는 조금 더 폭 넓은 분야의 지식에 대해서 습득하게 된다. 성능 최적화 기법을 찾는다면, 예전에는 프런트엔드가 어떻게 해야하는 지를 중점으로 보았다면 이제는 애플리케이션 전체에서 줄일 수 있는 포인트가 어떤 것이 있는 지를 살펴본다. (당연히 프런트엔드 영역을 더 잘할 수밖에 없기는 하지만)</p><p id="1806">코드를 직접 구현하는 능력을 하드스킬이라고 부르고, 그 외의 모든 스킬을 소프트스킬이라고 부르던데 어느샌가 나는 소프트스킬과 하드스킬이 1:1이 되어간다는 느낌을 받을 때가 있다. 코드를 작성하는 행위 자체는 쉽지만, 코드를 어떻게 작성해야 좋은 코드인가에 대해 고민하는 영역은 어려운 영역이다. 그런 영역에서 조직의 시니어로서 잘 역할할 수 있는 것이 매니저의 큰 역량이리라.</p><h2 id="7059">같이 고민하기</h2><p id="d6c7">매니저가 되고 나서 무엇보다 많이 느꼈던 감정은 외로움과 고독함이다. 무엇보다 내가 결정을 내려야하는 일들에 대한 책임감은 그 무엇보다도 무거웠고, 그런 때의 결정이 여러 사람에게 영향이 미친다는 것을 알고난 이후로는 더욱 힘들어지기도 했다.</p><p id="17ea">일이 잘 풀리지 않을 때에는 더욱 그렇다. 언젠가 피터 드러커 교수님의 저서에서 보았던 내용처럼, 선의로 시작했던 일이었던 게 여러 과정을 거치면서 악의로 변질되는 경우도 겪었기에 더욱 이런 주제에 대해서는 예민함과 책임감을 가질 수밖에 없다.</p><p id="9ed2">함께 일하는 동료를 믿고 어떤 의사결정 사항에 대해서 같이 고민하는 습관은 꽤 중요한 습관이라고 생각한다. 의사 결정이 필요한 사안에 대해서 공유하고, 내 생각은 어떠한 지에 대해서 함께 이야기를 나눈 후에 최적의 솔루션을 함께 찾아나가는 것은 동료들이 나에 대한 신뢰를 가질 때, 또 반대로 내가 동료들에 대한 신뢰를 가지고 있을 때 가능한 일이라 생각한다.</p><p id="b8be">대부분의 조직에서 매니저가 상위 직급자고 경험이 많은 사람이겠지만, 매니저도 지속하여 고민하고 가장 옳은 방향을 도출하는 데에 많은 시간을 쓴다. 다르게 이야기하자면 매니저들이 하는 고민과 IC (Indivisual Contributor)가 하는 고민은 그 형태가 다를 수는 있어도 비슷한 고민에 놓일 때가 있다는 것이다.</p><p id="97df">그래서 나는 더 많이 서로의 고민을 이야기하고, 같이 논의해나가는 과정이 엔지니어링 팀에서, 더 나아가 조직 내에서 자연스럽게 이루어져야한다고 생각한다. 우아한형제들에서 배웠던 것 중 가장 소중한 경험은 “잡담하는 문화” 였다. 일단 사소한 이야기라도 서로 이야기하는 문화가 생기고서는, 내가 가지고 있는 고민을 자연스럽게 털어놓을 수 있는 문화가 생겼다고 생각하기 때문이다.</p><h2 id="554b">마무리</h2><p id="e337">매니지먼트 문화도 바뀌어야한다고 생각한다. 직원을 단순히 부하로 바라보던 매니지먼트 방식은 이미 끝났고, 함께 일하는 동료로서 어떻게 일을 해야 가장 시너지가 날 지에 대해서 고민하는 게 현대 매니지먼트에서 무엇보다 중요한 일이라 생각한다.</p><p id="b6e4">매니저로서 고민하는 지점이 많지만, 그래도 다른 사람에게 도움이 조금이라도 될까 하여 글을 작성한다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

좋은 매니저로 가는 길
엔지니어링 매니저도 다른 매니지먼트와 비슷한 역할을 수행하지만, 무형의 자산을 관리한다는 측면에서 소프트웨어 엔지니어링 매니지먼트는 조금 더 어렵다고 생각한다. 무엇보다 리소스는 제한적인데 해야하는 일은 많고, 일단 사람을 많이 투입하면 일단 눈 앞의 문제는 해결되기 때문에 간과하는 포인트도 많다.
이 글에서는 엔지니어링 매니저로 일하면서 겪었던 크고 작은 이슈들을 정리하며 내가 스스로 매니저로서 주의하는 점들에 대해서 기록한다.
인간을 리소스화 시키지 않기
여러 사람들을 관리해야하는 입장이 되어보면 언제부터인가 인간을 리소스처럼 부리기 시작하는데, 여기서 말하는 리소스처럼 부린다는 건 개인의 피로도, 성격, 개성을 고려하지않고 단순히 MM (Man Month) 단위로만 바라본다는 것이다.
이전에도 여러번 이야기한 적 있지만 현대의 매니지먼트는 개인에 대한 신뢰도를 높이고 그 사람이 일을 잘하게 만드는 것이 무엇보다 중요하기 때문에, 매니저가 개인에 대해서 잘 알고 있는 것이 곧 생산성을 향상시키는 데에 큰 도움을 준다.
개인의 상황을 고려하지않고 인간을 리소스화시키는 순간 그 사람의 장점은 크게 사라지는 데 비하면 단점은 크게 부각되는 경우가 많다. 이는 매니저가 직원에게 신뢰를 주지 못한 것에 대한 사이드 이펙트에 가깝다고 생각한다.
그러니 어떤 프로젝트가 바쁘게 지나갔다면 다음 프로젝트를 하기 전에는 조금의 여유를 주는 것도, 야근으로 사람들이 힘들어하고 있다면 조금씩 풀어주는 것도, 혹은 개인의 사정이나 문제에 대해서 같이 고민해주는 것도 매니저의 역할이다.
기술을 놓지않기 (전문성을 잃지 않기)
트위터나 페이스북에도 몇 번 쓴 적이 있지만 엔지니어링 매니저는 기술을 잘 이해하는 데에서 시작하고, 같이 일하는 사람들에게 상징적인 인물로서 존재할 수 있어야한다 생각한다.
주니어들에게는 ‘저 사람에게 물어보면 적어도 내가 원하는 답변이 나오겠지?’ 라는 확신을 줄 수 있어야하고 시니어들에게는 ‘같이 기술 고민을 할 수 있는 좋은 동료’ 라는 확신을 줄 수 있어야 한다. 그렇기 때문에 매니저가 되어서도 기술을 놓쳐서는 안된다.
다만 매니저가 되고서는 특정 도메인에 제한된 지식보다는 조금 더 폭 넓은 분야의 지식에 대해서 습득하게 된다. 성능 최적화 기법을 찾는다면, 예전에는 프런트엔드가 어떻게 해야하는 지를 중점으로 보았다면 이제는 애플리케이션 전체에서 줄일 수 있는 포인트가 어떤 것이 있는 지를 살펴본다. (당연히 프런트엔드 영역을 더 잘할 수밖에 없기는 하지만)
코드를 직접 구현하는 능력을 하드스킬이라고 부르고, 그 외의 모든 스킬을 소프트스킬이라고 부르던데 어느샌가 나는 소프트스킬과 하드스킬이 1:1이 되어간다는 느낌을 받을 때가 있다. 코드를 작성하는 행위 자체는 쉽지만, 코드를 어떻게 작성해야 좋은 코드인가에 대해 고민하는 영역은 어려운 영역이다. 그런 영역에서 조직의 시니어로서 잘 역할할 수 있는 것이 매니저의 큰 역량이리라.
같이 고민하기
매니저가 되고 나서 무엇보다 많이 느꼈던 감정은 외로움과 고독함이다. 무엇보다 내가 결정을 내려야하는 일들에 대한 책임감은 그 무엇보다도 무거웠고, 그런 때의 결정이 여러 사람에게 영향이 미친다는 것을 알고난 이후로는 더욱 힘들어지기도 했다.
일이 잘 풀리지 않을 때에는 더욱 그렇다. 언젠가 피터 드러커 교수님의 저서에서 보았던 내용처럼, 선의로 시작했던 일이었던 게 여러 과정을 거치면서 악의로 변질되는 경우도 겪었기에 더욱 이런 주제에 대해서는 예민함과 책임감을 가질 수밖에 없다.
함께 일하는 동료를 믿고 어떤 의사결정 사항에 대해서 같이 고민하는 습관은 꽤 중요한 습관이라고 생각한다. 의사 결정이 필요한 사안에 대해서 공유하고, 내 생각은 어떠한 지에 대해서 함께 이야기를 나눈 후에 최적의 솔루션을 함께 찾아나가는 것은 동료들이 나에 대한 신뢰를 가질 때, 또 반대로 내가 동료들에 대한 신뢰를 가지고 있을 때 가능한 일이라 생각한다.
대부분의 조직에서 매니저가 상위 직급자고 경험이 많은 사람이겠지만, 매니저도 지속하여 고민하고 가장 옳은 방향을 도출하는 데에 많은 시간을 쓴다. 다르게 이야기하자면 매니저들이 하는 고민과 IC (Indivisual Contributor)가 하는 고민은 그 형태가 다를 수는 있어도 비슷한 고민에 놓일 때가 있다는 것이다.
그래서 나는 더 많이 서로의 고민을 이야기하고, 같이 논의해나가는 과정이 엔지니어링 팀에서, 더 나아가 조직 내에서 자연스럽게 이루어져야한다고 생각한다. 우아한형제들에서 배웠던 것 중 가장 소중한 경험은 “잡담하는 문화” 였다. 일단 사소한 이야기라도 서로 이야기하는 문화가 생기고서는, 내가 가지고 있는 고민을 자연스럽게 털어놓을 수 있는 문화가 생겼다고 생각하기 때문이다.
마무리
매니지먼트 문화도 바뀌어야한다고 생각한다. 직원을 단순히 부하로 바라보던 매니지먼트 방식은 이미 끝났고, 함께 일하는 동료로서 어떻게 일을 해야 가장 시너지가 날 지에 대해서 고민하는 게 현대 매니지먼트에서 무엇보다 중요한 일이라 생각한다.
매니저로서 고민하는 지점이 많지만, 그래도 다른 사람에게 도움이 조금이라도 될까 하여 글을 작성한다.

Engineering manager

댓글