Offcanvas

CIO / HR / 개발자

칼럼 | 2배를 해내는 풀 스택 엔지니어는 환상일 뿐

2023.01.02 Jeremy Duvall   |  InfoWorld
단 1명의 개발자가 모든 일을 다 해낸다. 그야말로 전설 같은 풀스택콘(풀 스택과 유니콘의 합성어)일 것이다.
 
신생업체, 또는 기술에 적극적인 회사에서 인력을 채용할 때에도 한 명의 풀 스택 엔지니어를 데려오면 일반 개발자보다 2배 이상의 일을 해낸다. 소프트웨어 엔지니어의 길에 들어서거나 지금 하고 있다면? 풀 스택 엔지니어링을 익히면 2배 빠르게 승진할 수 있다.
 
ⓒ Getty Images Bank

이렇듯 풀 스택 엔지니어링은 매력적인 전설이지만 많은 경우 착각에 불과하다. 실제로는 한 개인이 더 많은 스트레스를 받으면서 더 품질이 낮은 제품을 생산하는 결과가 나올 뿐이다.
 
따라서 이제 막 경력을 시작한 개발자라면 풀 스택 엔지니어 구인 공고에 주의해야 한다. 한 명분의 급여를 받으면서 시간을 반으로 나눠 두 사람 일을 해야 하기 때문이다.
 
개발자를 구하는 입장이라면 풀 스택 엔지니어로 조건을 한정해 구하면 안 된다. 당장 비용을 절감하더라도 나중에는 기형적인 데이터페이스와 막대한 기술 부채, 사용자 불편이라는 비용을 지출하게 된다.
 
몇 가지 예외는 있다. 특정 사용례, 특정 도구에서는 풀 스택 엔지니어가 완벽하게 기능하는 코드를 만들 수 있다. 또 오랜 경험을 쌓은 베테랑 엔지니어에게는 풀 스택 전문 기술이 실질적으로 최종 단계가 될 것이다. 그러나 대부분의 경우 풀 스택은 엔지니어를 실패의 길로 이끌고 그 과정에서 설익은 솔루션을 얻는 선택이다.
 
풀 스택 엔지니어링이 한 사람의 1/3만큼은 가치를 제공할까? 아니, 1/4일까? 어떻게 계산하든 결론은 명확하다. 전문적인 엔지니어로 구성된 유능하고 숙련된 팀이 한 사람의 풀스택콘보다 훨씬 더 많은 가치를 끌어낼 수 있다는 점이다.
 

사람의 두뇌는 멀티쓰레드가 아니다

인간의 두뇌는 기하급수적으로 확장되지 않고, 무거운 인지 부하 상황에서의 병렬 처리 능력도 매우 떨어진다.
 
대체로 스스로 멀티태스킹이 가능하다고 믿는 사람이 멀티태스킹 능력이 가장 떨어진다. 풀 스택 엔지니어링은 만성적인 문맥 전환을 감싼 화려한 포장지에 불과하다. 적절한 인덱스로 보이스 코드 정규형 데이터베이스 스키마를 설계하고 고도로 확장 가능한 RESTful 호출을 구현하는 동시에 객체 모델과의 상호작용을 노출하는 직관적인 사용자 인터페이스를 구축한다? 그런 다음 전체 구현을 지원하고 유지하면서 문제도 해결한다? 듣기만 해도 숨이 막히는 느낌이다.
 
프론트 엔드와 백엔드 엔지니어링은 둘 다 복잡한 영역이며 각자의 우선 순위와 관행이 있다. 각각 마스터하는 데 오랜 기간이 걸리고, 끊임없이 변화하므로 배움이 끝나지도 않는다.
 
풀 스택 엔지니어링은 너무 많은 것을 동시에 배우도록 요구하고 그 인지 부하는 뇌를 불필요하게 혹사한다. 이러한 과부하는 개발의 속도를 늦추고 더 많은 실수를 낳아 결국 과도한 기술 부채로 이어지게 된다. 경험이 부족한 개발자만의 문제가 아니다. 개발 분야가 빠른 속도로 계속 발전하는 한 베테랑 엔지니어라 해도 따라가기 버겁다.
 
모국어와 전혀 다른 새로운 외국어와 비유클리드 기하학을 배우는 동시에 엔지니어링 문제 해결에 외국어와 기하학을 모두 적용하려 한다고 상상해 보자. 게다가 문법 규칙과 기본 공리가 계속해서 바뀐다.
 
이런 과제에 도전하는 것이 영응적으로 보일 수는 있겠다. 하지만 실제로 엔지니어링 조직에 더 유익한 방법은 팀이 과제를 여러 개로 나눠 정복하면서 협력해 최선의 솔루션을 도출하는 것이다. 한계를 인식해야 더 나은 결과를 낳을 수 있다.
 

풀스택콘의 진짜 영역

