운영 배포 전 테스트 가능한 스테이징 환경 구축

[sounmind]

배경

현재 개발 프로세스에서 새로운 기능이나 변경사항을 운영 배포 전에 검증할 방법이 없습니다.

현재 흐름:

코드 변경 → main 병합 → Cloudflare Workers 운영 배포 → leetcode-study에서 실제 동작 확인

운영 환경에 배포된 후에야 webhook 동작을 확인할 수 있어서, 문제가 발생하면 실제 스터디 참여자에게 영향을 미칩니다. 최근 3개의 PR이 연속 리버트된 이력(#17, #18, #19)이 이를 잘 보여줍니다.

원하는 흐름:

코드 변경 → 스테이징 배포 → 테스트 PR로 검증 → 확인 완료 → main 병합 → 운영 배포

제약 조건

• 별도 테스트 레포를 만들지 않는다 — 관리 포인트가 늘어나는 것을 최소화
• 기존 leetcode-study 레포 안에서 테스트 가능해야 한다
• 프로덕션 워커 코드에 대한 변경은 최소화한다

선택한 접근 방식

라벨 기반 스테이징 라우팅

leetcode-study 레포에서 테스트용 PR을 생성할 때 staging 라벨을 붙이면, 프로덕션 워커가 해당 이벤트를 스테이징 워커로 포워딩한다.

leetcode-study PR (모든 webhook 이벤트)
        │
        ▼
  Production Worker (github.dalestudy.com)
        │
        ├─ staging 라벨 감지?
        │      YES ──► Forward ──► Staging Worker (별도 인스턴스)
        │      NO  ──► 정상 처리

왜 Production을 거쳐야 하는가?

GitHub App의 webhook URL은 앱 설정에서 하나만 지정 가능하다. PR 단위로 다른 URL을 보내는 기능이 없다. 따라서 모든 webhook 이벤트는 Production Worker(github.dalestudy.com)로 먼저 도착한다.

Production Worker와 Staging Worker는 서로 다른 URL을 가진 완전히 독립된 서버 인스턴스이다 (코드, Secrets, 메모리 모두 별개). Staging Worker는 GitHub이 존재를 모르기 때문에 직접 webhook을 받을 수 없다.

그래서 Production Worker가 staging 라벨을 감지하면 fetch("https://github-staging.xxx/webhooks", ...)로 Staging Worker에 HTTP 요청을 보내는 방식으로 중계한다. 코드 내부 분기가 아니라, 서버 A → 서버 B로의 네트워크 통신이다.

이 방식을 선택한 이유

• 별도 레포 불필요: leetcode-study 안에서 라벨 하나로 구분
• 프로덕션 변경 최소화: 라우팅 로직은 단순 forward 분기 하나
• 완전 분리된 워커: Cloudflare Workers environments로 Production/Staging이 독립 인스턴스로 배포됨
• 리얼한 테스트: 실제 GitHub webhook 이벤트를 그대로 받아서 처리

구현 스펙

1. Cloudflare Workers 환경 분리

wrangler.jsonc에 staging 환경 추가:

{
  "name": "github",
  "main": "index.js",
  // ...
  "env": {
    "staging": {
      "name": "github-staging"
    }
  }
}

wrangler deploy              # → Production Worker
wrangler deploy --env staging # → Staging Worker (별도 인스턴스)

2. 스테이징 배포: GitHub Actions (workflow_dispatch)

스테이징 배포는 자동이 아닌 수동 트리거로 원하는 브랜치를 선택해서 배포한다.

name: Deploy Staging 🚀

on:
  workflow_dispatch:
    inputs:
      branch:
        description: "배포할 브랜치"
        required: true
        type: string

jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ inputs.branch }}
      - run: npx wrangler deploy --env staging
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

수동 트리거를 선택한 이유:

• 스테이징은 항상 돌릴 필요 없이 테스트할 때만 배포하면 됨
• 어떤 브랜치를 배포할지 명시적으로 제어 가능
• 이미 management.yaml에서 workflow_dispatch 패턴을 쓰고 있어서 팀에 익숙

3. Production Worker에 라우팅 로직 추가

/webhooks 핸들러 최상단에 staging 라벨 감지 및 포워딩:

