풀스택 개발자에 대해서 어떻게 생각하나요?

프롤로그

이번에는 풀스택 개발자에 대해 한번 얘기를 해보려고 합니다. 명확한 실체 없이 떠도는 용어인 만큼 저마다의 해석이 다릅니다. 그러다 보니 상당히 많이 변질된 용어이기도 하고 사람들이 환상을 가지고 있는 용어이기도 합니다. 이번 글에서는 현업 프론트엔드 개발자의 시각에서 풀스택 개발자가 무엇인지 그리고 풀스택이 어떠한 의미를 가지는 지에 대해 이야기를 드릴까 합니다.

이 글 또한 또 하나의 풀스택 개발자에 대한 해석과 설명일 테지만, 프론트엔드 개발자이기 이전에 스스로를 풀 스택 개발자라고 생각했었기에 풀스택 개발자에 대한 이해를 도울 수 있기를 바랍니다.

풀스택 개발자란 무엇일까요? 구글에게 물어봤습니다.

우선 풀스택 개발자에 대한 사전적인 의미를 생각해봅니다. 그러기 위해서는 구글에 'full-stack developer'를 한번 검색해보았습니다.

• 클라이언트 및 서버 사이드 코드를 학습하고 웹 사이트가 작동하도록 해주는 모든 기술군에 대해 이해하고 있는 개발자입니다.
• 풀스택 개발자란 GUI 프론트엔드부터 데이터베이스 백엔드에 이르는 모든 소프트웨어 스택을 이해하는 개발자를 말한다.
• 풀스택 개발자는 데이터베이스, 서버, 시스템 엔지니어링 및 클라이언트의 모든 작업을 처리할 수 있는 엔지니어입니다.
• 풀스택 개발자, 폴리글랏 개발자 모두 하나의 범주를 넘어 다양한 환경 및 플랫폼을 이해하고 사용되는 대부분의 언어와 지식을 갖춘 인재를 얘기합니다.

점점 거대해져 가는 풀스택 개발자의 의미...

풀스택 개발자라는 말을 언제부터 쓰고 있었을까?

풀스택 개발자에 대한 정의가 정확하게 무엇인지 모르겠습니다. 이 말은 도대체 어디서부터 생겨난 말일까요?

2014년도를 기점으로 해서 풀스택 개발자의 용어가 크게 관심도가 증가한다는 것을 알 수 있습니다. 왜 저 시기부터 일까요? (눈치 채신 분들도 있겠죠?) 사실 웹에 오랫동안 종사한 사람들은 풀스택의 의미에 대해서 정확하게 알고 있습니다. “당신은 풀스택 개발자입니까?”라는 말은 사실 다음과 같습니다.

"혼자서... 웹 사이트(서비스) 만들 줄 아세요?"

2014년의 이유, 그 이전의 웹의 역사

웹 개발자

웹은 문서를 가상의 공간에서 공유하기 위해 태어났습니다. 오프라인에 있던 문서를 가상의 공간으로, 링크로 연결이 되는 공간을 만들어냈습니다. 이후 사용자의 정보를 전달하고 그 내용에 따라 다른 형태의 페이지를 동적으로 만들어내는 방법이 개발이 됩니다. 예컨대 방문자수에 따라 다르게 표기가 되는 카운터 같은 것처럼요.

그 과정이 발전을 하게 되면서 사용자가 스스로 문서를 만들어내고 보관할 수 있게 됩니다. 방명록이라고 하는 것들이 추후 게시판, 포럼과 같은 형식으로 발전을 하게 되죠. 문서를 보여주기 위해서 태어난 웹에서 문서를 생성하고 보관하고 관리하는 도구로 발전을 하게 됩니다.
 

이런 서비스들을 만들어내는 사람을 우리는 웹 개발자라고 불렀습니다.

웹 디자이너

웹은 문서였기에 이러한 서비스가 발전하기 이전에 잘 읽히게 하기 위해서 잘 꾸며져 있을 필요가 있었습니다. 문서이기도 했고 장식이기도 했고 카탈로그의 역할도 복합적인 의미를 가지고 있었죠.

