FE 리더가 되어버린 나, 이대로 괜찮은가?: 시니어 개발자인 내가 주니어 매니저가 되어 버린 건에 대하여

시작하며

안녕하세요, 카카오페이 채용팀입니다.
얼마 전 링크드인을 통해 참여 신청을 받았던 Paytalks with KREW - FE 밋업이 진행되었는데요. 많은 분들이 신청해 주셨지만 모두 모시지 못해, 밋업의 현장감을 느낄 수 있는 아티클로 전달드리고자 합니다. 이번 주제는 바로 ‘FE 리더가 되어버린 나. 이대로 괜찮은가?: 시니어 개발자인 내가 주니어 매니저가 되어 버린 건에 대하여’인데요. 1명의 개발자로서, 1명의 직장인으로서 느끼는 고민과 애환에 대해 두루두루 편하게 나누는 이야기를 들어보세요!

행사 소개

잠깐! Paytalks with KREW란?

Paytalk은 내부 크루와 외부 후보자분들을 연결하여 동반 성장 하실 수 있도록 마련해 드리는 밋업/네트워킹 세션인데요. 과거에는 주로 내부에서 기술 문화/일하는 방식을 정리해서 발표하는 식으로 진행되었지만, 이번에 진행한 Paytalks with KREW는 소규모로 구성하여 참가자분들의 깊은 고민을 들어보는 시간을 가지게 되었습니다.

메인 아젠다

FE 리더가 되어버린 나. 이대로 괜찮은가?: 시니어 개발자인 내가 주니어 매니저가 되어 버린 건에 대하여

상세 아젠다

[기술]

• FE 개발자는 FE 개발에만 관심을 가져도 될까?
• 웹 접근성 / 사용자 경험에 대한 고민을 나눠보기
• Native Client와 Frontend의 협업 방식에 대한 이야기
• 신기술(새로운 프레임워크, 도구) 도입에 대한 생각 나누기
• Server Side Rendering과 Client Side Rendering 이야기

[관리]

• 주니어 개발자들의 동기부여 - 성장촉진 방법에 대하여
• 팀의 성장과 나의 성장의 밸런스 찾기
• 채용할 때 내가 주목하는 부분
• 직군 리더 - 시니어로서 각자의 고민

자기 소개

🧑‍💻: 안녕하세요! 저는 카카오페이에서 프론트엔드 길드 전체를 리딩하고 있는 벤이라고 합니다. 프론트엔드 개발을 한 지 올해로 13년 차가 되었고, 오늘 나누는 이야기들이 여러분들에게 많은 도움이 되셨으면 좋겠습니다.

🧑‍💻: 저는 카카오페이에서 6년 차 프론트엔드 개발을 하고 있는 에릭이라고 합니다. 기술조직으로 구성된 FE개발팀 팀장을 하고 있습니다. 잘 부탁드립니다!

🧑‍💻: 안녕하세요. 저는 올해 8월부터 정식 프론트엔드 리드를 담당하게 되었고요. 작년 12월부터 리드 대행을 하고는 있었는데 고민되는 부분이 많아서 신청하게 되었습니다. 저는 8년차 프론트엔드 개발자이고 6명 규모의 조직을 리딩하고 있고요. 개발을 겸하고 있는 실무형 아가 리더라고 봐주시면 될 것 같아요.

🧑‍💻: 저는 10년 차 프론트엔드 개발자이지만, 리드 경험은 없는데요. 늘 혼자서 일했고 지금도 목적조직 내에서 1인 프론트엔드 개발자로 일하고 있습니다. 백엔드 개발자분들이 도와주시긴 하지만, 사이즈가 좀 작은 서비스다 보니 주로 혼자 설계하고 개발하고 있어요.

🧑‍💻: 저는 리드를 자발적으로 맡은 건 아니지만, 맡은 지 1년 정도 되어 가네요. 오늘의 주제가 ‘시니어 개발자가 주니어 매니저가 되어버린 건에 대하여’인데, 저는 제가 시니어라고 생각하지는 않아요. 많이 배우고자 참석하게 되었습니다.

🧑‍💻: 안녕하세요. 저는 작년에 리드가 되었다가 너무 힘들어서 다시 팀원으로 일을 하고 있습니다. 그래서 리드를 하고 계신 분들이 너무 존경스러워요.

🧑‍💻: 저는 이 회사에서 두 번째로 리드를 하고 있는데요. 실무를 병행하고 있어서 생각보다 쉽지 않은 부분도 있고 많이 배우고 있습니다.

FE 개발자는 FE 개발에만 관심을 가져도 될까?

