728x90
반응형

github 11

GitHub 별 기록 API 2,511번→24번: 개인정보를 덜 모으고 DB도 가볍게 만든 설계

오픈소스 프로젝트 운영자는 출시나 발표 이후 관심도가 얼마나 늘었는지 별(star) 변화 곡선으로 확인합니다. 그런데 기존 GitHub API로 이 곡선을 만들려면 별을 누른 사람과 시각을 페이지마다 받아 신원은 버리고 날짜만 다시 집계해야 했습니다.GitHub는 2026년 10월 14일 이 과정을 개인정보 노출과 데이터베이스 부하를 함께 줄이는 전용 별 기록 API로 재설계한 과정을 공개했습니다.3줄 핵심 요약GitHub는 저장소 별(star) 성장 추세를 조회할 때 사용자 신원 없이 날짜별 개수만 반환하는 전용 API를 만들었습니다.react/react 전체 기록을 재구성하는 요청은 약 2,511회에서 24회로 줄고, 한 요청은 최대 30주의 일별 집계를 제공합니다.핵심은 응답 크기만 줄인 것이 아니..

형식 없는 비밀번호도 코드 문맥으로 찾는다: GitHub의 새 비밀정보 탐지 모델

API 키처럼 일정한 접두사와 길이를 가진 비밀정보는 규칙으로 비교적 쉽게 찾을 수 있습니다. 하지만 설정 파일에 적힌 평범한 비밀번호나 사내 시스템의 짧은 인증 문자열은 일반 텍스트와 구분하기 어렵습니다.GitHub는 2026년 10월 7일 토큰 모양만 찾는 대신 주변 코드의 의미를 함께 읽는 비밀정보 탐지 전용 모델을 공개했습니다.3줄 핵심 요약GitHub가 주변 코드 문맥을 분석해 정해진 토큰 형식이 없는 비밀번호와 인증정보까지 찾는 전용 AI 모델을 공개했습니다.기존 AI 기반 Password 경고 사용자는 자동으로 새 모델을 적용받고, 푸시 차단과 Copilot 보안 검토 연동은 비공개 미리보기 단계입니다.탐지 범위가 넓어져도 오탐과 누락은 남을 수 있으므로 발견된 비밀정보는 즉시 폐기·교체하고..

큰 PR을 잘게 나눠도 순서대로 합친다: GitHub 스택형 풀 리퀘스트 정식 출시

기능 하나가 수천 줄짜리 풀 리퀘스트가 되면 리뷰가 늦어지고 충돌과 누락 위험이 커집니다. 너무 잘게 나누면 이번에는 어떤 변경부터 합쳐야 하는지와 각 브랜치의 기준이 복잡해집니다.GitHub는 2026년 10월 6일 여러 풀 리퀘스트를 순서가 있는 하나의 묶음으로 관리하는 스택형 풀 리퀘스트를 정식 출시했습니다.3줄 핵심 요약GitHub가 큰 변경을 서로 연결된 작은 풀 리퀘스트로 나누는 스택형 풀 리퀘스트를 정식 출시했습니다.승인 보존, 서명된 리베이스, 병합 큐 그룹 처리와 자동 대상 변경이 추가돼 스택을 유지하는 수작업이 줄었습니다.기능은 모든 github.com 요금제에서 사용할 수 있지만 변경 순서와 의존 관계를 명확히 관리해야 리뷰 혼선을 줄일 수 있습니다.스택형 풀 리퀘스트는 무엇인가하나의..

AI가 코드를 너무 빨리 만든다: GitHub가 Git 저장 구조를 다시 짓는 이유

AI 코딩 에이전트는 사람이 눈치채기 어려운 지연도 반복 작업마다 누적시킵니다. 작은 수정마다 커밋하고 여러 에이전트가 각자 브랜치를 밀어 올리면 저장소의 읽기뿐 아니라 쓰기 병목이 빠르게 커집니다.GitHub는 2026년 10월 6일 이런 ‘에이전트 규모’의 개발을 감당하기 위해 Git 인프라의 내구성 계층과 요청 처리 계층을 분리하는 재설계 방향을 공개했습니다.3줄 핵심 요약GitHub는 개발자와 AI 에이전트의 동시 작업 증가에 맞춰 Git 저장소 인프라를 새 구조로 재설계하고 있습니다.2025년 9월부터 2026년 8월 사이 월간 Git 활동은 2,182억 건에서 4,733억 건으로 늘었고, 2026년 9월 커밋은 73억 8천만 건에 달했습니다.새 구조는 저장과 연산을 분리하고 꼭 필요한 참조 업..

AI 코드 리뷰, 무엇이 더 정확할까: GitHub가 공개한 ReviewBench

AI가 코드 리뷰 의견을 빠르게 제안해도 그 의견이 실제 결함인지, 중요한 문제를 얼마나 놓쳤는지는 쉽게 알기 어렵습니다. GitHub는 2026년 10월 5일 AI 코드 리뷰 에이전트를 공통 조건에서 평가하는 ReviewBench를 공개했습니다.실제 GitHub 풀 리퀘스트 분포를 바탕으로 만든 데이터와 공개된 평가 기준을 이용해 정확성과 탐지 범위를 함께 비교하려는 시도입니다.3줄 핵심 요약GitHub가 AI 코드 리뷰 도구를 같은 기준으로 비교할 수 있는 공개 벤치마크 ReviewBench를 연구 프리뷰로 공개했습니다.219개 공개 풀 리퀘스트와 19개 프로그래밍 언어를 대상으로 정확도와 탐지 범위, 심각도·유형별 성능을 평가합니다.벤치마크 점수는 도구 선택의 참고 자료일 뿐이며 실제 배포 전에는 ..

