<div id="readability-page-1" class="page"><div><p><h2 id="f8c7">저도 시니어는 처음이라</h2></p><p><h2 id="ef04">시니어 엔지니어는 무슨 일을 해야하나요?</h2></p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*g33yt0Zr9nQViz2lFLtsOQ.jpeg" width="700" height="855" role="presentation"></p></div><figcaption>Photo by <a href="https://unsplash.com/@helloimnik?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener ugc nofollow" target="_blank">Hello I’m Nik</a> on <a href="https://unsplash.com/s/photos/expert?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText" rel="noopener ugc nofollow" target="_blank">Unsplash</a></figcaption></figure><p id="5887">조직에서나 사회에서나 시니어라는 직급을 달고 일한 지도 이제 3 ~ 5년정도 시간이 지난 거 같은데 여전히 시니어 엔지니어가 조직에서 무슨 역할을 해야하는가에 대해서는 회사에 따라서도, 상황에 따라서도 다른 듯 하다.</p><p id="902f">무엇보다 시니어에 대한 기준조차도 회사별로 너무 천차만별이고, 또 다양하게 이루어지다보니 절대적인 기준을 세우기는 조금 어려운 듯 하기도 하다. 그래서 이 글은 대략적으로 ‘내가 생각하는 시니어 엔지니어의 역할’ 에 대해서 이야기 한다.</p><h2 id="a388">직접 기여에서 간접 기여로</h2><p id="e8f9">먼저 개발자의 여러가지 역량 중에서 당연히 코드를 작성하는 능력, 코드를 통해 문제를 해결해나가는 능력은 무엇보다 중요하다. 주니어에서 시니어로 넘어갈 수록 코드에 대한 기여가 직접 기여보다는 간접 기여에 가까워진다고 생각한다.</p><p id="fc94">시니어가 직접 코딩을 해서 제품에 기여할 수도 있지만, 주니어들이 문제를 정의하고 해결해나가는 과정을 지켜보면서 멘토링을 해줄 수도 있고, 도저히 문제를 찾지 못할 때 문제를 정의해주는 등도 가능해진다. 다만 이런 멘토링을 1명을 대상으로 하기보다, 팀 전체의 주니어들을 대상으로 진행해야하는 경우가 더 많기 때문에 디테일한 직접 기여보다는 간접적으로 팀 전체에 기여하는 경우가 많다.</p><p id="61aa">또한 코드 리뷰, 설계 리뷰 등에 지속하여 참여하여 주니어들이 놓칠 수 있는 고려사항들에 대해서 이야기하고, 더 나은 코드 및 설계를 만들 수 있도록 하는 데에도 큰 역할을 한다. 그러니 시니어로서 경험이 쌓일수록 더 많은 개발자에게 더 좋은 영향력을 미칠 수 있는 존재라 생각한다.</p><p id="f077">시니어로서 일을 시작하고 어느 시점이 지나면 TL (Tech Lead), TLM (Tech Lead Manager), Team Lead, Domain Lead, Engineering Manager 등의 역할을 부여받을 수도 있고 개별 기여자로서 시니어의 역할을 지속해서 수행할 수도 있다. 어느 조직에는 SWE 면서 IC로 Staff Engineer까지 가는 케이스도 있다던데 정말 뛰어난 사람이 아니라면 대부분은 Tech Lead (or Manager) 역할을 하게 된다 생각한다.</p><h2 id="5de0">비즈니스에 대한 이해와 제품 방향성 잡기</h2><p id="a6b6">적어도 주니어일 때는 내가 비즈니스에 대한 이해도가 낮아도 시키는 일만 하면 되었기 때문에 크게 문제가 없었는데, 비즈니스의 방향성과 제품의 방향성이 서로 정렬되지 않았을 때 큰 문제가 생길 수 있기 때문에 시니어가 되면서부터는 비즈니스에 대한 이해도를 높여야겠다고 생각하게 되었다.</p><p id="d9ba">또한 개발을 잘한다는 말 자체에도 비즈니스에 대한 높은 이해를 바탕으로 적절한 제품을 만들어낼 수 있는 능력이 포함되어있다고 생각한다. 우리가 A라는 제품을 만들기로 하였을 때, 그 A 제품이 우리가 겪고있는 비즈니스 문제를 해결해준다면 A 제품을 만들어야하며, 만약 그게 아니라면 굳이 A 제품을 만들지 않아도 될 수도 있기 때문이다.</p><p id="f4f0">하나의 제품을 만들 때는 정말 많은 리소스가 투입되며, 개발 리소스뿐만 아니라 전략 — 기획 — 마케팅 — QA — PR 조직 등 정말 많은 조직에서 밀접하게 제품 개발에 참여해야한다는 점이다. 그래서 하나의 제품을 만들겠다는 의사결정 뒤에는 언제나 “우리가 겪고 있는 문제를 이 제품이 해결해줄 수 있다” 라는 확신이 필요하다.</p><p id="ed07">(코멘트: 이렇게 말했지만 이 글을 작성하는 나도 언제나 완전한 확신을 가지고 있지는 않다. 지금 상황에서 가장 최선이라고 생각하는 방향을 나아갈 뿐이며, 그 결정이 실패했던 적도 당연히 존재한다.)</p><h2 id="b907">성장 (Growth)</h2><p id="ae85">0년차 ~ 3년차까지는 자신이 어떻게 성장해야하는가에 대한 가이드라인이 잡혀있지 않을 때 불안감을 느낄 수 있다고 생각한다. 경력이 쌓인다고 해서 그 불안감이 사라지는건 아니지만, 그래도 주니어 때에 비하면 훨씬 안정적인 상태라고 생각한다.</p><p id="77bd">시니어는 조직의 성장을 이끌 수 있음과 동시에, 주니어들의 성장을 동시에 이끌어낼 수 있어야 한다. 제품을 제대로 만들어내어 비즈니스의 성공을 이끌어내는 것도 매우 중요하다. 따라서 시니어의 역할에서 무언가를 성장시킨다는 건 뗄레야 뗄 수 없으며, 특히 그 중에서도 함께 일하는 개발자의 성장을 이끌어내는 것이 중요하다고 생각한다.</p><p id="a2f5">예를 들어, 나는 한 조직의 매니저로서 지속해서 챌린지를 주고 그 챌린지를 해결해나가는 과정을 지켜보면서 문제를 인식하고 해결하는 능력을 기르게 하거나, 문제라고 생각했던 게 실제로 문제가 아닌 상황 등에 대해서 관찰하고 적절한 시점에 브레이크를 걸거나 힌트를 주는 등의 역할을 수행하고 있다.</p><p id="7994">시니어로서의 또 다른 면에서는 언제나 누군가의 성장, 무언가의 성장을 이룰 수 있어야 한다.</p><h2 id="c64d">상징성 (Influence)</h2><p id="ab39">이건 조금 더 스타트업에 한정되는 내용인 듯 하나, 어떤 시니어가 그 회사에 상주하고있는가는 생각보다 꽤 중요한 지표로 사용된다. 그러니 채용 마케팅 측면에서는 시니어 개발자의 이름을 통해서라도 개발자를 데려와야하는 상황이 오는 것이다.</p><p id="7e10">시니어가 될 수록 조금 더 채용 마케팅에도 집중하게 된다. 우리 회사가 좋은 회사라는 걸 지속적으로 공유하고, 내가 뛰어난 사람이라는 걸 지속적으로 공유해서 우리 회사에 왔을 때 성장할 수 있을 거라는 믿음을 줄 수 있어야 한다.</p><p id="0cf8">나는 이 영역을 블로그나 강의 등을 통해서 많이 수행하는 편인데, 그러다보니 항상 실속은 없고 그저 입만 나불대는 개발자가 되면 어쩌나라는 고민을 자주 하는 편이긴 하다. 그럼에도 내가 쓴 글이나 내가 만든 강의가 누군가에게 그저 도움이 되기를 바랄 뿐이다.</p><h2 id="52f3">결론</h2><p id="54c1">글로 대략적으로 내가 느꼈던 네가지 측면에 대해서 이야기를 하였다. 언젠가 트위터에도 이야기한 적 있지만 만약 블로그를 통해 취업에 성공한 사람은 블로그를 하라고 멘토링을 해줄 것이고, 지인을 통해 취업에 성공한 사람은 네트워크를 쌓으라고 멘토링을 해줄 것이라 말했는데 이 글에서도 나의 편린이 보이는 듯 하다.</p><p id="922e">그럼에도 시니어라고 감투를 쓰게 된 많은 분들에게 도움이 되기를 바라며 이 글을 작성한다.</p></div></div>

