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


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


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


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


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


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


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


====


어떻게 생각핢?

나도 예전부터 프엔은 코드베이스 복잡도를 관리하고 백엔은 한두가지의 big idea에 집중하지 코드는 의외로 단순할 거라고 생각했는데 몬가몬가 비슷해서 싱긔하네