A few years back, I had the opportunity to interview a candidate for a serverless team specializing in microservices. The individual before me was a highly skilled serverless engineer.

As our discussion progressed, we delved into the topic of teamwork.

Me: How would you describe your collaboration with QA engineers?

후보자: (헷갈려하는 표정으로… 며칠 후에) 음… 죄송합니다만, QA 엔지니어가 저희 팀에 없어서 이 질문에 대답할 수 없어요.

저: (놀람을 감추며) 아, 알겠어요. 괜찮아요. 그러면 QA 업무는 누가 수행하나요?

후보자: 저희는 5명의 엔지니어로 구성된 팀인데, 모두가 QA 업무를 나눠서 맡고 있어요!

시간이 부족해 대화를 마무리했지만, 백엔드 서비스 개발에 초점을 맞춘 서버리스 팀에서 QA 엔지니어의 역할과 필요성을 분석하기 위해 노력을 계속했습니다.

QA의 다양한 모습

품질 보증(Quality Assurance, QA)는 제품의 특성을 명시된 명세와 비교하여 원하는 품질을 얻을 수 있도록 보증하는 과정입니다.

예를 들어 제조업에서 제품의 품질은 생산 파이프라인의 각 단계의 품질에 기인합니다. 원자재부터 부품, 가공 공정, 포장까지 모든 단계의 품질이 영향을 미칩니다.

소프트웨어 품질 보증(Software Quality Assurance, SQA)

소프트웨어 엔지니어링에는 QA(품질 보증)가 원래 포함되어 있지 않습니다. 소프트웨어 품질 보증(SQA)는 소프트웨어 산업에서 QA 프로세스를 전문적으로 다루는 것으로 소프트웨어 개발 과정에서 품질 활동에 특화된 개념입니다.

제조업과 같이, SQA는 소프트웨어 개발의 각 단계가 표준을 준수하며, 품질 기준을 충족시키며, 전체 소프트웨어 개발 라이프사이클 전체에 걸쳐 병행되도록 보장합니다.

소프트웨어 테스트는 SQA의 하위 세트에 해당하며, 전체 SQA의 일부분에 불과합니다.

보증과 엔지니어링

만약 SQA가 원칙, 절차 및 프로토콜에 관한 것이라면 Software Quality Engineering (SQE)는 SQA 프로세스를 수행하는 역할을 맡고 있습니다.

컴퓨터 프로그래머(프로그래머), 소프트웨어 개발자(개발자) 및 소프트웨어 엔지니어를 구별하기 어려운 경우가 종종 있습니다. 마찬가지로 QA의 역할과 책임을 정의하는 것도 어려운 일입니다.

엔지니어링과 테스팅

과거에는 폭포수 모델의 순차적 소프트웨어(시스템) 개발 수명주기(SDLC)에서 요구 사항, 분석, 설계, 코딩, 테스트, 릴리스 및 유지보수와 같은 구분된 단계가 있었으며, 이는 몇 달이나 몇 년이 걸리는 작업이었습니다.

QA 팀의 전문가들은 품질 프로세스, 감사 절차, 규정 준수, 그리고 소프트웨어 테스트를 수행하며 품질을 확보했습니다. 테스트는 QA의 일부로, 이를 수행하는 사람들은 소프트웨어 테스터 또는 테스터들로 불리기도 합니다―때로는, 테스트 엔지니어들로도 불렸죠!

클라우드 네이티브의 확산과 함께 빠르게 변화하는 테스트 랜드스케이프

기술의 진화로 수십 년간의 시간이 흘러, 새로운 개발 및 운영 모델이 등장하며, 민첩성, 자율성, 그리고 가속화를 가져왔습니다.

현대 소비자들을 사로잡기 위해 기업들은 신속한 업무 흐름, 속도, 그리고 가치 창출을 경영 핵심 가치로 삼고 있습니다. 이는 전통적인 계층 구조에서 일원화되고 협력적인 팀으로의 전환을 요구했습니다.

퀄리티 게이트 — 스피드 브레이커