이러한 문서를 돋보이게 만들 수 있는 하는 사람들을 우리는 웹 디자이너라고 불렀습니다. 웹문서가 홈페이지로 업데이트가 되면서 회사의 정보를 표현하거나 개인을 표현하는 수단으로 발전을 했죠. 하지만 게시판이나 포럼 등 기능들과 디자인이 결합할 필요가 생기면서 둘 다 어느 정도 할 수 있는 역할이 필요했습니다. 때로는 웹 개발자가 웹 디자인을 적용해야 했고 웹 디자이너가 웹 개발을 하기도 했죠. 이제는 웹 사이트를 하나 만들기 위해서는 화면을 다루는 웹 디자인 영역과 데이터를 다루는 웹 개발 영역을 둘 다 할 줄 알아야 했습니다.

하지만 이때는 웹 사이트가 어느 정도 정형화가 되어 있었기에 웹 디자이너는 솔루션을 이용해서 디자인만 적용하거나 웹 개발자는 디자인 테마를 사서 적용 후 배포하는 식으로도 가능했었기에 충분히 혼자서도 웹 사이트를 만드는 것은 어렵지 않았던 시기입니다. 디자인도 할 수 있고 웹 개발도 할 수 있었던 사람을 당시에는 웹 마스터라고 부르던 시절이 있었습니다.

프론트엔드의 등장, 2014

하지만 2010년을 기점으로 구글을 앞세운 웹 서비스는 전혀 다른 방향으로 흘러갑니다. 웹은 이제 문서라는 개념을 완전히 탈피를 하고 하나의 애플리케이션과 같은 역할을 수행할 수 있게 됩니다. 그리고 페이스북의 2013년 React의 등장으로 웹 개발은 기존과는 다른 새로운 국면으로 흘러가게 됩니다. 이렇게 웹 서비스의 개념이 커지고 프론트엔드라는 생태계와 분야가 만들어지면서 기존의 많은 웹 개발자에게 프론트엔드라는 역할까지 원하게 됩니다. 그리고 기존의 웹 개발은 프론트엔드에 대치되는 백엔드라고 불리게 됩니다.

이때부터 기존의 웹 개발자이면서 새로운 생태계인 프론트엔드를 같이 할 수 있는 개발자를 찾기 시작합니다! 이른바 백엔드와 프론트엔드를 모두 할 줄 아는 '풀스택 개발자'를 말이죠. 지금이야 풀스택 개발자에게 자기 멋대로 의미부여가 확장이 되고 있지만 풀스택 개발자의 시초는 이 변화된 웹 생태계를 다 이해하고 있는 사람을 말하는 거였습니다.

왜 유독 웹에서 풀스택을 찾을까?

무릇 웹 개발자는 프론트엔드, 백엔드 가리지 않고 할 줄 알아야 되는 거 아닐까요?

다른 분야에 비해 왜 유독 웹에서 풀 스택을 많이 찾을까요? 그것은 웹 서비스의 특성 때문입니다. 웹은 다른 UI 애플리케이션 분야와 달리 클라이언트만으로 무엇을 하기에는 부족합니다. 일단 웹을 사용하기 위해서 브라우저는 필수적인 요소입니다. 브라우저를 통해서만 웹의 결과물들을 볼 수가 있죠. 그렇기에 브라우저를 잘 다룰 줄 안다는 것은 웹 개발에서 아주 중요한 역할을 하고 있습니다. 이 브라우저를 중심으로 개발을 하는 분야가 바로 프론트엔드이죠. 백엔드 개발자들이 웹 밖에서 데이터를 다루더라도 결국 웹 서비스가 제공이 되는 것은 브라우저 안이기 때문에 프론트엔드를 하지 않을 수 없습니다.

