개발 동향 정리 (2026.09.13) - Copilot 리뷰, Kotlin ADK, GitHub Actions, Chrome

개발 도구 관련 소식은 며칠만 지나도 새로운 기능과 방식이 쌓인다. 2026년 9월 13일 기준, 최근 발표 중 코드 리뷰와 에이전트 운영, CI/CD, 웹 개발 방식에 직접 닿는 내용을 정리해본다.

1. GitHub Copilot code review - 리뷰 후 수정 확인까지

GitHub는 9월 11일 Copilot code review의 분석과 자동 해결 기능을 업데이트했다. 이전에는 AI가 리뷰 코멘트를 남기는 데 초점이 맞춰졌다면, 이제는 후속 커밋이 지적 사항을 해결했는지 다시 분석하고 코멘트의 해결 상태를 자동으로 갱신한다.

수정 내용을 설명하는 커밋 메시지 생성, 셸 도구를 이용한 검증, 여러 분석 결과를 종합하는 리뷰 방식도 추가됐다. 코드만 읽고 의견을 내는 단계를 넘어, 수정과 실행 결과를 확인하는 쪽으로 범위가 넓어진 셈이다.

그림 1. 요구사항부터 리뷰·PR까지의 에이전트 작업 흐름

팀에서 이 기능을 사용할 때는 AI 리뷰 통과만으로 병합하지 않는 편이 좋다. 빌드와 테스트 결과, 사람이 확인해야 하는 변경 범위를 별도의 조건으로 두면 자동 리뷰의 속도를 이용하면서도 잘못된 판단을 걸러낼 수 있다.

출처: GitHub Changelog - Copilot code review 업데이트

2. VS Code Agents - 사용 여부도 팀 지표로 확인한다

같은 날 GitHub는 Copilot usage metrics에 VS Code Agents 활동을 추가했다. 조직 관리자는 에이전트가 실제 개발 과정에서 얼마나 사용되는지 확인할 수 있다.

AI 코딩 도구의 평가는 개인의 체감에 의존하기 쉬웠다. 사용량이 보이면 어느 팀과 작업에서 에이전트가 자주 쓰이는지 확인하고, 도입 전후의 변화를 비교할 수 있다.

다만 사용 횟수가 많다는 사실이 곧 생산성 향상을 뜻하지는 않는다. 리뷰에 걸린 시간, 사람이 다시 고친 코드의 비율, 배포 후 결함 같은 지표와 함께 봐야 실제 도움이 된 영역을 구분할 수 있다.

출처: GitHub Changelog - VS Code Agents usage metrics

3. Harness Engineering - 결과뿐 아니라 행동을 평가한다

Google Developers Blog는 AI 코딩 에이전트를 운영하는 방법으로 Harness Engineering을 소개했다. 여기서 하네스는 모델이 코드를 수정하고 테스트를 실행할 수 있도록 감싸는 도구와 규칙, 평가 환경을 뜻한다.

최종 코드가 테스트를 통과했더라도 과정이 적절했다고 단정할 수는 없다. 에이전트가 어떤 도구를 호출했는지, 필요한 테스트를 실제로 실행했는지, 수정하면 안 되는 파일을 건드렸는지까지 기록해야 같은 종류의 실패가 반복되는 이유를 찾을 수 있다.

그림 2. 에이전트 실행과 평가를 반복하는 Harness Engineering 구조

평가 결과는 모델 점수로 끝나지 않는다. 실패한 작업을 기준으로 프롬프트와 도구 설명, 접근 권한, 테스트를 수정하고 다시 실행하는 반복 구조를 만든다. 모델을 교체하기 전에 주변 실행 환경을 먼저 다듬어야 한다는 이야기다.

출처: Google Developers Blog - The anatomy of Harness Engineering

4. Tunix와 TPU - LLM 학습 과정도 에이전트가 반복한다

Google은 Tunix와 TPU를 이용한 autonomous LLM post-training 사례를 공개했다. 사람이 매번 학습 설정을 바꾸는 대신, 에이전트가 실험 결과를 읽고 다음 파인튜닝 전략을 계획한 뒤 새로운 실험을 실행하는 방식이다.

하나의 설정으로 학습을 끝내는 구조가 아니라 결과 평가와 다음 설정 생성을 반복한다. 코드 작성에 먼저 들어온 에이전트 방식이 데이터 준비, 모델 평가, 파인튜닝 같은 모델 개발 파이프라인으로 이동하고 있음을 보여준다.

