Blog

Bamboo CI에서 자동화된 API 테스트 단계별 실행 가이드

Atlassian Bamboo CI에 자동화된 API 테스트를 추가하세요. Apidog에서 스키마 인식 테스트를 구축하고 Apidog CLI로 이를 실행한 다음, 계약이 위반될 때 빌드를 실패시키세요.

Ashley Innocent

Ashley Innocent

15 June 2026

Bamboo CI에서 자동화된 API 테스트 단계별 실행 가이드

Apidog 엔터프라이즈

온프레미스 배포

SSO & RBAC

SOC 2 준수

Apidog Enterprise 살펴보기

빌드는 성공했습니다. 유닛 테스트가 통과하고, JAR가 패키징되고, 아티팩트가 배포되었습니다. 그런데 첫 실제 요청이 스테이징 API에 도달했을 때, 누군가 두 커밋 전에 응답 필드를 변경했기 때문에 다운스트림 서비스에서 500 오류를 반환했습니다. 빌드는 모든 것이 정상이라고 말했지만, 실제로는 그렇지 않았습니다. 단지 API를 확인하지 않았을 뿐입니다.

이것이 대부분의 Bamboo CI 파이프라인이 가진 간극입니다. Atlassian Bamboo는 코드 컴파일, JUnit 스위트 실행, 아티팩트 배포에는 능숙합니다. 하지만 HTTP 엔드포인트가 계약(contract)에 명시된 대로 작동하는지 자체적으로 검증하지는 않습니다. 이러한 안전망을 원한다면, 파이프라인에 자동화된 API 테스트를 한 단계로 추가해야 합니다. 이 가이드는 Apidog를 사용하여 테스트를 구축하고 Apidog CLI를 사용하여 Bamboo 작업 내에서 테스트를 실행하는 방법을 정확히 안내합니다.

이 가이드가 끝나면, 푸시할 때마다 엔드포인트를 호출하고, 상태 코드를 확인하며, 스키마에 대해 응답 본문을 검증하고, 계약이 깨지는 즉시 빌드를 실패시키는 Bamboo 플랜을 갖게 될 것입니다. 좌석당 Postman 라이선스도 필요 없고, 유지보수해야 할 수동 작성 어설션 스크립트도 없으며, 모든 빌드에 실제 HTML 테스트 보고서가 첨부됩니다. 따라하고 싶다면 Apidog를 다운로드하세요. CLI 부분은 무료이며 오픈 소스입니다.

버튼

API 테스트가 Bamboo에 속해야 하는 이유 (나중이 아닌 지금)

많은 팀이 API를 수동으로 테스트하거나, 더 나쁘게는 프로덕션 환경에서 테스트합니다. 누군가가 릴리스 전에 저장된 요청 컬렉션을 클릭하고 응답을 눈으로 확인합니다. 이는 문제가 생기기 전까지는 작동합니다. 사람들은 잊어버리고, 금요일에 릴리스가 이루어집니다. 아무도 다시 확인해야 한다고 생각하지 않은 바로 그 엔드포인트가 문제를 일으킵니다.

Bamboo 태스크
Bamboo CI

CI는 그러한 인간적인 변수를 제거하기 위해 존재합니다. 빌드 서버의 핵심 목적은 동일한 검사가 매번, 자동으로, 아무도 실행을 기억할 필요 없이 동일한 방식으로 실행되는 것입니다. 유닛 테스트는 이미 그곳에 있습니다. 통합 테스트도 아마 그럴 것입니다. API 테스트도 동일한 대우를 받을 자격이 있으며, 몇 가지 구체적인 이유는 다음과 같습니다.

더 깊은 맥락은 팀이 CI/CD를 처음부터 채택하는 이유와 동일합니다. 즉, 문제가 수정하기 저렴할 때 일찍 발견하고, 비용이 많이 들고 당황스러운 늦은 시점이 아닌 초기에 문제를 해결하는 것입니다. API 테스트는 대부분의 파이프라인이 건너뛰는 이러한 전략의 한 계층일 뿐입니다.

