‘프론트엔드냐, 백엔드냐’를 고민하는 당신에게

프론트엔드를 해야 할지 백엔드를 해야 할지 모르겠어요.

개발을 막 시작하거나 몇 년 지나지 않은 주니어 개발자들과 대화를 하다 보면 심심치 않게 듣는 말이다. 그렇다고 꼭 경험이 적은 개발자만의 고민은 아니다. 경력이 많은 개발자들도 종종 이런 고민을 토로한다.

지금은 4차 산업혁명 이후에 ‘뷰카(VUCA) 시대’라고 한다. 뷰카는 변동성(Volatility), 불확실성(Uncertainty), 복잡성(Complexity), 모호성(Ambiguity)의 영문 머리글자를 따 만들어진 말이며, 뷰카시대는 변동적이고 불확실하고 복잡하고 모호해 예측이 어려운 사회, 경제적 환경을 뜻한다*. 극단의 불확실성과 예측이 어려운 사회에서 기술은 하루가 멀다고 쏟아져 나온다.

*뷰카 시대의 개발자가 궁금하다면 ‘변동성의 시대를 살아가는 엔지니어의 자세’ 글을 참고하라.

프랑스 철학자 장 폴 사르트르는 “인생은 BCD이다”라고 말했다. 태어나서(Birth) 죽는(Death) 순간까지 끊임없이 선택(Choice)하며 산다는 뜻이다. 삶은 선택의 연속이다. 그렇다면 어떻게 해야 더 나은 선택을 할 수 있을까?

이 글에서는 선택의 문제에 대해 말하고자 한다.

왜 고민하게 될까

먼저 왜 프론트엔드와 백엔드를 고민하게 되는지 생각해 보자. 물론 각자의 내면을 내가 알 수는 없는 일이다. 하지만 모든 것을 내면의 문제로 치부할 수도 없다. 사람은 상황에 영향을 받기 때문이다. 그렇다면 우리를 둘러싼 상황은 어떻게 변했을까?

내가 개발을 시작했을 즘(2007년)에는 프론트엔드니 백엔드니 하는 말은 없었으며 굳이 비슷한 말을 찾자면 클라이언트/서버 프로그래밍 정도였다. 하지만 시대는 바뀌었으며 <요즘 IT>에 발행된 ‘시니어 개발자가 말하는, 프론트엔드 역사와 미래’ 글을 보면 메타(Meta)에서 만든 리액트(React)를 기점으로 프론트엔드 생태계가 폭발적으로 성장했다는 것을 알 수 있다.

이렇게 웹 개발은 인프라의 확장, 데이터의 처리, 화면의 개발 각각의 분야에서 기존의 방식과는 다른 방식이 필요하게 되었습니다. 거대 성장을 해버린 웹 산업에서 웹 개발 영역에서 본격적으로 프론트엔드가 분리가 되는 순간을 맞게 됩니다.

요즘은 논리적으로 하나인 시스템을 물리적으로 프론트엔드와 백엔드로 나눠 개발하는 것이 일반적이다. 그에 따라 개발 회사들은 프론트엔드 개발자와 백엔드 개발자를 구분하여 모집한다.

앞서 말했듯 사람은 상황에 영향을 받는다. 나는 프론트엔드 생태계의 폭발적인 성장과 개발 직군의 변화가 프론트엔드와 백엔드를 고민하게 만드는 데 많이 기여했다고 생각한다.

선택의 문제, 이분법 사고의 이면

무엇인가 결정할 때에는 이분법 사고는 도움이 될 수 있다. 선택을 둘 중 하나로 단순하게 만들기 때문이다. 하지만 이런 단순화는 다른 것을 보지 못하게 한다. 책 <팩트풀니스>는 ‘세상을 오해하는 인간의 10 가지 본능’에 대해 다루는데 ‘간극 본능'에서 이분법적 사고는 인간의 본능이라고 말하고 있다.

내 생각에는 인간에게는 이분법적 사고를 추구하는 강력하고 극적인 본능이 있는 것 같다. (중략) 우리는 이분법을 좋아한다. 세상을 뚜렷이 구별하는 양측으로 나누는 것은 간단하고 직관적일 뿐 아니라, 충돌을 암시한다는 점에서 극적이다. 우리는 별다른 생각 없이 항상 그런 구분을 한다.