프론트엔드만 있어서 브라우저만 잘 다룬다면 어떨까요? 브라우저는 여러 가지 보안정책으로 인해서 컴퓨터의 OS리소스를 거의 사용할 수가 없습니다. 그러니 중간과정을 아무리 잘 만들어도 최종적으로 데이터를 보관을 할 수 없는 애플리케이션은 데모 수준밖에 되지 않습니다. 브라우저에서 없는 기능은 반드시 백엔드의 도움을 받아야만 서비스를 완성할 수 있습니다. 그렇기 때문에 가치 있는 서비스를 만들기 위해서는 반드시 백엔드를 통한 데이터 조작이 필요합니다.

웹은 초창기 시절부터 브라우저와 DB를 둘 다 다루는 것들이 당연했으니 전통적인 시각에서 웹 개발자는 원래 풀스택이었고 무릇 웹 개발자라면 둘 다 할 줄 알아야 한다고 했습니다. 초창기 페이스북의 모든 개발자들은 스스로들을 풀스택 개발자라고 말했지요. 하지만 과연 지금도 그럴 수 있을까요?

풀스택은 왜 유니콘이 되었을까?

"풀스택이 왜 유니콘인 줄 아니?"

"엄청 멋있기 때문이지 않을까요?"

"...그런 것은 이 세상에 존재하지 않기 때문이야."

웹 개발은 이제 더 이상 1인 개발자의 세상이 아닙니다. 거대 웹 서비스들이 등장했고 세계 10위권 내의 서비스들이 존재합니다. 웹은 지난 10년 동안 폭발적으로 성장을 하였습니다.

한 명이 분명 여러 분야에 뛰어날 수 있습니다. 하지만 거대한 기업 세계에서는 1명의 개발자가 투자할 수 있는 시간은 동일합니다. 두 분야 모두 뛰어난 인재라면 연봉이 높을 텐데 2명의 풀 스택 개발자를 뽑아서 각각의 분야에서 0.5의 역할을 할 거라면 그냥 프론트엔드, 백엔드 전문가 1명씩 뽑아서 일을 하는 면이 회사 입장에서 효율적이기 때문입니다.

이것은 서비스의 덩치가 커질수록 심화됩니다. 여러 사람이 함께 일을 하게 되면 결국 특정 분야에 대해서는 누군가 보다 더 나은 전문가의 영역이 존재하게 됩니다. 할 줄 안다는 것과 그 분야의 전문가라는 것은 엄연히 다른 말입니다. 그러니 여러 명의 유니콘으로 이루어진 팀을 만들려고 하는 것보다 좋은 협업능력을 가진 전문가 집단이 훨씬 더 훌륭할 수 있습니다. 하지만 여전히 높은 연봉을 주고서라도 풀스택 개발자를 원하는 기업들이 존재합니다. 왜 그럴까요?

왜 기업은 풀스택을 원할까? – 희망편

현대의 풀 스택 개발자는 최소한의 실행 가능한 제품, 즉 초기 고객을 만족시키고 지속적인 개발을 위한 피드백을 촉발할 수 있으며, 충분한 기능을 갖춘 애플리케이션을 스스로 구축할 수 있는 경험 많은 제너럴리스트입니다.

여전히 몇몇 기업들은 고액의 연봉을 주고서라도 풀 스택 개발자를 희망하는 경우가 있습니다. 그들은 이 사람들이 프론트엔드와 백엔드의 두 분야 모두의 깊이 있는 전문가는 아님을 알고 있습니다. 하지만 혼자서 초기 서비스를 만들어내고 협업을 해야 하는 파이프라인을 이해하고 있는 전문가입니다.

아직 서비스를 만들기도 전이라면 빠르게 아이디어를 검증해 볼 수 있는 전문가가 필요합니다. 이들에게 깊은 전문성을 요구하는 게 아닙니다. 협업에는 커뮤니케이션 비용이 발생합니다. 아이디어를 빠르게 검증해서 성공할 수 있는 방법을 찾기 위해 프로토타이핑을 빨리 해내는 것은 아주 중요한 스킬입니다.