API 테스트가 Bamboo 플랜에 어떻게 적용되는가

단계별 설명에 앞서, 이것이 Bamboo 모델에서 어디에 위치하는지 이해하는 것이 도움이 됩니다. Bamboo는 작업을 플랜으로 구성하며, 각 플랜은 순서대로 실행되는 하나 이상의 스테이지를 포함합니다. 각 스테이지는 작업을 가지며, 각 작업은 태스크의 시퀀스입니다. 태스크는 실제 명령입니다: 체크아웃, 컴파일, 스크립트 실행.

Bamboo 태스크

API 테스트는 스테이지 안의 작업 안의 태스크가 됩니다. 애플리케이션이 빌드되어 테스트 환경에 배포된 후 실행되는 전용 스테이지에 위치시키는 것이 자연스럽습니다. 요청을 보낼 실제 실행 중인 무언가가 필요하기 때문입니다. 일반적인 플랜은 다음과 같이 구성됩니다.

Plan: payments-service
├── Stage: Build
│   └── Job: Compile & Unit Test
│       ├── Task: Source Code Checkout
│       └── Task: Maven, clean package
├── Stage: Deploy to Staging
│   └── Job: Deploy
│       └── Task: Deploy artifact to staging
└── Stage: API Tests          <- 이 부분이 추가하는 내용입니다
    └── Job: Run API Suite
        ├── Task: Source Code Checkout
        ├── Task: Script, install & run Apidog CLI
        └── Task: Final, publish test report

API 테스트 스테이지의 태스크가 0이 아닌 코드로 종료되면, Bamboo는 해당 스테이지를 실패로 표시하고 전체 빌드를 빨간색으로 만듭니다. 이것이 바로 여러분이 원하는 동작입니다. 깨진 계약은 그냥 넘어가지 않고 라인을 중단시켜야 합니다.

스크립트 태스크에서 실제 작업을 수행하는 도구는 Apidog CLI입니다. Apidog CLI는 Apidog에서 시각적으로 설계한 테스트 시나리오를 실행하는 명령줄 러너입니다. 코딩 없이 GUI에서 한 번 테스트를 만들면, 터미널과 Bamboo에서 동일한 테스트가 변경 없이 실행됩니다. 이는 팀이 모든 CI/CD 시스템에서 API 테스트를 자동화하는 데 사용하는 것과 동일한 패턴입니다. Bamboo는 여러 대상 중 하나일 뿐입니다.

단계 1: Apidog에서 API 테스트 구축하기

테스트가 없으면 CI에서 테스트를 실행할 수 없습니다. Apidog는 테스트를 설계하는 곳이며, 시각적인 디자인을 제공하므로 코드를 작성하지 않는 QA 엔지어도 백엔드 개발자가 만들 수 있는 것과 동일한 스위트를 구축할 수 있습니다.

Apidog를 열고 테스트 시나리오를 생성하세요. 시나리오는 위에서 아래로 실행되는 API 요청의 정렬된 시퀀스이며, 각 단계는 이전 단계의 데이터를 재사용할 수 있습니다. 결제 서비스에 대한 현실적인 시나리오는 다음과 같을 수 있습니다.

  1. 유효한 자격 증명으로 POST /auth/login을 호출하고, 응답에서 베어러 토큰을 추출합니다.
  2. 해당 토큰을 사용하여 POST /orders를 호출하고 새 주문을 생성한 다음, 반환된 orderId를 저장합니다.
  3. GET /orders/{orderId}를 호출하여 주문이 올바른 상태로 표시되는지 확인합니다.
  4. DELETE /orders/{orderId}를 호출하여 정리합니다.

각 요청에 대해 어설션을 추가하세요. 이것이 요청을 테스트로 바꾸는 부분입니다. Apidog는 스크립팅 없이 시각적으로 어설션을 할 수 있도록 합니다.

