<div id="readability-page-1" class="page"><div>
        <h2 id="1-qa-자동화의-필요성">1. QA 자동화의 필요성</h2>

<p>QA는 프로젝트에 참여하면 PM, 디자이너, 개발자뿐만 아니라 테스터인 외주 인력과 함께 다양한 유형(스모크 테스트, 기능 테스트, 리그레션 테스트, 확인 테스트 등)의 테스트를 진행하고 sign off를 하게 됩니다. 최근 QA팀은 외주 인력을 활용한 수동 테스트에 의존하여 많은 리소스를 소모하고 있었습니다. 이는 테스트 실행 속도가 느리고, 인력 관리의 어려움으로 인해 효율적인 테스트 환경을 구축하는 데 한계가 있었습니다. 이에 따라, 자동화 테스트를 도입하여 리소스를 절감하고 효율성을 높이는 것이 중요한 목표로 설정되었습니다.</p>

<p>자동화 테스트에는 크게 E2E 테스트와 API 테스트 정도로 많이 활용되는데요. E2E 테스트는 전체 시스템의 동작을 점검하고 실제 사용자 흐름을 검증하지만, API 테스트는 서버 간의 데이터 통신만 검사하는 방식입니다.</p>

<table>
  <thead>
    <tr>
      <th>항목</th>
      <th><strong>E2E 테스트</strong></th>
      <th><strong>API 테스트</strong></th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><strong>목적</strong></td>
      <td>전체 시스템의 기능을 사용자 관점에서 테스트</td>
      <td>API 요청과 응답이 올바르게 처리되는지 확인</td>
    </tr>
    <tr>
      <td><strong>범위</strong></td>
      <td>UI + 백엔드 시스템 전체</td>
      <td>백엔드의 API만 테스트</td>
    </tr>
    <tr>
      <td><strong>검증 항목</strong></td>
      <td>UI 상호작용, 비즈니스 로직, 사용자 흐름</td>
      <td>요청/응답, 상태 코드, 응답 데이터</td>
    </tr>
    <tr>
      <td><strong>실행 시간</strong></td>
      <td>시간이 오래 걸리고 복잡함</td>
      <td>빠르고 간단함</td>
    </tr>
    <tr>
      <td><strong>도구</strong></td>
      <td>Selenium, Cypress, Playwright 등</td>
      <td>Postman, SoapUI 등</td>
    </tr>
  </tbody>
</table>

<p>검증 자체의 효과는 E2E 테스트가 좋을 순 있지만, 화면의 변동성이 크다면 유지보수에 리소스가 많이 투자되는 번거로움이 존재합니다. 반면에 API는 한번 구현해두면 변동성이 적다는 장점이 있습니다. 그래서 “API를 활용하여 간단한 플로우부터 구현해보자!” 라는 아이디어를 가지고 자동화를 시작하게 되었습니다.</p>



<h2 id="2-초기-자동화-아키텍처">2. 초기 자동화 아키텍처</h2>

<p>초기에는 사내에 기존 자동화 히스토리를 참고하여 Jenkins 기반으로 구축하기로 하였습니다. 초기 모델은 Zephyr에서 테스트해야 할 항목을 제공하고, 그에 맞게 Postman Script를 실행하여 얻은 결과를 Slack으로 공유하는 방식으로 구성하였습니다.</p>


<p><img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/automation_flow_1.jpg">
  <img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/automation_flow.png">
</p>

<h2 id="21-jenkins의-문제">2.1 Jenkins의 문제</h2>

<p>Jenkins를 직접 로컬에 설치해보고 EC2 환경에 구축해보면서 몇 가지 단점이 있었습니다.</p>

<ol>
  <li>직접 Jenkins 서버 환경을 구축하고 관리해야 하는 어려움</li>
  <li>AWS EC2 환경에 대한 지식이 필요하여 러닝 커브가 있음</li>
  <li>설정이 복잡하여 GitHub Actions 같은 간단한 YAML 기반의 CI/CD보다 접근성이 낮음</li>
</ol>

<p>이런 단점을 보완하고자 이전에 웹 환경의 E2E 자동화를 했던 경험을 바탕으로 GitHub Actions를 구현하여 제안을 해보게 되었습니다.</p>



<h2 id="3-github-actions-도입-과정">3. GitHub Actions 도입 과정</h2>

<p>도입에 앞서 기존 구조가 달라지기 때문에 팀원들을 설득해야 했습니다. 그래서 구조를 다시 잡고 PoC 형태로 간단하게 구현하여 팀원들에게 공유하였습니다.</p>