당장 일반 애플리케이션 팀이 그대로 도입할 도구라기보다 연구와 AI 플랫폼 영역에 가까운 사례다. 그래도 반복 실험을 자동화할 때 결과만 모으는 것이 아니라, 에이전트가 선택한 설정과 판단 근거를 함께 남겨야 한다는 점은 다른 개발 자동화에도 적용할 수 있다.

출처: Google Developers Blog - Autonomous LLM post-training with Tunix on TPUs

5. ADK for Kotlin 1.0 - Android와 JVM으로 넓어진 에이전트 개발

Google은 Agent Development Kit for Kotlin 1.0을 발표했다. Kotlin/JVM과 Android에서 프로덕션용 AI 에이전트를 만들 수 있도록 세션 관리, 도구 연결, 멀티 에이전트 구성을 제공한다.

에이전트 프레임워크는 Python 예제가 많은 편이었지만, 이번 발표로 기존 Kotlin 백엔드와 Android 앱에서도 같은 개발 방식을 적용하기 쉬워졌다. 이미 JVM에 작성된 도메인 로직을 다른 언어로 다시 옮기지 않고 에이전트의 도구로 연결할 수 있다는 점이 실용적이다.

Android에서는 앱의 화면과 사용자 입력을 담당하는 부분, 서버에서 긴 작업을 수행하는 에이전트를 나누어 설계할 수 있다. 모바일에서 모든 처리를 직접 맡기기보다 네트워크 상태와 실행 시간, 사용자의 승인 시점을 함께 정하는 것이 중요하다.

출처: Google Developers Blog - ADK for Kotlin 1.0

6. GitHub Actions - 캐시 권한과 PR 검사를 더 세밀하게

GitHub는 9월 10일 Actions 캐시의 접근 방식을 제어하는 cache mode를 추가했다. 워크플로의 역할에 따라 캐시를 읽기만 하게 하거나 쓰기까지 허용할 수 있다.

캐시는 빌드 시간을 줄여주지만, 신뢰할 수 없는 Pull Request가 같은 캐시에 값을 쓰면 이후 작업에 영향을 줄 수 있다. 외부 기여 코드나 자동 생성 코드를 검사하는 작업에는 읽기 권한만 주고, 신뢰된 브랜치의 빌드에서만 쓰기를 허용하는 식으로 구분할 수 있다.

같은 날 Pull Request용 AI Scan API도 공개 미리보기로 나왔다. PR 단계에서 AI 기반 코드 검사를 실행할 수 있어, 에이전트가 만든 변경을 정적 분석과 정책 검사에 연결하는 흐름을 구성할 수 있다.

그림 3. 최소 권한과 단계별 검증을 적용한 AI·CI 흐름

AI가 코드를 수정하는 범위가 넓어질수록 CI 권한도 한 덩어리로 주기보다 단계별로 나누는 편이 안전하다. 저장소 쓰기, 캐시 쓰기, 배포 권한을 분리하고 각 검사를 통과한 작업만 다음 단계로 넘기는 구조가 필요하다.

출처: GitHub Changelog - Actions cache mode, GitHub Changelog - AI Scan for pull request APIs

7. Chrome - 안정 버전도 2주마다 나온다

Chrome은 안정 버전의 릴리스 주기를 4주에서 2주로 단축하는 계획을 발표했다. 웹 플랫폼 기능과 보안 수정이 더 빠르게 사용자에게 전달된다.

프런트엔드 팀에서는 브라우저 변화에 대응할 시간도 함께 짧아진다. 특정 버전에서만 동작하는 기능이 있는지, 배포 뒤 화면이나 입력 동작이 달라지지 않았는지를 더 자주 확인해야 한다.

버전 번호를 사람이 따라가는 방식보다 크로스 브라우저 자동 테스트와 기능 탐지를 사용하는 편이 안정적이다. 새 기능은 지원 여부를 확인한 뒤 켜고, 문제가 생겼을 때 되돌릴 수 있도록 단계적으로 배포하는 구조도 중요해진다.

출처: Chrome for Developers - Chrome moves to a two-week release schedule

그래서 무엇을 확인하면 좋을까?

이번 발표들은 서로 다른 제품의 소식이지만, 개발 자동화가 코드 생성 이후의 단계로 넓어지고 있다는 공통점이 있다. 리뷰 결과를 다시 확인하고, 에이전트의 행동을 기록하며, 실행 단계마다 권한을 나누는 기능이 함께 등장했다.

새 도구를 적용할 때는 먼저 완료 여부를 테스트로 확인할 수 있는 작은 작업을 맡겨보는 것이 좋다. 에이전트가 수정한 파일과 실행한 명령을 남기고, 테스트와 사람의 리뷰를 통과한 뒤에만 병합이나 배포 권한을 주면 도입 효과와 위험을 함께 살펴볼 수 있다.