“3년차 프론트엔드 엔지니어입니다. 이제 뭘 더 공부해야 할까요?”

‘웹 개발자’는 1990년대부터 있어왔지만 ‘프론트엔드 엔지니어’가 독립적인 직업군으로 불리게 된 것은 불과 10년도 채 안 됐다. 자바스크립트 생태계가 웹에 끼치는 영향이 급격히 커지고 UI/UX의 중요성도 훨씬 부각된 2010년대 중반부터 많은 조직에서 프론트엔드 엔지니어를 본격적으로 채용하기 시작했다.

이렇게 프론트엔드 개발의 역사가 짧다 보니, 다들 좋은 시니어 프론트엔드 엔지니어를 원하지만 찾기는 너무 힘들다(죄다 네카라쿠배토당야에 가있는 것 같다). 일단 뽑아서 키워보자는 생각으로 주니어를 채용한다. 주니어는 디자이너나 기획자가 건네준 화면 몇 개를 그리는 것으로 일을 시작한다. 수많은 용어와 프레임워크에 익숙해지는 것만도 벅찼던 주니어는 연차와 경험이 쌓이면서 슬슬 자신감이 붙는다. 디자이너와 기획자가 뭘 요구하든 검색하거나 라이브러리 쓰면 대부분 만들 수 있겠다고 생각한다. 그러나, 점점 자신감은 불안감으로 바뀐다.

• ‘어차피 해달라는 건 다 구현할 수 있겠는데 이제 뭘 더 공부해야 하지?’ (대부분의 스타트업에서 프론트엔드에 요구하는 기술 수준이 그다지 높지 않음)
• ‘내가 프론트엔드만으로 계속 먹고살 수 있을까? 주변 시니어들은 대부분 백엔드 출신이던데 나도 백엔드로 전업해야 하나?’ (프론트엔드 엔지니어 출신으로 좋은 커리어를 쌓은 롤모델이 주변에 별로 없음)
• ‘내 뒤에 들어온 주니어들을 이끌어주라는데, 과연 내가 잘 할 수 있을까?’ (조직 내 시니어 프론트엔드 엔지니어의 부재로 미들급에게 리더십이 더 많이 요구됨)

이 글은 이런 고민을 하는 프론트엔드 엔지니어와, 이들을 어떻게 이끌지 고민하는 팀 리드 및 CTO를 생각하며 썼다. 프론트엔드 엔지니어가 시니어로 나아가기 위해 어떤 역량을 쌓아야 하는지, 어떤 방향으로 전문성을 특화시켜야 할지, 그리고 향후 어떤 커리어를 쌓아나갈지에 대한 가이드로서 조금이나마 도움이 되길 기대한다.

1. 탁월한 엔지니어 되기

‘탁월한 시니어 프론트엔드 엔지니어가 되고 싶다’는 문장은 3가지 측면에서 해석할 수 있다.

• 탁월한 (시니어 프론트엔드) 엔지니어가 되고 싶다.
• 탁월한 (시니어) 프론트엔드 엔지니어가 되고 싶다.
• 탁월한 시니어 (프론트엔드) 엔지니어가 되고 싶다.

이중 첫번째가 가장 기본이며 가장 중요하다. 물론 모든 ‘기본’이 마찬가지겠지만 기본을 잘 하는 것도 무척 어렵다. 애초에 탁월한 엔지니어는 어떤 사람일까?

다음은 What Makes a Great Software Engineer?(Li Paul Luo 외, 2015년)라는 논문에 나오는 ‘탁월한 엔지니어의 5가지 주요 역량’을 요약하여 내 의견을 덧붙인 것이다. 올해 초에 작성한 뉴스레터와 개발자 채용 인터뷰 평가 템플릿에서도 공유한 바 있지만 재탕한다.

이 다섯 가지 역량을 쌓고자 지속적으로, 의식적으로 노력하는 사람이라면 비단 개발뿐 아니라 무슨 일을 하더라도 어디서나 환영받는 사람이 될 것이다.