더불어, 스타트업에서는 초기 팀 빌딩이나 협업에 대한 경험이 부족합니다. 풀스택 개발자들은 여러 기술 전반에 걸친 폭넓은 경험적인 요소를 높이 평가받습니다. 풀스택 개발자는 백엔드, 프론트 엔드 및 디자인 팀과 협업할 수 있는 CTO와 같은 가장 좋은 위치를 차지합니다.

뿐만 아니라 IT기업이 아닌 곳에서는 풀스택 개발자가 더 유리할지도 모릅니다. 빅 테크 기업과 같은 수준의 깊이를 요구하지 않더라도 기존의 아이디어를 적당히 서비스를 제공하는 것과 연결만 시킬 수 있더라도 부가가치를 만들어 낼 수 있습니다. 이들에게 필요한 능력은 기술적인 깊이가 아니라 최소한의 애플리케이션을 만들어 내는 능력과 해당 비즈니스 도메인에 대한 넓은 통찰력입니다.

왜 기업은 풀스택을 원할까? – 절망편

"풀.스.택. 개발자시니까... 이것도 할 줄 아시죠? 이것도?"

풀스택 개발자라는 용어가 주는 환상과 정해지지 않고 주관적인 해석으로 인해 이 글 초기에 봤듯이 이미 풀스택의 의미는 부풀려졌습니다. 그리고 이것을 악용하는 케이스도 늘어났습니다. 풀스택 개발자라는 직군이라는 핑계로 과도한 개발 능력을 요구합니다.

또한 풀스택의 기준이 주관적인 해석이 달려 있기 때문에 시각차도 존재합니다. 분명 풀스택이라고 해서 뽑았는데 분명 서비스를 만들어 낼 수는 있지만 할 줄 아는 분야가 너무 한정적일 수도 있습니다.

또는 인력이 없는 회사에서는 풀스택을 하면 좋지 않냐는 명목으로 한 개발자에게 여러 가지 일을 시키기도 합니다. 그리고 여러가지 경험이 많고 이력이 많은 풀스택을 선호한다면서도 정작 풀스택 개발자에 대해서는 깊이가 없기 때문에 취업에서 불리해지는 경우도 생깁니다.

자칭 풀스택 개발자를 꺼리는 이유

"만능형이라는 말의 다른 이면은 어중간함입니다."

해본 게 많지만 경험치가 낮은 풀스택 개발자들을 다른 실무에서 일을 하게 하려면 실제로 깊이가 모자란 경우가 많이 있습니다. 많은 것을 알지만 어느 하나 제대로 아는 게 없는 경우가 생기게 됩니다. 앞서 말한 서비스의 규모가 이미 커져있고 전문가 집단이 형성이 된 곳에 가면 이 현상은 더 두드러집니다. 각 분야에서 잘하는 사람이 기준이니까요.

경험치가 충분하지 못하다면 스스로를 풀스택이라고 칭하는 사람들은 신뢰하기가 어렵습니다. 대부분의 주니어 취업 상담의 얘기에서 공통적으로 하는 얘기가 있습니다. 이것도 해봤고 저것도 해봤고 해 봤다고 전부 다 기록을 하게 되면 오히려 신뢰도를 잃게 된다고 말이죠. 분명 예전에는 웹 개발자는 풀스택 개발자를 지향했어야 했는데 이 산업이 커지다 보니 풀스택을 담기에는 너무 커져버린 게 아닌가 싶습니다.

마치 옛날에 레오나르도 다빈치가 화가이자 조각가, 발명가, 건축가, 해부학자, 지리학자, 음악가였던 것처럼요. 그때는 각 분야가 해놓은 게 적었으니 한 사람이 수많은 역할을 수행할 수 있었지만 지금은 하나의 분야만 파고들기에도 너무 알아야 할 것이 많아져버린 것이지요.

사실 잘하는 사람은 다 잘한다!

"저... 그게 아니라 레오나르도 다빈치는 진짜 천재 아닌가요? 2007년 네이처에서 선정한 인류 역사를 바꾼 10인의 천재중 가장 창의성이 높은 사람인데요?"