워터폴 모델은 각 단계의 끝에서 품질 검사를 실시했습니다. 이를 품질 게이트 또는 QA 게이트라고 합니다. 예를 들어 소프트웨어 릴리스의 경우 테스팅 단계의 끝에 QA 팀의 승인이 필요했는데, 이를 QA 서명 프로세스라고 했습니다.

QA 서명의 목적은 좋았지만, 빠르게 진행되는 개발 환경에서 일을 늦추는 결과를 가져왔습니다.

사일로 철거의 성공

과거의 고립된 팀으로부터의 전환은 협업과 비즈니스 결과에 뚜렷한 혜택을 가져왔습니다. 그러나 산업 내 다른 여러 요소들도 성공에 기여했습니다.

• 점진적이고 반복적인 개발의 민첩성.
• 비즈니스 도메인과 경계된 맥락을 식별하는 도메인 주도 설계의 영향.
• 자율적인 두 피자 팀의 효율성.
• 데브옵스 운동의 힘.
• 서비스 소유 문화 - 당신이 만들면 당신이 운영하세요.
• 마이크로서비스의 장점.
• 이벤트 주도 아키텍처와 분산 시스템의 수용.
• 클라우드 운영 모델의 확산.
• 다재다능한 팀의 해결사 변신적 태도.

역할의 변화

클라우드의 채택은 많은 사람들의 사고를 바꾸었습니다. 클라우드 운영 모델의 공동 책임은 팀이 일부를 오른쪽으로 이동시키고 다른 일부를 왼쪽으로 이동할 수 있게 했습니다.

• 클라우드 공급업체가 관리하는 플랫폼과 서비스에 대한 책임.
• 클라우드 안에서는 소비자들이 배포하고 운영하는 응용프로그램에 대한 책임이 있습니다.

다양한 기술과 자율성을 갖춘 팀들은 배포 파이프라인을 구축하고, 보안 조치를 시행하며, 지속가능한 원칙을 적용하며, 작업 부하를 왼쪽(소프트웨어 엔지니어로) 이동시키는 책임을 갖게 되었습니다.

QA 및 테스팅은 어떨까요?

단위 테스트를 제외하고, QA 엔지니어나 테스터들이 다른 형태의 테스트를 담당하게 됩니다.

워터폴 개발 모델에서 테스터의 역할은 버그를 찾는 것이었습니다. 하지만 애자일과 현대적인 관행으로 접어들면서, 이 접근 방식은 버그를 예방하는 방향으로 전환되었습니다.

서버리스는 더 많은 변화를 가져올 예정입니다!

서버리스와 균형의 사각형!

서버리스는 소프트웨어 개발에 여러 가지 변화를 가져왔습니다. 기술 생태계로서, 이는 관리되는 서비스들의 이벤트 기반 오케스트레이션으로 제품을 본다는 마음가짐의 변화를 요구하며, 인프라 코드와 조화롭게 짜여진 서비스들을 통해 최상의 가치를 제공합니다.

"서버리스 개발을 AWS에서 (O'Reilly, 2024)은 기업을 위해 다학제적인 서버리스 팀을 권장합니다.

다학제적인 서버리스 엔지니어는 이해관계자 요구 사항을 이해하고 아키텍처를 제안하며 단일 목적 함수를 구현하고 마이크로서비스를 구성하며 보안 조치를 통합하며 지속적 관측을 사용하며 프로덕션에 배포하며 그 서비스를 소유합니다.

서버리스에서 일반적인 소프트웨어 테스트

일반적으로 서버리스 엔지니어는 단위 테스트와 필요한 통합 테스트를 작성합니다."

그 외 다른 유형의 테스트는 어떻습니까 — 부하, 성능, 계약, 수용, 엔드 투 엔드 등?

부하 테스트는 드물지만 특별한 경우에 존재합니다. 클라우드와 서버리스로 인해 고가용성 및 자동 확장을 위해 구축된 서비스들과 작업하게 됩니다.

성능 테스트는 관련이 있지만, 어디서 어떻게 진행할지는 애플리케이션 환경에 따라 다릅니다.

현대 아키텍처로 인해 엔드 투 엔드 테스트의 개념이 변화했습니다. 서버리스에 대한 테스트를 논의할 때, AWS의 Serverless Development은 다음과 같은 질문을 던집니다:

