빠른 쪽은 presigned URL(미리 서명된 URL)입니다. API가 URL에 서명해 주면 클라이언트가 파일을 버킷에 바로 PUT하고, 바이트는 API를 전혀 거치지 않습니다. 표준적인 답이고, 그럴 만한 이유가 있습니다. 그런데 이렇게 하는 순간 백엔드는 흐름에서 빠져 버립니다. URL을 하나 내주고 나서는 아무 소식도 못 듣죠. 파일이 도착했는지, 예상한 크기인지, 애초에 JPEG이 맞기는 한지. 누군가는 백엔드에 알려 줘야 하는데, 흔한 선택지는 하나같이 좀 서글픕니다. 클라이언트가 “다 됐어요"라고 다시 호출해 주길 믿거나(클라이언트는 거짓말하고, 죽고, 신호가 끊깁니다), 버킷을 주기적으로 폴링하거나(느리고 낭비죠), 첫 읽기 때 느긋하게 처리하거나(첫 방문자가 그 비용을 치르고, 파일을 언제부터 참조해도 안전한지는 여전히 모릅니다). S3 직접 업로드가 실제보다 어려워 보이는 이유가 이겁니다. 업로드 자체는 쉽습니다. 빠진 건 신호입니다.

객체 알림이 바로 그 신호입니다. 제가 Fly.io에서 쓰는 S3 호환 스토리지인 Tigris는 버킷에서 객체가 생성되거나 삭제될 때마다 작은 JSON 본문을 여러분의 앱에 POST해 줍니다. AWS에서 이에 해당하는 것이 S3 이벤트 알림인데, 보통은 Lambda나 SQS 큐, EventBridge를 먼저 엮어야 뭔가가 코드에 닿습니다(SNS가 HTTPS 엔드포인트로 POST를 보내 줄 수는 있지만, 그러면 구독 확인과 서명 검증부터 해야 하죠). Tigris는 이걸 여러분이 소유한 URL로 가는 HTTP 요청 하나로 줄였습니다. 스토리지에서 백엔드로 신호를 보내는 방법으로는 이보다 단순하기 어렵죠. 버킷이 백엔드와 이야기할 수 있도록, 여러분이 그 사이에 다리를 놓지 않아도 되도록 있는 기능입니다.

이 글은 그 흐름 전체를 다룹니다. 설정, 이벤트를 받는 Django 엔드포인트, 서버 쪽 처리를 하나도 포기하지 않는 presigned 업로드, 그리고 함정들(CORS, 크기 제한, 만료, 여러 파일)까지요. 마지막에는 같은 신호로 백오피스 일을 시킨 이야기도 있습니다. 버킷에 떨어지는 로그 파일이 Discord 알림이 됐고, 덕분에 몇 달 동안 달래 가며 쓰던 cron 작업 하나를 지울 수 있었습니다.

짧은 답

#

Tigris 대시보드에서 버킷을 열고 Settings, 그다음 Object notifications로 들어갑니다. 앱의 HTTPS URL을 넣고 Basic 인증을 고릅니다(Tigris가 Authorization 헤더에 담아 보내는 사용자 이름과 비밀번호입니다. 다른 선택지는 bearer 토큰이고요). 관심 있는 키만 듣도록 필터도 하나 겁니다. 필터는 SQL 비슷한 표현식이라서, “이 글에서 다루는 프리픽스 세 개만"은 이렇게 씁니다.

WHERE `key` REGEXP "^(uploads/raw|logs/api|media)/"

그러면 Tigris가 변경이 있을 때마다 이런 배치를 보냅니다.

{
  "events": [
    {
      "eventName": "OBJECT_CREATED_PUT",
      "eventTime": "2026-11-07T09:12:44Z",
      "bucket": "example-bucket",
      "object": { "key": "uploads/raw/1f3c.jpg", "size": 48213, "eTag": "9b2c…" }
    }
  ]
}

마주치게 될 이벤트 이름은 OBJECT_CREATED_PUT, OBJECT_CREATED_MULTIPART, OBJECT_CREATED_COPY, OBJECT_DELETED이고, 이름 변경과 스토리지 계층 전환 이벤트도 있습니다. 엔드포인트는 인증을 확인하고, 이벤트마다 키 프리픽스로 라우팅한 뒤, 10초 안에 2xx를 돌려주면 됩니다. 처음부터 염두에 둘 것이 세 가지 있습니다. 전달은 최소 한 번(at least once)이라 같은 이벤트를 다시 보게 되고, 이벤트는 배치로 오기 때문에 요청 하나에 여러 개가 실릴 수 있으며, 순서가 뒤바뀌어 도착할 수도 있으니 도착한 순서로 “최신"을 판단하면 안 됩니다.

버킷 이벤트를 받는 Django 웹훅

#

뷰는 일부러 지루하게 만들었습니다. 인증을 확인하고, 본문을 파싱하고, 이벤트를 하나씩 라우터에 넘깁니다.

import base64, hmac, json, logging
from django.conf import settings
from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt
from django.views.decorators.http import require_POST

from .bucket_events import handle, parse

logger = logging.getLogger(__name__)

def _authorised(request, secret) -> bool:
    header = request.headers.get("Authorization", "")
    if not header.startswith("Basic "):
        return False
    try:
        user, _, password = base64.b64decode(header[6:]).decode().partition(":")
    except (ValueError, UnicodeDecodeError):
        return False
    return hmac.compare_digest(user.encode(), b"tigris") and hmac.compare_digest(
        password.encode(), secret.encode()
    )

@csrf_exempt
@require_POST
def bucket_webhook(request):
    secret = settings.BUCKET_WEBHOOK_SECRET
    if not secret:
        return JsonResponse({"error": "not configured"}, status=503)
    if not _authorised(request, secret):
        return JsonResponse({"error": "unauthorised"}, status=401)
    try:
        body = json.loads(request.body or b"{}")
    except ValueError:
        return JsonResponse({"error": "invalid json"}, status=400)
    for event in parse(body):
        try:
            handle(event)
        except Exception:
            logger.exception("bucket event failed: %s", event.key)
    return JsonResponse({"ok": True})