🧑‍💻: 오늘은 크게 기술/관리 두 개의 주제로 이야기를 하려고 합니다. 첫 번 째는 리드로서 기술을 선택하는 부분, 두 번째는 팀을 관리하는 부분입니다. 기술에 대한 이야기부터 먼저 해볼까요? 요즘 개발자 커리어를 시작하는 분들을 보면 하나의 기술에 집중하는 분들이 많은데요. 제 경험을 비추어볼 때 프론트엔드 개발을 하다가 DB설계나 네이티브 개발을 하게 될 때 ‘이걸 내가 왜 해야 하지?’라는 생각도 들었거든요. 물론 회사의 사정에 따라서 하게 된 거지만 이제 돌이켜보면 풀스택이나 네이티브 개발에 대한 이해도가 있으니 백엔드 개발자분들과 커뮤니케이션을 할 때 수월한 부분이 확실히 있다고 생각이 됩니다. 그래서 주변 주니어 개발자분들에게 기회가 되면 관심을 좀 확장하거나 사이드 프로젝트라도 시도해 보라고 조언을 드리고 있어요.

🧑‍💻: 저도 굉장히 공감되는 말씀인데요. 백엔드 개발자와의 소통뿐 아니라 디자이너, 그 외 직군과의 소통과 직군 이해도가 있어야 하는 것 같아요. 커뮤니케이션을 떠나서도 저는 요즘 QA팀, CS팀, legal팀과 협업을 많이 하고 있습니다. 프로덕트를 만들 때 일이 되게 하는 방향으로 이끌고 싶다면 그들의 일을 이해하면서 소통해야 하는 것 같아요. 또 본격적으로 공부할 필요까지는 없지만 내 프로덕트와 맞닿아 있는 거라면 최대한 이해하려고 노력하고 있어요. 옛날에는 담당팀에서 알아서 해주겠지 라는 수동적인 생각이었다면, 요즘은 좀 더 능동적으로 챙기게 되는 것 같아요.

🧑‍💻: 좋은 말씀이시고 저도 동감하지만, 반면에 이런 생각도 들어요. 과거 웹 에이전시 SI 회사에서 일을 한 적이 있었는데 개발자에게는 디자인/기획을 알아야 한다고 하고, 기획자에게는 디자인/퍼블리싱 정도는 알아야 일을 잘한다고 하고, 디자이너에게도 같은 이야기를 하시더라고요 . 그런 맥락에서 보면 “내 일만 잘하기도 사실 바쁜데, 왜 다른 직군의 전문성까지 계속 두드려야 할까?”라는 면에서 생각해 볼 여지가 있을 것 같습니다.

🧑‍💻: 내가 프론트엔드 코드만 작성하고 끝나는 게 아니라, 이 코드가 빌드되고, 인프라에 올라가고, 배포되고.. 이런 일련의 과정이 있는데요. 어떤 이슈가 발생했을 때 프론트엔드 개발만 알고 있다면 좁은 범위의 문제 해결만 할 수 있는 것 같아요. 또, 제품 측면에서도 디자이너가 모든 부분을 챙기기 어려울 때 UI/UX 지식이 있다면 먼저 제안하면서 빠르게 만들 수 있는 것 같습니다.

🧑‍💻: 방금 하신 말씀 중에 비개발 쪽이나 다른 개발 직군에 대한 이해도가 있을수록 문제 해결 범위가 넓어진다는 부분이 공감이 되는데요. 최근 프론트엔드 인프라 측면에서 Client Side Rendering을 위해 Static File을 뽑아서 배포할수도 있고, Server Side Rendering을 선택해서 서버에 배포할 수도 있고요. 그 앞단에 CDN을 붙여서 캐싱 레이어를 추가하는 등 다양한 방법과 기법들이 존재하고 소개되는데요. 회사가 커질수록 각자의 전문분야가 나뉘다 보니 오히려 같이 고려하면 더 잘할 수 있는데 단절되어서 더 못하게 되는 경우도 발생하는 것 같아요.

🧑‍💻: 이야기하면서 느끼는 거지만 제 개인적으로는 더 뛰어난 프론트엔드 개발자가 되기 위해서는 알아야 하는게 더 많은 것 같습니다. 리드로 올라가면 회의하는 카운터파트들이 많은데, 그들의 언어에 대해 조금 더 학습해야 수월하더라고요.. 그러다 보면 “나는 개발자인가?”라는 생각도 들고요. (웃음)

웹 접근성/사용자 경험에 대한 고민을 나눠보기

🧑‍💻: 다음 주제는 웹 접근성과 사용자 경험인데요. 프론트엔드 개발자로서 어렵기도 하고 일하다 보면 점점 챙기기 어려운 부분이기도 해요. 플랫폼 중앙에서 컨트롤을 잘해줘야 가능한 영역이라고 생각이 되기도 하고요. 어떠세요?