서버리스 균형의 사각형

서버리스 애플리케이션을 여러 독립된 마이크로서비스로 구축하는 것에는 타당한 이유가 있습니다. 그러나 이벤트 기반 및 분산 애플리케이션을 만들 때는 모든 것을 지속적으로 테스트할 수 없다는 점을 염두에 두어야 합니다.

AWS에서 소개된 서버리스 개발의 균형의 사각형 개념은 네 가지 주요 활동을 보여줍니다:

• 테스트,
• 전달,
• 관찰, 그리고
• 복구.

서버리스 개발에서 중요한 것은 충분한 테스트와 감시 메커니즘 및 오류 복구입니다. 지나치게 많은 테스트와 복잡한 테스트 스위트 및 프레임워크를 추가하여 100% 테스트 커버리지를 달성하는 전통적인 접근법은 팀의 속도를 지연시킬 뿐입니다.

서버리스 팀에서 QA 전문가의 역할

소프트웨어 테스트 전문 지식을 가진 품질 보증 엔지니어는 Selenium 및 Cypress와 같은 테스트 프레임워크를 사용하여 테스트 전략을 작성하고 테스트 케이스를 디자인하며 테스트를 구현합니다.

하지만 사용자 경험 요소가 전문가 및 자동화된 스크립트에 의해 검사되어야 하는 경우, 번거로운 테스트 프레임워크를 사용할 필요성은 낮을 것입니다.

그러니까, 서버리스 팀에서 테스트 프레임워크 스킬이 필요할까요?

서버리스 팀에서 기대되는 테스트 스킬

빠르게 움직이는 백엔드 서버리스 팀의 엔지니어들은 클라우드와 그 다양한 서비스, IaC 도구 및 관련 주제에 대해 알아야 합니다. 더 많은 팀이 실제 클라우드 서비스를 테스트에 활용함에 따라, QA 엔지니어들은 서버리스 엔지니어들과 마찬가지로 서버리스에 대해 충분한 지식을 요구합니다.

서버리스와 QA 엔지니어 아키타입 간의 기술 간극을 좁힌다면 분리가 유익한가요?

모든 비즈니스 논리가 기능 코드에 포함되어 있지는 않습니다

서버리스 응용 프로그램에서 비즈니스 논리는 단순히 기능으로 구현되는 것이 아닙니다. 서비스 조정, 통합 및 인프라도 역할을 할 수 있습니다.

서버리스 엔지니어들이 기능 코드에 대한 단위 테스트를 수행하는 반면, 다른 형태의 테스트에는 클라우드 서비스와 인프라에 대한 상당한 지식이 필요합니다. 전통적인 QA 전문가들은 이를 갖추지 못하는 경우가 많습니다.

API 테스트는 어떠세요?

서버리스 팀이 모두 API를 소유하는 것은 아닙니다. 그러나 API 테스트는 QA 엔지니어들이 주로 초점을 맞추는 분야입니다.

API 테스트는 QA 작업이어야 할 필요는 없습니다. 서버리스 팀의 모든 구성원은 이를 수행할 수 있어야 합니다.

뿐만 아니라 대부분의 팀은 포스트맨(Postman), 카탈론(Katalon), HHTPie 또는 다른 도구를 사용하여 수동 및 자동 테스트를 위해 컬렉션을 레포지토리에 유지합니다.

QA-Gate에서 PR-Gate로

요즘 팀들은 지속적 배포(CD)를 실천하고 있지만 많은 팀이 작업 방식에서 PR-Gate 정책에 갇혀 있습니다.

PR(Pull Request)을 제출하는 서버리스 엔지니어는 QA 엔지니어가 변경 사항을 테스트 환경에 배포하고(대부분 수동으로) 테스트를 수행하여 승인하기를 기다려야 해서 지연이 발생합니다.

위의 내용은 인기 있는 Lean 운동의 가치 스트림 맵핑에서 추가 가치 시간에 대한 대기 시간을 나타냅니다.

블러링된 QA 프로세스와 책임

기술의 발전과 사용자 요구의 증대로 자율 팀의 작업 방식이 변화하고 있습니다. 속도의 필요성은 자동화로 이어지며 이는 하루에 여러 번의 수정 및 기능 릴리스를 가능하게 합니다.

