저장소에 마크다운으로 할 일을 적으면 AI가 이슈를 분류하고, 실패한 CI를 조사하고, 문서를 고칩니다. GitHub가 10월 28일 정식 출시한 Agentic Workflows의 출발점입니다. 그런데 반복 작업을 맡긴 뒤에는 다른 질문이 생깁니다. 무엇을 실행하도록 허용했는지, 결과가 어긋나면 어디를 고쳐야 하는지 말입니다. GitHub 발표

13호는 10월 27일~11월 1일 KST에 나온 소식 가운데 자동화, 모델 운영, 웹사이트의 학습 선호 표현, CI를 골랐습니다. 자료 확인 마감은 11월 1일 18:29 KST입니다. 아래 사실은 모두 03 · 공식 확인으로, 개발사의 발표·문서를 확인한 수준입니다. 제품 동작이나 성능을 직접 재현하지 않았습니다. 마지막 ‘L-Proof의 해석’은 그 사실을 바탕으로 한 별도 판단입니다.

GitHub — 마크다운으로 반복 작업을 정의하고 Actions에서 실행한다

GitHub Agentic Workflows는 이슈 분류, CI 실패 분석, 문서 갱신 같은 작업을 자연어 마크다운 파일로 정의하고 표준 GitHub Actions YAML로 컴파일합니다. 기존 Actions의 러너와 조직 정책을 이용하며, Copilot 외의 코딩 에이전트도 선택할 수 있습니다. 10월 28일 정식 출시됐고 GitHub Free·Team·Enterprise에서 사용할 수 있지만, 기본 Copilot CLI 엔진을 쓰려면 Copilot 라이선스가 필요합니다. 정식 출시 안내

GitHub가 설명한 기본 경계는 읽기 전용 권한, 격리된 실행 환경, 결과를 적용하기 전 검증 절차입니다. 이번 정식 출시에는 자체 러너 지원과 비용 예측, 작업에 따른 모델 선택도 보강됐습니다. ‘마크다운을 쓴다’는 편리함 뒤에는 컴파일된 워크플로와 실행 권한이 있으므로, 반복 실행할 작업이라면 설명 문장뿐 아니라 생성된 Actions 설정과 적용되는 결과까지 확인해야 합니다. 보호 장치와 변경 사항

Vercel — 모델 이름은 그대로 두고, 실제 모델을 바꾼다

Vercel은 10월 28일 AI Gateway에 Virtual Models를 추가했습니다. 앱이나 에이전트는 vmc/coding-agent 같은 고정 ID를 호출하고, 운영자는 그 뒤에 연결된 모델과 장애 시 대체 모델, 공급자 우선순위, 데이터 보관 조건을 중앙에서 바꿉니다. 호출 코드를 다시 배포하지 않아도 몇 분 안에 새 설정을 적용할 수 있습니다. 출시 글

설정의 우선순위가 핵심입니다. 가상 모델에 정한 공급자 순서나 대체 모델, Zero Data Retention 조건은 개별 요청에서 덮어쓸 수 없다고 Vercel은 설명합니다. 반면 특정 공급자에만 통하는 옵션은 다른 회사 모델로 바꿨을 때 그대로 적용되지 않습니다. Vercel도 운영 중인 ID를 곧장 바꾸기 전에 후보 ID로 평가하라고 권합니다. 같은 이름을 계속 쓰더라도, 그 이름이 가리키는 답의 품질과 비용은 달라질 수 있습니다. 설정과 전환 주의점

OpenAI — 웹사이트의 생성형 AI 학습 선호를 공통 신호로 받겠다고 밝혔다

웹사이트 운영자는 기초 생성형 AI 모델의 학습에 관한 선호를 여러 회사에 전달하려면 각 회사의 크롤러를 따로 관리해야 했습니다. OpenAI는 10월 30일 여러 제공업체가 함께 읽을 수 있는 robots.txt 공통 신호를 존중하겠다고 발표했습니다. IETF의 AI Preferences 논의에 참여하는 흐름이며, 기존 OpenAI 크롤러 제어 방식은 계속 유지됩니다. OpenAI 발표