🧑‍💻: 저희 같은 경우는 법적으로 챙겨야 하는 부분, 인증을 받아야 하는 부분이 있어서 신경을 많이 쓰고 있긴 해요. 근데 제 개인적으로는 실제로 접근성 기기를 사용하는 사람을 만나봐야 알 수 있다고 생각해요. 저번에 우연히 마사지를 받으러 갔는데 시각장애인 안마사 분이 계신 거예요. KTX 티켓을 끊으려고 하는데 어디는 결제가 되고 어디는 안되더라 말씀하시더라고요. 그 김에 이것저것 여쭤봤는데 그분들의 니즈가 굉장히 크시더라고요. 그래서 회사에 와서도 그런 사례를 전파하게 되었어요. 이렇게 실제 유저의 이야기를 듣지 않으면 진짜 유명무실하게 되는 것 같아요.

🧑‍💻: 어떻게 생각하면 양날의 검 같다는 생각도 들어요. 처음 의도대로 개발을 잘했는데도 불구하고 접근성을 지키면서 코드를 관리하기가 쉽지 않은 경우가 많아지는 걸 보면서 점점 더 신경 쓰지 않게 되는 것 같아요. 중앙에서 강력하게 이끄는 조직이 있다면 잘 관리할 수 있을 것 같은데, 그렇지 못해서 아쉬워요.

🧑‍💻: 제 생각엔 운영하는 서비스 코드의 수명이 너무 짧아서 그런 것도 있는 것 같아요. 프론트엔드 개발자로 일하다 보면 가끔 ‘내가 온라인 전단지 만드는 사람인가?’라는 생각이 들 때가 있어요. 그러다 보니 당장 오래 쓰일 거라는 확신이 없다면 웹접근성을 거쳐야 하는 전사 프로세스가 별도로 있지 않은 이상 챙길 수 없기도 하고요. 근데 저는 웹 접근성보다는 사용자 경험이 더 중요하다고 생각하고 있어요. 최근에 저희 서비스는 다크모드 관련 유저 피드백이 접수되고 있는데요. 사용자들의 의식이나 기술에 대한 기대 수준이 발전하면서 그걸 맞추고 따라가기에도 프론트엔드 입장에서 벅찬 것 같아요.

🧑‍💻: 사용자 경험이라는 부분은 여러 가지 포인트가 있을 것 같은데요. 과거 TV를 개발한 적이 있는데 지금이야 브라우저 성능이 좋아졌지만 성능이 좋지 않은 브라우저를 사용했었어요. 웹 표준에 미치지 못하는 부분들도 있었고요. 그 시절에 비하면 발전한 게 많아서 지금은 일반적인 사용자나 디자이너의 요구사항들을 거의 맞출 것 같은데, 아직도 해결하기 힘든 건 초기 진입 속도인 것 같아요. 특히 모바일에서 제공하는 서비스들은 그걸 어떻게 만족시킬지, 어떻게 해결할지가 당분간 프론트엔드 개발자가 해결해야 할 숙제인 것 같아요.

🧑‍💻: 저희도 여러 가지 검토를 했었는데요. 이것저것 테스트를 하는 과정에서 PWA (Progressive Web Apps)처럼 클라이언트에 미리 번들을 받아보기도 했고, SSR을 빡세게 쓰는 방법도 있었고, RN (React-Native)을 쓰는 방법도 있었어요. 결국 너무 슬프게도 RN으로 가기로 했지만요.

🧑‍💻: 왜 슬프죠?

🧑‍💻: 웹이 아니니까요. 아직은 RN 커뮤니티가 작고, 디버깅하기 어렵고, 항상 시뮬레이터를 띄워서 개발하는 게 힘들어요. 친숙한 브라우저의 ‘window’ 객체가 없는 것도 아쉬워요. 이제 도입을 시작한 지 1년이 넘었고, 초기 진입 속도가 중요한 서비스부터 시작해서 이 부분을 부스팅 하고자 점점 확장되는 추세예요.

🧑‍💻: 초기 진입 속도를 빠르게 하는 게 좋다고 하셨는데 저는 잘 모르겠어요. 어지간한 웹사이트들은 들어가면 로딩 시간이 필요하다는 건 사용자들도 알고 있다고 생각해요. 그래서 시간이 걸리더라도 로딩이 돌아가나 보다 생각하지, ‘이것 때문에 너무 불편해 사용자 경험이 안 좋아’라고 받아들이진 않을 것 같아요. 개발자들이 계속 SSR을 하자, 초기 레이턴시를 줄여보자고 하는 건 사실 개발자들의 바람이 아닐까 하는 생각도 들어요. 왜냐하면 제 생각에 사용자들은 초기 진입 속도보다는 버튼을 많이 눌러야 하거나 스텝이 많아질 때 불편함을 더 많이 느끼는 것 같다고 생각하고 있거든요.

