1970년대에 자라온 사람들에게는 대다수 사무실에서 타자기로 인해 발생하는 딸깍거리는 소리로 가득 차 있었습니다. 나의 성장 시기에는 타자기 실력과 속기 실력이 타자직을 확보하는 데에 중요한 기술들이었습니다.

엔지니어링 부서로 취직하게 되었을 때, 내 부서에는 메모, 공사 입찰서, 프로젝트 견적서, 그리고 고위 엔지니어들이 요청하고 따라서 말한 내용을 타자로 옮겨 적는 타자가 있었습니다. 이름은 라지였죠.

라지는 항상 바빴습니다. 그녀의 책상 위에 쌓인 종이들이 그 증거였습니다.

개인용 컴퓨터(PC)가 산업 전반에 빠르게 퍼지기 시작했습니다. 곧 라지도 WordStar라는 워드 프로세싱 애플리케이션이 설치된 PC를 갖게 되었습니다. 키보드와 WordStar와의 짧은 적응 기간 끝에, 라지는 매우 생산적인 업무를 할 수 있게 되었습니다.

Raji가 거의 즉시 생산적이 되게 한 요인은 무엇일까요? 컴퓨팅 파워인가요? WordStar인가요? 아니면 다른 무언가일까요? Raji의 능숙함에 기여한 두 가지 주요 요인이 있었죠.

• Raji의 타자 기술의 기초적인 기량입니다.
• QWERTY 키보드 레이아웃이라는 유산 패턴입니다.

기초기술

학교 교육 과정은 아이들이 읽기, 쓰기, 수리 등과 같은 기본 기술을 발전시키는 데 초점을 맞춥니다. 이러한 기술 없이 교육에서 추가적인 지식을 습득하는 것은 어렵습니다.

이는 직업 및 삶에도 적용됩니다. 소프트웨어 엔지니어링에서 배우는 운영 체제 개념, 인생에서의 자전거 타기, 수영 등은 우리와 영원히 함께 할 수 있으며 다양한 상황에서 적용할 수 있도록 해줍니다.

전이 가능한 기술

이는 하나의 직장에서 다른 곳으로 적용할 수 있는 소프트 스킬입니다. 커뮤니케이션 기술, 관리, 팀워크 등은 종종 전이 가능한 소프트 스킬로 언급됩니다. 그러나 새로운 환경에서 적용할 수 있도록 적응할 수 있다면 어떤 기술이든 그에 해당할 수 있습니다.

예를 들어, 웹 서비스를 개발하고 SOAP 프로토콜과 XML에 친숙한 경우가 있다고 가정해 봅시다. 새로운 RESTful 서비스를 개발하고 JSON을 사용하는 팀으로의 지식 전이를 통해 웹 서비스에 대한 지식을 확장할 수 있습니다.

기초적인 기술이 중요합니다

경험 많은 타자로서, 라지는 현대 기술로 이동할 때 기초적인 스킬인 타자 실력을 갖고 있었습니다. QWERTY 키 레이아웃에 익숙하여 라지의 타수는 승화되었고, 그녀의 전환은 성공적이었습니다.

종종 오래된 기술을 다루는 엔지니어들은 더 현대적인 기술로 이동할 때 자신이 갖고 있는 기술과 가치를 인지하지 못해 너무 빨리 포기하는 경우가 많습니다.

유산이 될 수도 있는 기존 언어들이 있더라도, 여러분의 코딩 스킬은 중요합니다

프로그래밍 언어의 진화 속도를 고려하면, 현재 존재하는 모든 언어를 배울 수는 없습니다. 여러분이 TypeScript나 Rust에 익숙하지 않더라도, 비즈니스와 프로그래밍 논리를 다룰 기초적인 기술이 있습니다. 올바른 마인드셋을 갖추면 어떤 기술 스택으로도 쉽게 이식할 수 있습니다.

서버리스 전문가들이 함수를 덜 사용하고 로우코드 패러다임을 장려하는 것을 듣고 계셨을 겁니다. 이는 여러분의 효율성이 작성한 코드 라인 수로 측정되지 않음을 의미합니다.

데이터는 증가했지만, 여러분의 데이터 모델링 기술에는 여전히 가치가 있습니다

