서버 관리 없는 초경량 클라우드 엣지 함수(Cloudflare/Supabase) 기반 자동화 기법

월 0원 비용으로 전 세계 어디서나 10ms 내에 응답하는 웹훅 처리 및 데이터 파이프라인 구축

이지웍스랩 인프라팀 · 2026-08-17 · B2B 업무 자동화 · 읽는 데 8분

많은 실무자들이 자동화 스크립트를 돌리기 위해 비싼 클라우드 가상 서버를 24시간 켜둡니다. 하지만 최신 서버리스 엣지(Edge) 기술을 이용하면 월 수만 건의 자동화도 무료 티어 내에서 완벽하게 처리할 수 있습니다.

1. Cloudflare Workers와 Supabase의 시너지

웹훅 수신 및 데이터 변환은 Cloudflare Workers가 담당하고, 변환된 데이터의 영구 저장 및 인증은 Supabase PostgreSQL이 처리하는 조합은 2026년 스타트업과 엔터프라이즈의 표준 아키텍처입니다.

많은 실무자가 자동화 스크립트를 돌리기 위해 가상 서버를 24시간 켜둡니다. 하지만 실제 실행 시간은 하루에 몇 분에 불과하며, 나머지 시간의 비용은 전부 낭비입니다. 요청당 과금 모델은 이 구조적 낭비를 제거합니다.

더 큰 이점은 운영 부담의 소멸입니다. OS 보안 패치, 디스크 용량 관리, 프로세스 재시작 같은 작업이 아예 존재하지 않으므로, 인프라 담당자가 없는 조직에서도 안정적으로 운영할 수 있습니다.

항목	상시 가상 서버	서버리스 엣지
비용 구조	실행 여부와 무관한 시간당 과금	요청 수 기준 과금, 무료 구간 존재
운영 부담	OS 패치·모니터링·용량 관리 필요	런타임 관리 불필요
응답 지연	단일 리전 기준, 해외 접근 시 지연	전 세계 엣지 노드에서 근거리 처리
장애 격리	프로세스 하나가 서버 전체에 영향	요청 단위 격리로 전파 차단

2. 웹훅 수신 함수 구현과 재시도 안전성

웹훅 처리에서 가장 중요한 원칙은 '빨리 받고 나중에 처리'입니다. 수신 즉시 200을 반환하지 않으면 발신 측이 타임아웃으로 판단해 같은 이벤트를 반복 전송하고, 그 결과 데이터가 중복 적재됩니다.

따라서 Workers에서는 요청 검증과 큐 적재까지만 수행하고 무거운 처리는 비동기로 넘기는 구조가 정석입니다. 서명 검증은 반드시 수행하십시오. 검증 없는 웹훅 엔드포인트는 누구나 가짜 데이터를 밀어 넣을 수 있는 열린 문입니다.

중복 수신 자체는 막을 수 없으므로 멱등 처리로 대응해야 합니다. 이벤트 ID를 유니크 키로 저장하고, 이미 존재하면 조용히 무시하는 방식이 가장 단순하고 확실합니다.

export default {
  async fetch(req: Request, env: Env, ctx: ExecutionContext) {
    if (req.method !== 'POST') return new Response('Method Not Allowed', { status: 405 })

    const raw = await req.text()
    const signature = req.headers.get('x-signature') ?? ''

    // 1) 서명 검증 실패 시 즉시 차단 (검증 없는 웹훅은 열린 문)
    if (!(await verifySignature(raw, signature, env.WEBHOOK_SECRET))) {
      return new Response('Invalid signature', { status: 401 })
    }

    const event = JSON.parse(raw)

    // 2) 무거운 처리는 응답 이후로 미룬다 (발신 측 타임아웃 방지)
    ctx.waitUntil(handleEvent(event, env))

    return new Response('ok', { status: 200 })
  },
}

async function handleEvent(event: any, env: Env) {
  // 3) 이벤트 ID 유니크 제약으로 중복 수신 멱등 처리
  const { error } = await supabase(env)
    .from('webhook_events')
    .insert({ event_id: event.id, payload: event })

  if (error?.code === '23505') return // 이미 처리된 이벤트
  if (error) throw error

  await processSettlement(event, env)
}

