Realtime multiplayer, automation, and you! — Idan Gazit, GitHub

URL: https://youtube.com/watch?v=iQ5xldZ9StU 날짜: 2026-08-08 (업로드) / 2026-08-09 (처리) 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

AI로 인해 코드 작성의 한계 비용이 0에 가까워지고, 시장과 기술이 매주 변하는 상황에서 우리는 무엇을 만들고, 어떻게 협업해야 하는가?

• GitHub Next의 임무는 단순히 내일의 GitHub이 아니라 1~2년 뒤의 소프트웨어 제작 도구를 미리 탐구하는 것이다.
• 이 문제는 더 이상 연구팀만의 문제가 아니라 모든 개발자, PM, 디자이너의 문제가 되었다.
• GitHub Next는 이 문제를 두 가지 지속 가능한 주제로 접근한다: ==자동화(Agentic Workflows)==와 ==실시간 협업(Aces)==.

AI가 개인 생산성을 100배 높여도 진정한 가치는 ‘더 많은 나를 만들어내는 것’이 아니라, 여러 사람이 함께 더 많은 일을 할 수 있도록 지원하는 데서 나온다. 이 영상은 이 두 가지 큰 주제를 GitHub Next에서 실제로 구현한 두 프로토타입으로 보여주고, 에이전트와 인간의 새로운 협업 관계를 전망한다.

---

1. 서론: 왜 지금 ‘미래의 도구’를 고민하는가

[이 섹션의 핵심 주장] GitHub Next의 일은 다음 주가 아니라 내년, 내후년의 GitHub을 설계하는 것이며, AI 시대에는 모든 팀이 ‘연구팀’이 되어 무엇에 시간을 쓸지 결정해야 한다.

1.1. GitHub Next란 무엇인가

1. 조직의 정체성

   1. ‘농담하고 결과를 확인하는 부서’: 발표자 Idan Gazit은 자신의 팀을 농담으로 부르지만, 실제 이름은 GitHub Next, 즉 GitHub의 랩스(Labs) 팀이다.
   2. Copilot의 탄生地: 이 팀이 Copilot을 만들었고, 이후 스펙 기반 프로그래밍, 자연어→앱 변환 등 여러 영역을 개척해 왔다.
   3. 완성품이 아닌 미래 탐구: 모든 프로젝트가 제품이 되는 것은 아니며, 핵심 임무는 미래를 탐색하고 파악하는 것이다.

2. 공개적인 작업 방식

   1. githubnext.com: 대부분의 작업이 공개되어 있으며, 누구나 살펴볼 수 있다.
   2. 소셜 미디어: 가끔 SNS에도 공유하지만, Idan은 가끔 잊는다고 농담한다.
   3. 연구가 아닌 메이킹: 미래를 예측하는 유일한 방법은 직접 만들어보는 것이므로, 이 팀은 ‘만들기’를 연구 방법으로 삼는다.

1.2. ‘무엇을 만들 것인가’라는 기회비용 문제

1. 방향성 없는 연구의 어려움

   1. 무제한 자원도 기회비용은 존재: Idan은 “심지어 토큰 억만장자이고, 10대의 단말에서 페이블(Fable)을 밤낮으로 돌려도 기회비용은 여전하다”고 말한다.
   2. 시장의 소음과 기술의 빠른 변화: 매주 기술이 바뀌는 상황에서 어떤 문제가 중요한지 선택하기 어렵다.
   3. 이제는 모두의 문제: 이 문제는 GitHub Next만의 고민이 아니라, AI를 쓰는 모든 팀의 공통된 고민이 되었다.

2. 지속 가능한 주제(Durable Themes) 찾기

   1. 미래 기술과 무관한 진실: 기술이 어떻게 변하든 변하지 않을 원칙을 찾는다.
   2. 이 시대의 주제: AI가 개인 생산성을 폭증시키고, 이제는 협업과 조직의 규모 확장으로 가치가 이동하고 있다.
   3. 두 가지 렌즈: GitHub Next는 자동화(Automation)와 협업(Collaboration)이라는 두 지속 가능한 주제를 통해 이 문제를 푼다.