아직 이 신호가 OpenAI 서비스에 적용됐다는 발표는 아닙니다. 회사는 앞으로 몇 달 안에 구현하고 세부 내용을 다시 알리겠다고 했습니다. 따라서 사이트 설정을 오늘 바꾸면 모든 AI 제공업체의 학습 이용이 즉시 달라진다고 읽어서는 안 됩니다. 운영자가 한 번 표현한 선택을 여러 곳에 전달하려는 방향은 확인됐지만, 실제 적용 시기와 참여 범위는 후속 공지를 봐야 합니다.

Vercel — 코드 변경의 영향을 받은 검사만 실행하는 CI 베타

Vercel CI가 10월 28일 베타로 공개됐습니다. Turborepo의 turbo.json에서 CI 대상 작업을 지정하면, 변경 내용과 작업 간 의존관계를 보고 필요한 검사를 실행합니다. 입력이 달라지지 않은 작업은 캐시 결과를 쓰고, 남은 작업은 각각 필요한 컴퓨팅 자원에서 돌립니다. 단일 패키지 저장소에서도 쓸 수 있으며 모든 요금제에 베타가 열려 있습니다. Vercel 발표

Vercel은 자체 저장소에서 푸시부터 CI 통과까지 걸린 시간이 이전보다 2~6배 빨랐다고 밝혔습니다. 이는 Vercel의 관찰이며 다른 저장소에서 같은 속도를 보장하는 수치는 아닙니다. 검사를 건너뛰는 만큼 어떤 파일과 환경이 작업의 입력인지 정확히 정의하는 일이 중요해집니다. 빠른 ‘통과’ 표시를 얻었을 때는 실제로 어떤 검사가 실행됐고 무엇이 캐시에서 왔는지도 볼 수 있어야 합니다.

L-Proof의 해석

실행 버튼보다 변경 지점이 많아졌다

GitHub의 워크플로는 사람이 작성한 작업 설명을 실행 가능한 Actions로 바꿉니다. Vercel의 가상 모델은 코드에 적힌 ID를 그대로 둔 채 그 뒤의 모델을 바꿉니다. 두 제품 모두 변경을 쉽게 만들지만, 나중에 같은 입력을 다시 실행했을 때 같은 결과가 나오는지 판단하려면 실행 당시의 설정이 필요합니다. 설명 파일만 보거나 모델 ID만 기록하면 중간에 무엇이 바뀌었는지 놓칠 수 있습니다.

그렇다고 모든 실행을 고정하면 모델을 개선하거나 장애를 피하기 어렵습니다. L-Proof는 자동화의 변경 가능성을 없애기보다, 작업별로 바꿀 수 있는 범위를 정하고 결과가 달라졌을 때 원인을 되짚을 수 있게 해야 한다고 봅니다. 예를 들어 모델을 교체한 날 실패율이 올랐다면, 호출 코드는 그대로였다는 사실보다 그 시간에 어느 실제 모델과 설정이 사용됐는지가 먼저 필요합니다. 이 연결을 운영 화면에서 얼마나 쉽게 확인할 수 있는지가 다음 평가 기준입니다.

‘선택했다’와 ‘적용됐다’ 사이

OpenAI의 공통 학습 선호 발표는 그 구분을 웹으로 넓힙니다. 사이트가 선호를 적을 수 있다는 사실과 각 제공업체가 이를 읽고 적용한다는 사실은 다릅니다. 지금은 구현 약속 단계입니다. Vercel CI의 ‘통과’도 모든 검사를 새로 돌렸다는 뜻은 아닙니다. 어떤 검사를 건너뛰었는지와 그 이유가 결과의 일부입니다.

공통점은 선택과 결과 사이에 해석하는 시스템이 있다는 것입니다. 운영자는 선택을 한 뒤에야 그 시스템이 어떤 범위에서 작동했는지 알게 될 수 있습니다. L-Proof가 다음 발표에서 보고 싶은 것은 설정 항목의 수보다, 당시 무엇이 적용됐고 무엇이 적용되지 않았는지를 보여주는 기록입니다.