Stories by 조은, Eun Cho on Medium

choeun

시니어 엔지니어는 무슨 일을 해야하나요?
조직에서나 사회에서나 시니어라는 직급을 달고 일한 지도 이제 3 ~ 5년정도 시간이 지난 거 같은데 여전히 시니어 엔지니어가 조직에서 무슨 역할을 해야하는가에 대해서는 회사에 따라서도, 상황에 따라서도 다른 듯 하다.
무엇보다 시니어에 대한 기준조차도 회사별로 너무 천차만별이고, 또 다양하게 이루어지다보니 절대적인 기준을 세우기는 조금 어려운 듯 하기도 하다. 그래서 이 글은 대략적으로 ‘내가 생각하는 시니어 엔지니어의 역할’ 에 대해서 이야기 한다.
직접 기여에서 간접 기여로
먼저 개발자의 여러가지 역량 중에서 당연히 코드를 작성하는 능력, 코드를 통해 문제를 해결해나가는 능력은 무엇보다 중요하다. 주니어에서 시니어로 넘어갈 수록 코드에 대한 기여가 직접 기여보다는 간접 기여에 가까워진다고 생각한다.
시니어가 직접 코딩을 해서 제품에 기여할 수도 있지만, 주니어들이 문제를 정의하고 해결해나가는 과정을 지켜보면서 멘토링을 해줄 수도 있고, 도저히 문제를 찾지 못할 때 문제를 정의해주는 등도 가능해진다. 다만 이런 멘토링을 1명을 대상으로 하기보다, 팀 전체의 주니어들을 대상으로 진행해야하는 경우가 더 많기 때문에 디테일한 직접 기여보다는 간접적으로 팀 전체에 기여하는 경우가 많다.
또한 코드 리뷰, 설계 리뷰 등에 지속하여 참여하여 주니어들이 놓칠 수 있는 고려사항들에 대해서 이야기하고, 더 나은 코드 및 설계를 만들 수 있도록 하는 데에도 큰 역할을 한다. 그러니 시니어로서 경험이 쌓일수록 더 많은 개발자에게 더 좋은 영향력을 미칠 수 있는 존재라 생각한다.
시니어로서 일을 시작하고 어느 시점이 지나면 TL (Tech Lead), TLM (Tech Lead Manager), Team Lead, Domain Lead, Engineering Manager 등의 역할을 부여받을 수도 있고 개별 기여자로서 시니어의 역할을 지속해서 수행할 수도 있다. 어느 조직에는 SWE 면서 IC로 Staff Engineer까지 가는 케이스도 있다던데 정말 뛰어난 사람이 아니라면 대부분은 Tech Lead (or Manager) 역할을 하게 된다 생각한다.
비즈니스에 대한 이해와 제품 방향성 잡기
적어도 주니어일 때는 내가 비즈니스에 대한 이해도가 낮아도 시키는 일만 하면 되었기 때문에 크게 문제가 없었는데, 비즈니스의 방향성과 제품의 방향성이 서로 정렬되지 않았을 때 큰 문제가 생길 수 있기 때문에 시니어가 되면서부터는 비즈니스에 대한 이해도를 높여야겠다고 생각하게 되었다.
또한 개발을 잘한다는 말 자체에도 비즈니스에 대한 높은 이해를 바탕으로 적절한 제품을 만들어낼 수 있는 능력이 포함되어있다고 생각한다. 우리가 A라는 제품을 만들기로 하였을 때, 그 A 제품이 우리가 겪고있는 비즈니스 문제를 해결해준다면 A 제품을 만들어야하며, 만약 그게 아니라면 굳이 A 제품을 만들지 않아도 될 수도 있기 때문이다.
하나의 제품을 만들 때는 정말 많은 리소스가 투입되며, 개발 리소스뿐만 아니라 전략 — 기획 — 마케팅 — QA — PR 조직 등 정말 많은 조직에서 밀접하게 제품 개발에 참여해야한다는 점이다. 그래서 하나의 제품을 만들겠다는 의사결정 뒤에는 언제나 “우리가 겪고 있는 문제를 이 제품이 해결해줄 수 있다” 라는 확신이 필요하다.
(코멘트: 이렇게 말했지만 이 글을 작성하는 나도 언제나 완전한 확신을 가지고 있지는 않다. 지금 상황에서 가장 최선이라고 생각하는 방향을 나아갈 뿐이며, 그 결정이 실패했던 적도 당연히 존재한다.)
성장 (Growth)
0년차 ~ 3년차까지는 자신이 어떻게 성장해야하는가에 대한 가이드라인이 잡혀있지 않을 때 불안감을 느낄 수 있다고 생각한다. 경력이 쌓인다고 해서 그 불안감이 사라지는건 아니지만, 그래도 주니어 때에 비하면 훨씬 안정적인 상태라고 생각한다.
시니어는 조직의 성장을 이끌 수 있음과 동시에, 주니어들의 성장을 동시에 이끌어낼 수 있어야 한다. 제품을 제대로 만들어내어 비즈니스의 성공을 이끌어내는 것도 매우 중요하다. 따라서 시니어의 역할에서 무언가를 성장시킨다는 건 뗄레야 뗄 수 없으며, 특히 그 중에서도 함께 일하는 개발자의 성장을 이끌어내는 것이 중요하다고 생각한다.
예를 들어, 나는 한 조직의 매니저로서 지속해서 챌린지를 주고 그 챌린지를 해결해나가는 과정을 지켜보면서 문제를 인식하고 해결하는 능력을 기르게 하거나, 문제라고 생각했던 게 실제로 문제가 아닌 상황 등에 대해서 관찰하고 적절한 시점에 브레이크를 걸거나 힌트를 주는 등의 역할을 수행하고 있다.
시니어로서의 또 다른 면에서는 언제나 누군가의 성장, 무언가의 성장을 이룰 수 있어야 한다.
상징성 (Influence)
이건 조금 더 스타트업에 한정되는 내용인 듯 하나, 어떤 시니어가 그 회사에 상주하고있는가는 생각보다 꽤 중요한 지표로 사용된다. 그러니 채용 마케팅 측면에서는 시니어 개발자의 이름을 통해서라도 개발자를 데려와야하는 상황이 오는 것이다.
시니어가 될 수록 조금 더 채용 마케팅에도 집중하게 된다. 우리 회사가 좋은 회사라는 걸 지속적으로 공유하고, 내가 뛰어난 사람이라는 걸 지속적으로 공유해서 우리 회사에 왔을 때 성장할 수 있을 거라는 믿음을 줄 수 있어야 한다.
나는 이 영역을 블로그나 강의 등을 통해서 많이 수행하는 편인데, 그러다보니 항상 실속은 없고 그저 입만 나불대는 개발자가 되면 어쩌나라는 고민을 자주 하는 편이긴 하다. 그럼에도 내가 쓴 글이나 내가 만든 강의가 누군가에게 그저 도움이 되기를 바랄 뿐이다.
결론
글로 대략적으로 내가 느꼈던 네가지 측면에 대해서 이야기를 하였다. 언젠가 트위터에도 이야기한 적 있지만 만약 블로그를 통해 취업에 성공한 사람은 블로그를 하라고 멘토링을 해줄 것이고, 지인을 통해 취업에 성공한 사람은 네트워크를 쌓으라고 멘토링을 해줄 것이라 말했는데 이 글에서도 나의 편린이 보이는 듯 하다.
그럼에도 시니어라고 감투를 쓰게 된 많은 분들에게 도움이 되기를 바라며 이 글을 작성한다.

저도 시니어는 처음이라

댓글