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

[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 생성

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