개발공부 기록지

목차

• 탄생 배경
• 사용하는 이유
• 장점 단점
• E2E 테스트와의 차이점

요약: Layer 테스트는 빠른 피드백, 문제의 원인 파악, 코드 안정성, 테스트 범위 확장 등을 제공하여 E2E 테스트와 상호 보완적으로 동작합니다. Layer 테스트는 기능과 성능을 빠르게 검증하는 데 유리하고, E2E 테스트는 최종 사용자 경험을 보장하는 데 필수적입니다.

1. 탄생 배경

Layer 테스트는 소프트웨어가 복잡해지고 규모가 커지면서 등장했습니다. 기존의 E2E 테스트만으로는 충분한 검증이 어려웠고, 특히 애플리케이션이 여러 계층(컨트롤러, 서비스, 리포지토리 등)으로 나뉘면서 각 계층을 개별적으로 테스트할 필요성이 제기되었습니다. 더불어 빠른 피드백을 제공하고 문제를 효율적으로 디버깅하기 위해 Layer 테스트가 도입되었습니다.

2. 사용하는 이유

1. 복잡성 증가에 따른 필요성
   • 현대 소프트웨어는 점점 복잡해지면서 여러 계층(예: 컨트롤러, 서비스, 리포지토리)으로 나뉘어 설계됩니다. 각 계층의 기능을 개별적으로 검증해야 각 계층이 올바르게 작동하는지를 보장할 수 있기 때문에 Layer 테스트가 필요합니다.
2. 빠른 피드백 제공
   
   • Layer 테스트는 특정 계층만 테스트하기 때문에 훨씬 빠르게 완료됩니다. 이를 통해 빠른 피드백을 받고, 수정해야 할 부분을 신속히 개선할 수 있습니다. 
3. 문제의 원인 파악이 용이함
   • E2E 테스트에서 에러가 발생할 경우, 문제의 정확한 원인을 찾기 어렵습니다.
   • Layer 테스트는 각 계층을 독립적으로 검증하기 때문에, 특정 계층에서 문제가 발생했을 때 이를 신속하게 식별할 수 있습니다.
   • 이러한 방식은 디버깅을 효율적으로 만들어 문제 해결 시간을 단축시킵니다.
4. 세부적인 기능 검증
   • Layer 테스트는 서비스나 비즈니스 로직 같은 개별 기능을 세밀하게 검증합니다.
   • E2E 테스트에서는 놓칠 수 있는 세부적인 로직을 더 정확하게 확인할 수 있습니다.
   • 각 계층의 로직이 기대대로 동작하는지 보장하여 시스템의 일관성을 높입니다.
5. 유지보수성 향상
   • 코드가 자주 수정되고 기능이 추가되는 상황에서도 안정적으로 시스템을 유지하기 위해 Layer 테스트는 중요한 역할을 합니다.
   • 특정 계층의 변경이 다른 계층에 영향을 미치지 않도록 보장하여 리팩토링 시에도 안정성을 유지할 수 있습니다.
6. 테스트 범위 확장
   • E2E 테스트만으로는 모든 시나리오를 포괄하기 어렵습니다.
   • Layer 테스트를 통해 특정 시나리오나 예외 상황까지 세밀히 검증할 수 있습니다.
   • 이로써 다양한 케이스를 커버하여 테스트의 신뢰성을 높입니다.
7.  테스트 비용 절감
   • E2E 테스트는 리소스를 많이 소모하지만, Layer 테스트는 가볍고 빠르게 실행됩니다. 이를 통해 자주 테스트를 실행할 수 있어 비용이 절감됩니다.
   • 개발 주기를 최적화하고 리소스를 효율적으로 사용할 수 있습니다.
8. 디자인 품질 향상
   • Layer 테스트를 염두에 두고 코드를 작성하면 더 모듈화되고 테스트 가능한 구조가 됩니다.
   • 코드가 더 응집력 있게 설계되며, 가독성과 유지보수성이 향상됩니다.
   • 설계 품질이 높아지면 향후 확장성에도 유리합니다.

