금요일 오후 4시, 배포가 진행됩니다. 단위 테스트는 모두 통과했고, 컨테이너는 빌드되었으며, 롤아웃은 오류 없이 완료되었습니다. 그런데 지원 큐가 쌓이기 시작합니다. 결제 시스템에서 500 오류가 발생합니다. 버그는 테스트된 코드에 전혀 없었습니다. 두 서비스가 서로 통신하는 방식에 있었고, 파이프라인의 어떤 테스트도 그 통신을 검증하지 않았습니다.
이는 DevOps에서 테스트 자동화가 해결해야 할 간극이며, 대부분의 팀이 투자를 소홀히 하는 부분이 바로 API 계층입니다. 단위 테스트는 함수가 독립적으로 작동하는지 증명합니다. 종단 간 UI 테스트는 브라우저가 느리고 불안정하게 플로우를 클릭할 수 있는지 증명합니다. 서비스 간의 계약, 즉 프로덕션 환경에서 실제로 문제가 발생하는 부분은 중간에 존재하며 종종 확인되지 않은 채로 남아 있습니다. API 테스트는 바로 그곳에 존재합니다.
DevOps에서 테스트 자동화가 실제로 의미하는 것
DevOps는 선이 아니라 루프입니다. 계획, 코딩, 빌드, 테스트, 릴리스, 배포, 운영, 모니터링, 그리고 다시 계획으로 돌아갑니다. DevOps의 테스트 자동화는 릴리스 전에 누군가 수동으로 실행하는 수동 게이트가 아니라, 문제가 가장 저렴하게 발견되는 루프의 지점에서 테스트가 자동으로 실행되는 것을 의미합니다.
그 이면의 원칙은 Shift-Left입니다. 즉, 개발자가 변경 사항을 작성하는 순간에 더 가깝게 테스트를 앞당기는 것입니다. 풀 리퀘스트에서 발견된 버그는 수정하는 데 몇 분이 걸립니다. 프로덕션 환경에서 발견된 동일한 버그는 롤백, 사고 채널, 그리고 사후 분석을 야기합니다. 자동화는 Shift-Left를 가능하게 합니다. 왜냐하면 사람은 모든 커밋에서 회귀 테스트 스위트를 수동으로 다시 실행할 수 없지만, 파이프라인은 할 수 있기 때문입니다.
"테스트 자동화"를 하나의 덩어리로 취급하는 것은 실수입니다. 테스트 피라미드는 이를 여러 계층으로 나누며, 각 계층은 다른 질문에 답합니다.
- 단위 테스트는 단일 함수가 올바른 값을 반환하는지 묻습니다. 빠르고 많습니다.
- API 및 통합 테스트는 서비스가 올바른 응답을 생성하고 서로 올바르게 통신하는지 묻습니다. 이들은 수가 적지만 각각 더 넓은 범위를 커버합니다.
- 종단 간 테스트는 사용자 입장에서 전체 시스템이 작동하는지 묻습니다. 느리고 취약하며, 수를 적게 유지하는 것이 좋습니다.
API 테스트는 생산적인 중간에 위치합니다. 몇 분이 아니라 몇 초 만에 실행됩니다. 렌더링된 UI에 의존하지 않으므로 버튼이 움직여도 깨지지 않습니다. 그리고 다른 서비스와 고객이 실제로 의존하는 표면을 테스트합니다. 이것이 바로 DevOps 파이프라인에서 API 테스트가 다른 어떤 계층보다 더 많은 회귀 탐지 부담을 지는 이유입니다. 이 실천의 기초에 대해서는 API 테스트 자동화가 어디서 실행할지 고민하기 전에 무엇을 단언해야 하는지, 그리고 그 이유를 다룹니다.
DevOps 라이프사이클, 단계별 API 테스트의 적합성
실제 지도입니다. 모든 팀이 모든 단계에서 API 테스트를 필요로 하는 것은 아니지만, 옵션을 알면 모든 것을 하나의 거대한 배포 전 작업에 쏟아붓는 대신 신중하게 선택할 수 있습니다.
개발 중: 로컬 및 사전 커밋
변경 사항이 CI에 도달하기 전에 개발자는 로컬 또는 개발 환경에서 관련 API 테스트를 실행할 수 있어야 합니다. 이것은 가장 빠른 피드백 루프입니다. 여기서 손상된 응답 형식을 잡아내면 손상된 코드가 푸시되지도 않습니다.
실제로 이것은 CI에서 나중에 실행할 것과 동일한 시나리오이며, 단지 로컬 환경을 가리키도록 설정되어 있습니다. 한 번만 구축하면 됩니다. 한 번도 작성해본 적이 없다면, Apidog로 테스트 시나리오 작성 방법이 요청을 연결하고 한 응답에서 다음 응답으로 값을 가져오는 과정을 안내합니다.
풀 리퀘스트에서: 병합 게이트
이것은 API 테스트의 가장 가치 있는 위치이며, 팀들이 가장 자주 건너뛰는 부분입니다. 풀 리퀘스트가 열리면 파이프라인은 서비스를 가동하고, 서비스에 대해 API 시나리오를 실행하며, 통과 또는 실패를 상태 확인으로 보고합니다. 실패한 확인은 병합을 차단합니다.
이것이 중요한 이유는 버그의 비용은 멀리 갈수록 급격히 상승하기 때문입니다. PR에서 실패한 단언은 변경 사항이 아직 머릿속에 생생한 작성자에게는 5분이면 고칠 수 있는 일입니다. 일주일 후 스테이징에서 발견된 동일한 오류는 고고학 프로젝트입니다. PR 게이트에 API 테스트를 배치하는 것은 가장 많은 결함을 Shift-Left로 이동시키는 단일 변경 사항입니다.
빌드 후, 릴리스 전: 통합 및 계약 확인
아티팩트가 빌드되어 스테이징 또는 통합 환경에 배포되면 더 광범위한 스위트를 실행합니다. 여기서는 실제 연결을 테스트합니다. 결제 서비스가 여전히 주문 서비스의 요청 본문을 수락하는지, 페이지 매김이 클라이언트가 읽는 필드를 여전히 반환하는지, 한 서비스에서 발급한 인증 토큰이 다른 서비스에서 수락되는지 등입니다.
이 단계는 또한 계약적 사고방식이 결실을 맺는 곳입니다. 로컬에서 유효한 변경 사항도 하류의 소비자를 망가뜨릴 수 있습니다. 통합 환경에서 전체 시나리오 세트를 실행하면 단위 테스트가 구조적으로 볼 수 없는 서비스 간의 오류를 발견합니다. 패턴은 더 넓은 API 테스트 자동화 실천에서 이어집니다.
배포 시점: 스모크 테스트
배포는 롤아웃이 완료될 때 끝나는 것이 아닙니다. 새 버전이 트래픽을 실제로 올바르게 서비스한다는 증거가 있을 때 완료됩니다. 스모크 테스트는 배포 직후 중요 경로를 확인하는 작고 빠른 시나리오입니다. 사용자가 인증할 수 있는지, 데이터를 읽을 수 있는지, 건강에 중요한 엔드포인트가 올바른 형식으로 200을 반환하는지 등입니다.
이 스위트는 작고 빠르게 유지하세요. 그 역할은 적용 범위가 아니라 실행 여부 신호입니다. 실패하면 자동으로 롤백됩니다. 단일 환경 플래그를 교체하여 프로덕션 환경에 대해 동일한 시나리오를 실행하면 중복 테스트를 유지 관리할 필요가 없습니다.
프로덕션 환경에서: 지속적인 모니터링
배포 후에도 루프는 멈추지 않습니다. CI에서 실행하는 것과 동일한 API 시나리오를 프로덕션 환경에 대해 합성 모니터링으로 스케줄에 따라 실행하여, 고객이 인지하기 전에 저하된 타사 종속성이나 만료된 인증서를 감지할 수 있습니다. 테스트와 모니터 사이의 경계는 주로 실행되는 스케줄에 있습니다. API 모니터링은 통과하는 테스트를 프로덕션 초기 경고 시스템으로 전환하는 방법을 다룹니다.
다섯 가지 단계 전반에 걸쳐 유용한 경험칙은 다음과 같습니다. 프로덕션에 가까울수록 스위트는 더 작고 빨라야 합니다. PR과 통합에서는 광범위한 적용 범위, 배포 및 모니터링에서는 얇고 엄격한 스모크 스위트입니다.
API 계층이 파이프라인에서 자리를 차지하는 이유
UI 테스트에 더 많은 부담을 주는 대신 API 테스트가 왜 최고의 자리를 차지해야 하는지 구체적으로 설명할 가치가 있습니다.
빠릅니다. API 시나리오는 HTTP와 직접 통신합니다. 브라우저를 가동할 필요도 없고, DOM을 기다릴 필요도 없으며, 느린 렌더링으로 인해 헤드리스 Chrome이 불안정해지는 일도 없습니다. 수십 개의 엔드포인트를 실행하는 시나리오는 몇 초 만에 완료되므로, 사람들이 10분짜리 작업을 무시하는 법을 배우지 않고도 모든 커밋에서 실행할 수 있습니다.
안정적입니다. UI 테스트는 클래스 이름이 변경되거나 요소가 한 프레임 늦게 다시 렌더링될 때 깨집니다. API 테스트는 실제 계약이 변경될 때만 깨지는데, 이는 정확히 알아야 할 때입니다. 불안정성이 적다는 것은 사람들이 실패한 빌드를 신뢰한다는 것을 의미하며, 사람들이 신뢰하는 빌드만이 어떤 것이든 차단할 수 있는 유일한 빌드입니다.
통합되는 것을 테스트합니다. 모바일 앱, 파트너 통합, 자체 마이크로 서비스는 모두 CSS가 아닌 API 계약에 의존합니다. 그 계약이 조용히 변경되면 모든 소비자가 동시에 고장납니다. API 테스트는 이를 감지하는 계층입니다.
이것이 파이프라인 문제가 실제로는 API 문제인 이유입니다. 철저한 단위 테스트 스위트와 예쁜 UI 스위트를 가지고 있으면서도 금요일 오후 결제 버그를 배포할 수 있습니다. 왜냐하면 어떤 계층도 서비스가 만나는 지점을 주시하고 있지 않았기 때문입니다.
Apidog CLI를 사용하여 API 테스트를 파이프라인에 연결하기
메커니즘이 중요합니다. 왜냐하면 존재하지만 자동으로 실행되지 않는 테스트는 아무것도 잡을 수 없기 때문입니다. 모든 CI 시스템에서 패턴은 동일합니다. 러너를 설치하고, 테스트를 가리키게 하고, 종료 코드가 빌드 통과 여부를 결정하도록 합니다.
Apidog를 사용하면 테스트를 코드로 다시 작성할 필요가 없습니다. 앱에서 시나리오를 한 번 구축하면 Apidog CLI가 동일한 시나리오를 헤드리스로 실행합니다. CLI는 npm 패키지이므로 Node.js가 설치된 모든 CI 러너에서 사용할 수 있습니다.
설치:
npm install -g apidog-cli
그런 다음 시나리오를 실행합니다. Apidog의 테스트 시나리오 CI/CD 탭에서 액세스 토큰과 시나리오 및 환경 ID를 생성하면 복사할 수 있는 전체 명령이 자동으로 생성됩니다.
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 605067 \
-e 1629989 \
-r cli
여기서 몇 가지 중요한 작업이 수행됩니다. `-t` 플래그는 ID로 시나리오를 지정합니다. 전체 폴더를 실행하려면 `-f`로 바꾸거나, 선별된 테스트 스위트를 하나의 작업으로 실행하려면 `--test-suite`로 바꿀 수 있습니다. `-e` 플래그는 환경을 선택하는데, 이는 동일한 시나리오가 스테이징에 대한 PR을 게이팅하고 중복 없이 프로덕션에 대해 스모크 테스트를 실행하는 방법입니다. `-r` 플래그는 리포터를 선택합니다. `cli`는 로그에 인쇄하고, `junit`는 CI 대시보드가 테스트 보고서로 렌더링할 수 있는 XML을 내보냅니다.
게이트 역할을 하는 부분은 종료 코드입니다. 모든 단언이 통과하면 `apidog run`은 `0`으로 종료됩니다. 하나라도 실패하면 0이 아닌 값으로 종료됩니다. CI 시스템은 이 코드를 읽고 단계를 실패로 표시하여 병합 또는 배포를 차단합니다. 별도의 게이트를 구성할 필요가 없습니다. 종료 코드가 바로 게이트입니다. `apidog run --help`를 실행하여 현재 버전에 대한 모든 플래그 옵션을 확인하세요.
다음은 GitHub Actions에 연결된 PR-게이트 단계입니다.
name: API Tests
on: [pull_request]
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run API scenarios
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token "$APIDOG_ACCESS_TOKEN" \
-t 605067 \
-e 1629989 \
-r cli,junit
토큰은 리포지토리 시크릿에 저장되며 `env:`를 통해 단계에 도달하며, 절대 하드코딩되지 않습니다. 동일한 블록은 해당 플랫폼의 구문을 사용하여 GitLab CI, Jenkins, CircleCI 또는 Azure Pipelines에 적용됩니다. 왜냐하면 유일한 실제 종속성은 Node이기 때문입니다. 플랫폼별 가이드는 자세한 내용을 다룹니다. GitHub Actions에서 API 테스트 자동화 및 Jenkins와 Apidog 자동화 테스트 통합.
배포 시 스모크 단계의 경우 명령은 거의 변경되지 않습니다. 프로덕션 환경 ID를 가리키고 시나리오를 작게 유지합니다.
apidog run --access-token $APIDOG_ACCESS_TOKEN -t 605067 -e $PROD_ENV_ID -r cli
하나의 시나리오, 하나의 환경 스왑, 두 개의 작업. 이것이 테스트를 한 번 작성하고 라이프사이클 전반에 걸쳐 실행하는 것의 매력입니다.
조용히 게이트를 무력화시키는 일반적인 실수
파이프라인은 완전히 자동화된 것처럼 보이지만 아무것도 잡지 못할 수 있습니다. 다음 사항을 주의하십시오.
종료 코드 삼키기. 누군가 테스트 명령을 셸 파이프라인으로 래핑하거나 빌드를 중단하지 않기 위해 `|| true`를 추가합니다. 이는 또한 아무것도 잡지 못하게 합니다. 빌드는 영원히 녹색으로 표시됩니다. 러너의 0이 아닌 종료를 절대 가리지 마십시오. 그 종료가 바로 핵심입니다.
해피 패스만 테스트하기. `200 OK`를 확인하고 멈추는 시나리오는 중요한 오류를 놓칩니다. 응답 본문 형태, 필드 유형, 잘못된 입력에 대한 오류 응답을 단언하십시오. API 단언은 상태 코드 이상의 유효성 검사를 다룹니다.
하나의 거대한 배포 전 작업. 모든 테스트를 릴리스 직전의 단일 단계에 밀어 넣는 것은 Shift-Left를 무력화시킵니다. PR에서가 아니라 배포 몇 분 전에 깨진 계약에 대해 알게 됩니다. 스위트를 여러 단계에 걸쳐 분산하십시오. PR에서는 광범위하게, 배포 시에는 얇게.
공유 가능한 변경 가능한 환경에 대해 테스트하기. 두 개의 파이프라인이 동일한 데이터베이스를 사용하면 한 실행의 쓰기가 다른 실행의 읽기를 오염시켜 신뢰를 저해하는 불안정한 오류가 발생합니다. 격리된 환경을 사용하거나, 통제할 수 없는 종속성을 대신하기 위해 API 모킹을 사용하여 타사 서비스의 다운타임이 빌드를 실패하게 하지 마십시오.
실패 시 보고서 누락. 테스트가 통과할 때만 보고서가 업로드되도록 구성하면, 가장 필요할 때 보고서를 볼 수 없습니다. 실패 시에도 아티팩트 업로드가 실행되도록 구성하십시오.
FAQ
API 테스트는 DevOps 파이프라인의 어디에서 실행되어야 합니까?
최소한 풀 리퀘스트에서 병합 게이트로 실행되어야 합니다. 이것이 가장 낮은 비용으로 가장 많은 결함을 잡기 때문입니다. 이상적으로는 빌드 후 통합 환경에 대해 계약 확인을 위해, 그리고 배포 직후 작은 스모크 스위트로 실행되어야 합니다. 동일한 Apidog 시나리오가 각 단계에서 실행됩니다. 환경 플래그만 변경하면 됩니다. Postman 없이 Apidog를 실행하는 팀도 동일한 단계를 따릅니다.
API 테스트 자동화와 CI/CD의 차이점은 무엇입니까?
CI/CD는 코드를 자동으로 빌드, 테스트, 배포하는 파이프라인입니다. API 테스트 자동화는 해당 파이프라인 내에서 실행되는 테스트의 한 종류입니다. CI/CD는 컨베이어 벨트이며, 자동화된 API 테스트는 그 위에 있는 품질 검사 스테이션입니다. CI/CD라는 용어 자체가 모호하다면, CI/CD란 무엇인가가 기본 사항을 다룹니다.
CI에서 API 테스트를 실행하려면 코드로 다시 작성해야 합니까?
Apidog에서는 그렇지 않습니다. 앱에서 테스트 시나리오를 시각적으로 구축하면 Apidog CLI가 동일한 시나리오를 헤드리스로 실행합니다. CLI는 npm 패키지이므로 Node.js가 설치된 모든 CI 러너에서 하나의 명령으로 실행할 수 있습니다.
API 테스트는 어떻게 빌드를 실패하게 합니까?
종료 코드를 통해 실패하게 합니다. 시나리오의 모든 단언이 통과하면 러너는 `0`으로 종료됩니다. 단언 중 하나라도 실패하면 0이 아닌 값으로 종료됩니다. CI 시스템은 이 코드를 읽고 단계를 실패로 표시하여 병합 또는 배포를 차단합니다. 별도의 게이트 구성은 필요하지 않습니다.
성능 테스트는 동일한 파이프라인에서 실행되어야 합니까?
모든 PR에서 기능 API 테스트를 유지하고, 더 무거운 부하 및 성능 테스트는 야간과 같은 별도의 스케줄로 실행하십시오. 성능 테스트는 시간이 더 오래 걸리고 안정적인 환경이 필요하므로, 모든 커밋에 연결하면 커밋당 신호를 크게 추가하지 않으면서 피드백을 지연시킵니다.
첫 번째 API 테스트를 어디에 배치해야 할까요?
DevOps의 테스트 자동화는 한 번 구축하는 단일 게이트가 아닙니다. 개발자의 머신에서 빠른 피드백을 위해, 가장 많은 것을 잡는 병합 게이트로 풀 리퀘스트에서, 계약 확인을 위해 빌드 후에, 배포 시 스모크 신호로, 그리고 모니터링으로 프로덕션 환경에서 루프 전체에 의도적으로 배치된 API 테스트입니다. API 계층은 빠르고 안정적이며 시스템이 실제로 고장나는 지점을 테스트하기 때문에 가장 많은 파이프라인 공간을 차지합니다.
API 테스트가 여전히 누군가 수동으로 실행하는 클릭 가능한 단계로 존재한다면, 닫아야 할 간극은 병합 게이트입니다. Apidog를 다운로드하고, 하나의 시나리오를 구축하고, CI/CD 탭에서 `apidog run` 명령을 복사하여 위 GitHub Actions 블록에 붙여넣으세요. 오후가 끝날 무렵에는 API 테스트가 손상된 병합을 차단할 것이며, 금요일 배포 버그는 지원 큐 대신 풀 리퀘스트에서 빨간색으로 표시될 것입니다.