🧑‍💻: 웹뷰 베이스로 개발을 하다 보면 느끼는 게 사용자들은 웹뷰를 그냥 앱의 구성 요소로 생각하고 있다는 거예요. 그래서 대부분의 첫 화면은 네이티브로 동작하는 경우가 많은 것 같고요. 그러다 보니 처음에는 되게 빠르게 잘 떴는데, 페이지를 이동할 때 느리게 뜨거나 로딩을 띄우면 바로 끄는 경우가 생기는 것 같아요.

🧑‍💻: 사용자 경험은 서비스 회사마다 방향이 다른 것 같아요. 예를 들어 네이버 같은 앱을 보면, 페이지를 로딩할 때 상단에 녹색으로 인디케이터를 표시해주고 있어요. 그래서 이게 오히려 더 좋을 수도 있을까?라는 생각을 하기도 하거든요. 근데 앱 기반의 다른 서비스들에서는 화면에 로딩도 뜨지 않거나 그러면 좀 그래요.

🧑‍💻: 그게 서비스의 스테이지에 따라 필요성이 달라지기도 하는 것 같은데요. 저희도 A/B테스트를 띄우는 MVP (Minimum Viable Product) 초기에는 로딩 속도가 중요하지 않은데 어느 정도 서비스가 성장하고 유저가 많아지면 다음 스테이지로 네이티브 경험을 주자고 하고 있어요. 퍼널을 줄이거나 버튼을 줄이거나 하는 챌린지는 이미 끝난 단계일 거고요. 사실 이런 부분은 보통 플랫폼 작업이기도 해서 전사적인 챌린지로 봐야 할 것 같아요.

Native Client와 Frontend의 협업 방식에 대한 이야기

🧑‍💻: 네이티브와의 대부분의 협업은 웹뷰에 필요한 기능에 대한 요청을 많이 하게 되는데요. 아무래도 프론트엔드에서 필요한 기능 대비 프론트엔드 개발자가 가지는 네이티브 플랫폼의 이해도가 떨어지거나 반대로 요청을 받는 네이티브 개발자가 바라보는 기능의 필요성이 공감이 잘되지 않는 경우들이 있어 기능에 대한 논의가 잘 이루어지지 않는 경우가 있는 것 같아요.

🧑‍💻: 그래서 보통 저희는 웹뷰에 대한 경험이 많고 레거시를 많이 아는 누군가가(아마도 저… 웃음) 기능에 대해 듣고, 정리하고, 네이티브 개발자들에게 공유하고, 검토 요청하고, 스펙을 확정하고, 배포 일정을 보고, QA 확인하고, 일정 잡고, 테스트 페이지로 검증하고…. (슬픈 웃음)

🧑‍💻: 저는 웹에서는 다 잘 돌아가는데 웹뷰에 올렸을 때 안 되는 경우도 있더라고요. 예를 들면 Geolocation API이었어요. 결론적으로는 앱에서 설정을 해줘서 해결했는데요. 이런 상황을 만나면 이게 내가 잘못한 건지, 아니면 환경 때문에 안 되는 건지를 잘 모르겠는 경우가 있더라고요.

🧑‍💻: 일단은 클라이언트 분들에게 물어봐야 해요. 근데 그분들도 모르실 수 있어요.

🧑‍💻: 정도는 아니지만 제가 써보고 효과가 좋았던 방법이 있는데요. 처음엔 그냥 여쭤봤어요. 근데 그분들도 잘 모르시길래 나름 증빙을 찾아서 올리고 했더니 사람들이 보통 답답해서 고쳐주시더라고요. (웃음) 많이 쓰면 이미지가 안 좋아지지만 가끔 쓰면 유용해요.

🧑‍💻: 저도 똑같은 걸 한 번 겪고 단순 요청을 하게 되면 오래 걸리는 경우가 많길래 지금 회사에서는 입사하자마자 네이티브 브릿지 문서를 만들었어요. 그러다 막히면 문서 같은걸 한 번씩 보기도 하고, 그냥 노트북 들고 가서 옆에서 같이 하기도 하고요. 재택을 안 하는 회사라. (웃음) 처음엔 네이티브 개발자분들에게 요청을 했는데 답변을 못 듣는 경우도 있었어요. 거기도 일이 많으실 거라 당연히 이해해요. 그래서 중간에 요청건들에 대해서는 PM을 거치는 프로세스를 만들었고, 서로 PM의 주도하에 도움을 주고받고 했던 것 같아요.

