최근 풀스택 개발자라는 용어가 점점 더 자주 사용되고 있습니다. 특히 팀 구조, 모집 요구 사항 또는 개인의 순수함을 추론하는 데 대한 토론에서.

이력서에서 이런 종류의 진술을 보거나 누군가가 자신을 풀 스택이라고 설명하는 것을 들을 때 많은 질문이 떠오릅니다.

• 풀 스택 개발이란 무엇을 의미합니까?
• 어떤 스택에 대한 지배권을 주장하고 있습니까?
• 각 요소에 대한 귀하의 지식은 얼마나 광범위합니까? 얼마나 채워야 합니까?

• 풀 스택 개발자는 진짜입니까? 그들은 정말로 존재합니까?
• 존재한다면 왜 유용합니까?
• 풀 스택은 Jack of all trades, master of none을 말하는 또 다른 방법인가요?

배경

세부 사항을 살펴보기 전에 우리가 개발하고 제공하려는 목표를 정의할 가치가 있습니다.

랩톱에서 실행되는 PoC의 풀스택 개발자라고 주장하는 것은 해당 솔루션의 모든 부분을 개발하는 한 사람이기 때문에 공정한 설명일 것입니다. 규모가 매우 작으며 잘못된 설계 또는 개발의 영향이 매우 제한적입니다. 기본적으로 서비스를 제공하지 않는 개념을 증명하는 것입니다. CIO에게 몇 시간 동안 시연할 수 있는 한 괜찮습니다.

라이브 고객 데이터를 처리하고 비즈니스 가치 창출을 주도하는 통찰력/데이터를 생성하는 생산 시스템으로 솔루션을 정의하면 상황이 다르며 코딩 오류 또는 잘못된 관행의 영향이 훨씬 더 큽니다.

이 게시물의 목적을 위해 실제 고객 데이터(PII 포함)를 대량(하루 10GB) 처리하고 최소 99.9999%의 가용성으로 주요 비즈니스 서비스를 제공하는 시스템을 고려할 것입니다.

풀 스택 개발자가 가치 있는 이유는 무엇입니까?

그러한 사람들의 존재를 제쳐두고 그들이 제공하는 이점은 자명합니다. 외부 지원 없이 솔루션을 설계, 구축 및 실행할 수 있습니다. 즉, 시간이 많이 걸리고 오류가 발생하기 쉬운 설계 워크샵, 구성 요소 통합, 테스트 주기 및 운영 핸드오버가 모두 제거됩니다. 솔루션을 설계, 구축 및 실행할 수 있기 때문에 보안, 플랫폼, DB, 운영, … SME 간에 회의를 예약하거나 더 나쁘게는 일련의 회의를 할 필요가 없습니다. 개발자와 같은 소수의 신(작은 g)이 대규모 교차 기능 팀의 작업을 제공할 수 있으며 핸드 오프의 오버헤드를 제거하기 때문에 전달도 훨씬 빠르고 오류가 발생하기 쉽습니다.

따라서 이러한 분명한 이점을 바탕으로 모든 IT 조직에서 이러한 사람들로 구성된 팀이 더 많지 않은 이유는 무엇입니까? 왜 기업들은 이러한 닌자 팀을 구성하기 위해 적극적으로 모집하고 교육하지 않습니까? 배트맨이나 토니 스타크와 같은 개발물이 실제로 존재하지 않기 때문인가요?

이러한 질문에 답하려면 (매우) 단순화된 스택이 어떤 모습인지 살펴봐야 합니다.

단순화된 스택

단순화를 위해 플랫폼 인프라를 제외하고 있습니다.

위의 요소를 살펴보면 각 계층의 전문가가 되는 것이 어려울 것이라는 점은 분명합니다. 그러나 각 계층의 모든 것을 알 필요가 없다고 가정하면 필요한 지식을 줄이고 풀 스택으로 간주할 수 있습니까? 프런트엔드 앱을 예제 도메인으로 사용하면 Android 및 iOS를 쉽게 제거하고 웹 채널에만 집중할 수 있으며 더 세분화하여 React로 제한된다고 말할 수 있습니다. 어떻게 도움이 됩니까?