compare_digest를 쓴 건 무엇을 보내든 확인에 걸리는 시간이 같게 하려는 겁니다(바이트로 비교하는 이유는, 문자열로 비교하면 ASCII가 아닌 입력에서 예외가 나서 조작된 헤더가 401 대신 500을 받기 때문입니다). 갓 만든 스테이징 서버처럼 시크릿이 설정돼 있지 않으면, 엔드포인트는 전부 받아들이는 대신 전부 거부합니다. 그리고 핸들러가 예외를 던져도 로그만 남기고 200을 돌려줍니다. Tigris는 2xx가 아니면 전부 재시도하는데, 재시도해 봐야 같은 버그에 부딪힐 테고, 그때쯤이면 이벤트는 이미 선점돼 있어서(두 섹션 아래에 나옵니다) 재시도가 아무 일도 하지 않을 테니까요. 고치게 만드는 건 그 로그 한 줄입니다. 다만 이건 실패가 매번 똑같이 재현된다는 가정 위에 서 있습니다. 스토리지가 잠깐 타임아웃된 거라면 그 이벤트는 영영 소비돼 버립니다. 사진은 상관없습니다. 저장 요청이 직접 처리할 수 있으니까요. 하지만 로그 파일 쪽 알림은 그대로 잃어버리게 됩니다. 그게 중요하다면 except에서 선점을 풀고 500을 돌려줘 Tigris가 재시도하게 하세요. 대신 진짜 버그는 고칠 때까지 계속 재시도된다는 건 감수해야 하고요.

프리픽스로 라우팅하기

#

버킷 안의 모든 것이 이미 프리픽스별로 정리돼 있으니, 라우팅도 그걸 기준으로 하는 게 자연스럽습니다. 용도 하나가 함수 하나, 테이블 한 줄입니다.

HANDLERS = [
    ("uploads/raw/",   on_raw_photo),
    ("logs/api/",      on_api_log_file),
    ("media/",         on_media_change),
]

def handle(event):
    for prefix, fn in HANDLERS:
        if event.key.startswith(prefix):
            if claim(event):  # 아래 참고
                fn(event)
            return

나중에 네 번째 용도를 추가하려면 함수 하나와 행 하나만 더하면 됩니다. 이게 생각보다 마음에 들더군요.

최소 한 번은 “두 번일 수도 있다"는 뜻

#

엔드포인트가 느리거나 에러를 돌려주면 Tigris는 재시도합니다. 그리고 대부분의 웹훅 발신자가 그렇듯, 이벤트를 딱 한 번만 받는다는 보장은 해 주지 않습니다. 그래서 핸들러가 돌기 전에 (key, eTag, eventName) 기준으로 이벤트를 선점합니다. 여기서 eTag가 중요합니다. 파일이 덮어써지면 eTag가 바뀐 새 버전이니 다시 처리해야 합니다. 같은 버전이 반복해서 온 거라면 처리하면 안 되고요.

from django.core.cache import cache

def claim(event, ttl=7 * 24 * 3600) -> bool:
    k = f"bucket-event:{event.name}:{event.key}:{event.etag}"
    return cache.add(k, 1, ttl)  # 이미 누가 선점했으면 False

cache.add는 키가 없을 때만 값을 넣고, Redis에서는 이게 원자적으로 처리됩니다. 그래서 같은 재시도를 받은 머신 두 대가 둘 다 이길 수는 없습니다. 실제 코드에서는 Redis가 비워져도 살아남게 하고 싶어서 데이터베이스 기반 리스(lease)를 쓰지만, 아이디어는 똑같습니다.

이미지는 S3에 직접 업로드, 파이프라인은 그대로

#

이 배관 작업이 제값을 하는 부분이 여기입니다.

예전에는 게시글에 넣을 사진을 고르면 앱이 들고 있다가, ‘게시’를 누르는 순간 전부 base64로 API에 보냈습니다. API가 리사이즈하고, 썸네일을 만들고, 색상과 blurhash를 계산한 다음에야 응답했죠. 느린 회선에서 사진 열 장이면 스피너가 한참 돌았습니다. 그리고 base64 사진 열 장을 실은 요청은 API 서버가 메모리에 들고 있기엔 크고 느린 본문이라, 사실 제가 사진을 작게 유지해 온 조용한 이유도 그거였습니다.

이제는 네 단계로 나뉘고, 백엔드는 단계마다 소식을 듣습니다.

1. 클라이언트가 사진을 줄이고 슬롯을 요청한다

#

앱은 여전히 기기에서 리사이즈합니다. 서버가 보관하는 긴 변 길이(1080px)에 맞춰 품질 0.7의 JPEG로요. 이 리사이즈는 오로지 사용자의 대역폭을 위한 것이고, 다른 이유는 없습니다. 그다음 API에 업로드 슬롯을 요청합니다.

import uuid
from datetime import timedelta
import boto3
from django.utils import timezone

s3 = boto3.client("s3", endpoint_url="https://fly.storage.tigris.dev")
BUCKET = "example-bucket"

def create_upload_slot(user):
    public_id = uuid.uuid4()
    key = f"uploads/raw/{public_id}.jpg"
    upload = PhotoUpload.objects.create(
        user=user,
        public_id=public_id,
        raw_key=key,
        expires_at=timezone.now() + timedelta(days=2),
    )
    url = s3.generate_presigned_url(
        "put_object",
        Params={"Bucket": BUCKET, "Key": key, "ContentType": "image/jpeg"},
        ExpiresIn=15 * 60,
    )
    return {
        "upload_id": str(upload.public_id),
        "url": url,
        "method": "PUT",
        "headers": {"Content-Type": "image/jpeg"},
        "expires_in": 15 * 60,
    }

슬롯은 파일이기 전에 먼저 행(row)입니다. 그 덕분에 서버는 누가 요청했는지, 언제 만료되는지, 나중에는 실제로 쓰였는지까지 알 수 있습니다.

2. 클라이언트가 버킷에 바로 PUT한다

#

const slot = await api.post("/photo-uploads/");
const res = await fetch(slot.url, {
  method: slot.method,
  headers: slot.headers,
  body: blob,
});
if (!res.ok) throw new Error("upload refused");
// 저장할 때 쓰도록 slot.upload_id를 보관

API는 바이트를 구경도 못 합니다. 브라우저든 React Native든 네이티브 앱이든 똑같고, 유일한 차이는 브라우저에는 버킷에 CORS 규칙이 필요하다는 점입니다. 아래 함정 섹션에 있습니다.

3. Tigris가 백엔드에 알리고, 파이프라인이 돈다

#

몇 초 안에 Tigris가 uploads/raw/…에 대한 OBJECT_CREATED_PUT을 보내고, 핸들러는 base64 경로가 늘 쓰던 것과 같은 이미지 파이프라인을 돌립니다. 사용자가 아직 제목을 입력하는 동안에요.

from io import BytesIO
from PIL import Image, ImageOps
from django.core.files.base import ContentFile
from django.utils import timezone
import blurhash