🧑‍💻: 사실 저희는 요청자 입장이다 보니 기능에 대한 긴급도가 서로 달라서 오는 문제도 있는 것 같아요. 서비스는 당장 필요하면 기능 구현을 요청할 때 공감도가 충분히 있는데 당장 쓰이지도 않는 기능을 미리 요청하게 되는 경우에는 native에서는 서비스 수준에서 구현되는 게 아닌 테스트페이지에서의 단순한 구현 결과만 보시기 때문에 이걸 서비스 수준에서의 테스트도 어렵고 기능에 대해 100% 이해하기도 어렵더라고요.

Server Side Rendering과 Client Side Rendering 이야기

🧑‍💻: 저희는 최근 만든 제품들은 100% SSR이에요. 초기 렌더링을 빠르게 하거나 SEO (Search Engine Optimization)를 챙겨야 하는 일이 많다 보니 CSR를 선택할 일이 많지는 않은 상황이에요.

🧑‍💻: 근데 SSR이 무조건 빠르다고 할 수는 없지 않나요? 서버 - 서버 요청에서 지연이 생기거나 초기 데이터가 너무 많아지면 느려지는 부분도 있어서, 특정 부분을 SSR로 처리하더라도 CSR이 장점을 갖는 케이스도 있는 것 같아요.

🧑‍💻: 저희는 SSR을 최근에 많이 도입하고 있는데, CSR을 위한 인프라가 따로 준비되어 있어요. CSR로 서비스를 구성한다고 하면 이 인프라를 활용해서 프로젝트 세팅부터 배포까지 10분 정도면 마무리가 되거든요. 이 인프라에서는 서비스 운영에 필요한 여러 기능도 제공하기 때문에 편리한 부분도 있고요. 다만 초기 렌더링 이슈도 있고, 구성원들의 성장과 같은 측면에서도 그렇고 해서 SSR을 많이 써보고 있는데요. 확실히 인프라가 갖추어진 CSR 보다는 운영적인 측면에서 어려워요. 저희의 CSR 인프라를 활용한다면 인프라팀의 든든한 운영을 바탕으로 안정적으로 서비스를 운영할 수 있는데, SSR을 쓰면서부터는 각 구성원들이 관련된 인프라를 다 챙겨야 하는 상황이거든요. 이런 부분이 고민입니다.

🧑‍💻: 저희는 렌더링 기법이 많이 섞여서 사용되는 편이에요. 예전에 개발된 건 CSR로 개발되어 있고, 요즘에 개발하고 있는 것들은 SSR을 많이 사용하고 있고요. 최근에는 RN으로도 많이 보고 있고요. 개발자 경험은 CSR이 우세한 경우도 있는 것 같아요. 직관적으로 개발할 수 도 있고 운영적인 측면에서도 장점이 있고요.

🧑‍💻: 저희는 대부분 SSR을 사용하지만 CSR을 사용해야 하는 경우도 분명히 있었어요. CSR을 사용할 때는 Prefetching 같은 기법을 사용해서 조금이라도 속도를 빠르게 하기 위해 노력하고 있고요.

🧑‍💻: 저희는 대부분 SSR을 사용하고 있는데 캐시랑 Prefetch를 사용해서 속도를 빠르게 하려고 노력하고 있어요. AWS Cloudfront를 사용한 캐시도 사용하고 있고요.

주니어 개발자들의 동기부여: 성장촉진 방법에 대하여

🧑‍💻: 요즘 개발자분들은 제가 신입 때와는 참 다르다고 느끼고 있는데요. (웃음) 원하는 게 워낙 명확하고 하고자 하는 욕구도 강하고요. 그런데 막상 실제로 할 수 있는 부분은 되게 제한적이고 팀으로서 일할 때 해야 하는 일들이 정해져 있는 부분에 대해 동기부여를 느끼지 못하는 주니어 개발자분들도 있으시더라고요. 예를 들어 입사 후 1년이 지나고 나면 더 이상 같은 걸 하기 싫어하는 사람도 있고요. 그런 경우에는 어떻게 동기부여 하는지 궁금합니다. 저 같은 경우는 당근을 주는 편인데요. 똑같은 서비스를 만들더라도 다른 기술을 써보라고 제안하기도 하고 새로운 걸 경험하게 하는 편이에요.

