커밋은 늘었고 에이전트는 IDE 안으로 들어왔다

2026 Octoverse 리포트가 나왔다. 제목이 직접적이다. "커밋·푸시가 역대 최고치, 개발자들이 에이전트와 함께 만들고 있다." GitHub Universe 2026 기조연설 바로 다음 날 공개됐고, Universe에서는 GitHub을 "세계에서 가장 종합적인 엔드투엔드 소프트웨어 딜리버리 시스템"으로 만들겠다는 비전을 선언했다.

수치는 화려하다. 근데 처음 읽었을 때 드는 감정은 기쁨이 아니었다. "저 커밋의 몇 퍼센트가 내가 실제로 판단해서 쓴 코드일까"였다.

숫자 뒤에 있는 질문

에이전트가 코드를 생성하면 커밋 수는 당연히 는다. 초안을 빠르게 잡고, 검토하고, 수정하고, 다시 커밋하는 사이클이 짧아지기 때문이다. 나도 올해 들어 보조 흐름을 손에 익히면서 하루에 스테이징에 올리는 횟수가 예전보다 많아졌다.

이게 나쁜 건 아니다. 다만 "커밋이 늘었다 = 생산성이 올랐다"는 등식이 성립하는지는 여전히 불확실하다. 커밋은 원래 양이 아니라 의미의 단위였다. 에이전트가 코드의 상당 부분을 채우기 시작하면서 그 단위의 경계가 흐릿해진 느낌이 있다. Git log를 보는 것만으로 "어떤 판단이 어느 시점에 있었는지"를 추적하기 어려워진다.

소규모 팀이나 혼자 운영하는 코드베이스라면 이 문제가 더 두드러진다. 대형 조직은 코드 리뷰, 티켓 시스템, PR 설명으로 맥락이 여러 곳에 남지만, 두셋이서 빠르게 치는 구조에서는 커밋 메시지와 history가 사실상 유일한 내러티브다. 에이전트가 만든 코드에 내가 메시지를 붙이는데, 그 메시지가 내 판단을 제대로 담고 있는지 매번 확인해야 한다. 하지 않으면 일주일 뒤 내가 그 log를 읽어도 맥락이 없다.

Octoverse가 보여주는 성장 곡선은 분명 흥미롭다. 근데 그 성장의 구성이 무엇인지, 에이전트 생성 코드와 개발자가 직접 쓴 코드의 비율이 어떻게 되는지는 리포트에서 확인하기 어렵다. 수치보다 그 내부 구조가 더 궁금한 상황이다.

GitHub이 "스택 전체를" 선언할 때

Universe 2026의 메시지는 선명했다. 이슈, PR, 배포, 보안, 모니터링, 소프트웨어를 만들고 운영하는 전 과정을 하나의 플랫폼 안에서 끝내겠다는 것이다. Octoverse 수치는 그 비전의 근거로 동원됐다. "보라, 개발자들이 이미 이 방향으로 움직이고 있다."

나 같은 규모에게 이 방향은 양날이다.

긍정적인 면은 분명하다. 도구를 넘나드는 컨텍스트 스위칭이 줄어든다. 이슈를 열고, 거기서 에이전트에게 작업을 넘기고, PR이 올라오고, 파이프라인이 돌고, 배포가 이어지는 흐름이 한 화면에서 연결된다면 관리 부담이 실질적으로 줄어들 수 있다. 지금도 자동화 도구들로 어느 정도는 가능하지만, 그 연결이 더 촘촘해질수록 이음새에서 생기는 잡일이 줄어든다.

문제는 종속 비용이다. 한 플랫폼에 스택 전체를 올려놓으면, 그 플랫폼의 방향 전환 하나가 내 운영 전반에 영향을 준다. 지금 당장은 GitHub를 신뢰하지만, "엔드투엔드"를 내세우는 서비스가 역사적으로 어떤 경로를 밟았는지는 오래 개발한 사람이라면 잘 안다. 편리한 통합이 나중엔 탈출 비용이 된다.

그래서 GitHub이 제공하는 자동화는 적극적으로 쓰되, 핵심 파이프라인 정의는 플랫폼 중립적인 형태로 최대한 유지하는 방향을 고수한다. Universe 발표를 흥미롭게 읽으면서도 바로 따라가지 않는 이유가 여기 있다. 발표는 비전이고, 내가 실제로 쓸 수 있는 기능이 언제 어떤 형태로 나오는지는 별개다.

Android Studio에 에이전트를 붙이는 일