---

2. 자동화: Agentic Workflows

[이 섹션의 핵심 주장] 에이전트 시대의 자동화는 사람이 매일 하던 판단형 업무를 마크다운 문서로 선언하고, 강력한 가드레일 안에서 백그라운드로 실행하는 것이다.

2.1. 동기: 개인 웹사이트의 Astro 업그레이드 문제

1. Astro의 빠른 릴리스

   1. 한 달 50개의 새 기능: Idan의 개인 웹사이트는 Astro 프레임워크로 만들어졌는데, Astro가 매우 빠르게 업데이트된다.
   2. Dependabot의 한계: Dependabot은 구식 라이브러리를 알려주지만, 실제 업그레이드는 코드 변경이 필요하다.
   3. 원하는 것: “항상 그 자리에 있으면서 백그라운드에서 의존성을 살피고, 코드 변경까지 포함해 업그레이드 PR을 만들어주는 슈퍼 Dependabot”.

2. Copilot으로 에이전트 워크플로우 만들기

   1. 마법 같은 한 줄: Idan은 파일 맨 위에 “에이전트 워크플로우를 만들어 보세요. 필요한 정보는 여기 문서에 있습니다.”라고 적은 스킬을 추가했다.
   2. 주니어 개발자에게 보내는 슬랙 메시지 형태: “매일 새 릴리스가 있는지 확인하고, 변경 로그와 문서를 보고, 업그레이드 계획을 세운 뒤 PR을 만들어라. 문서 링크는 여기.”
   3. 실제로 플레이북 생성: Copilot이 이 짧은 메시지를 바탕으로 전체 플레이북을 만들어냈다.

2.2. Agentic Workflow의 구조: 마크다운이 소스 코드

1. 마크다운 문서처럼 생긴 워크플로우

   1. GitHub Actions + Copilot의 결합: 마크다운으로 작성하고, GitHub Actions 워크플로로 컴파일되어 실행된다.
   2. 업그레이드 검사기 예시: 1) 새 릴리스 확인, 2) 변경 로그/업그레이드 가이드 검토, 3) 업그레이드 적용, 4) PR 생성.
   3. 코드베이스를 보고 추론: 에이전트가 프로젝트를 보고 어떤 종속성을 확인해야 할지 직접 추론한다.

2. YAML 프런트 매터: 가드레일

   1. 권한 명시: 읽기/쓰기 권한, 사용 가능한 도구, 허용된 네트워크 요청을 YAML에 명확히 기술한다.
   2. 안전장치는 에이전트에게 맡기지 않는다: “비트코인을 사지 마”라고 프롬프트만 주는 것은 부족하다. 누군가 프롬프트 주입으로 에이전트를 다른 방향으로 돌릴 수 있기 때문이다.
   3. 허용된 웹사이트 제한: NPM 생태계, GitHub, Astro 문서만 방문할 수 있도록 지정.
   4. Safe Outputs: 에이전트가 생성할 수 있는 출력을 제한한다. 예를 들어 PR은 한 개만 생성할 수 있다.
   5. “아무것도 하지 않는 것”도 허용: 불필요한 노이즈를 방지하기 위해, 할 일이 없으면 아무것도 하도록 명시한다.

2.3. 실제 실행 결과: Astro 5 → 7 업그레이드

1. 마이너 릴리스 업그레이드

   1. 릴리스 노트 요약: 현재 버전에서 목표 버전으로의 주요 변경 사항을 요약했다.
   2. 호환성 확인: 프로젝트를 빌드하고 실행해 깨지는 변경 사항이 없음을 검증했다.
   3. 프리뷰 배포로 최종 확인: Cloudflare 프리뷰 링크를 열어 웹사이트가 변함없이 작동함을 확인했다.

