DevOps

• 과거 개발의 형태는 운영팀과 개발팀이 철저하게 나눠져 있었음

개발팀(Dev)

• 속도(speed)

운영팀(Ops)

• 안정성(Stability)

• 혼란의 벽(wall of confusion)으로 인한 핑퐁(ping pong) 발생
  → 서비스 지연 발생

• 개발자의 로컬 환경과
  실제 서비스가 돌아가는 프로덕션 환경의 불일치가 원인

이러한 문제를 해결하기 위해 등장한 개념이
데브옵스(DevOps)와 컨테이너(Container)

Docker와 같은 컨테이너 기술을 활용하면
개발 환경을 그대로 패키징하여 서버로 옮길 수 있음 (환경의 표준화)

CI/CD
지속적 통합과 지속적 배포 파이프라인을 구축하면
수동적 배포에 대한 실수를 줄이고 코드의 문제를 자동으로 검증
→ 사용자에게 전달되는 시간을 획기적으로 단축

Batching Problem

배치(batch)
일의 집단 또는 한 묶음을 의미

배칭 문제
소프트웨어를 만들고 배포할 때, 너무 많은 양의 변경 사항을
한꺼번에 (Big Batch) 다음 단계로 넘기기 때문에 발생하는 모든 비효율과 위험

Batching Problem이 미치는 3가지 핵심 포인트

디버깅 불가
100만 줄의 코드 더미 속에서 버그 하나를 찾는 것은 불가능에 가까움

빅뱅 리스크(big bang risk)

협업 파괴
조직 내의 silo 현상 발생

batch size를 최소화하여 수시로 배포하고,
즉각적인 피드백을 받는 small batch 전략으로 해결이 가능

DevOps

(Development + Operation)

• 사용자에게 가치 있는 소프트웨어를 더 빠르고 안정적으로 전달하기 위해
  기획, 개발, 운영 전 과정을 유기적인 흐름으로 통합하는 것

협업(Collaboration)
개발과 운영이 한 팀처럼 생각하고 행동함

지속성(Continuous)
한 번 배포하고 끝이 아니라, 계속해서 개선하고 배포함

가치 전달(Value Delivery)
목적은 코딩이 아니라, 사용자에게 가치를 전달하는 것

• 모든 여정은 개발자가 코드를 push/PR를 보내는 순간 시작됨
  "이 소스 코드를 정말 믿어도 되는가?"

CI(Continuous Integration, 지속적 통합)

• 소스 코드를 검증하는 단계

• 속도와 정확성을 목표로 코드를 지속적으로 통합

정적 검사(static analysis)

• 실행 전 오타나 타입 오류, 혹은 팀의 약속과 다른 코딩 스타일이 있는지
  린트(Lint)와 타입 체크를 통해 수 초 내에 잡아냄

• 실행 환경 없이도 가능하기 때문에 가장 빠른 피드백을 줌

단위 테스트

• Jest 같은 도구를 활용해 각 모듈이 독립적으로 잘 돌아가는지 확인하는 과정

• 외부 의존성 없이 비즈니스 로직의 정확성을 소스 레벨에서 보장하며,
  소스 레벨의 보안 검사도 동시에 이루어짐

통합 검사

• 실제 DB나 API와 연동하여 모듈 간 호흡을 맞춤

해당 과정을 전부 통과해야 CI Gate가 열리고,
도커 이미지(Artifact)가 만들어짐

CD(Continuous Deployment)

• 아티팩트 전달 및 배포
  "이 패키지를 안전하게 사용자에게 보낼 수 있는가?" 에 집중

• 안정성과 신뢰성을 목표로 결과물을 사람들에게 전달

컨테이너 보안 검사

• CI에서 소스 코드를 검사했다면,
  도커 이미지 내부의 OS 레이어나 런타임 의존성에 숨은 취약점은 없는지
  트리비(Trivy) 같은 도구로 검사

E2E 테스트

• 사용자 시나리오 검증

