프론트엔드 엔지니어 커리어의 천장
웹 프론트엔드 엔지니어의 커리어에 한계가 있다는 주장. 주로 제시되는 근거는 업계에 프론트엔드 엔지니어 출신 CTO가 없다는 것이다.
소프트웨어 엔지니어의 분류를 백엔드와 프론트엔드로 분류하는 것이 적절한지 의문이다. 프론트엔드와 백엔드의 구분이 이렇게 주류가 된 건 어떻게 보면 웹 개발에서 관심사의 분리가 중요해진 이후의 일이다. 심지어 프론트엔드 개발자, 백엔드 개발자라고 불리는 이들이 업무에서 웹만 다루는 것도 아니다. 나는 이제 프론트엔드 개발자와 백엔드 개발자가 아닌, 프로덕트 개발자와 플랫폼 개발자로 구분하는 것이 더 적절하다고 생각한다.
내 첫 직장의 CTO를 생각해보면 백엔드 엔지니어인지, 프론트엔드 엔지니어인지 나눌 수 없는 소프트웨어 언지니어였다. 대학원에서 데이터베이스를 전공했고, 피쳐폰의 GUI를 개발하는 엔지니어로 일했다. Mithril.js 컨트리뷰터인 동시에 직접 개발한 ORM 프로젝트를 메인테이닝하기도 했다.
오피니언
@황성현 예전에 개발자들끼리의 술자리에서 "프론트엔드 출신의 CTO는 왜 없을까?"에 대해 얘기를 나눈 적이 있는데 (정말로 그런지는 모르겠지만) 당시에는 “그러게요 희한하네” 정도로 넘어갔는데, 요즘 들어 드는 생각은 프론트엔드와 백엔드 각자가 집중하는 문제 해결 방향이 달라서 그런가 싶다.
(논란이 있겠지만) 내 경험상 보통 백엔드의 경우, 코드 자체는 단순하다. 왜 그럴까? 생각해 보면 (1) 기본적으로 stateless라 복잡도가 낮고 (2) 많은 회사의 코드가 마이크로서비스로 되어있어 하나의 거대하고 복잡한 도메인이 잘 없고 (3) 어차피 많은 경우 RPC 하나를 만드는 거라 인풋과 아웃풋을 잘 정의하면 끝이고, 대부분의 경우 이 인풋과 아웃풋은 아주 잘 정의되어 있다.
반면에 프론트엔드의 경우 웹과 모바일 둘 다를 포함하여 생각할 때 (1) 기본적으로 state와의 싸움이고 (2) 마이크로서비스처럼 관심사를 코드베이스 차원에서 분리하는 방법은 있으나 보통 백엔드의 경우처럼 극적으로 코드가 줄지는 않고 (3) 사용자의 인풋과 사용자에게 보여줄 아웃풋이라는, 아주 넓게 정의된 인풋과 아웃풋을 다뤄야 한다.
그래서 백엔드는 코드 자체의 복잡도를 낮추는—예를 들어, 더 좋은 코드가 무엇인가? 더 좋은 코드베이스 구조가 무엇인가?—접근에는 큰 관심이 없다. 그냥 좀 코드가 길다 싶으면 일부 함수로 잘 리팩토링만 하면 된다. 그보다는 시스템의 복잡도에 더 집중한다. DB 구조를 어떻게 가져갈 것인가, 인덱스를 어떻게 설계할 것인가, 캐시를 어디에 둘 것인가, 큐를 어디에 어떻게 둘 것인가 등등. 그래서 보통 백엔드에서의 “어려운” 작업은 시스템을 설계하는 일이다.
반면에 프론트엔드는 코드 자체의 복잡도를 낮추는 일에 집중하게 된다. 특히 모바일 진영에서 '클린 아키텍처’가 괜히 오래도록 유행인 게 아니다. 코드베이스 자체의 복잡도가 워낙 크기 때문에 그렇다. 또한 주된 “어려운” 작업은 복잡한 상태를 다루는 일이다. 그래서 상태 관리를 어떻게 할 것인가에 대한 논의가 여전히 활발하고, 최대한 복잡도를 낮추기 위해 명시적 프로그래밍과 함수형 프로그래밍에 대한 관심이 백엔드에 비해 더 큰 편이다.
백엔드 출신 CTO가 더 많은 이유는 여기에 있지 않을까? 회사에서 해결해야 하는 대부분의 문제는 좋은 '코드’보다는 좋은 '시스템’이 필요하기 때문이다. 물론 내 경험상 둘 다 힘든 일이고, 무엇이 더 어렵다고 말하기는 어려우나 어디까지나 CTO가 해야 하는 일들의 속성을 따져볼 때 그럴 가능성이 높다는 얘기다.
번외로 이런 관점에서 볼 때 백엔드 개발에서 시스템적인 사고를 하지 않고, 자꾸 코드베이스 레벨에서 해결하려고 한다면 대체로 안 좋을 가능성이 높다고 생각한다. 예를 들어 주기적으로 무언가를 실행할 일이 있을 때 그냥 본인이 사용하는 백엔드 프레임워크 + cron job이 붙은 플러그인으로 해결하려고 한다거나… 백엔드 개발자에게는 코드 레벨의 관심사 분리만큼이나 시스템 레벨에서 관심사의 분리가 무엇보다 중요하다. 보통 이런 사고를 할 수 있냐 없냐가 이 사람에게 맡길 수 있는 복잡도의 크기를 결정하곤 한다.
@Dianiel Young Lee 저도 "프론트엔드 개발자의 천장"에 대해 생각해보니 개발자 출신의 고위직 인사 중 프론트엔드 출신이 적다는 걸 느꼈습니다. 프론트엔드 개발이 최근에야 세분화되고 발전했기 때문에 고위직에 프론트엔드 출신이 적은 것은 어느 정도 당연하지만, 승진은 회사에 대한 기여도에 ($$) 따라 결정되며, 아직까지 대부분의 회사에서 백엔드 개발자의 프로젝트들이 이 기여도를 관측하기가 더 쉽지 않나 생각이 듭니다.
@인호준 프론트엔드 개발자는 진입장벽이 낮지만 고점이 낮은 직군으로 알려져 있습니다. 고점이 낮다는 이 말을 수도없이 들었고 항상 부정해왔는데, 요즘들어 왜 그런지 체감하고 있습니다.
군 장교들의 진급의 비밀에 대해 아시나요? 장교들에게는 병과와 직능이라는게 있습니다. 가령 장교 A는 병과로 보병을 택하고 직능을 작전을 선택할 수 있습니다. 장교 B는 병과로 포병을 정하고 인사 직능을 가질 수 있어요. 작전 직능 보병 장교는 조직 내에서 중요와 기여도가 가장 높습니다. 그만큼 일이 힘들고 책임이 중합니다. 그래서 잘만 하면 최고 계급(4스타)까지 갈 수 있죠. 반면 같은 퍼포먼스를 내는 인사직능 포병장교는 잘해봐야 대령이나 1스타입니다.
프론트엔드 출신 CTO가 드문 이유도 이와 비슷합니다. 줄을 잘 서야한다는 뜻이 아니라, 똑같이 일을 열심히 하더라도 조직에서 중요한 역할을 맡는 사람이 위로 올라가는게 이치니까요. 치기어린 마음에 나도 할 수 있다고 생각하던 시절이 있었는데, 지금 생각해보니 왜 없는지 이해가 약간 갑니다.
당신이 말하는 프론트 개발자는 그냥 API로 데이터 받아서 뿌려주기만 하는 피쳐개발만 담당하는 부류의 개발자 아니냐고. 뭐 틀린 말은 아닙니다. 왜냐면 생각보다 우리 직종이 할 일이 많습니다. 열악한 환경 속에서도 안전하고 성능좋은 웹문서를 빠르게 개발해서 서빙할 수 있는 실력좋은 개발자는 몇 안됩니다. 설계, 보안, 문서화, 성능, SEO, 자동화, 개발자 경험 등 솔직히 파고들면 깊게 파고들 수 있고, 제품 개발 및 보완 단계에서 다양한 의견을 통해 더 나은 제품을 만들어나가는데 얼마든지 일조할 수 있습니다.
하지만 아무리 그러한 종류의 개발을 쉽고 빠르게 한다고 해도 그것이 오롯이 프론트엔드 개발자의 성과로 이어지기는 힘듭니다. 비즈니스 로직과 도메인 지식과 직접적인 관련이 없기 때문이에요. 저희가 어떤 설계를 하진 않으니까요.
그리고 어느정도 그러한 인식이 업계 전반에 깔려있다고 생각합니다. 도메인 지식과 크게 엮여있는 백엔드나 회사 IT제품의 존속을 결정하는 인프라 개발자보다 프론트엔드 개발자는 의존성이 낮습니다. 인력 풀도 계속 공급되고, AI도 치고 올라오고 있습니다.