2. 메이저 업그레이드: Astro 5 → 7

   1. 두 메이저 버전 건너뛰기: Astro 7 출시를 이용해 5에서 7로 두 단계 업그레이드.
   2. 깨진 코드 수정: Astro 7에서 발생하는 모든 코드 변경 사항을 찾아내고 수정.
   3. 빌드 검증: 빌드가 정상적으로 실행되는지 확인.
   4. 수동 단계 강조: 나중에 Idan이 직접 해야 할 수동 작업 단계도 문서에 표시.

2.4. Agentic Workflow 라이브러리와 보안 원칙

1. 기본 제공 워크플로우 라이브러리

   1. Issue Triager: 이슈를 분류하고, 필요한 정보가 부족하면 요청하고, 내부적으로는 GitHub 자체 이슈 분류 시스템의 기초가 되었다.
   2. Repo Assist: 여러 워크플로우가 프로젝트 유지보수를 돕는 스웜. 쉽게 해결할 수 있는 문제를 찾아 수정하고, 피드백이 필요한 티켓을 식별한다.
   3. CI Doctor: 실패한 CI를 단순히 재실행하는 대신, 원인을 파악하고 조치한다.
   4. 팀/저장소 현황 보고: 엔지니어와 PM 모두를 위한 자동화. “인터넷에서 숙제를 하듯” 정보를 수집하고 요약한다.

2. 4가지 보안 원칙

   1. 심층 방어(Defense in Depth): 한 겹의 가드레일로는 충분하지 않다.
   2. 비밀 정보는 에이전트에게 맡기지 않는다: 에이전트가 볼 수 있는 비밀은 이미 유출된 것으로 간주해야 한다. 비밀은 에이전트의 구역 밖에 보관되며, 서비스 연락 시 관리자(warden)에게 허가를 요청한다.
   3. 모든 권한 검토 및 기록: 어떤 작업을 했는지 감사 가능하도록 로그를 남긴다.
   4. 홈 어시스턴트 사례: 오픈소스 프로젝트 Home Assistant의 첫 워크플로우는 제출된 이슈의 Python 스택 트레이스를 따라 버그가 자사 코드인지 타사 코드인지 판단한 뒤, 타사 문제면 닫는 기능이었다. 이는 휴리스틱으로는 불가능했던 일이다.

3. 공개 미리보기 및 의미

   1. 오늘부터 Public Preview: Agentic Workflows가 이미 공개 미리보기로 제공된다.
   2. 대화형 AI보다 큰 범주: Idan은 백그라운드에서 자동으로 실행되는 자동화가 핵심이라며, 이 범주가 대화형 AI보다 더 클 것이라고 본다.

---

3. 협업: Aces — 실시간 멀티플레이어 소프트웨어 개발

[이 섹션의 핵심 주장] AI 시대의 개발은 ‘계획→개별 코딩→리뷰’가 아니라, 팀이 실시간으로 방향을 함께 정하고 AI가 한 걸음씩 나아가는 멀티플레이어 프로세스가 된다.

3.1. 기존 협업의 전제가 무너지다

1. 코드 작성 비용의 붕괴

   1. 기존: 혼자 짜는 ‘건설’ 단계: 계획과 검토는 함께했지만, 코딩은 모니터 불빛 아래 혼자 했다.
   2. 이제: 모두가 함께: 계획은 사전이 아니고, 리뷰는 사후가 아니다. 방향을 함께 정하고 AI가 한 단계를 밟으면, 그 방향으로 다시 함께 정한다.
   3. 속도가 빨라지면서 생기는 리스크: 작은 오차가 눈덩이처럼 커져 엄청난 작업 낭비로 이어진다. 이제 그 작업은 토큰을 소모하고, 토큰은 돈이 된다.