여기에 하나 더하자면, 커뮤니케이션/글쓰기 능력의 중요성이 이전보다도 훨씬 커졌다. 최근 각광받는 ChatGPT를 비롯한 인공지능에게 본인의 일을 대체당하는 대신 인공지능을 비서로 삼아 내 일을 더 효과적으로 하기 위해서다. 위 5가지 역량을 잘 쌓은 사람이 커뮤니케이션을 못할리 없겠지만, Prompt Engineering 관점에서 영어 글쓰기나 인터뷰 기법에 대해 좀 더 공부한다면 유용하게 써먹을 수 있을 것이다.

2. 탁월한 프론트엔드 엔지니어 되기

위의 다섯 가지 기본 역량은 탁월한 엔지니어가 되기 위한 태도 또는 마음가짐에 가깝다. 주니어 입장에서는 현실적으로 어떤 노력을 해야 하는지 모호하게 느껴질 수 있다. 그래서 더 구체적으로 프론트엔드 엔지니어가 어떤 방향으로 전문성을 쌓으면 좋을지 세 가지 트랙을 생각해봤다.

트랙별 차이를 드러내기 위해 편의상 분리하여 설명해두었지만, 실제로는 대부분의 시니어 프론트엔드 엔지니어가 한 트랙만 끝까지 밟기보다는 세 트랙 모두에서 어느정도 역량을 갖췄을 확률이 높다. 각 트랙은 상호보완적이므로 한쪽의 전문성이 충분히 있는 사람은 다른 트랙의 전문성을 쌓기 훨씬 쉬워지며, 당연히 각 트랙에서 시니어로서 가능한 커리어도 일부 겹친다. (‘운영 트랙’은 데브옵스적 측면과 프로세스/조직 운영적인 측면 둘 다를 포함했으나, 이 두 가지 역량을 꼭 같이 가져가야만 좋은 커리어를 쌓는 건 아니다. ‘프로세스 특화’ 트랙을 별도로 둬야 할지 고민도 됐지만 4번째 트랙을 유의미하게 만들기에는 아직 나의 역량이 부족하여 일단 하나로 합쳤다.)

전문성 트랙 1: 웹 특화

웹 특화 프론트엔드 엔지니어는 웹 브라우저에 대한 깊은 이해를 가지고, HTML/CSS/JS라는 웹의 3대 구성 요소를 적재적소에 써먹는 사람들이다. 이들은 우리가 ‘개발자’라고 할 때 흔히 떠올리는 ‘특정 기술에 능통한 소프트웨어 엔지니어’에 가깝다.

웹 특화 트랙은 전문성을 키우기 위해 필요한 기술 및 키워드가 로드맵으로 잘 정리되어 있고, 인터넷상에 무료 강의를 비롯해 공부할 수 있는 컨텐츠도 많다. 그래서 어느 정도 레벨까지는 혼자 공부하거나 사이드 프로젝트를 진행하면서 역량 수준을 빠르게 끌어올리기 수월하다. 그러나 그 이상으로 올라가려면 뉴스레터를 구독(e.g., Korean FE Article)하고, 여러 동료와 협업하고, 오픈소스 커뮤니티에 참여하고, 생태계를 이루는 도구들의 소스코드와 릴리즈 노트를 후벼파고, 신기술의 동향을 파악하며 직접 시험해보는 등 꾸준한 노력이 필요하다.

웹 전문가는 도구를 사용하는 데 만족하지 않고 그 동작 원리를 삽질해가며 파악하는 데서 재미를 느낀다. 제품의 복잡도가 올라가서 온갖 환경에서 트러블슈팅을 해야 하거나, 서비스가 어느정도 궤도에 올라 프론트엔드의 성능을 끌어올려야 할 때 이들의 이러한 지식과 삽질 경험이 빛을 발한다. 즉 웹 전문가들은 제품이 성숙해질수록 더 필요해지고, 더 큰 임팩트를 낼 수 있다.

이는 초기 스타트업에서 이들의 특화된 전문성이 인정받기 쉽지 않다는 뜻이기도 하다. 제품을 시장에 내놓고 핏을 찾을 때까지 고군분투하는 시기에는 대부분의 제품에서 필요한 웹 기술의 수준이 그리 높지 않기 때문이다. 나는 웹 기술이 부족해서 시장에서 성공하지 못하는 케이스도, 탁월한 웹 기술만으로 시장에서 성공한 케이스도 많이 접하지 못했다. 물론 웹 전문가가 있다면 당연히 어느 조직에서나 큰 도움이 되겠지만, 초기 스타트업에서 이들의 전문성을 필요로 할 만한 사건이 자주 일어나지는 않을 것이다.