스키마 기반 어설션은 특별히 언급할 가치가 있습니다. Apidog는 스키마 우선 방식이므로, API 정의에서 엔드포인트가 약속한 형태를 이미 알고 있습니다. 한 번의 클릭으로 "이 응답이 해당 스키마와 일치한다"고 어설션할 수 있으며, 이 단일 검사는 한 줄의 코드도 작성하지 않고도 계약 불일치, 필드 이름 변경, 잘못된 유형, 누락된 속성과 같은 광범위한 문제를 방지합니다. 스크립트 위주의 도구를 사용하던 분이라면, 이것만으로도 많은 유지보수 작업을 줄일 수 있습니다. 이는 Apidog를 API 테스트를 위한 일반적인 Postman 대안으로 만드는 시각적 어설션 모델과 동일합니다.

시나리오가 많다면 관련 시나리오를 테스트 스위트로 그룹화하세요. 스위트는 함께 실행할 수 있는 시나리오들의 모음으로, CI 명령을 단순하게 유지합니다. 즉, 스무 개의 시나리오를 나열하는 대신 하나의 스위트를 가리키는 방식입니다.

로컬, 스테이징, 프로덕션 간에 변경되는 모든 것(기본 URL, 자격 증명, API 키)에 환경 변수를 사용하세요. Apidog에서 baseUrl을 스테이징 호스트로 설정하여 스테이징 환경을 정의하세요. 런타임에 CLI에 사용할 환경을 지정하면, 동일한 시나리오가 Bamboo의 스테이징 환경과 노트북의 localhost에서 실행됩니다.

단계 2: Apidog 액세스 토큰 생성 및 ID 가져오기

Bamboo는 빌드 에이전트에서 헤드리스로 실행됩니다. 브라우저를 통해 Apidog 계정에 로그인할 수 없으므로, CLI는 대신 액세스 토큰으로 인증합니다.

테스트 시나리오 내에서 CI/CD 탭을 엽니다. "액세스 토큰 추가"를 클릭한 다음 "토큰 생성"을 클릭합니다. 값을 잠시 안전한 곳에 복사해 두세요. 곧 Bamboo 변수로 저장할 것이며, 스크립트에 붙여넣지 마세요. 이 토큰은 빌드 에이전트가 개인 프로젝트의 테스트를 가져와 실행할 수 있도록 하는 역할을 합니다.

CI/CD 탭에 있는 동안, Apidog는 전체 실행 명령어를 자동으로 생성해줍니다. 제공자로 "명령줄"을 선택하면 테스트 시나리오 ID와 프로젝트 ID가 이미 채워진 채로 직접 복사할 수 있는 내용이 출력됩니다. 이 복사된 명령어가 Bamboo 태스크의 기반이 됩니다. 중요하게 다룰 부분은 다음과 같습니다.

생성된 명령어를 잘 보관하세요. 다음 단계에서 Bamboo에 맞게 조정할 것입니다.

단계 3: 토큰을 Bamboo 플랜 변수로 저장하기

스크립트 태스크에 토큰을 하드코딩하지 마세요. 플랜에 읽기 권한이 있는 사람이나 빌드 로그를 읽는 사람은 누구나 토큰을 볼 수 있습니다.

Bamboo에서 플랜으로 이동하여 "플랜 구성"을 열고 "변수" 탭을 찾으세요. 새 변수를 추가하세요. APIDOG_ACCESS_TOKEN과 같이 명확한 이름을 지정하고 토큰을 값으로 붙여넣으세요. Bamboo는 이름에 password, secret, 또는 token이 포함된 변수를 마스킹하므로, 이에 따라 이름을 지정하면 로그와 UI에서 값이 숨겨집니다.

런타임에 Bamboo는 플랜 변수를 환경 변수로 스크립트에 노출합니다. 이 환경 변수는 접두사가 붙고 대문자로 변환되며, 점(.)은 밑줄(_)로 바뀝니다. APIDOG_ACCESS_TOKEN이라는 변수는 셸 태스크에서 $bamboo_APIDOG_ACCESS_TOKEN으로 사용할 수 있습니다. 빌드 스크립트에서는 항상 이 참조를 사용하고, 원본 토큰을 직접 사용하지 마세요.

