프론트엔드 출신의 CTO는 왜 없을까

CTO 전부 백엔드 출신인 건 아니겠지만, 당장 떠오르는 CTO분들을 나열해 봐도 대부분 백엔드가 주를 이룬다.

사실 이러한 사실에 대해 당연히 알고는 있었지만 왜 프론트엔드 출신의 CTO는 없을까라는 고민을 해본 적이 없었다.

 

그런데 동료 개발자가 뱅크샐러드의 공동창업자 황성현님의 글을 공유해 줬고, 그 글을 읽으며 다양한 생각을 하게 되었다.

 

---

 

예전에 개발자들끼리의 술자리에서 "프론트엔드 출신의 CTO는 왜 없을까?"에 대해 얘기를 나눈 적이 있는데 (정말로 그런지는 모르겠지만) 당시에는 "그러게요 희한하네" 정도로 넘어갔는데, 요즘 들어 드는 생각은 프론트엔드와 백엔드 각자가 집중하는 문제 해결 방향이 달라서 그런가 싶다.

 

(논란이 있겠지만) 내 경험상 보통 백엔드의 경우, 코드 자체는 단순하다. 왜 그럴까? 생각해 보면 (1) 기본적으로 stateless라 복잡도가 낮고 (2) 많은 회사의 코드가 마이크로서비스로 되어있어 하나의 거대하고 복잡한 도메인이 잘 없고 (3) 어차피 많은 경우 RPC 하나를 만드는 거라 인풋과 아웃풋을 잘 정의하면 끝이고, 대부분의 경우 이 인풋과 아웃풋은 아주 잘 정의되어 있다.

 

반면에 프론트엔드의 경우 웹과 모바일 둘 다를 포함하여 생각할 때 (1) 기본적으로 state와의 싸움이고 (2) 마이크로서비스처럼 관심사를 코드베이스 차원에서 분리하는 방법은 있으나 보통 백엔드의 경우처럼 극적으로 코드가 줄지는 않고 (3) 사용자의 인풋과 사용자에게 보여줄 아웃풋이라는, 아주 넓게 정의된 인풋과 아웃풋을 다뤄야 한다.

 

그래서 백엔드는 코드 자체의 복잡도를 낮추는—예를 들어, 더 좋은 코드가 무엇인가? 더 좋은 코드베이스 구조가 무엇인가?—접근에는 큰 관심이 없다. 그냥 좀 코드가 길다 싶으면 일부 함수로 잘 리팩토링만 하면 된다. 그보다는 시스템의 복잡도에 더 집중한다. DB 구조를 어떻게 가져갈 것인가, 인덱스를 어떻게 설계할 것인가, 캐시를 어디에 둘 것인가, 큐를 어디에 어떻게 둘 것인가 등등. 그래서 보통 백엔드에서의 "어려운" 작업은 시스템을 설계하는 일이다.

 

반면에 프론트엔드는 코드 자체의 복잡도를 낮추는 일에 집중하게 된다. 특히 모바일 진영에서 '클린 아키텍처'가 괜히 오래도록 유행인 게 아니다. 코드베이스 자체의 복잡도가 워낙 크기 때문에 그렇다. 또한 주된 "어려운" 작업은 복잡한 상태를 다루는 일이다. 그래서 상태 관리를 어떻게 할 것인가에 대한 논의가 여전히 활발하고, 최대한 복잡도를 낮추기 위해 명시적 프로그래밍과 함수형 프로그래밍에 대한 관심이 백엔드에 비해 더 큰 편이다.

 

백엔드 출신 CTO가 더 많은 이유는 여기에 있지 않을까? 회사에서 해결해야 하는 대부분의 문제는 좋은 '코드'보다는 좋은 '시스템'이 필요하기 때문이다. 물론 내 경험상 둘 다 힘든 일이고, 무엇이 더 어렵다고 말하기는 어려우나 어디까지나 CTO가 해야 하는 일들의 속성을 따져볼 때 그럴 가능성이 높다는 얘기다.

 

번외로 이런 관점에서 볼 때 백엔드 개발에서 시스템적인 사고를 하지 않고, 자꾸 코드베이스 레벨에서 해결하려고 한다면 대체로 안 좋을 가능성이 높다고 생각한다. 예를 들어 주기적으로 무언가를 실행할 일이 있을 때 그냥 본인이 사용하는 백엔드 프레임워크 + cron job이 붙은 플러그인으로 해결하려고 한다거나... 백엔드 개발자에게는 코드 레벨의 관심사 분리만큼이나 시스템 레벨에서 관심사의 분리가 무엇보다 중요하다. 보통 이런 사고를 할 수 있냐 없냐가 이 사람에게 맡길 수 있는 복잡도의 크기를 결정하곤 한다.

---

대부분의 말에 공감을 하지만 가장 공감이 가는 부분 아래와 같다.

 

프론트엔드는 코드 자체가 복잡하기 때문에 코드 자체의 복잡도를 낮추는 일에 집중하게 되고,

백엔드는 시스템의 복잡도를 낮추는 일에 집중한다는 점이다.

 

하나의 피쳐를 만들 때 프론트의 커밋과 백의 커밋을 비교해 보면 수정되는 프론트의 코드가 압도적으로 많다.

그 이유로는 위에 적힌대로 코드 자체가 복잡한 일이 많고, 상대적으로 가져가는 보일러플레이트 코드도 많았다.

 

그렇기 때문에 백엔드 엔지니어는 상대적으로 시스템의 복잡도를 낮추는 업무를 하는 비율이 많고 이는 CTO가 해야 하는 의사결정에 도움을 주는 것도 공감을 한다.

 

하지만 내가 생각하는 현재 프론트엔드 출신의 CTO 수가 적은 가장 큰 이유는 다른 곳에 있다고 생각한다.

 

이전에는 프론트엔드는 그저 백엔드를 표현하는 수단에 불과했다고 생각한다.

그렇기 때문에 백엔드 출신의 엔지니어가 프론트엔드 개발에 필요한 의사결정을 하는 데에 있어 크게 어렵지 않았을 것이라고 생각한다.

 

하지만 최근에는 Server Action, Server Components와 같은 개념까지 나오면서 프론트엔드 중심의 아키텍처를 구성할 수 있게 되었다.

이에 맞춰 나를 포함한 많은 프론트엔드 개발자들은 단순한 마크업만이 아닌 프론트엔드 중심의 웹 아키텍처에 대한 연구부터 서버 동작까지 공부를 하게 되었다.

 

그래도 대기업은 프론트엔드 개발에 대한 의사 결정을 도와줄 사람이 많기도 하고,

더 안정적인 시스템이 필요하기 때문에 백엔드 출신의 CTO가 주를 이룰 것이라고 생각한다.

 

하지만, 내 개인적인 생각으로는 스타트업에서는 점차 프론트엔드 출신의 CTO 수가 늘어날 것이라고 생각한다.

 

스타트업에서 필요한 개발 능력은 다양하겠지만 그 중 가장 중요한 능력은 MVP를 만들어내는 속도라고 생각하는데,

프론트엔드 중심의 아키텍처는 MVP를 빠르게 만들어낼 수 있다는 장점이 있기 때문이다.

이런 아키텍처가 보편화된다면 프론트엔드 출신의 CTO는 점점 많아질 것이라고 생각한다.