
풀 리퀘스트를 여는 에이전트
GitHub에 따르면 풀 리퀘스트의 40퍼센트 이상을 에이전트가 시작합니다. 이제 부족한 일은 코드를 쓰는 것이 아니라 명세하고, 검토하고, 테스트하고, 책임지는 것입니다.
10월 28일 GitHub는 플랫폼 전반의 활동에 관한 연례 보고서 Octoverse를 발표했으며, 그 가운데 한 줄이 눈에 띕니다. 2026년 9월 기준으로 GitHub 풀 리퀘스트의 40퍼센트 이상이 에이전트의 첫 초안에서 시작되었으며, 3월의 17퍼센트에서 늘어난 수치입니다. 9월 한 달에만 1억 1000만 건의 풀 리퀘스트였습니다. 같은 날 Universe 콘퍼런스에서 GitHub는 Copilot Projects를 공개 프리뷰로 내놓고 Agentic Workflows를 정식 출시했습니다.
일주일 뒤 Meta는 여러 코딩 에이전트를 동시에 실행하도록 만들어진 스타트업 Conductor를 인수했습니다. 이 소식들은 한 방향을 가리킵니다. 코드를 쓰는 일은 더 이상 소프트웨어 제작에서 부족한 부분이 아닙니다. 부족한 것은 코드를 명세하고, 검토하고, 테스트하고, 책임지는 일입니다.
GitHub가 센 것
이는 GitHub가 자체 플랫폼에서 측정한 자체 수치이며, 그렇게 읽어야 합니다. Octoverse는 GitHub가 감지할 수 있는 코딩 에이전트가 첫 초안을 만든 풀 리퀘스트를 에이전트가 시작한 것으로 집계하며, 보고서는 이 신호를 “모든 에이전트 사용이 감지되지는 않을 수 있으므로 하한선”이라고 부릅니다. 공개 및 비공개 저장소를 모두 포함하며, 이전 연도의 수치도 같은 기준으로 다시 계산되었습니다.
보고서는 또 에이전트 풀 리퀘스트가 이제 나머지 풀 리퀘스트와 적어도 같은 비율로 병합된다고 말합니다. 2월에는 에이전트가 관여한 풀 리퀘스트의 83퍼센트가 2주 안에 병합되었고, 에이전트가 감지되지 않은 풀 리퀘스트는 약 86퍼센트였습니다. 9월에는 에이전트 쪽 비율이 90퍼센트에 이르렀습니다. 범위도 더 넓습니다. 약 87퍼센트가 두 개 이상의 파일을 변경하며, 나머지는 79퍼센트입니다. 저희가 읽기에 병합은 검토자가 변경을 받아들였다는 뜻이지, 그 변경이 옳았다는 뜻은 아닙니다.
한 사람당 더 많은 에이전트
GitHub가 같은 날 내놓은 제품들은 이 비율이 계속 커질 것을 전제로 합니다. Copilot Projects는 여러 저장소에 걸친 작업에 맥락, 에이전트, 결과를 모아 두는 하나의 공간을 제공합니다. 목표를 설명하면 Copilot이 에이전트를 병렬로 실행하고, “사용자가 필요할 때 확인을 요청하며”, 검토할 풀 리퀘스트 같은 결과를 가져옵니다. Agentic Workflows를 쓰면 팀은 이슈 분류나 실패한 빌드 분석 같은 작업을 Markdown으로 기술하고 코딩 에이전트가 GitHub Actions에서 이를 수행하게 할 수 있습니다. 기본 권한은 읽기 전용이며, 제안된 변경이 적용되기 전에 별도의 작업이 이를 검사합니다.
GitHub의 Universe 글은 역할 분담을 한 문장으로 설명합니다. “개발자는 방향을 정하고, 결정을 내리며, 출시되는 것에 대한 책임을 집니다.” InfoWorld가 인용한 한 애널리스트는 이것이 실제로 무엇을 뜻하는지 짚었습니다. 컨설팅 회사 Kanerika에서 AI 개발을 이끄는 Amit Kumar Jena는 “예를 들어 10개의 병렬 에이전트 세션은 검토가 필요한 풀 리퀘스트 10개를 만들어 낼 수 있습니다”라고 말했습니다.
70퍼센트는 완료가 아니다
GitHub 밖의 새로운 테스트는 왜 그 검토를 건너뛸 수 없는지 보여 줍니다. 10월 26일 Alibaba와 여러 대학의 연구자들은 Co-Design Bench를 발표했습니다. 실제 사용자 코딩 세션 26'314건에서 뽑은 273개 과제로, 각 과제는 전문가가 작성한 숨겨진 인수 기준, 모두 2'331개에 비추어 검증됩니다. 같은 에이전트 환경에서 실행한 10개 모델 가운데 가장 강력한 모델은 과제당 평균 69.9퍼센트의 기준을 충족했지만, 과제를 완전히 충족한 경우는 26.4퍼센트에 불과했습니다. 11월 8일 이 연구를 보도한 The Decoder는 코딩 에이전트가 여전히 “과제 네 개 중 거의 세 개에서 사람의 마무리 작업이 필요하다”고 썼습니다.
이 연구에는 한계가 있습니다. 각 과제는 하나의 고정된 요청이어서 에이전트가 질문하거나 도중에 수정받을 수 없었고, 채점은 틀릴 수 있는 AI 심사자가 맡았으며, 저자 여러 명이 Alibaba 소속인데 테스트된 모델 가운데에는 Alibaba의 Qwen 모델도 있었습니다. 그래도 이 연구가 측정한 격차, 즉 요구 사항의 대부분과 전부 사이의 격차는 바로 검토자가 메우기 위해 존재하는 격차입니다.
좋은 팀이 지금 하는 일
이 모든 것에는 새로운 도구보다 오래된 규율을 더 엄격하게 적용하는 일이 필요합니다. 명세에서 시작하십시오. 에이전트가 변경의 초안을 쓸 때는 작성된 과제가 진짜 원천이며, Jena는 “잘못 정의된 과제는 반복 실행, 재작업, 더 많은 AI 크레딧 소비로 이어질 수 있다”고 경고했습니다. Co-Design Bench가 인수 기준을 먼저 정하듯, 에이전트가 시작하기 전에 완료가 무엇을 뜻하는지 적어 두십시오.
변경은 읽을 수 있을 만큼 작게 유지하십시오. GitHub에 따르면 관련 작업을 더 작은 변경으로 나눠 순서대로 검토하는 스택형 풀 리퀘스트는 프리뷰 출시 두 달 만인 9월까지 264'000명이 넘는 개발자가 사용했습니다. 테스트를 관문으로 삼으십시오. 변경은 테스트를 통과하기 전에는 사람에게 도달해서는 안 되며, 테스트 자체는 가장 꼼꼼히 검토해야 합니다. 자신의 테스트를 수정할 수 있는 에이전트는 무엇이든 통과시킬 수 있기 때문입니다.
마지막으로 사람을 지정하십시오. 출시되는 모든 변경에는 그것을 승인하고 설명할 수 있는 누군가가 필요하며, 그 누군가는 에이전트일 수 없습니다. CIO들에게 건네는 Jena의 조언도 같습니다. “에이전트가 생성한 풀 리퀘스트를 병합하기 전에 사람의 승인을 필수로 하십시오.”
도구는 꺼질 수 있다
Conductor 인수는 더 조용한 교훈을 더합니다. TechCrunch는 11월 4일 Meta가 2024년에 설립된 이 스타트업을 인수했다고 보도했습니다. Conductor의 에이전트 팀은 Anthropic, OpenAI 같은 연구소의 에이전트를 활용하며, “소프트웨어 엔지니어가 프로젝트의 분리되고 구획된 부분들을 협력하여 작업하도록 돕기 위해 설계되었습니다.” Meta는 인수를 확인했지만 조건은 밝히지 않았습니다.
Conductor의 자체 공지가 일정을 정합니다. 신규 가입은 11월 4일에 중단되었고, 클라우드 워크스페이스는 11월 13일부터 읽기 전용이 되며, 11월 20일부터 회사는 클라우드 사용자 데이터를 삭제하기 시작합니다. 따라서 고객에게는 그곳에 보관한 것을 내보낼 시간이 16일 있습니다. 데스크톱 앱은 당분간 계속 작동하며 2027년 초부터 단계적으로 종료됩니다. Conductor는 사용자 데이터를 판매하거나 학습에 사용한 적이 없다고 말하며, 내보내기와 로컬 앱으로의 이전을 제공합니다.
여기에 악의가 있다는 징후는 없습니다. 이는 에이전트를 실행하는 계층이 아직 얼마나 새롭고 불안정한지 보여 줍니다. 에이전트의 워크스페이스와 대화를 보관하는 서비스가 몇 주 만에 인수되고 문을 닫을 수 있습니다. 중요한 것은 직접 통제하는 곳에 두십시오. 코드와 그 이력은 자체 저장소에, 명세와 결정은 그 옆에 글로 적어 두고, 어느 공급업체의 에이전트든 반드시 통과해야 하는 테스트를 갖추십시오.
저희의 입장
저희의 앱 플랫폼 Werk는 제공 중이며, 바로 이런 역할 분담 위에 만들어졌습니다. 코드의 대부분은 저희가 만들고 신뢰하는 프레임워크 위에서 AI가 쓰고, 무엇을 만들지 정하고 어떤 느낌을 줄지 설계하며 모든 릴리스를 검토하는 것은 사람이며, 모든 릴리스는 테스트를 거칩니다. 코드는 귀사의 것이며, 그 아래의 플랫폼은 계속 성장합니다. 저희가 향해 가는 다음 단계는 일상적인 변경과 수정을 스스로 출시하는 에이전트입니다. 릴리스 전에 테스트와 검토를 거치며, 이는 명세, 테스트, 검토가 이미 자리를 잡았을 때에만 가능합니다.