선택은 우리에게 스트레스를 준다. 빨리 무엇인가를 선택해야 할 것 같다. 선택하지 않으면 선택 장애가 있는 것 같고 어중이떠중이가 되는 듯하다. 그리고 불안을 느낀다. 나는 그 까닭을 어린 시절부터 성인으로 성장하는 과정에서 충분히 고민하고 받아들이는 과정 없이 선택을 강요받아 왔기 때문이라고 생각한다. 하지만 꼭 둘 중 하나를 선택해야 할까? 다른 선택은 없는 것일까? 프론트엔드니 백엔드니 하는 것도 내가 만든 것이 아닌 남이 만든 기준이 아닌가.

“저는 프론트엔드만 해요”, “저는 백엔드만 해요”

“협업하기 가장 어려운 상대는 어떤 사람인가요?”라고 내게 묻는다면 나는 잠시도 망설이지 않고 이렇게 대답할 것이다.

의사소통하기 어려운 사람

프론트엔드와 백엔드를 나누어 개발하는 것이 보편화되면서 의사소통의 문제는 더욱 중요해졌다. 하지만 일을 하다 보면 “저는 프론트엔드만 해요”, “저는 백엔드만 해요” 혹은 “저는 프론트엔드(백엔드) 밖에 몰라요” 하며 자신을 강하게 한정 지어 가두려 하는 사람들을 만난다. 개인의 정체성을 비판하려는 것이 아니다. 협업 관점에서 이런 태도는 의사소통을 어렵게 만든다. 자칫하면 프론트엔드를 고려하지 않는 백엔드 개발이나 백엔드를 고려하지 않는 프론트엔드 개발이 일어날 수 있는 것이다.

프론트엔드만 있다고 동작하는 것도 아니고 백엔드만 있다고 동작하는 것이 아니다. 소프트웨어는 하나이며 유기적이다. 소프트웨어 엔지니어링은 트레이드오프의 산물이다. 나누어 개발하면 효율성은 좋아지지만 하나로 합치는 통합 비용이 발생한다. 통합 비용의 대푯값이 바로 의사소통 비용인 것이다. 오죽하면 <오늘도 개발자가 안 된다고 말했다>라는 책이 나왔을까.

해결하기 어려운 문제는 대부분 복합적인 문제이다. 이런 문제를 해결하기 위해서는 의사소통이 핵심이지만 회의를 할 때 관찰해 보면 서로가 서로를 너무 몰라서 문제가 무엇인지 알지 못하는 경우가 많다. 내가 프론트엔드 개발자라고 가정해 보자. 만일 백엔드를 어느 정도 알고 있다면 통합적 사고로 문제의 원인 파악과 해결이 한결 나아질 수 있다.

책 <일의 미래, 무엇이 바뀌고 무엇이 오는가>에서는 우리가 앞으로 살아가야 할 사회에서는 문제를 찾아 해결하고 다른 사람들과 소통하고 정보를 주고받는 협업 능력이 중요해진다고 말한다. 미래에 국한된 얘기가 아니다. 과거에도 현재에도 미래에도 일의 핵심은 의사소통인 것이다.

선택은 중요하지만 그것이 첫 번째는 아니다

내가 원하는 회사에 가거나 다른 사람들이 납득할 만한 경력을 쌓는 데에는 ‘프론트엔드냐 백엔드냐’라는 기술적 선택은 중요하다. 하지만 더 중요한 것은 내가 하고(이루고) 싶은 것을 찾는 것이다.

사회 초년생 시절의 나는 개발자를 해야겠다는 직업적 선택은 있었지만 그래서 ‘무엇을 개발해야겠다’는 없었다. 그러다 보니 환경에 적응하며 ‘하고 싶은 것이 있느냐?’는 불편한 질문에 분명하게 대답하지 못 한 채 살았었다. 그리고 문득 꿈을 떠올렸다. 그리고 생각했다.

인정하자. 그래 나는 지금 꿈이 없어. 그러면 내가 생각할 때 멋진 꿈을 꾸는 사람과 함께 일하는 거야. 그 꿈을 이루기 위해 함께 한다면 그 과정에서 나도 내가 하고 싶은 것을 발견할 수도 있지 않을까?