그렇습니다. 세상은 공평하지 않고 잘하는 사람은 사실 다 잘합니다. 풀스택이 유니콘이라고는 하지만 그것은 풀스택의 기준을 한없이 올려치기 했기 때문이 아닐까요? 주변에 혼자서 웹 서비스를 만들어내고 DB를 다루고 화면을 다루고 디자인을 하면서 프론트와 백엔드의 지식을 넘나드는 사람들은 분명히 존재합니다.

기술의 깊이가 전문가급은 아니더라도 비즈니스에 대한 이해도가 높아서 스타트업을 성공시키기도 하고, 프론트엔드에 전문가이면서도 필요한 백엔드 기술을 뚝딱뚝딱 잘 가져와서 스타트업에서 원하는 프로토타입을 만드는 경우도 있습니다. 백엔드의 전문가이지만 필요하면 UI를 가져와서 CMS나 백오피스를 만들어내는 개발자 역시 존재합니다. 결국 개발의 본질은 같으니까요.

무엇을 풀스택이라고 부를 것인가?

"혼자서 웹서비스 만들 수 있습니다!"

• React를 이용해서 AWS를 통해 인프라 배포나 Auto Scale 등의 구성은 하지 않고 express와 DB만 이용해서 서비스를 만들었다면 풀스택이라고 할 수 있을까?
• React를 이용해서 React Native를 이용해서 앱 개발을 하면 앱 개발자라고 부를 수 있나? 이는 또 하나의 풀스택일까?
• 워드프레스로 테마를 수정해서 웹사이트를 만들었다면 풀스택이라고 할 수 있을까?
• 혼자서 리눅스 서버를 이용해서 APM으로 게시판을 이용한 커뮤니티를 만들었다면 풀스택 개발자일까?
• Github의 pages를 이용해서 블로그를 만들었다면 풀스택이라고 할 수 있을까?
• DB 없이 구글시트를 연동해서 설문 결과를 저장하는 서비스를 만들었다면 풀스택이라고 할 수 있을까?

추상화된 좋은 서비스가 너무 많이 나오고 있다.

혼자서 웹 서비스를 만드는 방법은 너무나 다양합니다. 그리고 백엔드와 프론트엔드의 경계는 갈수록 희미해져가고 있습니다. 그러면서도 동시에 각 분야의 깊이는 점점 더 깊어지고 있습니다.

그런데 반대로 웹 서비스를 만드는 방법은 점점 쉬워지고 있습니다. 우리가 백엔드의 전문가가 아니더라도 클라우드 서비스를 이용해서 대용량 트래픽을 감당할 수 있는 서버를 쉽게 생성할 수 있습니다. javascript를 깊이 있게 알지 못해도 프레임워크를 통해서 복잡한 페이지도 쉽게 만들어 낼 수 있게 되었습니다. 디자인을 못해도 이미 잘 만들어진 UI Framework들이 존재합니다.

프론트엔드와 백엔드뿐만이 아닙니다. 우리는 음성인식 기능과 같은 AI 기술도 얼마든지 사용할 수가 있습니다. AI 전문가가 아니더라도 AI 서비스를 이용해서 서비스를 만들어내는 것은 어렵지 않은 일이 되었습니다. 하나의 전문성을 갖추는 것도 중요하지만 새로운 가치는 융합과 연결에서 나옵니다. 프론트엔드와 백엔드가 하나라도 없으면 웹 서비스라고 할 수 없듯이 말입니다.

우리가 풀스택 개발자의 시각을 가져야 하는 이유

풀스택이 유니콘이니 자칭 풀스택은 깊이가 없어서 꺼린다고는 하지만 어디까지나 그것은 회사나 특정 개인의 입장일 뿐, 내가 어느 분야의 전문가가 되기 전까지는 웹 개발자라면 풀스택 개발자의 시각을 유지하는 것은 충분히 필요한 일입니다.

