Need U V1 : CI(지속적 통합) 파이프라인 설계 - 100-hours-a-week/KTB4-4th-wiki GitHub Wiki

1. 설계 목적
2. V1 배포 구조와 CI 대상
3. CI 도구 선택
4. Branch 및 Trigger 정책
5. Frontend CI
6. Backend CI
7. AI Server CI
8. Artifact 및 Docker Image 관리
9. CI 보안
10. 실패 처리 정책
11. 최종 CI 흐름
12. V1 최종 기준

Need U는 Frontend, Spring Boot Backend, FastAPI AI Server를 각각 개발한다.

CI의 목적은 PR과 main 병합 시 동일한 환경에서 코드를 자동으로 검증하여 배포 가능한 상태의 코드만 기준 Branch에 유지하는 것이다.

V1에서는 다음 원칙을 적용한다.

• CI가 실패한 PR은 Merge하지 않는다.
• dev는 개발 중 변경사항을 통합하고 검증하는 Branch로 사용한다.
• main은 실제 Production 배포 후보를 관리하는 Release Branch로 사용한다.
• Frontend, Backend, AI Server는 각자의 기술 스택에 맞는 검증을 수행한다.
• 실제 배포 Artifact는 main의 최종 검증이 성공한 경우에만 생성한다.
• Backend와 AI Server Docker Image는 Git Commit SHA로 버전을 추적한다.
• CI와 CD를 분리하여, CI가 성공했다고 자동으로 운영 서버에 배포하지 않는다.

*GitHub Branch Protection / Ruleset에서는 Required Status Check가 성공해야 PR을 Merge하도록 설정한다.

GitHub Docs - Protected Branches

V1 Production 구조는 다음과 같다.

EC2 t3.medium

├─ Nginx
│  ├─ /      → React/Vite 정적 파일
│  └─ /api   → Spring Boot Backend
│
├─ Docker Compose
│  ├─ Backend (Spring Boot)
│  ├─ AI Server (FastAPI)
│  └─ Redis
│
├─ MySQL
└─ PostgreSQL + pgvector

CI 관점에서는 세 개의 배포 단위를 구분한다.

Backend와 AI Server는 서로 다른 Application이므로 CI에서 검증하는 범위도 구분한다.

Backend
├─ 사용자 / 친구 / 인증
├─ MySQL
├─ Backend에서 사용하는 Redis 기능
├─ 추천 결과 저장
└─ AI Server API 호출

AI Server
├─ FastAPI Endpoint
├─ AI 대화 / 취향 분석
├─ Prompt / Parsing
├─ 외부 LLM API
├─ Embedding API
├─ Redis 기반 AI State / Cache
├─ PostgreSQL + pgvector
└─ Vector Search / Ranking

따라서 Backend CI에서 AI 내부 Vector Search까지 검증하지 않는다.

• Backend CI → AI Server와의 API Contract를 검증
• AI CI → PostgreSQL + pgvector와 실제 AI Logic을 검증

이렇게 책임을 나눈다.

Need U는 GitHub Actions를 사용한다.

선택 이유는 다음과 같다.

• Source Code와 PR Workflow가 이미 GitHub 중심이다.
• 별도의 CI Server를 운영하지 않아도 된다.
• Frontend / Backend / AI Workflow를 각 Repository에서 관리할 수 있다.
• Docker Image Build와 Amazon ECR 연동이 가능하다.
• GitHub Branch Protection과 자연스럽게 연결할 수 있다.
• V1의 빠른 구축과 낮은 운영 복잡도에 적합하다.

Repository는 Private 상태를 유지한다.

CI 사용량은 사전에 정확하게 고정하기보다 실제 GitHub Billing을 기준으로 확인한다.

실행량이 예상보다 증가하면 다음 순서로 조정한다.

1. 불필요한 Workflow Trigger 제거
2. Dependency Cache 적용
3. PR과 Release 단계의 Test 범위 분리
4. 중복 Build 제거

Frontend, Backend, AI Repository 모두 동일한 Branch 전략을 사용한다.