3. Cron 트리거 기반 정기 배치 구성

매일 새벽 정산 데이터를 동기화하는 배치도 상시 서버 없이 구성할 수 있습니다. Workers의 Cron Trigger나 Supabase의 pg_cron을 쓰면 정해진 시각에만 깨어나 작업하고 즉시 종료됩니다.

다만 서버리스 환경에는 실행 시간 제한이 있으므로, 대량 데이터를 한 번에 처리하려 하면 중간에 잘립니다. 처리 대상을 커서 기반으로 나누고 여러 번에 걸쳐 진행하는 청크 처리 설계가 필수입니다.

배치 실패 감지도 함께 설계하십시오. 서버가 없다는 것은 '죽었는지 확인할 프로세스도 없다'는 뜻이므로, 실행 완료 시각을 기록하고 예상 시각까지 기록이 없으면 경보가 울리도록 해야 합니다.

4. 비용과 한계: 서버리스가 적합하지 않은 경우

서버리스가 만능은 아닙니다. 장시간 연속 연산이 필요한 작업, 대용량 파일을 메모리에 올려 처리하는 작업, 특정 라이브러리가 네이티브 바이너리를 요구하는 경우에는 오히려 제약이 많습니다.

또한 요청량이 일정 규모를 넘어서면 요청당 과금이 상시 서버보다 비싸지는 교차점이 존재합니다. 월 요청 수와 평균 실행 시간을 대입해 손익 분기를 미리 계산해보는 것이 좋습니다.

현실적인 권장안은 혼합 구성입니다. 웹훅 수신과 가벼운 API는 엣지에서, 대용량 파싱과 장시간 배치는 별도 워커 서버에서 처리하는 방식이 비용과 안정성 모두에서 균형점을 제공합니다.

자주 막히는 지점

동일한 웹훅 이벤트가 여러 번 저장되었습니다.

원인: 응답이 지연되어 발신 측이 재전송했고, 수신 측에 멱등 처리가 없었습니다.

해결: 이벤트 ID에 유니크 제약을 걸고 중복 삽입 오류를 정상 흐름으로 처리하십시오. 동시에 검증·적재까지만 하고 즉시 200을 반환하도록 구조를 바꿔 재전송 자체를 줄여야 합니다.

야간 배치가 중간에 멈추고 일부 데이터만 반영됩니다.

원인: 서버리스 실행 시간 제한을 초과해 함수가 강제 종료되었습니다.

해결: 처리 대상을 커서 기반 청크로 나누고, 각 청크 완료 시점에 진행 위치를 저장하십시오. 다음 실행이 저장된 위치부터 이어받도록 하면 데이터 증가에도 안전합니다.

핵심 요약

서버리스 엣지 아키텍처를 통해 인프라 유지 비용을 크게 낮추고 운영 부담을 제거할 수 있습니다.
웹훅은 '빨리 받고 나중에 처리' 원칙과 이벤트 ID 기반 멱등 처리가 핵심입니다.
실행 시간 제한 때문에 대량 배치는 반드시 청크 처리로 설계해야 합니다.
장시간 연산과 대용량 파일 처리는 별도 서버에 맡기는 혼합 구성이 현실적입니다.

자주 묻는 질문

기존 서버에서 돌던 스크립트를 그대로 옮길 수 있나요?

파일 시스템 접근과 네이티브 모듈 의존이 없다면 대부분 이식 가능합니다. 다만 실행 시간 제한과 메모리 제한을 먼저 확인하고, 초과할 가능성이 있다면 청크 처리로 재구성해야 합니다.

데이터베이스 연결은 어떻게 관리하나요?

서버리스는 인스턴스가 수시로 생성·소멸하므로 전통적인 커넥션 풀이 맞지 않습니다. Supabase의 HTTP 기반 클라이언트나 커넥션 풀러(Supavisor)를 경유하는 방식을 사용하십시오.

국내 서비스인데 엣지의 이점이 있나요?

지연 시간 이점은 크지 않지만, 비용 구조와 운영 부담 제거라는 이점은 그대로입니다. 국내 단일 리전 서비스라도 상시 서버를 없앨 수 있다는 점만으로 도입 가치가 있습니다.

전체 아티클 목록