9억 8,600만 개의 코드 푸시가 2025년 개발자 워크플로에 관해 말해주는 것

오늘날 소프트웨어를 구축하고 있다면 아마도 지금은… 정말 빠르다는 것을 눈치채셨을 것입니다. 그리고 그것이 바로 그것입니다: 그것은 단지 저것 우리는 더 빠르게 코딩합니다. 그것은 어떻게 우리는 변경된(그리고 변경 중인) 코드를 작성하고 검토하고 배송합니다.

Octoverse 2025 보고서를 보셨을 수도 있지만, 아직 보지 못하신 경우를 대비해 통계는 매우 다양합니다. 개발자는 230개 이상의 저장소를 만들었습니다. 분당 작년에 9억 8천 6백만 건의 커밋을 푸시했습니다. 거의 10억 개의 커밋이 이루어졌습니다! 와 비!

개발자(및 개발자 팀)가 전반적으로 더 빠르게 움직이고 있기 때문에 다른 선택을 해야 한다는 기대가 있습니다. 왜냐하면 그들은 더 빠르게 움직이고 있어요. 더 빠르게 움직이면 워크플로도 변경됩니다.

반복이 기본 상태입니다.

정말 흥미로운 점은 이것이 일시적인 급증처럼 느껴지지 않는다는 것입니다. 반복의 실제 장기적인 변화처럼 느껴집니다. 분기마다 한 번씩 대규모 릴리스를 출시하던 시대는 빠르게 지나가고 있습니다.

개발자들은 모든 것이 “준비”되었을 때만이 아니라 끊임없이 추진하고 있습니다. 더 작고 더 빈번한 커밋이 점점 더 일반화되고 있습니다. 개인적으로 나는 그것을 좋아합니다. 아무도 거대한 1000줄짜리 풀 리퀘스트를 항상 검토하고 싶어하지 않습니다. (그들의 눈이 번쩍 뜨일 때 필연적으로 “LGTM”을 집어넣을 뿐입니다.) 여전히 더 많은 코드가 있고 더 빠르게 배송되지만 버스트는 더 적습니다.

새로운 표준은 가벼운 커밋입니다. 버그를 수정하고, 작은 기능을 작성하고, 일부 구성을 조정하고… 푸시합니다. 우리가 보고 있는 변화는 일이 계속해서 움직이고 있다는 것이며, 일이 거대한 덩어리로 “완료”되었다는 것이 아닙니다. 왜냐하면 “완료”는 일시적이기 때문입니다!

“미술 코드는 결코 끝나지 않습니다. 버려진 반복되었습니다.”

레오나르도 다빈치 Cassidy와 ​​현재 대부분의 개발자

그리고 개발자들은 지속적인 배송이 위험을 줄이는 것임을 알고 있습니다. 작고 빈번한 변경은 디버그하기 쉽고, 문제가 발생할 경우 롤백하기가 더 쉽습니다. 문제를 해결하기 위해 한 달 동안의 변경 사항을 조사할 필요가 없습니다. 이 주기는 팀이 품질, 커뮤니케이션, 채용에 대해 생각하는 방식을 바꿉니다. 귀하의 팀이 여전히 무언가를 출시하기 위해 몇 주를 기다리는 속도로 움직이고 있다면 귀하의 팀은 솔직히 말해서처럼 일하지 않습니다. 많은 세상의 일은 더 이상 없습니다.

이제 배송이 달라진 것 같아요

우리는 다르게 반복하고 있기 때문에 다르게 배송됩니다. 실제로는 다음과 같습니다.