그러면 웹 특화 전문성을 쌓은 프론트 엔지니어는 이후 어떤 커리어를 밟아나갈 수 있을까? 우선 웹 전문가들은 웹 생태계 구성 도구를 직접 만드는 회사(e.g., Vercel, Remix, Chromatic)에 합류하거나, 본인의 전문성을 바탕으로 강의를 만들어서 교육하는 등 유니크한 기회를 만들 가능성이 있다.

• react-router를 만들고 React 교육 사이트를 운영하다가 Remix를 회사로 만든 Ryan Florence
• testing-library를 만들고 여러 교육 사이트(Testing Javascript, Epic React)를 운영하고 있는 Kent C. Dodds
• Gatsby와 Khan Academy 등에서 일하다가 CSS 전문가로서 훌륭한 강의(CSS for Javascript Developer)를 만들어 운영하고 있는 Josh W Comeau
• 본인의 이름을 따서 만든 TanStack Query를 운영하다가 react-query 강의도 오픈한 Tanner Linsley
• Babel을 대체하는 Rust 기반 컴파일러 swc를 만들어 운영하다가 Vercel에 합류한 강동윤님

역량이 개인 강의를 운영할 수준까지는 아니더라도, 복잡하고 성숙한 제품을 가진 조직에는 웹 전문가가 들어갈 자리가 충분히 존재한다. 경험상 엔지니어링 팀의 크기가 두자릿수를 넘길 때부터는 개발자 10명당 최소 1명 정도는 웹 전문가가 있어야 서비스의 품질 및 성능을 잘 끌어올릴 수 있다고 보기 때문이다. 매니저 역할에도 관심이 있는 엔지니어라면 그러한 조직의 테크 리드 자리도 노려볼 수 있다.

전문성 트랙 2: 제품 특화

제품 특화 프론트엔드 엔지니어는 제품을 시장에 내놓아서 성공시키기까지 필요한 일이라면 무엇이든지 할 수 있는 사람들이다. 이들은 스스로를 ‘프로덕 엔지니어’로 소개하는 것을 선호하며, 프론트엔드 기술은 제품을 성공시키기 위해 그들이 쓸 수 있는 유용한 도구 중 하나다. 웹 특화 엔지니어와 다르게 각 도구의 근본 작동 원리보다는 ‘그래서 언제 무엇을 어떻게 쓰는 게 좋은가?’에 관심이 더 많다.

제품 전문가는 아직 시장으로부터 충분한 반응을 얻지 못한 초기 스타트업에서 가장 환영받는 유형의 엔지니어다. 적절한 가설을 설정하고 빈번하게 실험하면서 초기 제품에 유의미한 변화를 만들어내려면 높은 수준의 기술보다는 고객/시장에 대한 이해와 프로덕 센스가 더 중요한데, 제품 특화 프론트엔드 엔지니어가 바로 그런 센스를 갖춘 사람들이기 때문이다. 이들은 코딩도 좋아하지만 코딩 없이 문제를 빠르게 해결하는 걸 더 좋아한다(노코드/로우코드 도구를 사용하든, 미팅을 통해 스펙을 줄이든). 자신의 기여로 UI/UX가 더 좋게 변하고, 제품 지표가 개선되는 걸 보면서 희열을 느낀다.

제품 특화 트랙을 밟고자 하는 엔지니어는 두 가지 함정에 빠지지 않도록 주의해야 한다. 첫번째는 PM이나 디자이너가 기획해준 작업을 맥락 파악(e.g., 어떤 고객의 어떤 문제를 풀기 위한 작업인가? 그 문제는 얼마나 시급하고 얼마나 중요한가?) 없이 그저 빠르게 수행하려는 태도다. 제품 특화 엔지니어가 임팩트를 내려면 단순히 빠르게 구현만 할 게 아니라, ‘고객이 원하는 가치를 가장 적절한 형태로 빠르게 전달’하는 데 집중해야 한다. 따라서 언제나 이 기능이 어떤 고객의 어떤 중요한 문제를 푸는 것인지 고민하며 의사소통하는 게 좋다.