const labels = payload.pull_request?.labels?.map(l => l.name) || [];
if (labels.includes("staging")) {
  return fetch(env.STAGING_WORKER_URL + "/webhooks", request);
}

• STAGING_WORKER_URL은 환경변수로 관리
• 포워딩 실패 시에도 프로덕션 처리에 영향 없음

4. Secrets 설정

Staging Worker Secrets (3개)

Cloudflare Workers secrets는 write-only로, 기존 Production 값을 조회/복제할 수 없다. Org owner 또는 Worker owner에게 아래 3개 값을 확인해야 한다:

Secret	확인 방법	비고
APP_ID	GitHub App 설정 페이지에서 확인 (숫자)	비밀 정보 아님
PRIVATE_KEY	원본 PEM 파일 필요. 없으면 GitHub App 설정에서 새 키 발급 가능	새 키 발급 시 기존 키와 별개로 추가됨
OPENAI_API_KEY	OpenAI 대시보드에서 확인 또는 새 키 발급

npx wrangler secret put APP_ID --env staging
npx wrangler secret put PRIVATE_KEY --env staging
npx wrangler secret put OPENAI_API_KEY --env staging

WEBHOOK_SECRET은 불필요

Production Worker가 GitHub 서명을 검증한 후에 Staging으로 포워딩하므로, Staging에서 다시 검증할 필요가 없다. 코드에서 env.WEBHOOK_SECRET 미설정 시 검증을 자동 스킵한다:

GitHub  ─── X-Hub-Signature-256 ───►  Production Worker  ─── forward ───►  Staging Worker
                                          ✅ 검증 완료                       검증 스킵
                                     (env.WEBHOOK_SECRET)             (WEBHOOK_SECRET 미설정)

Production Worker 환경변수 (1개)

Staging Worker 배포 후 URL을 확인하여 Production에 설정:

npx wrangler secret put STAGING_WORKER_URL
# 입력: https://github-staging.daleseo.workers.dev

GitHub Actions Secret (1개)

GitHub repo Settings > Secrets > Actions에서 설정:

• CLOUDFLARE_API_TOKEN: Cloudflare API Token (Workers 배포 권한)

5. 테스트 워크플로우

1. 이 레포에서 기능 브랜치 작성
2. GitHub Actions에서 해당 브랜치를 선택하여 스테이징 배포 실행
3. leetcode-study에서 테스트 PR 생성, staging 라벨 부착
4. Staging Worker가 처리 → 테스트 PR에서 동작 확인
5. 확인 완료 → 기능 브랜치를 main에 병합 → 운영 자동 배포
6. 테스트 PR은 close

6. 고려사항

• projects_v2_item 이벤트는 payload에 PR 라벨 정보가 직접 포함되지 않으므로 항상 Production에서 처리됨
• issue_comment, pull_request_review_comment 이벤트는 payload.issue.labels 또는 payload.pull_request.labels로 라벨 확인 가능
• Staging Worker의 댓글/리뷰가 테스트 PR에 실제로 달리므로, 스터디 참여자에게 혼동이 없도록 staging 라벨의 용도를 팀에 공유

기대 효과

• 운영 환경 장애 예방 (revert 횟수 감소)
• PR 리뷰 시 실제 webhook 동작을 스테이징에서 확인 가능
• 개발 속도 향상 (빠른 피드백 루프)

[sounmind]

Staging Environment Implementation Plan

For agentic workers: REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (- [ ]) syntax for tracking.

Goal: leetcode-study의 staging 라벨이 붙은 PR의 webhook 이벤트를 스테이징 워커로 포워딩하고, GitHub Actions로 원하는 브랜치를 스테이징에 배포할 수 있게 한다.

Architecture: Production Worker가 webhook 수신 시 payload의 PR 라벨을 검사하여 staging 라벨이 있으면 Staging Worker URL로 요청을 그대로 포워딩한다. Staging Worker는 Cloudflare Workers environments(wrangler deploy --env staging)로 동일 코드베이스의 별도 인스턴스로 배포된다. 배포는 GitHub Actions workflow_dispatch로 브랜치를 선택해서 수동 실행한다.

Tech Stack: Cloudflare Workers, wrangler, GitHub Actions

Spec: #21

---

File Structure