• 추가 기능 플래그: 기능 플래그는 “A/B 테스트 및 으스스한 실험 기능용”이었습니다. 이제 그들은 불완전한 작업을 안전하게 배송하는 방법의 핵심입니다. 기능 플래그는 어디에나 있으며 팀이 토글 뒤에 코드를 제공할 수 있습니다. “아마도” 기능을 밀어서 작동시켜 보고, 작동 방식을 확인한 다음 문제가 옆으로 진행되면 즉시 끌 수 있습니다. 팀은 극단적인 사례를 완료하기 위해 릴리스를 보류할 필요가 없습니다. 그리고 기능 플래그는 이제 나중에 고려하는 것이 아니라 기본 워크플로의 일부가 되었습니다.
• CI/CD가 모든 것을 실행합니다.: 푸시할 때마다 테스트, 빌드, 아티팩트 생성, 보안 검색 등 일련의 이벤트가 시작됩니다. 통과하면 배포됩니다. 개발자는 파이프라인이 자동으로 시작되기를 기대하며 수동 배포는 점점 더 드물어지고 있습니다.
• 더 작고 집중된 풀 요청: 풀 리퀘스트는 더 이상 소설이 아닙니다. 우리는 단일 목적을 가진 더 짧고 읽기 쉬운 풀 리퀘스트를 보고 있습니다. 검토하는 것이 더 쉽고 빠르며 정신적 부담만으로도 속도가 빨라지고 뇌 세포가 절약됩니다.
• 테스트 드라이브 모멘텀: 사용된 개발자 115억 GitHub Actions 분 작년에 테스트를 진행했습니다(35% 증가! ab와 함께! 다시 한번!). 이러한 모든 자동화를 통해 단위 테스트, 통합 테스트, 엔드 투 엔드 테스트 및 모든 테스트가 점점 더 필요해지고 있습니다. 자동화는 우리가 새로운 속도를 따라가는 방법이기 때문입니다.

팀의 의사소통 방식도 바뀌어야 합니다

개발자의 워크플로우가 변했다는 것은 이제 사실입니다. 하지만 저는 개인적으로 개발에 관한 커뮤니케이션도 이에 따라야 한다고 생각합니다.

제가 그 미래를 상상하는 방법은 다음과 같습니다.

• 스탠드업은 더 짧습니다(또는 비동기).
• 상태 업데이트는 이슈(그리고 회의가 아닌 “코드가 존재하는 곳”)에 존재합니다.
• “풀 요청이 아직 검토되지 않아 차단되었습니다”는 더 이상 허용되지 않습니다.
• 빠르게 배송할 수 있는 사람을 채용하는 방향으로 변화하고 있습니다. 그리고 명확하게 소통하세요.

예, 코드가 빨라졌으므로 개발자도 더 빠르게 움직여야 합니다.

개발자는 여전히 엔지니어링 속도의 일부입니다. 그러나 개발자 워크플로로 인해 작업 속도가 너무 느려져서는 안 됩니다.

이것을 가지고 가세요

2025년의 급격한 변화 이후 2026년 개발자 워크플로가 어떤 모습일지 지켜보는 것도 흥미로울 것입니다.

나는 “AI 피로”가 믿을 수 없을 정도로 현실적이고 타당하다고 생각하며, 자연적인 생산성 향상 요소가 성공하고 마찰을 추가하는 도구가 사라지면서 많은 도구가 중도에서 사라지는 것을 보게 될 것입니다. 그러나 나는 또한 끊임없이 변화하는 성공 지표를 위한 새로운 “기준”으로 새로운 표준과 도구가 등장할 것이라고 생각합니다.

앞으로는 사양과 코드가 더 가깝게 공존하게 될 것입니다(마크다운에서 코드로의 작업 흐름은 계속 성장할 것입니다). 이는 팀 간의 의사소통이 더 많아지고 전체적으로 더 많은 문서가 작성된다는 것을 의미합니다. 그리고 우리는 그것이 필요하기 때문에 (AI 툴링 채택이 여전히 느린 회사에서도) 점점 더 지속적이고 협력적인 배송을 계속 보게 될 것입니다.

올해 우리는 끌어오기 요청, 전체 프로젝트, 기여 등의 측면에서 전반적으로 많은 성장을 보았습니다. 그렇다면 어느 정도 안정화가 이루어질 수 있을까요?

그러나 물론 유일한 상수는 변화입니다.

작성자:

Cassidy는 GitHub의 개발자 옹호 부문 선임 이사입니다. 그녀는 소프트웨어 구축, 스타트업에 조언, 개발자에게 더 나은 구축 방법을 가르치는 것을 좋아합니다. 그녀는 cassidoo.co/newsletter에서 주간 뉴스레터를 발행하고 있으며 여기에서 업데이트를 받고, 코딩 문제를 연습하고, 받은 편지함에 농담을 보낼 수 있습니다!