MAX_BYTES = 15 * 1024 * 1024

def on_raw_photo(event):
    if not event.name.startswith("OBJECT_CREATED"):
        return
    if event.size > MAX_BYTES:
        s3.delete_object(Bucket=event.bucket, Key=event.key)
        return
    upload = PhotoUpload.objects.filter(raw_key=event.key, processed_at=None).first()
    if upload is None:
        return
    data = s3.get_object(Bucket=event.bucket, Key=event.key)["Body"].read()
    process(upload, data)

def to_webp(im, longest, quality):
    im = im.copy()
    im.thumbnail((longest, longest))
    buf = BytesIO()
    im.save(buf, "WEBP", quality=quality, icc_profile=im.info.get("icc_profile"))
    return ContentFile(buf.getvalue())

def process(upload, data):
    with Image.open(BytesIO(data)) as im:
        im = ImageOps.exif_transpose(im).convert("RGB")
        im.thumbnail((1080, 1080))
        upload.width, upload.height = im.size
        upload.dominant_color = "#%02x%02x%02x" % im.resize((1, 1)).getpixel((0, 0))
        upload.image.save(f"{upload.public_id}.webp", to_webp(im, 1080, 80), save=False)
        upload.thumbnail.save(f"{upload.public_id}_t.webp", to_webp(im, 320, 70), save=False)
        upload.blurhash = blurhash.encode(im.resize((32, 32)), 4, 3)
    upload.processed_at = timezone.now()
    upload.save()

on_raw_photo의 첫 줄은 보기보다 중요합니다. 라우터는 uploads/raw/ 아래의 모든 이벤트를 여기로 보내는데, 고아 정리 작업과 크기 검사 자체가 만들어 내는 삭제 이벤트까지 포함해서요. 이미 사라진 키에 get_object를 하면 예외만 날 뿐입니다.

그러니 클라이언트에서 줄인 건 처음부터 끝까지 전송로를 위한 것이었습니다. 포맷(WebP), 크기, 썸네일, 플레이스홀더, 저장할 치수는 여전히 서버가 정합니다. Pillow로 다시 인코딩하면 EXIF 블록도 떨어져 나가는데, 휴대폰 카메라가 GPS 위치를 넣어 두는 곳이 바로 거기라서 개인정보 제거는 덤으로 따라옵니다. ICC 프로필도 같은 식으로 사라질 텐데, 그러면 광색역(wide-gamut) 휴대폰 사진의 색이 살짝 틀어지기 때문에 to_webp는 이걸 그대로 넘겨 줍니다. 픽셀 하나 손대지 않은 원본을 보관하고 싶다면 클라이언트에서 줄이지 않으면 됩니다. 흐름은 똑같고 PUT만 커지는데, 큰 PUT이야말로 이 설계가 싸게 만들어 주는 바로 그것이니까요. 한 가지 걸리는 점은, iPhone 원본은 HEIC라서 Pillow가 pillow-heif를 설치해야만 열 수 있다는 겁니다.

4. 저장은 사진을 붙이기만 하고, 웹훅을 기다리지 않는다

#

‘게시’를 누르면 요청에는 이미지 데이터 대신 upload_ids가 실려 갑니다. 서버는 이를 하나씩 찾아보고, 결과는 세 가지 중 하나입니다.

def take(user, upload_ids):
    uploads = list(PhotoUpload.objects.filter(
        user=user, public_id__in=upload_ids, expires_at__gt=timezone.now()
    ))
    if len(uploads) != len(set(upload_ids)):     # 만료됐거나 이 사용자의 것이 아님
        raise UploadNotReadyError(upload_ids)
    for upload in uploads:
        if upload.processed_at is None:          # 웹훅이 아직 도착하지 않음
            data = read_raw(upload)              # PUT이 안 됐으면 None
            if data is None:
                raise UploadNotReadyError(upload.public_id)
            process(upload, data)
    return uploads

알림이 이미 처리를 마쳤다면 처리된 파일을 그대로 붙입니다. 파일은 버킷에 있는데 알림이 아직 안 왔다면, 저장 요청이 그 자리에서 인라인으로 처리합니다. 그래서 게시글이 웹훅을 기다리는 일은 없습니다. 알림은 의존성이 아니라 먼저 출발할 기회일 뿐이죠. 파일이 아예 없거나, id가 만료됐거나 다른 사람의 것이라면 저장은 검증 에러를 돌려주고 앱이 잠시 후 재시도합니다. 앱은 자기 PUT이 끝나길 기다린 뒤에 보내니까, 실제로는 드문 일입니다.

제대로 버티게 해 준 디테일이 몇 가지 있습니다. 슬롯은 사용자 소유라서 서버는 같은 사람이 만든 업로드 id만 받습니다. 그렇지 않으면 id를 본 누구든 남의 사진을 자기 게시글에 붙일 수 있으니까요. 모든 경로에 대체 수단이 있습니다. 슬롯 요청이 실패하거나, PUT이 거부되거나, API가 구버전이면 앱은 예전과 똑같이 base64를 보냅니다. 업로드 경로를 타는 건 새 사진 전부에 슬롯이 있을 때뿐이라서, 게시글 하나의 사진은 전부 업로드이거나 전부 base64이고, 순서도 목록 하나로 유지됩니다. 그리고 고아 업로드는 만료됩니다. 사진을 골라 놓고 그만두는 사람도 있어서, 어디에도 붙지 않은 업로드는 이틀 뒤에 만료되고 기존의 고아 미디어 정리 작업이 파일을 치웁니다.

presigned URL 업로드의 함정: CORS, 크기 제한, 만료, 여러 파일

#

presigned 업로드에서 꼬이는 일은 대부분 알림이 나가기도 전에 꼬입니다. 한 페이지에 모아 두고 싶었던 것들입니다.

CORS, 브라우저에만 해당

#

네이티브 앱은 신경 쓸 일이 없습니다. 브라우저는 PUT 전에 버킷으로 preflight OPTIONS를 보내는데, 버킷의 CORS 규칙이 여러분의 오리진에서 오는, Content-Type 헤더가 붙은 PUT을 허용하지 않으면 업로드는 CORS 에러로 실패합니다. Tigris는 표준 S3 CORS 설정을 그대로 받으니 규칙 모양은 AWS와 같습니다. presigned PUT이 curl에서는 되고 페이지에서는 안 될 때 제일 먼저 확인할 것이 이겁니다.

Content-Type은 서명의 일부다

#

