풀스택(full-stack) 개발자란? 2편

몇 일전에 적었던 풀스택 개발자에 대한 글의 조회수가 조금 있었습니다.

2022.07.29 - [개발자의 삶/상식과 잡담 사이] - 풀스택(full-stack) 개발자란?

풀스택(full-stack) 개발자란?

사실 다른 글을 적다가 풀스택이란 단어가 들어가길래 간단하게 적었던 글이었는데, 약간은 의외였습니다.

 

그래서 2편으로 조금 상세하게 개인의 생각을 첨가하여 적어보겠습니다.

 

full-stack developer라는 말은 제가 개발을 처음 시작했을 때만 하더라도 들어보지 못한 단어였습니다.

어느 순간부터 풀스택 풀스택 하더군요.

 

하나씩 접근해보겠습니다.

 

웹사이트를 만드는 일을 한다고 생각해보겠습니다.

소수의 회사를 제외하면 대부분은 별도의 프로젝트로 진행됩니다.

IT조직이 충분한 회사라면 각 팀에서 필요한 직원을 차출하여 TF(Task Force, 특별히 구성된 임시 팀)를 구성하게 됩니다. 자사의 인적 자원이 충분하지 않다면 외주를 맡기기도 합니다. 모든 회사가 IT회사도 아니며, IT회사여도 실무 프로그래머가 충분한 경우는 많지 않기 때문에 보통은 외주 발주 형태로 진행을 하게 됩니다.

 

이렇게 외주 발주를 통해 웹사이트를 만드는 프로젝트를 보통 SI(System Integration) 사업이라고 합니다.

(원래 의미는 시스템 통합으로 어떤 시스템을 개발, 구축하는 것 자체를 의미합니다만, 국내에서는 의미가 조금 한정되었습니다.)

 

그렇다면 SI 사업에서의 조직 구성은 어떤 형태로 진행될까요?

당연히 프로젝트의 성향이나 어떤 시스템이냐에 따라 달라지긴 합니다만, 보편적으로는 유사한 경우가 많습니다.

 

• PM
  프로젝트 매니저. 해당 프로젝트를 총괄하는 책임자를 의미합니다. 경우에 따라 발주사에서 PM을 맡는 경우도 있고 수행사에서 맡는 경우도 있습니다. 예산부터 일정, 인력 등을 관리하는 일을 하며, 스포츠에 비유하면 감독과 같은 역할입니다.
  큰 프로젝트의 경우 PM 한명이 모두 수행하기 어려울 수 있습니다. 이럴 때는 PMO(Project Management Officer)로 여러명이 해당 역할을 수행하기도 합니다. 이 경우에도 PMO의 수장을 PM이라고 하긴 합니다.
• PL
  Project Leader. 단어는 PM보다 높아보이지만 실제로는 중간 관리자입니다.
  보통은 프로젝트 내부에서 팀이나 파트를 나누면 해당 파트의 리더급 인력을 의미합니다. 실무자들과 PM 사이에서 일하게 되므로 관리자적인 능력이 요구되는 것은 당연합니다. 하지만 실무자들에게 인정받으려면 실무(보통은 개발)도 아주 잘 해야 합니다.
• 기획자
  세분하면 또 나눠지겠으나 보통은 해당 시스템을 어떻게 만들지를 업무적으로 설계하는 사람입니다. 업무와 요건 분석을 통하여 디자이너, 개발자이 이해할 수 있는 기획서를 만들게 됩니다.
• 디자이너
  UI가 없는 시스템이 아니라면 눈으로 보이는 부분을 담당합니다. 웹에서는 퍼블리싱까지 함께 하기도 합니다만, 최근에는 세분화되어 분리된 경우가 많습니다.
• DBA
  데이터베이스 관련된 업무를 합니다. 최근에는 DA와 구분하기도 합니다. 구분을 하지 않는다면 DB설계부터 설정, 튜닝까지 담당합니다.
• 아키텍트
  TA, AA, SA 등이 있습니다. 하는 일은 좀 다르지만 설계를 담당합니다. 어떤 기술을 사용할지부터 서버 구성은 어떻게 할 것인지, 네트워크 구성부터 어떤 SW를 사용할지도 결정하게 됩니다.
• 개발자
  개발자는 이제 흔히 말하는 프로그래밍을 하는 사람입니다. 그런데 범위가 워낙 크다보니 분야를 나누게 됩니다.
• 프론트엔드 개발자
  사용자에게 보이는 화면을 개발하는 사람입니다. 웹사이트에서는 실제 눈에 보이는 페이지들이 이 프론트엔드에 속합니다.
  앱의 경우에도 프론트엔드로 볼 수도 있지만, 기술셋이 다르기 때문에 앱 개발자는 따로 두는 경우가 대부분입니다.
• 백엔드 개발자
  프론트엔드가 실제 눈에 보이는 화면이라면, 눈에 보이지는 않지만 데이터 처리 등을 담당하는 사람입니다.
• 기타
  SE(System Engineer), NE(Network Engineer) 등등등

세분화 하면 끝도 없습니다. 보통의 경우에는 위와 같은 역할들이 있죠.

 

특정한 하나의 스킬에 특화된 사람은 전문가라고 부를 수 있을 겁니다.예를 들어 DBA는 DB의 전문가겠죠.

 