이러한 보안 수칙은 테스트에 필요한 다른 모든 비밀 정보(데이터베이스 암호, 타사 API 키, 서명 비밀)에도 적용됩니다. 이들을 마스킹된 Bamboo 변수로 정의하고 bamboo_ 환경 접두사를 통해 읽으세요.

단계 4: API 테스트 스테이지 및 스크립트 태스크 추가하기

이제 플랜에 연결하세요. "플랜 구성"에서 새 스테이지를 추가하고 "API 테스트"라고 명명하세요. 여기에 작업을 추가한 다음, 이 순서로 작업에 태스크를 추가하세요.

태스크 1, 소스 코드 체크아웃. 테스트는 Apidog 클라우드에 있지만, 리포지토리를 체크아웃하면 에이전트에게 깨끗한 작업 디렉토리를 제공하고 로컬 데이터 파일(예: CSV 반복 데이터)을 코드와 함께 커밋할 수 있게 합니다.

태스크 2, 스크립트. 이것이 핵심입니다. 스크립트 태스크를 선택하고 인터프리터를 Shell(또는 /bin/sh)로 설정한 다음, 인라인 스크립트 본문을 사용하세요. 이 스크립트는 에이전트에 Apidog CLI를 설치하고 시나리오를 실행합니다.

Apidog CLI는 npm 패키지이므로, 에이전트에는 Node.js v16 이상이 필요합니다. 에이전트에 이미 Node가 있다면 설치 라인을 건너뛸 수 있습니다. 그렇지 않다면 Bamboo의 기능 또는 Docker 기반 에이전트를 통해 프로비저닝하세요. 다음은 완전한 스크립트 본문입니다.

#!/bin/sh
set -e

# 에이전트에 Apidog CLI 전역 설치
npm install -g apidog-cli

# 스테이징에 대해 테스트 시나리오 실행, HTML + CLI 보고서 출력
apidog run \
  --access-token "$bamboo_APIDOG_ACCESS_TOKEN" \
  -t 637132 \
  -e 358171 \
  -r cli,html \
  --out-dir ./apidog-reports

637132를 실제 테스트 시나리오 ID로, 358171을 스테이징 환경 ID로 바꾸세요. 이 값들은 Apidog가 단계 2에서 생성한 명령어에서 가져온 것입니다. 각 플래그가 하는 역할에 대한 몇 가지 참고 사항입니다.

맨 위의 set -e는 중요합니다. 이는 첫 번째 실패 명령에서 셸이 종료되도록 합니다. Apidog CLI는 어떤 어설션이 실패하면 0이 아닌 종료 코드를 반환하며, 이 0이 아닌 코드가 Bamboo에 빌드 실패를 알립니다. 이 둘은 함께 API 계약 위반이 로그에 묻히는 대신 빌드를 실패하게 만들도록 보장합니다.

만약 이전에 GitHub Actions에 API 테스트를 연결해본 경험이 있다면, 이 과정이 익숙하게 느껴질 것입니다. 러너와 플래그는 동일하며, YAML과 Bamboo UI 래퍼만 다를 뿐입니다.

단계 5: 테스트 보고서를 Bamboo 아티팩트로 게시하기

실패한 빌드는 무언가 고장났음을 알려줍니다. HTML 보고서는 무엇이 고장났는지 알려줍니다. 모든 빌드가 보고서를 보관하도록 연결하세요.

동일한 작업에서 "아티팩트" 탭으로 이동하여 새 공유 아티팩트를 정의하세요.

