written by. 기술본부본부장 서영락
누구도 우리는 시니어 엔지니어가 어떤 사람인지 막연하게 생각하고 깊게 고민해본 적이 없었습니다.
우리 구성원들은 시니어란 연차가 많아 경험이 많은 사람, 다양한 프로젝트를 해본 사람, 하나에 깊은 지식이 있는 사람 등을 말하고, 위에서 언급한 역량이 필요하다는 것은 이야기했습니다.
이 역량들을 가진 시니어와 아닌 시니어는 실제 현업에서 어떤 차이가 있을까요?
상대적 시니어, 절대적 시니어
개인적으로 다양한 프로젝트와 스터디 등의 경험을 돌이켜보면, 신입에 비해서 수년의 경력이 있는 상대적 고연차나, 절대적으로 10년 이상의 고경력자 등 다양한 개발자를 100여 명 이상은 만나본 것 같습니다. 그런데 대부분 조직에서 연차가 가장 높은 사람을 시니어 대우를 해주덥니다. 이런 기준이 더 이상 의미가 없음을 알게 되었습니다.
위에서 언급한 제가 생각하는 시니어의 역량과 더불어 이 역량을 갖춘 엔지니어들이 많을 때 기대하는 효과는 능동적인 유기체(조직)가 되는 것입니다.
그래서 기대하지 않는/기대하는 시니어(엔지니어)를 2 분류로 나누어서 설명해보고자 합니다.
어쩌다 살다 보니 되어버린 수동적인 시니어(위에서 언급한 역량을 갖추지 않은 시니어)와 스스로 개척하고 극복하여 어디서나 자타공인되는 능동적인 시니어(위에서 언급한 역량을 갖춘 시니어)입니다.
완전히 들어맞게 분류했다기보다는 성장과정이나 업무성향 기준으로 분류해보았습니다.
1. 대부분 신입부터 좋은 사수를 만났던, 그렇지 않던 1~2년간 회사에 재직하다 보면 업무에 익숙해지고, 업무에 익숙해지는 동안 새로운 신입이 오며, 새로운 신입에 대해 의존과 존경을 받게 되거나 회사로써 1인분 몫을 인정받게 됩니다. 이렇게 경험을 쌓아가면서, 어쩌다 보니 시니어가 된 분들입니다.
2. 새로운 이슈와 기술이 나올 때마다 공부를 하고 싶어 하기도 하고, 조직에서 여건을 만들어주고자 하지만 현실에 부딪히면 학습욕이 소극적으로 변합니다. 그래서 업무에 치여 라이브러리 API 구현 껍데기만 보거나 충분히 학습할 시간을 내지 못하기도 합니다.
3. 협업 방식 등 업무 프로세스에 대해 불만은 있지만 주어진 업무에 충실하고자 하는 마음이 강해, 많이 의견을 제안하지는 않습니다.
4. 제품 자체나 기능 요청사항에 불만은 있지만, 주관적으로 본인의 사용자 입장 관점을 막연하게 생각해서 의견을 피력하는 수준입니다.
5. 하던 일이 바빠서 혹은 본인의 업무 범위가 아니라고 생각해서, 기능 요구사항/기획안을 누가 구체적으로 정의해오기를 기다립니다.
1. 처음 업무를 시작할 때부터 기술 분야에 대해서만큼은 원리를 탐구하려는 욕구(?)가 뚜렷하여 업무 소통에서조차도 거침이 없습니다. 무리한 요구사항이나 동료들과의 의견마찰에 타협을 할때도 있지만, 논리가 부족한 부분에 대해서는 기술 공학을 공부해오고 근거로 삼아 주장을 하며 인정을 받아 시니어가 된 분들입니다. 이런 분들은 매우 드물게 사이드 프로젝트에서만 만날 수 있었습니다.
2. 새로운 기술을 꾸준히 발굴하여 조직에게 기회를 제안하거나 만들고자 합니다. 학습욕이 항상 강합니다. 가끔은 업무는 안하고 공부만 하는 것 같기도 합니다.(저는 일에 치여서 업무 품질 안 좋은 것보다 공부해서 꼼꼼하고 정확하게 마무리하는 걸 더 선호합니다.)
3. 협업 방식에 문제가 있으면, 바로 상대방이나 상급자에게 제안과 피드백을 해서 조치를 요구합니다.
4. 제품이나 각각의 기능에 대해서 여러 가지 대안을 제시해줍니다. 구현 시간이 짧은 기준, 유지보수가 쉬운 기준, 확장성이 용이한 기준들이 있습니다.
5. 기획안에 관심을 가집니다. 하던 업무가 있더라도 기획안을 계속 참고합니다. 기획안에 대해서 기획자가 즉답하기 어려운 방법같은 즉, 어떻게 하냐고 물어보지 않고 어떻게 하면 되겠다고 제안합니다. 나아가서는 기획자가 기획안에 설명을 넣느라 기획안 전달 주는 시간이 지체되는 걸 싫어합니다.
면접에서의 차이
수동적인 시니어
과거 어떤 기술로 어떤 기능이나 서비스를 개발했다로 업적을 주로 언급합니다. 우리가 기대하는 시니어로써 역할을 할 수 있을지는 미지수로만 보입니다.
능동적인 시니어
현재의 관심 기술, 방향과 이를 위해서 개인적으로 준비해온 과정들과 이력이 특이하거나 좀 더 명확합니다. 우리와 핏이 맞는지 검토하기가 더 수월합니다.
문제상황 접근 방식의 차이
수동적인 시니어
문제상황에 대해서 어떻게 하다 보니 되었다던지, 시행착오를 통해 여러 방법을 바꿔서 해보았더니 되었다던지, 구글링을 통해서 해왔다 등의 주먹구구식의 해결방법이 습관화되어 있습니다.
능동적인 시니어
자바 개발자라면 조금 더 OOP의 공학부터 검증하거나, 관련 이슈에 해당하는 API 공식 가이드나 라이브러리/프레임워크 코드를 직접 분석해본다던지, 혹은 다른 아키텍처 진영이나 여러 가지 프랙티스를 비교하면서 답을 찾는 성향을 보입니다.
협업방식의 차이
수동적인 시니어
책임과 업무의 범위를 중요시합니다. 나의 일이 아니면 관심 스위치가 꺼집니다. 주니어와 같습니다.
능동적인 시니어
직무와 분야가 다르더라도 여러 가지 공학 관점으로 다양한 해결방법을 같이 찾아내고자 합니다. 모든 과업의 기술적인 도전이 발생하는 순간을 즐기기도 합니다.
주니어에 대한 성장 영향성 차이
수동적인 시니어
부딪힌 문제 혹은 새로운 문제에 대해서 그동안 쌓아온 경험에 의존하여 문제를 해결하며, 주니어들에게도 본인의 경험에 의한 설루션이 맞다고 생각하거나, 쉬운 분업을 위해 본인의 경험과 동일한 경험을 하도록 가이드합니다.
결국 주니어들은 시니어의 경험을 100% 습득하기도 어렵고 시니어의 경험에 한정된 성장을 하게 됩니다.
능동적인 시니어
과거와 비슷한 이슈더라도 새롭게 인식하고, 과거에 보지 못한 부분을 고민하거나, 현대에 발전된 API들로 개선할 수 있는지를 고민합니다. 이러한 갭 분석을 위해 DB모델링, OOP모델링, 디자인 패턴, 인프라 설계 등의 SW공학이 필요하다는 것을 알게 됩니다.
주니어들은 이슈를 보다 근본적으로 바라볼 수 있는 기회가 생겨 비슷한 이슈에 대해 응용된 문제 해결 능력을 갖추게되고, 철학과 같은 공학은 시니어 스스로에게도 다른 느낌의 시야를 제공하기도 합니다.
제로베이스의 업무나 팀을 빌드업 할 때 차이
수동적인 시니어
실무위주의 역량에는 뛰어나지만 업무나 팀을 정의하고 거버넌스(조직 관리 체계, 조직 구성, 업무 구성 등)를 구축하는 업무에는 실무자 수준의 시야에서 한계를 보입니다.
능동적인 시니어
실무 외적으로 여러 가지 협업방식과 업무 범위에 대한 이해가 포괄적이며, 그러한 관점에서 축적된 지혜를 나타내기도 합니다.
당장의 공수를 해결하기 위해 수동적인 시니어를 채용하게 되면, 위에서 이야기한 반대급부의 공수들이나 기대에 못 미치는 결과가 나타나게 됩니다. 장기적으로는 생산성을 저하도 피할 수 없게 될 것 입니다.
그렇다면 능동적인 시니어를 뽑으면 되는 거 아닌가?
라고 생각하신다면, 현재 우리 팀프레시 기술본부에 그런 시니어를 뽑아도 시니어의 부재에 대한 느낌들은 현재와 크게 다르지 않을 것입니다. 근본적인 해결책은 우리가 능동적인 개인 및 조직이 되는것 입니다. 개인이 저렇게 능동적이 되려고 하더라도, 조직 전체가 응원하고 협력하지 않으면 자주 낙심하게 됩니다. 따라서, 조직적인 조치와 제도가 필요합니다.
다음편에서는 구글의 지메일과 구글어스 출시의 비결이었던 80:20법칙에 대해 다뤄보려합니다.