2. Slack과 같은 인터페이스가 필요한 이유

   1. 코드에 담기지 않은 사실: 코드 안의 사실은 에이전트가 읽을 수 있다. 하지만 정치적 고려, “부사장님이 이 방향을 좋아하실 거야”, “보라색이 좋아하시는 색이야”, “Azure에서 인프라를 저렴하게 쓸 수 있어” 같은 사실은 코드에 없다.
   2. 같은 표면에서 창작과 협업: 이메일보다 Slack이 좋은 것처럼, 코드에 대한 창작과 협업도 같은 공간에서 이루어져야 한다.

3.2. Aces의 기본 구조

1. Slack처럼 보이는 개발 환경

   1. 왼쪽의 세션 목록: Aces의 UI는 Slack처럼 생겼으며, 세션을 만들고 선택할 수 있다.
   2. 클라우드의 마이크로 VM: 각 세션은 개발자의 머신이 아니라 클라우드의 마이크로 VM에서 실행된다.
   3. 브랜치 = 세션: 각 세션은 저장소의 브랜치를 클라우드의 특정 위치에 체크아웃한 것과 같다.

2. 자연어로 동료와 에이전트에게 동시에 지시

   1. 대화 기록 기반 행동: 팀원과 색깔에 대해 길게 대화한 뒤, Idan은 “야, Ace, 해봐!”라고 한 마디만 했다. Aces는 대화 전체를 이해하고 그에 맞게 UI를 변경했다.
   2. 엔지니어 대화의 최종 상태 추론: “이렇게 해보자”, “아니 edge case 생각났어”, “처음 생각으로 돌아가자” 같은 대화를 AI가 정리해 최종 상태를 찾아낸다.
   3. 로봇을 위해 일하지 않는다: AI가 대화의 최종 상태를 파악하므로, 개발자는 지시를 다시 정리할 필요가 없다.

3.3. 공동 편집 가능한 계획 문서

1. 마크다운 문서로 공유된 계획

   1. 앱에 시간대 선택 기능 추가: Idan은 Aces에게 계획을 세워달라고 요청했고, 계획이 마크다운 문서로 나왔다.
   2. 팀원과 동시 편집: Russ는 “전체 기간”을 추가하고, Idan은 “오늘”을 없애고, “계획을 업데이트했습니다”라고 작성한다. 이 문서는 둘 다 보며 수정한다.
   3. 문서를 사실로 만들기: “이 문서를 사실로 만들어 줘”라고 말하면, AI가 공동 편집된 계획에 따라 코드를 변경한다.

2. 문서 중심 개발의 미래

   1. docs 폴더에 쌓이는 진실: AI와 함께 하는 작업 결과물이 마크다운 문서 형태로 저장되어, 프로젝트의 진실을 담는다.
   2. 개발 방식의 변화: 앞으로는 코드를 직접 고치기보다 문서를 편집하고 AI에게 “이 문서를 사실로 만들어 줘”라고 할 수 있다.
   3. 공유 문서 편집은 nice-to-have가 아니다: 이것이 우리가 실제로 선호하는 작업 환경이 될 가능성이 높다.

3.4. 소셜 코딩과 주변 인식(Ambient Awareness)

1. 팀원이 무엇을 하는지 파악하기

   1. 실시간 멀티플레이어만으로는 부족: 다른 사람들이 어떤 이야기를 하고 있는지 주변 상황도 알아야 한다.
   2. 팀 현황 대시보드: Kristoff는 Vian 툴링 작업을, Maggie는 대시보드를 작성하고, David는 다른 작업을 하고 있다. Aces는 이 모든 활동을 보여준다.
   3. 하드코딩된 이름: Maggie가 대시보드에 자신의 이름을 하드코딩했기 때문에 Idan은 “Maggie의 이름”을 보고 있다고 농담한다.