풀스택콘이 자유롭게 노닐 수 있는 제한된 구역도 있긴 하다.

앞에서 언급했듯, 효율적인 풀 스택 엔지니어링은 오랜 경험이 있는 개발자 경력에서 달성 가능한 목표다. 다만 아주 드문 특별한 엔지니어라 해도 보통은 여러 전문가가 포함된 유능한 팀에 속해 활동할 때 더 많은 가치를 창출한다.

소프트웨어 엔지니어링 문제의 극히 일부라면 어떤 풀 스택 엔지니어든 혼자서 괜찮은 솔루션을 만들어낼 수 있다. 이때의 2가지 사용례는 다음과 같다.
 
  1. 서버 측 렌더링 모놀리스(monolith)
  2. 이것저것 집어넣어 만든 MVP(최소 기능 제품)이나 프로토타입(1번의 특수한 경우일 때도 있음)

일부 익숙하고 단순한 문제는 서버 측 렌더링 모놀리스로 해결할 수 있다. 필요한 솔루션이 루비 온 레일즈(Ruby on Rails), 장고(Django), 라라벨(Laravel)과 같은 프레임워크가 제공하는 독단적인 패턴과 잘 맞는다면 이와 같은 프레임워크를 잘 아는 숙련된 풀 스택 개발자 팀은 효율적으로 솔루션을 구축할 수 있다.
 
그러나 모놀리스는 단기적인 필요에 대응할 수는 있지만 규모가 커지면 복잡성과 실행 가능성 측면에서 한계가 있음을 유의해야 한다. 잘 알려진 문제 집합에 맞게 설계된 제한된 특정 선택에 계속 매달리게 된다. 모든 엔지니어링 과제의 정답이 모놀리스인 것은 아니다. 나중에 적절한 규모의 서비스로 전환하거나 새로운 문제에 대한 더 혁신적인 접근 방식을 구현하려면 코드베이스를 다시 구축해야 하는 상황에 처할 수도 있다.
 
비슷한 경우로, 초기 단계의 스타트업은 종종 자금 조달을 위해 “느슨한” MVP를 구축하는 데 만족한다(보통 서버 측 렌더링 프레임워크 중 하나에 구축됨). 풀 스택 엔지니어가 그 일을 할 수 있지만, 신생업체가 제대로 된 팀을 채용할 여력이 없다는 이유만으로 이들을 악용하거나 부당한 압박을 가해서는 안 된다.
 
여기서 핵심은 상당한 자금 지원을 받게 되면 코드를 처음부터 다시 쓰게 될 수 있다는 점을 분명히 인식하는 것이다. 영양실조 상태의 MVP를 리팩터링하거나 확장하는 문제가 아니다. MVP를 내다 버리고, 전문 엔지니어로 구성된 더 제대로 된 팀으로 새로 구축할 가능성이 높다.
 
모두가 풀 스택 엔지니어링의 한계를 인식하고 나중에 코드베이스의 단점에 대해 팀을 탓하지 않고 그 결과를 기꺼이 받아들일 수 있다면 풀스택콘이 자유롭게 노닐도록 해도 된다.
 
그러나 이러한 한계로 인한 위험을 감수하고 싶지 않다면 더 최적화된 솔루션으로 가는 다른 길을 선택해야 한다.
 

풀 벤 엔지니어링 팀의 역량

소프트웨어 엔지니어링의 많은 문제와 기회에 있어 프론트 엔드와 백엔드 엔지니어로 구성된 협업 팀이 풀 스택 한 명에 비해 훨씬 더 효과적일 수 있다.
 
백엔드 개발자는 데이터 계층, 잘 설계된 RESTful 엔드포인트, 스레딩, 확장성 문제에 집중하고 쿼리 등에 대한 n+1 문제는 피할 수 있다.
 
프론트 엔드 개발자는 사용자와 애플리케이션 간의 쾌적하고 직관적인 상호작용, 효율적인 UI 번들 다운로드, 잘 설계된 재사용 가능한 구성요소에 집중할 수 있다.
 
서로의 관심사에 대해 사려 깊은 무지함을 유지한 채 전문 영역에 완전히 집중해서 대부분의 작업을 혼자서 할 수도 있다. 그러나 책임 영역이 합쳐지는 부분, 즉 벤(Venn) 다이어그램의 원이 겹치는 부분에서는 팀원이 협력을 통해 최선의 솔루션을 결정해야 한다.
 
사용자가 액세스 또는 편집해야 하는 데이터는 무엇인가? UI에서 어떻게 API를 호출할 것인가? 데이터 계약은 어떤 형태가 되는가? 팀은 이러한 질문에 대해 의견을 조율한 다음 솔루션에서 각자가 맡은 부분으로 다시 돌아간다.
 