엔지니어가 전달받은 대로 구현만 한다면 첫 버전 배포는 빠를지도 모르지만, 고객이 별로 원하지 않는 제품을 전달했다거나, 유저플로우상 듬성듬성 빠진 케이스가 있다거나 하는 이유로 큰 효용을 못 보고 둘째 버전을 금방 만들어야 할 수도 있다. 때로는 제공하려는 핵심가치와 상관없는 곳에 오버엔지니어링(e.g., 처음 만들어보는 패턴으로 CSS 애니메이션을 구현해야 해서 오래 삽질했는데 알고보니 꼭 그렇게 안해도 됐었다거나)해서 첫 버전 배포조차 느려질 위험도 있다.

두번째는 너무 오랫동안 안전한 공간에만 머물러있으면서 역량 강화에 소홀해지는 것이다. 제품 특화 엔지니어는 문제가 주어졌을 때 본인에게 가장 익숙한 도구의 조합으로 최대한 신속하게 구현하려는 경향이 있다. 하지만 그 도구가 현 시점에 그 문제를 풀기에 가장 적합한 도구라는 보장은 없다. 학습 비용을 감수하고라도 때론 새로운 CSS 문법, 새로운 UI 프레임워크, 새로운 노코드 도구 등을 익히며 공구상자를 업데이트하는 게 장기적으로 이득이다.

또한 트래픽이 늘어나고, 조직규모가 커지고, 비즈니스 로직이 복잡해진다면 제품 특화 엔지니어가 슈퍼스타처럼 만들었던 구조와 코드를 대폭 뜯어고쳐야 할 일이 반드시 생긴다. 만약 이런 변화에 적응하지 못하고 ‘의도대로 작동하나 가독성이 나쁘고 유지보수하기 어려운 코드’나 ‘조직 내에서 본인만 잘 쓰는 도구 및 프레임워크’로만 계속 일한다면, 동료들로부터 협업하기 어렵다는 평가를 받으며 자신이 키워놓은 제품 조직에서 불명예스럽게 떠나 또다른 초기 스타트업으로 이동해야 할지도 모른다. 물론 초기 스타트업의 제품을 시장에 인정받을 수준까지 만들어내는 건 굉장히 특별한 역량이지만, 엔지니어로서의 기본 역량을 탄탄하게 유지하도록 노력해서 손해볼 리는 없다.

제품 특화 프론트엔드 엔지니어는 제품을 시장에 안착시키고자 하는 모든 조직에서 환영받으니, 테크 리드를 비롯한 시니어 엔지니어로서 커리어를 지속하기 쉽다. 그러나 꼭 프론트엔드 엔지니어가 아니더라도 다른 여러 역할도 충분히 수행할 수 있다. 그로스 컨설팅 조직에서 그로스 엔지니어나 컨설턴트로 일할 수도 있고, 엔지니어링 배경을 가진 채 PM/PO가 되면 엔지니어들과의 의사소통이나 적정기술 선택 등에서 아주 수월해지므로 이쪽으로 전업하여 CPO까지도 나아갈 수도 있다. 제품의 구현자들(PM, 디자이너, 동료 백엔드 개발자 등)과 좋은 협력관계를 유지하면서 영향력을 끼쳐야 할 일도 많으니 협력과 관리 역량을 강화하여 테크니컬 프로그램 매니저를 맡는 것도 가능하다고 본다.

전문성 트랙 3: 운영 특화

‘운영 특화’ 프론트엔드 엔지니어는 효과적으로 제품과 조직을 운영하는 데 필요한 여러 도구와 프로세스를 이용할 줄 아는 사람들이다. 이들은 백엔드/인프라/데브옵스/아키텍처/조직관리 등 여러 방면으로 관심을 가지고 역량을 쌓아, 프론트엔드 엔지니어라기보다는 ‘데브옵스 엔지니어’나 ‘풀 스택 엔지니어’로 불리는 일도 잦다.