<p>구현 과정은 다음과 같습니다:</p>

<h2 id="31-자동화-아키텍처">3.1 자동화 아키텍처</h2>



<p><img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/automation_architecture.png" alt="자동화_플로우"></p>



<h2 id="32-자동화-poc">3.2 자동화 PoC</h2>

<h4 id="1-로그인-회원가입-관련-postman-api-script-작성">1) 로그인, 회원가입 관련 Postman API Script 작성</h4>
<ul>
  <li>
    <p>ID, PW 올바르게 입력한 경우 → 200  ⇒ 성공
<img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/script_1.png" alt="자동화_플로우"></p>
  </li>
  <li>
    <p>올바르지 않은 PW 입력한 경우, 올바르지 않은 ID 입력한 경우 → 400 ⇒ 성공
<img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/script_2.png" alt="자동화_플로우">
<img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/script_3.png" alt="자동화_플로우"></p>
  </li>
</ul>



<h4 id="2-postman-script-파일-github-merge">2) postman script 파일 github merge</h4>
<ul>
  <li>테스트용으로 feat/slack-api 브랜치 → main 브랜치에 merge</li>
</ul>



<h4 id="3-collections을-github-공용-runner에서-실행">3) collections을 github 공용 runner에서 실행</h4>
<ul>
  <li>
    <p>github actions workflow 사용을 위한 .yml 파일 생성 
<img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/github_1.png" alt="자동화_플로우"></p>
  </li>
  <li>
    <p>github에서 제공하는 cloud runner에서 newman 실행
<img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/github_2.png" alt="자동화_플로우"></p>
  </li>
</ul>



<h4 id="4-수행한-결과를-slack-채널에-알림을-보냄">4) 수행한 결과를 slack 채널에 알림을 보냄</h4>
<p><img src="https://tech.socarcorp.kr/img/2025-06-02-qa-automation-environment/newman_1.png" alt="slack 알림"></p>



<h2 id="33-jenkins와-github-actions-비교">3.3 Jenkins와 GitHub Actions 비교</h2>
<p>Jenkins는 많은 기업에서 CI/CD 도구로 사용되어 온 대표적인 자동화 도구입니다. 하지만, Jenkins를 EC2에 구축하고 관리하는 방식은 여러 가지 문제를 안고 있었습니다. 서버의 안정성을 보장하기 위해 추가적인 관리 리소스가 필요했고, 플러그인 업데이트나 서버 유지보수, 백업 작업 등을 수시로 해야 했습니다. 이로 인해 운영의 복잡성이 증가했으며, 각종 플러그인 간의 호환성 문제도 발생할 수 있었습니다.</p>

<p>반면, GitHub Actions는 GitHub 플랫폼 내에서 제공되는 CI/CD 서비스로, 서버 관리의 부담을 덜어주는 장점이 있었습니다. 별도의 서버를 구축할 필요 없이 GitHub의 리소스를 그대로 활용할 수 있으며, 코드와 CI/CD 파이프라인을 하나의 저장소 내에서 관리할 수 있어 관리의 효율성이 높았습니다.</p>



<h2 id="34-github-actions-도입-전략과-팀-온보딩-경험">3.4 GitHub Actions 도입 전략과 팀 온보딩 경험</h2>
<p>API 자동화 프로젝트를 진행하면서 GitHub Actions를 도입해 자동화 효율을 높이는 동시에, 팀원들과의 협업과 온보딩을 통해 팀 전체의 역량을 함께 끌어올렸습니다.</p>

<p>우선 GitHub Actions 도입을 위해 두 가지 주요 전략을 설정했습니다.</p>

<blockquote>
  <p>💡 <strong>전략</strong></p>
  <ol>
    <li>기존 Jenkins 기반의 스크립트를 GitHub Actions 환경에 맞게 YAML 형식으로 수정하고, 저장소에 푸시한 후 반복적인 검증을 통해 점진적으로 이식해 나갔습니다.</li>
    <li>GitHub Actions의 스케줄 기능을 활용해 테스트를 정기적으로 실행하도록 설정함으로써, 수동 테스트의 부담을 줄이고 QA팀이 자동화된 테스트 결과를 주기적으로 확인할 수 있도록 했습니다.</li>
  </ol>
</blockquote>