웹 분야의 경우 산업이 발전하면서 경계가 희미해지고 프론트엔드와 백엔드의 스펙트럼이 계속 바뀌어 가고 있습니다. 특히 클라우드 서비스가 보편화가 되면서 인프라나 스케일링 서버 운영에 대해서 전혀 몰라도 React를 하면서 AWS를 이용해 Node로 express와 DB를 적당히 다루는 것과 같이, 프론트엔드 백엔드 기술을 같이 쓰는 것은 어렵지 않은 일이 되었습니다.

인프라와 DB, 스케일링을 클라우드화 해서 인프라 시스템만 백엔드가 하고 DB 스키마나 CRUD는 이제 프론트엔드에서 해야 한다는 입장도 존재합니다. Cloud Function와 Serverless는 현재 진행형인 상태입니다.

웹 개발자라면 내가 한 분야의 전문가가 되거나 취향이 확고해 지기 전까지는 결국 다 해야 합니다. 어중간하게 둘 다 하는 것이 아니라 내 전문성을 살리되 적어도 관심사의 스펙트럼은 넓게 유지를 해야 합니다. 어느 한 분야의 전문가 되는 식으로 커리어는 흘러가겠지만 결국 웹이라는 생태계 안에서 연결과 협업을 해야 하는 일은 계속해야 하니까요.

프론트엔드 건 백엔드 건 우리는 웹 개발자잖아요.

끝으로

풀스택의 Full이 주는 어감 때문일까요? 언제부턴가 풀스택이라는 단어에 너무나 많은 의미를 투영하려고 하는 것 같습니다. 풀스택 개발자가 유니콘이 되어버린 것이 개발자의 문제는 아닐지도 모르겠습니다. 하지만 사회는 점점 더 T자형 인재를 원하고 있습니다. 하나의 전문성을 가지고 있으면서 또 넓게는 다양한 분야에 대한 지식을 아우르는 그러한 의미로 T라는 모양을 사용하고 있습니다.

우리는 결국 어느 한 분야의 전문가가 되어야겠지만 웹 개발자, 나아가 개발자라는 생태계 안에서 계속 살아갈 것이고 누군가와 함께 일을 하게 될 것입니다.

'풀스택이어야 고연봉을 받으며, 당연히 개발자가 지향해야 하는 곳이다.' '풀스택은 전문성이 없기 때문에 지향하면 안 된다.' '풀스택이라는 것 자체가 잘못된 것이다.' 풀스택에 대한 의견이 많지만 대부분의 글들에는 풀스택에 대한 기준이 명확하지 않습니다. 저 역시 풀스택에 대해서 경계를 그을만한 명확한 정의를 내리기는 쉽지 않을 것 같습니다.

한 가지 분명한 사실은 풀스택의 정의는 계속 변하고 있다는 사실입니다. 웹도 변하고 있고 개발 생태계도 계속 변하고 있기 때문입니다. 이 변화를 끊임없이 주시를 하면서 이 넓은 생태계가 어떻게 변하고 있는지 어떻게 이용하고 연결하고 협업할 수 있을지는 계속 확인하시기 바랍니다.

웹 개발자라면 아주 쉽고 간단한 방법이라도 본인만의 서비스를 완성할 수 있는 것을 공부해봅시다. 풀스택 개발자의 타이틀을 따기 위함이 아닙니다. 조그맣게 여러 서비스들을 연결하여 한 사이클을 완성을 할 수 있다는 것은 개발자의 시각을 굉장히 넓혀줍니다. 그리고 혹시 아나요? 작은 아이디어를 구현한 그 서비스가 대박을 칠는지도?

‘풀스택을 지향한다는 것이 사실은 누구보다 열심히 개발하고 있다는 것을 뜻하지 않는가.’라는 생각을 해봅니다. 내가 고액 연봉을 받는 유니콘 풀스택 개발자가 못되더라도 우리는 다 같은 개발자이기에 하나라도 더 많이 아는 것은 좋다고 생각합니다. 개발의 본질은 사실 크게 차이 나지 않으니까요.

본인만의 기준에 맞는 전문성과 넓은 시각을 가진 풀스택 개발자가 되어보길 바라며,
이 글이 풀스택 개발자에 대한 이해에 도움이 되기를 바랍니다.