운영 특화 트랙에 필요한 전문성은 책을 읽거나 사이드 프로젝트를 수행하는 정도로는 발전시키기 어렵다. 큰 회사들이 여러 블로그 글을 통해 공개해둔 운영 방식을 읽어보거나, 다른 회사 지인들의 운영 방식/도구/프로세스를 접하는 것도 많은 도움이 되지만 그 외형을 따오기보다는 본인 조직에 맞게 고칠 줄 알아야 한다. 결국 운영 전문성은 대부분 현장에서 얻게 되는데, 일부러 ‘나는 운영 전문성을 키워야지’라고 결심해서 이것저것 공부하기보다는 제품과 조직이 성장함으로써 만나는 문제를 몸으로 해결하면서 ‘필요하니까’ 체득하곤 한다. 예를 들어:

• 어설프게 만들었던 서비스에 트래픽이 갑자기 폭발해서 생긴 장애에 대응하면서
• 사람 손으로 때워가며 서비스를 운영하다가 생기는 실수와 잃는 시간을 더이상 감당하기 어려워 자동화하면서
• 조직 규모가 커지고 스테이크홀더가 많아지며 눈에 띄게 길어진 제품 리드 타임을 줄이기 위해 여러가지 장치와 도구를 도입하면서

내가 아는 운영 특화 엔지니어 중에는 책임감이 높고 눈치가 빠른 사람들이 많다. 서비스가 커지고 조직 규모가 커지면 반드시 어딘가에 빈틈과 비효율이 생기기 마련인데 이들은 그런 빈틈을 기꺼이 메우며 윤활유 역할을 해준다. 이런 Glue Work를 도맡아 하는 분들은 자연스럽게 업무 커버리지가 넓어지며 많은 사람들을 돕게 되는데, 정작 본인이 원래 맡았던 기술적 업무에 쏟을 시간이 부족해져 역량에 깊이를 더하지 못하거나 좋은 성과평가를 받지 못할 위험이 있으니 주의해야 한다. 그래서 운영 특화 엔지니어는 본인이 하는 일의 가치를 인정받고 근본적 개선 및 역량 강화를 위한 시간을 확보받기 위해 관리자에게 셀프 PR을 꾸준히 할 필요가 있다.

운영 전문가도 웹 전문가처럼 소규모 스타트업에서는 전문성을 인정받기 어려울지도 모른다. 그러나 조직이 커지고 신규 기능 개발보다는 유지보수 및 운영 업무에 들이는 시간이 많아질수록 운영 특화 엔지니어의 유무가 전체 생산성에 미치는 영향이 커질 것이다. 또한 조직 규모가 작더라도, 그저 운영 업무를 수행하는 수준이 아니라 일을 더 효과적으로 하기 위한 자동화 경험과 프로세스 구축 경험, 다양한 역할의 동료들과 긴밀하게 협업한 경험이 있는 사람이라면 CTO와 같은 중요한 역할을 맡을 수도 있다. 스타트업 초기에는 구성원 한명 한명이 제너럴리스트로서 여러가지 역할을 해야 하는데, 온갖 기술적 업무를 운영 전문가가 커버하며 문제를 해결해줄 수 있기 때문이다.

운영 전문가는 넓은 커버리지와 더불어 기술역량을 꾸준히 높여나가면서, 테크 리드는 물론이고 제품이 다양하고 조직 규모가 큰 회사의 공통 파트를 다루는(대개 ‘플랫폼 팀’이라고 불리는) 곳에서 커리어를 밟을 수 있다. 만약 많은 사람들과 소통하고 영향력을 발휘하여 여러 팀을 변화시키는 쪽에 흥미가 생겼다면 애자일 코치나 테크니컬 프로그램 매니저 역할로 직무를 전환할 수도 있다. 이 방향에서는 소프트웨어 관리, 조직 관리에 대한 좋은 책들을 읽고 적용해보는 것도 도움이 될 것이다(e.g., Quality Software Management, 테크니컬 리더, 클린 애자일, 매니지먼트 3.0 등).

3. 탁월한 시니어 엔지니어 되기

위와 같이 전문성을 쌓은 사람이 탁월한 시니어 엔지니어로 성장하려면 어떻게 해야 할까? 좋은 시니어의 조건에 대해서는 사람들마다 의견이 갈릴 것이고, 나 또한 아직 미숙한지라 명료하게 정리하기는 어렵다. 간단하게 나는 어떻게 시니어 역할을 맡게 됐는지, 또 내가 만나왔던 훌륭한 시니어 엔지니어들은 어떤 사람이었는지를 토대로 탁월한 시니어 엔지니어가 되기 위한 세 가지 포인트 정도만 뽑아본다.

