v2 지속적 통합(CI) 파이프라인 설계

1. v1 CI의 한계

2.1 수동 테스트 의존

수동 테스트의 한계: v1 CI에는 별도의 자동화 테스트가 없어 기능 검증을 수동 테스트에 의존하고 있다. 수동 테스트는 동일한 시나리오를 반복하기 어렵고 사람이 결과를 직접 확인하는 과정에서 부주의로 오류를 놓칠 가능성이 있다. 서비스 규모와 기능이 커질수록 모든 시나리오를 반복적으로 검증하기 어렵다

1.2 자동화된 실행 기반 테스트 부재

런타임 테스트 부재 : v1에서는 전체 개발의 70%를 2주만에 완성 해야하는 만큼 개발 볼륨이 커서 별도의 테스트 코드를 작성하지 않고 정적인 테스트만 진행했다. 테스트가 없기 떄문에 버그를 발견하는 시점이 늦다는 한계가 있다.

---

3. v2 CI의 목적

v2 CI는 코드 변경 사항을 병합 전에 자동으로 검증해 장애를 사전에 예방하고 안정적인 코드 병합을 지원하는 것을 목적으로 한다.

1. 정적 검사, 단위 테스트, 핵심 API 테스트와 빌드를 자동화한다.
2. 변경으로 인해 기존 기능이 깨지는 회귀 결함을 조기에 발견한다.
3. 모든 필수 검사를 통과한 코드만 dev 브랜치에 병합한다.
4. 개인의 수동 확인에 의존하던 검증 절차를 반복 가능한 파이프라인으로 전환한다.

---

4. 브랜치 전략과 CI 실행 시점

4.1 브랜치 역할