<p>도입 과정에서 팀원들이 Git과 GitHub Actions 사용에 어려움을 겪었기 때문에, 이를 해결하기 위해 직접 온보딩 세션을 진행했습니다. 세션에서는 Git과 GitHub의 기본 개념을 실습 중심으로 설명하며, GitHub Actions를 활용한 API 자동화 워크플로우 작성 방법을 공유했습니다. 또한, Postman 환경 변수를 GitHub Actions에서 적용하는 방법, GitHub Secrets 관련 오류 해결법 등 실무에서 바로 활용할 수 있는 내용을 포함하여 팀원들이 독립적으로 자동화 작업을 수행할 수 있도록 도왔습니다.</p>

<p>이러한 전략적 도입과 적극적인 온보딩을 통해 팀원들은 GitHub Actions 기반의 워크플로우를 독립적으로 작성하고 관리할 수 있는 역량을 갖추게 되었고, 결과적으로 팀 전체의 자동화 생산성을 크게 향상시킬 수 있었습니다.</p>



<h2 id="4-github-actions-도입-성과와-postman-자동화의-한계">4. GitHub Actions 도입 성과와 Postman 자동화의 한계</h2>
<p>GitHub Actions 도입을 통해 얻은 가장 큰 성과 중 하나는 작업 기간의 대폭 단축이었습니다. Jenkins를 사용할 경우 새로운 환경 구축에 약 4개월이 소요될 것으로 예상되었지만, GitHub Actions는 간결한 구성 요소와 직관적인 설정 방식 덕분에 단 1개월 만에 환경을 구축할 수 있었습니다. 작업 기간을 약 75% 단축함으로써, 팀의 생산성과 효율성을 크게 향상시킬 수 있었습니다.</p>

<p>또한, GitHub Actions 기반의 CI/CD 파이프라인을 통해 API 테스트 자동화 기반을 성공적으로 구축했습니다. 이를 바탕으로 향후에는 배포 주기에 맞춰 테스트가 자동으로 수행되는 체계를 갖출 수 있는 기반을 마련했습니다.</p>

<p>하지만 GitHub Actions와 Postman을 활용한 자동화가 모든 상황에서 이상적인 것은 아니었습니다. 실제로 도입 후 특정 도메인 서버 구조에 적용해보려 했을 때 예상치 못한 구조적 한계에 직면했습니다. 해당 도메인은 gRPC와 REST API가 혼합된 서버 아키텍처였고, 우리가 구축한 Postman 기반 스크립트는 REST API 호출에 최적화되어 있었습니다. 이로 인해 gRPC 호출이 포함된 전체 흐름의 시나리오 구현에는 어려움이 있었습니다.</p>

<p>결과적으로, 기존 스크립트만으로는 플로우 전반의 유효성 검증이나 상태 전이 기반 테스트 한계가 있었고, 보다 복잡한 테스트 환경이 필요하다는 결론에 도달하게 되었습니다.</p>



<h2 id="5-실패를-통해-얻은-방향-전환">5. 실패를 통해 얻은 방향 전환</h2>
<p>이 경험은 단순히 도입을 보류하는 데 그치지 않았습니다. 오히려 자동화 전략을 재정립하는 계기가 되었습니다. 전 구간 자동화는 어렵더라도, 테스트 데이터 생성, 사전 조건 세팅, 반복 작업 자동화 등 효율성을 높일 수 있는 현실적인 영역부터 자동화를 적용하고 있습니다.</p>

<p>현재는 각 도메인별로 작은 단위부터 자동화를 점진적으로 확장하며, 실제 테스트 환경에서 바로 활용할 수 있는 실용적인 자동화 도구들을 구축해가고 있습니다.</p>

<p>완벽한 자동화보다는 지속 가능한 자동화, 지금 당장 효과를 줄 수 있는 부분부터 개선해나가는 것이 현재 우리가 택한 방향이며, 앞으로도 더 나은 테스트 환경을 위해 끊임없이 개선해나갈 예정입니다.</p>

        </div></div>

SOCAR Tech Blog

1. QA 자동화의 필요성
QA는 프로젝트에 참여하면 PM, 디자이너, 개발자뿐만 아니라 테스터인 외주 인력과 함께 다양한 유형(스모크 테스트, 기능 테스트, 리그레션 테스트, 확인 테스트 등)의 테스트를 진행하고 sign off를 하게 됩니다. 최근 QA팀은 외주 인력을 활용한 수동 테스트에 의존하여 많은 리소스를 소모하고 있었습니다. 이는 테스트 실행 속도가 느리고, 인력 관리의 어려움으로 인해 효율적인 테스트 환경을 구축하는 데 한계가 있었습니다. 이에 따라, 자동화 테스트를 도입하여 리소스를 절감하고 효율성을 높이는 것이 중요한 목표로 설정되었습니다.
자동화 테스트에는 크게 E2E 테스트와 API 테스트 정도로 많이 활용되는데요. E2E 테스트는 전체 시스템의 동작을 점검하고 실제 사용자 흐름을 검증하지만, API 테스트는 서버 간의 데이터 통신만 검사하는 방식입니다.
항목
      E2E 테스트
      API 테스트
    
