written by. 기술본부본부장 서영락
저는 현실에서 규정짓는 시니어의 정의에 대해 깨닫고 우리가 지향하는 시니어 엔지니어를 생각할 수 있다면,
‘시니어 부재’ 의 모든 이슈에 대해 이전과 다르게 다룰 수 있고 또 해결할 수 있을 것이라 생각합니다.
우리가 착각해서 발생하는 현실에서의 시니어에 대한 괴리는 다음과 같습니다.
대부분 우리나라 개발 그룹은 연차에 의해 시니어와 주니어를 구분한다.
현실에서는 이후 설명할 제가 생각하는 시니어 요소인, 기술 탐구욕, 업무 소통력, 동료 소통력 등의 판단 기준은 고려하지 않고, 시간이 지나면 자연히 관련 지식과 경험이 쌓일 것이라는 전제로 연차를 기준으로 판단하곤 합니다.
연차가 많더라도 경력이 적은 사람과의 경험과 지식의 차이가 크게 느껴지는 사람을 많이 보지 못했습니다. 특히 주니어의 경우 대다수가 매우 실력에 있어 자신이 없어 보이지만, 실제로 주니어와 주니어가 의존하는 시니어와의 지식의 갭은 단기간 학습으로 따라갈 수 있을 정도로 크지 않습니다. 다만, 시니어가 단기간 전달할만큼의 체계적인 지식을 갖추고 있지 않기 때문에 시니어에 의한 주니어 성장이 어렵습니다. (따라서 대부분 현재 시니어에 의존한 주니어 성장은 기대할 수 없으므로 지양해야 하고, 수평적 소통에 의한 성장을 해야합니다.) 다양한 출신들의 기업 개발자들, 메이저 IT 엔지니어들은 매우 겸손했습니다. 그들도 해당 프로젝트에서도 각자들이 서로 모르는 분야가 존재했고, 오히려 이런것들에 대해 같이 학습하고 토론하는 기술 탐구욕, 소통력이 다들 뛰어났습니다.
스타 개발자와 같은 이력을 보고 시니어로 기대한다.
개인적으로 기술 트렌드적인 내용이 포함된 강의나 세미나 95%는 개요 수준에 불과하다고 생각하지만, 스타 개발자 중 정말 뛰어난 사람도 있을 겁니다. 대부분 스타 개발자는 강의, 저서를 통해 만들어집니다.
반면, 우리가 존경하는 기술본부의 엔지니어들은 시스템 장애 처리, 트래픽 처리, 버그 수정 배포 등에 많은 시간을 쏟는 분들입니다. 이런 엔지니어보다 강연, 저서 활동을 하는 엔지니어를 더 인정하는 문화가 발생해서는 안될 것입니다.
특정 언어나 코딩 능력만으로 시니어 엔지니어를 세운다.
IDE를 잘 쓰는 개발자들의 화면을 보다 보면 영화의 한 장면처럼 현란해 보이기도 합니다. 특히 주니어들에게는 이런 분들은 거의 우상화되고, 충성을 다할 것입니다. 하지만 시간이 지나고 왜 이런 설계이고, 이런 코드가 만들어졌는지 소통의 공백이나 이해가 안되는 시기가 오게 됩니다. 더욱이 시니어가 기술 원리로 심오하게 고민하지 않고 본인만의 스타일대로 코딩할수록 쓰레기 코드가 됩니다. (에얼리언이 알을 까듯이...그러면 주니어들은 쌍욕을 하게 됩니다. )
개발을 잘하는 사람으로 기억되는 유형은 대부분 아래에 해당합니다.
1. 트렌드 위주로 구조를 잡는게 아니고, 아키텍처 개념에 기반한 구조로 개발한다.
MSA는 항상 JPA나 MyBatis를 선택해야 하는 것도 아니고, DDD나 MSA를 선택해야 하는 것도 아니다. MSA 조차 시스템 기능과 비기능의 특성에 맞게 아키텍처를 먼저 고려하고 선택되어야 한다.
2. 언어의 기본적인 개념을 알면서 코딩을 한다.
Java, Spring이라서 class를 만들고 annotation을 써야 하는 게 아니라, 왜 이렇게 되었는지 보다 근본적인 OOP 등의 개념으로부터 접근을 시작한다.
3. 라이브러리나 프레임워크를 도입할 때에는 내부적인 구현을 자주 분석하고 이해하며 개발한다.
실제 현실에서 순수 라이브러리, 프레임워크 API만으로 개발이 모두 가능하지 않는 경우가 많다. 커스터마이징과 응용력이 더 중요하다.
(https://techblog.woowahan.com/2525/ 매우 공감된 글이 있어 발췌했습니다.)