개발자의 경우는 C++전문가, 파이썬 전문가가 있을 수 있을 겁니다.

근데 SI사업, 즉 웹사이트를 구축하는 경우에는 개발자 단위에서 전문가를 특별하게 어필하지 않는 것 같습니다.

특별한 기술이 중요한 경우에는 그런 사람을 찾기도 합니다만, 보통은 어떤 기술의 전문가보다는 풀스택 개발자를 선호하는 것 같습니다.

 

왜 그럴까요?

하나의 시스템을 구성하는데 필요한 기술이 엄청 많습니다. 다른 역할도 그렇지만 개발 범위는 점점 더 넓어지고 있죠.

만약 10개 분야가 필요한 시스템이라고 해보겠습니다. 가장 좋은 것은 각 분야의 전문가 10명을 찾는 것입니다.

 

하지만 SI 프로젝트의 특성 때문에 그게 힘듭니다. 하청 구조는 언급하지 않더라도, 애초에 고정팀이 아니라 TF형태로 임시로 모이는 조직입니다. 검증된 각 분야의 전문가를 뽑는 것이 쉬운 일이 아니죠.

 

추가로 전문가는 비쌉니다.

10개 분야 중 1~5까지는 매우 어려운 업무라고 하겠습니다. 나머지는 상대적으로 쉽거나 사용하는 비중이 크지 않습니다.

하나만 잘하는 전문가 5명은 아무리봐도 과한 것 같네요. 풀스택 개발자 2명이면 될 것 같습니다. 그게 더 싸기도 하구요.

작은 프로젝트에서는 설계도 가능하고 DB도, 백엔드도 프론트엔드도 가능한 사람이 있으면 좋겠거든요.

인건비, 공간비용(책상자리), 부대비용 등 모두 절약할 수 있으니까요.

 

이런 형태로 풀스택 개발자를 필요로 하게 됩니다.

 

어떻게 보면 풀스택 개발자가 악용되는 경우라고 볼 수도 있겠죠.

반대로 풀스택이어서 저런 업무에 투입되는 것이 아니고, 업체에서 비용을 줄이기 위하여 풀스택을 강요하여 만들어지기도 합니다.

(사실 한국의 풀스택 개발자 상당수는 이렇게 시작되었을 겁니다. 저도 그렇구요)

 

바람직한 풀스택 개발자는 어떤 형태일까요?

흔히 말하는 T자형 인재가 있을 겁니다. 한 가지의 깊이있는 전문 분야와 넓은 지식을 두루 갖춘 인재이죠.

이 T자형 인재의 개발자 버전이 바로 풀스택이 아닐까 합니다.

 

이상적이라면 모든 분야에서 깊이까지 있는 개발자면 좋겠지요.

하지만 그건 불가능합니다. 천부적인 스포츠선수도 자기 종목만 잘하는 법이죠.

다만 다른 종목도 연습하면 '쉽게 잘 할 수' 있는 역량은 있을 겁니다.

 

그렇다면 풀스택 개발자가 필요한 경우는 언제일까요?

 

가장 빛을 발하는 곳은 스타트업이 아닐까 합니다.

저도 스타트업에서 일을 해보니 어느 분야든 왠만큼 할 수 있어서 참 다행이었습니다.

직원을 고용할 여력도 없을 뿐더러, 시간은 더더욱 없습니다. 빠르게 구현을 해야하죠.

스스로 모든 부분을 이해하고 있고 설계할 수 있으며 개발까지 가능하니 의사결정도 빠릅니다.

 

다음으로는 SI에서 PL이나 아키텍트 역할도 잘 수행할 수 있을 겁니다.

많이 알수록 시행착오를 줄일 수 있으니까요.

 

그렇다면 개발자는 풀스택을 추구해야 할까요?

 

제 생각에는 반드시는 아니지만, 대체적으로는 그렇다고 생각합니다.

기술도 유행을 타며 몸값도 유동적입니다. 대우를 받고 일하는 것이 좋으니까요.

 

그렇다면 풀스택 개발자가 되려면 어떻게 해야할까요?

정답도 왕도도 없습니다.

하나의 깊은 우물을 판 이후에 다른 곳을 파도 됩니다. 끝까지 파본 경험으로 더 쉽고 빠르게 팔 수 있을 겁니다.

다양한 경험을 위주로 해도 됩니다. 지뢰찾기 게임 하다보면 어느 순간 한번에 넓게 맞춰지는 것처럼 한번에 깨달음을 얻기도 하죠.

 

결국 자신의 환경에서 최선을 다하는 것이 좋겠다는 생각이 듭니다.

하는 업무에 집중하며 그 기술을 더 깊이 이해하는 것도 좋고, 여가시간을 활용하여 새로운 기술을 습득해나가도 좋겠죠.

 

노력하는 개발자는 결국 풀스택으로 갈 수밖에 없다고 생각합니다.

풀스택이란 단어에 집중하기보다는 꾸준히 노력하는 개발자가 된다면, 저절로 따라오는 수식어이지 않을까 하는 생각이 드네요.

 

저도 더더욱 노력해야겠다는 다짐을 하며 글을 마치겠습니다.