목적
      전체 시스템의 기능을 사용자 관점에서 테스트
      API 요청과 응답이 올바르게 처리되는지 확인
    
범위
      UI + 백엔드 시스템 전체
      백엔드의 API만 테스트
    
검증 항목
      UI 상호작용, 비즈니스 로직, 사용자 흐름
      요청/응답, 상태 코드, 응답 데이터
    
실행 시간
      시간이 오래 걸리고 복잡함
      빠르고 간단함
    
도구
      Selenium, Cypress, Playwright 등
      Postman, SoapUI 등
    
검증 자체의 효과는 E2E 테스트가 좋을 순 있지만, 화면의 변동성이 크다면 유지보수에 리소스가 많이 투자되는 번거로움이 존재합니다. 반면에 API는 한번 구현해두면 변동성이 적다는 장점이 있습니다. 그래서 “API를 활용하여 간단한 플로우부터 구현해보자!” 라는 아이디어를 가지고 자동화를 시작하게 되었습니다.
2. 초기 자동화 아키텍처
초기에는 사내에 기존 자동화 히스토리를 참고하여 Jenkins 기반으로 구축하기로 하였습니다. 초기 모델은 Zephyr에서 테스트해야 할 항목을 제공하고, 그에 맞게 Postman Script를 실행하여 얻은 결과를 Slack으로 공유하는 방식으로 구성하였습니다.
2.1 Jenkins의 문제
Jenkins를 직접 로컬에 설치해보고 EC2 환경에 구축해보면서 몇 가지 단점이 있었습니다.
직접 Jenkins 서버 환경을 구축하고 관리해야 하는 어려움
AWS EC2 환경에 대한 지식이 필요하여 러닝 커브가 있음
설정이 복잡하여 GitHub Actions 같은 간단한 YAML 기반의 CI/CD보다 접근성이 낮음
이런 단점을 보완하고자 이전에 웹 환경의 E2E 자동화를 했던 경험을 바탕으로 GitHub Actions를 구현하여 제안을 해보게 되었습니다.
3. GitHub Actions 도입 과정
도입에 앞서 기존 구조가 달라지기 때문에 팀원들을 설득해야 했습니다. 그래서 구조를 다시 잡고 PoC 형태로 간단하게 구현하여 팀원들에게 공유하였습니다.
구현 과정은 다음과 같습니다:
3.1 자동화 아키텍처
3.2 자동화 PoC
1) 로그인, 회원가입 관련 Postman API Script 작성
ID, PW 올바르게 입력한 경우 → 200  ⇒ 성공
올바르지 않은 PW 입력한 경우, 올바르지 않은 ID 입력한 경우 → 400 ⇒ 성공
2) postman script 파일 github merge
테스트용으로 feat/slack-api 브랜치 → main 브랜치에 merge
3) collections을 github 공용 runner에서 실행
github actions workflow 사용을 위한 .yml 파일 생성 
github에서 제공하는 cloud runner에서 newman 실행
4) 수행한 결과를 slack 채널에 알림을 보냄
3.3 Jenkins와 GitHub Actions 비교
Jenkins는 많은 기업에서 CI/CD 도구로 사용되어 온 대표적인 자동화 도구입니다. 하지만, Jenkins를 EC2에 구축하고 관리하는 방식은 여러 가지 문제를 안고 있었습니다. 서버의 안정성을 보장하기 위해 추가적인 관리 리소스가 필요했고, 플러그인 업데이트나 서버 유지보수, 백업 작업 등을 수시로 해야 했습니다. 이로 인해 운영의 복잡성이 증가했으며, 각종 플러그인 간의 호환성 문제도 발생할 수 있었습니다.
반면, GitHub Actions는 GitHub 플랫폼 내에서 제공되는 CI/CD 서비스로, 서버 관리의 부담을 덜어주는 장점이 있었습니다. 별도의 서버를 구축할 필요 없이 GitHub의 리소스를 그대로 활용할 수 있으며, 코드와 CI/CD 파이프라인을 하나의 저장소 내에서 관리할 수 있어 관리의 효율성이 높았습니다.
3.4 GitHub Actions 도입 전략과 팀 온보딩 경험
API 자동화 프로젝트를 진행하면서 GitHub Actions를 도입해 자동화 효율을 높이는 동시에, 팀원들과의 협업과 온보딩을 통해 팀 전체의 역량을 함께 끌어올렸습니다.
우선 GitHub Actions 도입을 위해 두 가지 주요 전략을 설정했습니다.
💡 전략
기존 Jenkins 기반의 스크립트를 GitHub Actions 환경에 맞게 YAML 형식으로 수정하고, 저장소에 푸시한 후 반복적인 검증을 통해 점진적으로 이식해 나갔습니다.
GitHub Actions의 스케줄 기능을 활용해 테스트를 정기적으로 실행하도록 설정함으로써, 수동 테스트의 부담을 줄이고 QA팀이 자동화된 테스트 결과를 주기적으로 확인할 수 있도록 했습니다.
도입 과정에서 팀원들이 Git과 GitHub Actions 사용에 어려움을 겪었기 때문에, 이를 해결하기 위해 직접 온보딩 세션을 진행했습니다. 세션에서는 Git과 GitHub의 기본 개념을 실습 중심으로 설명하며, GitHub Actions를 활용한 API 자동화 워크플로우 작성 방법을 공유했습니다. 또한, Postman 환경 변수를 GitHub Actions에서 적용하는 방법, GitHub Secrets 관련 오류 해결법 등 실무에서 바로 활용할 수 있는 내용을 포함하여 팀원들이 독립적으로 자동화 작업을 수행할 수 있도록 도왔습니다.
이러한 전략적 도입과 적극적인 온보딩을 통해 팀원들은 GitHub Actions 기반의 워크플로우를 독립적으로 작성하고 관리할 수 있는 역량을 갖추게 되었고, 결과적으로 팀 전체의 자동화 생산성을 크게 향상시킬 수 있었습니다.
4. GitHub Actions 도입 성과와 Postman 자동화의 한계
GitHub Actions 도입을 통해 얻은 가장 큰 성과 중 하나는 작업 기간의 대폭 단축이었습니다. Jenkins를 사용할 경우 새로운 환경 구축에 약 4개월이 소요될 것으로 예상되었지만, GitHub Actions는 간결한 구성 요소와 직관적인 설정 방식 덕분에 단 1개월 만에 환경을 구축할 수 있었습니다. 작업 기간을 약 75% 단축함으로써, 팀의 생산성과 효율성을 크게 향상시킬 수 있었습니다.
또한, GitHub Actions 기반의 CI/CD 파이프라인을 통해 API 테스트 자동화 기반을 성공적으로 구축했습니다. 이를 바탕으로 향후에는 배포 주기에 맞춰 테스트가 자동으로 수행되는 체계를 갖출 수 있는 기반을 마련했습니다.
하지만 GitHub Actions와 Postman을 활용한 자동화가 모든 상황에서 이상적인 것은 아니었습니다. 실제로 도입 후 특정 도메인 서버 구조에 적용해보려 했을 때 예상치 못한 구조적 한계에 직면했습니다. 해당 도메인은 gRPC와 REST API가 혼합된 서버 아키텍처였고, 우리가 구축한 Postman 기반 스크립트는 REST API 호출에 최적화되어 있었습니다. 이로 인해 gRPC 호출이 포함된 전체 흐름의 시나리오 구현에는 어려움이 있었습니다.
결과적으로, 기존 스크립트만으로는 플로우 전반의 유효성 검증이나 상태 전이 기반 테스트 한계가 있었고, 보다 복잡한 테스트 환경이 필요하다는 결론에 도달하게 되었습니다.
5. 실패를 통해 얻은 방향 전환
이 경험은 단순히 도입을 보류하는 데 그치지 않았습니다. 오히려 자동화 전략을 재정립하는 계기가 되었습니다. 전 구간 자동화는 어렵더라도, 테스트 데이터 생성, 사전 조건 세팅, 반복 작업 자동화 등 효율성을 높일 수 있는 현실적인 영역부터 자동화를 적용하고 있습니다.
현재는 각 도메인별로 작은 단위부터 자동화를 점진적으로 확장하며, 실제 테스트 환경에서 바로 활용할 수 있는 실용적인 자동화 도구들을 구축해가고 있습니다.
완벽한 자동화보다는 지속 가능한 자동화, 지금 당장 효과를 줄 수 있는 부분부터 개선해나가는 것이 현재 우리가 택한 방향이며, 앞으로도 더 나은 테스트 환경을 위해 끊임없이 개선해나갈 예정입니다.

자동화는 처음이라: 실험과 실패, 그리고 성장

댓글