Smoke Test

• 서비스가 정말 살아있는지, 핵심 API가 응답을 주는지 아주 빠르게 확인
  *문제가 있다면 그 즉시 롤백을 트리거

CI vs CD

CD의 두 가지 의미

Continuous Deployment: 지속적 제공

• 배포 버튼만 누르면 바로 실제 서비스가 가능한 상태로 대기시키는 것

• 비즈니스적인 관점에 따라 배포 시점을 조절하고 싶을 때 사용
  마지막 결정은 사람에 의해 내려짐

Continuous Delivery: 지속적 배포

• 사람의 승인 없이 기계의 판단 하에 배포가 이루어짐

Shift Left 활동(Shift Left Testing)

• 테스트와 검증을 개발 주기의 앞단계로 이동시켜 품질을 조기 확보하는 전략

CI

Instant Verification: 코드를 짜는 즉시 테스트 실행

• Static Analysis: 단위 분석
  코드의 스타일과 잠재적 결함을 미리 잡아내는 것
• Unit Testing: 단위 테스트 작성
• Code Review
  동료와 로직을 미리 점검하는 것

CD

Final Safety Net: 실전 배포 전 최종 안전장치

• Staging Deployment: 스테이징 환경 자동 배포

• E2E Testing

DevSecOps
보안 검사까지 왼쪽으로 당기는 개념으로, Shift Left의 일종임

1:10:100 원칙
개발 단계에서 발견한 버그를 수정하는 데에 1원,
통합 단계에서는 10원,
실제 운영 환경에서 발견하면 100원 이상의 비용이 필요함

CI/CD에서 이루어지는 주요 테스트

단위 테스트(Unit Test)

• 소스 코드의 가장 작은 단위인 함수나 메서드가
  의도한대로 정확히 작동하는지 확인
  각각의 부품을 확인하는 것

• 외부 데이터베이스나 네트워크 연결 같은 외부 요인 완전 배제하고
  코드 자체의 로직만 검사

• 실행 속도가 빠르고 오류 발생 시 어느 부분이 문제인지 바로 찾을 수 있음

• 범위가 좁고 비용이 낮으며, 빌드 초기 단계에서 수행됨

"할인율 계산 함수에 만 원을 넣었을 때 9천원이라는 값이 제대로 출력되는가?"

통합 테스트(Integration Test)

• 애플리케이션과 데이터베이스 또는, 외부 API 간의 연결이 원활한지 확인
  서로 다른 모듈들이 결합되었을 때,
  데이터가 올바르게 흐르고 상호작용 하는지 검증

• 컴포넌트 간 연결을 통한 중간 정도의 범위, 실행 속도와 비용이 발생하며, 빌드 후 배포 전에 수행됨

"회원가입을 눌렀을 때, 입력한 정보가 데이터베이스에 정확히 저장되는가?"

E2E(End-to-End) Test

• 실제 사용자 관점에서, 시스템의 처음부터 끝까지 전체 흐름을 시뮬레이션

• 실제 브라우저를 띄워서 마우스를 클릭하고, 텍스트를 입력하는 등
  전체적인 UX, 즉 사용자 경험을 검증

• 실제 서비스 환경과 가장 유사한 환경에서 테스트하기 때문에 신뢰도가 높음

• 시스템 전체를 테스트하기 때문에 범위가 매우 넓고,
  실행 속도가 느리고 비용이 크며, 스테이징 환경 배포 후 수행됨

사용자가 웹 사이트에 접속해서 상품을 검색하고, 장바구니에 담는 등의 UX

Smoke Test

• 새로운 빌드가 배포된 직후, 소프트웨어의 핵심적인 기능들이
  최소한으로 작동하는지 빠르게 확인하는 조기 경보 시스템

• 테스트를 통과하지 못할 시, 개발팀에 즉시 수정 요청

• 핵심 기능만을 테스트하여 범위가 좁고, 속도가 빠르며, 비용이 낮음