기본에 충실하고자 노력한다

처음에 언급한 ‘탁월한 엔지니어의 5가지 역량’은 당연히 시니어 엔지니어에게도 똑같이 적용된다. 좋은 코드를 짜고, 작업의 가치를 극대화하고, 데이터에 기반하여 의사결정하고, 동료의 효과적 의사결정을 돕고, 꾸준히 학습하는 걸 지속한다면 좋은 시니어가 될 가능성이 높아진다.

명시적 리더가 아니더라도 리더처럼 행동한다

나는 짧게나마 창업을 해본 다음 직장에 들어가서였는지 NBT에서 1년차 엔지니어였을 때도 스스로 주니어라는 자각이 딱히 없었다. 내가 여길 건드려도 괜찮나, 이렇게 목소리를 높여도 괜찮나 같은 자기검열 없이 빨빨거리며 돌아다녔다. 운좋게도 날 특별히 제지하는 사람이 없는 좋은 문화를 가진 팀이었고, 실제로 구체적인 성과도 몇 차례 있었다 보니(e.g., 팀 내 페어 프로그래밍이 더 잦아지고, Ruby 스타일 가이드를 팀 전체가 더 잘 따르게 되고, 피크타임 기준 주요 API 응답시간이 절반 이하로 낮아짐) 언젠가부터 다들 나를 시니어처럼 취급했다.

리더십은 명시적 리더가 아닐 때도 충분히 발휘할 수 있고, 때론 동료의 모범적 행동 하나가 명시적 리더의 수많은 말보다 더 큰 영향을 끼칠 수 있다. 엔지니어링 레벨을 빡빡하게 평가하는 걸로 유명한 구글에서는, ‘상위 레벨의 역할을 잘 할 것 같은 사람’을 승진시키는 게 아니라 ‘이미 상위 레벨의 역할을 일정 기간 이상 충분히 수행하고 있었던 사람’의 노고를 인정해주는 차원에서 승진시킨다고 한다. 본인에게 주어진 역할과 상관없이 제품에, 팀에, 조직 전체에 긍정적 영향을 미치고자 힘쓰다 보면 어느새 모두로부터 시니어로 인정받으리라 본다.

어떤 상황에서든 큰 임팩트를 낸다

버그가 생겼을 때 주니어는 보통 그 현상만 고치지만 시니어는 다각적으로 문제를 해결한다. 버그의 근본 원인을 파악하고, 비슷한 버그가 다른 곳에 존재하진 않는지 확인하고, 운영환경별로 다르게 적용할 만한 예외 케이스는 없는지 살피고, 다음에 비슷한 버그가 생기기 어렵도록 개발환경을 개선(린터 룰 추가, 테스트 추가, 구조 변경 등)하고, 만약 생기더라도 일찍 인지할 수 있는 장치를 추가한다. 이 모든 걸 혼자 하는 게 아니라 동료들과 의사소통하고 위임하여 함께 해결함으로써 조직 전체의 역량을 높인다.

이렇듯 디버그라는 작은 행위에서도 시니어는 주니어보다 훨씬 큰 영향력을 발휘한다. 사실 조직 내에서 큰 책임의 기회는 자주 오지 않는다. 어쩌다보니 덜컥 막중한 책임을 맡아버렸는데 잘 해내는 사람도 있겠지만, 보통은 작은 일을 맡아도 큰 임팩트를 만드는 사람들이 이후 더 큰 일을 맡는다. 이는 ‘명시적 리더가 아니더라도 리더처럼 행동’하는 것과 비슷하다. 주어진 일을 잘 끝마치는 걸로 만족하지 않고, 전후 맥락을 살피며 여러 사람과 의사소통하여 큰 영향력을 미치는 사람에게는 더 큰 책임과 권한이 주어진다. 이런 사람들은 제품에서든, 팀에서든, 회사에서든 어느 한 파트를 안심하고 맡길 수 있는 시니어로 성장할 것이다.