Action	Path	Responsibility
Modify	wrangler.jsonc	staging 환경 추가
Create	utils/staging.js	staging 라벨 감지 및 포워딩 로직
Modify	utils/constants.js	STAGING_LABEL 상수 추가
Modify	index.js	/webhooks 핸들러에 staging 라우팅 삽입
Create	.github/workflows/deploy-staging.yaml	스테이징 수동 배포 워크플로우
Modify	AGENTS.md	스테이징 환경 문서화

---

Task 1: Cloudflare Workers staging 환경 설정

Files:

• Modify: wrangler.jsonc

• Step 1: wrangler.jsonc에 staging 환경 추가

{
  "name": "github",
  "main": "index.js",
  "compatibility_date": "2024-01-01",
  "account_id": "94480614a6df7731f1e4491bdac5c440",
  "observability": {
    "logs": {
      "enabled": true,
      "head_sampling_rate": 1,
      "invocation_logs": true,
      "persist": true,
    },
  },
  "env": {
    "staging": {
      "name": "github-staging",
    },
  },
}

• Step 2: staging 배포 확인

Run: npx wrangler deploy --env staging --dry-run

Expected: 에러 없이 github-staging Worker에 대한 dry-run 출력. Secrets가 없으므로 실제 배포는 하지 않는다.

• Step 3: Commit

git add wrangler.jsonc
git commit -m "chore: add staging environment to wrangler config"

---

Task 2: staging 라벨 감지 유틸리티

Files:

• Modify: utils/constants.js

• Create: utils/staging.js

• Step 1: utils/constants.js에 STAGING_LABEL 상수 추가

utils/constants.js 파일 끝에 추가:

// 스테이징
export const STAGING_LABEL = "staging";

• Step 2: utils/staging.js 생성 — staging 라벨 감지 함수

/**
 * 스테이징 라우팅 유틸리티
 */

import { STAGING_LABEL } from "./constants.js";

/**
 * Webhook payload에서 staging 라벨 여부를 확인한다.
 *
 * 지원하는 이벤트:
 * - pull_request: payload.pull_request.labels
 * - issue_comment: payload.issue.labels
 * - pull_request_review_comment: payload.pull_request.labels
 *
 * projects_v2_item 이벤트는 payload에 라벨 정보가 없으므로 false를 반환한다.
 *
 * @param {Object} payload - GitHub webhook payload
 * @returns {boolean}
 */
export function hasStagingLabel(payload) {
  const labels = payload.pull_request?.labels || payload.issue?.labels || [];
  return labels.some((l) => l.name === STAGING_LABEL);
}

/**
 * Webhook 요청을 staging Worker로 포워딩한다.
 *
 * 원본 요청의 헤더(X-GitHub-Event, X-Hub-Signature-256 등)와
 * body를 그대로 전달하여 staging Worker가 동일하게 검증/처리할 수 있게 한다.
 *
 * @param {string} stagingUrl - Staging Worker의 base URL
 * @param {Headers} headers - 원본 요청 헤더
 * @param {string} rawBody - 원본 요청 body (raw string)
 * @returns {Promise<Response>}
 */
export async function forwardToStaging(stagingUrl, headers, rawBody) {
  return fetch(stagingUrl + "/webhooks", {
    method: "POST",
    headers: headers,
    body: rawBody,
  });
}

• Step 3: Commit

git add utils/constants.js utils/staging.js
git commit -m "feat: add staging label detection and forwarding utility"

---

Task 3: Production Worker에 staging 라우팅 삽입

Files:

• Modify: index.js:28-54 (/webhooks 핸들러 블록)

• Step 1: index.js에 staging import 추가

파일 상단 import 블록에 추가:

import { hasStagingLabel, forwardToStaging } from "./utils/staging.js";

• Step 2: /webhooks 핸들러에 staging 라우팅 로직 삽입