🧑‍💻: 일단 저한테는 평가 권한이 없지만 원온원을 하고 있어요. 제가 항상 여쭤보는 것 중에 요즘 못해서 아쉬운 부분을 물어보는데, 그러면 막 엄청 많이 나옵니다. 특히 개발에 열정적인 분들은 보통 많이 나오더라고요. 리더 입장에서는 그걸 말하게 하고 우리 팀의 목표와 얼라인 시켜서 개발 과제로 만들어 주고, 실제로 끝난 걸 체크해서 수치적인 임팩트를 증명하는 부분을 도와줘야 하는데 이게 참 어려워요.

🧑‍💻: 저는 B2C 개발을 하다 보니까 제가 꼭 필요하지만 어떻게 보면 재미는 없을 수 있는 일들을 하고, 재밌어 보이는 일들을 드리면 좋아하시더라고요. 아무래도 일반 유저가 대상이다 보니 내가 만들어서 직접 써보고, 주변 사람이 사용하는 모습을 보면서 뿌듯함을 많이 느끼는 걸 봤어요. 잘하고 있다는 이야기도 많이 해주고, 개인적으로는 이력서를 같이 봐주거나 컨퍼런스에 주기적으로 다녀오라고 지원해 주는 방향으로 동기부여를 하고 있어요. 또 면접에 함께 참여하거나 해서 시장의 상황을 파악하게 하고 면접관으로 더 노력하는 모습을 보기도 하고요. 아까 재미없는 일이라고 말씀 주셨는데 저희는 분기별로 재미없는 일을 하는 사람을 나누고 있어요. 한 명에게만 몰리지 않도록 1Q에는 장애 대응을 했다면 2Q에는 재밌는 일을 할 수 있도록요. 특히 젊은 친구들이 사용자 경험에 관심이 많은 것 같은데, 야근해서라도 막 챙기고 싶어 하더라고요. 사실 개발자가 원하는 모든 서비스가 진행되긴 어려워서 실험실 같은 기능을 만들자고 제 상위 리더를 설득해서 적용해 볼 수 있도록 노력해주고 있어요.

🧑‍💻: 저 한 가지 궁금한 부분이 있는데요. 재미없는 부분을 리더가 해준다고 하셨는데.. 저도 그러고 있거든요. 근데 그러다 보면 약간 현타도 오고, 이게 조직적으로 맞나? 하는 생각도 들더라고요. 누군가는 조직에서 문제를 정의하고 방향성을 제시해야 하는데 오는 문제만 처리하고 있는 게 맞나 싶기도 하고요. 물론 리소스가 충분하다면 해결될 문제지만, 이 밸런스를 어떻게 잡아야 할지가 고민이더라고요.

🧑‍💻: 주니어에게 동기부여 하기 위해 재밌어 보이는 일만 주고 쪼들리는 일을 대신해주다 보면, 나중에 그들이 시니어가 되었을 때 재미없는 일을 하면 받아들일 수 있을까요? 오히려 미리 겪는 게 더 멘붕이 안 올 수도 있다는 생각을 해봅니다. 항상 즐거운 건 아니구나. (웃음)

🧑‍💻: 저도 채용한 주니어 개발자분들이 많다 보니 똘똘하게 잘 찾아먹는 스타일도 있고 알려줘야 하는 스타일도 있고 다양한 것 같아요. 이렇게 제가 한 사람 한 사람 다 채용한 사람들이지만 평가를 할 때는 또 나쁜 소리를 할 때도 있어서 어려운 것 같아요. 성향상 싫은 소리를 잘 못하기도 하지만 구체적으로 평가를 잘해줘야 하는데 그게 어렵더라고요. 동기부여를 해주는 게 좋은 분이 있을 것이고, 나쁜 소리를 해줘야 좋은 분이 있을 건데 회사 분위기 자체가 나쁜 소리를 하는 분위기도 아니기도 해서요.

🧑‍💻: 제 경험에 뭔가 이벤트로 동기부여가 될 때도 있었어요. 가끔 장애를 겪게 되면 대응하는 프로세스라던지 휴먼 에러를 방지하기 위해 개발 습관을 바꾸게 된다던지 하는 부분이요. 또 같이 면접에 들어가게 되면서 이력서에 적혀있는 내용과 설명하는 부분을 간접적으로 보게 하면서 깨닫게 하는 방법도 있는 것 같아요.

🧑‍💻: 저희는 구성원 분들과 원온원을 할 때 여기서 쌓고 싶은 커리어, 나갈 때 갖고 나가고 싶은 커리어에 대해서 이야기해요. 특히 제가 도와드릴 수 있는 부분은 없을지 물어보는 편이지만 가끔은 회사의 방향과 맞지 않는 기술을 사용하고 싶다고 하시거나 하는 경우에는 설득하는 편인 것 같아요. 비생산적인 업무들은 최대한 자동화하자고 하기도 하고요.