AI 시대 개발자는 무엇을 배워야 할까: GitHub가 꼽은 3가지 핵심 역량

AI 코딩 도구가 코드를 더 빠르게 만드는 시대에 개발자는 무엇으로 실력을 증명해야 할까요. GitHub는 2026년 10월 2일 공개한 개발자 경력 글에서 코딩 자체는 여전히 중요하지만, AI를 지휘하고 결과를 평가하며 기술적 판단을 내리는 능력의 가치가 커지고 있다고 정리했습니다.핵심은 프롬프트 요령 하나가 아니라 일의 결과를 책임지는 세 가지 역량입니다.3줄 핵심 요약GitHub는 AI가 구현을 더 많이 맡을수록 문제 정의, 맥락 제공과 작업 분배 능력이 중요해진다고 설명했습니다.AI의 첫 답을 그대로 믿지 않고 코드·테스트·성능·보안을 비판적으로 검토하는 기술 판단이 핵심입니다.절약한 시간을 고객 문제, 설계의 장단점, 접근성과 성공 기준처럼 더 큰 문제를 푸는 데 써야 합니다.첫째, AI를 쓰는..

AI 보안 에이전트가 안드로이드 취약점 24개를 찾은 방법

AI가 코드를 읽고 취약점을 찾는 도구가 늘고 있지만, 모바일 앱의 진입점과 컴포넌트 관계를 이해해야 하는 감사는 여전히 어렵습니다. GitHub Security Lab은 2026년 9월 28일 공개 오픈소스 AI 보안 에이전트로 안드로이드 앱을 감사한 과정과 결과를 소개했습니다.24개 취약점이라는 결과보다 중요한 것은 앱 유형에 맞춘 점검 흐름과, AI의 판단을 사람이 검증하는 방식입니다.3줄 핵심 요약GitHub Security Lab이 공개한 Taskflow Agent로 모바일 애플리케이션을 감사해 지금까지 24개의 안드로이드 취약점을 찾아 보고했다고 밝혔습니다.에이전트는 진입점과 컴포넌트를 분류하고, 앱에 맞춘 취약점 점검 흐름을 반복해 로직 버그와 WebView·딥링크 문제까지 탐색했습니다.LL..

AI가 퍼징을 끝까지 돌린다: GitHub Security Lab의 Taskflow Agent

퍼징은 입력을 무작위로 바꿔 소프트웨어의 예외와 취약점을 찾는 강력한 방법이지만, 하네스를 만들고 커버리지를 읽고 크래시를 분류하는 사람의 시간이 병목이 됩니다. GitHub Security Lab은 2026년 9월 24일 이 반복 작업을 LLM 에이전트에게 맡기는 Fuzzing Taskflow를 소개했습니다.단순히 퍼저를 한 번 실행하는 도구가 아니라, 커버리지 피드백을 받아 다음 실행을 설계하는 자동화 파이프라인이라는 점이 핵심입니다.3줄 핵심 요약GitHub Security Lab이 C·C++ 저장소의 퍼징 준비, AFL++ 실행, 커버리지 개선, 크래시 분류를 이어서 수행하는 Taskflow를 공개했습니다.에이전트는 커버리지에서 비어 있는 경로를 찾아 시드·하네스·사전 토큰을 바꾸며 반복하고, 두..

GitHub Copilot 앱, 캔버스로 나만의 업무 화면을 만든다

고정된 메뉴에 업무를 맞추는 대신, 업무 흐름에 맞춰 화면을 만들 수 있다면 어떨까요. GitHub는 2026년 9월 25일 GitHub Copilot 앱의 캔버스 기능을 소개했습니다.캔버스는 사용자와 에이전트가 같은 상태를 보며 버튼·카드·필터를 조작하는 맞춤형 작업 화면입니다. 이번 글에서는 캔버스가 무엇을 바꾸는지와 도입할 때 확인할 점을 정리합니다.3줄 핵심 요약GitHub Copilot 앱의 캔버스는 에이전트와 사용자가 같은 화면 상태를 함께 편집하는 사용자 정의 작업 공간입니다.코드를 직접 작성하지 않고 /create-canvas 명령과 자연어 설명만으로 칸반 보드·이슈 분류표·릴리스 체크리스트 등을 만들 수 있습니다.에이전트가 화면을 바꾸더라도 코드 리뷰와 권한 확인은 필요하므로, 작은 업무..

GitHub가 CSS를 더 보내며 사이트를 더 빠르게 만든 방법

웹 성능 문제는 눈에 띄는 큰 기능보다 페이지마다 반복되는 작은 런타임 비용에서 시작되기도 합니다. GitHub는 2026년 9월 25일 Primer 디자인 시스템과 GitHub.com에서 CSS-in-JS를 걷어내고 CSS Modules로 옮긴 과정을 공개했습니다. 단순한 스타일 문법 교체가 아니라, 서버 렌더링과 브라우저 초기화 비용을 줄이면서도 수천 개 컴포넌트를 안전하게 전환한 점이 핵심입니다.3줄 핵심 요약GitHub는 CSS-in-JS 런타임을 줄이고 CSS Modules로 전환해 Primer 컴포넌트의 서버 렌더링 시간을 55%, 초기화를 25% 줄였다고 공개했습니다.sx prop 마이그레이션은 8명이 6개월 동안 6,419개를 옮겼고, 이후 Copilot 코딩 에이전트를 활용해 남은 895..

728x90
반응형