축소된 범위에 따라 React 웹 앱에 대해 알아야 할 사항은 무엇입니까?

먼저 단일 페이지 앱이 작동하는 방식, 특히 웹 앱을 빌드, 디버그 및 실행하는 데 필요한 핵심 원칙과 관련 도구(예: npm, webpack, 콘텐츠 관리, react devtools, UX 지침 등)를 이해해야 합니다.

또한 재료 UI, redux, 부트스트랩 등과 같은 타사에서 제공하는 기능과 npm과 같은 패키지 관리 솔루션(보안 취약성 관리 포함 - 일반적으로 DevOps 고려 사항, 이후 참고 사항 참조)에 매우 익숙해야 합니다.

성능은 어떻습니까? 예를 들어 콘텐츠가 있는 첫 번째 페인트 시간, 대화형 시간, 차단 시간, ... 프로그레시브 웹 앱 아키텍처 및/또는 서비스 작업자를 채택해야 합니까? 성능 요소와 다양한 핵심 패턴이 분석을 지원하는 도구(예: React DevTools 또는 Lighthouse)를 활용하는 데 어떻게 도움이 되는지 이해해야 합니다.

접근성은 앱이 내부적으로 제공되든 외부적으로 제공되든 관계없이 모든 애플리케이션에 필수입니다. WCAG 지침 준수를 어떻게 보장합니까?

요약하면 Front-End 레이어에서 알아야 할 것이 많고 틀림없이 이것은 그것을 가볍게 유지하고 있습니다. 나머지 레이어는 다르지 않으며 많은 경우 복잡성이 증가합니다. 설상가상으로 아키텍처 패턴과 원칙, 모범 사례 및 프레임워크는 겹치지 않습니다 .

그래서 각 계층에 대한 패턴, 표준, 모범 사례 및 실습 기술을 머리 속에 집어넣었다고 가정하면 그 밖에 무엇을 알아야 할까요? 필요한 지원 기능이 있습니까?

지원 기능

기술 스택 옆에는 솔루션의 모든 구성 요소를 설계, 구축, 제공 및 실행하는 데 필요한 다양한 지원 기능이 있습니다.

건축·SW공학

모든 언어/프레임워크에서 우수한 구현을 생성하는 계층 전체에서 아키텍처 설계를 지원하는 핵심 기술 세트

• SOLID(단일 책임, 개방/폐쇄, 대체, 인터페이스 분리, 종속성 반전)
• 'illities' 재사용성, 유지보수성, 이식성, 확장성, …
• 수평 및 수직 스케일링
• 코딩 구조
• 벌채 반출
• 코드 리뷰
• …

위의 단순화된 스택에서 각 계층 내의 각 계층 및 구성 요소(웹 채널 관점에서 프런트 엔드는 브라우저에 의해 구현되거나 일반적으로 클라이언트 측이기 때문에 제어할 수 없기 때문에 무시)는 보안 관점에서 신중한 고려가 필요합니다. 예를 들어

• API : TLS, DDoS, 인증 및 권한 부여, COR, 콘텐츠 보안 정책, …
• 마이크로 서비스: TLS(MA 포함), 액세스 제어, 비밀 관리, 사용자 입력 유효성 검사, …
• 데이터 : 액세스 제어, 미사용 암호화, 키 관리, 네트워크 보안 그룹 및 서브넷, …
• 플랫폼(추가) : 네트워크 보안, 고정 구성 요소 구성(예: ChefInspec)

모든 개발자는 핵심 테스트 기술이 필요하며 자신의 기능을 테스트할 수 없다는 변명의 여지가 없습니다. 그리고 전체 스택 환경에서는 위 다이어그램의 모든 구성 요소를 의미합니다.

시험의 다양한 유형과 단계를 이해하고 적용할 수 있음(숙제를 채점하지 않음):

• 기능 및 비기능
• 블랙박스 vs 화이트박스
• 단위, 통합, 시스템, 사용자 수용, 회귀, 스모크, …

지속적인 통합 및 지속적인 배포 파이프라인 개발 및 유지 관리