모든 사람들이 NoSQL을 무시하는 것이 정말 쉬운 것으로 여기지 마세요. 여러분의 수 년 간의 SQL 전문 지식이 아무런 가치가 없다고 생각하지 마세요. NoSQL 데이터 스토어를 효율적이고 비용 효율적으로 사용하기 위해서 데이터를 구조화하고 저장하며, 올바른 인덱스를 식별하고, 가장 빠른 데이터 액세스 패턴을 고안하며, 기타 작업을 수행하기 위해서 데이터 모델링, Entity 관계, 정규 형태 등의 기본적인 기술들이 중요해집니다.

어떤 시대에도 분석 및 설계 기술은 항상 중요합니다!

현재 기술 세계를 조사하면 Domain-Driven Design (DDD)의 우세함을 알 수 있습니다. 에릭 에반스(Eric Evans)의 DDD 책이 20년 전에 출판된 뒤로 한 번도 수정되지 않았음을 알고 계셨나요?

Structured Systems Analysis and Design Method (SSADM), Object-Oriented Anaylsis and Design (OOAD), Object Modeling Technique (OMT), 또는 Unified Modeling Language (UML)로 경력을 시작했던 여러분, DDD를 적용하거나 서버리스(serverless)를 위한 솔루션 설계를 만드는 데 필수적인 분석적 사고 능력을 가지고 있다는 이점이 있습니다.

위에 언급된 내용은 몇 가지 중요한 영역입니다. 귀하의 전문 기술을 평가하는 가장 좋은 방법은 이력서를 살펴보고 현대 기술 세계에서의 핵심 및 이전 가능한 기술을 식별하는 것입니다.

레거시는 쓰레기가 아닙니다

나는 이 글을 쓰는 순간 2020년대 노트북 키패드가 1870년대 QWERTY 레이아웃을 가지고 있습니다. 내 노트북에는 몇 가지 현대적인 기능이 있지만, 그 핵심 기능은 과거의 혁신에 기초를 두고 있습니다 - 레거시지만 기본적이고 핵심적인 기술들이죠!

레거시란 무엇인가요?

앱 개발에서 '레거시(legacy)'라는 용어를 자주 사용하지만, 이것을 레거시와 비레거시로 명확히 구분하는 것은 혼란스러울 수 있습니다. 사전에 따르면 레거시는 우리 역사의 일부이거나 이전 시대의 것이라고 명시되어 있지만, 오늘 우리가 하는 모든 것이 내일의 역사가 된다면, 레거시는 항상 함께합니다.

업계에서 유명한 다음 문구를 아시나요?

레거시를 스냅샷의 연속으로 바라보세요

레거시가 항상 우리와 함께하기 때문에 그것을 분리하는 것은 도전적일 수 있습니다. 하지만 우리는 그렇게 해야 할 필요가 있을까요?

만약 우리가 이를 다르게 인식하면 어떨까요?

과거를 전체적인 유산으로 보는 것이 아니라, 서로 다른 단계를 유산의 스냅샷으로 보는 것이 어떨까요?

예를 들어, 한 스냅샷은 여러 해나 몇 년간의 시간, 고용주와 보낸 시간, 경력에서 맡은 직책, 또는 특정 기술로 한 작업 등이 될 수 있습니다.

각 기간 내에서 획득한 기본 기술 및 이전가능한 기술을 파악하고, 적응을 거치든 그렇지 않든 성공적으로 이전한 기술을 평가해보세요.

레거시를 인정하되, 너무 편안해지지 마세요!

과거를 인정하고 축적한 기술을 알아봐야 하는 것은 중요하지만, 더 중요한 것은 현재와 미래를 주시하고 그 방향으로 커리어를 향해 나아가는 것입니다.

기술적인 진화가 빠르고 지속적으로 변화함을 알고 계십니다. 이 속도 때문에 우리는 학습, 학습 해제, 회사 입사, 퇴사, 기억하고 망각하는 등 다양한 산업 단계를 거치게 됩니다. 트렌드, 사용률, 인기도 등에 따라 많은 기술을 배웠다가 잊었다가 해야 하는데, 지나치게 과거의 기술에 갇히지 않도록 하는 것이 매우 중요합니다. 그렇게 되면 언젠가 매우 레거시한 느낌이 들게 될 것입니다.