3. 장점과 단점

장점

• 빠른 테스트 속도:  E2E 테스트보다 실행 속도가 빠릅니다.
• 효율적인 디버깅:  문제가 발생할 때 정확한 계층을 쉽게 파악할 수 있습니다.
• 높은 테스트 커버리지: 특정 비즈니스 로직이나 예외 상황을 세밀하게 테스트할 수 있습니다.
• 디자인 품질 향상: Layer 테스트를 염두에 둔 코드는 더 모듈화되고 테스트 가능한 구조가 됩니다.
• 테스트 비용 절감: 더 적은 리소스와 비용으로 빈번한 테스트를 수행할 수 있습니다.

단점

• 제약된 실제 환경 테스트: Layer 테스트는 개별 계층만 테스트하므로 실제 사용자 경험이나 전체 시스템의 통합을 충분히 검증할 수 없습니다.
• 추가적인 코드 작성 필요: Layer 테스트를 작성하기 위해서는 더 많은 테스트 코드와 설정이 필요합니다.
• 복잡성 증가: 각 계층에 대해 별도의 테스트를 작성하고 유지해야 하므로 프로젝트 관리가 복잡해질 수 있습니다.
• 전체 시스템 통합을 검증하는 데 제한적: Layer 테스트만으로는 전체 애플리케이션의 흐름을 보장할 수 없으므로 E2E 테스트와 함께 사용해야 합니다.

4. E2E 테스트와의 차이점

• DTO 유효성 검사는 E2E 테스트에서 실행

목차

• 탄생배경
  • 문제점
  • 탄생 배경및 목적
• 사용하는 이유
• 장점
• 단점

탄생배경

문제

1. 이미지 저장과 관리의 복잡성
   • Docker Hub 같은 퍼블릭 레지스트리에 민감한 이미지 저장 시 보안 취약
   • 사설 레지스트리 운영 시 높은 비용과 관리 부담 
2. 보안 문제
   • 이미지 권한 관리와 암호화가 부족하여 보안 위험
   • 세밀한 접근 제어 및 보호된 레지스트리의 필요성 증가
3. 확장성과 성능의 한계
   • 컨테이너 사용 증가로 대규모 이미지 관리 및 빠른 제공 필요성 증대
   • 기존 레지스트리의 확장성 및 성능 한계
4. AWS 서비스와의 통합 부족
   • Amazon ECS, Amazon EKS와 외부 레지스트리 통합 시 추가 설정 필요

탄생 배경과 목적

• 컨테이너 기술의 발전과 함께, 애플리케이션 배포의 효율성을 높이기 위해 컨테이너 이미지를 안전하게 저장하고 관리할 수 있는 레지스트리의 필요성이 대두
• AWS는 이러한 요구를 충족하기 위해 Amazon ECR(Elastic Container Registry)를 도입하여, AWS 환경 내에서 컨테이너 이미지를 손쉽게 저장, 관리 및 배포할 수 있도록 지원
• ECR을 통해 AWS 사용자는 Docker 이미지를 관리하는 부담을 줄이고, 안전한 방식으로 이미지를 저장할 수 있도록 지원

사용하는 이유

• AWS 통합성:  Amazon ECR은 Amazon ECS, Amazon EKS 등 AWS의 다른 서비스와 원활하게 통합되어, 컨테이너 이미지를 손쉽게 배포하고 관리가능.
• 보안: AWS Identity and Access Management(IAM)를 통해 세분화된 액세스 제어가 가능하며, 저장된 이미지는 자동으로 암호화되어 안전하게 보호
• 관리 편의성: ECR은 완전 관리형 서비스이기 때문에 인프라 관리에 대한 부담이 없습니다. AWS가 자동으로 스케일링하고 관리하므로 사용자는 컨테이너 이미지의 배포와 관리에만 집중할 수 있습니다.
• 확장성 및 신뢰성: Amazon S3를 기반으로 높은 내구성과 가용성을 제공하며, 사용량에 따라 자동 확장이 가능해 대규모 애플리케이션 배포에도 적합
• 관리 편의성: 완전 관리형 서비스로서, 인프라 관리에 대한 부담 없이 컨테이너 이미지를 관리가능