ContentType을 넣어 서명하면 클라이언트는 정확히 그 헤더를 보내야 하고, 아니면 버킷이 403 SignatureDoesNotMatch로 답합니다. 슬롯이 URL과 함께 헤더까지 돌려주는 이유가 그겁니다. 일부러 넣어서 서명하되, 그게 어디까지 막아 주는지는 알아 두세요. 강제되는 건 헤더이지 내용이 아니라서, image/jpeg라고 이름표를 붙인 PDF는 통과합니다. 진짜 검사는 파이프라인입니다. Pillow는 이미지가 아닌 것은 열기를 거부하고, 행은 끝내 처리됨으로 표시되지 않습니다.

크기 제한

#

presigned PUT URL에는 크기 제한이 없습니다. 바이트가 떨어지기 전에 확실히 막아야 한다면 content-length-range 정책 조건을 건 presigned POST가 그 일을 합니다. 저는 굳이 그러지 않았습니다. 알림에 객체의 size가 실려 오니까요. 핸들러는 제한을 넘는 것은 읽기 전에 지워 버리고, 저장 시점 경로는 많아야 제한에 1바이트를 더한 만큼만 읽어서 넘었는지 판별합니다. 앱이 보내는 건 몇백 KB입니다. 15MB 근처라면 앱이 보낸 게 아닙니다.

만료

#

시계가 두 개입니다. presigned URL은 15분 동안 유효한데, PUT 한 번에는 충분하고 새어 나간 URL이 금방 쓸모없어질 만큼 짧습니다. 슬롯 행은 이틀 동안 유효해서, 사진을 골라 놓고 휴대폰을 내려놨다가 다음 날 게시글을 마무리하는 경우까지 감당합니다. 클라이언트는 하루가 지난 미완료 업로드는 낡은 것으로 보고, 요행을 바라는 대신 새로 시작합니다.

여러 파일, 그리고 더 큰 파일

#

파일 하나에 슬롯 하나입니다. 사진 열 장이면 슬롯 열 개와 병렬 PUT 열 개이고, 각각 진행률이 따로 있습니다(XMLHttpRequest는 upload.onprogress를 주고, fetch는 주지 않습니다). 거대한 base64 POST 하나로는 얻을 수 없는 것이죠. 몇 MB를 넘어가면 멀티파트를 쓰세요(파트 하나가 최소 5 MiB라서, 그보다 한참 큰 파일에 쓰는 겁니다). 서버에서 멀티파트 업로드를 만들고, upload_part마다 presign한 뒤, 파트가 다 들어오면 완료하면 됩니다. 업로드가 완료되면 Tigris가 OBJECT_CREATED_MULTIPART를 보내니 같은 핸들러가 돌고 다른 건 아무것도 바뀌지 않습니다.

순서가 뒤바뀔 때

#

객체가 둘 이상의 리전에 쓰였을 수 있기 때문에 이벤트는 순서가 뒤바뀌어 도착할 수 있습니다. 업로드에는 상관없습니다. 키 하나에 이벤트 하나니까요. 덮어써지는 키라면 웹훅이 도착한 순서가 아니라 eTag와 객체의 Last-Modified를 믿으세요.

같은 신호를 로그에도: Discord 알림

#

버킷이 백엔드와 이야기할 수 있게 되면, 버킷에 떨어지는 무엇에든 같은 방식으로 반응할 수 있습니다. 제가 두 번째로 겨냥한 것은 로그였습니다.

앱 로그는 작은 gzip 파일로 버킷에 실려 옵니다. 앱마다 대략 5분에 하나씩이죠. 올해 대부분 동안은 15분 주기 cron으로 도는 GitHub Action이 DuckDB로 그 아카이브의 최근 20분을 읽어서 느린 요청 줄을 찾아 Discord에 요약을 올리고 있었습니다. 서류상으로는 문제없습니다. 그런데 실제로는 플랫폼이 바쁠 때 GitHub의 예약 워크플로가 제시간에 돌지 않습니다. 그래서 “15분마다"는 사실상 “몇 시간마다"에 가까웠고, 겨우 돌 때쯤엔 씹어야 할 구간이 커져 있어서 가끔 메모리가 바닥났습니다. 실행 사이에 빠지는 게 없도록 구간을 겹치게 잡아 뒀더니 같은 느린 요청이 두 번 올라오는 일도 생겼고요. “요청이 느리면 알려 줘” 하나 하자고 돌리기엔 장치가 너무 많았습니다.

이제는 로그 파일이 도착하는 순간 한 번씩만 읽습니다. gzip으로 몇 KB밖에 안 되는 파일들이죠. 핸들러가 느린 요청 줄을 뽑아내고, 그런 줄이 충분히 많거나 정말 느린 게 하나라도 있으면 Discord 웹훅으로 채널에 요약을 올립니다. 한 파일 안에 5xx 응답이 몰려 있을 때도 마찬가지입니다. Python에서 Discord 웹훅을 쏘는 건 호출 한 번입니다.

import requests
from django.conf import settings

def discord_alert(text: str) -> None:
    requests.post(
        settings.DISCORD_WEBHOOK_URL,
        json={"content": text[:1900]},  # Discord 메시지 상한은 2000자
        timeout=5,
    )

cron도 없고, 구간 겹침도 없고, 중복도 없습니다. 알림은 GitHub가 마음 내킬 때가 아니라 요청이 있고 몇 분 안에 도착합니다. 그 Action은 사라졌습니다.

어차피 파일을 열어 둔 김에, 안에 든 것(에러, 경고, 헬스 체크)을 세어서 시간별 집계 테이블에도 넣습니다. 일일 요약은 예전엔 하루치 아카이브를 통째로 훑었는데, 이제는 몇백 행만 읽고 집계에 빈 곳이 있을 때만 아카이브로 돌아갑니다.

삭제 감시

#

이건 계획한 게 아닙니다. OBJECT_DELETED 이벤트가 생기니 저절로 따라 나온 거죠. 미디어 파일이 삭제되면 핸들러가 아직 그 파일을 가리키는 행이 있는지 확인합니다. 있다면 어딘가에 버그가 있는 거라서(아니면 버킷 콘솔에서 손이 미끄러진 사람이 있거나요), 해당 컬럼을 비워 앱이 깨진 이미지 대신 플레이스홀더를 보여 주게 하고, 보고를 올립니다.

시간당 삭제 수도 셉니다. 평소 정리 작업으로 지워지는 건 몇 개 정도입니다. 혹시라도 한 시간에 몇백 개가 지워진다면, 사용자들이 사진이 비어 있다고 신고하기 시작할 때가 아니라 바로 그 순간에 알고 싶습니다.