서버리스에 대한 준비

서버리스 개발을 준비해보세요!

이 블로그를 읽는 당신, 이미 서버리스에 대한 준비가 시작되었습니다! 새로운 기술이나 서버리스와 같이, 서버리스를 이해하고 배우며 작업하기 위해서는 여정을 위한 정신적 및 기술적 준비가 필요합니다.

기술적 마음 가짐 조정하기

서버리스를 배우고 성공적으로 적용하기 위해서는 지난 시간의 사전에 구축된 생각 중 일부를 변경해야 합니다. 서버리스의 독특한 특성 때문에 정신적인 준비, 마음가짐 변화, 또는 마인드 쉬프트가 필요합니다. 서버리스 애플리케이션을 개발하고 운영하기 전에 이러한 것들을 이해하는 것이 성공하기 위해서 필수적입니다.

책 AWS에서의 서버리스 개발(오라일리, 2024년)에서 Luke Hedger와 저는 '서버리스로 생각하기'에 대한 준비 방법에 대해 논의했습니다.

서버리스의 특징들

다음은 주로 서버리스의 기술적 측면과 관련된 것들입니다.

• 사용량에 따른 요금 지불: AWS Lambda와 같은 순간적인 서비스의 경우, 호출 및 RAM 사용에 대해 지불합니다. 몇몇 관리되는 서비스의 경우, API 호출에 대해 지불합니다.
• 저장 공간에 대한 요금 지불: Amazon S3와 같은 관리되는 서비스의 경우, 매달 저장하는 데이터 양에 대해 지불합니다.
• 자동 확장: 사용량 수요에 따라 확장 또는 축소할 수 있는 능력.
• 제로로 확장: 예를 들어 Lambda 함수는 일정 기간 동안 요청이 없을 때, Lambda 서비스가 자원을 회수합니다.
• 높은 가용성: 서비스의 중복성 및 가용성 영역(AZs) 간 데이터 복제를 통해 단일 장애 지점을 피합니다.
• Cold start: 일반적으로 Lambda 함수와 관련이 있으며, 함수가 실행될 환경을 프로비저닝하는 초기 시간을 의미합니다.

서버리스의 혜택들

위에서 본 서버리스의 특징은 아래 강조된 혜택에 기여합니다.

• 자원의 세분화: 응용 프로그램에서 각 자원을 개별적으로 구성할 수 있는 능력은 서버리스의 강점입니다.
• 더 깊은 보안과 데이터 프라이버시: 자원의 세분화를 통해 서비스를 호출하거나 데이터에 접근하는 권한을 자세히 설정할 수 있습니다.
• 최적화 유연성: 응용 프로그램의 각 서버리스 자원은 비용, 성능, 지속가능성 또는 그 조합에 맞게 최적화될 수 있습니다.
• 반복 개발에 이상적: 사전 투자나 자원 프로비저닝이 필요 없어 개발을 계획하고 점진적이고 반복적으로 진행할 수 있습니다.
• 다양한 엔지니어링 팀을 촉진: DevOps 마인드셋으로, 서버리스 엔지니어는 함수 작성, 데이터 구조 설계, 애플리케이션 보안, 인프라 코드 작성 등 다양한 작업을 수행합니다.

서버리스는 기술 이상을 내포합니다.

특정 언어의 장기 프로그래머에서 서버리스로 전환하면 FaaS(Function as a Service)에 끌리게 되어 람다 함수를 작성하기 시작할 수 있습니다.

이 모든 것을 넘어섰어요. AWS에서 Serverless Development에 대해 이야기할 때, 우리는 서버리스를 생태계와 연관시킵니다. 서버리스 기술과 그 필수 요소들을 다루기 시작할 때, 이 깨달음은 중요합니다.

누가 서버리스 엔지니어인가요?

서버리스 엔지니어라는 용어는 지금 상당히 인기가 있죠, 적어도 취업 시장에서 말이에요! 소프트웨어 엔지니어와 크게 다르게 들리지는 않을 수 있지만, 위에서 서버리스에 필요한 필수 사항을 보았듯이, 특정 속성들은 서버리스 엔지니어에게 독특하게 속해 있고 서버리스 생태계에 속하게 됩니다.