팀이 모여 이런 대화를 하게 되면 단기적으로는 프로세스 속도가 절반으로 줄어들지만, 더 빠르게 일하고 올바르게 기능을 구현하기 위해 필요한 문맥을 손에 쥔 채로 각자의 일로 돌아가면 다시 최대 속도를 낼 수 있다. (반면 풀 스택 엔지니어는 멀티태스킹과 문맥 전환으로 인한 속도 저하로 프로젝트 전체를 빨라봐야 절반의 속도로 진행하게 된다.)
 
예상하겠지만 책임이 중첩되는 이러한 부분을 고려할 때 각 팀원이 서로의 전문 영역에 대해 어느정도 이해하는 것이 중요하다. 그러나 그 이해가 아주 깊을 필요는 없다(특히 아직 경력의 초반 단계에 있는 엔지니어라면).
 

경력은 협업의 산물

경력 초반의 소프트웨어 엔지니어는 (다른 직종도 마찬가지일 수 있지만) 모든 것을 한꺼번에 배우려는 경향이 있다. 그러나 이 성급함은 사실 속도를 더 늦추는 결과를 초래한다.
 
단백질 구조 접힘이라는 중요한 문제를 해결하기 위해 수학과 생물학에서 동시에 박사 과정을 진행한다고 상상해 보자. 주의력과 시간을 나누는 만큼 두 가지 박사 과정 중 하나를 마치기에도 오랜 시간이 걸릴 것이다. 또한 그 분야에 유의미하게 기여하기까지는 거기서 더 오랜 시간이 걸린다. 그 사이 문제가 변화한다면 또 다른 시간이 필요하다.
 
대신 그 중 하나만 선택한다면 어떨까? 수학, 그 중에서도 통계적 메커니즘을 전문 분야로 선택한다고 가정하자. 진행하면서 분자 및 세포 생물학 분야의 동료들과 접촉해 연합을 만들고, 여러 분야에 걸친 팀을 구성한다.
 
수학에 대한 이해는 훨씬 더 빠른 속도로 발전하고 그 사이 동료들도 생물학에서 같은 속도로 발전한다. 서로 배운다. 서로의 영역에 대한 박사 학위를 취득할 정도는 아니라 해도 일부 흥미로운 문제에 대해 협업하기 위한 정도로는 충분히 배울 수 있다. 또한 원활하게 협력하는 방법과 그 프로세스, 인성, 좋은 팀의 사회적 구조에 대해서도 배운다.
 
졸업한 후에도 각자의 영역에서 일어나는 일을 계속 주시하고 파악한다. 그리고 혼자 할 때보다 훨씬 더 빠르게, 더 지속적으로 단백질 접힘 문제에 대해 실제로 유의미한 기여를 하기 시작한다.
 
분자 및 세포 생물학에 대해서도 생물학자만큼은 아니지만 대부분의 수학자보다 더 깊이 이해하게 된다. 이는 스스로의 경쟁력, 자신의 분야에서 유의미한 영향을 미치는 역량에 보탬이 된다.
 
소프트웨어 엔지니어링도 마찬가지다. 충분한 시간을 프론트 엔드 또는 백엔드 엔지니어링 중 하나에 집중하고, 이후 다른 전문 분야를 선택한 사람들과 함께 팀을 이뤄 협업하는 방법을 배우면 훨씬 더 빠르게 발전할 수 있다. 몇 년에 걸쳐 협업을 통해 많은 것을 배우게 되고 여러 분야에 걸친 지식은 더 많은 성과를 내는 데 도움이 될 것이다.
 

풀 스택보다 더 충실한 것

개발자 경력의 마지막 단계를 풀 스택 엔지니어라고 할 수도 있지만, 보통 경력이 충분히 쌓인 시점이면 훨씬 더 많은 것을 다루는 위치에 있게 된다. 소프트웨어 설계자일 수도, 엔지니어링 관리자일 수도 있다. 탄탄한 기초, 한 분야에 대한 전문적인 지식, 전문 영역 외의 분야에 대한 익숙함, 그리고 가장 흥미로운 문제를 해결하기 위해 이 모든 요소가 어떻게 결합되는지에 관한 큰 그림을 이해하는 역량을 갖춘 사람이 된다.
 
이것이 진짜 혼자서 2명분, 때로는 5명이나 10명분의 일을 하는 것이다. 두 가지 일을 두 배의 시간에 걸쳐 절반의 품질로 할 수 있는, 과로에 시달리는 풀 스택 엔지니어 한 명이 아니다. 그보다는 전문가의 길에 들어서서 여러 분야에 걸친 협업을 통해 좋은 소프트웨어의 설계 방법에 대한 정교한 이해를 발전시킨 사람이 바로 진짜 전문가다.
 
풀 스택 엔지니어링은 잘해봐야 그저 그런 구현으로 이어지는 비효율적인 덧셈의 결과물이다. 클라이언트와 기업, 개별 엔지니어가 만들어내는 진짜 가치는 우수한 팀의 협업에서 나온다.
editor@itworld.co.kr 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.