지속적인 관찰은 자율 팀이 작업량을 운영하는 일부입니다. 서버리스 균형의 사각형을 달성하기 위해 엔지니어들은 자신의 응용 프로그램을 위한 사이트 신뢰성 엔지니어(SRE)로 행동합니다.

수동 테스트가 부분적으로 필요하지만, 이를 기본 옵션으로 고려해서는 안 됩니다.

제 7장, AWS에서 서버리스 개발에서 서버리스 응용 프로그램을 테스트하는 방법을 소개합니다.

서버리스에서 테스트하는 것을 옹호하는 사람들은 누구일까요?

서버리스 응용 프로그램을 테스트하는 방법에 대해 많은 의견이 있습니다: 이 방식으로 하든가, 저 방식으로 하든가, 간단하게 하든가 복잡하게 하든가, 로컬로 할지 클라우드로 할지, 가짜를 사용할지 실제를 사용할지, 피라미드 모양일지 육각형 모양일지.

하지만 QA 엔지니어나 전문가들이 옹호하는 서버리스 테스트 방법에 대해 들어보셨거나 읽어보셨나요?

왜 그럴까요?

서버리스 애플리케이션을 테스트하는 것은 QA 업무보다는 엔지니어링 업무에 가까운 것일까요?

아니면 서버리스가 QA 세계에 충분한 관심을 끌 정도로 깊게 파고들지 못했기 때문일까요?

확실한 것은 백엔드 서버리스 팀이 테스팅 방법에 대해 접근 방식을 변경하고 있다는 점입니다. QA 엔지니어의 도움을 받는지 여부에 상관없이요.

그러니까, 당신의 서버리스 팀은 QA가 필요한가요?

옵션은-

A) 네!

B) 아니요!

C) 그것은 상황에 따라 다릅니다!

D) 어쩌면요?

음, 정답은 모두 가능합니다!

당신의 요구사항을 평가하십시오

• 서버리스 팀이 웹 응용 프로그램과 사용자 인터페이스 또는 사용자 경험 컴포넌트를 소유합니까? 그렇다면 해당 영역에 초점을 맞춘 테스트 전문가가 필요합니다.
• 서버리스 팀이 대규모 공유 코드베이스를 사용합니까? 그렇다면 전용 QA 엔지니어를 채용하는 것이 좋은 아이디어일 수 있습니다.
• 서버리스 팀이 작업 부하를 공유 클라우드 계정에서 운영합니까? 그렇다면 테스트에 대한 추가 도움이 유용할 수 있습니다.
• 서버리스 팀이 경계가 불분명한 비즈니스 도메인에서 작업합니까? 그렇다면 추가 테스트와 품질 조치를 통해 계약을 보호하는 것이 필요할 수 있습니다.
• 서버리스 팀이 규제가 엄격한 환경에서 작업합니까? 그렇다면 규정 준수를 보장하기 위해 전문가가 필요할 수 있습니다.

위의 내용은 완전한 목록이 아닙니다. 팀과 기관마다 사용 사례, 도메인 및 기술이 다르므로 경우에 따라 다릅니다.

앞을 보고 변화의 촉진자가 되기

본 문서의 의도는 모든 서버리스 팀에서 QA 활동과 전문가를 제거하는 데 주장하는 것이 아닙니다. 기술과 개발의 변화가 우리에게 기존 관행을 재평가할 수 있는 기회를 제공하는 방식을 조사하는 것입니다.

한 가지 크기가 모든 것에 적합한 것은 아닙니다.

만약 당신의 팀이 두 피자만 먹는 규모로 명확한 경계를 가지고 있으며, 열정적이고 다재다능하며 현실적인 서버리스 엔지니어들로 가득 차 있고, 서버리스 균형의 네모 안에 자신들의 업무를 소유하고 운영하는 이해를 갖추고 있다면, 대담한 실험을 해보세요.

마지막으로, 아이디어와 실험은 기술적 발전과 함께 미래를 위한 적절한 개발 실천 방법과 팀 역동성을 식별하는 데 중요합니다!