조직이 원하는 엔지니어
written by. 기술본부본부장 서영락
결론을 중간에 미리 이야기하면, 제가 생각하는 우리에게 필요한 시니어 개발자는 아래와 같습니다.
필요한 개발자
첫번째, 업무 리딩한다. 제품에 대한 고민과 소통을 많이 한다.
1) 혼자서 기술적인 판단을 하고, 결과를 책임지라는 것이 결코 아닙니다.
간단한 기능 구현부터, 프레임워크, 라이브러리, 아키텍처까지 적용 시점과 구현 일정을 정하며 대외적으로 협의해야 합니다. 판단은 항상 조직원들의 하나의 의견으로써 내려야 하기 때문에 소통은 필수적입니다. 또한 리더라면 팀 내에서 의견을 통합하여 가장 좋은 의견을 내는 것으로, 절대 개인의 희생을 요구하는 위치도 아니며, 모든 것을 책임지는 자리도 아닙니다.
2) 현업 부서 혹은 고객에 대한 소통을 기획자에게 의존하지 마세요.
다양한 기능과 UI/UX경험은 시간이 지날수록 상대적으로 기획자보다 개발자에게 심오한 깊이로 계속 더 많이 축적됩니다. 좋은 설계 방향으로 요구사항을 이끌 수 있게 되면, 목표를 달성하면서도 프로젝트의 난이도를 낮추는 건 엔지니어의 역량에 좌우됩니다. 좋은 설계란 SW공학에 근거한 것입니다. 수십 년 전에 정의된 SW공학은 현시대에도 알맹이는 같고 껍데기만 바뀐다는 뜻으로 근본적으로 변하는 게 하나도 없을만큼, SW공학이 깊을수록 모든 이슈에 매우 정통하게 통한다는 사실을 알 수 있습니다.
두번째, 기술을 리딩한다.
기술 리딩이란, 기능 개발 시간을 줄여서라도, 일정을 늦추더라도 끊임없이 매일매일 설계 및 코드 리뷰를 한다는것을 뜻합니다.
1) 본인 혹은 동료 개발자들의 스타일의 비효율의 영향도가 정말 큰 것이나, 비기능적(성능/보안) 요소들에서 정말 필수적인 조치 등을 꾸준히 찾아내세요.
단기적인 일정을 맞추기 위해 기능 개발에 급급한 것보다 적당한 기술 부채 완화로 장기적인 생산성을 끌어올리는 게 훨씬 중요합니다.
2) 항상 무언가 조치할만한 게 생기면 다 같이 조치의 이유와 기대결과를 공유하세요.
절대로 혼자 해놓고 성과만 내놓는 건 의미가 없습니다. 왜냐하면 대부분 그렇게 할 일은 무궁무진하고 성과로 보기에는 티끌입니다. 동료와의 성장으로 활용하는 것이 본인의 성장과 동료들의 성장에 훨씬 도움이 되고 자타공인의 성과로도 인정할만합니다. (그리고 가끔씩 아무것도 할 일이 없다고 느껴지면, 아직은 주니어인 겁니다)
3) 기술 리딩이란 절대로 선생님처럼 모든 것을 알려주는 것을 의미하지 않습니다.
모르는 건 같이 스터디할 수 있고, 후임 개발자가 깨우칠 수 있게 인사이트를 충분히 제공하고, 리뷰나 페어를 자주 해야 합니다.
세번째, 다른 기술팀에 대한 내용도 들여다본다.
자신 업무에만 몰두하지 말고, 주변에서 일어나는 일에 신경 쓰고, 서로 간에 교훈을 공유하고, 혹시 몰랐던 영향도가 있는지 꾸준히 체크해야 합니다.
네번째, 경청을 제대로 한다.
경청은 잘 들어주기는 하는데, 할 말만 하는 게 아닙니다.
성실히 듣고, 잘못된 부분은 교정하고, 차분하게 설명해야 합니다. 특히나 설명해주는 입장일 때 잘 모르겠으면, 패배감이나 부끄러움을 느끼지 말고, 모른다고 하고 같이 공부하거나 따로 공부해서 정리하고 전달해서 다시 알려주세요. 본인도 다시 지식을 다듬을 수 있는 기회가 됩니다.
다섯번째, 말이나 찍기보다 코드를 먼저 들여다보는 용기가 필요하다.
우리는 항상 시간에 쫓겨 급박하게 조치를 하고 잘 될 때는 한 번에, 안될 때는 수 번에 걸쳐 지연되곤 합니다. 조치를 위해 분석할 코드가 있으면 코드부터 보는 용기가 필요합니다.
운영 업무가 중단되어도 침착하게 사이드 이펙트가 없는 정확한 조치하는 것이 가장 중요합니다. 신속성보다 정확성이 중요합니다. 잘 찍어서 1분일 수도 있지만, 못 찍으면 30분입니다. (최악은 몇 시간입니다.)
위 5가지 외, 추가적으로 필요한 기술적 역량은
1. 설계역량
유지보수성, 확장성을 높게 개발할 수 있도록 해야 합니다. 이를 위해서는 DB모델링, OOP모델링, API모델링, 디자인 패턴, 클린 코드, 서버 인프라 전략 등 다양한 분야에 관심을 가지고 의견을 제시할 수 있게 끊임없이 고민해야 합니다.
2. 라이브러리, 프레임워크 응용력
라이브러리와 프레임워크의 레퍼런스를 보면서 커스터마이징 할 수 있는 수준으로 고민해야 합니다. 그러면 어떤 어려운 난제도 해결할 수 있습니다. 혹은 해결할 수 없는 난제인지의 여부를 알 수 있습니다.
동료들과 시너지를 내고 변화를 주는 엔지니어가 시니어이고, 이 시니어는 기술 스킬보다 기술 탐구욕, 업무 소통력, 동료 소통력이 필수 조건입니다.
동시에 2개 프로젝트를 할 수 있는 2인분의 개발 수준의 역량을 갖춘 시니어를 뽑아도,
나머지 2 생산력 대비 0.5인분 생산력을 가진 주니어들의 생산력을 1 이상 끌어올릴만한 사람이 아니라면,
1 생산력을 가질만한 주니어 2명을 뽑는 게 낫습니다.
게다가 입사할 때부터 2 생산력을 보이는 시니어는 없습니다.
2 생산력 시니어가 해당 생산력을 보이기 위한 적응시간도 적지 않습니다. 만약 1 생산력 주니어를 만드는 시간이 더 오래 걸리더라도 장기적으로 1 생산력을 갖춘 주니어는 2 생산력 시니어까지도 당연히 역량이 된다고 볼 수 있고, 잠재 역량도 더 크게 보게 됩니다.
계속 성장하고 있고, 우리가 추구하는 시니어가 될 수 있는 가능성이 더 높으니까요.
왜 주니어가 가능성이 높냐하면, 여기서 언급하는 기준의 시니어가 아닌 코딩만 빠르고 소통을 잘하지 않는 2 생산력의 시니어는 시간/체력적으로 3 생산력으로 성장도 불가하며, 우리가 추구하는 시니어가 되기에는 그동안의 개인의 축적된 습관을 버려야 해서 같이 일하기가 더 어려울지도 모릅니다.
(https://yozm.wishket.com/magazine/detail/771/ 내용을 발췌했습니다.)