🧑‍💻: 가장 중요한 건 결국 개개인에 대한 현 상황 판단이 중요한데 결국 비슷한 것 같아요. 리드를 하고 있지만 개발도 하고 있고, 코칭도 하고 있고, 이리저리 쫓아다니다 보면 결국 개개인에게 소홀해지는 것 같더라고요. 혼자만의 현타를 겪다 보면 나는 개발자인가 관리자인가 싶기도 하고요. 한 조직은 그 리더의 역량 이상으로 성장하지 못한다 는 이야기를 들었는데, 그게 맞다고 생각했어요. 그러다 보니 내가 더 잘해야지만 이 친구들이 더 잘하지 않을까 생각에 스트레스를 받기도 하고요.

🧑‍💻: 팀 리더라는 게 우리에게 부여된 어떤 일을 해내게끔 팀원들을 다독이는 역할인 것 같아요. 그 팀원들이 가지고 있는 니즈를 채워줘야 하기도 하고요.

🧑‍💻: 지금 드는 생각은, 팀원의 성장을 챙긴다는 것보다는 팀의 성장을 챙겨야 하는 것 같아요. 이 사람이 더 큰걸 볼 수 있게 되면 기술적/프로덕트적으로도 더 좋은 역량을 낼 수 있기 때문에 저희 프로덕트가 성장하게 되고 그러기 위해서는 그 사람이 제일 빠르게 성장할 수 있는 방향을 제가 어떻게든 캐치해줘야 하는 거죠.

🧑‍💻: 그럼 우리들의 성장은 누가 챙겨주나요?

팀의 성장과 나의 성장의 밸런스 찾기

🧑‍💻: 결국 시간이 가면 갈수록 관리자와 테크 리더의 커리어가 나뉠 텐데, 대부분의 회사에서는 이 역할을 함께 수행하고 있는 것 같아요. 그 과정에서 내가 어떻게 성장할 수 있을까 하는 갈증은 모두 있으실 것 같고요. 아까 말씀드린 리더가 쪼들리는 일들을 대신해주다 보면, “그럼 나도 나중에 이직을 해야 하는데 어떡하지?” 싶기도 하고요. 보통 테크 기업들이 직급이 올라갈수록 백엔드 백그라운드의 개발자분들이 많은데, “프론트엔드 개발자로서 우리는 그 좁은 문을 통과할 수 있을까?”하는 고민을 하게 되는 것 같아요. 전통적인 시각에서 보면 직급이 올라갈수록 전체적인 기술을 보겠지만 사실 백엔드 관점에서 바라봐야 하는 부분이 많은 것 같기도 하고요.

🧑‍💻: 저는 최근에 운 좋게 몇 년 빨리 시작해서 지금 일을 하고 있다고 생각하는데요. 같이 공부했던 분들은 PM/PO로 커리어를 전환하신 분들이 많아요. 제 생각에 저보다 나은 선택을 하고 더 나은 방향으로 잘 성장한다고 생각했던 분들이 커리어 전환을 하시는 걸 보면 제 커리어도 돌아보게 되더라고요. 비슷한 일을 하더라도 PD/PM/PO 같은 단어들로 무장되는 걸 보면, 회사에서 정의해 준 명칭이 아니라 내가 나를 정리하는 단어가 따로 있으면 좋겠다는 생각도 들고요.

🧑‍💻: 어떻게 보면 저희 세대가 프론트엔드 최전방이라고 봐야 할 것 같아요. 우리가 정점을 찍는 정도에 따라 후배들이 따라올 텐데 그 이정표를 어떻게 찍는지가 중요한 것 같아요. 회사에서 별도로 커리어 트랙을 명확히 만들어주지 않는 이상 확고한 길을 이어나가기는 어려울 것 같아서 먼저 그림을 그리는 작업은 필요하겠네요. 시간이 해결해 줄 수도 있고요.

🧑‍💻: 제가 젊었을 때는 잘 몰랐거든요. 나이를 먹으면서 시간이 지날수록 회사 입장에서 나를 써야 할 이유가 필요하잖아요. 나의 가치를 증명할 수 있는 위치도 필요할 거고 나만이 할 수 있는 일들이 필요한데, 다른 개발자분들보다 내세울만한 게 점점 없어진다는 생각도 들기는 해요. 솔직히 더 이상 이직을 못하겠다는 생각을 한 적도 있지만, 생각을 바꿔서 내가 이직을 한다면 그 사람들이 내게 어떤 역할을 기대할까? 생각하게 됐어요. 현황을 파악하고 조직을 세팅하고 개선하고 하는 부분들을 생각하다 보니 조금 알겠지만요. 그래도 사전과제나 코딩 테스트를 보는 건 좀 두렵더라고요.

