안전하게 개발하기 레츠GO! #5 실전 테스트

실전 데이터 테스트

많은 회사에서 Golang의 testing 패키지를 활용해 다양한 테스트를 수행하고 있습니다. 하지만 실제로는 간단한 Mock 테스트나 기본적인 유닛 테스트 수준에서 멈추는 경우가 대부분입니다. 물론 이러한 테스트 방식도 프로젝트 품질을 높이고 개발 속도를 향상하는데 충분히 의미가 있습니다.

 

하지만 개인적인 관점에서는, Mock 환경에만 의존한 테스트는 실제 운영 환경과의 갭을 줄이는 데 한계가 있다고 생각합니다. Mock 테스트는 안정적이고 빠르게 동작하지만, 실제 데이터 흐름·스키마 변화·외부 시스템과의 연동 문제 같은 현실적인 오류를 잡아내기 어렵기 때문입니다. 그래서 저는 개발 단계에서부터 Mock 테스트를 넘어, 실제 개발 환경에서 사용하는 Database 또는 Pipeline 환경에 가까운 구조로 데이터를 처리해 보는 실전 테스트가 훨씬 더 안전하고 효과적인 방법이라고 판단합니다. 이러한 방식은 개발 중 발생할 수 있는 잠재적 장애를 미리 발견할 수 있고, 운영 환경과의 차이로 인해 발생하는 ‘예상치 못한 버그’를 줄이는 데 큰 도움이 됩니다.

이번 포스팅에서는 Golang에서 실제 데이터를 기반으로 테스트를 수행하는 방법, 그리고 이를 GitHub Actions Self-Hosted Runner와 연동하여 자동화하는 방법까지 함께 살펴보겠습니다. 단순한 유닛 테스트를 넘어서, CI 환경에서 실제 데이터 흐름을 검증하는 엔드투엔드 테스트(E2E) 구조를 구축하는 방법을 중심으로 설명해보겠습니다.

 

실전 데이터 테스트를 위한 개발 환경 아키텍처

일반적으로 대부분의 회사는 Development(Dev), Staging(Stg), Production(Prod) 환경을 분리하여 개발과 배포를 진행합니다.

이 중 실전 데이터를 활용한 테스트를 수행하기 위해서는, Development 환경에서 운영되는 Database와 Pipeline에 직접 접근하여 실제 데이터 흐름을 기반으로 테스트를 실행할 수 있어야 합니다. Mock 데이터만으로는 운영 환경에서 발생할 수 있는 예외 상황이나 데이터 구조의 미묘한 차이를 모두 잡아내기 어렵기 때문입니다.

 

저의 경우, 개발 인프라 전체가 Kubernetes 기반으로 구성되어 있으며, 대부분의 미들웨어(Database, Kafka 등) 역시 Kubernetes 클러스터 내부에서 운영되고 있습니다. 이러한 환경에서 GitHub Actions Self-Hosted Runner를 추가로 구축하여, GitHub 저장소에서 Push 또는 Pull Request가 발생할 때마다 자동으로 Dev 환경에 접근하여 실전 데이터를 기반으로 테스트가 실행되도록 구성했습니다.

 

이 구조를 사용하면 다음과 같은 장점이 있습니다.

• Mock이 아닌 실제 Dev 데이터 흐름을 통한 테스트 수행
• 개발자가 로컬 환경에서 일일이 테스트를 실행할 필요 없음
• PR 기반 자동 테스트로 코드 안정성 향상

 

실전 데이터 테스트를 위한 Self-hosted Runner 구축

이번 문서에서는 예시로 Kubernetes 환경에 Kafka와 Elasticsearch와 같은 미들웨어를 배포하고, 여기에 GitHub Actions Self-Hosted Runner를 연동하여 실전 데이터를 이용한 테스트 환경을 구축하는 방법을 다뤄보겠습니다.

 

예시로 Kafka와 Elasticsearch를 사용하지만, 이 글의 핵심은 어떤 미들웨어를 쓰는가가 아니라 GitHub Actions Self-Hosted Runner를 어떻게 Dev 환경과 붙여서 실전 데이터를 테스트에 활용하는가에 있습니다. 따라서 인프라 구성보다도, Self-Hosted Runner를 Kubernetes 위에 올리고, 이를 통해 테스트가 자동으로 실행되도록 만드는 과정에 초점을 맞춰서 설명하겠습니다.

미들웨어(Kafka, Elasticsearch) 설치 방법이나 Helm 차트 설정 등 보다 상세한 인프라 구성 방법이 궁금하시다면, 문서 아래 GitHub 저장소를 참고해 주시면 됩니다.

 

전제 조건

• Kubernetes 클러스터 내에 Kafka, Elasticsearch 등 미들웨어가 배포되어 있다고 가정
• 동일 클러스터(또는 같은 네트워크)에 GitHub Actions Self-Hosted Runner를 배치한다.
• GitHub에 Push나 Pull Request가 발생할 때마다 Runner가 Dev 환경의 실제 데이터에 접근하여 테스트를 수행한다.

Github action self-hosted runner controller 설치