index.js의 /webhooks 블록을 아래와 같이 수정한다. signature 검증 직후, handleWebhook 호출 직전에 staging 분기를 추가한다:

    // GitHub Webhook 수신
    if (url.pathname === "/webhooks") {
      // Webhook signature 검증
      const signature = request.headers.get("X-Hub-Signature-256");
      const rawBody = await request.text();

      // Secret이 설정되어 있으면 검증
      if (env.WEBHOOK_SECRET) {
        const isValid = await verifyWebhookSignature(
          rawBody,
          signature,
          env.WEBHOOK_SECRET
        );

        if (!isValid) {
          console.error("Invalid webhook signature");
          return errorResponse("Invalid signature", 401);
        }
      }

      // Staging 라우팅: staging 라벨이 있으면 staging Worker로 포워딩
      if (env.STAGING_WORKER_URL) {
        const payload = JSON.parse(rawBody);
        if (hasStagingLabel(payload)) {
          console.log("Forwarding to staging worker");
          return forwardToStaging(env.STAGING_WORKER_URL, request.headers, rawBody);
        }
      }

      // Request 객체 재생성 (body를 다시 읽을 수 있도록)
      const newRequest = new Request(request.url, {
        method: request.method,
        headers: request.headers,
        body: rawBody,
      });

      return handleWebhook(newRequest, env);
    }

핵심 포인트:

• env.STAGING_WORKER_URL이 설정되지 않으면 분기 자체를 타지 않음 (기본적으로 no-op)

• signature 검증은 포워딩 전에 이미 완료됨

• 원본 헤더(X-GitHub-Event, X-Hub-Signature-256)를 그대로 전달하여 staging Worker도 동일하게 검증 가능

• Step 3: 로컬에서 동작 확인

Run: npx wrangler dev

별도 터미널에서 staging 라벨이 없는 요청이 정상 처리되는지 확인:

curl -s -X POST http://localhost:8787/webhooks \
  -H "Content-Type: application/json" \
  -H "X-GitHub-Event: pull_request" \
  -d '{"action":"opened","organization":{"login":"DaleStudy"},"repository":{"name":"leetcode-study"},"pull_request":{"number":1,"labels":[],"head":{"sha":"abc"},"user":{"login":"test"}}}'

Expected: 200 응답. STAGING_WORKER_URL이 미설정이므로 staging 분기를 타지 않고 정상 처리 (또는 토큰 미설정으로 인한 에러 — 라우팅 자체는 스킵되었음을 로그로 확인).

• Step 4: Commit

git add index.js
git commit -m "feat: route staging-labeled webhook events to staging worker"

---

Task 4: GitHub Actions 스테이징 배포 워크플로우

Files:

• Create: .github/workflows/deploy-staging.yaml

• Step 1: 워크플로우 파일 생성

name: Deploy Staging 🚀

on:
  workflow_dispatch:
    inputs:
      branch:
        description: "배포할 브랜치"
        required: true
        type: string

jobs:
  deploy-staging:
    name: Deploy to Staging Worker
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ inputs.branch }}

      - name: Deploy to Cloudflare Workers (staging)
        run: npx wrangler deploy --env staging
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}

      - name: Summary
        run: |
          echo "## 🚀 Staging 배포 완료" >> $GITHUB_STEP_SUMMARY
          echo "" >> $GITHUB_STEP_SUMMARY
          echo "- **브랜치:** \`${{ inputs.branch }}\`" >> $GITHUB_STEP_SUMMARY
          echo "- **Worker:** github-staging" >> $GITHUB_STEP_SUMMARY

• Step 2: Commit

git add .github/workflows/deploy-staging.yaml
git commit -m "ci: add staging deployment workflow with branch selection"

---

Task 5: Secrets 설정 및 검증

이 Task는 코드가 아닌 인프라 설정이므로, 수동으로 진행한다.

• Step 1: Staging Worker Secrets 설정

npx wrangler secret put APP_ID --env staging
npx wrangler secret put PRIVATE_KEY --env staging
npx wrangler secret put OPENAI_API_KEY --env staging
npx wrangler secret put WEBHOOK_SECRET --env staging

값은 Production과 동일하게 입력한다 (같은 GitHub App 사용).

• Step 2: Production Worker에 STAGING_WORKER_URL 환경변수 설정

Staging Worker 배포 후 생성되는 URL을 확인:

npx wrangler deploy --env staging

