오늘 개발 분야에서 확인한 공식 발표 다섯 건입니다. 배포 플랫폼 Vercel이 낸 두 건(런타임 캐시와 CI), 코드 저장소 서비스 GitHub의 자동화 기능 Actions, 웹 보안·네트워크 회사 Cloudflare, 쇼핑몰 플랫폼 Shopify의 소식입니다. 전부 만든 곳의 글을 열어 날짜와 내용을 확인했습니다.
| Vercel 런타임 캐싱 | 10월 30일 | Data Cache가 Runtime Cache로 합쳐졌습니다 |
| Cloudflare 비공개 오리진 | 10월 30일 | 비공개 서버를 감춘 채 WAF와 캐시를 씁니다 |
| Shopify Sidekick | 10월 28일 | 앱에서 Sidekick 대화를 열 수 있습니다 |
| Vercel CI | 10월 28일 | 바뀐 부분만 검사하는 CI가 베타로 나왔습니다 |
| GitHub Actions 잠금 파일 | 10월 28일 | 워크플로 의존성 고정이 GA가 됐습니다 |
- Vercel 블로그Vercel 런타임 캐싱 (새 창에서 열려요)Data Cache가 Runtime Cache로 합쳐진 이야기
- Vercel 블로그Vercel CI (새 창에서 열려요)바뀐 작업만 돌리는 CI 베타
런타임 캐싱 (10월 30일). Vercel이 Next.js의 fetch 캐시 같은 데이터 캐시(Data Cache)를 Runtime Cache 하나로 합쳤습니다. Next.js fetch 캐싱과 unstable_cache를 쓰는 쪽은 코드를 고칠 필요가 없다고 합니다. 대신 지금까지 청구하지 않던 읽기와 쓰기에 Runtime Cache 요금이 붙습니다. 기존 팀에는 사전에 안내가 간다고 하니, 캐시를 많이 쓰는 프로젝트라면 안내 메일을 한 번은 열어 보는 게 좋겠습니다.
그림: vercel.com
- Pro 저장 공간8배
프로젝트와 환경마다 따로, 예전 팀 전체 풀 대비
- Enterprise 저장 공간10배
예전 Data Cache 대비
Vercel은 Enterprise 프로젝트 가운데 캐시가 자주 밀려나던 곳에서 하루 안에 캐시 미스율이 대략 절반이 됐다고 적었습니다. 읽기가 가장 몰릴 때의 p99 지연도 가장 큰 리전에서 약 5분의 1로 줄었다고 합니다. 다만 느려진 순간에는 방금 무효화한 데이터를 잠깐 신선한 것으로 볼 수 있다는 단서도 같은 글에 있습니다. 빠른 대신 감수하는 부분이 있는 셈입니다.
Vercel CI (10월 28일). turbo.json에 "ci" 태그를 붙인 작업만 골라, 바뀐 코드가 영향을 주는 것만 돌리는 CI입니다. 따로 워크플로 YAML을 쓰지 않고, 입력이 그대로인 작업은 캐시에서 가져옵니다. 지금은 베타이고 모든 요금제에서 쓸 수 있습니다.
그림: vercel.com
Vercel은 git push부터 "CI passed"까지가 이전보다 2~6배 빨라졌다고 합니다. 자기 저장소와 비공개 베타에서 약 800만 개 작업을 처리한 결과라는데, 말 그대로 만든 곳이 밝힌 수치입니다. 우리 저장소에서도 그만큼 나올지는 돌려 보기 전에는 모릅니다.
- GitHub ChangelogGitHub Actions 잠금 파일 (새 창에서 열려요)워크플로 의존성 고정 GA
- Cloudflare 블로그Cloudflare 비공개 오리진 (새 창에서 열려요)공개 트래픽을 비공개 서버로
GitHub Actions 잠금 파일 (10월 28일). 워크플로에서 v4 같은 태그로 쓰던 액션이 나중에 다른 커밋을 가리켜도, 잠금 파일에 적어 둔 커밋만 실행합니다. gh actions-lock 확장을 설치해 돌리면 .github/workflows/actions.lock이 만들어지고, 액션이 끌어오는 의존성까지 담깁니다. 워크플로는 하나씩 옮기면 되는데, 옮긴 워크플로의 의존성은 전부 잠금 파일에 있어야 합니다.
그림: github.blog
- gh actions-lock 실행 → actions.lock 생성
- actions.lock 생성 → 검토하고 커밋
- 검토하고 커밋 → 잠긴 커밋만 실행
- 잠긴 커밋만 실행 → Dependabot이 같은 PR에서 갱신 (버전 업데이트 때)
Dependabot 버전 업데이트는 같은 PR에서 해당 잠금 항목을 다시 만들어 주고, 관리자는 "Require lockfile" 정책으로 강제할 수도 있습니다. 한 가지 짚어 둘 말이 있습니다. GitHub도 잠금 파일이 예상 밖의 변경을 막아 줄 뿐 그 의존성이 안전한지는 알려 주지 않는다고 적었습니다. 고정하기 전에 내용을 직접 봐야 합니다.
Cloudflare 비공개 오리진 (10월 30일). 인터넷에서 오는 요청을 공개 IP가 없는 서버로 받는 기능이 GA가 됐습니다. 프록시를 켠 DNS 레코드가 사설 IP를 가리키게 하고, 이미 쓰는 Cloudflare One 연결로 서버에 닿습니다. 레코드를 만들 때 "private_routing": true를 넣으면 되고, WAF와 봇 관리, 속도 제한, 캐시, Workers를 그대로 씁니다. 서버는 숨긴 채 내부 API나 AI 에이전트용 서버를 파트너에게 열고 싶을 때 쓰는 그림입니다.
글 제목에는 모든 고객이라고 돼 있지만 설정 단계에는 계정 담당자가 켜 주는 Private Origins 권한이 먼저 나옵니다. 막상 쓰려면 한 단계가 더 있는 셈입니다.
Shopify Sidekick (10월 28일). Shopify 관리자 안에서 도는 앱이 shopify.sidekick.launch({ message })를 부르면, 입력해 둔 메시지가 상인의 질문으로 들어간 Sidekick 대화가 열립니다. Shopify가 든 예시는 보고서 옆에 "Sidekick에게 묻기" 버튼을 두는 것입니다. 앱을 떠나지 않고 맥락에 맞는 도움을 받게 하는 용도입니다.
그림: shopify.dev
다섯 건은 성격이 꽤 다릅니다. 캐시 통합은 청구가 바뀌니 읽어 둘 일이고, 잠금 파일은 GitHub Actions를 쓰는 팀이라면 한 번 시도해 볼 만합니다. 저라면 워크플로 하나로 먼저 해 보겠습니다. Vercel CI의 2~6배는 아직 만든 곳의 숫자라서, 우리 저장소에서 돌려 보기 전에는 아무것도 말하기 어렵습니다. Cloudflare와 Shopify 소식은 해당 서비스를 이미 쓰는 팀의 이야기입니다.
- Simplifying runtime caching on Vercel, Vercel 블로그
- Cloudflare services for private origins is now generally available, Cloudflare 블로그
- Start Sidekick conversations from your app, Shopify 개발자 변경 기록
- Introducing Vercel CI, Vercel 블로그
- GitHub Actions workflow lockfiles are generally available, GitHub Changelog