🦞 09. AWS Serverless vs Cloudflare

한 줄 요약: 이 문서는 로컬 중심으로 쓰던 사용자가 필요 시 클라우드까지 확장할 때의 판단 기준을 정리한 가이드이며, AWS/Cloudflare 선택도 기술 우열보다 운영 습관·보안 요구·장애 대응 방식으로 결정하는 게 맞다.

flowchart TD
  A[우리 팀 운영 방식] --> B{AWS IAM/CloudWatch 익숙?}
  B -->|Yes| C[AWS Serverless 우선]
  B -->|No| D{Cloudflare 엣지 운영 익숙?}
  D -->|Yes| E[Cloudflare 계열 우선]
  D -->|No| F[동일 시나리오 1주 PoC 비교]

0) 먼저 결론

• AWS가 맞는 팀: IAM/권한분리/감사로그/계정 분리 운영이 중요한 팀
• Cloudflare가 맞는 팀: 빠른 배포, 경량 운영, 엣지 응답성이 중요한 팀
• 모르면 정답: 두 플랫폼 모두 같은 시나리오로 1주 PoC 후 운영 피로도 기준으로 결정

0-1) 로컬 사용자 관점에서 왜 이 문서가 필요한가

로컬로 안정적으로 쓰고 있다면 클라우드 이야기가 뜬금없게 느껴질 수 있다. 그 감각이 맞다.
핵심은 “지금 당장 옮기자”가 아니라, 언제 로컬만으로 충분하고 언제 확장이 필요한지 기준을 미리 갖추자는 데 있다.

로컬 유지가 맞는 상황

• 개인 사용 중심이고, 접속 범위가 본인 디바이스/사설망에 머무를 때
• 보안 정책상 외부 노출을 극도로 줄여야 할 때
• 장애 대응을 본인이 즉시 할 수 있고 운영 규모가 작을 때

클라우드 검토가 필요한 신호

• 장시간/정시 작업(배치·자동화)이 늘어 로컬 가동 의존이 커질 때
• 협업자가 늘어 접근 제어/로그 추적/권한 분리가 필요할 때
• “내 노트북이 꺼지면 업무도 멈춤” 구조를 끊고 싶을 때
• 장애 시 복구를 개인이 아닌 팀 체계로 관리해야 할 때

실전 권장 프레임

1. 기본은 로컬 유지
2. 필요 기능만 클라우드로 분리(예: 스케줄러, webhook 수신)
3. 하이브리드 운영 후 전체 전환 여부 판단

1) AWS Serverless OpenClaw 구조 요약

flowchart TD
  U[사용자] --> W[웹 채팅]
  U --> T[텔레그램]
  W --> A[API Gateway]
  T --> L[Lambda]
  A --> L
  L --> F[Fargate OpenClaw 컨테이너]
  F --> D[DynamoDB]
  F --> S[S3]

• 요청 시 실행되는 온디맨드 구조로 유휴 시간 비용을 낮추기 쉬움
• AWS 표준(권한, 로그, 배포)과 결합하기 쉬움

2) 비교표 (실무형)

항목	AWS(Serverless OpenClaw)	Cloudflare(Worker/MoltWorker 계열)
진입 난이도	중간	낮음~중간
배포 속도	중간	빠름
권한/보안 세분화	매우 강함(IAM)	상대적으로 단순
로그/관측	CloudWatch 중심	플랫폼 도구 중심
엔터프라이즈 운영적합	높음	중간
빠른 실험/반복	중간	높음

3) 선택 체크리스트

AWS 우세 조건

• IAM 최소권한/감사 추적이 필수다
• 계정/환경 분리(dev/stage/prod)가 중요하다
• 이미 AWS 운영팀/운영 표준이 있다

Cloudflare 우세 조건

• 배포 단순성과 속도가 최우선이다
• 엣지 기반 응답 특성이 중요하다
• 팀이 Cloudflare 도구에 더 익숙하다

4) AWS 도입 시 최소 실행 순서

git clone https://github.com/serithemage/serverless-openclaw.git
cd serverless-openclaw
npm install
cp .env.example .env
npm run build
npm run lint
npm run test
cdk deploy

실제 배포 전에는 리전/권한/비용 경계조건을 반드시 사전 점검한다.

5) 운영 관점에서 자주 틀리는 포인트

• 비용 숫자만 보고 결정하고, 운영 난이도를 과소평가함
• “배포 성공”을 “운영 성공”으로 착각함
• 시크릿/권한 모델 정리 전에 운영 전환함
• 장애 시 롤백/복구 경로를 문서화하지 않음

6) 추천 도입 전략 (2주)

1. 동일 시나리오로 AWS/Cloudflare PoC 각 1주
2. 동일 체크리스트로 점수화
   • 배포 속도
   • 장애 복구 시간
   • 로그 추적성
   • 운영자 피로도
3. 팀이 실제로 오래 유지할 수 있는 쪽으로 결정

7) 현재 구조와 연결해보면

• OpenClaw 메인 구조는 지금처럼 로컬 안전성 중심으로 유지한다.
• 클라우드는 “메인 대체”보다 부하 분산용 실행 레이어로 점진 도입한다.
• 핵심은 플랫폼 선택보다 **운영 표준(권한·로그·복구)**을 먼저 고정하는 것이다.

추천 단계(로컬 사용자용)

• 1단계(현재): 로컬 단독 운영 + API/cron 안정화
• 2단계(하이브리드): 스케줄/웹훅 같은 1~2개 기능만 클라우드 분리
• 3단계(확장): 협업·권한분리 요구가 명확할 때만 본격 전환 검토

AI 활용 고지

이 문서는 생성형 AI를 활용해 초안 작성과 구조 정리를 수행했으며, 최종 공개 전 사람이 검토했다.

📚 다음 읽기

• 🦞 05. Mac Mini + Ollama — 로컬 하드웨어 운영
• 🦞 20. 운영아키텍처 규칙총정리 — 전체 아키텍처 기준
• 🦞 01. 설치 — 설치 가이드로 돌아가기