출력에서 URL을 확인 (예: https://github-staging.daleseo.workers.dev).

Production Worker에 해당 URL을 환경변수로 설정:

npx wrangler secret put STAGING_WORKER_URL
# 입력: https://github-staging.daleseo.workers.dev

• Step 3: GitHub Actions Secret 설정

GitHub repo Settings > Secrets and variables > Actions에서:

• CLOUDFLARE_API_TOKEN: Cloudflare API Token (Workers 배포 권한 필요)

---

Task 6: End-to-end 검증

• Step 1: Staging Worker 배포

GitHub Actions에서 Deploy Staging 워크플로우를 main 브랜치로 실행.

• Step 2: leetcode-study에서 테스트 PR 생성

1. leetcode-study 레포에서 테스트용 PR 생성 (내용은 아무거나)
2. staging 라벨 부착
3. Production Worker 로그 확인 (wrangler tail): Forwarding to staging worker 메시지 확인
4. Staging Worker 로그 확인 (wrangler tail --env staging): 이벤트 수신 및 처리 확인

• Step 3: staging 라벨 없는 PR이 영향받지 않는지 확인

leetcode-study에서 staging 라벨이 없는 일반 PR이 기존과 동일하게 Production Worker에서 처리되는지 확인.

• Step 4: 테스트 PR close

검증 완료 후 테스트 PR을 close한다.

---

Task 7: 문서 업데이트

Files:

• Modify: AGENTS.md

• Step 1: AGENTS.md에 스테이징 환경 섹션 추가

## 배포 섹션 아래에 추가:

### 스테이징 환경

운영 배포 전 webhook 동작을 검증하기 위한 스테이징 환경.

#### 배포 방법

GitHub Actions > `Deploy Staging 🚀` > 배포할 브랜치 입력 > Run workflow

또는 로컬에서:
```bash
npx wrangler deploy --env staging

테스트 방법

1. 기능 브랜치를 스테이징에 배포
2. leetcode-study에서 테스트 PR 생성, staging 라벨 부착
3. 스테이징 Worker 로그 확인: npx wrangler tail --env staging
4. 검증 완료 후 테스트 PR close, 기능 브랜치를 main에 병합

동작 원리

Production Worker가 webhook 수신 시 PR의 staging 라벨을 감지하면 Staging Worker로 요청을 포워딩한다. projects_v2_item 이벤트는 payload에 라벨 정보가 없으므로 항상 Production에서 처리된다.

- [ ] **Step 2: Commit**

```bash
git add AGENTS.md
git commit -m "docs: add staging environment guide to AGENTS.md"

[sounmind]

인프라 및 작동 구조

1. 전체 인프라 구성

graph TB
    subgraph GitHub["GitHub"]
        GA["GitHub App (dalestudy)"]
        LS["leetcode-study 레포"]
        GR["github 레포 (이 프로젝트)"]
    end

    subgraph CF["Cloudflare Workers (독립 인스턴스)"]
        PW["Production Worker<br/>github.dalestudy.com<br/><i>name: github</i>"]
        SW["Staging Worker<br/>github-staging.daleseo.workers.dev<br/><i>name: github-staging</i>"]
    end

    GA -->|"Webhook URL (하나만 설정 가능)"| PW
    GR -->|"main 병합 → 자동 배포 (Git 연동)"| PW
    GR -->|"Actions: workflow_dispatch → 브랜치 선택 배포"| SW

    style GA fill:#f9f,stroke:#333
    style PW fill:#4CAF50,stroke:#333,color:#fff
    style SW fill:#FF9800,stroke:#333,color:#fff

Loading

핵심: GitHub App webhook URL은 앱 레벨에서 하나만 설정 가능하다. PR 단위로 다른 URL을 지정할 수 없다. 그래서 모든 webhook은 Production Worker로 먼저 도착한다.

2. Webhook 요청 흐름

sequenceDiagram
    participant GH as GitHub
    participant PW as Production Worker<br/>(github.dalestudy.com)
    participant SW as Staging Worker<br/>(github-staging.xxx)

    Note over GH: leetcode-study에서<br/>PR 이벤트 발생

    GH->>PW: POST /webhooks<br/>(X-Hub-Signature-256 포함)
    PW->>PW: 1. Webhook 서명 검증 (WEBHOOK_SECRET)
    PW->>PW: 2. payload JSON 파싱
    PW->>PW: 3. PR 라벨에 "staging" 있는지 확인

    alt staging 라벨 없음 (일반 PR)
        PW->>PW: 정상 처리<br/>(Week 체크, 패턴 태깅 등)
        PW-->>GH: 200 OK
    else staging 라벨 있음 (테스트 PR)
        PW->>SW: fetch() — HTTP 요청으로 포워딩<br/>(원본 헤더 + body 그대로)
        Note over SW: WEBHOOK_SECRET 미설정<br/>→ 서명 검증 스킵<br/>(Production이 이미 검증 완료)
        SW->>SW: 정상 처리<br/>(스테이징 코드로 동작)
        SW-->>PW: 200 OK
        PW-->>GH: 200 OK (staging 응답 전달)
    end

Loading

3. 배포 흐름

graph LR
    subgraph "Production 배포 (자동)"
        M["main 브랜치에<br/>PR 병합"] -->|"Cloudflare Git 연동<br/>(자동)"| PD["Production Worker<br/>배포"]
    end

    subgraph "Staging 배포 (수동)"
        D["GitHub Actions 실행<br/>(workflow_dispatch)"] -->|"브랜치 선택"| CO["해당 브랜치<br/>checkout"]
        CO -->|"wrangler deploy<br/>--env staging"| SD["Staging Worker<br/>배포"]
    end

    style PD fill:#4CAF50,stroke:#333,color:#fff
    style SD fill:#FF9800,stroke:#333,color:#fff

Loading

요약

• 두 Worker는 완전히 독립된 인스턴스 (별도 코드, 별도 Secrets, 별도 URL)
• GitHub App webhook URL이 하나이므로, Production Worker가 모든 webhook을 먼저 수신
• Production Worker는 staging 라벨을 감지하면 fetch()로 Staging Worker에 HTTP 요청을 중계
• 라벨 없는 일반 PR은 Production Worker가 직접 처리 (기존과 동일)

[DaleSeo]

@sounmind 스테이징 환경 구축 제안 내용 잘 읽어 보았습니다. 최근 원복된 PR에 대한 문제 의식에 충분히 공감하며 검증 단계가 필요하다는 점은 동의합니다.

다만 단기 프로젝트로 예상하고 있는데 스테이징 환경을 장기적으로 유지보수하는 데 몇 가지 우려사항이 있습니다. 우선 Secrect 동기화가 우려됩니다. Production과 Staging의 APP_ID, PRIVATE_KEY, OPENAI_API_KEY를 별도로 관리해야 하고, 키 갱신 시 양쪽 모두 업데이트 필요할테니까요. 그리고 이 프로젝트가 종료 후에 전담으로 유지보수할 팀이 없는 상황에서, 관리해야하는 인프라가 하나 더 늘어나는 부담이 두렵습니다.

최근 3개의 PR이 연속 리버트된 이력을 확인해보았는데 공통적으로 외부 API 응답을 처리하는 로직 버그이며, 실제 웹훅 수신 없이도 자동화 테스트로 충분히 잡아낼 수 있었던 문제가 아니얼까 생각이 듭니다. #13 의 경우 fixture 기반 테스트로 예방할 수 있어소, #14의 경우 입출력 검증 테스트를 작성할 수 있었고, #15의 경우 호출 회수 카운팅을 검증하는 테스트를 작성할 수 있지 않았을까요?

그래서 저는 대안으로 있는 테스트를 먼저 추가하고 (이슈 #2), CI에서 자동 테스트를 하시는 것을 추천드리고 싶습니다.

제안해주신 흐름이 아래와 같은데요.

코드 변경 → 스테이징 배포 → 테스트 PR로 검증 → 확인 완료 → main 병합 → 운영 배포

이 개발 워크플로우는 지나치게 수동 테스트에 의존하는 것 같습니다. 스테이징 배포, 테스트 PR 생성, 라벨 부착, 로그 확인, PR 병합 과정이 모두 사람이 직접 해야되서 개발자 경험도 좋지 않을 것 같습니다.

그래서 다음과 같은 워크플로우로 제안드리고 싶습니다.

코드 변경 → PR 생성 → CI에서 자동 테스트 → 통과 → main 병합 → 운영 배포

좀 더 구체적으로 설명드리면,

• 실제 웹훅 Payload를 fixture로 저장하여 테스트 데이터로 활용합니다. (웹훅 Payload가 변경될 가능성은 아주 희박합니다)
• 핸들러 수준 단위 테스트 작성. (외부 API 호출은 mock하고, 로직 검증에 집중)
• GitHub Actions 워크플로우 추가. (PR마다 자동 실행, 통과해야 머지 가능하도록 required check)

이렇게 탄탄한 테스트 자동화를 구축해놓으면 #17, #18, #19와 같은 원복은 최소화할 수 있지 않을까요?

물론 예외적으로 E2E 검증이 꼭 필요한 경우도 있을 것입니다. 그럴 때는 상시 스테이징 환경 대신 ngrok를 활용하여 일회성으로 대응할 수 있다고 생각합니다.

wrangler dev --remote   # Cloudflare 런타임으로 로컬 실행
ngrok http 8787              # 임시 공개 URL 생성

정리하면 스테이징 환경 자체를 반대하는 건 아니지만, 현재 상황에서는 자동화 테스트를 먼저 갖추는 것이 더 현실적이고 장기적으로 유지보수가 용이한 전략이라고 생각합니다. 테스트 자동화된 후에도 동일한 이슈가 재발된다면 그때 스테이징 환경을 추가해도 늦지 않을 것 같아 보입니다.

[soobing]

@DaleSeo 달래님 안녕하세요~

먼저 “AI를 활용한 오픈소스 기여”라는 새로운 경험을 할 수 있게 해주셔서 감사합니다.

리뷰 주신 내용에서 #13(revert PR #18), #14(revert PR #19)의 경우 기능 구현에 문제가 있어서 revert한 것이 아니라 CloudFlare의 “Too many subrequests by single Worker invocation 에러”로 인해서 revert한 상황입니다.
(근데 상황과 별개로, 테스트 코드는 추가를 해보도록 하겠습니다 😊)

위의 에러의 원인을 파악하고자 추가했던 기능들을 모두 원복시켰고 그럼에도 불구하고 에러가 해결되지 않아 본질적인 해결이 아님을 알게 되었습니다.

그래서 AI 핸들러별로 Worker 호출을 따로 하도록 코드를 수정해서 PR(#16)을 올렸지만 테스트 환경이 없다보니 또 운영환경에서 테스트를 해야하는 점과 현재 리트코드 스터디 프로젝트 댓글에 완전히 구현되지 않은 기능들이 포함되어 다른 스터디원들에게 혼란을 줄 수 있는 점 등을 고려하여 테스트 환경 구축을 고려하게 되었습니다.

이에 작성해주신 리뷰를 보며 Cloudflare의 subrequest limit은 런타임이 강제하는 제약이라, mock 환경에서는 100% 재현할 수 없기는 하지만, subrequest 횟수를 세는 테스트를 추가하여 배포 전에 확인할 수 있게 추가해 보면 좋겠다는 생각이 들었습니다.

그러나 테스트 코드가 있더라도 실제 배포 환경에서 동작을 확인하는 것은 별개의 문제라고 생각합니다. 일반적인 웹 개발에서도 단위 테스트를 통과한 코드를 개발 서버에 배포해서 실제 동작을 검증하듯이, 이 프로젝트에서도 운영 배포 전에 확인할 수 있는 환경이 있으면 완성도 측면에서 도움이 될 것 같습니다.

말씀 주신대로 로컬에서 ngrok으로 테스트는 가능하지만, ngrok의 경우 GitHub App 권한이 필요하여 모든 기여자가 독립적으로 테스트하기 어려울 것 같은데요.

그래서 질문드리고 싶은 것은,

leetcode-study 레포에 staging라벨이 달린 경우에만 스테이징 환경으로 테스트가 돌아가게 할 예정이라, APP_ID, PRIVATE_KEY, OPENAI_API_KEY를 운영 환경과 동일하게 사용할 예정인데도 관리포인트가 클까요?

관리 포인트가 크다면 권한을 가지고 계신 운영자분(@sounmind, @SamTheKorean)들과 협의해서 테스트를 할 수 있는 방법을 조율해 보도록 하겠습니다!

+ 건설적인 리뷰 감사합니다. ㅎㅎ 테스트 코드 작성을 더욱 열심히 해보도록 하겠습니다~

(cc. @sounmind)

[DaleSeo]

@soobing 죄송합니다. Cloudflare Workers 무료 플랜에 subrequest 50회 한도가 있다는 걸 제가 까먹고 있었습니다. 이 부분 짚어주셔서 감사합니다. 원복 원인을 로직 버그로 단순하게 봤는데, 실제로는 런타임 제약이었다는 점 이해했습니다.

질문 주신 부분에 대해서 먼저 답변 드리면, 이 프로젝트 하나만 놓고 보면 관리 포인트 증가가 크지 않다고 생각하실 수 있습니다. 하지만 솔직히 말씀드리면, 제가 현재 커뮤니티에서 관리해야하는 프로젝트가 다 수가다 보니 이 프로젝트에만 특별히 스테이징 환경이 있다는 것 자체를 기억할 자신이 없습니다. 제 기억력의 한계를 제가 누구보다 잘 알아서요... 팀원들이 떠나고 현재 기본적인 의존성 업데이트도 제대로 못하고 있는 프로젝트가 다수거든요 ㅎㅎ 그래서 저는 커뮤니티 차원에서 더 장기적인 관점으로 이 문제를 볼 수 밖에 없는 부분 양해 부탁드립니다.

제가 좀 찾아보니 Cloudflare Workers 월 5불을 내고 유료 플랜으로 전환하면 subrequest 한도를 1,000회로 늘려주더라고요. 현재 최악의 경우가 파일 10개 기준 약 62회이므로, 1,000회 한도에서는 당분간 문제가 되지 않습니다. 원하시면 제가 Paid 플랜으로 전환해드릴 수 있습니다. (월 5불을 내고 프로젝트 별 특이 사항을 잊어 버릴 수 있다면 저한테는 아주 합리적인 Deal이라고 느껴집니다.)

그리고 제가 예전에 다른 프로젝트에서 했던 꼼수를 한가지 떠오르는데, fetch 래퍼 함수를 만들어서 subrequest 한도를 관리하는 것도 생각해볼 수 있을 것 같습니다.

const SUBREQUEST_LIMIT = 50;

export function createFetchWithBudget(limit = SUBREQUEST_LIMIT) {
  let count = 0;
  return async function budgetedFetch(...args) {
    count++;
    if (count > limit) {
      throw new Error(`Subrequest budget exceeded: ${count}/${limit}`);
    }
    console.log(`Subrequest ${count}/${limit}: ${args[0]}`);
    return fetch(...args);
  };
}

요렇게 fetch를 래퍼로 감싸서 호출 횟수를 추적하면, 프로덕션에서 한도 초과 전에 명확한 로그를 확인할 수도 있고, mock fetch에도 같은 래퍼를 적용하면 CI에서 한도를 초과를 사전에 감지할 수 있을 거라 생각합니다.

혹시 Walker에 문제가 발생하여 리트코드 스터드 분들이 불편을 겪을까봐 우려하시는 부분은 매우 감사하게 느끼고 있습니다. 그런데 프로젝트 성격 상 동시 접속자들이 있어서 24/7 무중단 가동되어야 하는 웹사이트도 아니고, 사실 규칙이 없이 발생하는 이벤트에만 반응하기만 하면 서버리스 함수들인데, 스테이징 환경까지 추가할 정도까지 아키텍쳐의 복잡도를 키워야하는 걸까? 잠깐 장애나도 스터디 멤버 분들이 너그럽게 이해해주시지 않을까? 이번 문제를 실제로 스터디 멤버 중에서 몇 분이 인지하셨을까? 하는 생각이 자꾸 드는 것 같습니다.

다시 한 번 말씀드리면 저는 스테이징 환경을 추가하는 것에 반대하지 않습니다. @sounmind 님께서 의견을 물어봐주셔서 드리는 것 뿐이며, 최종 결정은 AI 프로젝트 팀에서 해주시면 됩니다. 감사합니다!

[sounmind]

@DaleSeo 좋은 의견 감사합니다! 팀원들에게 좋은 참고가 될 것 같습니다. 정기 모임에도 이 논의 내용을 알리고 짧게나마 의견 받았었습니다. 팀원들과 논의해 결정하고 디스코드나 깃허브에 공유하도록 하겠습니다. 현재 이 건의 드라이버는 저와 @soobing 입니다.

[sounmind]

잠정 결론

• 단위테스트 + 병합 후 수동테스트
• 추후에 다른 이슈가 있는지 지켜보는걸로

[soobing]

일단 단위테스트 먼저 추가하는 방향으로 진행해보겠습니다. 이슈는 close 합니다 :)