각 빌드 후, Bamboo는 apidog-reports 디렉토리의 모든 것을 수집하여 빌드 결과에 첨부합니다. 아무 빌드나 열고 "아티팩트" 탭으로 이동하면 HTML 보고서를 다운로드하거나 볼 수 있습니다. 여기에는 요청별 결과, 실행된 어설션, 그리고 실패한 모든 것에 대한 정확한 응답 본문이 포함됩니다. 마지막 부분은 실제 디버깅 시간을 절약해줍니다. 실패한 요청을 수동으로 다시 실행하는 대신, 빌드에서 캡처된 응답을 직접 읽을 수 있습니다.

더 풍부한 Bamboo 내 표시를 위해 junit 리포터도 유용합니다. -r 목록에 junit를 추가한 다음, JUnit XML 파일을 가리키는 JUnit Parser 태스크를 추가하세요. 그러면 Bamboo는 유닛 테스트 결과와 동일한 방식으로 빌드 요약에 테스트 수, 합격/실패 분석, 실패 추세를 기본적으로 렌더링합니다.

단계 6: 실행 및 결과 확인

첫 실행은 수동으로 플랜을 트리거하세요. Bamboo의 플랜 페이지에서 "플랜 실행"을 클릭하세요. API 테스트 스테이지의 빌드 로그를 확인하세요. npm이 CLI를 설치하는 것을 볼 수 있고, 이어서 시나리오 이름, 각 요청, 각 어설션, 그리고 총계를 포함한 최종 요약 줄과 함께 Apidog 실행 출력이 스트림으로 표시될 것입니다.

두 가지 결과:

모든 어설션이 통과하면, CLI는 0으로 종료되고, 스테이지는 초록색이 되며, 빌드는 성공합니다. HTML 보고서는 어쨌든 아티팩트로 첨부되므로 기록을 갖게 됩니다. 좋습니다. 이제 자동화하세요. 메인 브랜치에 대한 모든 커밋에 대해 플랜이 트리거되도록 설정하세요 ("플랜 구성", "트리거", "저장소 폴링" 또는 웹훅). 이제부터 모든 푸시는 사람의 개입 없이 API 스위트를 실행할 것입니다.

어설션이 실패하면, CLI는 0이 아닌 값으로 종료되고, set -e는 스크립트를 중단시키며, 스테이지는 빨간색이 되고, 빌드는 실패합니다. 아티팩트를 열어 실패한 요청을 찾고 캡처된 응답을 읽으세요. 필드가 변경되었을 수도 있습니다. 종속성 문제로 인해 스테이징에서 502를 반환했을 수도 있습니다. 어느 쪽이든, 문제가 발생한 커밋 후 1~2분 이내에 이를 알 수 있다는 것이 전체적인 이점입니다.

실제 콘솔 요약은 다음과 같습니다.

┌──────────────┬──────────┬──────────┐
│              │ executed │   failed │
├──────────────┼──────────┼──────────┤
│   iterations │        1 │        0 │
├──────────────┼──────────┼──────────┤
│     requests │        4 │        0 │
├──────────────┼──────────┼──────────┤
│   assertions │       11 │        1 │
└──────────────┴──────────┴──────────┘

  1 assertion failed:
    GET /orders/{orderId}
      expected $.data.status to equal "pending" but got "failed"

그 하나의 실패한 어설션이 이 스테이지가 존재하는 모든 이유입니다. 이는 깔끔하게 컴파일되고 모든 유닛 테스트를 통과한 계약 회귀를 잡아냈습니다.

CI에서 스위트를 신뢰할 수 있게 만들기

불안정한 API 테스트는 없는 것보다 나쁩니다. 팀이 실패한 빌드를 무시하도록 훈련시키기 때문입니다. 몇 가지 습관이 스위트를 신뢰할 수 있게 유지합니다.

테스트 데이터를 격리하세요. 각 실행은 필요한 것을 생성하고 스스로 정리해야 합니다. 위에 설명된 생성-삭제 주문 흐름처럼 말이죠. 지난 화요일에 누군가가 생성한 레코드에 의존하는 테스트는 그 레코드가 변경되는 순간 깨질 것입니다. 전용 스테이징 또는 테스트 환경에 대해 실행하고, 절대 프로덕션 환경에 대해 실행하지 마세요.