알아 두면 좋은 것들

#

빨리 응답하세요. Tigris는 전달 한 번에 10초를 줍니다. 5 KB짜리 로그 파일을 읽거나 휴대폰 사진 한 장을 처리하는 건 그 안에 들어갑니다. 더 걸릴 수 있는 건 큐로 보내고 뷰는 200을 돌려주세요. 안 그러면 Tigris가 타임아웃 후 재시도하고, 다시 중복 제거 문제로 돌아가게 됩니다.

버킷 단에서 거르세요. 제 로그 수집기는 앱마다 몇 분에 한 번씩, 끝없이 파일을 씁니다. 관심 있는 프리픽스가 하나뿐이라면 알림 필터에 그렇게 적어서, 나머지 일로 앱이 깨어나지 않게 하세요.

가짜 본문으로 테스트하세요. 페이로드가 작고 안정적이라서, 테스트는 올바른 Authorization 헤더와 함께 JSON을 뷰에 POST하고 핸들러가 한 일을 확인하기만 하면 됩니다. 실제 스토리지는 건드리지 않습니다.

첫날부터 모든 걸 걸지는 마세요. 여기 나온 용도는 전부 대체 수단이 있습니다. 저장이 사진을 직접 처리할 수 있고, 일일 요약은 여전히 아카이브를 훑을 수 있고, 앱은 여전히 base64를 보낼 수 있습니다. 알림 덕분에 하나하나 빨라지고 저렴해졌지만, 웹훅 하나가 빠졌다고 무너지는 건 없습니다.

이번 주의 백미는 그 워크플로 파일을 지운 순간이었습니다. YAML 40줄, Python 스크립트 하나, 저장소 시크릿 두 개, 그리고 주기적으로 찾아오던 “알림이 왜 안 왔지?“가 전부 사라졌고, 그 자리를 작은 파일 하나가 도착하면 그걸 읽는 핸들러 하나가 대신하고 있습니다. 그래도 핵심은 업로드였습니다. 사진은 네트워크가 허락하는 만큼 빠르게 올라가고, 서버는 여전히 사진 하나하나에 대해 마지막 결정권을 쥐고 있으며, 버킷과 백엔드 사이에 다리를 놓을 필요는 아무에게도 없었습니다. 이제는 버킷이 무슨 일이 있었는지 그냥 말해 주니까요.

2026년 9월 13일 업데이트. 이 글이 올라간 뒤 Codemagic이 CodePush 계열의 오픈소스 자체 호스팅 OTA 서버 Patch를 공개했습니다. 서버를 직접 만들고 싶지는 않아서 여기까지 오셨다면 이제 현실적인 선택지가 하나 생긴 셈입니다. 저도 그 뒤 아래 구성에서 Patch로 앱 하나를 옮기고 그 과정을 글로 정리했고, 마치며 아래에 짧은 메모를 덧붙였습니다. 밝혀둘 것: 그 마이그레이션과 글은 Codemagic의 의뢰로 비용을 받고 진행했고, 이 글에 언급을 넣어달라는 요청도 있었습니다. 본문의 코드는 이후 짧은 예제로 줄였습니다.

제가 만들고 있는 견적 앱은 버그 수정을 OTA(Over-the-Air)로 배포합니다. JavaScript 변경 사항이 App Store 심사를 거치지 않고 바로 사용자 폰에 도착하죠. Expo의 호스팅 서비스인 EAS Update를 쓰면 이걸 알아서 해주지만, 저는 Django REST Framework와 Tigris S3로 서버를 직접 만들었습니다. 그 뒤로 iOS와 Android 업데이트는 전부 이 서버가 처리하고 있습니다.

Expo OTA 업데이트는 이렇게 동작합니다. 앱에 들어 있는 expo-updates 라이브러리가 플랫폼과 런타임 버전을 헤더에 담아 업데이트 서버에 매니페스트를 요청합니다. 서버는 호환되는 최신 업데이트와 그 JavaScript 번들·에셋의 URL을 돌려주고, 앱은 그것들을 내려받아 다음 실행 때 새 번들로 뜹니다. EAS Update는 이 프로토콜을 구현한 Expo의 호스팅 서버일 뿐이라, 같은 프로토콜을 말하는 서버라면 무엇이든 그 자리를 대신할 수 있습니다. 제가 만든 게 바로 그런 서버입니다.

이 글에서는 모델 설계부터 매니페스트 엔드포인트, 퍼블리시 파이프라인, 그리고 직접 운영해 봐야 알게 되는 함정까지 전체 과정을 정리했습니다.

굳이 직접 호스팅하는 이유

#

제 경우엔 비용이 가장 컸습니다. EAS Update 요금은 사용량에 따라 올라가서, 사용자가 늘고 업데이트가 잦아지면 부담이 됩니다. 반면 Tigris 같은 S3 호환 스토리지는 거의 공짜에 가깝죠. 다른 이유가 더 중요한 경우도 있을 겁니다. 애플리케이션 에셋을 전부 자체 인프라 안에 둬야 하는 업계도 있고, 서버를 직접 운영하면 업데이트 흐름 전체를 손에 쥐게 되니 특정 사용자 그룹에만 배포하거나 번들 A/B 테스트를 하는 것도 자유롭습니다. 업데이트 파이프라인이 Expo의 가용성이나 다음 요금 개편에 좌우되지 않는다는 점도 은근히 큽니다.

전체 구조

#

구성 요소는 넷입니다. 업데이트 매니페스트를 내려주고 메타데이터를 저장하는 Django 백엔드, 번들과 에셋 실물을 보관하는 Tigris, 내보내기·업로드·등록을 한 번에 처리하는 퍼블리시 스크립트, 그리고 Expo 서버 대신 제 서버를 바라보도록 설정한 모바일 앱입니다.

┌─────────────────┐
│   Mobile App    │
│  (expo-updates) │
└────────┬────────┘
         │ 1. Request manifest
         │    (with headers: platform, runtime-version)
         ↓
┌─────────────────┐
│  Django Server  │
│  /api/expo-     │◄─── 2. Query DB for latest update
│   updates/      │
│   manifest/     │
└────────┬────────┘
         │ 3. Generate presigned URLs
         │
         ↓
┌─────────────────┐
│   Tigris S3     │
│  (Asset Files)  │◄─── 4. App downloads bundles directly
└─────────────────┘

구현

#

모델 두 개

#

모든 것의 바탕은 ExpoUpdate와 ExpoUpdateAsset입니다. 전자는 업데이트별 메타데이터를 담습니다.