main–dev–feat/* 브랜치 전략을 사용한다.

브랜치	역할
main	배포 가능한 안정 버전 관리
dev	각 기능 개발 결과를 통합하고 검증하는 브랜치
feat/*	기능 단위 개발 브랜치

4.2 CI 트리거

CI는 dev 브랜치를 대상으로 하는 Pull Request가 생성되거나 새로운 커밋으로 갱신될 때 실행한다. GitHub Actions의 pull_request 이벤트와 대상 브랜치 필터를 사용한다.

feat/* 브랜치에 push
        ↓
dev 대상 Pull Request 생성 
        ↓
CI 실행 ─────────────┐
        코드 리뷰 ────┤ 병행
                     ↓
최신 커밋의 CI 통과 + 리뷰어 1명 이상 승인
                     ↓
dev 브랜치에 병합
                     ↓
dev에서 main으로

CI 통과와 리뷰어 승인을 둘다 통과해야 병합이 가능합니다.

• Pull Request를 통한 병합만 허용
• 필수 CI 상태 검사 통과
• 리뷰어 1명 이상의 승인 (pr 올린 사람을 제외하고)
• 새 커밋이 추가되면 최신 커밋을 기준으로 CI 재실행
• 필요하면 새 커밋 push 시 기존 리뷰 승인 해제

---

5. CI 도구 선정: GitHub Actions

v1에서는 팀이 GitHub Actions 외의 CI/CD 도구를 사용한 경험이 없었다. 추가 도구 도입에 필요한 학습 시간과 운영 부담을 줄이기 위해 GitHub Actions를 선택했으며 v2에서도 기존 도구를 유지한다.

v2의 CI는 Pull Request 기반 정적 검사 뿐만 아니라 테스트와 빌드가 중심이므로 GitHub Actions만으로 요구 사항을 충족할 수 있다. 또한 GitHub 저장소, Pull Request와 브랜치 보호 규칙을 별도 연동 작업 없이 함께 관리할 수 있다.

---

6. 테스트

v1의 정적 검사는 기존 설정을 유지하고 실행 기반 테스트를 추가해 코드 변경으로 발생하는 결함을 병합 전에 확인한다.

6.1 Frontend

정적 검사 → 단위 테스트 → 빌드

• 정적 검사: 기존 lint, 타입 검사와 코드 스타일 검사를 유지한다.
• 단위 테스트: JavaScript 함수와 클릭,입력 이벤트 처리를 검증한다.

frontend에서 API 테스트 제외 이유

Frontend와 Backend가 별도 저장소로 분리된 상태에서 백엔드 서버 없이 가짜 API 응답만 사용하면 프론트엔드의 응답 처리 로직은 확인할 수 있지만, 실제 API 연동까지 보장할 수는 없다. 따라서 v2 Frontend CI에서는 API 테스트를 제외하고 정적 검사와 단위 테스트에 집중한다.

6.2 Backend 및 AI

정적 검사 → 단위 테스트 → 테스트 DB 실행 → 핵심 API 테스트 → 빌드

Workflow: Backend CI
└─ Job: backend-ci
   ├─ Step 1. 정적 검사
   │      ↓
   ├─ Step 2. 단위 테스트
   │      ↓
   ├─ Step 3. 테스트 DB 기동
   │      ↓
   ├─ Step 4. 핵심 API 테스트
   │      ↓
   └─ Step 5. 빌드

GitHub Actions의 동일한 Job 안에 있는 Step은 위에서 아래로 순차 실행된다. 테스트 DB가 준비된 이후에만 핵심 API 테스트를 실행하며 앞 단계가 실패하면 이후 단계는 실행하지 않고 CI를 실패 처리한다. 테스트 DB는 Testcontainers가 제공하는 MySQL 컨테이너를 사용한다. 이를 통해 운영 DB와 분리된 환경에서 데이터 접근과 트랜잭션을 검증한다.

6.3 단위 테스트

frontend :Vitest,jsdom

• Vitest: JavaScript 단위 테스트 실행
• jsdom: Node.js 기반 CI 환경에서 가상 브라우저 환경을 만들어서 요소 조회, 이벤트 처리와 화면 내용 변경 검증함

Java: JUnit 5

Backend 단위 테스트에는 JUnit 5를 사용한다. JUnit 5는 기존 Gradle 빌드와 GitHub Actions에서 바로 실행할 수 있고 Spring Boot 테스트 생태계와도 연동된다.

Python: pytest

LLM의 답변 품질이 테스트의 목정이 아니기 떄문에 실제 외부 LLM api를 직접 부르지 않고 가짜 사용자를 만들어 항상 똑같은 응답이 오도록 해야한다. 이때 fixture라는 함수로 간단하게 가짜 사용자 정보를 만들 수 있어서 사용할 예정이다.

6.4 핵심 API 테스트

Backend

[테스트 도구]

• JUnit 5: 테스트 실행과 결과 검증
• Spring Boot Test: 애플리케이션 컨텍스트를 포함한 통합 테스트
• MockMvc: 실제 네트워크 포트를 열지 않고 Spring MVC 계층에 가짜 HTTP 요청을 전송해준다
• Testcontainers MySQL: 테스트용 MySQL 컨테이너 제공한다.

[restapi]

• 로그인
• 전체 프로필 조회
• 상세 프로필 조회
• 좋아요 등록
• 매칭 요청

[채팅 메시지]

• 메시지 저장
• 메시지 조회
• 채팅방 참여자만 메시지를 전송가능한지.

AI

[테스트 도구]

• pytest: 테스트 실행, 테스트 케이스 관리와 결과 검증 (fixture)

• FastAPI TestClient: 실제 네트워크 포트를 열지 않고 Spring MVC 계층에 가짜 HTTP 요청을 전송해준다

• mock: 외부 LLM API 호출을 예측 가능한 가짜 응답으로 대체

• AI–사용자 연습 대화

• AI 간 대화

• 사주 분석

• 관상 분석

Frontend, Backend, AI가 각각 별도 저장소로 관리되고 있어 전체 사용자 흐름을 검증하려면 세 서비스를 동일 버전으로 배포하고 연결하는 별도의 통합 테스트 환경이 필요하다. v2에서는 일정과 구축 비용을 고려해 E2E 테스트,통합테스트를 제외하고 저장소별 단위 테스트와 핵심 API 테스트를 진행한다.

---

7. 참고 자료

• 수동 테스트와 테스트 자동화 관련 참고 자료
• 회귀 테스트 자동화와 CI/CD 파이프라인