중복 없이 커버리지를 위해 데이터 기반 실행을 사용하세요. 스무 가지 다른 입력으로 동일한 엔드포인트를 테스트해야 한다면, 스무 개의 시나리오를 만들지 마세요. --iteration-data path/to/data.csv (또는 -d)와 함께 단일 시나리오를 사용하면 CLI는 행당 한 번씩 이를 실행합니다. CSV를 리포지토리에 커밋하여 코드와 함께 체크아웃되도록 하세요. 이것은 로컬에서 사용하는 것과 동일한 데이터 기반 테스트 패턴이며, 단지 CI에서 파일로부터 구동될 뿐입니다.

CLI 버전을 고정하세요. npm install -g apidog-cli는 최신 버전을 가져옵니다. 재현 가능한 빌드를 위해 알려진 버전을 고정하려면 npm install -g apidog-cli@<version>를 사용하세요. 이렇게 하면 CLI 업데이트가 동일한 커밋의 두 빌드 사이에서 동작을 조용히 변경하는 것을 방지할 수 있습니다.

합리적인 시간 초과를 설정하세요. --timeout-request 10000을 추가하여 Bamboo 자체의 시간 초과로 빌드가 중단될 때까지 기다리지 않고, 응답이 없는 엔드포인트에서 빠르게 실패하도록 하세요. 명확한 "요청 시간 초과" 메시지가 모호하게 멈춘 빌드보다 낫습니다.

API 스테이지에서 배포를 게이팅하세요. API 테스트 스테이지는 어떤 프로덕션 배포 스테이지보다 먼저 실행되고, 실패한 스테이지는 플랜을 중단시키기 때문에, 깨진 계약은 프로덕션에 도달할 수 없습니다. 이 순서가 바로 여러분의 릴리스 게이트입니다. 이것은 단순히 컴파일만 하는 빌드가 아닌, 실제 CI/CD 파이프라인을 구축하는 실용적인 버전입니다.

시나리오를 빠르고 집중적으로 유지하세요. 20분이 걸리는 CI 스위트는 모든 커밋에서 실행되지 않을 것입니다. 사람들은 이를 야간 빌드로 옮겨 빠른 피드백을 놓치게 될 것입니다. 커밋별 스위트는 핵심 경로, 인증, 핵심 CRUD, 결제 흐름에 집중하고, 철저한 엣지 케이스 스위트는 스케줄에 따라 실행하세요.

마무리

Bamboo는 컴파일되지 않는 코드와 통과하지 못하는 유닛 테스트로부터 이미 여러분을 보호합니다. API 테스트 스테이지를 추가하면 이러한 보호가 서비스가 실제로 와이어를 통해 노출하는 계약, 즉 대부분의 "하지만 로컬에서는 작동했어요" 사고가 실제로 발생하는 계층으로 확장됩니다.

설정은 간단합니다. Apidog에서 시각적이고 스키마를 인식하는 테스트를 구축하고, 액세스 토큰을 생성하며, 이를 마스킹된 Bamboo 변수로 저장하고, 시나리오 및 환경 ID로 apidog run을 실행하는 스크립트 태스크를 추가합니다. 보고서를 아티팩트로 게시하고, 배포 스테이지를 그 뒤에 두어 게이팅하며, 모든 커밋에서 플랜을 트리거합니다. 그 후에는 모든 것이 자동입니다. 모든 푸시가 API를 확인하고, 깨진 계약은 중단 사태로 이어지기 전에 빌드를 실패시킵니다.

Apidog를 다운로드하여 첫 번째 테스트 시나리오를 구축한 다음, 생성된 CLI 명령어를 Bamboo 스크립트 태스크에 삽입하세요. 깔끔하게 컴파일된 회귀를 처음 발견할 때, 이 스테이지는 설정에 소요된 10분의 가치를 충분히 증명할 것입니다.

버튼

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드