그 후 나는 내가 맘에 드는 꿈을 꾸는 사람을 찾아 함께 일했다. 시작은 내가 선장이 아니어도 좋았다. 일등 항해사면 어떠냐 내가 맘에 드는 꿈을 함께 하고 있는데. 멋진 꿈은 좋은 동료들을 불러 모으는 힘이 있는 듯하다. 나는 좋은 동료를 만나 자극을 주고받으며 성장했고 내 안의 욕망을 깨닫기 시작했다.

지금의 나는 ‘프론트를 하고 싶다’, ‘백엔드를 하고 싶다’라는 욕망 보다 ‘시장에서 가치가 있는 서비스(제품)를 만들고 싶다’는 욕망이 크다. 그러다 보니 내가 원하는 것을 만들기 위해 필요하면 기획도 하고 설계도 하고 화면도 만들고 API도 만들고 인프라도 한다. 흔히 말하는 풀 스택 개발자가 된 것이다.

사실 풀 스택 개발자가 목적도 목표도 아니었다. 심지어 내가 풀 스택을 할지도 스스로 몰랐다. 책 <한국인에게 나는 누구인가>에서는 나를 더 나답게 만드는 것이 욕심이라 했다. 내 안의 욕망을 깨닫고 욕심을 내기 시작할 때 나는 더욱 나답게 만들어 내가 진짜로 무엇을 원하는지 깨달을 수 있으리라 믿는다.

충분하지 않은 정보로 서둘러 선택하기보다는

다시 선택의 문제로 돌아가 보자. 무엇인가 결정할 때에는 정보의 양이 중요하다. 우리는 선택해야 한다는 강박과 불안 때문에 결정하기에 충분한 정보를 얻지 않고 서둘러 결정하는 경향이 있다. 나는 이전에 쓴 글 ‘개발자를 코칭하며 배운 7 가지’에서 ‘결정에 충분한 정보’를 언급했다.

선택을 할 때 중요한 것은 ‘결정에 충분한 정보'이다. 정보가 충분하지 않은 상태에서 고민만 하다가는 시간만 낭비한다. 실용적인 접근 방법은 여러 선택지를 모두 조금씩 해보고 결정하는 것이다. 언뜻 보면 낭비일 것 같은 말이다. 모두 해보라니...

 

나는 전에 어떤 프로그래밍 언어를 쓸 것인가를 고민한 적이 있었다. 두 가지 선택지가 있었다.

 

• Node.js
• Python

 

문제는 내가 둘 다 실제로 해본 적이 없다는 것이었다. 해본 적도 없으면서 고민한다니 웃기는 일이었다. 결국 나는 간단한 기능을 일주일씩 두 가지 언어를 모두 구현해 보았다. 해보니 알게 되었다(결정에 충분한 정보). 지금 내 맥락에는 Python이 맞다는 것을...

하지만 현실에서 결정에 충분한 정보를 얻을 때까지 선택을 미룰 수는 없는 경우가 많다. 나는 선택하더라도 본인이 확신이 없다면 가능성을 열어두고 그 일을 하며 외적으로 다양하고 풍부한 경험을 쌓는 것이 좋다고 생각한다. 어떤 이는 어중이떠중이가 될 수 있지 않냐고 반문할 수도 있겠다. 나는 목표 없이 이것저것을 하는 것과 목표를 가지고 이것저것을 하는 것은 다르다고 생각한다.

건투를 빈다

정체성이란 내가 나 자신에게 대해 내게 들려주는 이야기이다. 나는 어떤 사람인가, 나는 무엇을 상징하는가, 나는 무엇을 잘하는가, 나는 무엇을 할 수 있는가에 관한 이야기다*. 정체성은 남이 아니라 내가 결정하는 것이다.

우리는 스스로의 경험을 기반으로 성장하며, 경험이 쌓일수록 우린 더 나은 선택을 할 수 있다. 자신을 한정 짓지 말고 무한의 가능성을 바탕으로 다양하고 풍부한 시도를 해보라고 권하고 싶다. 그 과정에서 자연스럽게 내가 어떤 사람인지, 무엇을 잘하는지, 무엇을 할 수 있는지 깨닫게 되리라 믿는다.

*책 <일의 99%는 피드백이다> 275 쪽

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.