NAMESPACE="gh-runner"
kubectl create namespace ${NAMESPACE}

NAMESPACE="gh-runner"
helm upgrade --install gh-arc \
	oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller \
	--namespace "${NAMESPACE}" --create-namespace

 

Github action self-hosted runner values.yaml

runnerScaleSetName: "runner-set"

containerMode:
  type: "dind"
  kubernetesModeWorkVolumeClaim:
    accessModes: ["ReadWriteOnce"]
    storageClassName: "dynamic-blob-storage"
    resources:
      requests:
        storage: 1Gi

 

Github action self-hosted runner 배포

GITHUB_TOKEN, GITHUB_REPO 값을 설정한 후 아래 명령어를 실행하여 self-hosted runner를 배포합니다.

GITHUB_TOKEN=<your_github_token>
GITHUB_REPO=<your_github_repo>
NAMESPACE="gh-runner"

helm upgrade --install gh-runner \
    oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set \
    --namespace ${NAMESPACE} --create-namespace \
    -f dev_setup/helm/gh-runner.yaml \
    --set githubConfigSecret.github_token=${GITHUB_TOKEN} \
    --set githubConfigUrl=${GITHUB_REPO}

 

Github Repo 변수 설정

실전 테스트를 위해서는 Github Repo에 Kafka와 Elasticsearch 접속 정보를 변수로 설정해야 합니다. 아래는 예시로 설정한 변수들입니다. Github repo > Settings > Secrets and variables > Actions > Variables

• KAFKA_BROKERS: Kafka 브로커 주소
• KAFKA_TOPIC: Kafka 토픽 이름
• ELASTICSEARCH_ADDR: Elasticsearch 주소
• ELASTICSEARCH_INDEX: Elasticsearch 인덱스 이름
• ELASTICSEARCH_USER: Elasticsearch 사용자 이름 (Secret)
• ELASTICSEARCH_PASSWORD: Elasticsearch 비밀번호 (Secret)

 

실전 테스트를 위한 Github workflow 작성

실전 데이터를 이용한 테스트를 위해서는 Github workflow를 작성해야 합니다. 아래는 예시로 작성한 workflow입니다. 이 workflow는 push 또는 pull request가 발생할 때마다 self-hosted runner에서 go test를 실행하여 실전 데이터를 이용한 테스트를 수행합니다.

name: Test Runner

on:
  push:
    branches:
      - develop
  pull_request:
    branches:
      - main
  workflow_dispatch:

jobs:
  go-test:
    runs-on: runner-set
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up golang
        uses: actions/setup-go@v5
        with:
          go-version: ${{ vars.GH_GO_VERSION }}

      - name: Run tests
        env:
          KAFKA_BROKERS: ${{ vars.KAFKA_BROKERS }}
          KAFKA_TOPIC: ${{ vars.KAFKA_TOPIC }}
          ELASTICSEARCH_ADDR: ${{ vars.ELASTICSEARCH_ADDR }}
          ELASTICSEARCH_INDEX: ${{ vars.ELASTICSEARCH_INDEX }}
          ELASTICSEARCH_USER: ${{ secrets.ELASTICSEARCH_USER }}
          ELASTICSEARCH_PASSWORD: ${{ secrets.ELASTICSEARCH_PASSWORD }}
        run: |
          echo "Running tests..."
          echo "Go version: $(go version)"

          go test -v ./...

 

테스트 결과 확인

위와 같이 구성을 완료하면, GitHub 저장소에 Push 또는 Pull Request가 발생할 때마다 Kubernetes 내부에 배치된 Self-Hosted Runner가 자동으로 동작하게 됩니다. Runner는 Dev 환경의 Kafka와 Elasticsearch 등 실제 미들웨어에 직접 접속하여 실전 데이터를 기반으로 테스트를 수행합니다.

 

지금 예시에서는 단순히 go test를 실행하여 테스트가 정상적으로 통과하는지만 확인했지만, 실제 개발 환경에서는 이 테스트 실행 결과를 기반으로 훨씬 다양한 자동화 작업을 확장할 수 있습니다.

 

예를 들어:

• 테스트 실패 시 Slack·Teams·Email 알림 전송
• 테스트 결과에 따라 배포 파이프라인 자동 실행
• 테스트 통과 시 이미지 빌드 및 릴리즈 태깅
• 운영 환경과 유사한 E2E 테스트 추가
• 실제 데이터 품질 검증 또는 샘플링 파이프라인 연결
• 성능 테스트/지표 수집 자동화

 

이처럼 Self-Hosted Runner를 통해 Dev 환경의 실전 데이터를 테스트에 활용함으로써, 단순 Mock 단위 테스트를 넘어선 신뢰도 높은 CI 환경을 구축할 수 있습니다. 개발자는 로컬에서 일일이 테스트 환경을 셋업 할 필요 없이, PR만 생성해도 실전 테스트가 자동으로 실행되기 때문에 개발 속도와 코드 안정성 모두 크게 향상됩니다.

 

예시 프로젝트 링크

https://github.com/k8shuginn/event-collector

GitHub - k8shuginn/event-collector