• 배포 직후 환경 점검 시 수행됨

서버를 배포한 후 사용자가 로그인 페이지에 접속할 수 있는지

소프트웨어 개발 환경 및 테스트 전략 종합

1. 환경별 비교 (Environment Comparison)

개발 환경 (Dev)

• 목적: 기능 구현 및 빠른 피드백
• 데이터: Mock / 가짜 데이터
• 인프라: 로컬 또는 격리된 클라우드
• 접근 권한: 개발자 전체
• 배포 주기: 수시 (커밋 단위)
• 실패 허용도: 높음 (실험 장려)

스테이징 환경 (Staging)

• 목적: 운영 배포 전 최종 검증
• 데이터: 운영 데이터 복사본 (익명화)
• 인프라: 운영과 동일한 구성
• 접근 권한: 개발자 + QA + 일부 운영
• 배포 주기: CI 통과 후 자동 또는 수동
• 실패 허용도: 중간 (발견이 목적)

운영 환경 (Production)

• 목적: 실제 사용자 서비스
• 데이터: 실제 사용자 데이터
• 인프라: 실제 서비스 인프라
• 접근 권한: 운영팀 + 제한된 개발자
• 배포 주기: 검증 완료 후
• 실패 허용도: 낮음 (장애 = 비용)

2. 환경별 테스트 전략 비교

단위 테스트 (Unit Test)

• 수행 환경: 개발 환경
• 검증 대상: 함수 / 모듈 단위 로직
• 실행 주체: 개발자 (자동)
• 실행 시점: 코드 작성 중 / Push 시
• 실행 시간: 수 초 ~ 수십 초
• 외부 의존성: 없음 (Mock 처리)
• 실패 시: 즉시 수정 후 재실행
• 대표 도구: Jest, Vitest
• 커버리지 범위: 넓음 (코드 전체)
• 비용: 매우 낮음

통합 테스트 (Integration Test)

• 수행 환경: 개발 환경 (후반)
• 검증 대상: 모듈 간 연동, DB/API 연결
• 실행 주체: CI 파이프라인 (자동)
• 실행 시점: PR Merge 전후
• 실행 시간: 수십 초 ~ 수 분
• 외부 의존성: 있음 (DB, API 등 실제 연결)
• 실패 시: PR Merge 차단
• 대표 도구: Jest + Supertest, Testcontainers
• 커버리지 범위: 중간 (연동 지점 중심)
• 비용: 낮음 ~ 중간

E2E 테스트 (End-to-End Test)

• 수행 환경: 스테이징 환경
• 검증 대상: 사용자 시나리오 전체 흐름
• 실행 주체: QA / CI 파이프라인 (자동)
• 실행 시점: 스테이징 배포
• 실행 시간: 수 분 ~ 수십 분
• 외부 의존성: 있음 (브라우저, 네트워크 등)
• 실패 시: 운영 배포 차단
• 대표 도구: Playwright, Cypress
• 커버리지 범위: 좁음 (핵심 시나리오)
• 비용: 높음

스모크 테스트 (Smoke Test)

• 수행 환경: 운영 환경
• 검증 대상: 핵심 기능 생존 여부
• 실행 주체: CD 파이프라인 (자동)
• 실행 시점: 운영 배포 직후
• 실행 시간: 수 초 ~ 수 분
• 외부 의존성: 있음 (실제 운영 환경)
• 실패 시: 즉시 롤백 트리거
• 대표 도구: curl, k6, 자체 헬스체크
• 커버리지 범위: 매우 좁음 (생존 확인)
• 비용: 낮음

테스트 피라미드와 환경의 관계

• 비싸고 느린 테스트일수록 운영에 가까운 환경에서 적게 실행하고,
  빠르고 저렴한 테스트일수록 개발 환경에서 최대한 많이 실행하는 것

• Smoke Test는 배포 후 생존 확인(Health Verification)의 성격이 강해
  피라미드 밖 개념으로도 간주