2. 자동화의 자연스러운 통합

   1. 에이전트가 어깨를 톡톡 두드리는 경험: Idan은 자동화 시스템과 대화하고 싶을 때, 에이전트가 대화 인터페이스에서 질문을 던지는 상황을 상상한다.
   2. Aces는 미래의 협업 인터페이스 실험: 이달 말 기술 프리뷰로 제공될 예정이며, 실시간 협업과 에이전트 자동화가 결합된 형태를 탐구한다.

---

4. 결론: 에이전트와 인간의 역전된 관계

[이 섹션의 핵심 주장] AI가 타이핑을 도왔던 5%의 영역을 넘어, 나머지 95%의 비타이핑 업무를 처리하는 시스템을 만들어야 한다. 그 핵심은 에이전트가 목표를 더 명확히 이해할수록 우리를 덜 필요로 하게 되는 ‘역전된 관계’에 적응하는 것이다.

4.1. 5% vs 95%의 문제

1. 타이핑은 업무의 5%에 불과

   1. 수천 시간의 연구: 100명의 개발자를 대상으로 수천 시간에 걸쳐 진행된 장기 연구 결과, 키보드를 직접 사용하는 시간은 전체의 5%에 불과했다.
   2. AI가 나머지 95%를 도와야 한다: 지금까지 AI는 타이핑을 도왔지만, 이제는 탐구, 의사결정, 협업, 조직 확장 등 나머지 영역을 도와야 한다.
   3. 새로운 질문: 내가 조작하고 싶은 시스템은 어디에 있고, 어떻게 작동하는가? 다른 사람들은 그것을 어떻게 변형해야 한다고 생각하는가?

2. Agentic Workflows와 Aces의 역할

   1. Agentic Workflows: 자동화를 통해 개인과 팀의 시간을 벌어주고, 산업 규모의 확장을 가능하게 한다.
   2. Aces: 실시간 협업 인터페이스를 통해 팀이 함께 방향을 정하고, AI가 한 단계씩 실행하는 새로운 개발 문화를 만든다.
   3. 확장된 가치: 단순히 5%의 코딩 효율을 높이는 것이 아니라, 지금까지 모든 도구가 도왔던 그 정도의 성과를 나머지 95%에도 가져와야 한다.

4.2. 에이전트와 인간의 새로운 관계

1. 목표를 명확히 할수록 에이전트는 우리를 덜 필요로 한다

   1. 더 나은 모델: 모델이 좋아질수록, 미정의된 동작을 찾아내고 우리에게 설명을 요청한다.
   2. 필요할 때 손을 요청: 에이전트가 도움이 필요할 때만 인간을 호출하고, 그 외에는 스스로 실행한다.
   3. 인터페이스의 변화: 인터페이스는 이제 에이전트가 모든 것을 수신하고, 필요할 때 인간을 호출할 수 있도록 설계되어야 한다.

2. 두 접근법이 같은 지점에 도달

   1. 자동화와 협업의 수렴: Agentic Workflows와 Aces는 다른 방향에서 시작했지만, 에이전트가 주변을 듣고 필요할 때 인간을 부르는 같은 지점에 도달한다.
   2. 역전된 관계의 수용: 우리는 에이전트를 위해 일하지 않고, 에이전트가 우리의 목표를 위해 일하도록 방향을 제시하는 역할을 맡게 된다.

4.3. 행동 제안 및 마무리

1. 지금 할 수 있는 일

   1. Agentic Workflows 사용: 이미 공개 미리보기이므로, 이슈 분류, CI 복구, 의존성 업그레이드 등에 적용해 본다.
   2. Aces 기술 프리뷰 기대: 이달 말 기술 프리뷰가 예정되어 있으니, 실시간 멀티플레이어 개발 환경을 직접 체험해 본다.
   3. GitHub Next에 피드백: githubnext.com과 Microsoft 부스, SNS를 통해 의견과 사용 사례를 공유한다.