제가 여러 블로그를 작성하여 여러분의 마음을 갖추고 서버리스 여정에 대비할 수 있도록 도와드렸어요.

서버리스로 무게 감아보세요

서버리스와 그 도구들, 기술들의 생태계에 맞춰 마음이 한쪽으로 기울면, 자신을 서버리스에 적응시키는 것이 쉬워집니다.

몇 가지를 살펴보고, 서버리스와 어떻게 관련시킬 수 있는지 살펴보겠습니다.

클라이언트/서버 아키텍처는 물리적 계층을 가진 1990년대에 인기를 끌었습니다. 마이크로서비스 이전에도 엔지니어들은 인터페이스를 통해 통신하는 모듈화된 시스템을 구축했습니다. 이러한 기술을 서버리스와 마이크로서비스로 전이시킬 수 있습니다.

• Domain-Driven Design에 의해 널리 알려진 비즈니스 도메인과 그들의 구분을 이해하고, 도메인 경계 내의 소프트웨어 구성 요소를 매핑합니다.
• 구성 요소 간의 강력한 의존성을 피하면서 느슨한 결합과 독립적인 배포 가능성을 촉진합니다.

만약 여러분이 소프트웨어 시스템의 물리적 계층과 각 계층 내 구성 요소의 논리적 층에 익숙하다면, 다음 필수 사항을 통해 클라우드 시대의 분산 시스템을 이해에 가까워진다.

• 각 지역의 클라우드 리전과 데이터 센터 존의 분포에 대한 지식이 필요합니다. 서버리스에서는 여러 계층에 걸쳐있는 분산 애플리케이션을 구축하지만 시스템 아키텍처에 따라 단일 계정에서 한 리전 또는 여러 계정과 리전의 혼합에 배포될 수 있습니다.
• 관리형 클라우드 서비스를 사용하는 경우 물리적 계층과 논리적 층의 명확한 분리를 얻지 못할 수 있지만 클라우드 제공업체가 이를 처리합니다.

서비스 지향 아키텍처(SOA)는 서비스를 제공하는 소프트웨어 컴포넌트를 메시지 브로커나 버스를 통해 통신하도록 하는 방식입니다. 비즈니스 애플리케이션을 구축하기 위해 이 방법을 사용할 수 있습니다. SOA는 여전히 인기가 있으며, 여러분의 SOA 기술은 쉽게 마이크로서비스, 이벤트 주도 아키텍처, 이벤트 버스, 클라우드, 서버리스 등으로 전이될 수 있습니다.

**BPEL (Business Process Execution Language)**은 비즈니스 프로세스를 조율하는 데 사용되는 표준으로, 주로 웹 서비스를 활용합니다. 이 기술은 이미 20년이 넘었죠. 클라우드에서 운영되는 워크플로 서비스나 AWS Step Functions과 같은 조율 서비스와 연관 짓기 쉽습니다.

위에서 간략히 언급했지만, 과거의 여러 기술과 기술적 개념은 서버리스로 쉽게 전환될 수 있습니다. 이는 서버리스의 해안으로 여행하기 위해 다리를 건너는 것과 같은 일입니다.

늦었다고 생각하지 말고

학습에는 만료 기간이 없습니다.

특정 개념이나 기술이 시간이 흐름에 따라 인기가 떨어지거나 가치가 줄어들더라도, 그것과 작업했을 때 기본적이고 이전하지만 가능성 있는 기술을 담고 있을 수 있습니다. 그러한 기술을 간직하세요.

만약 어제가 레거시라면, 당신의 오늘을 활용하여 내일의 기술을 습득하고 평가하고 전달하는 데 기술을 활용하세요.

서버리스로의 여정도 예외는 아닙니다.

계속 전진해 나가세요!

서버리스 개발에 관한 책인 'Serverless Development on AWS' (O'Reilly, 2024)에서 Luke Hedger와 저는 소프트웨어 엔지니어링의 기존 시대에서 서버리스 기술의 진화를 논의하며, 과거 기술 스킬을 서버리스로 전환하는 방법을 설명하고 있습니다.