Collaborative AI Engineering — Maggie Appleton, GitHub Next
📺 원본 영상: Collaborative AI Engineering — Maggie Appleton, GitHub Next 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-04-27 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(데모 화면, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
GitHub Next의 스태프 리서치 엔지니어 Maggie Appleton은 현재 AI 코딩 에이전트 생태계가 개인 생산성의 극대화에만 집중하는 근본적인 설계 결함을 지닌다고 주장한다. 소프트웨어는 혼자 만드는 것이 아니라 팀 스포츠임에도 불구하고, 에이전트 도구들이 팀 정렬(alignment)을 오히려 어렵게 만들고 있다는 것이 강연의 핵심 문제의식이다. 이에 대한 대안으로 GitHub Next가 개발 중인 연구 프로토타입인 ACE(Agent Collaboration Environment)를 소개하며, 계획·맥락 수집·의사결정·개발이 하나의 공간에서 이루어지는 협업형 에이전트 환경의 비전을 제시한다.
개인 생산성 신화의 함정: “아홉 명이 한 달 만에 아기를 낳는다”는 논리
강연은 현재 개발자들 사이에서 유행하는 이미지, 즉 수십 개의 터미널 기반 코딩 에이전트를 한 사람의 머신에서 병렬로 실행하는 장면으로 시작한다. Appleton은 이를 “원맨 투다즌 클로드(One Man, Two Dozen Claudes)” 이론이라고 부르며, 에이전트 군단 하나면 개발팀 전체의 일을 대체할 수 있다는 약속이 이 그림에 담겨 있다고 설명한다.
그러나 이 전제는 소프트웨어가 한 사람에 의해 만들어진다는 잘못된 가정에 기반한다. 모든 현재의 에이전트 도구는 단일 플레이어 인터페이스이며 개인의 산출량을 늘리는 데 초점을 맞추고 있다. 하지만 팀 전체가 무엇을 왜 만드는지에 동의하지 않은 상태에서 개인의 생산성만 높이는 것은 문제를 해결하기는커녕 오히려 악화시킨다. Appleton이 사용하는 비유는 명쾌하다. “아홉 명이 모이면 한 달 만에 아기를 낳을 수 있다”는 논리, 즉 개인의 산출량 합산이 커뮤니케이션과 조율이 필요한 문제를 해결한다는 착각이 바로 그것이다.
진짜 병목은 구현이 아니라 합의다
코드를 작성하는 것, 즉 구현(implementation)은 이제 빠르고 저렴해졌으며 품질도 향상되고 있다. 강연자에 따르면, 이제 어려운 질문은 “어떻게 만드는가”가 아니라 “무엇을 만들어야 하는가”로 이동했다. 무엇을 만들지에 대한 합의(agreeing on what to build)가 새로운 병목이 된 것이다.
생산이 저렴해질수록 기회비용(opportunity cost)이 진짜 비용이 된다. 모든 것을 다 만들 수는 없고, 무언가를 선택한다는 것은 나머지 모든 것을 포기한다는 의미이기 때문이다. 팀의 모든 구성원이 “우리가 옳은 것을 만들고 있는가”, “우리의 에너지가 올바른 곳에 쓰이고 있는가”, “어떻게 가장 큰 임팩트를 낼 수 있는가”라는 질문에 지속적으로 참여해야 한다. 정렬(alignment)이 항상 병목이었다는 사실 자체는 새롭지 않지만, 에이전트의 등장으로 정렬되지 않은 상태에서 치러야 할 비용이 훨씬 더 커졌다는 점이 핵심이다.
에이전트 시대에 어울리지 않는 협업 도구들
GitHub, Slack, Jira, Linear와 같은 현재의 협업 도구들은 에이전트 중심의 개발 세계를 위해 설계되지 않았다. Appleton은 GitHub 소속임에도 불구하고 이 점을 솔직하게 인정한다. PR(Pull Request)과 이슈(Issue)가 소프트웨어 개발의 미래라고 믿는 사람은 GitHub 내부에도 거의 없으며, 많은 이들이 그 다음이 무엇인지 탐색하고 있다고 밝힌다.
과거의 개발 프로세스는 계획(planning), 구현(building), 리뷰(review) 세 단계에 걸쳐 자연스럽게 정렬 지점이 분산되어 있었다. Slack 대화, Zoom 미팅, 이슈 댓글, 초안 PR 등을 통해 팀 전체가 작업의 흐름을 따라갈 수 있었고, 코드가 병합될 때쯤이면 모두가 대략적으로 같은 페이지에 있었다. 구현이 느렸기 때문에 그 사이사이의 커뮤니케이션이 가능했던 것이다.
그런데 에이전트의 등장으로 구현 창구(implementation window)가 극적으로 좁아졌다. 이슈를 로그하고 에이전트가 PR을 여는 데 이제 단 몇 분이면 충분하다. 코드가 너무 저렴해진 나머지 프롬프트를 입력하기 전에 충분히 생각을 멈추지 않게 된다. 설상가상으로 대부분의 코딩 에이전트는 팀과 공유되지 않는 로컬 계획(plan) 모드를 갖고 있어, 에이전트가 세운 계획이 옳은지 팀과 확인하는 과정 자체가 사라진다. 그 결과 정렬의 무게가 전부 PR 위에 쌓이게 된다. 모든 검토가 구현이 끝난 후, 프로세스의 맨 마지막에 이루어지게 되는데, 이는 PR이 원래 수행하도록 설계된 역할이 아니기 때문에 매우 비효율적으로 작동한다.
이렇게 에이전트 없이 빠른 정렬 없이 달려가는 현상은 실질적인 피해를 낳는다. 아무도 요청하지 않은 기능을 만들거나, 완성 후에야 치명적인 피드백을 받아 전부 버려야 하거나, 에이전트들이 같은 파일을 건드려 복잡한 병합 충돌이 발생하거나, 두 개발자가 동일한 작업을 중복으로 진행하거나, 맥락 없이 쌓인 PR 더미를 아무도 리뷰하지 못하는 상황이 벌어진다.
ACE: 에이전트 협업 환경의 비전
이러한 문제의식 아래, GitHub Next 팀이 개발 중인 연구 프로토타입이 바로 ACE(Agent Collaboration Environment)다. Appleton은 아직 프라임타임 제품이 아니며 거친 부분이 있을 수 있다고 솔직히 밝히면서도, 기술 프리뷰(technical preview)를 통해 수천 명을 대상으로 사용자 테스트를 진행할 예정이라고 설명한다.
ACE의 기본 구조는 Slack, GitHub, Copilot, 그리고 클라우드 컴퓨터가 결합된 형태라고 표현된다. 왼쪽에는 세션 목록이 있고, 각 세션은 작업이 이루어지는 공간이다. 단순한 채팅 채널이 아니라, 각 세션은 자체 Git 브랜치를 가진 마이크로 VM(샌드박스 클라우드 컴퓨터)으로 뒷받침된다. 즉 팀원들과 코딩 에이전트가 하나의 멀티플레이어 채팅 공간에서 동시에 작업할 수 있으며, 각 세션의 변경사항은 격리되어 병렬 작업과 즉각적인 전환이 가능하다.
07:19 - ACE 인터페이스 전체 구조 — 세션 목록, 멀티플레이어 채팅, 에이전트 통합 화면
💡 [영상 참조] 강연자는 이 시점부터 ACE의 실제 인터페이스를 직접 시연합니다. 상세 데모 내용은 원본 영상을 확인하세요.
ACE의 핵심 기능: 실시간 협업과 공유 맥락
ACE가 기존 도구들과 다른 첫 번째 특징은 팀원의 작업 맥락에 즉시 접근할 수 있다는 점이다. 다른 팀원의 세션에 합류하면 그들이 에이전트와 나눈 전체 프롬프트 이력을 볼 수 있어, 현재 결과물에 어떻게 도달했는지 맥락을 파악할 수 있다. Git 변경사항을 stash하거나 새 브랜치를 pull할 필요가 없다. 마이크로 VM 아키텍처 덕분에 팀원 모두가 클라우드의 동일한 컴퓨터 위에서 작업하기 때문이다.
08:29 - 에이전트가 색상 테마를 purple로 변경하고 브라우저 라이브 프리뷰에 즉시 반영되는 장면
두 번째 특징은 진정한 멀티플레이어 에이전트 세션이다. 데모에서 Appleton이 세션을 시작했지만 팀원인 Nate가 동일한 에이전트에게 추가 요청을 보낼 수 있었다. 에이전트는 채팅의 전체 대화 내용을 프롬프트 입력으로 읽기 때문에, 팀원들이 서로 논의한 내용을 자연스럽게 지시로 이어받아 처리한다. “이렇게 하자”라는 팀 내 합의가 곧바로 에이전트의 행동 지침이 되는 구조다.
10:04 - 팀원 Nate가 동일 세션에서 에이전트에게 teal 테마 추가를 요청하는 멀티플레이어 장면
세 번째는 Slack 같은 친숙한 인터페이스를 통해 개발자뿐 아니라 디자이너, PM, 고객 지원 담당자까지 소프트웨어 개발 과정에 실시간으로 참여할 수 있다는 점이다. 터미널을 몰라도 기능이 만들어지는 과정을 지켜보고, 의견을 제시하고, 에이전트에게 지시를 내릴 수 있다. Appleton은 이를 두고 Slack이 이 역할을 하지 못하는 이유는 Slack이 소프트웨어 개발 도구로의 전환을 진지하게 시도하지 않는 한 diff, 터미널 명령어 같은 필요한 프리미티브를 갖추지 않을 것이기 때문이라고 설명한다.
11:40 - ACE에서 VS Code를 열어 실시간 멀티플레이어 편집을 하는 화면 (마이크로 VM 공유 환경)
공유 계획(Plan)과 협업적 의사결정
ACE의 또 다른 주요 기능은 복잡한 기능을 구현할 때 에이전트가 계획서를 작성하고, 팀 전체가 그 계획서를 실시간으로 함께 편집할 수 있다는 것이다. 강연의 데모에서 팀원들이 각자의 커서로 동일한 계획 문서를 수정하는 장면이 등장한다. 팀원 Nate가 인터페이스 구현 방식에 대한 대안을 제안하고, 이를 계획서에 반영하면 에이전트가 이 맥락을 바탕으로 작업을 진행한다. 이렇게 계획·토론·구현이 하나의 흐름으로 연결되는 것이 기존 도구 체계와 근본적으로 다른 점이다.
12:37 - 에이전트가 생성한 계획서를 팀원들이 실시간으로 커서를 공유하며 협업 편집하는 화면
세션 우측 상단의 요약 블록(summary block)도 주목할 만하다. 이 기능은 자신이 시작하지 않은 세션을 포함해 병렬로 진행되는 여러 세션의 최신 변경사항을 요약해 제공한다. 팀원이 수십 개의 세션을 넘나들더라도 각 세션에서 무슨 일이 일어나고 있는지 쉽게 파악할 수 있도록 돕는다.
09:03 - 세션 우측 상단 요약 블록(summary block)이 최신 변경사항을 표시하는 화면
대시보드: 팀의 사회적 맥락을 에이전트가 요약하다
ACE의 대시보드는 이 도구의 비전을 가장 잘 보여주는 기능 중 하나다. Slack, GitHub, Linear에서 분산되어 오가던 계획과 논의가 이제 ACE 세션 안에서 이루어지기 때문에, 에이전트는 팀 전체의 작업 흐름에 대한 풍부한 맥락(rich context)에 접근할 수 있다.
월요일 아침 대시보드를 열면 지난 주 금요일에 마무리하지 못했던 작업을 상기시켜 주고, 팀원들이 최근 며칠 동안 무엇을 했는지 요약해서 보여준다. 원시 이슈와 PR 피드도 있지만 Appleton은 에이전트가 정리한 요약이 훨씬 유용하다고 언급한다. 에이전트 개발 환경에서 팀원들이 하루에 다섯 가지 기능을 출시하는 속도를 인간이 따라잡기란 사실상 불가능하기 때문이다. 에이전트가 사회적 정보 패브릭(social information fabric)에 접근함으로써 매일 아침 팀 전체를 재정렬시키고, 내가 만든 기능을 다른 팀원이 확장하려 할 때 알림을 보내거나 관련 대화로 끌어들이는 역할을 할 수 있다는 것이 Appleton의 구상이다.
13:11 - ACE 대시보드 — 개인 미완료 작업 알림, 팀원 활동 요약(team pulse), 최근 PR/이슈 피드 화면
에이전트 시대가 돌려준 시간: 더 잘 만들 기회
강연의 마지막 부분은 기술적 논의를 넘어 더 본질적인 이야기로 향한다. 코딩 에이전트가 등장하기 전, 개발자들은 구현에 너무 많은 시간과 에너지를 쏟아부었기 때문에 사용자 리서치를 충분히 하거나, 디자인 디테일을 고민하거나, 아키텍처 선택의 함의를 깊이 생각하기 어려웠다. 원해서가 아니라, 단순히 시간이 없어서였다.
에이전트는 그 시간을 일부 돌려주었다. Appleton은 이 시간을 단순히 같은 수준의 소프트웨어를 더 빨리 더 많이 만드는 데 쓰는 것이 아니라, 더 깊은 비판적 사고와 더 나은 계획으로 훨씬 더 좋은 소프트웨어를 만드는 데 써야 한다고 역설한다. 빠르고 저렴한 소프트웨어가 범람하는 세계에서는 품질이 새로운 차별점이 된다. 장인 정신(craftsmanship)이 바이브(vibe)로만 짜인 조악한 코드와 자신을 구분 짓는 기준이 된다. 하지만 장인 정신은 시간과 에너지를 요구하며, 그 시간과 에너지를 확보하려면 더 적은 것을 더 잘 해야 하고, 그러기 위해서는 강력한 팀 정렬이 필요하다.
마무리: 협업하는 에이전트 환경이 소프트웨어의 미래다
Appleton의 결론은 명확하다. ACE든 다른 도구든, 팀이 어려운 문제를 함께 엄밀하게 사고할 수 있는 환경을 만드는 것이 에이전트 시대 도구의 진정한 목표여야 한다. 에이전트 도구는 개인이 더 빨리 실행하도록 돕는 것이 아니라, 팀이 더 높은 품질의 작업을 하고, 더 빠르게 정렬하고, 수천 개의 조악한 것 대신 몇 가지 탁월한 것을 만들 수 있도록 도와야 한다.
수십 개의 솔로 에이전트가 각자의 터미널에서 단절된 채로 돌아가는 모습이 아니라, 팀 전체가 같은 작업 공간과 맥락을 공유하는 살아있는 지능형 환경. 그것이 Maggie Appleton과 GitHub Next가 그리는 개발의 미래다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Collaborative AI Engineering — Maggie Appleton, GitHub Next |
| 채널 | AI Engineer |
| 강연자 | Maggie Appleton (GitHub Next, Staff Research Engineer) |
| 리포트 작성 | 2026-04-27 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.