이번 주 Android Dev Summit에서 Android Studio Rabbit 2 안정화 발표가 나왔다. 여러 기능 중 "Bring Your Own Agent" - 직접 지정한 에이전트를 IDE에 붙이는 기능 - 이 실용적으로 보였다.

GitHub Universe와는 결이 다른 접근이다. 플랫폼이 어떤 에이전트를 쓸지 결정해 주는 게 아니라, 개발자가 자기 흐름에서 이미 쓰고 있는 에이전트를 IDE 안에 끌어다 쓸 수 있도록 인터페이스를 여는 것. 소규모 팀 입장에서는 이 방향이 훨씬 현실적이다. 이미 손에 익은 보조 흐름을 Android 개발 환경에도 그대로 가져올 수 있다면, 새로운 도구를 처음부터 배우는 비용이 줄어든다.

AI 코드 리뷰 기능도 함께 포함됐다고 한다. 이게 내 리뷰 습관을 보완하는 레이어로 쓰일지, 아니면 리뷰 자체를 에이전트에 떠넘기는 방향으로 흐를지는 직접 써봐야 안다. 에이전트가 잡아주는 패턴과 내가 신경 쓰는 맥락이 겹치는 부분과 그렇지 않은 부분을 가려내는 과정이 필요하다.

Rabbit 2는 안정 채널이라고 했으니 올려볼 수 있다. 다만 XR 에뮬레이터나 에이전트 스킬 매니저 같은 새 레이어들이 얼마나 무거운지 아직 모른다. 화려한 기능보다 "기존 빌드가 그대로 돌아가는가"를 먼저 확인하고 올릴 생각이다. 이 순서를 한 번 뒤집었다가 파이프라인이 꼬였던 기억이 있어서.

속도와 판단 사이

세 소식을 관통하는 흐름이 있다. 에이전트가 도구 안으로 통합되는 속도가 빨라지고, 그 통합이 수치로 보이기 시작했다는 것. Octoverse의 커밋 수, Universe의 비전, Rabbit 2의 IDE 통합, 모두 같은 방향을 가리킨다.

이 방향이 틀렸다고 생각하지는 않는다. 다만 도구가 스택 전체를 감싸줄수록, 내가 그 바깥 레이어를 직접 다룰 수 있는지 확인하는 루틴이 더 필요해진다. 커밋 수가 늘었다고 코드를 더 잘 이해하는 게 아니고, IDE에 에이전트가 붙었다고 설계 결정이 좋아지는 게 아니니까.

내년 이맘때 내 Git log를 열었을 때, 각 커밋이 무슨 판단에서 나왔는지 여전히 설명할 수 있어야 한다. 그게 에이전트와 협업하는 구조를 유지하는 데 내가 실제로 신경 쓰는 지표다.

참고한 글

• Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents - https://github.blog/news-insights/octoverse/octoverse-commits-pushes-reach-new-highs-in-2026-as-developers-build-with-agents/
• GitHub Universe 2026: Evolving every layer of the stack - https://github.blog/news-insights/company-news/github-universe-2026-evolving-every-layer-of-the-stack/
• Your favorite agents are now integrated in Android Studio - https://developer.android.com/blog/posts/ai-agents-android-studio-integration

짧게

Ghostty 1.4. 큰 방향 전환 없이 착실한 릴리스다. 터미널 에뮬레이터는 한 번 자리잡으면 잘 바꾸지 않는 도구인 만큼, 조용한 1.x 개선이 오히려 신뢰 지표가 된다.

Git for the US Code. 미국 법전을 Git으로 관리하는 접근이 나왔다. 변경 이력과 diff 가능한 문서 구조가 소프트웨어 바깥에서도 자연스럽게 채택되기 시작한다는 신호로 읽힌다. 설계 자체보다 "왜 지금인가"가 더 흥미로운 질문이다.

Emacs 50주년. 쓰지 않더라도, 50년간 사용자가 직접 확장해온 도구가 살아 있다는 사실은 확장성 설계의 교과서로 계속 참고할 만하다.

Genie 4 (DeepMind). 에이전트가 동작하는 환경 자체를 모델이 실시간으로 생성하는 방향이다. 당장 실용 단계는 아니지만, 시뮬레이션과 모델이 분리된 레이어였던 시간이 줄어들고 있다.

Gemini 4 Carbon. 모델 라인 명명 체계가 복잡해질수록 소비자 입장에서는 어떤 모델을 언제 쓸지 판단 비용이 올라간다. 기능 경쟁과 별개로, 이 쪽도 주시할 트렌드다.