feature/*
   ↓
  dev
   ↓
 main

개발 인원 수와 관계없이 동일한 정책을 사용하는 이유는 Repository마다 Branch 의미가 달라지는 것을 방지하기 위해서다.

개발 중인 기능이 기존 코드와 함께 동작할 수 있는지 빠르게 확인한다.

feature/*
↓
PR → dev
↓
기본 CI
↓
성공 시 Merge

실제 Production Release 후보이므로 기본 Test보다 검증 범위를 넓힌다.

dev
↓
PR → main
↓
Release 검증 CI
↓
성공 시 Merge

main에 실제로 Merge된 최종 상태를 다시 확인한 뒤 배포 Artifact를 생성한다.

main Push
↓
최종 검증
↓
Artifact 생성
↓
CD 대기

PR 단계가 성공했더라도 main에서는 여러 변경사항이 합쳐진 최종 상태를 다시 확인한다.

열려 있는 PR에 Commit이 추가되면 CI를 다시 실행한다.

PR 생성
↓
CI 실행

추가 Commit Push
↓
CI 재실행

운영 중 다음과 같은 핵심 장애가 발생하면 정기 Release를 기다리지 않고 Hotfix를 진행한다.

예:

• 카카오 로그인 전체 실패
• AI 대화 전체 실패
• 추천 기능 사용 불가
• 주요 API 지속적인 5xx 오류

Hotfix는 현재 Production 상태인 main에서 분기한다.

main
↓
hotfix/*
↓
PR → main
↓
main 기준 CI
↓
Merge
↓
긴급 배포

Hotfix라고 CI를 생략하지 않는다.

배포 이후에는 동일한 수정사항을 dev에도 반영하여 다음 정기 Release에서 문제가 다시 발생하지 않도록 한다.

Need U Frontend는 React + Vite 기반이다.

Frontend는 Container로 실행하지 않고 Production Build 결과인 dist/를 Host Nginx에서 제공한다.

빠른 개발 검증을 수행한다.

Type Check
↓
Lint / Format
↓
Vite Build
↓
Merge

TypeScript 타입 오류를 확인한다.

코드 스타일과 기본 정적 오류를 확인한다.

Production용 dist/가 정상적으로 생성되는지 확인한다.

Release 후보에서도 동일한 기본 검증을 수행한다.

Type Check
↓
Lint / Format
↓
Vite Build
↓
Merge

main에서는 실제 배포 Artifact를 생성하고 E2E Test를 수행한다.

Production Build
↓
dist 생성
↓
Playwright E2E
↓
GitHub Actions Artifact 저장
↓
CD 대기

E2E Test는 개별 함수나 Component가 아니라 사용자가 실제로 사용하는 핵심 흐름을 확인한다.

대표 흐름:

카카오 로그인
↓
친구 조회
↓
AI 대화
↓
추천 결과 확인
↓
외부 상품 페이지 이동

E2E Test에서 확인할 수 있는 대표적인 문제는 다음과 같다.

• Frontend Routing
• Backend API 연동
• 인증 흐름
• 화면 간 데이터 전달
• Browser 환경에서의 실제 동작

E2E Test가 실패하면 dist/가 생성되었더라도 Production 배포 대상으로 사용하지 않는다.

Frontend는 Docker Image를 만들지 않는다.

React / Vite
↓
npm run build
↓
dist/
↓
GitHub Actions Artifact
↓
CD
↓
EC2 Nginx

Artifact 이름에는 Commit SHA를 포함한다.

예:

needu-frontend-93fbc21

name: Frontend CI

on:
  pull_request:
    branches: [dev, main]

  push:
    branches: [main]

permissions:
  contents: read

jobs:
  check:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci

      - name: Type Check
        run: npm run type-check

      - name: Lint
        run: npm run lint

      - name: Build
        run: npm run build

  release:
    needs: check

    if: github.event_name == 'push' && github.ref == 'refs/heads/main'

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm run build

      - name: Playwright E2E
        run: |
          npx playwright install --with-deps
          npx playwright test

      - name: Upload Frontend Artifact
        uses: actions/upload-artifact@v4
        with:
          name: needu-frontend-${{ github.sha }}
          path: dist/
          if-no-files-found: error
          retention-days: 14

실제 Script 이름과 Node Version은 Frontend Repository 설정에 맞춰 조정한다.

Backend는 Spring Boot 기반이며 Docker Image 단위로 배포한다.

Backend가 직접 사용하는 주요 구성요소는 다음과 같다.

Backend
├─ MySQL
├─ Redis
└─ AI Server API

AI Server 내부의 PostgreSQL + pgvector, LLM API, Embedding API는 Backend가 직접 처리하지 않는다.

개발 속도를 유지하기 위해 빠른 검증 위주로 수행한다.

Unit Test
↓
Build
↓
Format / Static Check
↓
Merge

주요 목적:

• 변경한 비즈니스 로직 검증
• 기존 기능 Regression 확인
• Compile / Build 오류 확인
• 코드 품질 기본 검사

Production Release 후보이므로 실제 연동을 추가 검증한다.

Unit Test
↓
Build
↓
Integration Test
   ├─ MySQL
   ├─ Redis
   └─ AI Server API Contract / Mock
↓
Docker Build Check
↓
Merge

Backend가 관리하는 일반 서비스 데이터의 기본 Read / Write를 확인한다.

예:

• 사용자
• 친구
• 상품 원본 정보
• 추천 결과

Backend가 Redis를 사용하는 기능이 있는 경우 연결 및 기본 동작을 확인한다.

실제 Redis 사용 범위는 Backend 구현과 AI Server의 Redis 책임 분리가 확정되면 맞춘다.

Backend는 FastAPI 내부 AI Logic을 직접 Test하지 않는다.

대신 Backend와 AI Server 사이의 Interface를 검증한다.

예:

Backend
↓
AI Request Schema
↓
AI Server
↓
AI Response Schema
↓
Backend

검증 범위:

• Request 필드
• Response 필드
• HTTP Status
• Timeout 처리
• AI Server 오류 처리
• 잘못된 Response 처리

CI에서는 Mock Server 또는 Stub을 사용할 수 있다.

dev → main 단계에서는 Dockerfile 자체가 정상적으로 Image를 생성하는지 확인한다.

Source
↓
Dockerfile
↓
docker build
↓
Build 성공 여부

이 단계에서는 ECR에 Push하지 않는다.

main에 Merge된 최종 상태가 성공하면 Production Image를 생성한다.

최종 검증
↓
Docker Image Build
↓
Git Commit SHA Tag
↓
Amazon ECR
↓
CD 대기

ECR Repository:

needu-backend

Image 예시:

needu-backend:a82f3c1

Dockerfile의 목적은 실행 가능한 Production Image를 만드는 것이다.

Unit Test와 Integration Test는 CI에서 먼저 수행한다.

CI Test 성공
↓
Docker Build
↓
Production Image

따라서 Dockerfile의 bootJar가 Test 전체를 담당하도록 하지 않는다.

name: Backend CI

on:
  pull_request:
    branches: [dev, main]

  push:
    branches: [main]

permissions:
  contents: read
  id-token: write

env:
  AWS_REGION: ap-northeast-2
  ECR_REPOSITORY: needu-backend

jobs:
  fast-check:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '25'
          cache: gradle

      - name: Unit Test
        run: ./gradlew test

      - name: Build
        run: ./gradlew build

  release-check:
    needs: fast-check

    if: github.base_ref == 'main' || github.ref == 'refs/heads/main'

    runs-on: ubuntu-latest

    services:
      mysql:
        image: mysql:8.4
        env:
          MYSQL_ROOT_PASSWORD: root
          MYSQL_USER: test
          MYSQL_PASSWORD: test
          MYSQL_DATABASE: needu_test
        ports:
          - 3306:3306

      redis:
        image: redis:7-alpine
        ports:
          - 6379:6379

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '25'
          cache: gradle

      - name: Integration Test
        run: ./gradlew integrationTest

      - name: Docker Build Check
        run: docker build -t needu-backend:ci-check .

  ecr-push:
    needs: release-check

    if: github.event_name == 'push' && github.ref == 'refs/heads/main'

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.BACKEND_CI_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and Push
        env:
          REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        run: |
          docker build \
            -t $REGISTRY/$ECR_REPOSITORY:${{ github.sha }} .

          docker push \
            $REGISTRY/$ECR_REPOSITORY:${{ github.sha }}

integrationTest Task와 실제 환경변수 이름은 Backend 구현에 맞춰 조정한다.

AI Server는 FastAPI 기반의 별도 Application이며 Backend와 독립적으로 배포한다.

외부 LLM과 Embedding Model은 API로 사용하지만, Need U의 AI 기능을 수행하는 FastAPI Server 자체는 직접 개발하고 운영한다.

Backend
↓
AI Server (FastAPI)
├─ Prompt / Parsing
├─ 추천 Logic
├─ 외부 LLM API
├─ Embedding API
├─ Redis
└─ PostgreSQL + pgvector

따라서 AI Repository도 CI와 CD가 모두 필요한 Production Application Repository다.

AI Project는 needu-ai 0.1.0이며 Python 3.12.11을 사용한다.

현재 Dependency는 pyproject.toml과 uv.lock으로 관리하며, CI에서는 uv 0.8.4를 사용한다.

Dependency 설치는 다음 명령을 기준으로 한다.

uv sync --frozen --dev

--frozen을 사용하여 CI에서도 uv.lock에 잠긴 Dependency Version을 그대로 재현한다.

현재 주요 Runtime Dependency는 FastAPI 0.141.1, Uvicorn 0.53.0, Pydantic 2.13.5, Pydantic Core 2.46.5, pydantic-settings 2.15.0, Starlette 1.6.0 기준이다.

AI Repository도 다른 Repository와 동일하게 다음 Branch 전략을 사용한다.

feature/*
   ↓
  dev
   ↓
 main

• feature/*: 기능 개발
• dev: 개발 변경사항 통합 및 기본 검증
• main: Production Release 후보

현재 AI Repository에서 실제로 수행 가능한 기본 검증을 실행한다.

Checkout
↓
Python 3.12.11 설정
↓
uv 0.8.4 설정
↓
uv sync --frozen --dev
↓
Unit Test
↓
Lint
↓
Merge

현재 기준 명령:

uv run pytest tests/unit
uv run ruff check .

AI 내부 Logic을 빠르게 검증한다.

예:

• Prompt / Parsing Logic
• Recommendation Logic
• Schema 처리
• Utility Function
• 외부 API Adapter의 Mock 기반 Logic

Ruff를 사용해 Python 코드의 기본 정적 오류와 코드 품질을 확인한다.

Release 후보에서는 기본 검증을 통과한 뒤 Docker Image가 실제로 Build되는지 확인한다.

feature → dev 단계의 기본 검증
↓
Docker Build Check
↓
Merge

현재 단계에서는 Redis / PostgreSQL + pgvector Integration Test를 필수 Release Check로 넣지 않는다.

아직 해당 Adapter와 Integration Test가 구현되지 않은 상태에서 CI Service만 먼저 추가하면 실제 검증 없이 복잡도만 증가하기 때문이다.

Redis Adapter와 PostgreSQL + pgvector Adapter가 구현되면 release-check 단계에 Integration Test를 추가한다.

추가 예정 범위:

Redis Adapter 구현
→ Redis Integration Test 추가

PostgreSQL + pgvector Adapter 구현
→ pgvector Integration Test 추가

FastAPI Endpoint Test 정리
→ Endpoint Contract Test 추가

향후 AI Release Check는 다음 형태로 확장할 수 있다.

Unit Test / Lint
↓
Redis Integration Test
↓
PostgreSQL + pgvector Integration Test
↓
FastAPI Endpoint Test
↓
Docker Build Check

즉 현재 CI를 단순하게 유지하고, 실제 Adapter와 Test가 구현되는 시점에 검증 범위를 넓힌다.

일반 CI에서는 외부 LLM / Embedding API를 매번 실제 호출하지 않는다.

이유:

• API Key 필요
• 호출 비용
• Rate Limit
• 외부 API 장애 영향
• 응답의 비결정성

따라서 Unit Test에서는 Mock / Fixture를 사용한다.

실제 API 연결 확인이 필요하면 일반 PR CI와 분리된 수동 Test Workflow로 구성한다.

main에 Merge된 최종 상태가 검증되면 AI Docker Image를 생성하여 Amazon ECR에 저장한다.

main Push
↓
fast-check
↓
release-check
↓
Docker Image Build
↓
Git Commit SHA Tag
↓
ECR needu-ai Push
↓
CD 대기

ECR Repository:

needu-ai

Image 예시:

needu-ai:7e42c91

CI는 ECR Push까지 담당한다.

실제 Production 배포는 CD에서 수행한다.

CI
→ ECR Push
→ CD 대기

CD
→ ECR Image Pull
→ EC2 Docker Compose AI Server 재기동
→ /health 확인
→ 실패 시 Rollback

name: AI CI

on:
  pull_request:
    branches: [dev, main]

  push:
    branches: [main]

permissions:
  contents: read

env:
  AWS_REGION: ap-northeast-2
  ECR_REPOSITORY: needu-ai

jobs:
  fast-check:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12.11"

      - uses: astral-sh/setup-uv@v6
        with:
          version: "0.8.4"
          enable-cache: true

      - name: Install dependencies
        run: uv sync --frozen --dev

      - name: Unit Test
        run: uv run pytest tests/unit

      - name: Lint
        run: uv run ruff check .

  release-check:
    needs: fast-check

    if: >
      github.event_name == 'push' ||
      github.event.pull_request.base.ref == 'main'

    runs-on: ubuntu-latest
    timeout-minutes: 15

    steps:
      - uses: actions/checkout@v4

      - name: Docker Build Check
        run: docker build -t needu-ai:ci-check .

  ecr-push:
    needs: release-check

    if: github.event_name == 'push' && github.ref == 'refs/heads/main'

    runs-on: ubuntu-latest
    timeout-minutes: 20

    permissions:
      contents: read
      id-token: write

    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ vars.AI_CI_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and Push
        env:
          REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build \
            -t "$REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" .

          docker push \
            "$REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG"

현재 Workflow는 실제 AI Repository 구조에 맞춘 최소 CI다.

Redis / PostgreSQL + pgvector Integration Test는 관련 Adapter와 Test 구현이 완료되면 release-check에 추가한다.

Frontend, Backend, AI Server는 서로 다른 배포 Artifact를 사용한다.

Backend와 AI Server Image는 서로 다른 Repository에 저장한다.

Amazon ECR
├─ needu-backend
└─ needu-ai

Repository를 분리하면 두 Application의 배포 버전과 Lifecycle을 독립적으로 관리할 수 있다.

모든 PR에서 Image를 ECR에 저장하지 않는다.

PR에서는 다음까지만 확인한다.

PR
↓
Test
↓
Docker Build Check
↓
ECR Push X

실제 배포 후보인 main에서만 ECR에 Push한다.

main
↓
최종 검증
↓
Docker Image Build
↓
Git Commit SHA
↓
ECR Push

latest는 사용하지 않는다.

Git Commit SHA를 Tag로 사용한다.

예:

needu-backend:a82f3c1
needu-ai:7e42c91

이를 통해 Git Commit과 운영 Image를 직접 연결할 수 있다.

Git Commit
↓
Docker Image
↓
Production Deployment

운영 EC2에서 Source Code를 다시 받아 Build하지 않는다.

CI에서 검증한 Image를 그대로 ECR에 저장하고, CD에서 동일한 Image를 배포한다.

CI
↓
Image Build
↓
ECR
↓
CD
↓
EC2 Docker Compose

이를 통해 CI에서 검증한 Artifact와 실제 운영 Artifact가 달라지는 문제를 줄인다.

Frontend는 Docker Image가 아니라 dist/를 배포한다.

GitHub Actions
↓
Vite Build
↓
dist/
↓
Artifact
↓
CD
↓
Host Nginx

V1 초기에는 Backend와 AI 모두 main Image만 저장한다.

초기 배포 빈도가 높지 않다면 자동 삭제 정책 없이 이전 Image를 유지하여 Rollback에 활용한다.

Image가 많이 누적되거나 저장 비용 관리가 필요해지는 시점에 ECR Lifecycle Policy를 적용한다.

Backend와 AI CI는 ECR에 Image를 Push하기 위해 AWS 권한이 필요하다.

장기 AWS Access Key를 GitHub Repository에 저장하지 않고 GitHub Actions OIDC를 사용한다.

GitHub Actions
↓
OIDC
↓
AWS IAM Role
↓
Amazon ECR

CI Role은 필요한 ECR Repository에만 접근할 수 있도록 제한한다.

예:

Backend CI Role
→ needu-backend Push

AI CI Role
→ needu-ai Push

CI가 AWS 전체 Resource를 수정할 수 있도록 하지 않는다.

GitHub 공식 문서:

• GitHub Docs - OIDC in AWS

main Push 이후 실패하면 이미 Merge가 완료된 상태이므로 Merge를 되돌리는 것이 아니라 배포 Artifact 생성을 중단한다.

실패한 Commit은 Production CD 대상으로 사용하지 않는다.

기존 운영 버전은 그대로 유지한다.

CI 실패는 다음에서 확인한다.

• GitHub Actions Workflow
• PR Status Check
• 실패 Step Log

개발자는 실패 원인을 수정한 뒤 다시 Push하여 CI를 재실행한다.

feature → dev PR
Type Check
→ Lint / Format
→ Build
→ Merge

dev → main PR
Type Check
→ Lint / Format
→ Build
→ Merge

main Push
Production Build
→ Playwright E2E
→ dist Artifact
→ CD

feature → dev PR
Unit Test
→ Build
→ Static Check
→ Merge

dev → main PR
Unit Test
→ Build
→ Integration Test
   ├─ MySQL
   ├─ Redis
   └─ AI API Contract
→ Docker Build Check
→ Merge

main Push
최종 검증
→ Docker Build
→ SHA Tag
→ ECR needu-backend
→ CD

feature → dev PR
Python 3.12.11
→ uv sync --frozen --dev
→ Unit Test
→ Ruff Lint
→ Merge

dev → main PR
위 기본 검사
→ Docker Build Check
→ Merge

main Push
fast-check
→ release-check
→ Docker Build
→ SHA Tag
→ ECR needu-ai
→ CD 대기

향후
Redis / pgvector Adapter 구현 후
→ Integration Test 추가

현재 AI CI에서 필수로 수행하는 검증은 다음과 같다.

feature → dev
→ uv sync --frozen --dev
→ Unit Test
→ Ruff Lint

dev → main
→ 위 검사
→ Docker Build Check

main
→ 최종 검증
→ Docker Image Build
→ ECR Push
→ CD 대기

Redis / PostgreSQL + pgvector Integration Test는 Adapter와 Test 구현 이후 추가한다.

모든 Repository는 동일한 Branch 정책을 사용한다.

feature/*
↓
dev
↓
main

• feature/*: 기능 개발
• dev: 개발 변경사항 통합 및 검증
• main: Production Release 후보

Frontend
→ Type / Lint / Build
→ E2E
→ dist Artifact

Backend
→ Unit / Integration Test
→ Docker Build
→ ECR needu-backend

AI Server
→ Unit / AI Logic / Integration Test
→ Docker Build
→ ECR needu-ai

Frontend
→ CI
→ dist/
→ GitHub Actions Artifact
→ CD

Backend
→ CI
→ Docker Image
→ ECR needu-backend
→ CD

AI Server
→ CI
→ Docker Image
→ ECR needu-ai
→ CD

• PR CI 실패 시 Merge하지 않는다.
• dev와 main의 역할을 세 Repository에서 동일하게 유지한다.
• Backend는 AI Server 내부 구현이 아니라 AI API Contract를 검증한다.
• PostgreSQL + pgvector Integration Test는 관련 Adapter와 Test 구현 후 AI release-check에 추가한다.
• 외부 LLM / Embedding API는 일반 CI에서 Mock 중심으로 검증한다.
• Backend와 AI Server는 main 성공 후에만 ECR에 Image를 저장한다.
• Git Commit SHA로 Production Artifact를 추적한다.
• CI 실패 시 Production CD를 진행하지 않고 기존 운영 버전을 유지한다.