class ExpoUpdate(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4)
    runtime_version = models.CharField(max_length=50, db_index=True)
    platform = models.CharField(
        max_length=10,
        choices=[("ios", "iOS"), ("android", "Android")],
        db_index=True
    )
    is_active = models.BooleanField(default=True, db_index=True)
    manifest_data = models.JSONField()
    description = models.TextField(blank=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        indexes = [
            models.Index(fields=["runtime_version", "platform", "is_active", "-created_at"])
        ]

설계할 때 의도한 부분이 몇 가지 있습니다. runtime_version은 app.json의 runtimeVersion에 대응하는데, 클라이언트는 자기 런타임 버전과 일치하는 업데이트만 내려받기 때문에 이 필드가 핵심 역할을 합니다. iOS와 Android는 번들 자체가 다르니 레코드를 분리했고, is_active는 롤백 장치입니다. 문제 있는 업데이트를 비활성화하면 클라이언트는 이전 것으로 돌아갑니다. manifest_data에는 Expo Updates v1 프로토콜 매니페스트 전체를 JSON으로 넣어두기 때문에, 서빙할 때는 꺼내기만 하면 됩니다.

ExpoUpdateAsset은 개별 파일을 추적합니다.

class ExpoUpdateAsset(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4)
    update = models.ForeignKey(ExpoUpdate, on_delete=models.CASCADE, related_name="assets")
    hash = models.CharField(max_length=255, db_index=True)
    key = models.CharField(max_length=255)
    content_type = models.CharField(max_length=100)
    file_extension = models.CharField(max_length=10)
    file_path = models.CharField(max_length=500)
    file_size = models.IntegerField(default=0)

에셋은 SHA-256 해시로 참조하므로 불변이고 캐시하기도 좋습니다. 같은 에셋을 여러 업데이트에서 공유할 수도 있고요.

매니페스트 엔드포인트

#

앱과 서버가 실제로 대화하는 곳이 /api/expo-updates/manifest/입니다. Expo Updates v1 프로토콜을 구현합니다.

@action(detail=False, methods=["get"], url_path="manifest")
def manifest(self, request):
    # Extract required headers
    protocol_version = request.META.get("HTTP_EXPO_PROTOCOL_VERSION")
    platform = request.META.get("HTTP_EXPO_PLATFORM")
    runtime_version = request.META.get("HTTP_EXPO_RUNTIME_VERSION")

    # Validate protocol version
    if protocol_version != "1":
        return Response(
            {"error": f"Unsupported protocol version: {protocol_version}"},
            status=400
        )

    # Find latest active update for this runtime + platform
    update = ExpoUpdate.objects.filter(
        runtime_version=runtime_version,
        platform=platform,
        is_active=True,
    ).order_by("-created_at").first()

    # No update available - client uses embedded bundle
    if not update:
        response = Response(status=204)
        response["expo-protocol-version"] = "1"
        return response

    # Generate presigned URLs for all assets
    manifest_data = build_manifest(update)  # fills in presigned asset URLs

    return Response(manifest_data, status=200)

여기서 중요한 게 셋 있습니다. 업데이트가 없으면 204를 반환하고, 앱은 내장 번들을 그대로 씁니다. 매니페스트의 에셋 URL은 presigned URL이라 Django를 거치지 않고 Tigris CDN에서 바로 내려받습니다. 그리고 응답의 expo-protocol-version 헤더는 생략하면 안 됩니다. 클라이언트가 실제로 확인하거든요.

업데이트 퍼블리시

#

퍼블리시는 Django 관리 명령과 이를 감싼 셸 스크립트로 합니다. 관리 명령은 expo export 출력을 읽고, 에셋마다 SHA-256 해시를 계산하고, 번들과 에셋을 Tigris에 병렬로 올리고, 데이터베이스 레코드를 만들고, 필요하면 프로덕션 동기화용 임포트 JSON까지 버킷에 올립니다. 핵심만 추리면 이렇습니다.

from concurrent.futures import ThreadPoolExecutor

from django.db import transaction


def publish(platform, runtime_version, manifest, files):
    # Upload the bundle and assets in parallel (keys are content hashes)
    with ThreadPoolExecutor(max_workers=10) as executor:
        list(executor.map(upload_asset, files))

    # Swap the active update in one transaction
    with transaction.atomic():
        ExpoUpdate.objects.filter(
            runtime_version=runtime_version,
            platform=platform,
            is_active=True,
        ).update(is_active=False)

        return ExpoUpdate.objects.create(
            runtime_version=runtime_version,
            platform=platform,
            manifest_data=manifest,
        )

평소에 실제로 치는 명령은 래퍼 스크립트 쪽입니다.

# Publish to local environment
./publish.sh ios

# Publish to production
./publish.sh ios --production

# Dry run to validate
./publish.sh --dry-run

내보내기 전에 프로덕션 환경 변수를 불러오고, 플랫폼은 하나만 또는 둘 다 지정할 수 있으며, 다음에 설명할 프로덕션 동기화까지 알아서 해줍니다.

프로덕션 동기화

#

프로덕션 인증 정보를 제 노트북에 두고 싶지 않아서, 프로덕션 배포는 두 단계로 나눴습니다. 먼저 로컬에서 퍼블리시하고(에셋은 Tigris로, 메타데이터 JSON 스냅샷도 함께), 그다음 S3 경로를 담아 프로덕션 API를 호출하면 서버가 직접 메타데이터를 가져옵니다.

@action(detail=False, methods=["post"], url_path="import-update")
def import_update(self, request):
    # Authenticate via Bearer token
    token = request.META.get("HTTP_AUTHORIZATION", "").removeprefix("Bearer ")
    if not hmac.compare_digest(token, settings.IMPORT_TOKEN):
        return Response({"error": "Invalid token"}, status=401)

    # Download the import JSON from the bucket
    s3_key = request.data.get("s3_key")
    obj = s3_client.get_object(Bucket=bucket_name, Key=s3_key)
    data = json.loads(obj["Body"].read())

    # Import into the production database
    with transaction.atomic():
        update, _ = ExpoUpdate.objects.update_or_create(id=data["id"], defaults={...})
        for asset_data in data["assets"]:
            ExpoUpdateAsset.objects.update_or_create(...)

    # Clean up the import JSON
    s3_client.delete_object(Bucket=bucket_name, Key=s3_key)
    return Response({"update_id": str(update.id)})

앱이 내 서버를 바라보게 하기

#

app.json에서 업데이트 URL과 런타임 버전을 설정합니다.

{
  "expo": {
    "runtimeVersion": "1.0.0",
    "updates": {
      "url": "https://api.example.com/api/expo-updates/manifest/"
    }
  }
}

runtimeVersion은 앱과 서버 간에 엄격하게 맞춰야 합니다. 네이티브 코드를 바꾸거나 Expo SDK를 올렸다면 런타임 버전을 올리고 그 버전용 업데이트를 새로 퍼블리시하세요.

Tigris 스토리지

#

Tigris는 S3 호환 오브젝트 스토리지인데, AWS S3보다 훨씬 저렴하고 글로벌 엣지 캐싱이 기본으로 포함됩니다. 사용자가 수 메가바이트짜리 번들을 내려받는 상황에서는 이게 꽤 중요하죠. Django 쪽 설정은 이렇습니다.

# settings.py
BUCKET_NAME = os.getenv("BUCKET_NAME")
AWS_ENDPOINT_URL_S3 = os.getenv("AWS_ENDPOINT_URL_S3")
AWS_ACCESS_KEY_ID = os.getenv("AWS_ACCESS_KEY_ID")
AWS_SECRET_ACCESS_KEY = os.getenv("AWS_SECRET_ACCESS_KEY")
AWS_REGION = os.getenv("AWS_REGION", "auto")

클라이언트 생성은 평범한 boto3입니다.

import boto3

def create_s3_client(endpoint_url, region, access_key, secret_key):
    return boto3.client(
        "s3",
        endpoint_url=endpoint_url,
        region_name=region,
        aws_access_key_id=access_key,
        aws_secret_access_key=secret_key,
    )

다운로드는 presigned URL을 거치므로 앱이 CDN에서 바로 받아옵니다.

presigned_url = s3_client.generate_presigned_url(
    "get_object",
    Params={"Bucket": bucket_name, "Key": asset.file_path},
    ExpiresIn=3600,  # 1 hour
)

보안

#

매니페스트 엔드포인트는 일부러 인증을 걸지 않았습니다. 로그인하기 전의 앱에도 업데이트는 필요하니까요. 임포트 엔드포인트는 이야기가 다릅니다. 프로덕션 데이터베이스에 쓸 수 있는 만큼 공유 시크릿으로 보호하고, 타이밍 공격을 막기 위해 상수 시간 비교를 씁니다.

IMPORT_TOKEN = os.getenv("IMPORT_TOKEN")

# Constant-time comparison prevents timing attacks
if not hmac.compare_digest(token, IMPORT_TOKEN):
    return Response({"error": "Invalid token"}, status=401)

에셋 무결성은 이 설계에서 공짜로 따라옵니다. 모든 것이 SHA-256 해시로 검증되니 변조된 에셋은 그냥 실패할 뿐입니다. presigned URL도 1시간이면 만료돼서 번들이 계속 직링크로 노출될 일이 없습니다.

속도

#

(runtime_version, platform, is_active, -created_at) 복합 인덱스 덕분에 업데이트가 아무리 쌓여도 매니페스트 쿼리는 빠르게 유지됩니다.

class Meta:
    indexes = [
        models.Index(fields=["runtime_version", "platform", "is_active", "-created_at"])
    ]

퍼블리시 스크립트는 에셋을 병렬로 업로드합니다.

with ThreadPoolExecutor(max_workers=10) as executor:
    futures = {executor.submit(upload_asset, asset): asset for asset in assets}
    for future in as_completed(futures):
        # Track progress

에셋 50개 정도의 일반적인 업데이트 기준으로, 퍼블리시 시간이 2분 남짓에서 15초로 줄었습니다. 배포 쪽은 할 일이 없습니다. Tigris가 알아서 사용자 가까운 엣지에 캐싱해 줍니다.

평소 워크플로우

#

개발 중

#

# 1. Make code changes in the app
git commit -am "Fix bug"

# 2. Publish OTA update to local environment
./publish.sh ios

# 3. Test on device
# App automatically downloads and applies update

프로덕션 배포

#

# 1. Publish to production
./publish.sh ios --production

# 2. Monitor
# Check Django admin for update records
# Verify assets in Tigris dashboard

롤백

#

# Mark problematic update as inactive in Django admin
# or via management shell:
python manage.py shell

>>> from updates.models import ExpoUpdate
>>> bad_update = ExpoUpdate.objects.get(id="uuid-here")
>>> bad_update.is_active = False
>>> bad_update.save()

# Clients will now receive the previous active update

비용

#

이 앱의 활성 사용자는 500명 정도입니다. Tigris에서는 과거 업데이트 약 200MB 저장에 월 $0.02쯤, 업데이트 다운로드로 나가는 월 약 50GB 이그레스에 $1.00쯤 나옵니다. Django 쪽은 원래 API가 돌아가던 서버에 얹혀 있어서 추가 비용이 없고요. 다 합쳐 월 1달러 수준입니다. 비슷한 사용량이면 EAS Update는 연간 $300~500 정도 나올 테니, 본전은 사실상 바로 뽑았습니다.

모니터링과 디버깅

#

특별한 건 없습니다. ViewSet이 매니페스트 요청을 전부 로그로 남깁니다.

logger.info(f"Manifest request: platform={platform}, runtime={runtime_version}")

사실상의 대시보드는 Django admin입니다. 모델만 등록해 두면 조회와 필터링이 다 됩니다.

@admin.register(ExpoUpdate)
class ExpoUpdateAdmin(admin.ModelAdmin):
    list_display = ["platform", "runtime_version", "is_active", "created_at"]
    list_filter = ["platform", "is_active", "runtime_version"]
    search_fields = ["description"]

클라이언트 쪽에서는 expo-updates가 지금 무엇을 보고 있는지 알려줍니다.

import * as Updates from 'expo-updates';

Updates.checkForUpdateAsync().then(update => {
  console.log('Update available:', update.isAvailable);
  console.log('Manifest:', update.manifest);
});

함정들

#

런타임 버전 불일치

#

가장 흔한 실패가 가장 조용하게 일어납니다. 클라이언트는 자기 런타임 버전과 일치하는 업데이트만 내려받습니다. 설치된 앱이 런타임 1.0.0인데 1.0.1용으로 퍼블리시하면, 아무것도 도착하지 않고 에러도 없습니다. 런타임 버전은 빌드와 맞춰 두고, 올리는 건 네이티브 코드가 바뀔 때만으로 제한하세요.

createdAt 타임스탬프

#

expo-updates 클라이언트는 매니페스트의 createdAt을 내장 번들의 commitTime과 비교해서, createdAt이 더 새로운 업데이트만 적용합니다. ViewSet에서는 데이터베이스 타임스탬프로 덮어씁니다.

manifest_data["createdAt"] = update.created_at.strftime("%Y-%m-%dT%H:%M:%S.%fZ")

로컬 개발에서 OTA를 퍼블리시한 뒤에 바이너리를 빌드했다면, 타임스탬프가 더 새로워지도록 OTA를 다시 퍼블리시하세요.

매니페스트 에셋 key 값

#

매니페스트의 에셋별 key 필드는 expo-updates가 캐싱에 쓰는 값인데, 랜덤 UUID나 아무 문자열이 아니라 결정론적 해시(파일명의 MD5 같은)여야 합니다. 이걸 틀리면 클라이언트가 에셋을 제대로 캐시하거나 가져오지 못해서, 첫 로드만 성공하고 그 뒤로는 업데이트가 조용히 깨집니다. 이 문제를 알려준 독자 Raphael Mutschler에게 감사드립니다. 원인을 찾기 전까지 그의 환경에서는 업데이트가 정확히 한 번만 동작했다고 하네요.

expoClient의 앱 설정

#

Linking, Constants처럼 런타임에 앱 설정을 읽는 기능을 쓰고 있다면, 매니페스트의 extra.expoClient 필드에 앱 설정을 넣어야 합니다. 없으면 처음엔 멀쩡히 실행되다가, 앱을 껐다 다시 열 때 크래시하거나 아예 열리지 않을 수 있습니다. expo-updates가 내장 매니페스트를 OTA 매니페스트로 교체하는데, expoClient가 빠져 있으면 해당 API들이 의존하는 설정에 접근할 길이 없어지기 때문입니다. 이것도 Raphael Mutschler가 잡아준 문제입니다.

에셋 정리

#

오래된 업데이트는 Tigris에 계속 쌓입니다. 지금은 수동으로 정리하고 있습니다.

# Delete updates older than 30 days
from datetime import timedelta
from django.utils import timezone

cutoff = timezone.now() - timedelta(days=30)
old_updates = ExpoUpdate.objects.filter(created_at__lt=cutoff, is_active=False)

for update in old_updates:
    # Delete assets from S3
    for asset in update.assets.all():
        s3_client.delete_object(Bucket=bucket_name, Key=asset.file_path)
    # Delete DB records
    update.delete()

당연히 예약 작업으로 돌려야 할 일인데, 아직 손을 못 댔습니다.

다음에 붙이고 싶은 것들

#

(2026년 9월: 지금은 Patch가 이 세 가지를 비롯해 더 많은 걸 해줍니다. 마이그레이션 후기를 참고하세요.)

점진적 롤아웃

#

rollout_percentage 필드를 추가하면 일부 사용자에게 먼저 내보낼 수 있습니다.

rollout_percentage = models.IntegerField(default=100)

# In the manifest view:
if update.rollout_percentage < 100:
    # Hash user ID and check if they're in rollout group
    user_hash = int(hashlib.sha256(user_id.encode()).hexdigest(), 16)
    if (user_hash % 100) >= update.rollout_percentage:
        return Response(status=204)  # No update

스테이징 업데이트 분리

#

environment 필드를 두면 스테이징 빌드와 프로덕션이 서로 다른 업데이트를 받게 할 수 있습니다.

environment = models.CharField(max_length=20, default="production")

# Client sends environment in custom header
environment = request.META.get("HTTP_X_UPDATE_ENVIRONMENT", "production")
update = ExpoUpdate.objects.filter(environment=environment, ...).first()

다운로드 집계

#

작은 모델 하나면 “이 업데이트, 실제로 받은 사람이 있긴 한가?“라는 질문에 제대로 답할 수 있게 됩니다.

class ExpoUpdateDownload(models.Model):
    update = models.ForeignKey(ExpoUpdate, on_delete=models.CASCADE)
    user_id = models.CharField(max_length=255, null=True)
    platform = models.CharField(max_length=10)
    downloaded_at = models.DateTimeField(auto_now_add=True)

마치며

#

시스템 전체가 Django 모델 두 개와 뷰 몇 개, 퍼블리시 스크립트 하나, 그리고 인프라 비용 월 1달러입니다. 시작하기 전에 예상했던 것보다 작게 끝났고, 그 뒤로 두 플랫폼에서 조용히 제 몫을 하고 있습니다.

위 코드는 그 프로덕션 앱의 코드를 예제로 단순화한 것이니, 만드시는 것에 맞게 고쳐 쓰면 됩니다. 독자 Raphael Mutschler가 독립형 구현을 expo-ota-server로 공개해 두었으니, 바로 돌아가는 코드에서 시작하고 싶다면 그쪽도 좋습니다.

서버를 직접 쓰고 싶지 않다면

#

이 글을 쓴 뒤로 Django 없이 같은 자리를 채워주는 것이 둘 생겼습니다. 하나는 위에서 언급한 Raphael의 expo-ota-server입니다. 다른 하나는 Codemagic Patch입니다. 오픈소스이고, Docker Compose 설치로 자기 서버에서 돌아가며, Expo Updates 프로토콜 대신 CodePush 방식을 쓰기 때문에 expo-updates를 Patch SDK로, eas update를 cmpatch release-react로 바꾸게 됩니다. S3 호환 스토리지를 쓸 수 있어서 이 글에 나온 것 같은 Tigris 버킷도 그대로 씁니다.

“다음에 붙이고 싶은 것들"에 적어두고 결국 만들지 않은 것들이 기본으로 들어 있습니다. 스테이징과 프로덕션 배포, 퍼센트 롤아웃, 릴리스별 다운로드·설치 집계, 필수 업데이트, 바이너리 패치, 코드 서명, 그리고 새 번들이 앱 준비 완료를 보고하기 전에 크래시하면 기기에서 롤백하는 기능까지요. 대신 SDK가 앱에 들어 있어야 하니 누구든 Patch 업데이트를 받기 전에 새 네이티브 바이너리가 필요하고, 관리 명령 대신 운영할 서버가 생깁니다.

제 앱 하나를, 커밋된 네이티브 프로젝트와 실제 릴리스 파이프라인째로, 이 글의 구성에서 Patch로 옮겼습니다. 그 후기에 뭐가 됐고 뭐가 안 됐는지, 실제로 얼마나 어려운지를 적었습니다. 그 작업은 Codemagic이 후원했고, 사실관계 검토는 있었지만 편집 방향에 대한 검토는 없었습니다.

전체 사양은 Expo Updates Protocol Specification을 참고하세요.