CICD의 핵심 인에이블러는 종종 중앙 집중식/전담 팀에서 생성되지만 모든 사람이 최소한 파이프라인을 업데이트하고 유지할 수 있어야 합니다. (예, 알고 있습니다. DevOps 팀이 있는 경우 DevOps를 수행하지 않지만 많은 조직에서 수행합니다.)

다음과 같은 도구 사용:

• Jenkins, TravisCI, Spinnaker
• GitHub, 비트버킷
• 소나큐브
• 자프록시
• 베라코드, 스닉크
• 도커, 앵커, 하버
• …

"구축하고 실행"하는 접근 방식을 무시하면 운영과 관련된 전체 스택 개발자의 요구 사항이 크게 단순화됩니다.

작동 가능하도록 애플리케이션을 구축하는 데 초점을 맞춰야 합니다. 실행 팀이 개발 팀의 도움을 받지 않고도 문제를 분류하고 잠재적으로 해결할 수 있도록 필요한 모든 진단 후크, 이벤트 로그 및 실행 책을 포함합니다.

물론 위의 기능에 대한 책임은 조직이 관리되는 방식에 따라 달라질 수 있습니다. 개발이 엄격하게 단위 테스트만 수행되거나 보안 테스트를 제외한 모든 테스트가 스크럼 팀 내에서 수행될 수 있습니다. 그러나 다른 사람의 지원 없이 API 개발 및 CICD 파이프라인 관리를 맡을 수 있다면 많은 시간을 절약할 수 있습니다.

기술 스택의 계층과 마찬가지로 전체 스택 상태를 주장하는 데 필요한 지원 기능의 범위는 방대합니다.

결론

나는 진정한 풀스택 개발자가 (대부분) 신화라고 믿으며 스택이 1980년대에 6502에서 어셈블러를 실행하는 것 이상으로 발전한 이후로 계속 그러했습니다. K8 노드에서 실행되는 노드로 작성된 몇 가지 API와 대화하면서 프론트엔드를 가져오고 실행하는 것이 풀스택 개발자라는 생각에 속지 마십시오.

이러한 개인은 서로 다른 기술 영역에서 필요로 하는 지식과 경험의 깊이뿐만 아니라 이 범위가 계속 증가하고 있기 때문에 신화적입니다. 현재까지는 매우 매우 어렵습니다.

또한 이러한 개인은 일반적으로 대부분의 IT 조직이 지불할 수 있는 것보다 더 많은 돈을 요구할 것입니다.

나는 당신이 달성하기를 바랄 수 있는 최선은 당신이 선택한 도메인(해당 계층 내에서 제한된 기술 스택을 가진 특정 계층)의 숙달과 기껏해야 다른 영역에 대한 지식 부족에 대한 역량과 인식이라고 제안합니다.

팀이 성공하는 더 좋은 방법은 풀스택 개발자를 모집하거나 교육하는 것이 아니라 프론트엔드, 백엔드, 데이터베이스 등과 같은 도메인을 만들고 주어진 도메인 내에서 닌자 수준의 지식을 얻기 위해 노력하는 것입니다(역시 스택은 제한됨) 고품질 개발을 지원하기 위해 매우 명확한 인터페이스, 표준, 모범 사례 및 프레임워크를 사용하여 다른 도메인에 대한 중복/교차 지식을 사용합니다. 개인이 전문가 수준에서 여러 도메인에 걸쳐 있을 수 있다면 훌륭하지만 내 경험으로는 이것은 정말 예외입니다.

보너스 코멘트:

데이터 과학 개발자로서 "더욱" 성공하기 위해 알아야 할 사항은 무엇입니까? 거기에서 당신을 도울 수 없습니다!). 이 개발자를 이러한 각 영역에서 개발할 수 있지만 데이터 과학 부분*의 전문가(즉, 위의 축소된 목표)로 정의하면 더 넓은 스택의 산업화는 머신 러닝 엔지니어가 할 일입니다. 하지만 그 논의는 다른 시간 동안.

*단순화된 스택에서 모델이 마이크로서비스 비트에 들어간다고 말할 수 있습니다.