에이전트를 위한 인프라가 바뀌고 있다

이번 주에 눈에 띈 소식 세 개가 묘하게 같은 방향을 가리킨다.

GitHub가 새 Git 스토리지 아키텍처를 공개했는데, 요약의 첫 문장이 인상적이다. "수천 개의 에이전트가 동시에 단일 저장소에 푸시할 수 있도록 설계됐다." Cloudflare는 에이전트가 사람처럼 행동하지만 사람이 아닌 문제를 다루면서, 서버 입장에서 에이전트 트래픽을 어떻게 식별하고 신뢰할지에 대한 접근법을 제안했다. Vercel은 Schedules 기능을 퍼블릭 베타로 열었다. cron 작업을 플랫폼 수준에서 직접 관리하는 기능이다.

세 소식을 따로 읽으면 각자의 릴리스 노트지만, 함께 보면 인프라 레이어 전체가 사람이 아닌 에이전트를 기본 행위자로 가정하기 시작했다는 느낌이 든다.

저장소가 에이전트 속도를 버티도록 바뀐다

GitHub 블로그의 요약에서 "수천 개의 에이전트가 동시에 단일 저장소에 푸시"라는 문구를 처음 읽었을 때, 솔직히 나와 무슨 상관인가 싶었다. 내가 돌리는 자동화는 많아야 서너 개 봇이 하루에 수십 번 커밋하는 수준이다. 수천 개는 아직 먼 얘기다.

그런데 이건 현재의 내 규모 문제가 아니라 인프라 설계 철학의 문제다. 기존 Git 스토리지는 사람이 하루에 수십 번 푸시하는 것을 기준으로 설계됐다. 에이전트가 초 단위로 커밋을 만들어내면 그 가정이 무너진다. GitHub가 이 가정을 명시적으로 바꿨다는 건, 에이전트 기반 작업 흐름이 단순히 허용되는 것을 넘어서 최적화의 기준점이 된다는 의미다.

내가 가장 신경 쓰이는 부분은 병렬 처리다. 지금은 하나의 봇이 순차적으로 수집, 처리, 커밋, 배포를 한 줄로 처리한다. 이걸 여러 에이전트가 병렬로 나눠서 처리하게 바꾸고 싶었던 적이 있는데, 그때마다 발목을 잡은 게 Git 충돌이었다. 같은 저장소에 여러 프로세스가 동시에 쓰려고 하면 충돌이 나고, 그걸 해결하는 로직이 오히려 복잡해진다. 순차 실행이 단순하고 안전하다는 이유로 계속 그 방식을 유지해왔다.

스토리지 레이어가 그 충돌을 흡수하는 방향으로 설계된다면, 병렬 에이전트 구조로의 전환이 덜 무서운 선택이 된다. 구체적인 메커니즘은 블로그 글을 직접 읽어봐야 안다. 요약만으로는 내부 동작을 추정하기 어렵고, 단정하면 틀린다.

에이전트가 누구인지 서버는 모른다

Cloudflare 글의 제목이 재미있다. "에이전트는 사람이 아니다, 하지만 어느 정도는 그렇다." 이 모호함이 지금 자동화를 돌리는 사람들이 매일 부딪히는 현실이다.

에이전트는 사용자 대신 행동하지만, 서버 입장에서는 그 에이전트가 어떤 권한을 위임받았는지, 실제 사용자가 누구인지 보이지 않는다. Cloudflare가 소개한 "협업적 접근"이 구체적으로 어떤 형태인지는 직접 읽어봐야 알겠지만, 이 문제를 공식 의제로 올렸다는 것 자체가 의미 있다.

내가 운영하는 봇들이 외부 API를 호출할 때, 그 API 입장에서 내 봇은 그냥 하나의 HTTP 클라이언트다. 사람이 직접 쓰는 건지, 자동화된 에이전트인지 구분하지 않는다. 그러다가 속도 제한에 걸리거나, 이상 트래픽으로 분류돼서 차단되는 경우가 종종 있다. 반대로 에이전트임을 명시했더니 더 엄격하게 걸러진 경험도 있다. 뭐가 맞는 건지 기준이 없으니 그때그때 눈치를 봐야 한다.