장점

• 간편한 통합: AWS의 다양한 서비스와의 통합이 용이하여, 기존 워크플로우에 쉽게 적용가능
• 보안 강화: IAM을 통한 세분화된 액세스 제어와 자동 암호화를 통해 컨테이너 이미지를 안전하게 보호
• 고가용성 및 내구성: Amazon S3를 기반으로 한 저장소를 통해 높은 가용성과 내구성을 제공
• 자동 확장: 사용량에 따라 자동으로 확장되어, 대규모 애플리케이션 배포에도 대응가능

단점

• 비용: 저장 용량과 데이터 전송량에 따라 비용이 발생하므로, 대규모 이미지 저장 및 빈번한 전송 시 비용이 증가
• AWS 종속성: AWS 환경에 최적화되어 있어, 다른 클라우드 서비스나 온프레미스 환경과의 통합에는 추가적인 설정이 필요
• 퍼블릭 레지스트리와의 비교: Docker Hub와 같은 퍼블릭 레지스트리에 비해 퍼블릭 이미지 공유 기능이 제한적

1. 탄생 배경

기존의 단위 테스트(Unit Testing)와 통합 테스트(Integration Testing)가 가진 한계를 극복하기 위해 만들어졌습니다.

• 단위 테스트(Unit Testing) : 개별 함수나 클래스 등 작은 코드 단위를 테스트
  • 한계점
    • 시스템 전체의 흐름이나 상호작용을 확인하기 어려움
    • 실제 사용자 시나리오를 반영하지 못함
• 통합 테스트(Integration Testing): 여러 모듈이나 컴포넌트를 통합한 테스트
  • 한계점
    • 전체 시스템 관점에서의 테스트 부족
    • 외부 시스템과의 연동 문제를 발견하기 어려움

두 테스트의 주요 문제점

• 전체 시스템 흐름 검증 부족
• 사용자 관점 부재
• 시스템 간 의존성 문제 - 외부 시스템, API, 데이터베이스와의 연동에서 발생하는 의존성 문제
• 데이터 무결성 확인 어려움 -  시스템 전반에 걸친 데이터 흐름을 확인하기 어려움
• 복잡한 버그 미검출  - 여러 모듈과 컴포넌트의 상호 작용에서 발생하는 복잡한 버그

# 모듈(Module)

- 여러 개의 함수나 클래스를 모아 특정 기능을 수행하는 코드의 단위

    (예시) 사용자 관리 모듈: 회원가입, 로그인, 비밀번호 변경 등과 관련된 기능들을 모아 놓은 것

# 컴포넌트(Component) 

- 시스템에서 특정 기능이나 역할을 수행하는 독립적인 단위

- 독립적이고 재사용 가능한 단위로, 하나 이상의 모듈로 구성

    (예시) 인증 컴포넌트 : 사용자의 신원을 확인하고, 인증된 사용자에게 접근 권한부여 (jwt 토큰 발급, 검증 등) 

2. 사용하는 이유

• 전체 시스템 검증: E2E 테스트는 전체 애플리케이션의 기능을 검증하여 시스템이 통합적으로 잘 작동하는지를 확인
• 사용자 경험 반영: 실제 사용자 행동을 시뮬레이션 및 검증하여 시스템의 품질 보장
• 시스템 간 의존성 문제 해결 : 외부 시스템과의 연동에서 발생하는 문제를 효과적으로 테스트
• 데이터 무결성 확인 :  데이터가 시스템 전반에 걸쳐 올바르게 전달되고 처리되는지 검증.
• 복잡한 워크플로우 테스트: 단순한 기능 테스트로는 발견하기 어려운 복잡한 시나리오나 예외 상황을 테스트