2. 발표자의 마지막 메시지

   1. 우리는 모두 연구팀: AI 시대에는 모든 팀이 자동화와 협업의 미래를 탐구하는 연구팀이 되었다.
   2. 지속 가능한 주제에 집중: 시장이 소란해도, 미래 기술과 무관한 진실에 기반을 두고 무엇을 만들지 선택해야 한다.
   3. 감사 인사: Idan은 청중에게 감사 인사를 전하며, 마이크로소프트 부스와 GitHub Next 채널에서 추가 대화를 초대한다.

---

주요 발언 모음

“우리의 임무는 내일의 GitHub이 아니라, 내년의 GitHub, 1년 뒤 2년 뒤 우리가 소프트웨어를 만드는 데 사용할 도구를 향해 나아가는 것입니다.” “이제는 모든 사람이 연구실 팀이에요. 다음 세대가 이러한 문제에 대해 생각하는 방식은 지속 가능한 주제를 찾는 것입니다.” “가장 큰 가치는 나를 더 많이 만들어내는 데서 오는 것이 아닙니다. 이는 여러 사람이 모여 더 많은 일을 할 수 있도록 지원하는 데서 비롯됩니다.” “모든 산업혁명은 자동화를 통해 일어났습니다. 우리의 거대한 소프트웨어 산업이 산업화 이전 시대와 비슷하다는 생각을 하면 우습지만, 어느 정도는 맞습니다.” “자동화가 많은 환경에서는 불필요한 노이즈가 발생하는 것을 원치 않습니다. 에이전트가 서비스 거부 공격을 하는 것을 막고 싶습니다.” “에이전트에게 ‘비트코인을 사지 마’라고 말하는 것만으로는 충분하지 않습니다. 누군가 에이전트에 특정 명령어를 주입할 수 있기 때문입니다.” “우리가 에이전트에게 우리의 목표를 더 명확하게 설명할수록, 그들은 우리를 덜 필요로 하게 됩니다.” “과거 몇 년 동안 AI는 제 타이핑을 도왔습니다. 하지만 키보드 사용은 전체 업무의 약 5%에 불과합니다. 이제 AI는 나머지 95%를 처리해야 합니다.”

핵심 데이터 & 수치

• 5%: 장기 연구에 따르면 개발자가 키보드로 직접 타이핑하는 시간은 전체 업무의 5%에 불과하다.
• 50개/월: Astro 프레임워크는 한 달에 약 50개의 새로운 기능을 출시한다.
• Astro 5 → 7: Agentic Workflows 데모에서 두 메이저 버전을 건너뛰는 업그레이드를 자동으로 처리했다.
• 2가지 프로토타입: Agentic Workflows(자동화)와 Aces(실시간 협업).
• 4가지 보안 원칙: 심층 방어, 비밀 맡기지 않기, 권한 검토 및 감사, Safe Outputs.
• Public Preview: Agentic Workflows는 이미 공개 미리보기 가능. Aces는 이달 말 기술 프리뷰 예정.

결론 및 시사점

1. AI의 다음 단계는 개인 생산성을 넘어 팀과 조직의 생산성을 확장하는 것이다.
2. GitHub Next는 ‘자동화’와 ‘협업’이라는 두 지속 가능한 주제로 이 변화를 탐구하고 있다.
3. Agentic Workflows는 강력한 가드레일 안에서 마크다운 기반의 백그라운드 자동화를 가능하게 한다.
4. Aces는 코드 작성이 클라우드 마이크로 VM에서 실시간으로 이루어지는 멀티플레이어 개발 환경을 제안한다.
5. 에이전트와 인간의 관계가 역전되고 있으며, 인간은 목표를 명확히 제시하고 필요할 때만 개입하는 역할을 맡게 될 것이다.
6. 95%의 비타이핑 업무를 AI가 도울 수 있는 시스템을 설계하는 것이 앞으로의 핵심 과제이다.