에이전트가 위임받은 권한을 어떻게 증명하느냐, 서버가 그걸 어떻게 검증하느냐. 이게 표준화된다면 내 봇도 "이 요청은 사용자의 허가를 받은 에이전트가 보낸 것"이라는 맥락을 담을 수 있게 된다. 지금은 그냥 API 키 하나로 모든 걸 처리한다. 그 단순함이 편하긴 한데, 에이전트가 여러 단계로 체인처럼 연결될수록 그 단순함이 오히려 취약점이 된다.

Cloudflare가 신뢰 위임 모델을 인프라 수준에서 다루기 시작했다면, 비슷한 움직임이 다른 플랫폼에서도 나올 것이다. 그 표준이 어느 방향으로 굳어지느냐에 따라 에이전트 인증 방식을 처음부터 다시 설계해야 할 수도 있다. 미리 알아둬서 나쁠 건 없다.

스케줄링이 플랫폼 안으로 들어온다

Vercel Schedules 퍼블릭 베타 소식은 조용하지만 실용적이다.

cron 작업을 플랫폼에서 직접 관리한다는 개념. 스케줄링은 자동화에서 가장 번거로운 부분 중 하나인데, 서버에서 직접 cron을 돌리면 실패 감지가 약하다. 뭔가 조용히 죽어있어도 로그를 뒤지기 전까지 모른다. 외부 스케줄링 서비스를 붙이면 또 하나의 의존성이 생기고, 뭔가 잘못됐을 때 원인을 추적할 대상이 하나 더 늘어난다.

배포 플랫폼이 스케줄링을 흡수하면, 적어도 "어떤 코드가 언제 실행되는지"를 한 곳에서 볼 수 있다. 배포 로그와 실행 로그가 같은 대시보드에 있다는 것만으로도 디버깅이 편해진다. 세밀한 간격을 지원하는지, 실패 재시도 정책이 어떤지, 타임아웃 설정은 어떻게 하는지는 직접 돌려봐야 판단이 선다. 베타 기능이면 더더욱 써봐야 안다.

지금 운영하는 자동화 중 Vercel에 올라간 것들이 있다. 그 쪽 스케줄링을 쓸 수 있다면 별도 cron 서버를 줄일 수 있는지 검토해볼 만하다. 모든 걸 한 플랫폼으로 모으는 게 항상 좋은 건 아니지만, 단순성의 가치가 있는 경우도 있다.

같은 방향을 가리키는 것들

지금 당장 뭔가를 바꿔야 한다는 얘기가 아니다.

GitHub의 스토리지 아키텍처가 에이전트 대규모 동시 쓰기를 최적화 기준으로 삼았고, Cloudflare가 에이전트 신뢰 위임을 인프라 의제로 올렸고, Vercel이 스케줄링을 플랫폼 기능으로 흡수했다. 각자 다른 레이어의 움직임인데, 방향이 같다. 에이전트가 작업 흐름의 주체가 되는 것을 플랫폼들이 가정하기 시작했다.

그 가정이 공유될수록, 에이전트를 중심으로 파이프라인을 짜는 선택이 덜 이상한 것이 된다. 지금은 "안정적이니까 순차 실행"이라는 이유로 보수적으로 가고 있는데, 그 보수성의 근거 일부가 인프라 제약이었다면 조금씩 다시 생각해볼 여지가 생긴다.

인프라가 에이전트를 기본값으로 받아들이는 속도가 생각보다 빠르다.

참고한 글

• Inside GitHub's new Git storage architecture - https://github.blog/engineering/architecture-optimization/inside-githubs-new-git-storage-architecture/
• Agents aren't humans (but they kinda are) - https://blog.cloudflare.com/trusted-agent-delegation/
• Vercel Schedules is now in public beta - https://vercel.com/changelog/vercel-schedules-is-now-in-public-beta
• Claude Code sends your email address to websites - https://github.com/anthropics/claude-code/issues/107757

한 가지 더 붙여둔다. 에이전트 신뢰 모델을 얘기하는 사이, Claude Code가 작업 중 접근한 웹사이트에 사용자 이메일을 함께 전달한다는 이슈가 GitHub에 올라왔다. 에이전트가 올바른 권한을 위임받는 것과, 그 과정에서 불필요한 정보를 흘리지 않는 것은 별개의 문제다. Cloudflare가 신뢰 위임 프레임을 설계한다 해도, 클라이언트 쪽에서 이런 식으로 새면 그 프레임 자체가 의미를 잃는다.

지금 쓰는 버전부터 확인해야겠다.