채용할 때 내가 주목하는 부분

🧑‍💻: 최근에는 채용 전형에 참여하시나요? IT가 불황이라고 하는데 어떠세요? 채용 과정에서 어떤 식으로 하시는지도 궁금해요.

🧑‍💻: 저는 서류를 볼 때는 지원자들이 했던 것들을 쭉 보면서 업계 트렌드를 파악하게 되는 것 같아요. 계속 지켜보니 회사가 달라도 기술적인 부분은 전체적인 트렌드가 있더라고요. 2018년 초기에는 리액트를 쓰는 분이 별로 없었는데 이후에 많아졌다거나, Redux를 사용하거나 Next.js를 사용하는 방향 같은 부분이요.

🧑‍💻: 저는 면접을 많이 들어가면서 어떻게 하면 면접 준비 시간을 최소화할까 고민을 많이 했던 것 같아요. 그전에는 이력서나 과제를 보고 궁금한 부분을 모두 적어놓고 참여했는데, 면접 시간이 제한적이다 보니 막상 그 질문 리스트를 반도 활용하지 못하는 경우가 많더라고요. 그래서 저 나름대로 밸런스를 갖추기 위해 템플릿을 만들고 섹터별로 궁금한 질문을 2개씩 준비해서 최대한 골고루 물어볼 수 있도록 하고 있어요.

🧑‍💻: 작은 회사일수록 컬처핏을 좀 빡세게 보는 경우도 있는 것 같아요. 제가 전에 다녔던 회사는 16명 규모였지만 한 분을 5시간 동안 면접을 봤었거든요. 그래서 그런지 동료들이 다 다르긴 했지만 비슷한 결의 사람들로 모여있다는 생각이 들었어요.

참여 후기

🧑‍💻: 네, 아쉽게도 저희가 준비한 시간이 모두 지났습니다. 이야기를 들으면서 느낀 건, 일에 몰입하고 잘하는 것도 중요하지만 가끔은 이렇게 한 발자국 떨어져서 객관적으로 내가 하는 일을 바라보는 시간이 필요하다는 생각이 들었어요. 소감 한 마디씩만 부탁드릴게요!

🧑‍💻: 오늘 이 시간이 너무 좋았습니다. 저는 사실 컴퓨터학과 전공이 아니었다 보니 이런 개발 이야기를 편하게 나눌 사람이 없었는데요. 이 자리를 통해서 허심탄회하게 이야기를 나누었고 어디서도 경험할 수 없는 인사이트와 공감을 얻은 것 같아요!

🧑‍💻: 저는 리드 경험은 없는 시니어 개발자이지만 말은 되게 많이 한 것 같은데요. 내가 리딩을 하게 된다면 이런 부분들을 조심해야겠구나 하는 사전지식을 쌓고 예습하는 시간이었던 것 같습니다. 가르쳐 주셔서 감사해요. (웃음) 프론트엔드 개발 10년 차이지만 사실 저는 또래 개발자들을 만나본 적이 한 번도 없는 것 같아요. 아무래도 프론트엔드 개발이 나온 지 얼마 안 되어서 그런 것도 있을 것 같은데 그래서 이 자리가 더 소중했던 것 같습니다. 비슷한 연차의 분들이 비슷한 고민을 하고 있다는 게 참 신기했고, 이 자리에 오기 전에 해야 할 이야깃거리들을 다 풀지도 못해서 아쉽기도 합니다.

🧑‍💻: 이 세상에 진짜 나랑 같은 고민을 하는 사람이 어딘가에는 있다는 것만으로도 위안이 되는 것 같아요. 오늘 그런 공감대를 나누는 좋은 시간이었던 것 같아서 준비한 저희 입장에서도 기분이 좋은 마무리인 것 같습니다. 감사합니다!

마치며

아티클로 참여한 Paytalks with KREW: FE 내용 어떠셨나요?

현장에서는 치열한 토론과 의견 핑퐁을 통해 자극받는 신선한 시간이었는데요. 함께 참여했던 호스트로서 개인적인 소감을 나누자면, 같은 눈높이에 있는 분들이 고민을 털어놓고 정답을 강의하기보다는 다양한 의견과 입장이 함께 존중받는 시간이어서 더 의미 있었던 것 같아요. 이 글을 읽는 독자분들에게도 그런 울림이 전달되었으면 좋겠습니다.

앞으로 다양한 주제로 찾아뵐 Paytalks with KREW에 많은 관심 부탁드립니다!