즉, 프로덕션 환경에서 발생할 수 있는 문제를 미리 발견하여 배포 후의 리스크를 감소시키기 위해서다.

3. 장점과 단점

장점:

• 사용자 중심의 테스트: 실제 사용자의 행동을 기반으로 테스트하여 사용자 경험을 향상
• 높은 신뢰성: 전체 시스템의 기능을 검증하기 때문에 배포 전에 시스템의 안정성을 높일 수 있습니다.
• 문제 조기 발견: 통합된 환경에서의 문제점을 미리 발견하여 수정 비용을 줄입니다.
• 비즈니스 로직 검증 : 실제 시나리오를 테스트함으로써 비즈니스 로직이 의도한 대로 동작하는지 확인할 수 있습니다.

단점:

• 시간과 비용 소모: 테스트 범위가 넓어 실행 시간과 유지 보수 비용이 증가할 수 있습니다.
• 복잡성 증가: 다양한 시나리오를 커버하려면 테스트 스크립트가 복잡해질 수 있습니다.
• 테스트 불안정성: 작은 UI 변화나 환경 변화에도 테스트가 실패할 수 있어 민감하게 반응합니다.
• 테스트 유지보수 어려움 : 작은 변경에도 테스트 스크립트 수정이 필요할 수 있습니다.

4. 요약

E2E 테스트

• 기존 테스트 방식의 한계를 보완하여 전체 시스템 동작과 사용자 경험을 종합적으로 검증

도입 효과

• 더 나은 품질의 소프트웨어 개발 가능.
• 사용자에게 안정적이고 신뢰성 있는 서비스 제공.

E2E 테스트는 시스템 전체의 품질을 보장하기 위한 중요한 도구이지만, 효율적인 테스트 전략을 수립하여 단점을 최소화하는 것이 중요

탄생배경

전통적인 애플리케이션 배포방식에서 자주 마주하는 문제점 "It works on my machine":

• 개발 환경과 운영 환경의 불일치
• 복잡한 환경 설정과 종속성 관리의 어려움

이러한 문제를 해결하기 위해, 애플리케이션을 어디서나 동일한 환경에서 실행할 수 있는 기술의 필요성이 대두되어습니다.

그 결과, 애플리케이션을 컨테이너로 패키징하여 어디서나 동일하게 실행할 수 있게 해주는 가상화 플랫폼인 Docker 가 탄생하게 되었습니다.

Docker 를 사용하는 이유

장점

• 일관된 환경 제공: 개발부터 운영까지 동일한 환경을 유지하여 환경 불일치로 인한 문제를 최소화
• 신속한 배포 및 롤백: 이미지 기반 배포로 빠른 배포와 롤백이 가능
• 유연한 스케일링: 컨테이너 오케스트레이션 도구(Kubernetes 등)를 사용하여 수요에 따라 쉽게 확장하거나 축소가능
• 리소스 효율성: 시스템 자원을 효율적으로 사용하여 비용 절감에 도움
• 풍부한 생태계: Docker Hub 등 다양한 이미지와 커뮤니티 지원이 활발
• CI/CD 파이프라인 통합 용이

단점

• 보안 문제: 호스트 커널을 공유하기 때문에 가상 머신보다 보안 격리가 약할 수 있음
• 복잡한 관리: 다수의 컨테이너 관리와 오케스트레이션이 복잡할 수 있음.
• 윈도우 지원 제한: 초기에는 리눅스 중심으로 개발되어 윈도우 환경에서 제약이 있을 수 있습니다.
• 디버깅 어려움: 컨테이너 내부의 문제를 진단하고 디버깅하는 데 어려움이 있을 수 있습니다.

Common Use Cases

• Web Applications: Deploying and scaling web applications.
• Microservices Architecture: Building and managing distributed applications composed of small, independent services.
• Data Science: Running data science pipelines and machine learning models.
• Continuous Integration and Continuous Delivery (CI/CD): Automating the testing and deployment of applications.